DCMI: Expressing Qualified Dublin core in RDF / XML

Title:	Expressing Qualified Dublin Core™ in RDF / XML
Creator:	Stefan Kokkelink
Creator:	Roland Schwänzl
Date Issued:	2002-04-14
Identifier:	http://dublincore.org/specifications/dublin-core/dcq-rdf-xml/2002-04-14/
Replaces:	http://dublincore.org/specifications/dublin-core/dcq-rdf-xml/2001-11-30/
Is Replaced By:	Not applicable
Latest Version:	http://dublincore.org/specifications/dublin-core/dcq-rdf-xml/
Status of Document:	This is a DCMI Proposed Recommendation.
Description of Document:	This document describes how qualified Dublin Core™ metadata can be encoded in RDF / XML and gives practical examples.

0 Introduction

  <dd>1 <a href="#sec1">Unqualified DC</a>: The hedgehog
  model</dd>

  <dd>2 <a href="#sec2">Qualified DC</a>

  <dd>3 <a href="#sec3">DC in collaboration with other
  vocabulary and DumbDown</a>

  <dd>4 <a href="#sec4">Language Qualification</a>

  <dd>5 Appendix: <a href="#sec5">Schema Drafts</a>

  <dd>6 Appendix: <a href="#sec6">Summary DC
  Qualifiers</a>

  <dd>7 <a href="#Acknow">Acknowledgements</a>

  <dd>8 <a href="#references">References</a>

0 Introduction

In this paper Qualified Dublin Core™ is encoded in terms of RDF, the Resource Description Framework as defined by the RDF Model & Syntax Specification (XML namespace for RDF). RDF is a W3C recommendation. Also RDFS the RDF Schema specification 1.0 is used (XML namespace for RDFS). RDFS is a W3C candidate recommendation. Quite often the notion of URI (Uniform Resource Identifier) is used. The notion of URI is defined by RFC 2396. The notion of URI embraces URL and URN.

We also discuss collaboration of qualified DC with other vocabularies and DumbDown. In this paper explicit encoding is provided for classical classification systems and thesauri. Additionally a procedure is discussed to create encoding for more general schemes. One of the major changes with respect to the data model draft is the more systematic use of RDF Schema.

0.1 RDF(S) Basics
What is RDF	The basic layer of RDF can best be understood as collection of simple sentences (assertions): They have a subject, a predicate and an object. A nice way to visualize the underlying structure is to draw nodes for subject and object and an arrow between them for the predicate. In case another sentence is talking about - say - the same subject, just glue the two pieces together at the subject node. Generally such geometric/semantic objects are called labeled directed graphs. RDF thereby recognizes it occurs rather seldom, that one can travel from A to B in a unique optimal fashion. This observation is basic to RDF and the basis of its potential.
Resources	The notion of resource in RDF is formal. Any resource can be given a URI, but one is not forced to expose a choice visibly to the outside world. There is at most one choice one can provide to the outside world. RDF treats different URI as different resources. All resources without explicitly assigned URI are assumed as different by RDF.A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources. [RFC 2396, 1.1].
Literals	A literal is an object one cannot make any assertions about. As with resources RDF is formal with the definition of a literal. >From the viewpoint of RDF any well formed XML can be used as a literal. In case one declares an object as literal, RDF will not attempt to interpret embedded mark up.
Assertions (Statements)	Taken together the notion of resource and the notion of literal, it appears obvious to require resources as subjects of assertions, but not to make limitations on the object.
Properties (Predicates)	As the predicate in a sentence is supposed to carry meaning, which can be explained in more detail, RDF assumes predicates as resources as well. The predicate might be viewed as a property of the subject resource, which has the object object as target.

0.2 RDF(S) Specifics (1)
Repeated Elements	All DC Elements are repeatable. RDF allows to disambiguate the meaning of repetitions by four semantically different constructions. Qualified DC in RDF makes heavy use of these constructions. (Details will be given below).
``MetaMetaData''	One often runs into the problem to explain a certain package of MetaData has been issued by some authority. RDF solves this problem without introducing vocabulary, one would have to reinvent for each additional layer, but with a construction which automatically creates first class resources from second class. For this process RDF uses the word Reification.
RDF Transport	RDF Expressions can be send on the web in XML form. As XML essentially is defined by trees for general reasons one cannot expect a particular uniqueness for the Transfer Syntax. Indeed RDF M & S provides XML encoding for the same RDF object, which cannot be detected as equivalent by an XML parser. This behavior enables RDF to travel along with other XML languages like a submarine. This behavior is explored elsewhere.

More RDF specifics will show up during the course.

Basic Observation: DC Elements correspond to RDF properties.

1 Unqualified DC: The hedgehog model

The following graph re - expresses unqualified DC in HTML in RDF in a schematic way. There is a tiny bit of extra information in the hedgehog model as opposed to HTML: it is obvious, that all assertions made are about a fixed resource. (Throughout the paper resources are indicated by .) Content which is well-formed XML will be denoted with and addressed as literals.

A diagram of unqualified DC that looks like a hedge hog.

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:dc="http://purl.org/dc/elements/1.1/">  
  <rdf:Description>
    <dc:creator>a</dc:creator>
    <dc:contributor>b</dc:contributor>
    <dc:publisher>c</dc:publisher>
    <dc:subject>d</dc:subject>
    <dc:description>e</dc:description>
    <dc:identifier>f</dc:identifier>
    <dc:relation>g</dc:relation>
    <dc:source>h</dc:source>
    <dc:rights>i</dc:rights>
    <dc:format>j</dc:format>
    <dc:type>k</dc:type>
    <dc:title>l</dc:title>
    <dc:date>m</dc:date>
    <dc:coverage>n</dc:coverage>
    <dc:language>o</dc:language>
  </rdf:Description>
</rdf:RDF>

Observe that all DC properties are optional and repeatable.

1.1 Example

A diagram showing that all DC properties are optional and repeatable.



<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description>

<dc:creator>Karl Mustermann</dc:creator>

