Dublin Core
Dublin Core
About DCMI 的mes Members Governing Board Usage Board Directorate
Twitter YouTube GitHub RSS Feed

Expressing Dublin Core™ metadata using the DC-Text format

Creator: Pete Johnston
Eduserv Foundation, UK
Date Issued: 2007-12-03
Identifier: //www.voudr.com/specifications/dublin-core/dc-text/2007-12-03/
Replaces: Not applicable
Is Replaced By: Not applicable
Latest Version: //www.voudr.com/specifications/dublin-core/dc-text/
Status of Document: This is a DCMIRecommended Resource
Description of Document: This document specifies a simple text format for representing a Dublin Core™ metadata description set. The format is known as "DC-Text".

Table of contents

  1. Introduction
  2. 的DCMI Abstract Model and DC-Text
  3. Some Features of the DC-Text Syntax
  4. 的DC-Text Syntax
  5. References
  6. Acknowledgements

1. Introduction

的"Description Set Model" of the DCMI Abstract Model [DCAM] describes the constructs that make up a DC metadatadescription set. This document specifies a syntax for serialising, or representing, a DC metadatadescription setin plain text. The format is referred to as "DC-Text". A plain text format for serialisation of suchdescription setsis useful as a means of presenting examples in a human-readable form which highlights the constructs of the DCMI Abstract Model, and also as a means of comparing the information represented in other machine-processable formats.

2.的DCMI Abstract Model and DC-Text

According to the "Description Set Model" of the DCMI Abstract Model [DCAM], a DCdescription sethas the following structure:

  • adescription setis made up of one or moredescriptions

  • adescriptionis made up of

    • zero or onedescribed resource URIand

    • one or morestatements

  • astatementis made up of

    • exactly oneproperty URIand

    • exactly onevalue surrogate

  • avalue surrogateis either aliteral value surrogateor anon-literal value surrogate

    • aliteral value surrogateis made up of

      • exactly onevalue string

    • anon-literal value surrogateis made up of

      • zero or onevalue URIs

      • zero or onevocabulary encoding scheme URIs

      • zero or morevalue strings

  • avalue stringis either aplain value stringor atyped value string

    • aplain value stringmay be associated with avalue string language

    • atyped value stringis associated with asyntax encoding scheme URI

  • anon-literal valuemay be described by anotherdescription

的format described in this document supports the full DCAM "description set model".

3. Some Features of the DC-Text Syntax

This section presents an overview of some features of the the syntax.

3.1 The Structure of a DC-Text Document

的general structure of a DC-Text document is as follows:

namespace declaration label ( label ( content ) label ( label ( [...] ) [...] ) )

Each of the primary components of a DC metadata description set defined by the DCMI Abstract Model is represented in DC-Text by a syntactic structure of the form:

label ( content )

wherelabelis replaced by one of the following strings:

DescriptionSet, Description, ResourceURI, ResourceId, Statement, PropertyURI, VocabularyEncodingSchemeURI, ValueURI, ValueId, ValueString, Language, SyntaxEncodingSchemeURI, LiteralValueString

andcontentis one of:

  • a sequence of one or more syntactic structures of the formlabel ( content )(i.e. these structures are "nested"); or

  • a string of the form"literal", which represents that Unicode literal; or

  • a string of the form, which represents a URI; or

  • a string of the formprefix:name, which represents a "qualified name" used as an abbreviation for a URI

  • a string which represents a language tag

  • a string which is a locally-scoped identifier used to establish relationships between values and their descriptions

For eachlabelvalue in the list above, the permitted form ofcontentis determined by the syntax rules specified in Section 4 below.

的DC-Text syntax supports the representation of a single DCdescription set, so a DC-Text document consists of zero or morenamespace declarationsfollowed by a singlelabel ( content )syntactic structure with alabelofDescriptionSet, and ascontent, one or more nestedlabel ( content )structures with alabelofDescription, i.e. a DC-Text document has the following outline form:

@prefix prefix:  . DescriptionSet ( Description ( Statement ( ... ) Statement ( ... ) ) Description ( Statement ( ... ) Statement ( ... ) ) )

3.2 URIs in DC-Text

的DCAM uses Uniform Resource Identifiers (URIs) [RFC3896] to refer both to the resources described and to metadata terms (properties,classes,vocabulary encoding schemesandsyntax encoding schemes).

In the DC-Text syntax, URIs may be represented in full or may be represented as "qualified names".

3.2.1 uri

