Element Refinement in Dublin Core™ Metadata
| Creator: | Pete Johnston |
|---|---|
| Date Issued: | 2005-04-11 |
| Identifier: | http://dublincore.org/specifications/dublin-core/dc-elem-refine/2005-04-11/ |
| Replaces: | http://dublincore.org/specifications/dublin-core/dc-elem-refine/2005-01-23/ |
| Is Replaced By: | http://dublincore.org/specifications/dublin-core/dc-elem-refine/2005-06-13/ |
| Latest Version: | http://dublincore.org/specifications/dublin-core/dc-elem-refine/ |
| Status of Document: | This is a draft DCMI Recommended Resource. |
| Description: | This document describes the concept of "element refinement" as used in Dublin Core™ metadata. It seeks to explain the consequences of stating that one property "refines" a second property. The purpose is to clarify that in some cases it may be appropriate and useful to make such an assertion and in other cases such an assertion may result in contradictions. |
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 resources [DCMIAM]. Each property corresponds to a type of relationship, such as the notion that a resource "is created by" an agent (the agent is a second resource), or that a resource "is about the subject of" some concept (the concept is also a resource).
A property is itself a resource, a "conceptual" resource. When DCMI adds a property to one of its "DCMI Namespaces", it creates a human-readable description of that concept, and it assigns a globally unique identifier to the property, in the form of a URI.
The scope of URIs is global: the URI is used as if it denotes that same concept, that same relationship type, wherever it is cited. Further, the persistence policies described in the Namespace Policy for the Dublin Core guarantee that the URIs DCMI assigns to its properties will always denote that same essential concept [DCMINS]. So, the assignment of a URI means that other parties can use this unique identifier, and the combination of its global uniqueness and persistence mean that the reference is unambiguous.
The URI 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 URI (the "resource URI"). The reference to a property also takes the form of a URI (the "property URI"). The reference to the value may take the form of a URI or a "value representation". For the purposes of this discussion, the examples show the simplest cases where that reference takes the form of a URI (a "value URI") or a representation in the form of 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 URI | Statements | ||||
|---|---|---|---|---|---|
ex:book1 |
|
Element Refinement
In addition to providing a definition and identifier for each of the properties it declares, DCMI also describes relationships between these properties. If the definitions of two properties are such that whenever two resources are related by the first property they are also related by the second property, the first property is said to "refine", or to be a "refinement" of, the second property.
So for example, the definition of the property dcterms:created is "Date of creation of the resource", and the definition of the property dc:date is "A date associated with an event in the life cycle of the resource". The date of creation of a resource is always "a date associated with an event in the lifecycle of the resource", so the dcterms:created property refines the dc:date property.
The machine-processable schemas published by DCMI include descriptions of all DC elements and element refinements. In the description of an element refinement, a statement is included using the property URI rdfs:subPropertyOf from the RDF Vocabulary Description Language (RDF Schema) [RDFS]. This states that a relationship exists between two properties, and the nature of that relationship is defined by the RDFS concept rdfs:subPropertyOf:
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 [RDFS].
This rdfs:subPropertyOf assertion enables a human reader or a software application to infer new information when they encounter a statement made using the "refinement" or subproperty.
So if it is asserted that
dcterms:created rdfs:subPropertyOf dc:date
and a statement is made using dcterms:created as a property URI, e.g.
| Resource URI | Statements | ||||
|---|---|---|---|---|---|
ex:book1 |
|
then it can be inferred that it is also true that
| Resource URI | Statements | ||||
|---|---|---|---|---|---|
ex:book1 |
|
This outcome holds for all statements made using the URI of the element refinement as a property URI: whenever two resources are related by the element refinement, they are also related by the corresponding 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 support that conclusion.
"To refine or not to refine"
If there is just one case where the inferred statement would not be true, 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. (The marcrel:OWN property is part of a set of properties defined by the Library of Congress, based on the MARC Relator Codes [MARCREL].)
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 of the resource has not made a contribution to the content of the resource: not all resource owners are resource contributors. If marcrel:OWN was described as a refinement of dc:contributor, then that would mean that every statement using marcrel:OWN as a property URI would result in a statement using dc:contributor as a property URI, which would not be desirable.
Note also 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 URI | Statements | ||||||
|---|---|---|---|---|---|---|---|
ex:book1 |
|
As a second example, consider the case of dc:date, 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 URI | Statements | ||||
|---|---|---|---|---|---|
ex:document1 |
|
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, consider 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 URI | Statements | ||||
|---|---|---|---|---|---|
ex:document1 |
|
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 - though an element may be refined by multiple element refinements.
However, in principle, multiple assertions might be made, with the result that when the property 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 URI, e.g.
| Resource URI | Statements | ||||
|---|---|---|---|---|---|
ex:book1 |
|
then the following two statements are also true:
| Resource URI | Statements | ||||||
|---|---|---|---|---|---|---|---|
ex:book1 |
|
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 Library of Congress defines a set of properties based on the MARC Relator Codes [MARCREL], 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 URI | Statements | ||||
|---|---|---|---|---|---|
ex:music1 |
|
can derive the statement
| Resource URI | Statements | ||||
|---|---|---|---|---|---|
ex:music1 |
|
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. Such a process enhances interoperability between metadata applications.
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 be useful for them to make a subproperty assertion:
exterms:songwriter rdfs:subPropertyOf dc:creator
so that, when their Dublin Core™ application encounters
| Resource URI | Statements | ||||
|---|---|---|---|---|---|
ex:music1 |
|
that application can derive the statement
| Resource URI | Statements | ||||
|---|---|---|---|---|---|
ex:music1 |
|
Finally, it should be re-emphasised that the existence of a subproperty relationship with a DC property is not a requirement for the use of properties from other metadata vocabularies in DC metadata. In the case of the MARC Relator properties, a subproperty relation may exist in many cases, but those properties for which no such relation exists, such as the owner property marcrel:OWN, can still be deployed in statements in DC metadata descriptions.
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 second property.
- A subproperty assertion is global : it applies to all occurrences of the property URI in a statement; care should be taken not to assert subproperty relations where the inferences that may be drawn are incorrect or contradictory.
- Refinement/subproperty relations may be asserted to exist between any two properties.
- A property may be the subject of multiple refinement/subproperty relations.
- The existence of subproperty assertions about a property enables an application to infer additional statements from statements made using that property; the availability of subproperty assertions supports semantic interoperability between applications
- 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.
Notes
[1] For the sake of brevity, in the examples, URIs are represented by Qualified Names. Prefixes are assumed to be associated with Namespace Names as follows:
- dc:
http://purl.org/dc/elements/1.1/ - dcterms:
http://purl.org/dc/terms/ - dcmitype:
http://purl.org/dc/dcmitype/ - marcrel:
http://www.loc.gov/marc.relators/ - rdf:
http://www.w3.org/1999/02/22-rdf-syntax-ns# - rdfs:
http://www.w3.org/2000/01/rdf-schema# - exterms:
http://example.org/terms/ - ex:
http://example.org/things/
N.B. At the time of writing, the URIs to be assigned to the MARC Relator properties are still under discussion. The URIs used here are provisional, and should not be cited without first checking the Library of Congress Web site for the authoritative identifiers of the properties.
References
[DCMIAM]
DCMI Abstract Model
http://www.ukoln.ac.uk/metadata/dcmi/abstract-model/
[DCMINS]
Namespace Policy for the Dublin Core™ Metadata Initiative (DCMI)
http://dublincore.org/specifications/dublin-core/dcmi-namespace/
[MARCREL]
MARC Code List: Part I: Relator Codes
http://www.loc.gov/marc/relators/relators.html
[RDFS]
RDF Vocabulary Description Language 1.0 (RDF Schema)
http://www.w3.org/TR/rdf-schema/