<dc:title>Algebra</dc:title>

<dc:subject>mathematics</dc:subject>

<dc:date>2000-01-23</dc:date>

<dc:language>EN</dc:language>

<dc:description>An introduction to algebra</dc:description>

</rdf:Description>

</rdf:RDF>

The state of affairs given by the hedgehog is unsatisfactory in various respects. In particular there is no way to provide structure for a resource discovery process.

2 Qualified DC

The DCMI has recognized two broad classes of qualifiers. We collect from the Qualifier Recommendation the information we need.

Element Refinement. These
qualifiers make the meaning of an element narrower or more
specific. A refined element shares the meaning of the
unqualified element, but with a more restricted scope. A
client that does not understand a specific element
refinement term should be able to ignore the qualifier and
treat the metadata value as if it were an unqualified
(broader) element. The definitions of element refinement
terms for qualifiers must be publicly available.
Encoding Scheme. These qualifiers
identify schemes that aid in the interpretation of an
element value. These schemes include controlled
vocabularies and formal notations or parsing rules. A value
expressed using an encoding scheme will thus be a token
selected from a controlled vocabulary (e.g., a term from a
classification system or set of subject headings) or a
string formatted in accordance with a formal notation
(e.g., "2000-01-01" as the standard expression of a date).
If an encoding scheme is not understood by a client or
agent, the value may still be useful to a human reader. The
definitive description of an encoding scheme for qualifiers
must be clearly identified and available for public
use.
The normative reference for DC
Qualifiers is at http://dublincore.org/specifications/dublin-core/dcmes-qualifiers.
A convenience copy of it's summary is included here as (6 Appendix).

The first issue for qualification is what DCMI calls Element refinement. RDFS provides a special property for this kind of semantic refinement:

2.1.1 RDF(S) Specifics (2)
rdfs:subPropertyOf	The property `rdfs:subPropertyOf` is an instance of `rdf:Property` that is used to specify that one property is a specialization of another. A property may be a specialization of zero, one or more properties. If some property P2 is a subPropertyOf another more general property P1, and if a resource A has a P2 property with a value B, this implies that the resource A also has a P1 property with value B.

2.1.1 RDF(S) Specifics (2)

rdfs:subPropertyOf

The property rdfs:subPropertyOf is an instance of rdf:Property that is used to specify that one property is a specialization of another. A property may be a specialization of zero, one or more properties. If some property P2 is a subPropertyOf another more general property P1, and if a resource A has a P2 property with a value B, this implies that the resource A also has a P1 property with value B.

2.1.2 Example

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
            xmlns:dc="http://purl.org/dc/elements/1.1/"
            xmlns:dcterms="http://purl.org/dc/terms/">     
  <rdf:Description>
    <dcterms:abstract>The paper resolves the issues of the datamodel
        draft.
    </dcterms:abstract>
  </rdf:Description>
  <rdf:Description rdf:about="http://purl.org/dc/terms/abstract">
    <rdfs:subPropertyOf 
       rdf:resource="http://purl.org/dc/elements/1.1/description"/>
  </rdf:Description>
</rdf:RDF>

Here three things happened at a time:

We use the qualifier vocabulary,
we declare in machine understandable way the qualifier dcterms:abstract refines dc:descriptionand for the first time
we use another resource as the target of an assertion and not just a literal.

2.1.3 Remark

Other communities can also use rdfs:subPropertyOf to declare refinements of DCMI Elements in a transparent way.Observe further, that rdfs:subPropertyOf statements can be repeated and nested.

The declaration of dcterms:abstract as subProperty of dc:description in the example above ensures that for every dcterms:abstract arc a corresponding dc:description arc (with the same subject and object) is implicitly contained in the RDF.

2.1.4

DC Model

The former version of the datamodel draft ([DM]) did not make use of RDFS and instead introduced an ad hoc work around, which shows cumbersome in case one wants to refine for instance the notion of abstract further.

Basically this is all, what one has to say about element refinement. The flexible notion of subProperty frees from the HTML dot notation. It gives room for transparent encoding of partial orderings on refinements of a given element.

A draft for an RDF Schema Declaration for the element refinements specified in the DC Qualifiers recommendation is given in (5.1).

2.1.5 Remark

There is some relation between parts of RDF - Vocabulary and DC - Vocabulary which appear by recalling some definitions on both sides.

2.1.5.1 RDF(S) Specifics (3)
rdf:value	Identifies the principal value (usually a string) of a property.
rdfs:label	Provides a human-readable version of a resource name. The target of an `rdfs:label` arc must be a literal.
rdfs:isDefinedBy	Indicates a resource containing and defining the subject resource. The target of an `rdfs:isDefinedBy` arc must be a Resource.
rdfs:seeAlso	Indicates a resource that provides information about the subject resource. The target of an `rdfs:seeAlso` arc must be a Resource.
rdfs:Comment	This is used to provide a human-readable description of a resource.
rdfs:Class	The concept of Class
rdf:type	Identifies the Class of a resource. The target of an `rdf:type` arc must be an instance of `rdfs:Class`.

2.1.5.2 Dublin Core™ Properties
dc:title	A name given to the resource.
dc:relation	A reference to a related resource.
dc:description	An account of the content of the resource.
dc:type	The nature or genre of the content of the resource.

2.1.5.3

Observe that rdf:value is not caught by an enveloping DC property. We will make active use of rdf:value in section 2.3. Relations between the two vocabularies are made explicit in (5.1_DC Terms RDF Schema Draft_). These relations are also relevant for the DC DumbDown Algorithm defined below. We recall these relations here in a more convenient form for human readers.

2.1.5.4

-- subPropertyOf -->
rdfs:label	dc:title
rdf:type	dc:type
rdfs:isDefinedBy	dc:relation
rdfs:seeAlso	dc:relation
rdfs:comment	dc:description

2.1.5.5

