UK Office for Library and Information Networking (UKOLN) logo Metadata for Education Group (MEG) logo

Functional Requirements for MEG Registry



Second draft, 2002-05-19

Pete Johnston, UKOLN

Summary

1. Purpose of the MEG Registry system

The Metadata for Education Group (MEG) offers an open forum for debating the description and provision of educational resources at all levels across the UK. The educational community have adopted or developed a number of metadata element sets or vocabularies for the description of such resources. The descriptions or definitions of these element sets are made available in machine-processable form as schemas. [1] The purpose of the registry is to provide a publication environment in which the developers and implementers of education-related metadata schemas can disclose information on schemas and on their use.

The registry is more than a "dictionary" of the terms 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. [2]

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

Users of the registry might include:

2. Scope/content of the MEG Registry system

The registry will provide access to information on [3]

This information is stored and made available in machine-processable form as schemas. The W3C Resource Description Framework (RDF) recommendation provides a general data model for expressing statements about resources, and an associated XML syntax for serialising descriptions constructed using the model. 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 MEG registry prototype is the absence of an interface to allow the owners/maintainers of schemas to manage the relevant entries within the registry. The proposed registry should allow for this information to be created and managed in a distributed form, so that its owners/maintainers can control the content which is indexed by the registry.

The registry is not a "closed" system. The owners of some of the element sets in use by this community have already made them available on the Web in a standard machine-processable form; the registry should reuse those schemas where possible. In other cases, the owners of element sets will need to create schemas for their namespace/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 MEG registry - for reuse by other applications, which may include other metadata schema registries.

3. Structure and use of the MEG Registry system

The primary user community for the registry system is the membership of the Metadata for Education Group, and the broader community working with metadata schemas for the description of educational resources. This document has been drafted with the interests of those communities in mind. However, it is hoped that these tools will be of interest to a larger community of schema researchers, developers and implementers, and it would be valuable if, during development, consideration could be given to the potential for the reuse and re-purposing of the tools by this broader community.

The registry system has been separated into two components:

Clearly the schema creation/registration tool will need to exchange data with the registry to perform these functions. If those 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 for their interoperability with other tools developed independently.

The registry

Users of the registry will include:

The registry should:

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 may update their schemas using the schema creation and registration tool, or they may do so using their own maintenance procedures which result in the output of an RDF/XML instance accessible on the Web which can then be submitted to the registry.

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". This move to a devolved model also introduces the question of establishing and assessing levels of "trust" in the information content presented by the registry. 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. [At what level of "granularity"? Probably the schema?]

