* * *
Title:
|
DCMI Roadmap for development of Vocabulary Management and Schema
Registry Systems
|
Editor: |
Harry Wagner |
Editor: |
Rachel Heery
|
Date Issued: |
2002-02-18 |
Identifier: |
http://dublincore.org/groups/registry/roadmap-20020117.html |
Previous version: |
No prior version |
Latest version:
|
|
Status of document:
|
This is a DCMI Working Draft.
|
Description of document:
|
IMPORTANT: sections 3 and 4 await comment
by Usage Board
This document provides high level requirements to inform development of
DCMI systems for
- managing the evolution of the DCMI Vocabulary
- navigating DCMI schemas
|
|
### 1. Introduction
This document derives from prior work within the DCMI Registry Working
Group related to the registry prototypes and their functional requirements. This document
presents a Roadmap for
further work on the registry, intended to help achieve the goal of an
operational service by 3rd quarter 2002.
Following discussions and meetings with other working groups at DC2001 in
Tokyo, a decision was made to consider future development of two systems: a DCMI
Vocabulary Management System and a DCMI Registry.This was based on differing
requirements emerging from the Usage Board (with a focus on managing evolution
and administration of DCMI terms) as opposed to people and software agents (with
focus on seeking information about DCMI terms).
Information on discussions and decisions that form background to this
document are available from the
Registry working group home page and the Registry
working group mailing list. Current Registry Prototypes can be accessed at
http://wip.dublincore.org:8080/registry/Registry.
### 2. Overview
The following diagram shows the components required to manage the DCMI
vocabulary and to provide registry service to human users and
applications. In addition the relationships between components are identified.
The remaining part of the document gives a high level view of the functionality
of each component.
##
### 3. Vocabulary Management System
Important: this section awaits comment by Usage
Board
Overall aim: To assist the Usage Board in the management and evolution of the
DC vocabulary
#### User Interface requirements
3.1 To provide authoritative description of all past and present DCMI
terms
3.2 To provide structured view (according to DCMI 'grammar' of elements,
element refinements and schemes) of all DCMI terms
3.3 To provide means to manage process of approving new terms
3.4 To provide a secure Web interface for adding new terms, and managing term
revisions, that have been approved by the DC Usage Board.
3.5 To provide historical audit of all changes to status and description of
terms
3.6 To manage multilingual descriptions of DC terms
3.7 To identify DCMI recommended names for schemes. In order to facilitate
this a means for registration of schemes by remote third parties will be
required, and means for the Usage Board to manage approval of the data
registered.
### 4. VMT output in other encodings
Important: this section awaits comment by Usage
Board
4.1 To provide authoritative outputs of DCMI vocabulary in various formats as
required (e.g. RDF schemas, XML schemas, text versions of descriptions of terms, etc).
### 5. VMT-Registry API
Important: this section awaits comment by Usage
Board
5.1 To provide output of authoritative description of all current DCMI terms
in format suitable for import to Registry (currently this would be by means of
schemas in RDFS).
5.2 To ensure RDFS schemas expressing the DCMI vocabulary indicate the
structure and relationship between terms (reflecting the DC 'grammar' of
elements, element refinements, controlled vocabularies and schemes). The schemas
will also need to include all information required by people seeking information
about terms i.e. Name, Label, Registration Authority, Language, Definition,
Comment.
5.3 To provide regular updates of the schemas.
### 6. DCMI Registry
Overall aim: The DCMI registry is designed to provide an added value
'information service' about DCMI vocabulary over and above a simple text
description of terms or a human readable text schema. The intention is to assist
humans and software to obtain reliable trusted information about DCMI terms.
Users: We have identified four categories of users of the registry
- information seekers : those looking for up to date information on the
semantics of DCMI terms. these might typically be metadata creators,
information specialists implementing new systems and looking for appropriate
terms for their schemas, librarians, etc. There will be novice and expert
users.
- software using the regsitry to obtain information about DCMI terms
- contributors: those who are authorised to import schemas
- system administrator
#### User Interface requirements
6.1 To provide a user-friendly interface for novice and expert users. For the
novice user all RDF jargon needs to be replaced with more accessible
terminology.
6.2 To provide comprehensive information about DC terms, the relationship
between those terms, and their usage. This information should be available to
all individuals (implementors of resource discovery systems, information
professionals, DC Usage Board, etc.) seeking information about the DCMI.
6.3 To provide complete listings of particular categories of terms e.g.
element refinements, elements, schemes, schemes associated with particular
elements, controlled vocabularies; as well as human readable version of DCMI
schemas:
-
http://purl.org/dc/elements/1.1/
-
http://purl.org/dc/terms/
-
http://purl.org/dc/dcmitype/
- To provide a multilingual interface (user interface dialogue, drop down
boxes etc to be translated).
- To provide multilingual descriptions of DCMI terms.
- To provide links to annotations, guidelines and other relevant documents.
- To provide access to authoritative mappings and crosswalks between DCMI
and other vocabularies.
### 7. Registry-Application API Functional Requirements
This API is intended to enable applications to gather information about DCMI
schemas to support their functionality. It is intended to reduce the need for
individual appliccations to store locally information about schemas. This will
assist applications to stay up-to-date regarding the schemas they use, and will
enable generic applications to infuse schemas in order to provide functionality
customised by the user's choice of schema. An example of such an application
might be metadata creation tool, query tool, user profiling tool.
7.1 To provide a machine-readable interface for navigating and searching
terms.
7.2 Support for an application to query the registry, select or contruct a
schema and import the resulting schema. The resulting imported schema might be
an existing DCMI schema, a sub-set or super-set of an existing DCMI schema, or
an expression of a DCMI application profile e.g. DC-Education profile,
DC-Government profile.
7.3 To provide access to authoritative mappings and crosswalks between DC and
other vocabularies.
### 8. Registry to Registry API
In future it is expected that the DCMI registry will interact with other
registries in order to enable a distributed registry service model. Details of
the relationsships between registries is not developed here, but might be
expected to enable exchange of schemas between registries and querying between
registries.
### 9. Definitions of terms in this document
DCMI term: A DCMI term is a DCMI element, a DCMI qualifier or term
from a DCMI-maintained controlled vocabulary. Each DCMI term is defined in a
DCMI recommendation and is identified by a Uniform Resource Identifier (URI)
within a DCMI namespace
DCMI namespace: A DCMI namespace is a collection of DCMI terms. Each
DCMI namespace is identified by a URI.
DCMI recommendation: A DCMI recommendation is a human-readable
document that may define one or more DCMI terms.
Term declaration: A term declaration is the machine-processable
representation of one or more terms, expressed in a schema language.
Application profile : An application profile is a term declaration
describing a set of terms used by a particular application, implementation or
'sector'. These terms will have already been identified by a unique namespace
which may or may not be a DCMI namespace. These terms will be selected from
already existing schema as optimal for use within a particular implementaion or
sector e.g. educational applications, library applications or even a particular
project application.
### 10. Relevant documents:
Dublin Core™ Metadata Element Set, Version 1.1: Reference Description
http://dublincore.org/documents/dces/
Dublin Core™ Qualifiers
http://dublincore.org/documents/dcmes-qualifiers/
Controlled vocabularies:
DCMI Box Encoding Scheme: Specification of the
spatial limits of a place, and methods for encoding this in a text string.
http://dublincore.org/documents/2000/07/28/dcmi-box/
DCMI Period Encoding Scheme: specification of the limits of a time interval,
and methods for encoding this in a text string.
[http://dublincore.org/documents/2000/07/28/dcmi-period/%20Draft%20RDF%20schemas](/specifications/dublin-core/dcmi-period/2000-07-28/
DCMI Point Encoding Scheme: a point location in space, and methods for
encoding this in a text string
http://dublincore.org/documents/2000/07/28/dcmi-point/
Draft DCMI schemas:
http://dublincore.org/2001/08/14/dces#
http://dublincore.org/2001/08/14/dcq#
http://dublincore.org/2001/08/14/dctype#