Observe that the direction of the rdfs:subPropertyOf relation is due to some additional constraints which are specified for the RDF(S) properties.
For example, although the definitions of rdfs:label and dc:title are basically equivalent, the requirement for rdfs:label to have a literal as target enforces the definition of rdfs:label as a subPropertyOf dc:title and not vice versa.

2.2 Repeated Properties and ``MetaMetaData''

All Dublin Core™ Elements are repeatable. Repeating element E:

The objects mentioned as targets all meet the relation represented by element E with the subject under description.

In RDF it is also possible to repeat properties with the cited meaning of a logical AND.

Sometimes one wants to explicitly say something slightly different: The objects fulfil the relation E as a group , in order or picking one or the other doesn't really matter w.r.t. E.

RDF allows to mark such internal relationships, by creating new resources from given objects in three different ways, called Bag,Seq and Alt construction.

2.2.1 AND

AND
The entities AAAAA and BBBBB are both primarily responsible for the making of the concept known as the Wheel.
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/"> <rdfs:Class rdfs:label="Wheel"> <dc:creator>AAAAA</dc:creator> <dc:creator>BBBBB</dc:creator> </rdfs:Class> </rdf:RDF>

AND

The entities AAAAA and BBBBB are both primarily responsible for the making of the concept known as the Wheel.

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
            xmlns:dc="http://purl.org/dc/elements/1.1/"
            xmlns:dcterms="http://purl.org/dc/terms/">   
<rdfs:Class rdfs:label="Wheel">
 <dc:creator>AAAAA</dc:creator>
 <dc:creator>BBBBB</dc:creator>
</rdfs:Class>
</rdf:RDF>

The three constructions Bag, Seq and Alt are generally referred to as Container in RDF. They bind objects together. Each Container is doing that in a very specific way. Their use has potential to structure information.

2.2.2 Bag

The first container type RDF comes up with, is that of a Bag. The notion of Bag realizes semantically the notion of an unordered list. More specifically of a list, with ordering explicitly declared as irrelevant. This notion for instance matches the meaning of Co-authorship in Mathematics: In Math co-authors are given as a bag, whose objects are resources of type Person. This way the micro-profile Bag of Persons avoids the introduction of new vocabulary to express the relationship.

Such a Bag may or may not have a public URI. The same applies to resources of type person. In the example below the bag construction is used with otherwise unqualified DublinCore. Even in this form the meaning differs from the previous AND Example. Jon Doe and Karin Mustermann together formed an entity, which as such represents a creator. The order in the record is an artifact of the coding and nothing else.

Bag
Jon Doe and Karin Mustermann joint their forces to create a gadget with title Healthy Meat
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description dc:title="Healthy Meat"> <dc:creator> <rdf:Bag> <rdf:li>Jon Doe</rdf:li> <rdf:li>Karin Mustermann</rdf:li> </rdf:Bag> </dc:creator> </rdf:Description> </rdf:RDF>

Bag

A diagram showing the RDF container called Bag

Jon Doe and Karin Mustermann joint their forces to create a gadget with title Healthy Meat

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
            xmlns:dc="http://purl.org/dc/elements/1.1/"
            xmlns:dcterms="http://purl.org/dc/terms/">   
<rdf:Description dc:title="Healthy Meat">
 <dc:creator>
   <rdf:Bag>
     <rdf:li>Jon Doe</rdf:li>
     <rdf:li>Karin Mustermann</rdf:li>
   </rdf:Bag>
 </dc:creator>
</rdf:Description>
</rdf:RDF>

2.2.3 Seq

Some academic circles expect some meaning from the ordering of author names. They will be satisfied with the Seq construction. Seq is a sequence, with the ordering explicitly declared as relevant. Seq and Bag share, that their objects have to be taken in all.

Below we indicate a more interesting use of Seq.

Seq
Karin Mustermann and John Doe jointly contributed to a gadget. The anti-lexicographic order has been chosen with deliberation.
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description> <dc:contributor> <rdf:Seq> <rdf:li>Karin Mustermann Inc.</rdf:li> <rdf:li>John Doe Inc.</rdf:li> </rdf:Seq> </dc:contributor> </rdf:Description> </rdf:RDF>

Seq

Karin Mustermann and John Doe jointly contributed to a gadget. The anti-lexicographic order has been chosen with deliberation.

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:dcterms="http://purl.org/dc/terms/">
<rdf:Description>
<dc:contributor>   
<rdf:Seq>
        <rdf:li>Karin Mustermann Inc.</rdf:li>
        <rdf:li>John Doe Inc.</rdf:li>
</rdf:Seq>
</dc:contributor>
</rdf:Description>
</rdf:RDF>

2.2.4 Remark

With respect to numerical constructions we here confine ourselves to an analysis of points in Euclidean three space.

These points form a class say R3. Each such point is given by a sequence of three real numbers. So we have a natural idea on how to construct a value. The value will be a resource of type Seq. Each object of the Seq container will be a RealNumber. In case we want to give one or all components, we have to decide on a number representation system. Each such system can be declared as a class. Say we choose decimal system. The problem is, that most real numbers don't have finite representations. To make processing unambiguous we will at least have to introduce a property one might call precision. The content model for precision one would still have to define separately.

One might even want more control on the notion of value . One way to do that would be to define a subProperty of rdf:value, which is supposed to take values in sequences of length 3.

More complicated situations may want to reuse such structure worked out in detail.

2.2.5 Alt

Alt (Relative Case)
	The resource called by #17 in this paper is identified by either one of the given URL's. You only need to retrieve one of them.
	<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description rdf:ID="17"> <dc:identifier> <rdf:Alt> <rdf:li rdf:resource="http://dublincore.org/"/> <rdf:li rdf:resource="http://purl.org/dc/"/> </rdf:Alt> </dc:identifier> </rdf:Description> </rdf:RDF>
Alt (Absolute Case)
	With respect to whatever assertion with object the resource called by #18, the cited URL's have to be viewed as equivalent. It always suffices to look at one of them.
	<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Alt rdf:ID="18"> <rdf:li rdf:resource="http://dublincore.org/"/> <rdf:li rdf:resource="http://purl.org/dc/"/> </rdf:Alt> </rdf:RDF>

