DCMI Abstract Model

Creator:	Andy Powell UKOLN, University of Bath, UK Mikael Nilsson KMR Group, CID, NADA, KTH (Royal Institute of Technology), Sweden Ambjörn Naeve KMR Group, CID, NADA, KTH (Royal Institute of Technology), Sweden Pete Johnston UKOLN, University of Bath, UK
Date Issued:	2005-03-07
Identifier:	//www.voudr.com/specifications/dublin-core/abstract-model/2005-03-07/
Replaces:	//www.voudr.com/specifications/dublin-core/abstract-model/2005-01-31/
Is Replaced By:	//www.voudr.com/specifications/dublin-core/abstract-model/2007-06-04/
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 DCMI metadata descriptions.

Table of contents

1. Introduction
2. DCMI abstract model
3. Descriptions, description sets and records
4. Values
5. 镜像下
6. Encoding guidelines
7. Terminology
   References
   Acknowledgements
   Appendix A - A note about structured values
   Appendix B - The abstract model and RDF
   Appendix C - The abstract model and XML
   Appendix D - The abstract model and XHTML

---

1. Introduction

This document specifies an abstract model for DCMI metadata [DCMI]. The primary purpose of this document is to provide a reference model against which particular DC encoding guidelines can be compared. To function well, a reference model needs to be independent of any particular encoding syntax. Such a reference model allows us to gain a better understanding of the kinds of descriptions that we are trying to encode and facilitates the development of better mappings and translations between different syntaxes.

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 those people developing metadata application profiles based on the Dublin Core™.

2. DCMI abstract model

The abstract model of theresourcesbeing described by DCMI metadatadescriptionsis as follows:

• Eachresourcehas zero or moreproperty/value pairs.
• Eachproperty/value pairis made up of onepropertyand onevalue.
• Eachvalueis aresource(the physical or conceptual entity that is associated with apropertywhen it is used to describe aresource).
• Eachresourcemay be a member of one or moreclasses.
• Eachpropertyandclasshas some declaredsemantics.
• Eachclassmay be related to one or more otherclassesby a refines (sub-class) relationship (where the twoclassesshare somesemanticssuch that allresourcesthat are members of thesub-classare also members of the relatedclass).
• Eachpropertymay be related to one or more otherpropertiesby a refines (sub-property) relationship (where the twopropertiesshare somesemanticssuch that whenever aresourceis related to avalueby thesub-property, it follows that theresourceis also related to that samevalueby theproperty).

The abstract model of DCMI metadatadescriptionsis as follows:

• Adescriptionis made up of one or morestatements(about one, and only one,resource) and zero or oneresource URI(a URI reference that identifies theresourcebeing described).
• Eachstatementinstantiates aproperty/value pairand is made up of aproperty URI(a URI reference that identifies aproperty), zero or onevalue URI(a URI reference that identifies avalueof theproperty), zero or onevocabulary encoding scheme URI(a URI reference that identifies theclassof thevalue) and zero or morevalue representationsof thevalue.
• Thevalue representationmay take the form of avalue stringor arich representation.
• Eachvalue stringis a simple, human-readable string that is a representation of theresource这是valueof theproperty.
• Eachvalue stringmay have an associatedsyntax encoding scheme URIthat identifies asyntax encoding scheme.
• Eachvalue stringmay have an associatedvalue string languagethat is an ISO language tag (e.g. en-GB).
• Eachrich representationis somemarked-up text, an image, a video, some audio, etc. or some combination thereof that is a representation of theresource这是valueof theproperty.
• Eachvaluemay be the subject of a separaterelated description.

The italicized words and phrases used above are defined in the terminology section below. A number of things about the model are worth noting:

• Arelated descriptiondescribes a relatedresourceand is therefore not part of thedescription- for example, arelated descriptionmay provide metadata about the person that is the creator of the describedresource.
• Syntax encoding schemesare also known as 'datatypes' in some contexts.
• Eachresourcemay be a member of one or moreclasses. Note that where theresourceis avalue,classis referred to as avocabulary encoding scheme.
• In DCMI metadatadescriptions,classof theresourcebeing described is normally indicated by thevalueof the DC Typeproperty.

