Functional Requirements for CORES Schema Creation and RegistrationTool Final version, 2002-11-04 Rachel Heery, UKOLN

Background

The ambition of the CORES project is to build consensus on a shared data model for the declaration of element sets and application profiles. Such a shared data model would facilitate the re-use of existing schemas by other services, projects and initiatives. In order to further this ambition, CORES is implementing a schema creation tool which will work interactively with a complementary schema registry. Both will be based on the same data model to enable implementors to create schemas, register the schemas, then make them available for re-use by other implementors.

Development of the CORES schema creation tool and registry build on work carried out within the UK MEG Registry project [1]. CORES builds on the data model and functional requirements [2] developed in that project, and enhances the existing software in order to provide an appropriate tool for use by a range of schema implementors. In addition CORES will explore the use of annotations within the Registry to convey information about the deployment and use of element sets and application profiles. Previously, within the SCHEMAS [3] prototype registry, such information had been structured in a more formal manner as activity reports submitted by experts to a central administrator for input to the Registry.

The CORES project will implement a de-centralised, distributed mode whereby more informal comments can be added by authenticated users as 'annotations' to the Registry.

CORES is collaborating closely with the MEG Registry work in the UK and the DCMI Registry work [4] which is being undertaken as part of the international Dublin Core Metadata Initiative. In addition CORES partners have been involved in discussion with the W3C Semantic Web activity [5] regarding the use of RDF Vocabulary Description Language [6] to express schemas. Both the CORES and the MEG Registries build on previous activity within the DESIRE and SCHEMAS projects which established data models for declaring schemas and local usage within a schema registry, and implemented prototype registries[7] [8] [9].

Summary of Requirements

The primary purpose of the schema creation tool is to provide the means for non-experts to declare their schemas according to the RDF schema specification. The schema creation tool must enable a structured RDF schema to be produced identifying and defining:

• Element Sets;
• the Elements in those Element Sets;
• Application Profiles;
• Element Usages which make up those Application Profiles;
• Encoding Schemes;
• Values within those Encoding Schemes;
• the Agencies who own/create/maintain these resources
• Commentaries (contextual annotations) outlining deployment of the Element Sets, Application Profiles, and Schemes
• links to User Guidelines for the Element Sets, Application profiles or Schemes

The schema creation tool must be suitable for use by non-experts to enter information about these entities.The schema creation tool should allow the owners of this information to create and maintain schemas in a convenient way. These tools should allow the user to focus on the structure and semantics of the descriptions they create and manage and should insulate them from, for example, details of the XML syntax of the schemas. A generic "node and arcs" representation may not be the most useful "view" for the users of this tool, and consideration should be given to presenting table-/text- based views which may be more familiar to this constituency.

The information must be output in a form suitable for registration in the CORES registry, though it may be necessary to supplement the information input by the schema creator in order to record attributes of these resources required for the registry.

The information about these resources must also be stored locally to the schema creation tool in machine-processable form as RDF schemas, which may be distributed on the Web. The owners of schemas may wish to make them available to other applications independently of the SCHEMAS registry, and the tool should support this. The W3C Resource Description Framework (RDF) recommendation provides a general data model for expressing this information, and conventions for representing those descriptions in XML. RDF Schema defines a basic vocabulary which can be used to describe these types of resource.

Devolving the management of this information introduces questions of how to establish "trust" in the information content presented by the registry. Sufficient "administrative metadata" should be recorded and made available so that a registry might ensure it can record by whom assertions were made, and when.

Purpose of the CORES Registry system

The variety of new and emerging Web based services and initiatives have adopted or developed a number of different metadata Element Sets or vocabularies for the description of the resources on which their services are based. CORES intends to encourage sharing of metadata semantics, and will provide a metadata schema registry [10] to facilitate the 'publication' of metadata schemas. Such a registry is intended to help implementors of information projects and services find out about metadata terms in use (both official definitions and local variations) to encourage harmonisation of metadata usage within particular fields and applications.

