DCMI: DCMI Abstract Model

Creator:	Andy Powell Eduserv Foundation, UK
Creator:	Mikael Nilsson KMR Group, CID, NADA, KTH (Royal Institute of Technology), Sweden
Creator:	Ambjörn Naeve KMR Group, CID, NADA, KTH (Royal Institute of Technology), Sweden
Creator:	Pete Johnston Eduserv Foundation, UK
Creator:	Thomas Baker DCMI
Date Issued:	2007-06-04
Identifier:	//www.voudr.com/specifications/dublin-core/abstract-model/2007-06-04/
Replaces:	//www.voudr.com/specifications/dublin-core/abstract-model/2005-03-07/
Replaces:	//www.voudr.com/specifications/dublin-core/abstract-model/2007-04-02/
Is Replaced By:	Not applicable
Latest Version:	//www.voudr.com/specifications/dublin-core/abstract-model/
Status of Document:	This is a DCMIRecommendation
Description of Document:	This document describes an abstract model for Dublin Core™ metadata.

Introduction
DCMI Abstract Model
Descriptions, description sets and records
Values
DCMI Abstract Model semantics
Encoding guidelines
Terminology
Appendix A - Relationship to legacy DCMI Grammatical Principles
References
Acknowledgements

1. Introduction

这个文档指定为Dubl抽象模型in Core™ metadata. The primary purpose of this document is to specify the components and constructs used in Dublin Core™ metadata. It defines the nature of the components used and describes how those components are combined to create information structures. It provides an information model which is independent of any particular encoding syntax. Such an information model allows us to gain a better understanding of the kinds of descriptions that we are encoding and facilitates the development of better mappings and cross-syntax translations.

This document is primarily aimed at the developers of software applications that support Dublin Core™ metadata, people involved in developing new syntax encoding guidelines for Dublin Core™ metadata and people developing metadata application profiles based on DCMI vocabularies or on other compatible vocabularies.

The DCMI Abstract Model builds on work undertaken by the World Wide Web Consortium (W3C) on the Resource Description Framework (RDF) [RDF, RDFS]. The use of concepts from RDF is summarized below in Section 5.

The DCMI Abstract Model is represented here using UML class diagrams [UML]. Readers that are not familiar with UML class diagrams should note that lines ending in a block-arrow should be read as 'is' or 'is a' (for example, "avalueis aresource") and that lines starting with a block-diamond should be read as 'contains a' or 'has a' (for example, "astatementcontains aproperty URI"). Other relationships are labeled appropriately. In this document, words and phrases in italics are defined in Section 7, Terminology.

2. DCMI Abstract Model

2.1 The DCMI Resource Model

The abstract model of theresourcesdescribed bydescriptionsis as follows:

Eachdescribed resourceis described using one or moreproperty-value pairs.
Eachproperty-value pairis made up of onepropertyand onevalue.
Eachvalueis aresource- the physical, digital or conceptual entity orliteralthat is associated with apropertywhen aproperty-value pairis used to describe aresource. Therefore, eachvalueis either aliteral valueor anon-literal value:
- Aliteral valueis avaluewhich is aliteral.
- Anon-literal valueis avaluewhich is a physical, digital or conceptual entity.
Aliteralis an entity which uses a Unicode string as a lexical form, together with an optional language tag or datatype, to denote aresource(i.e. "literal" as defined by RDF [RDF]).

**Figure 1 - the DCMI resource model**

2.2 The DCMI Description Set Model

The abstract model of DC metadatadescription setsis as follows:

Adescription setis a set of one or moredescriptions, each of which describes a singleresource.
Adescriptionis made up of one or morestatements(about one, and only one,resource) and zero or onedescribed resource URI(aURIthat identifies thedescribed resource).
Eachstatementinstantiates aproperty-value pair, and is made up of aproperty URI(aURIthat identifies aproperty) and avalue surrogate.
Avalue surrogateis either aliteral value surrogateor anon-literal value surrogate:
- Aliteral value surrogateis avalue surrogatefor aliteral value, and is made up of exactly onevalue string. Thevalue stringis aliteralwhich encodes theliteral value.
- Anon-literal value surrogateis avalue surrogatefor anon-literal value, and is made up of zero or onevalue URI(aURIthat identifies thenon-literal valueassociated with theproperty), zero or onevocabulary encoding scheme URI(aURIthat identifies thevocabulary encoding schemeof which thenon-literal valueis a member), and zero or morevalue strings. Eachvalue stringis aliteralwhich represents thenon-literal value.
Avalue stringis either aplain value stringor atyped value string
- Aplain value stringmay have an associatedvalue string languagethat is an ISO language tag (for example en-GB).Plain value stringsare intended to be human-readable.
- Atyped value stringhas an associatedsyntax encoding scheme URIthat identifies asyntax encoding scheme.

**Figure 2 - the DCMI description set model**

2.3 The DCMI Vocabulary Model

The abstract model of thevocabulariesused in DC metadatadescriptionsis as follows:

Avocabularyis a set of one or moreterms. Eachtermis a member of one or morevocabularies.
Atermis aproperty(element),class,vocabulary encoding scheme, orsyntax encoding scheme.
Eachpropertymay be related to one or moreclassesby ahas domainrelationship. Where it is stated that apropertyhas such a relationship with aclassand thepropertyis part of aproperty/value pair, it follows that thedescribed resourceis an instance of thatclass.
Eachpropertymay be related to one or moreclassesby ahas rangerelationship. Where it is stated that apropertyhas such a relationship with aclassand thepropertyis part of aproperty/value pair, it follows that thevalueis an instance of thatclass.
Eachresourcemay be aninstance ofone or moreclasses.
Eachresourcemay be amember ofone or morevocabulary encoding schemes.
Eachclassmay be related to one or more otherclassesby asub-class ofrelationship (where the twoclassesare defined such that allresourcesthat are instances of the sub-class are also instances of the relatedclass).
Eachpropertymay be related to one or more otherpropertiesby asub-property ofrelationship. Where it is stated that such a relationship exists, the twopropertiesare defined such that whenever thesub-propertyis part of aproperty/value pairdescribing aresource, it follows that theresourceis also described using a secondproperty/value pairmade up of thepropertyand thevalue.
Eachsyntax encoding schemeis aclass(ofliterals).

Note that the word "vocabulary" is used here to refer specifically to a set ofterms, a set in which the members areproperties(elements),classes,vocabulary encoding schemes, and/orsyntax encoding schemes.

**Figure 3 - the DCMI vocabulary model**

2.4 Notes

A number of things about the model are worth noting:

Eachnon-literal valuemay be thedescribed resourcein a separatedescriptionwithin the same description set - for example, a separatedescriptionmay provide metadata about the person that is the creator of thedescribed resource. Aliteral valuecan not be thedescribed resourcein a separatedescription.
The DCMI description set model does not provide an explicit mechanism for indicating theclassesof thedescribed resource.Classesof thedescribed resourcecan either be indicated explicitly using one or morestatementsin thedescriptionor be inferred from thedomainsof thepropertiesused in thedescription.
The DCMI description set model indicates the distinction betweenliteral valuesandnon-literal valuesthrough the presence in astatementof aliteral value surrogateor anon-literal value surrogate. For anon-literal value, the DCMI description set model does not provide an explicit mechanism for indicating further theclassesof thevalue. Classes of any givennon-literal valuecan either be indicated explicitly using one or morestatementsin a separatedescriptionabout thatvalueor be inferred from therangeof theproperty. For aliteral value, theclassesof thevaluecan either be indicated explicitly using asyntax encoding schemeof thevalue stringor be inferred from therangeof theproperty.
XML content in avalue stringis indicated using atyped value stringwith asyntax encoding scheme URIofhttp://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral.

3. Descriptions, description sets and records