The DCMI abstract model for resources and descriptions is represented as UML class diagrams [UML] in figures 1 and 2.

**Figure 1 - the DCMI resource model****Figure 2 - the DCMI description model**

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, 'avocabulary encoding schemeis aclass') 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. The classes represented by the clear boxes are not mentioned explicitly in the textual description of the abstract model above but are discussed in Appendix A. Note that the UML modeling used here shows the abstract model but is not intended to form a suitable basis for the development of DCMI software applications.

3. Descriptions, description sets and records

The abstract model described above indicates that each DCMI 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 the describedresourcesare 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 (XHTML meta tags, XML, RDF/XML, etc.) [DCMI-ENCODINGS].

This document defines adescription setand a DCMI metadatarecordas follows:

• Adescription setis a set of one or moredescriptionsabout one or moreresources.
• A DCMI metadatarecordis adescription setthat is instantiated according to one of the DCMI encoding guidelines (XHTML meta tags, XML, RDF/XML, etc.)

4. Values

A DCMI metadatavalueis the physical or conceptual entity that is associated with apropertywhen it is used to describe aresource. For example, thevalueof the DC Creatorpropertyis a person, organization or service - a physical entity. Thevalueof the DC Datepropertyis a point (or range) in time - a conceptual entity. Thevalueof the DC Coverageproperty可能是一个地理区域或国家——一个物理entity. Thevalueof the DC Subjectpropertymay be a concept - a conceptual entity - or a physical object or person - a physical entity. Each of these entities is aresource.

Thevaluemay be identified using avalue URI; thevaluemay be represented by one or morevalue stringsand/orrich representations; thevaluemay have somerelated descriptions- but thevalueis aresource.

5. Dumb-down

The notions of 'simple DC' and 'qualified DC' are widely used within DCMI documentation and discussion fora. This document does not present a definitive view of what these phrases mean because their usage is somewhat variable. However, in general terms, the phrase 'simple DC' is used to refer to DC metadata that does not make any use ofencoding schemesandelement refinementsand in which each statement only contains avalue stringwhile the phrase 'qualified DC' is used to refer to metadata that makes use of all the features of the abstract model described here.

The process of translating qualified DC into simple DC is normally referred to as 'dumbing-down'. The process of dumbing-down can be separated into two parts: property dumb-down and value dumb-down. Furthermore, each of these processes can be approached in one of two ways. Informed dumb-down takes place where the software performing the dumb-down algorithm has knowledge built into it about thepropertyrelationships andvaluesbeing used within a specific DCMI metadata application. Uninformed dumb-down takes place where the software performing the dumb-down algorithm has no prior knowledge about thepropertiesandvaluesbeing used.

Based on this analysis, it is possible to outline a 'dumb-down algorithm' matrix, shown below:

	Element dumb-down	Value dumb-down
Uninformed	Discard anystatementin which theproperty URIidentifies apropertythat isn't in the Dublin Core™ Metadata Element Set [DCMES].	Usevalue URI(if present) orvalue stringas newvalue string. Discard anyrelated descriptionsandrich representations. Discard anyencoding scheme URIs.
Informed	Recursively resolve sub-property relationships until a recognisedpropertyis reached and substitute theproperty URIof thatpropertyfor the existingproperty URIin thestatement. If no recognisedpropertyis reached, then discard thestatement. (In many cases, this process stops when apropertyis reached that is not anelement refinement.)	Use knowledge of anyrich representations,related descriptionsor thevalue stringto create a newvalue string.

Note that software should make use of the DCMItermdeclarations represented in RDF schema language [DC-RDFS], the DC XML namespace URIs [DC-NAMESPACES] and the appropriate DCMI encoding guidelines (XHTML meta tags, XML, RDF/XML, etc.) [DCMI-ENCODINGS] to automate the resolution of sub-property relationships.

In cases where software is dumbing-down adescription setcontaining multipledescriptions, it may either generate several 'simpler'descriptions(one perdescriptionin the originaldescription set) or a single 'simple' description (in which case it will have to determine which is the 'primary'descriptionin the originaldescription set). This is an application-specific decision.

