Elements, Properties and Statements

Dublin Core elements and element refinements are properties. A property is "a specific aspect, characteristic, attribute, or relation used to describe resources". According to the DCMI Abstract Model, all these aspects, characteristics, attributes and relations" involve relationships between the subject resource and a second resource, a value [DCMIAM]. This means that a property is a type of relationship between two things.

A property is itself a resource, 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. Further, the persistence policies described in the Namespace Policy for the Dublin Core guarantee that that URI reference will always denote that same relationship type [DCMINS]. So, the assignment of a URIref means that other parties can use this unique identifier to refer to that relationship type, and the combination of its global uniqueness and persistence mean that the reference is unambiguous.

The URIref assigned to the property can be used in statements in Dublin Core metadata descriptions. According to the DCMI Abstract Model, a DC metadata description is a set of one or more statements about a single resource, and a statement is a two-part construct consisting of a reference to a property and a reference to a second resource, a value [DCMIAM]. The reference to the subject of the description is made by a URIref (the "resource URI"). The reference to a property also takes the form of a URIref (the "property URI"). The reference to the value may take various forms but for the purposes of this discussion, the examples show the simplest cases where that reference takes the form of a URIref (a "value URI") or a string (a "value string").

Each statement asserts that a relationship of the type indicated by the property exists between two resources: the resource that is the subject of the description, and the value (see note [1]:

Resource URIref	Statements
ex:book1	Property URIref Value URIref dc:subject ex:SemanticWeb

A property is a resource and may itself be described by a DC metadata description, in which case the URIref of the property appears as the "resource URI", and the property itself is part of a relationship whose type is denoted by another property URI:

Resource URIref	Statements
dc:subject	Property URIref Value String 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."

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 ... which shares the meaning of a particular DCMI Element but with narrower semantics.

So for example:

dcterms:created rdfs:subpropertyOf dc:date

The machine-processable schemas published by DCMI include descriptions of all DC elements and element refinements. When one property refines another, a statement is included in the description of the element refinement, in which the property URIref is the URIref of a property from the RDF Vocabulary Description Language (RDF Schema) [RDFS], 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

dcterms:created rdfs:subpropertyOf dc:date

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

Resource URIref	Statements
ex:book1	Property URIref Value String dcterms:created "1973-05-05"

then it is also true that

Resource URIref	Statements
ex:book1	Property URIref Value String dc:date "1973-05-05"

This outcome holds for all statements made using of the URIref of the element refinement as a property URIref: 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.

"To refine or not to refine"

If there is just one case where the inferred statement would be inappropriate, then the refinement/subPropertyOf relationship should not be asserted.

Consider, for example, the case of the properties marcrel:OWN ("The person or organization that currently owns an item or collection") and dc:contributor ("An entity responsible for making contributions to the content of the resource"). Both properties describe relationship types that relate a resource to an "entity", an agent capable of some action.

And for a specific resource, it may well be true that a single entity is both an owner of and a contributor to that resource. But that does not apply in all cases. i.e. there are some resources where the entity who is the owner has not made a contribution to the content of the resource: not all resource owners are resource contributors. If marcrel:owner was described as a refinement of dc:contributor, then that would mean that every statement using marcrel:OWN as a property URIref would result in a statement using dc:contributor as a property URIref, which would not be appropriate.

Note that the absence of a subproperty assertion in no way limits the capacity of the metadata author to say that, for any given resource, the same entity is both the owner and the contributor. The metadata author simply makes the two statements separately:

Resource URIref	Statements
ex:book1	Property URIref Value URIref dc:contributor ex:agent1 marcrel:OWN ex:agent1

A second example: dc:date is defined as "A date associated with an event in the life cycle of the resource". If an implementer uses a property exterms:updatingFrequency to indicate "The periodicity of modifications to the resource", and describes that property as an element refinement of dc:date, then statements such as the following might be inferred:

Resource URIref	Statements
ex:document1	Property URIref Value String dc:date "Monthly"

Resources which are appropriate values for statements using exterms:updatingFrequency are not appropriate values for statements using dc:date, so it is not appropriate to describe that property as an element refinement of dc:date.

Similarly, conisder dc:rights, defined as "Information about rights held in and over the resource". Suppose an implementer uses a property exterms:privacyIndicator to indicate whether a document should be publicly available or not, and specifies that Boolean (yes/no) values should be used. If that property is described as an element refinement of dc:rights, that would result in statements such as the following being inferred:

Resource URIref	Statements
ex:document1	Property URIref Value String dc:rights "Yes"

There may be an argument that strictly speaking a Boolean value does not contradict the definition of dc:rights, but it would be difficult to consider the value "Yes" to be "information about rights held in and over the resource". So, again, it is not appropriate to describe exterms:privacyIndicator as an element refinement of dc:rights, because of the statements that would be inferred.

"How many?" : Multiple Refinement Relationships

In the declarations that DCMI makes, any given property is the subject of only one rdfs:subPropertyOf relationship: a DC element refinement refines exactly one element. In principle, multiple assertions might be made, with the result that when the propert is used in a statement multiple additional relationships can be inferred to exist.

So if it is asserted that

exterms:bookDistributor rdfs:subpropertyOf exterms:distributor

and also

exterms:bookDistributor rdfs:subpropertyOf dc:publisher

and a statement is made using exterms:bookDistributor as a property URIref, e.g.

Resource URIref	Statements
ex:book1	Property URIref Value URIref exterms:bookDistributor ex:Company1

then the following two statements are also true:

Resource URIref	Statements
ex:book1	Property URIref Value URIref exterms:distributor ex:Company1 dc:publisher ex:Company1

Note that it is not a question of choosing one option over the other, or two applications behaving in different ways: both statements are implied in all cases, and as long as the two applications have "knowledge" of the two subproperty relations, they should both generate the same inferences.

"Who says so?": DCMI Namespaces and other Metadata Vocabularies

The capacity to assert the existence of rdfs:subPropertyOf relationships involving properties from the DCMI Namespaces is not limited to DCMI.

The publisher of another vocabulary may wish to declare that a property in that vocabulary is a subproperty of a property from the DCMI Namespaces, or even that a property from the DCMI Namespaces is a subproperty of a property from their vocabulary.

The MARC Relator Codes [MARCREL] provide a set of properties that can be used to assert relationships between resources and agents. It is useful that, where appropriate, subproperty relations between these properties and properties from the DCMI Namespaces are declared. e.g.

marcrel:ARR rdfs:subpropertyOf dc:contributor

(marcrel:ARR denotes a property which links a musical composition and its arranger.

With such information available, a Dublin Core application that encounters

Resource URIref	Statements
ex:music1	Property URIref Value URIref marcrel:ARR ex:person1

can derive the statement

Resource URIref	Statements
ex:music1	Property URIref Value URIref dc:contributor ex:person1

This means that an application that has no "prior knowledge" of marcrel:ARR, but which does derive the appropriate inferences from the assertion of the rdfs:subPropertyOf relationship, can make use of the dc:contributor> statement.

Finally, it should be noted that a subproperty assertion may be made by a third party who is not the owner/publisher of either of the properties involved. Suppose a metadata vocabulary has been constructed by a designer with no knowledge of the existence of Dublin Core. In their descriptions of their properties they have made no references to the notion that their property exterms:songwriter is related to dc:creator. If an implementer is working with both that metadata vocabulary and with the DCMI vocabularies, it may well be valuable for them to make a subproperty assertion:

exterms:songwriter rdfs:subpropertyOf dc:creator

so that, when their Dublin Core application encounters

Resource URIref	Statements
ex:music1	Property URIref Value URIref exterms:songwriter ex:person1

that application can derive the statement

Resource URIref	Statements
ex:music1	Property URIref Value URIref dc:creator ex:person1

Summary

• A declaration that one property refines, or is a subproperty of, a second property is an assertion of a specific type of relationship between the two properties.
• The meaning of the refinement/subproperty relationship is defined by the RDF Vocabulary Description Language (RDF Schema): the existence of a subproperty assertion states that all resources related by one property are also related by the other property.
• Refinement/subproperty relations may be asserted to exist between any two properties
• The existence of subproperty assertions enables an application to infer additional statements; this can be useful to an application encountering an "unknown" property
• A subproperty assertion is global: it applies to all occurrences of the property URIref in a statement; care should be taken not to assert subproperty relations where the inferences that may be drawn are incorrect or contradictory.
• A subproperty assertion is not a requirement for using a property from another vocabulary in Dublin Core metadata descriptions.
• Subproperty assertions may be made by the owner(s) of the properties or by a third party.