DCMI Registry : Background and demonstration DC2001 Tokyo October 2001

1. DCMI Registry : Background and demonstrationDC2001 Tokyo October 2001 r.heery@ukoln.ac.uk http://www.ukoln.ac.uk/ wagnerh@oclc.org www.dublincore.org Rachel Heery , UKOLN, University of Bath Harry Wagner, OCLC DC2001, Tokyo

2. DCMI Registry WG • Chartered post-DC7 Frankfurt - late 1999 • Working Group has had two aspects • defining functionality of registry • seeking software solution • First prototype DC8 Ottawa - 2000 • Further work on functionality, software • what content? DC2001, Tokyo

3. Definitions... ‘Schema’ • Names terms in a particular vocabulary (element set) • Declares definitions for a particular vocabulary • Expresses structure and relationship between terms • Can be expressed in different syntaxes • RDFS, XMLS, HTML, Word document etc DC2001, Tokyo

4. Definitions.. ‘Schema Registry’ • Provides access to schema declaration and adds value in some way. • Examples of added value might be : • Ease of navigation • Access to several related schemas • Mapping between schemas • Quality control (e.g. ISO11179 compliance) DC2001, Tokyo

5. Prototype schema registries • Meta-Form • http://www2.sub.uni-goettingen.de • - local usage of Dublin Core • Metadata for Education Group registry • http://desire.ukoln.ac.uk/registry/ - schemas related to education • SCHEMAS registry • http://www.schemas-forum.org/ - application profiles and related metadata activity reports ….. DCMI registry DC2001, Tokyo

6. People Publishers of standards Implementers seeking appropriate schemas Developers comparing schemas Metadata creators for assistance Functions Search for schemas, elements Browse and navigate schemas View annotations etc evaluate Who uses a registry? DC2001, Tokyo

7. Software tools Metadata instance editor Metadata instance validator Metadata transformation tool Application profile development tool … etc! Functions Identify terms Retrieve definitions of terms Retrieve usage recommendations (e.g. recommended schemes) Perform mappings Who uses registries? DC2001, Tokyo

8. Purpose of DCMI registry? Assisting DCMI • To manage evolution of DCMI vocabulary • To provide authoritative names and identifiers for terms • To provide authoritative definitions • To express relationship between terms • To manage multilingual aspects of the vocabulary … in machine readable and human readable mode DC2001, Tokyo

9. User categories • Information seekers : looking for up to date information on the semantics of DCMI terms • Computer specialists : developers using RDF/XML • Applications : software using the registry • Administrators : who may add, edit and delete entries DC2001, Tokyo

10. Some design principles • Registry will give user full information at level of individual terms, schema, and full vocabulary • Semantics • Structure of DCMI vocabulary • DCMI elements • DCMI qualifiers - element refinements and schemes • DCMI controlled vocabulary(s) - dcmitype • ISO 11179 full descriptions as in reference documents DC2001, Tokyo

11. Details of DCMI schemas • Infused by the three RDFS schemas which express DCMI vocabulary • http://purl.org/dc/elements/1.1/ • Dublin Core Metadata Element Set, Version 1.1 • http://purl.org/dc/terms/ • all otherDCMI elements and DCMI qualifiers • http://purl.org/dc/dcmitype/ • DCMI Type Vocabulary DC2001, Tokyo

12. Name Identifier Registration Authority Language Definition Obligation Datatype Maximum Occurrence Comment Class Relation to other terms Version Status …... For each term DC2001, Tokyo

13. Browse all terms elements element refinements encoding schemes controlled vocabularies Search string to match terms string within description, definition or comment Display full summary Phase 1 requirements DC2001, Tokyo

14. Multilingual Manage translations of definitions Translate user interface Why? Currently DC term definitions have several languages in translation Need to manage translations To promote their use Phase 1 additional requirements DC2001, Tokyo

15. Choice of display mode • Provide simple interface replacing RDFS jargon with more accessible terms • Retain choice of RDFS style interface too • Ensure ‘DCMI grammar’ is reflected in simple interface e.g. • use ‘schemes’ instead of ‘sub-classes’ • use ‘elements’ instead of ‘properies’ • use ‘element refinements’ instead of ‘sub-properties’ DC2001, Tokyo

16. Prototype 1 Based on EOR software Full indexing Toolkit RDF model pervasive in software ‘Heavyweight’ Prototype 2 Based on ‘parser’ approach Shallow functionality ‘Lightweight’ Details of prototypes DC2001, Tokyo

17. Issues • Use of RDFS reveals tension • standard schema language contributes to interoperability • building block for semantic web • but immature technology, bits missing • Need for clarity of expression within schema(s) • structure and relations between terms • level of detail in schemas DC2001, Tokyo

18. Phase 2 requirements Suggestions…. • Include application profiles • raises issues of scope, what profiles are in scope? How to deal with non-DCMI terms? • Facilitate approval process • proposed, recommended, under review • enable proposers to submit terms for approval • Integrate information from usage guidelines • Mappings DC2001, Tokyo