6. Encoding guidelines

Particular encoding guidelines (HTML meta tags, XML, RDF/XML, etc.) [DCMI-ENCODINGS)不需要编码abstrac的方方面面t model described above. However, DCMI recommendations that provide encoding guidelines should refer to the DCMI abstract model and indicate which parts of the model are encoded and which are not. In particular, encoding guidelines should indicate the mechanism by whichresource URIsandvalue URIsare encoded. Note that the abstract model does不indicate that avalue stringwith an associatedhttp://purl.org/dc/terms/URIsyntax encoding schemeshould be treated as avalue URIorresource URI. Encoding guidelines should provide an explicit mechanism for encoding these features of the model. Encoding guidelines should also indicate whether anyrich representationsorrelated descriptionsassociated with astatementare embedded within therecordor are encoded in a separaterecordand linked to it using a URI reference.

Appendices B, C and D below provide a summary comparison between the abstract model and the RDF/XML, XML and XHTML encoding guidelines.

7. Terminology

This document uses the following terms:

class

Aclassis a group containing members that have attributes, behaviours, relationships or semantics in common; a kind of category.

class URI

Aclass URIis a URI reference that identifies aclass.

description

Adescriptionis made up of one or morestatementsabout one, and only one,resource.

description set

Adescription setis a set of one or moredescriptionsabout one or moreresources.

element

Within DCMI,element通常是使用d as a synonym forproperty. However, it should be noted that the word element is also commonly used to refer to a structural markup component within an XML document.

element refinement

Anelement refinementis apropertyof aresourcethat shares the meaning of a particular DCMIpropertybut with narrower semantics. Sinceelement refinementsareproperties,y can be used in metadatadescriptionsindependently of thepropertiesthey refine. In DCMI practice, anelement refinementrefines just one parent DCMIproperty.

encoding scheme

Encoding schemeis the generic name forvocabulary encoding schemeandsyntax encoding scheme.

encoding scheme URI

The generic name for avocabulary encoding scheme URIor asyntax encoding scheme URI.

marked-up text

A string that contains HTML, XML or other markup (for example TeX) and that is associated with thevalueof aproperty.

property

Apropertyis a specific aspect, characteristic, attribute, or relation used to describeresources.

property URI

Aproperty URIis a URI reference that identifies a singleproperty.

property/value pair

Aproperty/value pairis the combination of apropertyand avalue, used to describe aresource.

qualifier

Qualifierwas the generic name used for thetermsthat are now usually referred to specifically aselement refinementsorencoding schemes.

record

Arecordis adescription setthat is instantiated according to one of the DCMI encoding guidelines (XHTML meta tags, XML, RDF/XML, etc.)

related description

Arelated descriptionis adescriptionof aresourcethat is related to theresourcebeing described.

resource

Aresourceis anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of otherresources. Not allresourcesare network "retrievable"; e.g., human beings, corporations, concepts and bound books in a library can also be consideredresources.

resource URI

Aresource URIis a URI reference that identifies a singleresource.

rich representation

Somemarked-up text, an image, a video, some audio, etc. (or some combination thereof) that is associated with thevalueof aproperty.

statement

Astatementis made up of aproperty URI(a URI reference that identifies aproperty), zero or onevalue URI(a URI reference that identifies avalueof theproperty), zero or onevocabulary encoding scheme URI(a URI reference that identifies theclassof thevalue) and zero or morevalue representationsof thevalue.

structured value

Structured valueis the generic name for the following:

• Avalue stringthat contains machine-parsable component parts (and which has an associatedsyntax encoding schemethat indicates how the component parts are encoded within the string).
• Somemarked-up text.
• Arelated description

syntax encoding scheme

Asyntax encoding schemeindicates that thevalue stringis formatted in accordance with a formal notation, such as "2000-01-01" as the standard expression of a date.

syntax encoding scheme URI

Asyntax encoding scheme URIis a URI reference that identifies asyntax encoding scheme. For all DCMI recommendedencoding schemes,由concatenatin URI引用g the name of theencoding schemewith thehttp://purl.org/dc/terms/namespace URI.

term