Another typical application of Alt appears with lists of synonyms for a chosen descriptor. As Alt gives a slight precedence to the first given value, this is exactly what happens with synonyms: They form an equivalence class with a chosen representative.

2.2.6 Warning

The RDF Container Alt must not be confused with the refinement alternative of the DC Element title.

2.2.7 Reification

One often wants to express some kind of authority on a given assertion. RDF here offers a method called Reification. Despite it's awkward name and seemingly complicated representation as a graph, Reification is hardly more than providing a resource for an assertion, one can reference. A reification unambiguously identifies the assertion, it provides a resource for. To that objective explicitly subject, object and predicate of the assertion are given in the graph representation.

The general method of Reification avoids the introduction of particular vocabulary for ``MetaMetaData'', but makes the Dublin Core™ Vocabulary available in that situation also.

Reification
The given abstract has been provided by the author John Doe of http://www.potato.org. John Doe claims his work as a highly original introduction to potato theory.
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description rdf:about="http://www.potato.org/"> <dcterms:abstract rdf:ID="19"> An excellent introduction to potato theory is provided by this highly original paper </dcterms:abstract> <dc:creator>John Doe</dc:creator> </rdf:Description> <rdf:Description rdf:about="#19"> <dc:creator>John Doe</dc:creator> </rdf:Description> </rdf:RDF>

Reification

The given abstract has been provided by the author John Doe of http://www.potato.org. John Doe claims his work as a highly original introduction to potato theory.

<?xml version="1.0"?>
<rdf:RDF 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"    
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:dcterms="http://purl.org/dc/terms/">
  <rdf:Description rdf:about="http://www.potato.org/">
    <dcterms:abstract rdf:ID="19">
      An excellent introduction to potato theory is 
      provided by this highly original paper
    </dcterms:abstract>
    <dc:creator>John Doe</dc:creator>
  </rdf:Description>
  <rdf:Description rdf:about="#19">
    <dc:creator>John Doe</dc:creator>
  </rdf:Description>
</rdf:RDF>

2.3 Encoding Schemes

One may view Bag, Seq, Alt as first important examples of encoding schemes, which simply come for free with RDF. As indicated with the discussion on R3 these structures in RDF can be iterated and nested and therefore are of great potential in encoding structured MetaData.

But there are simpler structures, which one may think about first.

Perhaps the simplest case of value encoding (off the basic character representation rules which come by using XML for RDF transport) is that of a classical subject classification scheme.

Typically here we have a code - some obscure string - and a caption, which is (supposed) as human understandable.

This sounds like providing a value/label pair.

In case we know a URI, specifying the object we want to use in it's relation with the scheme, we could make an rdfs:isDefinedBy arc pointing to that URI. Such a triple of RDF(S) properties hanging off a resource is what one may call:

2.3.1 Poor Man's Structured Values

A diagram showing Poor Man's structured values



<?xml version="1.0" ?>

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:dc="http://purl.org/dc/elements/1.1/"

xmlns:dcterms="http://purl.org/dc/terms/">

<Description>

<dc:subject>

<Description>

<value>19D10</value>

<rdfs:label>Algebraic K-Theory of spaces</rdfs:label>

<rdfs:isDefinedBy rdf:resource="URI2"/>

</Description>

</dc:subject>

</Description>

</RDF>

2.3.2 Remark: value/label game

In case there is some RDF Class given to identify the Scheme, we might know how to process the value and also how to take advantage of the partial order within the scheme itself. In case the Class definition reveals in machine understandable form, how to process the value one can dispense with the rdfs:isDefinedBy on the resource itself, but in general this is not very likely to believe. The Thesaurus - like case was already briefly discussed in connection with the Alt container. Please observe, that rdfs:label by definition must target literal content and cannot be processed by RDF any further.

A diagram showing RDF value/label information

#### 2.3.3 Remark

Observe, that it is NOT required that rdf:value arcs target literals. Such requirement would restrict RDF's potential for MetaData in an unreasonable way.

As we have seen with the discussion on points in R3 it can become necessary to iterate value/label game and also eventually introduce new properties till one believes strings (or resources) one eventually enters could be processed - in case of complete recognition of the semantic help given - with their full potential.

2.3.4 Iterated value/label game
DC Model	The complete set of instructions collected on the way should suffice to correctly process the eventual value. DCMI may recommend the use of properties additional to the core and additional to `rdf:type, rdfs:isDefinedBy` to aid processing for encoding of objects relevant to its focus. It is recommended at most one `rdf:value` (or subProperty thereof) emanate from a resource in a qualified DC record. Declaring some property as `subProperty` of a DC property is a legitimate processing hint. There is no restriction on the number (including zero) of `label` arcs in a qualified DC record.

2.3.4 Iterated value/label game

DC Model

The complete set of instructions collected on the way should suffice to correctly process the eventual value.

DCMI may recommend the use of properties additional to the core and additional to rdf:type, rdfs:isDefinedBy to aid processing for encoding of objects relevant to its focus.

It is recommended at most one rdf:value (or subProperty thereof) emanate from a resource in a qualified DC record. Declaring some property as subProperty of a DC property is a legitimate processing hint. There is no restriction on the number (including zero) of label arcs in a qualified DC record.

2.3.5 Remark

As long as it is possible to embed iterated poor man's structured values in the sense of the DC Model section a record can be viewed as qualified DC compliant and can expect a useful interpretation at least on unqualified DC level.

2.3.6 Remark

Some properties one might want to use may not be subordinated to any DC Element at all on their domain of definition, but in the case at hand also a DC Element or one of its refinements applies (semantic overlap). Then it is RDF's AND construction can be used in the record and one should provide that DC arc additionally. This will be considered as a legitimate processing hint also. When using core elements in a poor man's [cf. 2.3.4] carefully observe [2.1.5.4-5]. In case a scheme assigns it's values in the form of URIs, a node with such a URI should be used instead of the (anonymous node/value) part of poor man's.

