In 2008, Karen started to enumerate some common design patterns. We have
provisionally concluded that a revised DCAM would need to be be based on, and
illustrated with, examples. Here -- minus the DSP angle-bracket examples -- is
the starter set of patterns. They are similar in nature to the examples that
Alistair penciled into his draft.
Can we take this as a start, or does anyone want to propose a different type of
examples (or patterns)? As Antoine has suggested, the effort of just trying it
might be less than the effort of discussing it in the abstract...
Tom
----------------------------------------------------------------------
http://dublincore.org/dcmirdataskgroup/apDesigns
Some Application Profile Design Patterns
These design patterns are based on the Dublin Core Description Set
Profile (DSP). The DSP structure is a single description set that
contains one or more descriptions, each of which contains one or more
metadata statements. Both the description and the metadata statements
can define constraints on usage.
Statement: A Simple String
The simplest metadata statement describes a property that takes a
simple string value ("literal"), with no constraints.
[... example ...]
Mandatory and Repeatable
Both description templates and statement templates can be coded as
mandatory/optional and repeatable/not repeatable. This is done
using the values "minimum" and "maximum". The most commonly used
values are:
[... example values ...]
The following code defines a property ("title") that is required
and not repeatable:
[... example ...]
Using Controlled Lists
One way to assure consistency of metadata use is to require that
values be taken from a controlled list. Controlled lists can be
short ("yes" "no" "maybe") or they can be long (such as the Library
of Congress Subject Headings, which number about 250,000).
To define a property as taking a member of a controlled list as its
value using the terms of the DC Application Profile, the controlled
list is called a "Vocabulary Encoding Scheme" and the list itself
is represented with its identifier, a URI. Use of a list can be
mandatory or optional.
This code illustrates a "subject" property that optionally can use
terms from the LC Subject Heading list.
[... example ...]
This code shows a subject property that requires the use of a term
from the LCSH list:
[... example ...]
If you have a short list that you wish to embed in the DSP you can
do that using the "LiteralOption". Each term is listed, and values
must be taken from the list:
[... example ...]
You can support multiple languages with the LiteralOption by
including the XML "lang" attribute:
[... example ...]
--
Tom Baker <[log in to unmask]>
|