The generic name for aproperty(i.e.elementorelement refinement),vocabulary encoding scheme,syntax encoding schemeor concept taken from a controlled vocabulary (concept space).

term URI

The generic name for a URI reference that identifies aterm.

value

Avalueis the physical or conceptual entity that is associated with apropertywhen it is used to describe aresource.

value URI

Avalue URIis a URI reference that identifies thevalueof aproperty.

value representation

Avalue representationis a surrogate for (i.e. a representation of) thevalue.

value string

Avalue stringis a simple string that represents thevalueof aproperty. In general, avalue stringshould not contain anymarked-up text.

value string language

Thevalue string languageindicates the language of thevalue string.

vocabulary encoding scheme

Avocabulary encoding schemeis aclassthat indicates that thevalueof apropertyis taken from a controlled vocabulary (or concept-space), such as the Library of Congress Subject Headings.

vocabulary encoding scheme URI

Avocabulary encoding scheme URIis a URI reference that identifies avocabulary encoding scheme. For all DCMI recommendedencoding schemes,由concatenatin URI引用g the name of theencoding schemewith thehttp://purl.org/dc/terms/namespace URI.

References

DCMI

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

UML

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

DCTERMS

DCMI Metadata Terms
<//www.voudr.com/specifications/dublin-core/dcmi-terms/>

DCMES

Dublin Core™ Metadata Element Set, Version 1.1: Reference Description
<//www.voudr.com/specifications/dublin-core/dces/>

DCMI-ENCODINGS

DCMI Encoding Guidelines
<//www.voudr.com/schemas/>

DC-RDFS

DCMI term declarations represented in RDF schema language
<//www.voudr.com/schemas/rdfs/>

DC-NAMESPACES

Namespace Policy for the Dublin Core™ Metadata Initiative (DCMI)
<//www.voudr.com/specifications/dublin-core/dcmi-namespace/>

Acknowledgements

Thanks to Tom Baker, Rachel Heery, the members of the DC Usage Board and the members of the DC Architecture Working Group for their comments on previous versions of this document.

---

Appendix A - A note about structured values

This appendix discusses 'structured values', as they are used in DC metadata applications at the time of writing.

Many existing applications of DC metadata have attempted to encode relatively complex 'value representations' (i.e. representations that are not just a simple string). These attempts have been loosely referred to as 'structured values'. It is possible to identify a number of different kinds of structured values that have been commonly used. Four are enumerated below. The first two of these are recommended by the DCMI, in the sense that there are existing encoding schemes that define values that conform to these definitions of structured values. The latter two are not currently recommended, but it is likely that they are in fairly common usage across metadata applications worldwide.

Labelled strings

These are strings that contain explicitly labeled components. Examples of this kind of structured value include:

DCSV

and the various DCMI syntax encoding schemes built on it - Period, Point and Box. An example of the use of DCSV in Period is:

vCard

for example:

Note that vCard is not currently a DCMI recommended encoding scheme.

未标记的字符串

These are strings that contain implicit components within the string, i.e. the components are determined based solely on their position within the string. Examples of this kind of structured value include:

W3CDTF

the date-time format used within most DC metadata. For example:

Marked-up text

These are strings containing 'presentational' or other markup, for example adding paragraph breaks, superscripts or chemical/mathematical markup to a dc:description. It is possible to characterize various kinds of markup as follows:

• Markup based on a version ofHTML.
• Markup based on other XML-based languages such asCMLandMathML.
• Non-XML markup languages such asTeX.

Related resource descriptions

These are metadata descriptions that describe a second resource (i.e. not the resource being described by the DC description). For example, a related description associated with the value of dc:creator could contain a complete description of the resource author (including birthday, eye-colour and favourite beverage if desired!).

In the past, 'related resource descriptions' have tended to be encoded using XML, vCard (see above) or by inventing multiple 'refinements' of DCMES properties (for example DC.Creator.Address). The RDF/XML encoding of DC (see below) provides us with a more thorough modeling of related metadata records through the use of multiple linked nodes in an RDF graph.

Summary

