|The Metadata Community — Supporting Innovation in Metadata Design, Implementation & Best Practices|
Global navigation options:
|Is Replaced By:||http://dublincore.org/documents/2005/12/07/dc-elem-refine/|
|Status of Document:||This is a 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.|
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 in one of two ways. The description may use a URI to reference the subject resource explicitly (the "resource URI"). Alternately the subject of the description may be implicit, depending on the format and/or the context in which the description occurs: for example, for a DC metadata description embeddded in an XHTML document [DCHTML], that XHTML document is the subject of the description. For simplicity, the examples presented in this document reflect the case where a resource URI is provided.
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 ):
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
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
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].
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 (see note ).
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.
then it can be inferred that it is also true that
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.
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:
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:
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: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:
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.
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
exterms:bookDistributor rdfs:subPropertyOf dc:publisher
and a statement is made using
exterms:bookDistributor as a property URI, e.g.
then the following two statements are also true:
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.
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
can derive the statement
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
that application can derive the statement
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.
 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:
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.
 This document does not concern itself with the details of how an application obtains information about the existence of subproperty relationships. That information may be built into the application by its developer, or it may be obtained from some external data source. That source may be data made available by the owner/publisher of one of the properties, or it may be made available by a third party. Services such as metadata registries can act as a source of information about properties made available by many different agencies and indeed may use that aggregated data to provide functions based on inferencing about multiple subproperty relationships.
DCMI Abstract Model
Namespace Policy for the Dublin Core Metadata Initiative (DCMI)
Expressing Dublin Core in HTML/XHTML meta and link elements
MARC Code List: Part I: Relator Codes
RDF Vocabulary Description Language 1.0 (RDF Schema)
Copyright © 1995-2017 DCMI. All Rights Reserved.