General Notes for the Practical Exercises

1. Schemas

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

a structured representation that defines and identifies 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 MEG 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, you could maintain them using a text editor (though it may be a rather laborious process!); or you could store the content 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, or metadata records describing, other resources - instances of the types listed in the registry "data model" (Elements, Element Sets, Element Usages, Application Profiles, Encoding Schemes and Controlled Values) - and the relationships between those resources.

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

When you are using the MEG 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 descriptions of all the resources that are visible as nodes are saved as the contents of a single Schema.

From the point of view of the registry, you could manage descriptions of multiple Element Sets and Application Profiles within a single Schema (i.e. a single XML document), or you could create separate Schemas for each Element Set and Application Profile (i.e. one XML document per Element Set and Application Profile.

2. 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 MEG 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, so that 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.

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 such resources, even though the resources themselves are not Web-retrievable. 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.