A URI may be represented in full. The following example shows aproperty URIas the content of alabel ( content )syntactic structure:

Example 1: URI represented in full

DescriptionSet ( Description ( Statement ( PropertyURI (  ) ValueString ( "Metadata" ) ) ) )

Note that the DC-Text format doesnotsupport URI references in the form of relative references.

3.2.2 URIs,

Qualified Names and Namespace Declarations

A URI may be represented as a "qualified name".

A "qualified name" is an abbreviation for a URI used in the DC-Text format. A "qualified name" is made up of two parts, aprefixand aname, separated by a colon (:). In DC-Text, wherever a "qualified name" is used, it is used to represent a URI.

的"prefix" in a "qualified name" is associated with a "namespace URI" using a namespace declaration. The URI represented by the "qualified name" is determined by concatenating the "namespace URI" with which the prefix is associated and the "name".

Namespace declarations occur at the start of a DC-Text document, and have the following form:

@prefix prefix:  .

For example, the following declarations associates the prefixdctermswith the URIhttp://purl.org/dc/terms/and the prefixexwith the URIhttp://example.org/resources/.

@prefix dcterms:  . @prefix ex:  .

When "encoding" adescription setby generating a DC-Text instance, a "qualified name" to represent a URI is determined by

  • dividing the URI into a pair consisting of a local name (the trailing characters of the URI, subject to the lexical constraints described above) and a namespace URI (the preceding part of the URI), and

  • providing a Namespace Declaration element for this namespace URI (using a prefix in the namespace declaration and in the "qualified name").