In order to facilitate building such a registry the descriptions and definitions of these Element Sets need to be made available in machine-processable form as Schemas. The purpose of the schema creation tool is to enable implementors to 'publish' their schemas so that they can be registered, either in the CORES registry or elsewhere. Additionally the schemas may be used in other applications, either locally or remotely. The registry provides a publication environment in which the developers and implementers of education-related metadata schemas can disclose information on schemas and on their use.

The CORES registry is more than a "dictionary" of the Elements described by schemas: fundamental to the registry is the recognition that implementers deploy and adapt "standard" Element Sets in a pragmatic way. While "standard" schemas are widely available, these use-oriented adaptations, which are often localised and service-specific, tend to be less visible. Researchers on schema usage have introduced the idea of the "Application Profile" as a means of capturing this information on adaptations and constraints of Element Set usage. [11]

Such differentiation in the use of schemas brings a cost in terms of interoperability between systems that deploy them, and unnecessary variation should be avoided where possible. Making such variation visible by means of a schema registry

• contributes to the goal of enhancing interoperability between systems which use these schemas,
• reduces confusion for implementers, and
• may help avoid costly duplication of effort by promoting the reuse of existing solutions.

Users of the registry might include:

• Standards creators publishing "standard" Element Sets
• Implementers publishing Application Profiles
• Implementers/developers seeking appropriate Element Sets/Application Profiles
• Metadata instance creators seeking guidance on use of Element Sets and Application Profiles
• Researchers studying schema usage
• Developers studying tools to support schema usage
• Commentators on deployment of Element Sets and Application Profiles

Scope/content of the CORES Registry system

The registry will provide access to information on [12]

• Element Sets (i.e. on the Element Sets as units, rather than on their constituent Elements), including information on their intended scope/area of use and their relationship to other Element Sets;
• Elements which make up those Element Sets, including information on the semantics of the Elements and their recommended usage, and any semantic relationships to other Elements in this or other vocabularies (e.g. the relationship described by the DCMI concept of "element refinement" or by RDF Schema as a "sub-property" relation)
• Application Profiles, including information on their intended scope/area of use and their relationship to other Element Sets and Application Profiles;
• Usages of Elements which make up those Application Profiles, including the Element used, any prescription of Encoding Schemes, and other constraints on element use;
• Encoding Schemes, which constrain the value space of Elements, including information on their intended scope/area of use;
• values prescribed by that Encoding Scheme (in practice this is likely to be recorded only where that list consists of a small number (<20?) of values);
• Agencies who own/create/maintain Element Sets, Application Profiles, and Encoding Schemes
• Commentaries allowing for evaluative information to be added about Element Sets, Application Profiles, Elements and Encoding Schemes
• Guidelines for linking to usage guidelines relating to Element Sets, Application Profiles, and Encoding Schemes Application Profiles

This information is stored and made available in machine-processable form as schemas. As far as possible, the information above should be expressed using "standard" (or at least widely understood) semantic vocabularies, such as RDF Schema and the Element Sets of the DCMI. It is recognised, however, that some information used by the registry will require the use of additional vocabularies.

One of the limitations of the current SCHEMAS registry is the absence of an interface to allow the owners/maintainers of schemas to manage the relevant entries within the registry. It is not scaleable for schemas to be entered into the registry centrally, by hand. Implementors need to create schemas for their Element Sets and Application Profiles in order to submit them to the registry. It should be possible for the schema creators to store a copy of that schema, serialised in a form compatible with Web metadata standards, which they can make available - independently of the CORES registry - for reuse by other applications, which may include other metadata schema registries.

Structure and use of the CORES Schema Creation tool

The primary user community for the CORES schema creation tool are implementors of Web based systems working within EC projects, particularly in areas related to the Semantic Web activity. This document has been drafted with the interests of this community in mind. However, it is hoped that this tool will be of interest to the broader community working with metadata schemas for the description of Web resources, in particular schema researchers, developers and implementers. It would be valuable if, during development, consideration could be given to the potential for reuse of existing tools and future re-purposing of the tool by this broader community.