2.3.7 Remark

The notion of Microprofile seems useful in this context. One is tempted to construct Application Profiles from such micro structures which in themselves rest on primitive Data - Types.

Some work in this direction is documented at CARMEN AP6.

Such procedure is in particular advisable in the area, where MetaData meets Data. This for instance happens in the notations for dates and locations. The work done on data typing in XML - Schema appears relevant. An integration of XML Schema data types with RDF in general is proposed in DAML+OIL. It fits with value/label game and is basically compliant with the cooperation of Dublin Core™ with other vocabulary as discussed in section 3.

DCMI recommended Schemes for dates and locations will be dealt with in a separate document.

2.3.8 URI Identifier Scheme

DCMES Element	Element Refinement(s)	Element Encoding Scheme(s)
Relation	Is Version Of Has Version Is Replaced By Replaces Is Required By Requires Is Part Of Has Part Is Referenced By References Is Format Of Has Format	URI
Identifier	-	URI
Source	-	URI

RDFMS gives the URI scheme a privileged role with respect to resources. There is no particular processing instruction required once a URI is given. We simply can call a resource by the rdf:resource construction. The usage of rdf:resource is defined in section 6 of RDFMS. A typical coding example is the following.

2.3.8.1 Example

A diagram showing a URI example



<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description>

<dc:identifier rdf:resource="http://www.myorg"/>

</rdf:Description>

</rdf:RDF>

In case one will not use URI as labelling scheme for resources or one is not satisfied with a simple string without further processing instructions,

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/">  
  <rdf:Description>
    <dc:identifier>1234564TGRF</dc:identifier>
  </rdf:Description>
</rdf:RDF>

then one should proceed as described in general at the beginning of this paragraph to construct a DC compliant RDF encoding.

2.3.9 Subject Schemes

DCMES Element	Element Refinement(s)	Element Encoding Scheme(s)
Subject	-	LCSH MeSH DDC LCC UDC

For each DCMI recommended encoding scheme an RDFS class is defined by the DC Terms RDF Schema.

2.3.9.1 Example

The following RDF/XML is a snip from the DC Terms RDF Schema.

< -- Class definition -- >
<rdfs:Class rdf:about="http://purl.org/dc/terms/MESH">
  <rdfs:label>MeSH</rdfs:label>
  <rdfs:comment>Instances of this class are Medical Subject Headings 
  and must provide an rdf:value (with content the code) 
  and should provide an rdfs:label arc (with content the caption).
  </rdfs:comment>
  <rdf:type rdf:resource = "http://purl.org/dc/terms/SubjectScheme" />
  <rdfs:isDefinedBy rdf:resource="http://purl.org/dc/terms/" />
</rdfs:Class>

2.3.9.2 Example: Usage of a MeSH object as subject.

A diagram shoing the usage of a MeSH object as subject

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
            xmlns:dc="http://purl.org/dc/elements/1.1/"
            xmlns:dcterms="http://purl.org/dc/terms/">   
<rdf:Description>
 <dc:subject>
   <dcterms:MESH>
     <rdf:value>D08.586.682.075.400</rdf:value>
     <rdfs:label>Formate Dehydrogenase</rdfs:label>
   </dcterms:MESH>
 </dc:subject>
</rdf:Description>
</rdf:RDF>

2.3.10 Language Schemes

DCMES Element	Element Refinement(s)	Element Encoding Scheme(s)
Language	-	RFC1766 ISO639-2

For each DCMI recommended encoding scheme an RDFS class is defined by DC Terms RDF Schema.

2.3.10.1 Example

A diagram showing an RDF language refinement

(RDF/XML snip from the DC Terms RDF Schema:)

<rdfs:Class rdf:about="http://purl.org/dc/terms/RFC1766">
  <rdfs:label>RFC1766</rdfs:label>
  <rdfs:comment>Internet RFC 1766 'Tags for the identification of Language' 
   specifies a two letter code taken from ISO 639, followed optionally by a 
        two letter country code taken from ISO 3166.</rdfs:comment>
  <rdf:type rdf:resource = "http://purl.org/dc/terms/LanguageScheme" />
  <rdfs:seeAlso rdf:resource = "http://www.ietf.org/rfc/rfc1766.txt" />
  <rdfs:isDefinedBy rdf:resource="http://purl.org/dc/terms/" />
</rdfs:Class>

2.3.10.2 Example: Usage of a RFC1766 object as language.

A diagram shoing the use of a RFC1766 object as language

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
            xmlns:dc="http://purl.org/dc/elements/1.1/"
            xmlns:dcterms="http://purl.org/dc/terms/">   
<rdf:Description>
 <dc:language>
   <dcterms:RFC1766>
     <rdf:value>EN</rdf:value>
     <rdfs:label>English</rdfs:label>
   </dcterms:RFC1766>
 </dc:language>
</rdf:Description>
</rdf:RDF>

2.3.11 Format Schemes

DCMES Element	Element Refinement(s)	Element Encoding Scheme(s)
Format	Extent	-
Format	Medium	IMT

For each DCMI recommended encoding scheme an RDFS class is defined by DC Terms RDF Schema.

2.3.11.1 Example

(RDF/XML snip from the DC Terms RDF Schema:)

<rdfs:Class rdf:about="http://purl.org/dc/terms/IMT">
  <rdfs:label>IMT</rdfs:label>
  <rdfs:comment>
    Instances of this class are the Internet media types
  </rdfs:comment>
  <rdf:type rdf:resource="http://purl.org/dc/terms/FormatScheme"/>
  <rdfs:isDefinedBy rdf:resource="http://purl.org/dc/terms/"/>
  <rdfs:seeAlso 
     rdf:resource="http://www.isi.edu/in-notes/iana/assignments/media-types/media-types"/>
</rdfs:Class>

2.3.11.2 Example: Usage of an IMT object as format.

A diagram of the use of an IMT object as format



<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:dcterms="http://purl.org/dc/terms/">

<rdf:Description>

<dcterms:medium>

