Dublin Core Data Model Working Group Decisions
Note: originally posted as:
http://www.mailbase.ac.uk/lists/dc-datamodel/files/decisions.html
with date 1999-03-20. The decisions date from a 1998-09-24 Data
Model Working Group meeting at ECDL in Heraklion, Crete.
Dublin Core Data Model Working Group
Decisions
Contents
--------
1 Process
2 General
3 Qualified DC
4 Namespaces, specifications, URIs and naming
5 Repetition
6 Interoperation between DC-Simple and Qualified-DC systems
7 RDF Schema
8 Multilingual strings
9 Element-specific points
10 Miscellaneous
11 Informative Annex A -- Element Qualifier(s) for dc:Title
1 Process
-------
1.1 The draft spec will include explicit mention that it is only a
draft and that element-specific WGs are invited to review it and
comment on it, especially on the element-specific aspects.
2 General
-------
2.1 The DC community will "borrow or steal" from other communities
where reasonable. This applies in particular to terminology,
schemas, vocabularies etc.
2.2 The RDF data model is the foundation for the DC data model. This
does not mean that DC (qualified or unqualified) must be expressed
in RDF or even in XML. These langauges do, however, offer us
powerful modelling tools, which we are glad to make use of.
2.3 The value of each of the DC elements may be a string or a URI.
The URI may be either the URI of an RDF node or a URI which should
be resolved in order to obtain a value.
3 Qualified DC
------------
3.1 Qualified DC adds three tools to the toolbox provided by
unqualifed DC. These are:
- Value Qualifiers, which allow us to correctly interpret string
values.
- Element Qualifiers, which allow us to make statements such as
"X is a Y".
- Value Components, which allow us to make statements such as
"X has a Y".
The first two of these are referred to as "Qualifiers". All three
are further discussed below.
In addition to the above three tools, RDF provides very useful
constructs for the grouping and sequencing of statements. These
constructs (Seq, Alt, Bag) may be used for both qualified and
unqualified DC.
DC delegates the handling of language qualification to RDF and XML.
3.2 A Value Qualifier:
- Qualifies a string value and can be applied only to string
values.
- Defines either an encoding scheme, or a controlled vocabulary.
- Is expressed using the machine-readable token "xyz:Scheme"
(where "xyz" is the local abbreviation for the "dcq" namespace).
- Takes as a value either a string (eg "ISO-8601") or a URI
(eg "http://www.w3.org/TR/NOTE-datetime").
3.3 We consider that the following definition of Value Qualifiers is
broadly correct but will require further editing:
A Value Qualifier refers to the value, specifying either an
encoding rule or a controlled vocabulary to aid in interpreting
the value. Value Qualifiers apply only to strings, but may be
expressed as URIs. Recommended practice is to use a Value
Qualifier generally understood by the target community, or a
standard encoding or parsing scheme in wide use across
communities. Repetition of elements allows use of Value
Qualifiers from more than one source or at more than one level
of specificity.
3.4 We consider that the following definition of Element Qualifiers is
broadly correct but will require further editing:
An Element Qualifier refines the semantics of a DC element to
further specify the relationship of the element to the resource
itself. The Element Qualifier does not change the definition
of the element, nor does it modify the value. Recommended
practice is to use an Element Qualifier from the DCQ controlled
list defined for that element or from a domain specific list
approved and maintained by a particular community. Repetition
of elements allows use of terms from more than one source.
3.5 Each DC Element may have zero or more Element Qualifiers.
3.6 We consider that the following definition of Value Components is
broadly correct but will require further editing:
Value Components are semantic characteristics (eg name,
haircolor, eyecolor, SSN, etc of a person) of a value. These
characteristics may be drawn from existing vocabularies or
defined by local communities. Value Components are intrinsic
to the value regardless of its relationship to a particular
resource.
3.7 We shall use the term "Intermediate Node" to denote a resource in
an RDF graph that does not have an independent existence in the
real world.
3.8 Element Qualifiers and Value Qualifiers are properties of a
structural node. A single such structural node can have both an
Element Qualifier and a Value Qualifier, eg:
Unqualified:
[R1]---dc:Date------->"1998-12-31"
Qualified:
[R1]---dc:Date------->[IN1]
[IN1]--rdf:Value----->"1998-12-31"
[IN1]--dcq:DateType-->"http://....Issued"
[IN1]--dcq:Scheme---->"http://www.w3.org/TR/NOTE-datetime"
4 Namespaces, specifications, URIs and naming
-------------------------------------------
4.1 We shall use different namespaces for unqualified DC and for
qualified DC.
4.2 For the 15 DC elements defined in RFC 2413, the namespace we shall
use is:
http://purl.org/dc/elements/1.0/
We note that the portion:
purl.org/dc
may change in the future.
The corresponding recommended abbreviation is "dc". The use of a
common abbreviation improves readability. Note, however, that the
actual choice of abbreviation is a local matter, as the namespace
is defined solely by a URI.
4.3 For the DC qualifiers, the namespace we shall use is:
http://purl.org/dc/qualifiers/1.0/
The corresponding recommended abbreviation is "dcq". The use of a
common abbreviation improves readability. Note, however, that the
actual choice of abbreviation is a local matter, as the namespace
is defined solely by a URI.
4.4 Some of the terms (eg IsBasedOn) to be used with DC qualifiers (eg
RelationType) will be defined by the DC community. These will be
grouped into logically related sets of terms (eg the set of
Relation Types). We shall define a namespace for each such
logically related set of terms (eg for the set of Relation Types).
[Editorial note: The use of a separate namespace for each group of
terms is under review.]
4.5 We shall not include dots (or any other punctuation) in the names
of qualifiers.
4.6 The DC specifications will define lists of values for some of the
DCQ qualifiers (such as dcq:RelationType) though not for all such
qualifiers. For some of the qualifiers for which we will define
lists of values, it will be open to other communities to define
additional values. For those qualifiers for which we do not
define lists of values, all possible values will be defined by
other communities.
4.7 Referring to the point above, the values defined in the DC
specifications will be URIs
(eg "http:/purl.org/.../dublin.../...IsBasedOn"). We are not
imposing such a restriction on values defined by others. That is,
in general, the value of an Element Qualifier or of a Value
Qualifier may be either a string or a URI.
4.8 Where the DC community specifies a list of values for a DC Element
(or Value Component), those values shall take the form of URIs.
4.9 Developers MUST not assume that all changes to DC-defined
vocabularies (lists of qualifier values or value values) will be
identified by changing the URI of the vocabulary.
4.10 We shall document unqualified and qualified DC in a single
(versioned) spec, while retaining the various distinct namespaces
with their own versions. The spec version is for human
consumption. The namespace versions are for machine consumption.
Note that qualifiers are not guaranteed to be independent of the
version of the "dc" namespace. The spec should incorporate the
notion of a migration path.
4.11 The "dcq" spec should include a non-normative section, containing
a statement such as "Developers of new vocabularies MUST state
whether any change to the vocabulary will be identified by
changing the URI of the vocabulary".
5 Repetition
----------
5.1 Multiple instances of a DC PropertyType may be expressed using
simple repetition or any one of the three RDF M&S collection
constructs (Bag, Seq and Alt). The DC DM WG seeks feedback on
this decision from DC implementors.
5.2 Where multiple instances of a DC PropertyType are to be ordered,
the appropriate RDF M&S collection construct (Seq or Alt) should
be used.
5.3 The above decisions apply also to Element Qualifiers and to Value
Qualifiers (though we cannot see good uses for Alt in this case).
We seek feedback on this decision from DC implementors.
5.4 For the repetition and ordering of values we recommend the use of
a single rdf:value arc pointing to the appropriate one of the
three RDF collection constructs (Alt, Seq, Bag). In some cases it
may be appropriate, instead, to repeat the entire DC element, with
the additional value. Where values are provided in multiple
languages and there is no default language, we recommend use of a
Bag; if there is a default language, we recommend use of an Alt.
The DC DM WG seeks feedback on this decision from DC implementors,
particularly those working on multilingual DC.
6 Interoperation between DC-Simple and Qualified-DC systems
---------------------------------------------------------
6.1 A DC agent MUST understand the "dc" namespace and the RDF M&S
namespace (here shown as "rdf"). Understanding the "rdf"
namespace includes understanding how to extract unqualified DC
values from qualified DC constructs.
6.2 Every valid unqualified DC description is a valid qualified DC
description. In other words, qualifier-capable DC systems can't
require the presence of qualifiers, they must be able to use
unqualified elements.
6.3 Qualifier-capable DC systems MUST not automatically add any
particular qualifier and qualifier value to incoming descriptions
which lack them. For example, don't automatically add
dcq:DateType="...Created" to any incoming dc:Date element.
6.4 Conversion from a qualified-DC description to a simple DC
description is accomplished through the standard procedure given
below:
// dumb-down(Element)
// Returns a string that is the Simple DC version of the qualified
// DC description, Element.
// The gist of the procedure is to ignore all qualifiers that
// originate at structural nodes, and follow the chain of
// rdf:value arcs until a String is found. That string is returned
// as the value of the procedure. For example,
// [resource]---dc:Title--->[sn01]
// [sn01]---dcq:TitleType--->"alternative"
// ---rdf:value--->"Paris Symphony"
// would simplify to
// [resource]---dc:Title--->"Paris Symphony"
//
// The expected invocation of the procedure is in a loop like:
// For each (qualified) dc element in a description
// currentArc = the arc of the DC element
// string = dumb-down(currentArc);
// replace qualified value of DC element with string
// (if its a null string, then don't specify that DC element)
procedure dumb-down(theArc) returns a string {
if (theArc points to a string)
return that string
else if (theArc points to a structural node with an rdf:value
arc)
return dumb-down(the rdf:value arc from that node)
else if (currentArc points to a node of 'known' type)
// e.g. a vCard node
handle it in the manner appropriate for that known type
(this will either return a string or call dumb-down with
some arc emenating from that node)
else if (currentArc points to a Bag)
tempString = null
for each member arc j from the bag
// member arcs are the _1, _2,... arcs
tempString += dumb-down(j); // += means concatenation
else if (currentArc points to a Seq)
tempString = null
for each member arc j from the seq
tempString += dumb-down(j); // += means concatenation
else if (currentArc points to an Alt)
pick one member arc, using the default (first) arc if
you have no particular reason to pick another.
return dumb-down(the chosen arc)
else (currentArc points to a node of unknown type)
return a null string
// The alternative of mindless concatenation is not
// recommended.
}
7 RDF Schema
----------
7.1 Element Qualifiers are all instances of a class named something
like dcq:ElementQualifier. Value Qualifiers and Value Components
may be able use a similar approach.
7.2 The WG has decided that an isDefinedIn property is necessary and
will request that the RDF Schema WG provide such a property.
Failing this, the WG will specify such a property.
8 Multilingual strings
--------------------
8.1 The DC community requires the ability to handle multilingual
strings, associating each sub-string with its language. Language
qualification of an entire string is just a degenerate case of
this requirement. Hence, the functionality of the Canberra
language qualifier (which applied to entire strings) is satisfied
by XML's xml:lang attribute.
8.2 The DC DM WG asks the XML, I18N and HTML WGs of the W3C to provide
a general mechanism for multilingual strings in XML documents.
8.3 The DC DM WG asks the W3C RDF M&S WG to support the above
mechanism once it has been specified.
9 Element-specific points
-----------------------
9.1 An Element Qualifier for the dc:Contributor, dc:Creator and
dc:Publisher elements, which qualifies those elements by
specifying the contributory role, is dcq:AgentRole. Feedback from
the relevant WG(s) is requested.
9.2 An Element Qualifier for the dc:Relation element, which qualifies
that element by allowing a more specific relation to be given, is
dcq:RelationType. Feedback from the Relation WG is requested.
9.3 An Element Qualifier for the dc:Date element, which qualifies that
element by allowing a more precise specification of the type of
the date, is dcq:DateType. Feedback from the Date WG is requested.
9.4 Additional qualifiers will be added over time, via the DC process.
9.5 The semantic purpose of a dc:Identifier is satisfied by the
Resource's own URI.
9.6 We recommend that agents (dc:Creator, dc:Contributor and
dc:Publisher) be described in any of the following ways:
- using a string to hold the agent's name,
- using in-line RDF from other appropriate namespaces (eg vCard
or LCNAF) once use of such RDF has been sanctioned by the
organisations owning the particular standards (eg vCard or
LCNAF),
- using a URI to point to a remote name file (which uses vCard
or LCNAF etc).
9.7 The Personal vs Corporate (etc?) nature of a value is expressed
using the rdf:Type property if the value is a node. The DC
community will develop a controlled vocabulary incorporating at
least terms representing a person and a corporate body.
10 Miscellaneous
-------------
10.1 In RDF, we use only DC element names as the names of properties of
nodes which represent actual resources. In other words, at the
outermost level, we do not use any property names other than the
fifteen DC element names.
10.2 In RDF, we do not use the fifteen DC element names except as the
names of properties that apply to actual resources. In other
words, at inner levels, we do not use the fifteen DC element names
to name properties.
11 Informative Annex A -- Element Qualifier(s) for dc:Title
--------------------------------------------------------
11.1 An Element Qualifier for the dc:Title element, which qualifies
that element by allowing a more precise specification of the
structure (eg Main, Alternative) of the title, might be
dcq:TitleStructure.
An example of another possible Element Qualifier for dc:Title
might be dcq:TitleExpression, whose values might be, eg,
Original, Transliterated, Translated, etc.
Feedback from the Title WG is requested, covering:
a) the need for each qualifier,
b) the semantics of each qualifier,
c) the machine-readable token representing each qualifier,
d) the DC-defined values of each qualifier (if any).