The CORES registry system can be separated into components:

• The registry proper, which will read schemas describing the resources listed above, store that aggregated data, and present an interface to that data which allows a human reader to browse and search it. From this point in this document, references to "the registry" are to this "central" component of the system. The registry will be hosted on a server at UKOLN. The existing SCHEMAS registry software solution, will be migrated to an RDF based Registry solution now in alpha test within the MEG project.
• The commentary tool for creating annotations within the Registry. This will be associated with an authentication mechanism to validate commentator by email address which will enable the commentator to update their annotations.
• The schema creation and registration tool, which will allow a human user to create and edit schemas, and to submit/re-submit them to the registry. It is expected that the tool will be used on PCs, probably mainly in a Windows environment, but it would be highly desirable to ensure that this tool is portable to other environments.

The schema creation/registration tool will need to exchange data with the registry to perform these functions. If the interfaces to the registry can be created in standardised forms and supporting documentation provided, that would enhance the possibility for the reuse of these tools and facilitate interoperability with other tools developed independently.

The commentary tool will be integrated within the Registry.

The registry

Users of the CORES registry will include

• Standards creators publishing "standard" Element Sets
• Implementers publishing Application Profiles
• Implementers/developers seeking appropriate Element Sets/Application Profiles
• Metadata instance creators seeking guidance on use of Element Sets and Application Profiles
• Researchers studying schema usage
• Commentators creating annotations associated with Element Sets, Application Profiles, Elements and Schemes

The registry should:

• read/gather schemas - machine-processable forms of descriptions of the resources listed above;
• store and index that aggregated data; present an interface to that data which allows a human reader to browse and search it and navigate the relationships between resources in a convenient fashion;
• provide interfaces which permit the schema creation and registration tool to request information from the registry and to submit new information to the registry enable creation of annotations provide means to browse annotations

The "source" schemas may be distributed at various locations on the Web, and the registry must provide support for re-reading and re-indexing any of those descriptions as they are updated by their owners. Those owners will update their schemas using the schema creation and registration tool.

This devolved model may require some form of basic authentication/authorisation mechanism to ensure that the maintainers of this information can edit only those units of information in the registry which they "own". Sufficient "administrative metadata" should be recorded and made available so that a user browsing this information can see by whom assertions were made, and when, regarding element sets, application profiles, and annotations.

The schemas contain descriptions of instances of various classes of resource (Element Sets, Elements, Element Usages etc). Specific types of relationship exist between instances of these different classes of resource. The interface through which human readers of the registry access this information should make these relationships clear to the reader and should allow them to navigate those relationships, for example, via hypertext links. In displaying information about resources, the registry should apply appropriate "labels" in preference to displaying URIs of properties or resource classes.

The schema creation and registration tool

Users of the schema creation/registration tool will include:

• Standards creators publishing "standard" Element Sets
• Implementers publishing Application Profiles
• Developers studying tools to support schema usage
• Standards creators, implementers adding links to user guidelines
• Standards creators, implementers and the registry 'editor' adding commentary

The schema creation/registration tool should allow a human user

• to create and edit schemas (descriptions of the resources listed above), and
• to submit/re-submit those schemas to the registry.

The user interface to this tool should allow the user to focus on the structure and semantics of the descriptions they are managing; as far as possible, it should insulate them from the syntax of the machine-readable forms of those descriptions. As in the case of the registry interface, the "labels" of properties and classes should be displayed in preference to their URIs wherever possible. Further, many schema creators within CORES have a limited familiarity with the concepts and terminology used in association with the RDF model, and it will be important to provide interfaces which take that limitation into account. A "view" of an "Element Set" as a table of "Elementss" will be more intuitive than a graphical representation based on nodes and arcs, for example. Ideally the tool would provide the flexibility to render different views for different groups of user.