<dcterms:IMT>

<rdf:value>text/html</rdf:value>

<rdfs:label>HTML</rdfs:label>

</dcterms:IMT>

</dcterms:medium>

</rdf:Description>

</rdf:RDF>

2.3.12 Type Schemes

DCMES Element	Element Refinement(s)	Element Encoding Scheme(s)
Type	-	DCMI Type Vocabulary

For each approved term given by the DCMI Type Vocabulary a RDFS class is defined in the RDF Schema for DCMI Type.

2.3.12.1 Example

(RDF/XML snip from the DC Terms RDF Schema:)

<!-- class of type classes -->

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
            xmlns:dc="http://purl.org/dc/elements/1.1/"
            xmlns:dcterms="http://purl.org/dc/terms/"
            xmlns:dctype="http://purl.org/dc/dcmitype/">

<rdfs:Class rdf:about="http://purl.org/dc/dcmitype/DCMIType">
  <rdfs:label>DCMI Type Vocabulary</rdfs:label>
  <rdfs:comment>
   The DCMI Type Vocabulary provides a general, cross-domain list of approved
   terms that may be used as values for the Resource Type element to identify
   the genre of a resource.
  </rdfs:comment>
  <rdf:type 
     rdf:resource="http://purl.org/dc/terms/TypeScheme"/>
  <rdfs:seeAlso 
     rdf:resource="http://dublincore.org/specifications/dublin-core/dcmi-type-vocabulary/"/>
  <rdfs:isDefinedBy 
     rdf:resource="http://purl.org/dc/dcmitype/"/>
</rdfs:Class>

<!-- Example: Image -->

<rdfs:Class rdf:about="http://purl.org/dc/dcmitype/Image">
  <rdfs:label>Image</rdfs:label>
  <rdfs:isDefinedBy 
      rdf:resource="http://purl.org/dc/dcmitype/"/>
  <rdfs:seeAlso 
      rdf:resource="http://dublincore.org/specifications/dublin-core/dcmi-type-vocabulary/"/>
  <rdfs:comment>
    An image is a primarily symbolic visual representation other than text. 
    For example - images and photographs of physical objects, paintings, 
    prints, drawings, other images and graphics, animations and moving 
    pictures, film, diagrams, maps, musical notation. Note that image may 
    include both electronic and physical representations.
  </rdfs:comment>
  <rdf:type rdf:resource="http://purl.org/dc/dcmitype/DCMIType"/>
</rdfs:Class>
</rdf:RDF>

2.3.12.2 Example: Usage of Image as type.

A diagram showing the use of Image as type



<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/"

xmlns:dctype="http://purl.org/dc/dcmitype/">

<dctype:Image>

<dc:creator>Carl</dc:creator>

</dctype:Image>

</rdf:RDF>

2.3.13 Date Schemes

DCMES Element	Element Refinement(s)	Element Encoding Scheme(s)
Date	Created Valid Available Issued Modified	DCMI Period W3C-DTF

For each DCMI recommended encoding scheme an RDFS class is defined by DC Terms RDF Schema.

2.3.13.1 Example

A diagram showing the use of date encoding schemes.

(RDF/XML snip from the DC Terms RDF Schema:)

<rdfs:Class rdf:about="http://purl.org/dc/terms/W3CDTF">
  <rdfs:label>W3C-DTF</rdfs:label>
  <rdfs:comment>Instances of this class are dates and times encoded with 
  the W3C Encoding rules - a profile based on ISO8601 </rdfs:comment>
  <rdf:type rdf:resource = "http://purl.org/dc/terms/DateScheme" />
  <rdfs:seeAlso rdf:resource = "http://www.w3.org/TR/NOTE-datetime" />
  <rdfs:isDefinedBy rdf:resource="http://purl.org/dc/terms/" /> 
</rdfs:Class>

2.3.13.2 Example: Usage of a W3C-DTF object as date.

An example of the use of a W3C-DTF object as date.

(RDF/XML snip from the DC Terms RDF Schema:)

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:dcterms="http://purl.org/dc/terms/">   
<rdf:Description>
 <dc:date>
   <dcterms:W3CDTF>
     <rdf:value>1999-09-25T14:20+10:00</rdf:value>
   </dcterms:W3CDTF>
 </dc:date> 
</rdf:Description>
</rdf:RDF>

2.3.14 Coverage Schemes

DCMES Element	Element Refinement(s)	Element Encoding Scheme(s)
Coverage	Spatial	DCMI Point ISO 3166 DCMI Box TGN
Coverage	Temporal	DCMI Period W3C-DTF

For each DCMI recommended encoding scheme an RDFS class is defined by DC Terms RDF Schema.

2.3.14.1 Example

(RDF/XML snip from the DC Terms RDF Schema:)

<rdfs:Class rdf:about="http://purl.org/dc/terms/Point">
  <rdfs:label>DCMI Point</rdfs:label>
  <rdfs:comment>
     DCMI Point is used for identifying a point in space using 
     its geographic coordinates
  </rdfs:comment>
  <rdf:type 
     rdf:resource="http://purl.org/dc/terms/SpatialScheme"/>
  <rdfs:seeAlso 
     rdf:resource="http://dublincore.org/specifications/dublin-core/dcmi-point/2000-07-28/"/>
  <rdfs:isDefinedBy 
     rdf:resource="http://purl.org/dc/terms/"/> 
</rdfs:Class>

2.3.14.2 Example using DCMI Point as coverage.

An example using DCMI Point as coverage.

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
        xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
        xmlns:dc="http://purl.org/dc/elements/1.1/"
        xmlns:dcterms="http://purl.org/dc/terms/">      
<rdf:Description>
<dc:coverage>
  <dcterms:Point>
    <rdfs:label>Perth</rdfs:label>
    <rdf:value>
    name=Perth, W.A.; east=115.85717; north=-31.95301
    </rdf:value>
  </dcterms:Point>
</dc:coverage> 
</rdf:Description>
</rdf:RDF>

