By Thomas Baker
Submitted to the DC Registry Working Group, Oct 19 2000
The paper that follows articulates 'first-step' requirements for publishing
project- and domain-specific adaptations of metadata standards ('application
profiles') in a registry of the European SCHEMAS Project. Please see the previous
message for further context. Comments to email@example.com
for Publishing Application Profiles in the SCHEMAS Project Registry
The SCHEMAS Project defines itself as a 'forum for metadata schema implementors'
. Its mission is primarily didactic -- to help project implementors understand
the overall landscape of metadata standards and metadata-using applications.
It aims at promoting good-practice methods for drawing on or adapting those
standards, as needed, in the design of their own project- or domain-specific
schemas. By registering application profiles, therefore, the SCHEMAS Project
wants to help project managers and other implementors discover existing projects
in a particular sector or domain and see how those projects are using standards
in their metadata. The ultimate goal of these activities is the harmonization
of good practice in the use of metadata.
'Vocabulary terms' (or simply 'terms') are elements, qualifiers, or any other
type of word-like entity declared in a namespace or application profile.
the names and definitions ('semantics') of vocabulary terms -- ideally on the
Web and in a way that is both human- and machine-understandable. The archetypal
example is an RDF schema holding the official names and definitions of the Dublin
Core Metadata Element Set at the official Web site of the Dublin Core Metadata
Initiative. Individual projects, however, can also set up namespaces to declare
the names and definitions of elements they have coined locally.
(or simply 'profiles') declare which elements from which namespaces a particular
application or project underlie the local project schema used for its metadata
-- in other words, it 'reuses' semantics from namespaces and repackages them
for a particular purpose. Ideally, they are also machine-understandable and
An application profile should be able (in order of decreasing importance):
1) to declare which elements from which namespaces an application or application
community is using in its project- or domain-specific schema.
2) to override the default (i.e., standard) definition or label of a particular
element (from the namespace) with a definition or label that makes sense in
the local context. For example, a profile for an application for describing
collections might redefine the Dublin Core element Title -- officially, 'A name
given to the resource' -- with a more restricted local definition: 'A name given
to the collection'.
3) to describe the project or application to which it refers. At a minimum,
this description should give the name and mission of a project or application.
Ideally, it would provide further technical detail about the application environment
in which the schema is used.
4) to specify dependencies among vocabulary terms -- for example (in profiles
that use Dublin Core), that particular encoding schemes may be used with particular
5) to define multiple entity classes in a particular data model. For example,
a given application may need to describe both 'people' (with attributes like
name, occupation, and weight) and 'resources' (with attributes like title, subject,
6) to provide guidelines, in free text, about the local use of particular terms.
7) to express controlled vocabularies in a machine-understandable way. For example,
if the values of the term 'Economic Sector' are restricted to just 'Agriculture',
'Industry', or 'Services', the profile should be able to declare this.
In addition to simply discovering which terms are being used by whom, it could
be useful for profiles to describe, in more detail and in machine-understandable
ways, exactly how metadata semantics are used in a particular application. For
example, profiles could potentially be used by software for automatically validating
the conformance of metadata records. To use an old distinction from the world
of markup languages, profiles could be not just 'descriptive' of intellectual
content (like SGML), but also provide information that is more 'procedural'
(like layout or font tags in HTML). Such profiles could therefore:
1) specify in a standard machine-understandable way that an element is mandatory,
optional, or repeatable.
2) specify whether a particular field in the instance metadata records can be
Mr Baker has also
written an interesting article entitled 'A Grammar for Dublin Core'
for D-Lib Magazine:
Dr. Thomas Baker
GMD Library Schloss Birlinghoven
Sankt Augustin, Germany