The abstract model presented above indicates that each DC metadatadescriptiondescribes one, and only one,resource. This is commonly referred to as the one-to-one principle.

However, real-world metadata applications tend to be based on loosely grouped sets ofdescriptions(where thedescribed resourcesare typically related in some way), known here asdescription sets. For example, adescription setmight comprisedescriptionsof both a painting and the artist. Furthermore, it is often the case that adescription setwill also contain adescriptionabout thedescription setitself (sometimes referred to as 'admin metadata' or 'meta-metadata').

Description setsare instantiated, for the purposes of exchange between software applications, in the form of metadatarecords, according to one of the DCMI encoding guidelines (for example, XHTML meta tags, XML and RDF/XML) [DCMI-ENCODINGS].

4. Values

A DC metadatavalueis the physical, digital, or conceptual entity orliteralthat is associated with apropertywhen aproperty-value pairis used to describe aresource. For example, avalueassociated with the Dublin Core™ Creatorpropertyis a person, organization or service - a physical entity. Avalueassociated with the Dublin Core™ Datepropertyis a point (or range) in time - a conceptual entity. Avalueassociated with the Dublin Core™ Coveragepropertyis a geographic region or country - a physical entity. Avalueassociated with the Dublin Core™ Subjectpropertyis a concept (a conceptual entity) or a physical object or person (a physical entity). Avalueassociated with the FOAF namepropertyis aliteral. Each of these entities is aresource.

5. DCMI Abstract Model semantics

Note that this Recommendation does not explicitly define a formal semantics for the DCMI Abstract Model. The intention is that the formal semantics can be defined by reference to the RDF and RDF Schema semantics, as defined in [RDFMT]. The equivalence between some of the notions in the DCMI Abstract Model and the corresponding RDF notions is given in the following table:

DCMI Abstract Model	RDF/RDFS
resource	Class:http://www.w3.org/2000/01/rdf-schema#Resource
propertyorelement	Class:http://www.w3.org/1999/02/22-rdf-syntax-ns#Property
class	Class:http://www.w3.org/2000/01/rdf-schema#Class
syntax encoding scheme	Class:http://www.w3.org/2000/01/rdf-schema#Datatype
has domainrelationship	Property:http://www.w3.org/2000/01/rdf-schema#domain
has rangerelationship	Property:http://www.w3.org/2000/01/rdf-schema#range
sub-property ofrelationship	Property:http://www.w3.org/2000/01/rdf-schema#subPropertyOf
sub-class ofrelationship	Property:http://www.w3.org/2000/01/rdf-schema#subClassOf
plain value string	Plain literal. See:http://www.w3.org/TR/rdf-concepts/#dfn-plain-literal
typed value string	Typed literal. See:http://www.w3.org/TR/rdf-concepts/#dfn-typed-literal

Table 1 - DCMI Abstract Model semantics

DCMI推荐”表达Dublin Core™ using the Resource Description Framework (RDF)" [DCRDF], these equivalences form the basis of the formal semantics of the DCMI Abstract Model. However, the details of such a semantics is outside the scope of this Recommendation.

6. Encoding guidelines

Particular encoding guidelines (HTML meta tags, XML, RDF/XML, etc.) [DCMI-ENCODINGS] do not need to encode all aspects of the abstract model described above. However, they should refer to the DCMI Abstract Model and indicate which parts of the model are encoded and which are not.

Encoding guidelines should indicate how anon-literal valuecan be treated as adescribed resourcein a separatedescriptionin those cases where anon-literal value surrogatedoes not include avalue URI.

7. Terminology

This document uses the following terms:

class(http://www.w3.org/2000/01/rdf-schema#Class): A group containing members that have attributes, behaviours, relationships or semantics in common; a kind of category.
described resource: Aresourcethat is described by adescription.
described resource URI: AURIthat identifies thedescribed resource.
description: One or morestatementsabout one, and only one,resource.
description set: A set of one or moredescriptions, each of which describes a singleresource.
element(http://www.w3.org/1999/02/22-rdf-syntax-ns#Property): A synonym forproperty. It should be noted that the word element is also commonly used to refer to a structural markup component within an XML document.
has domain(http://www.w3.org/2000/01/rdf-schema#domain): A relationship between apropertyand aclasswhich indicates that if thepropertyis part of aproperty/value pair, then it follows that thedescribed resourceis an instance of thatclass.
has range(http://www.w3.org/2000/01/rdf-schema#range): A relationship between apropertyand aclasswhich indicates that if thepropertyis part of aproperty/value pair, then it follows that thevalueis an instance of thatclass.
instance of: A relationship between aresourceand aclasswhich indicates aclassof which theresourceis an instance.
literal: An entity which uses a Unicode string as a lexical form, together with an optional language tag or datatype, to denote aresource(i.e. "literal" as defined by RDF [RDF].
literal value: Avaluewhich is aliteral.
literal value surrogate: Avalue surrogatefor aliteral value, made up of exactly onevalue string(aliteralthat encodes thevalue).
member of(http://purl.org/dc/dcam/memberOf): A relationship between aresourceand avocabulary encoding schemewhich indicates that theresourceis a member of a set.
non-literal value: Avaluewhich is a physical, digital or conceptual entity.
non-literal value surrogate: Avalue surrogatefor anon-literal value, made up of aproperty URI(aURIthat identifies aproperty), zero or onevalue URI(aURIthat identifies thenon-literal valueassociated with theproperty), zero or onevocabulary encoding scheme URI(aURIthat identifies thevocabulary encoding schemeof which thevalueis a member), and zero or morevalue strings(literalsthat represent thevalue).
plain value string: Avalue stringwithout an associatedsyntax encoding scheme URI.
property(http://www.w3.org/1999/02/22-rdf-syntax-ns#Property): A specific aspect, characteristic, attribute, or relation used to describeresources.
property URI: AURIthat identifies a singleproperty.
property/value pair: The combination of apropertyand avalue, used to describe a characteristic of aresource.
record: An instantiation of adescription set, created according to one of the DCMI encoding guidelines (for example, XHTML meta tags, XML and RDF/XML).
resource(http://www.w3.org/2000/01/rdf-schema#Resource): Anything that might be identified. Familiar examples include an electronic document, an image, a service (for example, "today's weather report for Los Angeles"), and a collection of otherresources. Not allresourcesare network "retrievable"; for example, human beings, corporations, concepts and bound books in a library can also be consideredresources.
statement: An instantiation of aproperty-value pairmade up of aproperty URI(aURIthat identifies aproperty) and avalue surrogate.
sub-class of(http://www.w3.org/2000/01/rdf-schema#subClassOf): A relationship between twoclasseswhich indicates that the twoclassesare defined such that allresourcesthat are instances of the sub-classare also instances of the relatedclass).
sub-property of(http://www.w3.org/2000/01/rdf-schema#SubPropertyOf): A relationship between twopropertieswhich indicates that the twopropertiesare defined such that wheneverthe sub-propertyis part of aproperty/value pairdescribing aresource, it follows that the resource is also described using a secondproperty/value pairmade up of thepropertyand thevalue.
syntax encoding scheme(http://www.w3.org/2000/01/rdf-schema#Datatype): A set of strings and an associated set of rules that describe a mapping between that set of strings and a set ofresources. The mapping rules may define how the string is structured (for example DCMI Box) or they may simply enumerate all the strings and the corresponding resources (for example ISO 3166).
syntax encoding scheme URI: AURIthat identifies asyntax encoding scheme.
term: Aproperty(element),class,vocabulary encoding scheme, orsyntax encoding scheme.
typed value string: Avalue stringwith an associatedsyntax encoding scheme URI.
URI: A Uniform Resource Identifier [URI] or Internationalized Resource Identifier [IRI]. From the perspective of the DCMI Abstract Model, equivalence of URIs is defined as in RDF [RDF].
value: The physical entity, conceptual entity orliteral(aresource) that is associated with apropertywhen aproperty-value pairis used to describe aresource.
value URI: AURIthat identifies thevalue.
value string: Aliteral, optionally associated with either asyntax encoding scheme URIor avalue string language. In aliteral value surrogateavalue stringencodes thevalue; in anon-literal value surrogateavalue stringrepresents thevalue.
value string language: An ISO language tag that indicates the language of thevalue string.
value surrogate: Aliteral value surrogateor anon-literal value surrogate.
vocabulary: A set of one or moreterms.
vocabulary encoding scheme(http://purl.org/dc/dcam/VocabularyEncodingScheme): An enumerated set ofresources.
vocabulary encoding scheme URI: AURIthat identifies avocabulary encoding scheme.

Appendix A - Relationship to legacy DCMI Grammatical Principles

The underlying model for Dublin Core™ metadata has evolved since first formalisms were proposed in the late 1990s. The following table presents rough terminological equivalences between earlier versions of DCMIgrammatical principles[DCMI-GRAM-PRIN] and the current DCMI Abstract Model.

DCMI Grammatical Principles	DCMI Abstract Model
vocabulary term	resource
element	propertyorelement
element refinement	propertywithsub-property ofrelation
encoding scheme	syntax encoding schemeorvocabulary encoding scheme
syntax encoding scheme	syntax encoding scheme
qualifier	propertywithsub-property ofrelation,syntax encoding scheme, orvocabulary encoding scheme
vocabulary encoding scheme	vocabulary encoding scheme

Table 2 - DCMI Grammatical Principles and DCMI Abstract Model

References

[DCMI]
Dublin Core™ Metadata Initiative
<//www.voudr.com/>

[DCMI-GRAM-PRIN]
DCMI Usage Board. DCMI Grammatical Principles. November 2003.
<//www.voudr.com/specifications/dublin-core/grammatical-principles/>

[DCMI-ENCODINGS]
DCMI Encoding Guidelines
<//www.voudr.com/schemas/>

[DCRDF]
Nilsson, Mikael, Andy Powell, Pete Johnston, and Ambjörn Naeve. Expressing Dublin Core™ metadata using the Resource Description Framework (RDF). DCMI Proposed Recommendation. April 2007.
<//www.voudr.com/specifications/dublin-core/dc-rdf/>

[IRI]
Duerst, M., M. Suignard. RFC 3987: Internationalized Resource Identifiers (IRIs). Internet Engineering Task Force (IETF). January 2005.
<http://www.ietf.org/rfc/rfc3987.txt>

[RDF]
Klyne, Graham and Jeremy Carroll, editors. Resource Description Framework: Concepts and Abstract Syntax. W3C Recommendation. 10 February 2004.
<http://www.w3.org/TR/rdf-concepts/>

[RDFMT]
海斯,帕特里克,编辑器。RDF语义。W3C Recommendation. 10 February 2004.
<http://www.w3.org/TR/rdf-mt/>

[RDFS]
Brickley, Dan and R.V. Guha, editors. RDF Vocabulary Description Language 1.0: RDF Schema. W3C Recommendation. 10 February 2004.
<http://www.w3.org/TR/rdf-schema/>

[UML]
Booch, Grady, James Rumbaugh and Ivar Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 1998.

[URI]
Berners-Lee, T., R. Fielding, L. Masinter. RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. Internet Engineering Task Force (IETF). January 2005.
<http://www.ietf.org/rfc/rfc3986.txt>

Acknowledgements

Thanks to Dan Brickley, Rachel Heery, Alistair Miles, Sarah Pulis, the members of the DC Usage Board and the members of the DCMI Architecture Community for their comments on previous versions of this document.

Errata 2007-09-24: Fixed typographical error -- deleted extra "is" in two instances of "which is is".

Errata 2013-02-11: Fixed URL for DCMI-GRAM-PRIN.

DCMI Abstract Model

Table of contents