3 DC in collaboration with other vocabulary and DumbDown

DC has proven to be able to interact with other vocabularies and community defined schemes. The following more or less well known example shows how it works with vCard. In view of the DumbDown which we will discuss in 3.2 one only has to ensure a useful label. This is particularly easy with vCard for it provides the full name of the person as literal value.

3.1 Example

3.1.1 Using vCard with Dublin Core™

A diagram showing the use of vCard with Dublin Core™

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
         xmlns:vCard = "http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf:Description> 
<dc:creator>              
 <rdf:Description rdf:about = "http://qqqfoo.com/staff/corky" >
  <rdfs:label> Corky Crystal </rdfs:label>
  <vCard:FN> Corky Crystal </vCard:FN>
  <vCard:N rdf:parseType="Resource">
    <vCard:Family> Crystal </vCard:Family>
    <vCard:Given> Corky </vCard:Given>
    <vCard:Other> Jacky </vCard:Other>
    <vCard:Prefix> Dr </vCard:Prefix>
  </vCard:N>
  <vCard:BDAY> 1980-01-01 </vCard:BDAY>
 </rdf:Description>
</dc:creator>
</rdf:Description> 
</rdf:RDF>

3.1.2 Math-Net

This is a more elaborate example that uses some vocabulary from Math-Net Schemes in addition to the vCard vocabulary. See section 3.2 how this metadata description is mapped to unqualified Dublin Core™ by the DumbDown algorithm.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rdf:RDF [
  <!ENTITY mnpns 'http://www.iwi-iuk.org/material/RDF/1.1/Schema/Property/mnp#'>
]>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 xmlns:rdfs="http://www.w3.org/1999/02/22-rdf-schema-ns#"
 xmlns:dc="http://purl.org/dc/elements/1.1/"
 xmlns:dcterms="http://purl.org/dc/terms/"
 xmlns:mnp="&mnpns;"
 xmlns:mn="http://www.iwi-iuk.org/material/RDF/1.1/Schema/Class/mn#"
 xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">

<!-- 
 subPropertyOf relations 
 encoded in the .../mnp# Namespace
-->

<rdf:Description 
    rdf:about="&mnpns;primarySubject">
  <rdfs:subPropertyOf 
    rdf:resource="http://purl.org/dc/elements/1.1/subject"/>
</rdf:Description>
<rdf:Description 
    rdf:about="&mnpns;secondarySubject">
  <rdfs:subPropertyOf 
    rdf:resource="http://purl.org/dc/elements/1.1/subject"/>
</rdf:Description>


<!-- An example file -->

<mn:Preprint>
 <dc:title>Algebra</dc:title>
 
 <dc:creator>
  <rdf:Bag>
   <rdf:li>
    <mn:Person>
     <vCard:FN>John Smith</vCard:FN>
     <rdfs:label>John Smith</rdfs:label>
     <vCard:EMAIL>[email protected]</vCard:EMAIL>
     <vCard:N rdf:parseType="Resource">
      <vCard:Family>Smith</vCard:Family>
      <vCard:Given>John</vCard:Given>
     </vCard:N>
    </mn:Person>
   </rdf:li>
  </rdf:Bag>
 </dc:creator>
 
 <dcterms:created>   
  <dcterms:W3CDTF>
     <rdf:value>1999-09-25</rdf:value>
     <rdfs:label>25 September 1999</rdfs:label>
  </dcterms:W3CDTF>
 </dcterms:created>
 
 <dc:identifier>
  <rdf:Alt>
    <rdf:li rdf:resource="http://www.math.org/doc.ps"/>
         <rdf:li rdf:resource="http://www.math.org/doc.html"/>
  </rdf:Alt>
 </dc:identifier>

 <mnp:primarySubject>
  <rdf:Description>
    <rdf:value>15-06</rdf:value>
    <rdfs:label>Proceedings, conferences, collections, etc. </rdfs:label>
    <rdfs:isDefinedBy rdf:resource="http://www.ams.org/index/mathweb/msc2000/"/>
  </rdf:Description>
 </mnp:primarySubject>

 <mnp:secondarySubject>
  <rdf:Description>
    <rdf:value>15A12</rdf:value>
    <rdfs:label>Conditioning of matrices</rdfs:label>
    <rdfs:isDefinedBy rdf:resource="http://www.ams.org/index/mathweb/msc2000/"/>
  </rdf:Description>
 </mnp:secondarySubject>

 <dcterms:abstract>An introduction to algebra</dcterms:abstract>
 
 <dc:subject>algebra, function, relation</dc:subject>

</mn:Preprint>

<!-- Formats -->

<rdf:Description rdf:about="http://www.math.org/doc.ps">
  <dc:format>
    <dcterms:IMT rdf:value="application/PostScript"
             rdfs:label="Postscript Document">
    </dcterms:IMT>
  </dc:format>
</rdf:Description>

<rdf:Description rdf:about="http://www.math.org/doc.html">
  <dc:format>
    <dcterms:IMT rdf:value="text/html"
             rdfs:label="HTML Document">
    </dcterms:IMT>
  </dc:format>
</rdf:Description>

<!-- /Formats -->

</rdf:RDF>

3.2 DumbDown

The goal of a DumbDown algorithm is to provide a useful approximation of RDF graphs extending qualified DC with other vocabularies by a set of unqualified DC hedgehogs. The algorithm is described below and extends the version originally given in the DC datamodel draft.

The algorithm gives preference to the linking of Dublin Core™ with other vocabulary by means of rdfs:label, rdf:value, (dc:title) and URI.

Particular emphasis is given to close approximation of the RDF/S concepts.

3.2.1 An Extended DumbDown algorithm

This algorithm creates from an arbitrary RDF graph containing Dublin Core™ elements (or subPropertiesOf Dublin Core™ elements) a (new) RDF graph whose arcs are all given by the 15 Dublin Core™ elements pointing to an 'appropriate literal'.

Suppose we have a property X which has been recognized as a subProperty of a DC15 element Y or is itself a DC15 element and