Note that this means for a single URI there is more than one possible "qualified name" representation. For example, the URIhttp://purl.org/dc/terms/titlemight be represented using any of the following (namespace URI, local name) pairs:

  • {http://purl.org/dc/terms/}, title

  • {http://purl.org/dc/terms/t}, itle

  • {http://purl.org/dc/terms/ti}, tle

  • {http://purl.org/dc/terms/tit}, le

  • {http://purl.org/dc/terms/titl}, e

Communities typically decide on a convention for the "qualified name" to be used for a URI, particularly for the URIs of terms (properties,classes,vocabulary encoding schemesandsyntax encoding schemes), but in theory any of these four forms could be deployed without changing the interpretation of the instance. For all DCMI terms, the convention used by the DCMI community is to split the term URI into an expanded name at the right-most '/' (forward slash) character (as per the first example above). Also, the characters used for the prefix in a "qualified name" are not significant, but communities often adopt a convention on the common use of a prefix to facilitate human readability.

的following examples shows a namespace declaration and the use of a "qualified name" for the property URIhttp://purl.org/dc/terms/title:

Example 2: URI represented as "qualified name"

@prefix dcterms:  . DescriptionSet ( Description ( Statement ( PropertyURI ( dcterms:title ) LiteralValueString ( "DCMI Home Page" ) ) ) )

如果前缀用于限定名称没有been associated with a URI in a namespace declaration, it is an error. If the prefix has been associated with multiple URIs (though multiple namespace declarations) then the prefix is associated with the namespace URI specified in the latest declaration.

In the following examples the prefix "xx" is used in a "qualified name", and there are two namespace declaration for that prefix. The second namespace declaration is used to generate the URIhttp://your.example.org/terms/approvedfrom the "qualified name":

Example 3: URI represented as "qualified name", multiple namespace declarations

@prefix xx:  . @prefix xx:  . DescriptionSet ( Description ( Statement ( PropertyURI ( xx:approved ) LiteralValueString ( "2007-12-03" ) ) ) )

3.3 Comments

Comments can be inserted anywhere in a DC-Text document. A comment starts with a#and ends with a newline.

# A comment at the start of the document @prefix prefix:  . DescriptionSet ( Description ( # A comment at the start of a description Statement ( ... ) # A comment following a statement Statement ( ... ) ) Description ( Statement ( ... ) Statement ( ... ) ) )

3.4 String Escapes

Strings representing literals may contain escape characters to encode non-printable characters and characters that are used in the DC-Text syntax as terminators. The escape characters are:

  • \t = U+0009, tab
  • \n = U+000A, line feed
  • \r = U+000D, carriage return
  • " = U+0022, double quote
  • \ = U+005C, backslash

Example 4: Literal containing Escape Characters

@prefix dcterms:  . DescriptionSet ( Description ( Statement ( PropertyURI ( dcterms:title ) LiteralValueString ( "Things that go \"bump\" in the night" ) ) ) )

4. The DC-Text Syntax

This section describes how each of the constructs of the DCAM Description Set Model is represented using the DC-Text syntax.

4.1 Encoding a Description Set

Adescription setis made up of one or more_descriptions_.

A DC-Text document supports the representation of a single DCdescription set. Adescription setis represented using aDescriptionSet ( )syntactic structure.

Example 5: Description Sets

DescriptionSet ( Description ( Statement ( PropertyURI (  ) ValueString ( "Metadata" ) ) ) )

4.2 Encoding

a Description

Adescriptionis a set of one or morestatementsabout a resource.

Adescriptionis represented using aDescription ( )syntactic structure.

的following example represents adescription setconsisting of a singledescription.

Example 6: Description

DescriptionSet ( Description ( Statement ( PropertyURI (  ) ValueString ( "Metadata" ) ) ) )

Adescription setmay contain multipledescriptions.

Eachdescriptionis represented using a separateDescription ( )syntactic structure.

的following example represents adescription setconsisting of twodescriptions. The order of theDescription ( )syntactic structures is not significant.

Example 7: Multiple Descriptions

DescriptionSet ( Description ( Statement ( PropertyURI (  ) ValueString ( "Metadata" ) ) ) Description ( Statement ( PropertyURI (  ) LiteralValueString ( "Dublin Core™ Metadata Initiative" ) ) ) )

4.4.1 The

Described Resource URI

Adescriptionmay have an associateddescribed resource URI.

Adescribed resource URIis represented using aResourceURI ( )syntactic structure:

Example 8: Described Resource URI

DescriptionSet ( Description( ResourceURI(  ) Statement ( PropertyURI (  ) ValueString ( "Metadata" ) ) ) )

By introducing namespace declarations, the "qualified name" mechanism can be used to abbreviate thedescribed resource URI. The samedescription setas in the previous example might be encoded as follows.

Example 9: Described Resource URI abbreviated using "qualified name"

@ prefix页面:< //www.voudr.com/pages/ >。DescriptionSet ( Description ( ResourceURI ( page:home ) Statement ( PropertyURI (  ) ValueString ( "Metadata" ) ) ) )

Note: from this point in this document, all the examples will show URIs abbreviated as "qualified names", but in each case they could be represented as URIs in full.

4.3 Encoding a Statement

Adescriptionis made up of one or morestatements.

Astatementis represented using aStatement ( )syntactic structure.

的following example represents adescriptionconsisting of a singlestatement.

Example 10: Statements

@ prefix页面:< //www.voudr.com/pages/ >。@prefix dcterms:  . DescriptionSet ( Description ( ResourceURI ( page:home ) Statement ( PropertyURI ( dcterms:subject ) ValueString ( "Metadata" ) ) ) )

Adescriptionmay contain multiplestatements.

Eachstatementis represented using a separateStatement ( )syntactic structure.

的following example represents adescriptionconsisting of twostatements. The order of theStatement ( )syntactic structures is not significant.

Example 11: Multiple Statements

@ prefix页面:< //www.voudr.com/pages/ >。@prefix dcterms:  . DescriptionSet ( Description ( ResourceURI ( page:home ) Statement ( PropertyURI ( dcterms:subject ) ValueString ( "Metadata" ) ) Statement ( PropertyURI ( dcterms:title ) LiteralValueString ( "DCMI Home Page" ) ) ) )

4.3.1 Encoding a Property URI

Astatementmust contain exactly oneproperty URI.

Aproperty URIis represented using aPropertyURI ( )syntactic structure.

的following example represents adescriptionconsisting of a singlestatementwhere theproperty URIishttp://purl.org/dc/terms/subject.

Example 12: Property URI

@ prefix页面:< //www.voudr.com/pages/ >。@prefix dcterms:  . DescriptionSet ( Description ( ResourceURI ( page:home ) Statement ( PropertyURI ( dcterms:subject ) ValueString ( "Metadata" ) ) ) )

4.4 Encoding a Value Surrogate

Astatementmust contain exactly onevalue surrogate. Avalue surrogateis either aliteral value surrogateor anon-literal value surrogate.

4.4.1 Encoding a Literal Value Surrogate

Aliteral value surrogateis made up of exactly one_value string_.

4.4.1.1 Encoding a Literal Value Surrogate Value String

Avalue stringwithin aliteral value surrogateis represented using aLiteralValueString ( )syntactic structure.

的following example represents adescriptionconsisting of a singlestatementwith aliteral value surrogatecontaining avalue string.

Example 13: Literal Value Surrogate: Value String

@ prefix页面:< //www.voudr.com/pages/ >。@prefix dcterms:  . DescriptionSet ( Description ( ResourceURI ( page:home ) Statement ( PropertyURI ( dcterms:title ) LiteralValueString ( "DCMI Home Page" ) ) ) )

4.4.2 Encoding a Non-Literal Value Surrogate

Anon-literal value surrogateis made up of:

  • zero or onevalue URIs

  • zero or onevocabulary encoding scheme URIs

  • zero or morevalue strings

4.4.2.1 Value URI

Avalue URIis represented using aValueURI ( )syntactic structure.

的following example represents adescriptionconsisting of a singlestatementwith anon-literal value surrogatecontaining avalue URI.

Example 14: Non-Literal Value Surrogate: Value URI

@ prefix页面:< //www.voudr.com/pages/ >。@prefix agent:  . @prefix dcterms:  . DescriptionSet ( Description ( ResourceURI ( page:home ) Statement( PropertyURI ( dcterms:creator ) ValueURI ( agent:DCMI ) ) ) )
4.4.2.2 Vocabulary Encoding Scheme URI

Avocabulary encoding scheme URIis represented using aVocabularyEncodingSchemeURI ( )syntactic structure.

的following example represents adescriptionconsisting of a singlestatementwith anon-literal value surrogatecontaining avalue URIand avocabulary encoding scheme URI.

Example 15: Non-Literal Value Surrogate: Vocabulary Encoding Scheme URI

@ prefix页面:< //www.voudr.com/pages/ >。@prefix dcterms:  . @prefix exterms:  . @prefix exsh:  . DescriptionSet ( Description ( ResourceURI ( page:home ) Statement ( PropertyURI ( dcterms:subject ) ValueURI ( exsh:metadata ) VocabularyEncodingSchemeURI ( myterms:EXSH ) ) ) )
4.4.2.3 Encoding a Non-Literal Value Surrogate Value String

Avalue stringwithin anon-literal value surrogateis represented using aValueString ( )syntactic structure.

的following example represents adescriptionconsisting of a singlestatementwith anon-literal value surrogatecontaining avalue URI, avocabulary encoding scheme URIand avalue string.

Example 16: Non-Literal Value Surrogate: Value String

@ prefix页面:< //www.voudr.com/pages/ >。@prefix dcterms:  . @prefix exterms:  . @prefix exsh:  . DescriptionSet ( Description ( ResourceURI ( page:home ) Statement ( PropertyURI ( dcterms:subject ) ValueURI ( exsh:metadata ) VocabularyEncodingSchemeURI ( exterms:EXSH ) ValueString ( "Metadata" ) ) ) )

Anon-literal value surrogatemay contain multiplevalue strings.

的following example represents adescriptionconsisting of a singlestatementwith anon-literal value surrogatecontaining avalue URI, avocabulary encoding scheme URI和两个value strings.

Example 17: Non-Literal Value Surrogate: Multiple Value Strings

@ prefix页面:< //www.voudr.com/pages/ >。@prefix dcterms:  . @prefix exterms:  . @prefix exsh:  . DescriptionSet ( Description ( ResourceURI ( page:home ) Statement ( PropertyURI ( dcterms:subject ) ValueURI ( exsh:metadata ) VocabularyEncodingSchemeURI ( exterms:EXSH ) ValueString ( "Metadata" ) ValueString ( "Métadonnées" ) ) ) )

4.5 Encoding a Value String

Avalue stringis either aplain value stringor atyped value string.

4.5.1 Encoding a Plain Value String

Aplain value stringmay be associated with avalue string language

4.5.1.1 Encoding a Value String Language

Avalue string languageis represented using aLanguage ( tag )syntactic structure.

的following example represents adescriptionconsisting of a singlestatementwith anon-literal value surrogatecontaining avalue URI, avocabulary encoding scheme URI和两个plain value strings, each associated with avalue string language.

Example 18: Value String Languages

@ prefix页面:< //www.voudr.com/pages/ >。@prefix dcterms:  . @prefix exterms:  . @prefix exsh:  . DescriptionSet ( Description ( ResourceURI ( page:home ) Statement ( PropertyURI ( dcterms:subject ) ValueURI ( exsh:metadata ) VocabularyEncodingSchemeURI ( exterms:EXSH ) ValueString ( "Metadata" Language ( en ) ) ValueString ( "Métadonnées" Language ( fr ) ) ) ) )

4.5.2 Encoding a Typed Value String

Atyped value stringis associated with asyntax encoding scheme URI.

4.5.2 Encoding a Syntax Encoding Scheme URI

Asyntax encoding scheme URIis represented using theSyntaxEncodingSchemeURI ( )syntactic structure.

的following example represents adescriptionconsisting of a singlestatementwith anon-literal value surrogatecontaining avalue URIand avocabulary encoding scheme URI.

Example 19: Syntax Encoding Scheme URI

@ prefix页面:< //www.voudr.com/pages/ >。@prefix dcterms:  . @prefix xs:  . DescriptionSet ( Description ( ResourceURI ( page:home ) Statement ( PropertyURI ( dcterms:modified ) ValueString ( "2006-02-14" SyntaxEncodingSchemeURI ( xs:date ) ) ) ) )

4.6 Descriptions of Non-Literal Values

Adescription setmay contain multipledescriptions,每一个都代表Description ( content )syntactic structure. The order of the structures has no significance.

Example 20: Multiple Descriptions

@ prefix页面:< //www.voudr.com/pages/ >。@prefix dcterms:  . @prefix foaf:  . DescriptionSet ( Description ( ResourceURI ( page:home ) Statement ( PropertyURI ( dcterms:subject ) ValueString ( "Metadata" ) ) ) Description ( Statement ( PropertyURI ( foaf:name ) LiteralValueString ( "Dublin Core™ Metadata Initiative" ) ) ) )

Aresource which is referred to as anon-literal valuein astatementin onedescriptionmay be thedescribed resourceof anotherdescriptionwithin thedescription set_. If that_ resourcehas been assigned a URI, then that URI appears as thevalue URIin thestatementwhere theresourceis referred to as thenon-literal value and as adescribed resource URIin thedescriptionof thatresource, as shown below:

Example 21: Non-Literal Value as Described Resource

@ prefix页面:< //www.voudr.com/pages/ >。@prefix agent:  . @prefix dcterms:  . @prefix foaf:  . DescriptionSet ( Description ( ResourceURI ( page:home ) Statement ( PropertyURI ( dcterms:creator ) ValueURI ( agent:DCMI ) ) ) Description ( ResourceURI ( agent:DCMI ) Statement ( PropertyURI ( foaf:name ) LiteralValueString ( "Dublin Core™ Metadata Initiative" ) ) ) )

In some cases aresourcewill not have a URI assigned, or the URI will not be known. Such aresourcemay still be a referred to as anon-literal valuein astatementin onedescriptionand thedescribed resourceof anotherdescriptionin the samedescription set.

In DC-Text, the association between thestatementin the firstdescriptionand the seconddescriptionis made by using an identifier for theresourcewhich is local to a DC-Text instance. This local identifier is used in aValueId ( id )syntactic construct within one or moreStatement ( )constructs where theresourceis referred to as anon-literal value, and in aResourceId ( id )construct within aDescription ( )construct for which the resource is thedescribed resource. The content of aValueId ( id )construct must match the content of aResourceId ( id )construct in the same DC-Text instance.

Note that this is a syntactic mechanism for linking references tovaluesinstatementstodescriptionsof thosevalues: the local identifier itself does not appear in thedescription set.

Example 23: Non-Literal Value as Described Resource

@ prefix页面:< //www.voudr.com/pages/ >。@prefix agent:  . @prefix dcterms:  . @prefix foaf:  . DescriptionSet ( Description ( ResourceURI ( page:home ) Statement ( PropertyURI ( dcterms:creator ) ValueId ( agentDCMI ) ) ) Description ( ResourceId ( agentDCMI ) Statement ( PropertyURI ( foaf:name ) LiteralValueString ( "Dublin Core™ Metadata Initiative" ) ) ) )

References

[DCAM]
DCMI Abstract ModelDCMI Recommendation. 2007-06-04
//www.voudr.com/specifications/dublin-core/abstract-model/2007-06-04/

[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>

Changes to this document

2008-01-14. Removed note saying: As of 2007-12-03, aproposalto "replicate" the fifteen properties of thehttp://purl.org/dc/elements/1.1/("dc:") namespace in thehttp://purl.org/dc/terms/(“使用dc:“)名称空间并没有被批准或implemented. Until this is approved, references herein to names such as dcterms:subject and dcterms:title should be understood as having the status of "proposed" as well.

2008-03-31. Changed captions of examples 14, 15, 16 & 17 from "Literal Value Surrogate..." to "Non-Literal Value Surrogate...". Removed profile URI.