- DCText/2007-04-02

DC-Text: A Text Syntax for Dublin Core Metadata

This document is part of the DC Architecture Wiki.

IMPORTANT: Do not cite materials in this Wiki other than for the purposes of collaborating on document creation. This Wiki is intended to be used to work on draft copies of documents. Finished documents will be published, in a persistent and citable form, on the dublincore.org Web site (or elsewhere in some cases).

This is a draft document, currently being worked on by the DC Architecture Working Group. Comments should be sent to the DC-ARCHITECTURE@jiscmail.ac.uk mailing list or direct to the authors.

Title:	DC-Text: A Text Syntax for Dublin Core Metadata
Creator:	Pete Johnston, Eduserv Foundation <pete.johnston@eduserv.org.uk>
Date Issued:	2007-04-02
Identifier:	http://dublincore.org/architecturewiki/DCText/2007-04-02
Replaces:	http://dublincore.org/architecturewiki/DCText/2006-05-24
Is Replaced By:	Not applicable
Latest Version:	http://dublincore.org/architecturewiki/DCText
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".

Introduction
The DCMI Abstract Model (Summary)
Some Features of the DC-Text Syntax
The DC-Text Syntax
Examples
Appendix A: DC-Text in BNF
Notes
References

1. Introduction

The DCMI Abstract Model [DCAM] describes the constructs which make up DC metadata description sets. This document specifies a syntax for serialising, or representing, a DC metadata description set in plain text. The format is referred to as "DC-Text". A plain text format for serialisation of such description sets is useful as a means of presenting examples in a way which highlights the constructs of the DCMI Abstract Model, and also as a means of comparing the information represented in other formats such as DC-XML, RDF/XML and XHTML/HTML.

2. The DCMI Abstract Model (Summary)

According to the DCMI Abstract Model [DCAM], a DC description set has the following structure:

a description set is made up of one or more descriptions
a description is made up of

zero or one resource URI and
one or more statements

a statement is made up of

exactly one property URI and
exactly one value surrogate

a value surrogate is either a literal value surrogate or a non-literal value surrogate

a literal value surrogate is made up of exactly one value string
a non-literal value surrogate is made up of

zero or one value URIs
zero or one vocabulary encoding scheme URIs
zero or more value strings

a value string is either a plain value string or a typed value string

a plain value string may be associated with a value string language
a typed value string is associated with a syntax encoding scheme URI

a non-literal value may be described by another description

3. Some Features of the DC-Text Syntax

A formal description of the DC-Text syntax is presented in Appendix A.

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

3.1 The Structure of a DC-Text Document

The 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 )

where label is replaced by one of the following strings:

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

and content is either:

a sequence of one or more syntactic structures of the form label ( 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 <uri>, which represents a URI; or
a string of the form prefix: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 each label value in the list above, the permitted form of content is determined by the syntax rules specified in Appendix A. These are explained through examples below.

The DC-Text syntax supports the representation of a single DC description set, so a DC-Text document consists of zero or more namespace declarations followed by a single label ( content ) syntactic structure with a label of DescriptionSet, and as content, one or more nested label ( content ) structured with a label of Description. i.e. a DC-Text document has the following outline form:

@prefix prefix: <uri> .

DescriptionSet (
  Description (
    Statement ( ... )
    Statement ( ... )
  )
  Description (
    Statement ( ... )
    Statement ( ... )
  )
)

3.2 URIs, Qualified Names, and Namespace Declarations

The DCMI Abstract Model uses URIs to refer to resources and to metadata terms (properties, vocabulary encoding schemes and syntax encoding schemes). In the DC-Text syntax, URIs may be written in full or may be represented as "qualified names". A qualified name is made up of two parts, a prefix and a name, separated by a colon (:). In DC-Text, wherever a qualified name is used, it is used to represent a URI. The URI represented by the qualified name is determined by appending the name part of the qualified name to the URI with which the prefix is associated in a namespace declaration (sometimes called the namespace URI).

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

@prefix prefix: <uri>

For example, the following declarations associates the prefix dc with the URI http://purl.org/dc/terms/ and the prefix ex with the URI http://example.org/resources/

@prefix dcterms: <http://purl.org/dc/terms/>
@prefix ex: <http://example.org/resources/>

Note that the limitations on the characters which can occur in the name part of a qualified name mean that there are URIs that can not be expressed as qualified names. For example the URIs http://example.org/resources/12345 and http://example.org/resources#12345 can not be represented as qualified names, because the name part can not include the "/" or "#" characters, and can not begin with a numeric character.

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: <uri> .
DescriptionSet (
  Description (
    # A comment at the start of a description
    Statement ( ... )
    # A comment following a statement
    Statement ( ... )
  )
  Description (
    Statement ( ... )
    Statement ( ... )
  )
)

3.4 String Escapes

To be provided.

4. The DC-Text Syntax

This section describes how each of the constructs of the DCMI Abstract Model i srepresented using the DC-Text syntax.

4.1 Description Sets

A DC-Text document supports the representation of a single DC description set. A description set is represented using a DescriptionSet ( ) syntactic structure.

DescriptionSet (
  Description (
    Statement (
      PropertyURI ( <http://purl.org/dc/terms/subject> )
      ValueString ( "Metadata" )
    )
  )
)

Example 1: Description Sets

4.2 Descriptions

A description set is made up of one or more descriptions.

A description is represented using a Description ( ) syntactic structure.

The following example represents a description set consisting of a single description.

DescriptionSet (
  Description (
    Statement (
      PropertyURI ( <http://purl.org/dc/terms/subject> )
      ValueString ( "Metadata" )
    )
  )
)

Example 2: Descriptions

A description set may contain multiple descriptions.

Each description is represented using a separate Description ( ) syntactic structure.

The following example represents a description set consisting of two descriptions.

DescriptionSet (
  Description (
    Statement (
      PropertyURI ( <http://purl.org/dc/terms/subject> )
      ValueString ( "Metadata" )
    )
  )
  Description (
    Statement (
      PropertyURI ( <http://xmlns.com/foaf/0.1/name> )
      LiteralValueString ( "Dublin Core Metadata Initiative" )
    )
  )
)

Example 3: Multiple Descriptions

The order of descriptions within a description set is not significant.

4.2.1 Described Resource URI

A description may have an associated described resource URI.

A described resource URI is represented using a ResourceURI ( <uri> ) syntactic structure:

DescriptionSet (
  Description(
    ResourceURI( <http://dublincore.org/pages/home> )
    Statement (
      PropertyURI ( <http://purl.org/dc/terms/subject> )
      ValueString ( "Metadata" )
    )
  )
)

Example 4: Described Resource URI

By introducing namespace declarations, the qualified name mechanism can be used to abbreviate the described resource URI. The same description set as in the previous example might be encoded as follows.

@prefix page: <http://dublincore.org/pages/> .

DescriptionSet (
  Description (
    ResourceURI ( page:home )
    Statement (
      PropertyURI ( <http://purl.org/dc/terms/subject> )
      ValueString ( "Metadata" )
    )
  )
)

Example 5: Described Resource URI abbreviated using Qualified Name

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 Statements

A description is made up of one or more statements.

A statement is represented using a Statement ( ) syntactic structure.

The following example represents a description consisting of a single statement.

@prefix page: <http://dublincore.org/pages/> .
@prefix dcterms: <http://purl.org/dc/terms/> .

DescriptionSet (
  Description (
    ResourceURI ( page:home )
    Statement (
      PropertyURI ( dcterms:subject )
      ValueString ( "Metadata" )
    )
  )
)

Example 6: Statements

A description may contain multiple statements.

Each statement is represented using a separate Statement ( ) syntactic structure.

The following example represents a description consisting of two statements.

@prefix page: <http://dublincore.org/pages/> .
@prefix dcterms: <http://purl.org/dc/terms/> .

DescriptionSet (
  Description (
    ResourceURI ( page:home )
    Statement (
      PropertyURI ( dcterms:subject )
      ValueString ( "Metadata" )
    )
    Statement (
      PropertyURI ( dcterms:title )
      LiteralValueString ( "DCMI Home Page" )
    )
  )
)

Example 7: Multiple Statements

The order of statements within a description is not significant.

4.3.1 Property URI

A statement must contain exactly one property URI.

A property URI is represented using a PropertyURI ( <uri> ) syntactic structure:

The following example represents a description consisting of a single statement where the property URI is http://purl.org/dc/terms/subject .

@prefix page: <http://dublincore.org/pages/> .
@prefix dcterms: <http://purl.org/dc/terms/> .

DescriptionSet (
  Description (
    ResourceURI ( page:home )
    Statement (
      PropertyURI ( dcterms:subject )
      ValueString ( "Metadata" )
    )
  )
)

Example 8: Property URI

4.4 Value Surrogates

A statement must contain exactly one value surrogate. A value surrogate is either a literal value surrogate or a non-literal value surrogate.

4.4.1 Literal Value Surrogates

A literal value surrogate is made up of exactly one value string.

4.4.1.1 Value Strings

A value string within a literal value surrogate is represented using a LiteralValueString ( ) syntactic structure.

The following example represents a description consisting of a single statement with a literal value surrogate containing a value string.

@prefix page: <http://dublincore.org/pages/> .
@prefix dcterms: <http://purl.org/dc/terms/> .

DescriptionSet (
  Description (
    ResourceURI ( page:home )
    Statement (
      PropertyURI ( dcterms:title )
      LiteralValueString ( "DCMI Home Page" )
    )
  )
)

Example 9: Literal Value Surrogate: Value String

4.4.2 Non-Literal Value Surrogates

A non-literal value surrogate is made up of:

zero or one value URIs
zero or one vocabulary encoding scheme URIs
zero or more value strings

4.4.2.1 Value URI

A value URI is represented using a ValueURI ( <uri> ) syntactic structure:

The following example represents a description consisting of a single statement with a non-literal value surrogate containing a value URI.

@prefix page: <http://dublincore.org/pages/> .
@prefix agent: <http://example.org/agents/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
DescriptionSet (
  Description (
    ResourceURI ( page:home )
    Statement(
      PropertyURI ( dcterms:creator )
      ValueURI ( agent:DCMI )
    )
  )
)

Example 10: Value URIs

4.4.2.2 Vocabulary Encoding Scheme URI

A vocabulary encoding scheme URI is represented using a VocabularyEncodingSchemeURI ( <uri> ) syntactic structure:

The following example represents a description consisting of a single statement with a non-literal value surrogate containing a value URI and a vocabulary encoding scheme URI.

@prefix page: <http://dublincore.org/pages/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix exterms: <http://example.org/terms/> .
@prefix exsh: <http://example.org/sh/> .

DescriptionSet (
  Description (
    ResourceURI ( page:home )
    Statement (
      PropertyURI ( dcterms:subject )
      ValueURI ( exsh:metadata )
      VocabularyEncodingSchemeURI ( myterms:EXSH )
    )
  )
)

Example 11: Vocabulary Encoding Scheme URI

4.4.2.3 Value Strings

A value string within a non-literal value surrogate is represented using a ValueString ( ) syntactic structure.

The following example represents a description consisting of a single statement with a non-literal value surrogate containing a value URI, a vocabulary encoding scheme URI and a value string.

@prefix page: <http://dublincore.org/pages/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix exterms: <http://example.org/terms/> .
@prefix exsh: <http://example.org/sh/> .

DescriptionSet (
  Description (
    ResourceURI ( page:home )
    Statement (
      PropertyURI ( dcterms:subject )
      ValueURI ( exsh:metadata )
      VocabularyEncodingSchemeURI ( exterms:EXSH )
      ValueString ( "Metadata" )
    )
  )
)

Example 12: Non-Literal Value Surrogate: Value String

A non-literal value surrogate may contain multiple value strings.

@prefix page: <http://dublincore.org/pages/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix exterms: <http://example.org/terms/> .
@prefix exsh: <http://example.org/sh/> .

DescriptionSet (
  Description (
    ResourceURI ( page:home )
    Statement (
      PropertyURI ( dcterms:subject )
      ValueURI ( exsh:metadata )
      VocabularyEncodingSchemeURI ( exterms:EXSH )
      ValueString ( "Metadata" )
      ValueString ( "M�tadonn�es" )
    )
  )
)

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

4.5 Value Strings

A value string is either a plain value string or a typed value string.

4.5.1 Plain Value Strings

A plain value string may be associated with a value string language

A value string language is represented using a Language ( tag ) syntactic structure.

@prefix page: <http://dublincore.org/pages/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix exterms: <http://example.org/terms/> .
@prefix exsh: <http://example.org/sh/> .

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

Example 14: Value String Languages

4.5.2 Typed Value Strings

A typed value string must be associated with a syntax encoding scheme URI.

A syntax encoding scheme URI is represented using the SyntaxEncodingSchemeURI ( <uri> ) syntactic structure.

The following example represents a description consisting of a single statement with a non-literal value surrogate containing a value URI and a vocabulary encoding scheme URI.

@prefix page: <http://dublincore.org/pages/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix xs: <http://www.w3.org/2001/XMLSchema#> .
DescriptionSet (
  Description (
    ResourceURI ( page:home )
    Statement (
      PropertyURI ( dcterms:modified )
      ValueString ( "2006-02-14"
        SyntaxEncodingSchemeURI ( xs:date )
      )
    )
  )
)

Example 15: Syntax Encoding Scheme URI

4.6 Descriptions of Non-Literal Values

A description set may contain multiple descriptions, each represented by a Description ( content ) syntactic structure. The order of the structures has no significance.

@prefix page: <http://dublincore.org/pages/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

DescriptionSet (
  Description (
    ResourceURI ( page:home )
    Statement (
      PropertyURI ( dcterms:subject )
      ValueString ( "Metadata" )
    )
  )
  Description (
    Statement (
      PropertyURI ( foaf:name )
      LiteralValueString ( "Dublin Core Metadata Initiative" )
    )
  )
)

Example 16: Multiple Descriptions

A resource which is referred to as a non-literal value in a statement in one description may be the described resource of another description within the description set. If that resource has been assigned a URI, then that URI appears as the value URI in the statement where the resource is referred to as the non-literal value and as a described resource URI in the description of that resource, as shown below:

@prefix page: <http://dublincore.org/pages/> .
@prefix agent: <http://example.org/agents/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

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" )
    )
  )
)

Example 17: Value as Described Resource

In some cases a resource will not have a URI assigned, or the URI will not be known. Such a resource may still be a referred to as a non-literal value in a statement in one description and the described resource of another description in the same description set.

In DC-Text, the association between the statement in the first description and the second description is made by using an identifier for the resource which is local to a DC-Text instance. This local identifier is used in a ValueId ( id ) syntactic construct within one or more Statement ( ) constructs where the resource is referred to as a non-literal value, and in a ResourceId ( id ) construct within a 'Description ( ) construct for which the ''resource'' is the ''described resource''. The content of a ValueId ( id ) construct must match the content of a ResourceId ( id )` construct in the same DC-Text instance.

Note that this is a syntactic mechanism for linking references to values in statements to descriptions of those values: the local identifier itself does not appear in the description set.

@prefix page: <http://dublincore.org/pages/> .
@prefix agent: <http://example.org/agents/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
DescriptionSet (
  Description (
    ResourceURI ( page:home )
    Statement (
      PropertyURI ( dcterms:creator )
      ValueId ( agentDCMI )
    )
  )
  Description (
    ResourceId ( agentDCMI )
    Statement (
      PropertyURI ( foaf:name )
      LiteralValueString ( "Dublin Core Metadata Initiative" )
    )
  )
)

Example 11: Multiple Related Descriptions

Appendix A. Grammar

A DC-Text document is a sequence of Unicode characters encoded in UTF-8 defined by the grammar below. It is specified by means of the version of Extended BNF used in XML 1.0 (Third Edition) [XML]

DC-Text - EBNF

Notes

References

[DCAM]
DCMI Abstract Model Proposed DCMI Recommendation, 2007-04-02
http://dublincore.org/documents/2007/04/02/abstract-model/

[XML]
Extensible Markup Language (XML) 1.0 (Third Edition). W3C Recommendation 04 February 2004.
http://www.w3.org/TR/REC-xml

[XMLS]
XML Schema Part 0: Primer Second Edition. W3C Recommendation 28 October 2004.
http://www.w3.org/TR/xmlschema-0/

[TURTLE]
Turtle - Terse RDF Triple Language
http://www.dajobe.org/2004/01/turtle/

Changes in this version

Revise for DCAM 2007-04-02: remove rich representations, introduce literal value surrogates, no-literal value surrogates

> DCText/2007-04-02