R --- X ---> N

is contained in the given RDF graph. (In particular the subPropertyOf relations mentioned in section 2.1.6 are recognized.)

The function dumbDownOf( Y ,N) described below returns a set n₁,...,n_k of 'appropriate literals' for this property. For each returned value n_i an arc

R --- Y --> n_i

starts at the resource R in the result graph.

dumbDownOf(dc:property,N):

  1. if the Node N is a literal we have unqualified Dublin Core™. Return the
     literal.
  2. else the Node N is a resource:
  
    2.1 if dc:property is in {dc:identifier,dc:source,dc:relation}
    
    /* In this case the algorithm should preferably calculate a URI */
    
    2.1.1 if N is a Bag or Sequence: return the literal that is
          calculated by dumbDown_Bag_Seq(dc:property,N).
    2.1.2 if N is an Alt: return the literals that are
          calculated by dumbDown_Alt(dc:property,N).
    2.1.3 if N is given a fully expanded URI return the string (literal) 
          given by the URI.
    2.1.4 if N has rdfs:label arcs: return the set of literals that are
          target of those arcs.
    2.1.5 if N has rdf:value arcs: return the union of sets of literals      
          calculated by dumbDown(dc:property,V) for every Node V that
          is target of an rdf:value arc.
    2.1.6 else: return empty set.
    
    2.2 else:
    
    2.2.1 if N has rdfs:label arcs: return the set of literals that are
          target of those arcs.
    2.2.2 if N has rdf:value arcs: return the union of sets of literals      
          calculated by dumbDown(dc:property,V) for every Node V that
          is target of an rdf:value arc.
    2.2.3 if N is a Bag or Sequence: return the literal that is
          calculated by dumbDown_Bag_Seq(dc:property,N).
    2.2.4 if N is an Alt: return the literals that are
          calculated by dumbDown_Alt(dc:property,N).
    2.2.5 if N has dc:title arcs:return the union of sets of literals      
          calculated by dumbDown(dc:property,V) for every Node V that
          is target of a dc:title arc.   
    2.2.6 if N is given a fully expanded URI return the string (literal) 
          given by the URI.
    2.2.7 else: return empty set.
    
Subroutines:

dumbDown_Bag_Seq(dc:property,N):
    Let N_1,...,N_n denote the elements of the container N. 
    Join the strings (literals) calculated by dumbDownOf(dc:propery,N_i)
    (for all elements) separated by "; ". Return *the* constructed string.

dumbDown_Alt(dc:property,N):
    Let N_1,...,N_n denote the elements of the container N. 
    Return the set of literals calculated by dumbDownOf(dc:propery,N_i)
    (for all elements).

This algorithm terminates.

3.2.2 Garbage collection

The result graph constructed by the DumbDown algorithm described in 3.2.1 may contain some useless information in terms of isolated subgraphs of the following form:

It is recommended to delete isolated arcs that start at an anonymous resource, are labeled with dc:type and have an rdfs:Class of the RDF Model and Syntax or the RDF Schema specification as target.

There might be further application specific requirements for refining the result graph of the DumbDown algorithm.

3.2.3

The Online Demo at http://zoe.mathematik.Uni-Osnabrueck.DE/dc/ already has 'recognized' the subPropertyOf relations in the DCQ namespace as proposed in (5.1).

3.2.4 Example

The example given in 3.1.2 results in the following DC15 description:

anonymous resource 1

Expressing Qualified Dublin core in RDF / XML

Expressing Qualified Dublin Core™ in RDF / XML

Table of Contents

0 Introduction

0.1 RDF(S) Basics

0.2 RDF(S) Specifics (1)

Basic Observation: DC Elements correspond to RDF properties.

1 Unqualified DC: The hedgehog model

1.1 Example

2 Qualified DC

2.1 Element Refinement

2.1.1 RDF(S) Specifics (2)

2.1.2 Example

2.1.3 Remark

2.1.4

2.1.5 Remark

2.1.5.1 RDF(S) Specifics (3)

2.1.5.2 Dublin Core™ Properties

2.1.5.3

2.1.5.4

2.1.5.5

2.2 Repeated Properties and ``MetaMetaData''

2.2.1 AND

2.2.2 Bag

2.2.3 Seq

2.2.4 Remark

2.2.5 Alt

2.2.6 Warning

2.2.7 Reification

2.3 Encoding Schemes

2.3.1 Poor Man's Structured Values

2.3.2 Remark: value/label game

2.3.4 Iterated value/label game

2.3.5 Remark

2.3.6 Remark

2.3.7 Remark

2.3.8 URI Identifier Scheme

2.3.8.1 Example

2.3.9 Subject Schemes

2.3.9.1 Example

2.3.9.2 Example: Usage of a MeSH object as subject.

2.3.10 Language Schemes

2.3.10.1 Example

2.3.10.2 Example: Usage of a RFC1766 object as language.

2.3.11 Format Schemes

2.3.11.1 Example

2.3.11.2 Example: Usage of an IMT object as format.

2.3.12 Type Schemes

2.3.12.1 Example

2.3.12.2 Example: Usage of Image as type.

2.3.13 Date Schemes

2.3.13.1 Example

2.3.13.2 Example: Usage of a W3C-DTF object as date.

2.3.14 Coverage Schemes

2.3.14.1 Example

2.3.14.2 Example using DCMI Point as coverage.

3 DC in collaboration with other vocabulary and DumbDown

3.1 Example

3.1.1 Using vCard with Dublin Core™

3.1.2 Math-Net

3.2 DumbDown

3.2.1 An Extended DumbDown algorithm

3.2.2 Garbage collection

3.2.3

3.2.4 Example

4 Language qualification

4.1 Example

4.1.1 Note

4.2 Poor mans language qualification

4.2.1 Example

4.3 Remark

5 Appendix

5.1 DC Terms RDF Schema Draft

5.2 DCMIType RDF Schema Draft

6 Appendix: Summary DC Qualifiers

Acknowledgements

References

Instruments

Requires

SeeAlso