The schemas contain descriptions of instances of various classes of resource (namespace/element sets, elements/terms, term 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. Further details of the requirements for the user interface are provided in sections 5 and 6.

The schema creation and registration tool

Users of the schema creation/registration tool will include:

The schema creation/registration tool should allow a human user

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 MEG 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 "namespace/element set" as a table of "elements/terms" may 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" terms from existing namespaces/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 Namespace/Element set

A UK organisation 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 MEG community via the registry.

To publish requires the following steps. The Namespace/Element set publisher:

  1. Uses the Schema Creation and Registration Tool (SCART) to add Agency description (if not already present) (see below).
  2. Submits new Agency description to registry
  3. Uses SCART to add Namespace/Element Set description (see below).
  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 (see below).
  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 (see below).

Use Case 2: Publishing a description of an Application Profile

A UK organisation 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 Element/Terms drawn from the cross-domain element sets of the Dublin Core Metadata Initiative; a domain-specific Element/Term which was created by another portal service for their own schema; and a number of new terms specific to this service. The organisation has developed a number of controlled vocabularies for several of the Element/Terms 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 SCART to add Agency description (if not already present) (see below).
  2. Submits new Agency description to registry
  3. Uses SCART to add Encoding Scheme descriptions for their controlled vocabularies (see below).
  4. Depending on size of controlled vocabularies, may use SCART to add Value descriptions
  5. Submits new Encoding Scheme and Value descriptions to registry
  6. May check results by browsing Encoding Scheme descriptions via registry Web interface (see below).
  7. Uses SCART to add Namespace/Element Set description for local Namespace/Element Set (see below).
  8. Uses SCART to add Element/Term descriptions for Element/Terms in local Namespace/Element Set, including association of Element/Term with Encoding Scheme(s) where appropriate (see below).
  9. Submits new Namespace/Element Set and Element/Term descriptions to registry
  10. May check results by browsing Namespace/Element Set descriptions via registry Web interface (see below).
  11. Uses SCART to add Application Profile description (see below).
  12. Uses SCART to add Term Usage descriptions, drawing on Element/Term descriptions for DC elements, for Namespace/Element Set created by other portal, and for their own newly added Namespace/Element Set. May specify new "usage-specific" associations between Element/Term and Encoding Scheme(s) as part of this process (see below).
  13. Submits new Application Profile and Term Usage descriptions to registry
  14. May check results by browsing Application Profile descriptions via registry Web interface (see below).

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

An international standards body makes schema for their cross-domain element set available in RDF/XML on their Web server. Various MEG members wish to "use" Element/Terms from the Namespace/Element Set in their Application Profiles.

Either the representative of standards body or the registry administrator:

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

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 Element/Terms via registry Web interface (see below).
  2. Displays description of Element/Term "dcterms:audience", which includes pointers to the Encoding Schemes associated with the Element/Term, and pointers to its usage by various Application Profiles
  3. Follows references to Term Usage descriptions, which included descriptions of how implementers have constrained the use of the Element/Term, including the prescription of other Encoding Schemes

4. The registry 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 Desire registry [4] and also draws on the work of the Schemas project in exploring approaches based on RDF Schema [5]. In particular, it adopts the recommendation of Baker et al that "Term Usages" should be modeled as resources in their own right. [6]

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

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

Registry model

4.1 Agency attributes/properties

LabelProperty nameComments 
Identifier (rdf:about)
Name of Agency reg:agencyName The name or title of the Agency
Agency URL?
Agency home page?
reg:agencyHomepage The URL of a document which provides more information about the Agency, typically an organisational "home page".

4.2 Namespace/Element Set attributes/properties

LabelProperty nameComments 
Identifier (rdf:about)
Name of Namespace/Element Set dc:title The name or title of the Namespace/Element Set
Version reg:version The version of the Namespace/Element Set.
Creation date dcterms:created Date this version created
Status reg:status Status of Namespace/Element Set.
Description dc:description Description of Namespace/Element Set, including any notes of scope/purpose.
Classification reg:classification Classification of use of this Namespace/Element Set
Responsible Agency reg:responsibleAgency Publisher of Namespace/Element Set Pointer to resource of type Agency
Namespace name/URI reg:xmlNamespace XML Namespace name/URI associated with this Namespace/Element Set
??Namespace prefix reg:xmlNamespacePrefix ??Prefix to be used in instances using this Namespace/Element Set
Specification reg:specification URL of prose description of/guidelines for use of Namespace/Element Set

Format? Type? Language?

4.3 Element/Term attributes/properties

LabelProperty nameComments 
Identifier (rdf:about)
Name of Element/Term rdfs:label A human-readable version of the property name
Definition rdfs:comment A statement that clearly represents the concept and essential nature of the Element/Term
Comment reg:useComment A remark concerning the application/use of the data element
Data type reg:datatype Indicates the type of data that can be represented in the value of the data element
Obligation reg:obligation Indicates whether the Element/Term is always or sometimes required to be present
Maximum occurrence reg:maximumOccurrence Indicates any limit to the repeatability of the Element/Term
Associated Encoding Scheme reg:associatedEncodingScheme An Encoding Scheme which specifies constraints on the value of this Element/Term Repeatable. Pointer to resource of type Encoding Scheme
Refines rdfs:subPropertyOf An Element/Term of which this Element/Term is a "refinement" [DC] Pointer to resource of type rdf:Property
Namespace/Element Set reg:isElementOf An Namespace/Element Set of which this Element/Term is part Pointer to resource of type Namespace/Element Set

4.4 Encoding Scheme attributes/properties

LabelProperty nameComments 
Identifier (rdf:about)
Name of Encoding Scheme rdfs:label The name or title of the Encoding Scheme
Version reg:version The version of the Encoding Scheme.
Creation date dcterms:created Date this version created
Status reg:status Status of Encoding Scheme.
Description rdfs:comment Description of Encoding Scheme, including any notes of scope/purpose.
Classification reg:classification Classification of use of this Encoding Scheme
Responsible Agency reg:responsibleAgency Publisher of Encoding Scheme Pointer to resource of type Agency
Specification reg:specification URL of prose description of/guidelines for use of Encoding Scheme

4.5 Value attributes/properties

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

LabelProperty nameComments 
Identifier  
Value rdf:value The value of a term in an Encoding Scheme
Label rdfs:label The human-readable form of the value of a term in an Encoding Scheme
Description rdfs:comment Description
Encoding Scheme rdf:type An Encoding Scheme of which this value is part. Pointer to resource of type Encoding Scheme.

4.6 Application Profile attributes/properties

LabelProperty nameComments 
Identifier (rdf:about)
Name of Application Profile dc:title The name or title of the Application Profile
Version reg:version The version of the Application Profile.
Creation date dcterms:created Date this version created
Status reg:status Status of Application Profile.
Description dc:description Description of Application Profile, including any notes of scope/purpose.
Classification reg:classification Classification of use of this Application Profile
Responsible Agency reg:responsibleAgency Publisher of Application Profile Pointer to resource of type Agency
URL of XML Schema reg:associatedXMLSchema XML Schema associated with this Application Profile
Specification reg:specification URL of prose description of/guidelines for use of Application Profile

Format? Type? Language?

4.7 Term Usage attributes/properties

LabelProperty nameComments 
Identifier (rdf:about)
Uses reg:uses An Element/Term which is used in the context of this Application Profile. Pointer to resource of type rdf:Property
Name of Term Usage rdfs:label A human-readable version of the property name, when used in the context of this Application Profile.
Definition rdfs:comment A statement that clearly represents the concept and essential nature of the Element/Term, as used in this Application Profile.
Comment reg:useComment A remark concerning the application/use of the Element/Term, when used in the context of this Application Profile.
Data type reg:datatype Indicates the type of data that can be represented in the value of the Element/Term, when used in the context of this Application Profile.
Obligation reg:obligation Indicates whether the Element/Term is always or sometimes required to be present, when used in the context of this Application Profile.
Maximum occurrence reg:maximumOccurrence Indicates any limit to the repeatability of the Element/Term, when used in the context of this Application Profile.
Associated Encoding Scheme reg:associatedEncodingScheme An Encoding Scheme which specifies constraints on the value of this Element/Term Repeatable. Pointer to resource of type Encoding Scheme
Application Profile reg:isUsageIn An Application Profile of which this Term Usage is part Pointer to resource of type Application Profile

5. Browsing the MEG Registry

The user interface to the registry should allow a user to browse lists of instances of the principal resource classes:

There is no requirement to browse Values within Encoding Schemes.

Browse Agencies by name

A table/list of summary descriptions of all agencies, sorted by name. Each entry should display the properties:

From any entry the user should be able to navigate to a detailed description for the agency.

Display Agency description

A full display of the properties of the Agency:

In addition,

From any entry the user should be able to navigate to a detailed description for the Namespace/Element Set, Application Profile or Encoding Scheme.

Browse Namespace/Element Sets by name

A table/list of summary descriptions of all Namespace/Element Sets, sorted by name. Each entry should display the properties:

From any entry the user should be able to navigate to a detailed description for the Namespace/Element Set.

Display Namespace/Element Set description

A full display of the properties of the Namespace/Element Set:

In addition,

From any entry the user should be able to navigate to a detailed description for the Element/Term.

Browse Element/Terms by name

A table/list of summary descriptions of all Elements/Terms, sorted by name. Each entry should display the properties:

From any entry the user should be able to navigate to a detailed description for the Element/Term.

Display Element/Term description

A full display of the properties of the Element/Term:

In addition,

From any entry the user should be able to navigate to a detailed description for the element refinement (an Element/Term), Encoding Scheme, or Term Usage.

Browse Encoding Schemes by name

A table/list of summary descriptions of all Encoding Schemes, sorted by name. Each entry should display the properties:

From any entry the user should be able to navigate to a detailed description for the Encoding Scheme.

Display Encoding Scheme description

A full display of the properties of the Encoding Scheme:

In addition,

From any entry in the latter two tables, the user should be able to navigate to a detailed description for the Element/Term or Term Usage.

Browse Application Profiles by name

A table/list of summary descriptions of all Application Profiles, sorted by name. Each entry should display the properties:

From any entry the user should be able to navigate to a detailed description for the Application Profile.

Display Application Profile description

A full display of the properties of the Application Profile:

In addition,

From any entry the user should be able to navigate to a detailed description for the Term Usage.

Browse Term Usages by name of Element/Term

A table/list of summary descriptions of all Term Usages, sorted by name of Element/Term. Each entry should display the properties:

From any entry the user should be able to navigate to a detailed description for the Term Usage.

Display Term Usage description

A full display of the properties of the Term Usage:

In addition,

From any entry the user should be able to navigate to a detailed description for the Encoding Scheme.

6. Searching the MEG registry

The user interface to the registry should allow a user to search descriptions of instances of the principal resource classes. Suggested searches are:

Result sets should be returned as summary lists as described in the browse operations above.

7. Creating and editing schemas using the SCART

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

[Are there questions of integrity here? What happens if I remove an Element/Term from my Namespace/Element Set and others have reused that Element/Term in their Application Profiles? Permit and allow references to break or prevent?]

Add Agency description

Edit/Update Agency description

Remove Agency description

Add Namespace/Element Set description

Edit/Update Namespace/Element Set description

Remove Namespace/Element Set description

Add Encoding Scheme description

Edit/Update Encoding Scheme description

Remove Encoding Scheme description

Add Application Profile description

Edit/Update Application Profile description

Remove Application Profile description

Notes & references

[1] The SCHEMAS Forum : A Retrospective Glossary
HTML: http://www.schemas-forum.org/info-services/d74.htm

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

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

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

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

[6] 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/