In constructing an "Application Profile", a core part of the task is to establish relationships to existing descriptions of resources within the registry e.g. a profile "uses" Elements from existing Element Sets and may associate them with existing Encoding Schemes. In such cases, the interface should allow the user to do so in a manner which is intuitive and simple to use, but which maintains the integrity of relationships between resources. e.g. the tool might present views of the appropriate resources available within the registry, from which the user can select the relevant items.

As noted above, the registry is not a closed system, and the schema creation and registration tool should permit a user to store their descriptions as RDF/XML documents so that they might be used for purposes other than submission to the registry.

Use Case 1: Publishing a description of a Element Set

An EC project provides a resource discovery service for Web-based educational materials. That service utilises a simple metadata schema developed specifically for that purpose. The organisation wishes to publish this information to the wider community via the CORES registry.

To publish requires the following steps. The Element Set publisher:

1. Uses the Schema Creation and Registration Tool (SCART) to add Agency description (if not already present)
2. Submits new Agency description to registry
3. Uses SCART to add Namespace/Element Set description
4. Uses SCART to add Element/Term descriptions for Element/Terms in Namespace/Element Set, including association of Element/Term with Encoding Scheme(s) where appropriate
5. Submits new Namespace/Element Set and Element/Term descriptions to registry
6. May check results by browsing Namespace/Element Set descriptions via registry Web interface

Use Case 2: Publishing a description of an Application Profile

An EC project provides a resource discovery service for Web-based educational materials. That service utilises a simple metadata schema developed specifically for that purpose. The schema uses a number of Elements drawn from the cross-domain Element Sets of the Dublin Core Metadata Initiative; a domain-specific Element that was created by another portal service for their own schema; and a number of new Elements specific to this service. The organisation has developed a number of controlled vocabularies for several of the Elements in this schema; the service also specifies the use of some standardised forms for dates and identifiers within metadata instances. The organisation wishes to publish this information to the MEG community via the registry.

In the terms of the registry data model, this organisation's schema is an Application Profile. To publish requires the following steps. The Application Profile publisher:

1. Uses the the CORES Schema Creation Tool to add Agency description (if not already present)
2. Submits new Agency description to registry
3. Uses SCART to add Namespace/Element Set description
4. Uses SCART to add Element/Term descriptions for Element/Terms in Namespace/Element Set, including association of Element/Term with Encoding Scheme(s) where appropriate
5. Submits new Namespace/Element Set and Element/Term descriptions to registry
6. May check results by browsing Namespace/Element Set descriptions via registry Web interface.

Use Case 3: Indexing a standard schema for a Element Set

An international standards body makes schema for their cross-domain Element Set available in RDF/XML on their Web server. European implementors wish to "use" Elements from the Element Set in their Application Profiles.

Either the representative of standards body or the registry administrator:

1. Uses the CORES Schema Creation Tool to add Agency description (if not already present) ).
2. Submits new Agency description to registry
3. Uses the CORES Schema Creation Tool to add Element Set description (assumes external schema on Web does not contain required data)
4. Requests registry to read Element descriptions from URL
5. May uses the CORES Schema Creation Tool to enhance Element descriptions for registry-specific data (or may leave incomplete)
6. Submits updated Element descriptions to registry
7. May check results by browsing Element Set descriptions via registry Web interface .

Use Case 4: Exploring Element Usage

A schema developer wishes to survey the usage of the DCMI "audience" element, and particularly the use of any controlled vocabularies to control values of this element.

The developer

1. Browses Elements via registry Web interface
2. Displays description of Element "dcterms:audience", which includes pointers to the Encoding Schemes associated with the Element, and pointers to its usage by various Application Profiles
3. Follows references to Element Usage descriptions, which included descriptions of how implementers have constrained the use of the Element, including the prescription of other Encoding Schemes

Use Case 5: Creating annotations

