- RDFValueStringsClarification

Note: The following text is retained here for historical purposes only. No further editing takes place here.

Clarification of the recommendations for encoding 'value strings' in DC RDF/XML

This document is currently under development. It is being worked on by the DCRDFTaskforce. Comments should be sent to the dc-rdf-taskforce@jiscmail.ac.uk mailing list.

Introduction

DCMI has two documents concerning the use of Dublin Core metadata in RDF/XML. The first, Expressing Simple Dublin Core in RDF/XML is a 'recommendation' and describes how to encode simple DC in RDF/XML. The second, Expressing Qualified Dublin Core in RDF/XML is a 'proposed recommendation' and describes how to encode qualified DC in RDF/XML.

More recently, the DC Architecture WG has developed the DCMI Abstract Model which provides a reference model against which particular DC encoding guidelines can be compared.

The Abstract Model defines a terminology that includes the following terms (the definitions are repeated here for clarity):

resource: A resource is 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, concepts and bound books in a library can also be considered resources.
resource URI: A resource URI is a URI that identifies a single resource.
property: A property is a specific aspect, characteristic, attribute, or relation used to describe resources.
property URI: A property URI is a URI that identifies a single property.
value: A value is the physical or conceptual entity that is associated with a property when it is used to describe a resource.
value URI: A value URI is a URI that identifies the value of a property.
value string: A value string is a simple string that represents the value of a property.

One issue with the two DCMI documents for encoding DC in RDF/XML is that they each recommend a different mechanism for encoding the value string that represents the value of a property. In the simple DC recommendation, a construct represented by the RDF graph in figure 1 is used. This construct uses a literal string as the value of the property. In the qualified DC proposed recommendation, a construct represented by the RDF graph in figure 2 is used. This construct represents the value of the property as an intermediate (often blank) node, allowing further properties to be used to describe the value resource, including a simple value string (using rdfs:label).


Figure 1	Figure 2

Clarification

The graphs in figures 1 and 2 say different things, both in terms of the RDF Model and in terms of the DCMI Abstract Model (DCAM).

In terms of the RDF Model, figure 1 says:

_:resource a:property "value string" .

i.e. some resource has a relationship of type indicated by the property a:property with the literal "value string".

In RDF, a literal is a resource: it's an instance of the class called =rdfs:Literal=. Furthermore, rdfs:Literal is a subclass of rdfs:Resource. (Note: this is also true of the DCAM - in the DCAM, literals are resources.) rdfs:Literal is a class; therefore rdfs:Literal is a vocabulary encoding scheme (or can be used as a vocabulary encoding scheme).

So in terms of the DCAM, figure 1 might be represented as

Description:
  Statement:
    Property URI: a:property
    Value String: "value string"
    Vocabulary Encoding Scheme URI: rdfs:Literal

In terms of the RDF Model, figure 2 says:

_:resource a:property _:x .
_:x rdfs:label "value string" .

i.e. some resource has a relationship of type indicated by the property a:property with a second resource and that second resource has an rdfs:label relationship with the literal "value string".

Assuming that the rdfs:label relationship maps to "is represented by value string" in the DCAM, then this maps to

Description:
  Statement:
    Property URI: a:property
    Value String: "value string"

in terms of the DCAM.

Note the difference from figure 1: the figure 1 example had a vocabulary encoding scheme URI of rdfs:Literal - the figure 2 example doesn't.

Of course, if the _:x object node is typed in the figure 2 example then the corresponding DCAM representation gets a vocabulary encoding scheme. For example:

_:resource a:property _:x .
_:x rdfs:label "value string" .
_:x a foaf:Person .

maps to:

Description:
  Statement:
    Property URI: a:property
    Value String: "value string"
    Vocabulary Encoding Scheme URI: foaf:Person

in terms of the DCAM.

Note that DCMI properties are not being treated in a special way here: this works for any RDF property a:property, and the DCAM representation is completely consistent with the RDF representation: figure 1 says the value is a resource of type rdfs:Literal; figure 2 says the value is an untyped resource.

Conclusion

This document shows that the two different constructs used in the current DCMI recommendation and draft recommendation for encoding simple and qualified DC in RDF/XML are consistent with the DCMI Abstract Model but that they make different assertions.

What are DC-aware applications allowed to do in terms of transforming graphs between these two forms? Can they transform in both directions, in one direction or in neither direction?

> RDFValueStringsClarification

Clarification of the recommendations for encoding 'value strings' in DC RDF/XML

Introduction

Clarification

Conclusion