Dublin Core
Dublin Core
About DCMI Themes Members Governing Board Usage Board Directorate
Bluesky Twitter YouTube GitHub RSS Feed

Data Model Working Draft

Creators: Mischa Wolf
Date Issued: 1998-10-07
Latest Version: https://dublincore.org/specifications/dublin-core/datamodel/
Release History: https://dublincore.org/specifications/dublin-core/datamodel/release_history/
Description: An overview of the DC-RDF data model.

1. General

1.1
The DC community will "borrow or steal" from other communities where reasonable. This applies in particular to terminology, schemas, vocabularies etc.

2. Data Model

2.1
The RDF data model is the foundation for the DC data model.

2.2
We shall use the term "structural node" to denote a resource in an RDF graph that does not have an independent existence in the real world.

3. DC elements

3.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.

3.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.

3.3
The value of each of the following properties 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.

  • dc:Contributor
  • dc:Creator
  • dc:Date
  • dc:Description
  • dc:Format
  • dc:Language
  • dc:Publisher
  • dc:Relation
  • dc:Rights
  • dc:Subject
  • dc:Title
  • dc:Type

3.4
The semantic purpose of a dc:Identifier is satisfied by the Resource's own URI. If an explicit dc:Identifier is used, its value 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.

4. Agents

4.1
Re the Contributor/Creator/Publisher question, we advise that:

  • we DO change some of the descriptive names (eg "Other Contributor"),
  • we DO change some of the element definitions,
  • we DO NOT add or remove any elements at this time,
  • we DO NOT change any element labels (eg "Contributor"),
  • we DO NOT add any label aliases.

4.2
We recommend that agents 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).

4.3
We refer the "Personal vs Corporate" issue to the Sub-elements WG and ask them for information on whether/where support for this distinction is required when not handled by external name authorities.

5. Namespaces

5.1
We shall have two DC namespaces: one for the 15 elements and one for qualification. In documentation we shall use the abbreviations "DC" and "DCQ".

5.2A
"simple" DC agent MUST understand the "simple" Dublin Core™ namespace (often abbreviated as "dc") 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 by following the chain of "rdf:value"s.

5.3
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".

5.4
For the DC qualifiers (eg RelationType) the namespace we shall use is:

http://purl.org/dc/qualifiers/1.0/

The corresponding recommended abbreviation is "dcq".

5.5
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).

6. Qualifiers

6.1
Two categories of qualifier are widely useful, which we called A and B. Types and Roles are examples of category A and Schemes of category B. The semantics of category A qualifiers are to refine the meaning of the relationship between the resource and the value, whereas category B qualifiers make statements about the value itself. We express qualifiers in both categories using a property of a synthetic node. A single such synthetic node can have both a category A qualifier and a category B qualifier. The template for the use of these categories looks like this:

Unqualified:

[R1]---dc:Foo---------------------->the-value

Qualified:

[R1]---dc:Foo---------------------->[SN1]
[SN1]--rdf:Value------------------->the-value
[SN1]--dcq:a-category-A-qualifier-->...
[SN1]--dcq:a-category-B-qualifier-->...

As well as being used to qualify DC elements, this template can be used to qualify other relationships.

6.2
We shall not include dots (or any other punctuation) in the namesof Types etc.

6.3
The DC specifications will define lists of values for some of the DCQ qualifiers (such as dcq:TitleType) 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.

6.4
Referring to the point above, the values defined in the DC specifications will be URIs (eg http:/purl.org/.../dublin.../...Alternative). We are not imposing such a restriction on values defined by others. That is, in general, the value of a dcq:XxxxType and dcq:Scheme etc may be a string or a URI.

6.5
The value of an rdf:Value can be qualified by dcq:Scheme.

6.6
We define the following Types:

  • dc:Title can be qualified by a dcq:TitleType.
  • dc:Date can be qualified by a dcq:DateType.
  • dc:Relation can be qualified by a dcq:RelationType.
  • dc:Creator, dc:Contributor and dc:Publisher can be qualified by a dcq:AgentType, indicating the agent's role in relation to the resource.

Other Types may be added later.

7. Repetition

7.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.

7.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.

7.3
The above decisions apply also to Type A and Type B qualifiers (though we cannot see good uses for Alt in this case). The DC DM WG seeks feedback on this decision from DC implementors.

7.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.

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.