1. Objectives

The practical sessions are intended to allow you:

• to explore the Application Profile "model" on which the registry is based;
• to apply this model to some "real world" examples of Application Profiles;
• to become familiar with the CORES registry and the CORES schema creation tool;
• to use the CORES schema creation tool to create descriptions of Application Profiles;
• to assess the usefulness of the model;
• to evaluate the usefulness of the registry and the schema creation tool

2. Examples of Application Profiles

Four examples of Application Profiles are suggested for analysis and use in the exercises during the workshop:

• The Dublin Core Libraries Working Group Application Profile for the description of bibliographical resources
  http://dublincore.org/documents/library-application-profile/
• The Dspace Application Profile
  http://dspace.org/technology/metadata.html
• The GEM Application Profile for the description of educational materials
  http://www.geminfo.org/Workbench/gem2.html
• The Application Profile proposed by the Dublin Core Usage Board for the description of DCMI terms

However, please treat these as suggestions only. If you have specific Application Profiles with which you are familiar and which you wish to test against the registry model - or indeed if you wish to submit invented or experimental examples just to explore the model and the tools, please go ahead.

3. Schemas

In the context of the registry, the term Schema is used to refer to

a structured representation that identifies and describes one or more Elements, Element Sets, Element Usages, Application Profiles, Encoding Schemes and Controlled Values.

In the sense that it is used here, a Schema is a digital object. It can be placed on a file server and made available by a suitable file retrieval protocol.

Schemas may take many different forms: the Schemas used by the registry are XML documents which use the syntactic conventions of RDF/XML. Using the CORES Client application you can create and edit these Schemas.

Since an XML document is a plain text file, and both the RDF/XML syntax specification and the descriptions of the vocabularies used in these Schemas are publicly available, you could also create and edit these schemas using other tools. As we shall see in the exercises, it would be possible to maintain them using a text editor (though it would be a rather laborious process!). If you are managing large numbers of complex descriptions you could store the content of your descriptions in some form of "content management system" (e.g. a simple relational database) and expose or export that content in the form of XML documents as required.

The Schemas contain descriptions of resources of the types listed in the registry "data model" (Elements, Element Sets, Element Usages, Application Profiles, Encoding Schemes and Controlled Values) - including descriptions of the relationships between those resources.

These resources are "abstract" resources, not digital objects: an Element itself is not a Web-retrievable resources. The metadata stored, indexed and displayed by the registry is metadata about these "abstract" resources, not metadata about the Schemas themselves.

When you are using the CORES Client, each main document window corresponds to a Schema. As you create descriptions of resources (Element Sets, Elements etc), you will see nodes being added in the viewer boxes in the centre of the window. The Client is building up an RDF graph in memory, and the File--Save function generates an XML "serialization" of that graph. i.e. the descriptions of all the resources that are visible as nodes are saved as the contents of a single Schema.

You can manage descriptions of multiple Element Sets and Application Profiles within a single Schema (i.e. a single XML document), or you can create separate Schemas for each Element Set and Application Profile (i.e. one XML document per Element Set and Application Profile). You could even store descriptions of Elements in the same Element Set in separate Schemas. How the data is physically partitioned across Schemas is unimportant to the registry software.

4. A note on resource identifiers

All the resources described for the registry must have unique identifiers associated with them, and those identifiers take the form of Uniform Resource Identifiers (URIs).

Some of the resources for which you (or other registry contributors) are creating descriptions may already have URIs assigned to them. Some organisations responsible for "standard" metadata Element Sets have assigned and published URIs for the Elements within those Element Sets. So for example, the DCMI has published URIs for the various "terms" in the Dublin Core Metadata Element Set.

Many of the resources described in the context of the registry have not (at least not yet!) been formally assigned URIs elsewhere. Such resources will be assigned URIs for use within the registry.

As we shall see, the CORES Client application generates identifiers for most resources as you create descriptions for them. But the application always allows you the option of overriding the generated identifier: if you know that a URI has already been provided for a particular resource, you can use that URI in place of the suggested one.

N.B. The authentication requirements of the registry server mean that, in the context of the workshop, for certain resources, you will need to utilise some predefined URIs. The exercises will note where this is the case.

As noted above, none of the resources you are describing for the registry are Web-retrievable resources: Element Sets, Elements, Application Profiles etc. are "abstract" resources, not digital objects. Schemas - machine-readable representations of descriptions of these other resources - are digital objects and are (potentially at least) Web-retrievable. In the current version of the registry, metadata about the Schemas themselves is not provided.

However, it has become common practice to employ URIs which use the http: scheme as identifiers for resources that are not Web-retrievable. By basing their URIs on a Web domain name that they own, the owners of these abstract resources can have some expectation that the URIs are unique and persistent.

The use of such an identifier does not imply that you should expect to obtain a digital object if you attempt to "de-reference" that URI e.g. by issuing an HTTP GET on typing it in the address box of a Web browser. The URI is serving only as an identifier for the resource, not as a locator. It may be the case that you do obtain a digital object but there is no requirement that this is the case.