Properties and Statements

Dublin Core elements and element refinements are properties. A property is a type of relationship between two things. A property is a "conceptual" resource. When DCMI adds an element or element refinement to one of its vocabularies (DCMI Namespaces), it creates a human-readable description of that relationship type, that concept, and it assigns a globally unique identifier to the property, in the form of a URI reference. The scope of URI references is global: the URI reference denotes that same relationship type, that same concept, wherever it is cited. And the persistence policies described in the Namespace Policy for the Dublin Core [1] guarantee that that URI reference will always denote that same relationship type.

The assignment of a URIref means that other parties can use this unique identifier to refer to that relationship type. It can be used in statements in Dublin Core metadata descriptions. DC metadata statements are three part constructs consisting of a subject, predicate and object. The predicate of the statement is the URIref of a property, and the subject and object are references to resources. Each statement asserts that a relationship of the type indicated by the property exists between two resources.

Subject	Predicate	Object
<http://example.org/book/1>	<http://purl.org/dc/elements/1.1/subject> dc:subject	<http://example.org/topics/SemanticWeb>

The URIref of a property might also be used as the subject of a statement (the "resource URI" in the terms of the Abstract Model [2], or the object of a statement (the "value URI") in which case the property itself is part of a relationship whose type is denoted by another property URI:

Subject	Predicate	Object
<http://purl.org/dc/elements/1.1/subject> dc:subject	<http://purl.org/dc/elements/1.1/description> dc:description	"Description may include but is not limited to: an abstract, table of contents, reference to a graphical representation of content or a free-text account of the content."
<http://purl.org/dc/terms/abstract> dcterms:abstract	<http://www.w3.org/2000/01/rdf-schema#subPropertyOf> rdfs:subPropertyOf	<http://purl.org/dc/elements/1.1/description> dc:description

Element Refinement

In addition to providing a definition and identifier for each of the properties it declares, DCMI also describes relationships between these properties. In particular it declares that some properties "refine" other properties. In the terms of the Grammatical Principles [3]

An Element Refinement is a property of a resource which shares the meaning of a particular DCMI Element but with narrower semantics.

So for example:

dcterms:created refines dc:date

The assertion that one property refines another is made using a statement in which the subject is the URIref of the element refinement, the object is the element, and the predicate is the URIref of a property from the RDF Vocabulary Description Language (RDF Schema) [4], rdfs:subPropertyOf. This states that a relationship exists between the two Dublin Core properties, and the nature of that relationship is defined by the RDFS concept rdfs:subPropertyOf. The RDFS specification explains that this has a very specific consequence:

The property rdfs:subPropertyOf is an instance of rdf:Property that is used to state that all resources related by one property are also related by another.

So if it is asserted that

Subject	Predicate	Object
<http://purl.org/dc/terms/created> dcterms:created	<http://www.w3.org/2000/01/rdf-schema#subPropertyOf> rdfs:subPropertyOf	<http://purl.org/dc/elements/1.1/date> dc:date

and a statement is made using dcterms:created as a predicate, e.g.

Subject	Predicate	Object
<http://example.org/book/1>	<http://purl.org/dc/terms/created> dcterms:created	"1973-05-05"

then it is also true that

Subject	Predicate	Object
<http://example.org/book/1>	<http://purl.org/dc/elements/1.1/date> dc:date	"1973-05-05"

This outcome holds for all occurrences of the element refinement as a predicate: whenever two resources are related by the element refinement, they are also related by the element. So an assertion that one element refines another - that an rdfs:subPropertyOf relationship exists between the properties - should be made only when the definitions of the properties are such that that is a desirable outcome.

If there is just one example where the inferred second statement results in a contradiction, then the refinement/subPropertyOf relationship should not be asserted. Consider, for example, the case of dc:publisher ("An entity responsible for making the resource available") and dc:contributor ("An entity responsible for making contributions to the content of the resource"). For an individual resource, it may well be true that a single entity is both the publisher and the contributor, but that does not apply in all cases. i.e. There is a set of other resources where the publisher has not made a contribution to the content of the resource. If dc:publisher was described as a refinement of dc:contributor, then that would mean that every statement using dc:publisher as a predicate would result in a statement using dc:contributor as a predicate, which is not a desirable outcome.

When no subproperty assertion is made, it is still possible to state that for any given resource, the same entity is both the publisher and the contributor:

Subject	Predicate	Object
<http://example.org/doc/1>	<http://purl.org/dc/elements/1.1/publisher> dc:publisher	<http://example.org/
<http://example.org/doc/1>	<http://purl.org/dc/elements/1.1/contributor> dc:contributor	<http://example.org/

In the declarations that DCMI makes, for any given property, they assert only one rdfs:subPropertyOf relationship. In principle, multiple assertions might be made, with the result that multiple additional relationships can be inferred to exist also.

So if it is asserted that

Subject	Predicate	Object
<http://purl.org/dc/terms/created> dcterms:created	<http://www.w3.org/2000/01/rdf-schema#subPropertyOf> rdfs:subPropertyOf	<http://purl.org/dc/elements/1.1/date> dc:date
<http://purl.org/dc/terms/created> dcterms:created	<http://www.w3.org/2000/01/rdf-schema#subPropertyOf> rdfs:subPropertyOf	<http://purl.org/my/terms/pointInTime> my:pointInTime

and a statement is made using dcterms:created as a predicate, e.g.

Subject	Predicate	Object
<http://example.org/book/1>	<http://purl.org/dc/terms/created> dcterms:created	"1973-05-05"

then it is also true that

Subject	Predicate	Object
<http://example.org/book/1>	<http://purl.org/dc/elements/1.1/date> dc:date	"1973-05-05"
<http://example.org/book/1>	<http://purl.org/my/terms/pointInTime> my:pointInTime	"1973-05-05"

DCMI Namespaces and other Metadata Vocabularies

The capacity to assert the existence of rdfs:subPropertyOf relationships is not limited to the publisher of a metadata vocabulary. The publisher of another vocabulary may wish to declare that a property in that vocabulary is a sub-property of a property from the DCMI Namespaces, or even that a property from the DCMI Namespaces is a sub-property of a property from their vocabulary.

The MARC Relator Codes [5] provide a set of properties that can be used to assert relationships between resources and agents. It is useful that, where appropriate, sub-property relations between these properties and properties from the DCMI Namespaces are declared. With such information available, a Dublin Core application that encounters

can derive the statement

Summary

• A declaration that one property refines, or is a sub-property of, a second property is an assertion of a specific type of relationship between the two properties.
• Refinement/sub-property relations may be asserted to exist between any two properties
• The meaning of the refinement/sub-property relationship is defined by the RDF Vocabulary Description Language (RDF Schema): the existence of a sub-property assertion states that all resources related by one property are also related by the other property.
• The existence of sub-property assertions enables an application to infer additional statements; this can be useful to an application encountering an "unknown" property
• A sub-property assertion is global: it applies to all occurrences of the property as the predicate of a statement; care should be taken not to assert sub-property relations where the inferences that may be drawn are incorrect or contradictory.
• Where no sub-property relation is asserted, it is still possible to use two properties as predicates of statements about a resource to assert that that resource has two different types of relation with a second resource.
• A sub-property assertion is not a requirement for using a property from another vocabulary in Dublin Core metadata descriptions.

References

[1]  Powell, Andy and Harry Wagner. Namespace Policy for the Dublin Core Metadata Initiative (DCMI), (November 2001)
http://dublincore.org/documents/dcmi-namespace/