The categories outlined above are not watertight and there are certainly overlaps between them. For example, labeled strings can be viewed as a type of non-XML markup language. In addition, there will be cases where marked-up text (e.g. MathML) can be viewed as a related resource description.

Nevertheless, the purpose of the categorization used here is to try and analyze existing usage of complex metadata structures within current DC metadata applications. In the context of the abstract model proposed here, all the types of structured values outlined above form part of the DCMI abstract model:

• A labeled string should be treated as arelated description(though it should be noted that DCSV and the various DCMI syntax encoding schemes built on it - Period, Point and Box - are currently encoded asvalue stringswith an appropriatesyntax encoding scheme).
• An unlabeled string should be treated as avalue stringwith an appropriatesyntax encoding scheme.
• Marked-up text should be treated as arich representation.
• A related resource description should be treated as arelated description.

---

Appendix B - The abstract model and RDF

This appendix discusses the relationship between the DCMI abstract model and the Resource Description Framework (RDF).

RDF currently provides DCMI with the richest encoding environment of the available encoding syntaxes. It is therefore worth taking a brief look at how the abstract model described here compares with the RDF model.

Note that the intention here is not to provide a full and detailed description of how to encode DC metadata records in RDF. Instead, three simple examples of the use of DC in RDF are considered.

Example 1: dc:creator

Figure 3 shows a simple RDF graph (and the RDF/XML document that represents it). The graph shows a resource with a single property (dc:creator). Thevalueof the property is a second (blank) node, representing the creator of the resource. This second blank node has several properties, used to describe the creator, and an rdfs:label property that is used to provide thevalue stringfor the dc:creator property.

Figure 3

Figure 4 shows the same information separated into two graphs. In this case therelated descriptionthat describes the creator has been more clearly separated from the description of the resource by moving it into a separate RDF/XML document. In order to do this, the node representing thevaluehas been assigned avalue URI, allowing the two nodes in the two RDF/XML documents to be treated as representing the same thing. Therelated descriptionin the second RDF/XML document is linked to the first using the rdfs:seeAlso property and the URI of the RDF/XML document. Note that it is not strictly necessary to separate the two graphs in this way; it is perfectly valid to represent the second graph as a sub-graph of the first, as shown in figure 3. However, for the purposes of this document, the two graphs have been separated in order to more clearly differentiate thedescriptionfrom therelated description. In some cases it will be good practice to facilitate this separation anyway. For example, in order to serve the second graph from a directory service of some kind.

Figure 4

Example 2: dc:subject

Figure 5 shows a second simple RDF graph (and the RDF/XML document that represents it). The graph shows a resource with a single property (dc:subject). Thevalueof the property is a second (blank) node, representing the subject of the resource. This second blank node has an rdfs:label property that is used to provide thevalue stringfor the dc:subject property, an rdf:value property that is used to provide the classification scheme notation and an rdf:type property to provide the encoding scheme URI.

Figure 5

Figure 6 shows the same information separated into two graphs. In this case therelated descriptionthat describes the subject has been more clearly separated from the description of the resource by moving it into a separate RDF/XML document. In order to do this, the node representing thevaluehas been assigned avalue URI, allowing the two nodes in the two RDF/XML documents to be treated as representing the same thing. Therelated descriptionin the second RDF/XML document is linked to the first using the rdfs:seeAlso property and the URI of the RDF/XML document. Note that it is not strictly necessary to separate the two graphs in this way; it is perfectly valid to represent the second graph as a sub-graph of the first, as shown in figure 5. However, for the purposes of this document, the two graphs have been separated in order to more clearly differentiate thedescriptionfrom therelated description. In some cases it will be good practice to facilitate this separation anyway. For example, in order to serve the second graph from a terminology service of some kind.

Figure 6

Example 3: dc:description

Figure 7 shows a third simple RDF graph (and the RDF/XML document that represents it). The graph shows a resource with a single property (dc:description). Thevalueof the property is a second (blank) node with an rdfs:label property that is used to provide thevalue stringfor the dc:description property. The second node also has an rdfs:seeAlso property that links to arich representation- in this case some HTMLmarked-up textthat provides a richer representation of the description. Note that it is possible to embed themarked-up textwithin a single RDF graph (using rdf:parseType="Literal"). However, this is not shown here.