Schema Creator creates a schema using CORES schema creation tool and registers it in CORES Registry. They then want to annotate the schema with information about the number of implementations, domains in which this schema is deployed, and pointers to user guidelines.

The schema creator

1. Browses element sets via Registry web interface
2. Displays details of the chosen element set
3. Adds an annotation

A schema creator searches the registry and displays an element set, then is interested in whether this schema is currently being maintained. He browses each annotation associated with the schema, looking in particular at the names of the annotator and associated organisation.

1. Display details of chosen element sets
2. Display annotations

A commentator wants to annotate an element with usage notes and comments regarding a scheme outlining experience gained in using that scheme.

The CORES Schema Creation Tool data model

A graphical outline of the classes of resource described and the relationships between instances is provided below. This section outlines the attributes/properties of instances of these classes. It is based on the data model for the MEG registry [2] and also draws on the work of the SCHEMAS project [13] .In particular, it adopts the recommendation of Baker et al that "Element Usages" should be modeled as resources in their own right. [14]

An Application Profile defines a set of Element Usages of Elements drawn from one or more Element Sets. Such a Element Usage may:

• introduce constraints on the value of an Element by associating the it with one or more Encoding Schemes,
• introduce constraints on the obligation to use an Element (e.g. make its use mandatory) or the occurrence of an Element (e.g. whether it is repeatable),
• refine the semantic definition of an Element to make it narrower or more specific to the application domain.

In the tables below, the prefixes used in property names are associated with XML Namespaces as follows:

• rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns#
• rdfs: http://www.w3.org/2000/01/rdf-schema#
• dc: http://purl.org/dc/elements/1.1/
• dcterms: http://purl.org/dc/terms/
• dcmitype: http://purl.org/dc/dcmitype/
• reg: http://www.ukoln.ac.uk/metadata/education/regproj/reg/

Figure One: CORES data model

Agency attributes/properties

4.2 Element Set attributes/properties

4.3 Element attributes/properties

4.4 Encoding Scheme attributes/properties

4.5 Value attributes/properties

An Encoding Scheme is a rdfs:Class. Values are instances of resources of that Class.

4.6 Application Profile attributes/properties

4.7 Element Usage attributes/properties

4.8 Annotation attributes/properties

4.9 Commentator attributes/properties

Creating and editing schemas using the CORES schema creation tool

The tool should allow a user to create, maintain and remove resource descriptions which they own within the CORES registry.

Add Agency description

• Create description of Agency
• Save description of Agency
• Submit description of Agency to registry

Edit/Update Agency description

• Open existing description of Agency
• Amend description of Agency
• Save description of Agency
• Re-submit description of Agency to registry

Remove Agency description

• Open existing description of Agency
• Remove existing description of Agency (Do not permit removal if used in relationships?)

Add Element Set description

• Create description of Element Set
• For each Element in Element Set, create description of Element
• Save description of Element Set
• Submit description of Element Set to registry

Edit/Update Element Set description

• Open existing description of Element Set
• Amend description of Element Set
• For each Element to be amended, open existing description of Element, amend description of Element
• For each Element to be added, create description of Element
• For each Element to be removed, remove description of Element (Do not permit removal if Element used in relationships?)
• Save description of Element Set
• Re-submit description of Element Set to registry

Remove Element Set description

• Open existing description of Element Set
• Remove existing description of Elements in Element Set, remove existing description of Element Set (Do not permit removal if any Element used in relationships, or if Element Set used in relationships?)

Add Encoding Scheme description

• Create description of Encoding Scheme
• For each Value in Encoding Scheme, create description of Value
• Save description of Encoding Scheme
• Submit description of Encoding Scheme to registry

Edit/Update Encoding Scheme description

• Open existing description of Encoding Scheme
• Amend description of Encoding Scheme
• For each Value to be amended, open existing description of Value, amend description of Value
• For each Value to be added, create description of Value
• For each Value to be removed, remove description of Value
• Save description of Encoding Scheme
• Re-submit description of Encoding Scheme to registry

