Second draft, 2002-05-19

Pete Johnston, UKOLN

Summary

• The registry will provide access to information on:
  • namespaces/element sets;
  • the elements/terms in those namespaces/element sets;
  • application profiles,
  • term usages which make up those application profiles,
  • encoding schemes,
  • values within those encoding schemes,
  • the agencies who own/create/maintain these resources.
• The information about these resources is (or will be) stored in machine-processable form as schemas, which may be distributed on the Web. 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 - though it may be necessary to supplement that vocabulary to record the attributes of these resources required for the registry.
• The registry should include tools to 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 the 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 registry is not a "closed system". The owners of schemas may wish to make them available to other applications independently of the registry, and the registry should support this.
• The registry should read/gather this distributed information and provide an interface to this aggregated information which permits a human reader to browse and search it, and to navigate relationships between instances. That interface should make careful use of labelling/naming (for example in the representation of property names) so that the descriptions are presented to the reader in a style which is understandable without knowledge of the RDF/XML representation.
• 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 user browsing this information can see by whom assertions were made, and when.

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

• 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

2. Scope/content of the MEG Registry system

The registry will provide access to information on [3]

• namespaces/element sets (i.e. on the namespaces/element sets as units, rather than on their constituent terms), including information on their intended scope/area of use and their relationship to other namespaces/element sets;
• the elements/terms which make up those namespaces/element sets, including information on the semantics of the terms and their recommended usage, and any semantic relationships to other terms 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 namespaces/element sets and application profiles;
• the usages of terms which make up those application profiles, including the element/term used, any prescription of encoding schemes, and other constraints on element use;
• encoding schemes, which constrain the value space of terms, including information on their intended scope/area of use;
• where an encoding scheme takes the form of an enumerated list, the 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);
• the agencies who own/create/maintain namespaces/element sets, application profiles, and encoding schemes

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:

• 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.
• A 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.

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:

• 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

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

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:

• Standards creators publishing "standard" element sets
• Implementers publishing application profiles
• Developers studying tools to support schema usage

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 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:

• introduce constraints on the value of an Element/Term by associating the it with one or more Encoding Schemes,
• introduce constraints on the obligation to use an Element/Term (e.g. make its use mandatory) or the occurrence of an Element/Term (e.g. whether it is repeatable),
• refine the semantic definition of an Element/Term 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/

4.1 Agency attributes/properties

Label	Property name	Comments
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

Label	Property name	Comments
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

Label	Property name	Comments
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

Label	Property name	Comments
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.

Label	Property name	Comments
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

Label	Property name	Comments
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

Label	Property name	Comments
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:

• Agency
• Namespace/Element Set
• Element/Term
• Encoding Scheme
• Application Profile
• Term Usage

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:

• Identifier, Name of Agency, Agency URL (hyperlink)

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:

• Identifier, Name of Agency, Agency URL (hyperlink)

In addition,

• a table/list of summary descriptions of Namespace/Element Sets owned/managed by this agency, sorted by name;
• a table/list of summary descriptions of Application Profiles owned/managed by this agency, sorted by name;
• a table/list of summary descriptions of Encoding Schemes owned/managed by this agency, sorted by name.

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:

• Identifier, Name of Namespace/Element Set, Version, Agency (hyperlink)

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:

• Identifier, Name of Namespace/Element Set, Version, Creation date, Status, Description, Agency (hyperlink), Namespace name/URI, Namespace prefix, Specification (hyperlink)

In addition,

• a table/list of summary descriptions of Element/Terms in this Namespace/Element Set, sorted by name;

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:

• Identifier, Name of Element/Term, Namespace/Element Set (hyperlink)

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:

• Identifier, Name of Element/Term, Definition, Comment, Data type. Obligation, Maximum occurrence, Refines (hyperlink), Namespace/Element Set (hyperlink)

In addition,

• a table/list of summary descriptions of element refinements of this Element/Term;
• a table/list of summary descriptions of Encoding Schemes associated with this Element/Term (in its description in the Namespace/Element Set, not in descriptions of Term Usages in Application Profiles);
• a table/list of summary descriptions of Term Usages of this Element/Term in Application Profiles

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:

• Identifier, Name of Encoding Scheme, Agency (hyperlink)

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:

• Identifier, Name of Encoding Scheme, Version, Creation date, Status, Description, Agency (hyperlink), Specification (hyperlink)

In addition,

• a table/list of descriptions of Values in this Encoding Scheme, sorted by Value and including Identifier, Value, Label, Definition;
• a table/list of summary descriptions of Elements/Terms associated with this Encoding Scheme, sorted by name of Element/Term;
• a table/list of summary descriptions of Term Usages which reference this Encoding Scheme, sorted by name of Element/Term;

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:

• Identifier, Name of Application Profile, Version, Agency (hyperlink)

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:

• Identifier, Name of Application Profile, Version, Creation date, Status, Description, Agency (hyperlink), URL of XML Schema (hyperlink), Specification (hyperlink)

In addition,

• a table/list of summary descriptions of Term Usages in this Application Profile, sorted by name of Element/Term;

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:

• Identifier, Name of Element/Term, Application Profile (hyperlink)

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:

• Identifier, Name of Element/Term, Used Element/Term (hyperlink), Definition, Comment, Data type. Obligation, Maximum occurrence, Application Profile (hyperlink)

In addition,

• a table/list of summary descriptions of Encoding Schemes associated with this Term Usage (N.B. only the Encoding Schemes explicitly associated with this Term Usage)

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:

• Search for Agencies, by keyword in name, description
• Search for Namespace/Element Sets, by keyword in name, description, classification, agency
• Search for Encoding Schemes, by keyword in name, description, classification, agency
• Search for Application Profiles, by keyword in name, description, classification, agency

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

• 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 Namespace/Element Set description

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

Edit/Update Namespace/Element Set description

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

Remove Namespace/Element Set description

• Open existing description of Namespace/Element Set
• Remove existing description of Element/Terms in Namespace/Element Set, remove existing description of Namespace/Element Set (Do not permit removal if any Element/Term used in relationships, or if Namespace/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 Term Usage in Application Profile, create description of Term Usage. Note: a Term Usage does not automatically inherit the Encoding Schemes associated with the used Element/Term. Any relevant Encoding Schemes must be explicitly associated with the Term 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 Term Usage to be amended, open existing description of Term Usage, amend description of Term Usage
• For each Term Usage to be added, create description of Term Usage
• For each Term Usage to be removed, remove description of Term 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 Term Usages in Application Profile, remove existing description of Application Profile (OK because no references)

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/