Figure 7

Summary

By re-visiting the second figure from example 2 (figure 6) it is possible to layer the terminology used in the abstract model above over the RDF graph. Almost all aspects of the DCMI abstract model are supported by the RDF encoding guidelines though, at the time of writing, some issues about how best to handledescription setsstill need to be resolved.

Figure 8

Appendix C - The abstract model and XML

This appendix compares the DCMI abstract model with theGuidelines for implementing Dublin Core™ in XMLDCMI recommendation.

Simple DC

**Figure 9**

Figure 9 shows an example simple DC description encoded according to the XML guidelines above. The example shows how the encoding supports theproperty URI,value stringandvalue string languageaspects of the DCMI abstract model. It should be noted that all thevaluesthat are encoded in this syntax are represented byvalue strings, even those that look, to the human reader, as though they are URIs.

Qualified DC

**Figure 10**

Figure 10 shows an example qualified DC description encoded according to the XML guidelines above. This example shows how the encoding supports theproperty URI,value string,value string language,encoding scheme URIandresource classaspects of the DCMI abstract model. Note also that, although theresource classis indicated, theclass URIis not encoded anywhere in this description.

Summary

The following aspects of the DCMI abstract model are supported by theGuidelines for implementing Dublin Core™ in XMLrecommendation:

• properties
• property URIs
• value strings
• value string languages
• encoding schemes
• encoding scheme URIs
• resource classes

The following aspects of the DCMI abstract model are not supported:

• resource URIs
• value URIs
• rich representations
• related descriptions
• property/sub-property relationships
• resource class URIs

The following constraints apply:

• Eachpropertymay have onevalue string(but not more than one).
• Vocabulary encoding schemesandsyntax encoding schemesare handled in exactly the same way.

Note that, at the time of writing, neitherresource URIs也不value URIscan be explicitly encoded in the XML encoding syntax. Although it may be the case that some software applications have chosen to interpret the use of ahttp://purl.org/dc/terms/URIsyntax encoding schemeas an indication that the URI in thevalue stringis aresource URIorvalue URI, this is不guaranteed to be a correct interpretation of the metadatarecordin all cases.

Appendix D - The abstract model and XHTML

This appendix compares the DCMI abstract model with theExpressing Dublin Core™ in HTML/XHTML meta and link elementsDCMI recommendation.

Simple DC

**Figure 11**

Figure 11 shows an example simple DC description encoded according to the XHTML guidelines above. This example shows how the encoding supports theproperty URI,value string,value string languageandvalue URIaspects of the DCMI abstract model. Again, it should be noted that the value of the DC Identifierpropertyrepresented in this encoding syntax is denoted by avalue string, even though it looks, to the human reader, as though it is a URI.

Qualified DC

**Figure 12**

Figure 12 shows an example qualified DC description encoded according to the XHTML guidelines above. This example shows how the encoding supports theproperty URI,value string,value string language,value URI,encoding scheme URIandresource classaspects of the DCMI abstract model. Note that although theresource classis indicated, theclass URIis not encoded anywhere in this description. Finally, note that although thehttp://purl.org/dc/terms/URIsyntax encoding schememeans that software can reliably interpret the DC Identifiervalue stringas a URI, it should not be interpreted as aresource URI.

Summary

The following aspects of the DCMI abstract model are supported by theExpressing Dublin Core™ in HTML/XHTML meta and link elementsDCMI recommendation:

• properties
• property URIs
• value strings
• value string languages
• value URIs
• encoding schemes
• encoding scheme URIs
• resource classes

The following aspects of the DCMI abstract model are not supported:

• resource URIs
• rich representations
• related descriptions
• property/sub-property relationships
• resource class URIs

The following constraints apply:

• Eachpropertymay have onevalue string(but not more than one) or avalue URIbut not both.
• Vocabulary encoding schemesandsyntax encoding schemesare handled in exactly the same way.

Note that, at the time of writing,resource URIscannot be explicitly encoded in the XHTML encoding syntax. However, theresource URImay be implicit from the URI of theresourceinto which therecordis embedded.