Remove Encoding Scheme description

• Open existing description of Encoding Scheme
• Remove existing description of Values in Encoding Scheme (OK because no references), remove existing description of Encoding Scheme (Do not permit removal if Encoding Scheme used in relationships)

Add Application Profile description

• Create description of Application Profile
• For each Element Usage in Application Profile, create description of Element Usage. Note: a Element Usage does not automatically inherit the Encoding Schemes associated with the used Element. Any relevant Encoding Schemes must be explicitly associated with the Element Usage.
• Save description of Application Profile
• Submit description of Application Profile to registry

Edit/Update Application Profile description

• Open existing description of Application Profile
• Amend description of Application Profile
• For each Element Usage to be amended, open existing description of Element Usage, amend description of Element Usage
• For each Element Usage to be added, create description of Element Usage
• For each Element Usage to be removed, remove description of Element Usage (OK because no references)
• Save description of Application Profile
• Re-submit description of application to registry

Remove Application Profile description

• Open existing description of Application Profile
• Remove existing description of Element Usages in Application Profile, remove existing description of Application Profile (OK because no references)

6. Creating and editing annotations

Add commentator description

• Prompt for details on first attempt to create annotation

Edit commentator description

• Amend description

Add annotation description

• Click on annotations button
• Enter details of annotation
• Specify whether public or private
• Specify type of annotation
• Specify whether it is public or private annotation

Edit annotation description

• Open existing annotation
• Amend text

Remove annotation description

7. Notes and references

[1] MEG Registry project.
HTML: http://www.ukoln.ac.uk/metadata/education/regproj/

[2]Johnston, Pete, Functional Requirements for MEG Registry
HTML:http://www.ukoln.ac.uk/metadata/education/regproj/funcreq/

[3] Schemas project.
HTML: http:www.schemas-forum.org

[4] DCMI Registry.
HTML: http://dublincore.org/dcregistry/

[5] W3C Semantic Web Activity Group.
HTML: http://www.w3.org/2001/sw/

[6] RDF Vocabulary Description Language 1.0: RDF Schema. W3C Working Draft 30 April 2002 (Work in Progress).
HTML: http://www.w3.org/TR/rdf-schema

[7] DESIRE Registry
HTML: http://www.desire.ukoln.ac.uk

[8] Heery, Rachel, Tracy Gardner, Michael Day & Manjula Patel, DESIRE metadata registry framework
HTML: http://www.desire.org/html/research/deliverables/D3.5/

[9] The SCHEMAS Forum Registry
HTML: http://www.schemas-forum.org/registry/

[10]For a contextual definition of 'Registry' see The SCHEMAS Forum : A Retrospective Glossary
HTML: http://www.schemas-forum.org/info-services/d74.htm

[11] Heery, Rachel & Manjula Patel, Application Profiles: mixing and matching metadata schemas Ariadne 25. Sept 2000.
HTML: http://www.ariadne.ac.uk/issue25/app-profiles/

[12] This is a subset of the information managed within the current prototype SCHEMAS registry, which uses the model developed by the DESIRE project. The model suggested here excludes support for the capacity to group Element Sets by "Namespace Concept" and for the capacity to describe "Value Components" for an Encoding Scheme. Activity reports are modelled as Annotations.

[13] The SCHEMAS Forum Registry : sample RDF encodings of Application Profiles
HTML: http://www.schemas-forum.org/registry/schemas/

[14] Baker, Thomas, Makx Dekkers, Rachel Heery, Manjula Patel and Gauri Salokhe, What terms does your metadata use? Application profiles as machine-understandable narratives, Journal of Digital Information Volume 2 Issue 2 (Nov 2001)
HTML: http://jodi.ecs.soton.ac.uk/Articles/v02/i02/Baker/

[CORES] | [SCHEMAS] | [MEG]

Web page by Rachel Heery of UKOLN.