DCMI Roadmap for development of Vocabulary Management and Schema Registry Systems

* * *

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. DCMI vocabulary diagram ## ### 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#