Note: this document is out of date. Please see more recent DCMI documents for details of how to encode DC metadata in RDF/XML:
|
DRAFT PROPOSAL |
This Version: <URL: http://www.ukoln.ac.uk/metadata/resources/dc/datamodel/WD-dc-rdf/WD-dc-rdf-19990701.html>
Latest Version: <URL: http://www.ukoln.ac.uk/metadata/resources/dc/datamodel/WD-dc-rdf/>
Previous Versions:
Editors: Eric Miller, Paul Miller and Dan Brickley
This document is a Working Draft of the Dublin Core Metadata Initiative [DC], and is intended to reflect consensus reached within the Data Model Working Group [DCDM] of that Initiative. Following due consideration within the working group, and a period of open consultation with the wider Dublin Core community, this draft is offered to the Dublin Core Advisory Committee for acceptance and ratification.
Comments and feedback should be sent to the working group mailing list, dc-datamodel@mailbase.ac.uk, the archives for which may be browsed at <URL: http://www.mailbase.ac.uk/lists/dc-datamodel/>.
The Dublin Core Metadata Initiative [DC] is a cross-disciplinary international effort to develop mechanisms for the discovery-oriented description of diverse resources in an electronic environment. The Dublin Core Element Set comprises fifteen elements [DCES] which together capture a representation of essential aspects related to the description of resources.
The majority of work on the Dublin Core has addressed the definition of semantics rather than syntax or structure, allowing rapid conceptual development free of the constraints imposed by specific implementation environments. Whilst beneficial in many ways, this has led to a certain lack of clarity at times, especially in relation to development of 'qualification' mechanisms which enrich descriptions in the Dublin Core. It has also made interoperable implementation difficult, as individual implementors have typically developed their own internal mechanisms for actually encoding Dublin Core; mechanisms which are not always compatible with those of their potential collaborators elsewhere.
A significant number of users currently implement Dublin Core within the HyperText Markup Language (HTML) [HTML], the lingua franca of most pages on the World Wide Web. To this end, a document was recently published [KUNZE] in order to bring some order to the plethora of divergent implementations of Dublin Core in HTML. A related document on the expression of richer Qualified Dublin Core within HTML is approaching completion.
The Dublin Core Data Model working group [DCDM] was set up to look at means by which the richness of the Dublin Core model might be expressed outwith the limitations of HTML. This document represents a technical report on two specific outcomes from this process; a means by which the model may be considered, extended, tested and manipulated within the Resource Description Framework (RDF); and suggested mechanisms by which both simple and complex Dublin Core might be expressed using the eXtensible Markup Language (XML), the formal syntax of RDF. Although RDF is the 'language' used to express the data model, users are not limited to using only RDF in their own applications. Similarly, although examples throughout this document are expressed in XML, this does not mean the Dublin Core may only be encoded in this way.
The following sections introduce the building blocks upon which this document relies, such as XML and RDF. Those who are familiar with these standards may move directly to A Syntax for the Dublin Core.
The eXtensible Markup Language (XML) [XML-SPEC] is a development of the World Wide Web Consortium (W3C) [W3C], derived from the more complex Standard Generalised Markup Language (SGML), and aimed specifically at implementation over the web much as HTML is used today, but with the possibility of greater richness in both content and functionality.
In form, an XML document looks much like one coded in HTML — which in turn resembles SGML — although certain SGML structural conventions which were only loosely adopted in HTML have been made mandatory within a valid XML document.
XML is the syntax chosen to express RDF, and all of the examples within this paper are represented in XML, validated by the Simple RDF Parser and Compiler (SiRPAC) [SIRPAC].
For further information on XML and its uses, visit the World Wide Web Consortium's XML Home Page [XML].
The Resource Description Framework (RDF) [RDF-SPEC] is a further World Wide Web Consortium initiative, building upon earlier developments such as the Dublin Core and the Platform for Internet Content Selectivity (PICS) [PICS] content rating initiative [IANNELLA].
RDF is an attempt to empower effective creation, exchange and use of metadata on the World Wide Web, and therefore addresses many of the same issues as the Dublin Core. Unlike the Dublin Core, however, RDF makes few assumptions about semantics whilst instead defining a coherent structure (for the expression of semantics) and recommending a powerful transport syntax in the form of XML [XML-SPEC]. As such, the combination of structure and syntax offered by RDF in XML is a suitable complement to the semantically rich Dublin Core element set, and the three can be used together to good effect, as demonstrated by this document.
The basic premise behind RDF is a simple one; that an identifiable, addressable 'resource' may be described by means of a selection of 'properties' (size, name, maker, etc.), each of which has an associated 'value' (23 x 45 cm, Moonlight over Columbus, Fred Bloggs, etc.). In certain cases, the statement of a 'property' may, in itself, form a further 'resource', allowing the model to grow, potentially infinitely, by linking information resources together.
As stated above
, XML provides the default syntax used to encode RDF descriptions, and numerous examples of this may be seen later in the paper. At times, it can aid clarity to express RDF descriptions in a diagrammatic form, allowing the distinction between resources, properties and values to become clear. At their most basic, such diagrams take the form demonstrated below.| Figure 1: A simple RDF assertion |  |
Here, a 'resource', http://doc, has a 'property', author, describing some aspect of it. The value of the 'property' is Joe Smith. In other words, Joe Smith is the author of http://doc.
In this diagrammatic form, resources are always represented as ovals. Properties are always represented by arrows which point from the subject of any statement to the object of the statement (Joe Smith is the author of the resource. The resource is not the author of Joe Smith). Where the statement is simply a text string (like "Joe Smith"), it is shown in a rectangular box. In cases where the statement is itself a resource, the statement is represented as an oval which may, in turn, point to further properties, statements and resources.
Presented in XML, the diagram above would be coded as follows, the individual elements of the XML being described further, below.
| Example 1: A simple RDF assertion |
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://doc">
<author> Joe Smith </author>
</rdf:Description>
</rdf:RDF>
|
For further information on RDF and its uses, visit the World Wide Web Consortium's RDF Home Page [RDF].
The great power of both XML and RDF is the ability for individual content providing communities to declare their own modes of expression for the description of resources of importance to them. However, rather than having each community develop a comprehensive system describing all aspects of their resources, XML and RDF offer a more interoperable foundation whereby a single description may comprise elements drawn from any number of accessible recording practices. It therefore becomes possible, for example, for all communities to share the notion of 'authorship' and use the same element for describing this notion, whilst one community then makes use of its own subject classification system and another embeds complex date-related information.
The means by which this rich yet interoperable diversity is facilitated is known as the XML Namespace [XML-NAME], a construct which is adopted in RDF.
At it's most basic, an XML Namespace may be seen as providing human and computer-parseable context for any resource description element. The term, Creator, for example, means a variety of things to different communities. If it were clear, though, that this were the Dublin Core element, Creator, then the semantics of the element and its contents become somewhat clearer.
By using a globally unique assertion such as http://purl.org.dc.elements/1.0/creator to unambiguously identify this concept, XML/RDF allows terms in a metadata vocabulary to be treated as reliably describable objects. This further lays the foundations by which interrelationships between terms and concepts from competing structures may be expressed. Additionally, these unique associations of terms (in any language) with a single authoritative object provide impetus to much of the internationalisation work currently underway within the Dublin Core process [DC-INTERNAT], as a label (in French, say) may be linked with the authoritative definition of its associated element as viewed by the Dublin Core community.
In order to differentiate between terms drawn from different descriptive paradigms, or 'namespaces', the XML Namespace mechanism requires that all elements not core to basic XML be preceded by a shorthand identification of the namespace from which they originate. To make it clear that Creator is the Dublin Core element, it would therefore be preceded by 'dc:'. XML is case sensitive, making it important that 'dc:' be entered consistently as 'dc:', 'Dc:', 'DC:' and 'dC:' would normally be interpreted as shorthands for four totally different namespaces.
To make the human-interpretable link between 'dc:' and the Dublin Core intelligible to a piece of software, RDF descriptions in which the XML Namespace constructs are used begin with a declaration of the namespaces to be used, the location at which they may be resolved by appropriate software, and the abbreviated form by which they may be recognised throughout the RDF description to follow.
To associate 'dc:' with the Dublin Core, for example, an RDF description expressed in XML might begin
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/">
When resolved, suitably enabled software would unpack this statement in order to turn dc:creator into <URL: http://purl.org/dc/elements/1.0/creator>, and by following the link both human and machine may be able to decode the meaning of this element.
From the outset, development of the Dublin Core element set [DCES] has been primarily concerned with the evolution of semantics for the description of resources. Syntax has, to a large extent, been left to individual implementors, allowing the community as a whole to remain focussed upon defining effective semantics for the Core.
The development of RDF provides an environment in which the semantic ideals of Dublin Core may be both preserved and expressed, whilst allowing the simultaneous definition of a syntax utilising the eXtensible Markup Language (XML). A range of other syntaxes may continue to be used by implementors of the Dublin Core, however only the combination of RDF and XML currently offers the range of capabilities required to fully express the richness of both qualified and unqualified Dublin Core in an unambiguous manner.
As discussed above, XML's concept of Namespaces [XML-NAME] is utilised in RDF in order to allow different communities to develop their own means of resource discovery, and for individual descriptions to select from one or more of these community-specific frameworks as required.
The fifteen basic elements of the Dublin Core Element Set [DCES] as defined by RFC 2413 may be considered to comprise a single Namespace, the encoding of which is demonstrated in Appendix 1, and available for reference on the World Wide Web at <URL: http://purl.org/dc/elements/1.0/>.
Although it is permissible to use any character string to identify this Namespace in a description, the Data Model group recommends use of the lower case 'dc:'.
Users who intend to code XML by hand, or write applications which make use of it, should familiarise themselves with the XML specification [XML-SPEC], and with some of the tools and introductory texts for XML that are beginning to appear. Although no substitute for a more detailed grounding in XML, this section offers a number of reminders to key elements of any well formed XML document. In ensuring that documents remain well formed, users are pointed to the emerging range of XML validation tools, such as 'Are You Well Formed?' (RUWF) [RUWF].
Any well-formed XML document will include a statement of the version of XML used. At present, the only valid version of XML, as defined in the W3C Recommendation [XML-SPEC], is 1.0. Documents should therefore include the statement
<?xml version="1.0"?>
on their first line.
It is necessary to declare that RDF is being used, as this brings extra functionality and constraints to a basic XML document. This is done by including
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
as the first line of an RDF description; normally on the line following the XML version declaration. The RDF description must then be closed by appending
</rdf:RDF>
to the end.
As any description of Dublin Core in RDF will require the use of at least the Dublin Core Namespace, this statement will normally be expanded to become
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/">
This expanded statement clearly informs both users and applications that RDF is being used, and may be recognised within this portion of the document by the prefix 'rdf:'. Additionally, Dublin Core is being used and may be recognised within this portion of the document by the prefix 'dc:'. The RDF description must still be closed through use of
</rdf:RDF>after which the definitions of the namespaces become meaningless unless declared again in a new block of RDF.
In XML, the case used in element names is extremely important, such that 'Creator', 'creator', 'CREATOR' and 'cREATOR' are interpreted as four totally different elements.
The Data Model group defines element names expressed wholly in lower case to be best practice (so 'creator', not 'Creator', 'CREATOR' or 'cREATOR'), and this convention must be used where links are made to the Dublin Core Namespace.
This statement of best practice applies only to Dublin Core element names expressed as part of a URI (such as dc:creator, which software might expand to <URL: http://purl.org/dc/elements/1.0/creator>), and has no bearing upon the use of element names in contexts where they are only to be read by human beings.
HTML was rather flexible in it's interpretation of SGML's tagging rules, such that it was possible to use tags (such as <P>) without closing them (with </P> in this example).
In XML, a document will only be considered valid if all tags display both a start tag <TAG> and an end tag </TAG> in all cases.
XML supports the notion of 'empty' tags, which are used for a number of purposes. In these cases, a short hand notation may be adopted, permitting the replacement of <TAG> </TAG> with <TAG />. This shorthand notation is frequently used in RDF, and is especially useful when it comes to encoding elements of a qualified Dublin Core Description, as discussed in Section 3. Section 2.3 also illustrates use of these empty tags for RDF's abbreviated syntax, where the bulk of the description is stored inside an empty <rdf:Description /> tag.
An advantage of using an established syntax such as XML is that it provides certain extra tools and features that the Dublin Core community would otherwise need to develop separately.
It has long been argued, for example, that a need exists to identify the language in which a piece of metadata is expressed. This language may well be different from the language of the resource being described, which can be entered in the Dublin Core's Language element, but is often vital to the resource discovery process.
Catalogued in a German search engine, for example, this document would still be in English, but its title may be given in German to aid discovery by German speakers. Dublin Core provides the ability, via <dc:language>, to express the language of the document itself. XML, via the <xml:lang> declaration [XML-LANG], provides the ability to identify the languages in which individual elements of metadata are expressed, and the Dublin Core data model simply utilises this mechanism. See Example 14 for an example of metadata expressed in different languages.
| Example 2 |
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://doc">
<author> Joe Smith </author>
</rdf:Description>
</rdf:RDF>
|
| Example 3 |
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/">
<rdf:Description rdf:about="http://doc">
<dc:creator> Joe Smith </dc:creator>
</rdf:Description>
</rdf:RDF>
|
| Example 4 |
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/">
<rdf:Description rdf:about="http://www.ukoln.ac.uk/metadata/resources/dc/datamodel/
WD-dc-rdf/">
<dc:title> Guidance on expressing the Dublin Core within the Resource Description
Framework (RDF) </dc:title>
<dc:creator> Eric Miller </dc:creator>
<dc:creator> Paul Miller </dc:creator>
<dc:creator> Dan Brickley </dc:creator>
<dc:subject> Dublin Core; Resource Description Framework; RDF; eXtensible
Markup Language; XML </dc:subject>
<dc:publisher> Dublin Core Metadata Initiative </dc:publisher>
<dc:contributor> Dublin Core Data Model Working Group </dc:contributor>
<dc:date> 1999-07-01 </dc:date>
<dc:format> text/html </dc:format>
<dc:language> en </dc:language>
</rdf:Description>
</rdf:RDF>
|
Functionally richer — and therefore recommended — ways of expressing the contents of the creator and subject elements are discussed in association with Example 14, below.
As described elsewhere [KUNZE], methods exist whereby Dublin Core metadata may be embedded in web pages using HTML's [HTML] <META> tag construct [HTML-META].
It is also possible to embed RDF-based Dublin Core in web pages, as may be seen by viewing the source of this document and examining the <HEAD> ... </HEAD> area. However, the basic RDF syntax utilised in the examples throughout this paper is not suitable for embedding in HTML documents, due to the inconsistent manner in which it is treated by the current generation of web browsing software, and a special abbreviated syntax [RDF-ABBREV] must be used instead.
This syntax is discussed more fully in the RDF Model and Syntax specification [RDF-SPEC], but principally involves including all of the metadata description within the <rdf:Description...> statement such that;
| Example 5: Basic Syntax |
|
<?xml version="1.0"?> |
would become
| Example 6: Abbreviated Syntax |
|
<?xml version="1.0"?> |
where text in red has been removed from Example 5 to make Example 6, and text in green appears for the first time in Example 6.
The two syntaxes mean essentially the same thing, although the former may be considered less ambiguous, whilst the latter allows straightforward embedding into HTML web documents.
Rather than resorting to the abbreviated syntax, Dublin Core that is encoded using the basic RDF syntax shown in examples throughout this paper may, alternatively, be left external to the HTML document itself and associated with it by means of the HTML <LINK> element. The recommended relation type for this purpose is REL="meta", for example:
<LINK rel="meta" href="mydoc.html.rdf">where "mydoc.html" is the name of the HTML document being described.
The less ambiguous basic syntax is used elsewhere in this document and, for the sake of clarity, is recommended for use in cases where embedding in web pages is not required.
The discussion, above, includes all of the information required to implement RFC 2413-compliant Dublin Core in RDF. However, the wider Dublin Core community has long sought to increase the richness of their descriptions through the use of qualification and substructure. Due to the manner in which these extensions to the basic fifteen elements evolved, a number of solutions arose, with current implementations including such notions as 'scheme', 'type' and 'subelement', and the majority of coding solutions involving the use of convoluted pseudo-hierarchical strings such as DC.Creator.personalName, etc.
Many of these current solutions work, but they are based upon a series of compromises and coded in a far from logical manner. The use of RDF allows clarification of the meaning of this substructuring, prior to offering a sound means of representing it in XML/RDF.
There has been a tremendous amount of discussion regarding the types of qualification most useful to the range of communities represented in the Dublin Core process. The following list is an attempt to capture some of the different requirements which have emerged:
In considering the ways in which a Dublin Core element might usefully be qualified or enhanced, it became clear to the Data Model group that the existing possibilities through such constructs as Schemes, Types and Subelements served only to confuse, with similar tasks often being tackled by means of different solutions. Rather than attempting to represent the current structure in RDF, the Data Model group considered the needs of qualification in the abstract and evolved a suitable solution to Dublin Core's requirements. This solution is outlined below, and may be easily mapped to existing implementations of Dublin Core substructure and qualification.
Use of the confusing term 'Subelement' is deprecated as a label for aspects of element qualification.
Examined in the abstract, it became clear that qualification takes two main forms in Dublin Core applications; those qualifiers that refine or enhance the meaning of the element (totally hypothetically, 'modification date' might be a refinement of the Dublin Core element, Date), and those that refine or enhance the interpretation of the value (knowing that '1999-04-12' is encoded according to the rules of ISO 8601 greatly enhances a reader's ability to interpret the value, as it becomes clear that the twelfth day of April is being expressed, rather than the fourth day of December).
The basic model for qualifying Dublin Core can be represented graphically in the following diagram. As well as the rectangular box (representing a text string) and oval (representing a resource) introduced previously, this diagram makes use of a pentagon to demonstrate cases in which the arrow may point at either a text string or a resource whilst remaining valid.
For the sake of interoperability, and to enable future enhancement of these resource descriptions, it is strongly recommended that use of simple text strings be deprecated in favour of properly addressable resources. i.e., a URI locating the term, illustrator, within an online thesaurus or controlled terminology is preferable to use of the text string, "illustrator".
| Figure 2: An illustration of the Dublin Core Data Model |
 |
The components of this fully elaborated illustration include:
"A resource can be 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 other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources."
[RFC2396]
Importantly, a resource in RDF must always be identifiable by means of a URI of some kind.
An element is a specific
characteristic or attribute of a resource. An element, in terms of the RDF
data model [RDF-SPEC], is analogous to a property.
Each element (or property) defined by the Dublin Core
community has a specific semantic meaning and may define
its permitted values, the types of resources it can
describe, and its relationship with other elements. The
Dublin Core Element Set [DCES] defines a set properties and
associated semantics common to many resource description
communities.
Literals are simple text
strings. Literals may have structured content (e.g. XML
markup) but are not further evaluated by the RDF processor. There are some
syntactic restrictions on how markup in literals may be
expressed; see Section
2.2.1 in the RDF Model and
Syntax Specification.
Element qualifiers are the solution proposed in order to meet the requirement (identified above) of many implementors to specify aspects of a given resource with greater precision than is offered by the fifteen Dublin Core elements. Element Qualifiers would, for example, allow the broad concept of date (handled within Dublin Core's Date element) to be further subdivided into (hypothetically) date of creation, date of last modification, etc.
Element Qualifiers correspond loosely to the notion of 'types' or 'subelements' in some early implementations of the Dublin Core.
An Element Qualifier
refines the semantics of a
Dublin Core element to further specify the relationship
of the element to the resource itself. The Element
Qualifier does not change the definition of the element,
nor does it modify the value. Recommended practice is to
use an Element Qualifier from a controlled list of
Element Qualifier Terms defined for that element or from
a domain specific list approved and maintained by a
particular community.
Element Qualifier Terms represent permissible values for any given Element Qualifier. By separating the generic enabling mechanisms (the Element Qualifiers) from the actual qualifications themselves (the Element Qualifier Terms) it remains possible to provide guidance on the ways in which qualification should be undertaken without the necessity to create an all-encompassing set of terms from which all communities should select.
For example, the ability to qualify the Date element is widely accepted by Dublin Core implementors. The need for a specific type of Date recording the date of accession is not so universal. The generic (community-wide) Element Qualifier might therefore be dateType, whilst one implementation permits the locally useful Element Qualifier Term accessioned to be used along with this Element Qualifier.
The manner in which this extensibility mechanism works is illustrated in the Examples.
Value Qualifiers are the solution proposed in order to meet the requirement (identified above) of many implementors to specify the manner in which a value is encoded, normally with reference to some list of controlled terms or to a set of parsing rules. Value Qualifiers would, for example, allow the Date, 1999-04-12, to be unambiguously associated with the ISO 8601 standard for expressing dates; thus making it clear that the 12th of April is being described, rather than the 4th of December.
Value Qualifiers correspond loosely to the notion of 'schemes' in some early implementations of the Dublin Core.
A Value Qualifier refers to the value, specifying either an encoding rule or a controlled vocabulary to aid in interpreting the value. Recommended practice is to use a Value Qualifier generally understood by the target community, or a standard encoding or parsing scheme in wide use across communities.
Value Qualifier Terms represent permissible values for any given Value Qualifier. By separating the generic enabling mechanisms (the Value Qualifiers) from the actual qualifications themselves (the Value Qualifier Terms) it remains possible to provide guidance on the ways in which qualification should be undertaken without the necessity to create an all-encompassing set of terms from which all communities should select.
For example, the ability to identify the encoding used for values in the Date element is widely accepted by Dublin Core implementors. The need for specific reference to encoding in the Gregorian calendar is not so universal. The generic (community-wide) Value Qualifier might therefore be dateScheme, whilst one implementation permits the locally useful Value Qualifier Term Gregorian to be used along with this Value Qualifier.
The manner in which this extensibility mechanism works is illustrated in the Examples.
The central oval in Figure 2 is known as an 'Intermediate Node', and is the diagrammatic means by which a series of related statements are grouped together. Unlike named resources (those with some form of label text inside the oval), these intermediate nodes do not represent tangible or identifiable resources.
Represented in the XML syntax (see Example 8 for illustration), the group of values pointed to from one of these 'Intermediate Nodes' would be gathered within a single <RDF:Description...> instance.
Although not represented in Figure 2, Value Components are an important part of the Dublin Core model, allowing pieces of a resource description to be grouped together and identified as aspects — or components — of some whole independent of the resource being described.
Value Components are semantic characteristics (e.g. the name, hair colour, eye colour and social security number of a person) of a value. These characteristics may be drawn from existing vocabularies or defined within specific communities. Value Components are intrinsic to the value regardless of its relationship to a particular resource.
See Example 12 for one instance of a Value Component.
In many applications, the repetition and grouping of elements or their values is desirable. RDF provides useful constructs for such grouping[RDF-SPEC]. These include:
The use of these constructs (when appropriate) is encouraged when repeating elements, values, element qualifiers and value qualifiers, and may be seen in Example 14.
In a heterogeneous environment such as that in which the Dublin Core operates, it is necessary to offer a means by which perceived over-complexity may be handled. Such a need is manifested in cases where users or software expecting 'simple' Dublin Core (as described in Section 2) encounter 'qualified' Dublin Core (as described in Section 3), as well as in situations where users or software able to handle 'qualified' Dublin Core encounter terminology from additional namespaces with which they are unfamiliar, and which they do not wish to resolve through reference to the namespace declaration itself.
In both cases, a clear and unambiguous mechanism is required by which the acceptable values (unqualified text in the first example, and values only from understood namespaces in the second) may be extracted from the Description in such a way that intelligible results are obtained without significant loss of value.
Expressed in English, the mechanism proposed is that tools simply ignore any resources originating from intermediate structural nodes in the node-and-arc diagram, and follow the chain of rdf:value arcs until they terminate in a character string. The content of that character string is then returned as the value of the Dublin Core element.
| Figure 3: A qualified Dublin Core statement | |
 |
|
| Figure 4: The statement, above, after dumbing down | |
 |
|
The metadata ecology of the Internet will be partitioned into many modular niches, each targeted to particular functions or communities. Such niches are often represented as namespaces, or controlled vocabularies. XML (the underlying encoding idiom of RDF) provides a native namespace facility that is useful for partitioning authority for the management of such element sets and their qualifiers.
The 15 elements of the Dublin Core represent a namespace of bounded function (resource discovery). The combination of the namespace token (conventionally, dc: has been used for Dublin Core) and an element name identifies a defined description field of clearly defined scope. The syntactic conventions for unambiguously identifying the namespace are provided by the namespace declaration of XML [XML-NAME].
In the Dublin Core namespace the semantics of 15 elements are defined. In order to be explicit when combining semantics from multiple namespaces, the namespace identifier token (i.e. 'dc:') is prepended to these elements in order to uniquely identify each element. Thus the element <dc:title> could be interpreted as <URL: http://purl.org/dc/elements/1.0/title> or "the 'Title' as defined by the Dublin Core Community", and could be resolved by either the human reader or by a suitable software agent upon looking up the reference definition formed by the URL.
The requirement for additional substructure for the Dublin Core elements and the permissible terms or values associated with this substructure has been evident from the inception of the Dublin Core. The Data Model Working Group is persuaded that these additional qualifiers and qualifying mechanisms should be managed under a separate, but closely related namespace of Dublin Core Qualifiers. Thus, the semantic declaration of the 15 elements will be managed in a particular namespace (dc:), and generic qualifying mechanisms promoted by the Dublin Core community will be managed in an additional namespace (dcq:) available to those in need of the extra functionality it offers.
Finally, a non-exclusive set of commonly used terms and values might additionally be defined in the dct: namespace.
Users and implementors are therefore free to adopt and support the basic Dublin Core (as represented by dc:) on its own. Additionally, they may choose to embrace the extensibility mechanisms offered through dcq:. Finally, those using dcq: are further able to make use of commonly requested terms and values within the dct: namespace, and/or to utilise their own lists.
| Namespace Definition |
Namespace Prefix |
Namespace URI |
Namespace Declaration |
| The Dublin Core Namespace |
dc | http://purl.org/dc/elements/1.0/ | xmlns:dc="http://purl.org/ dc/elements/1.0/" |
| The Dublin Core Qualifier Namespace |
dcq | http://purl.org/dc/qualifiers/1.0/ | xmlns:dcq="http://purl.org /dc/qualifiers/1.0/" |
| The Dublin Core Terms Namespace |
dct | http://purl.org/dc/terms/1.0/ | xmlns:dct="http://purl.org /dc/terms/1.0/" |
Additionally, through this type of modular design, domain specific descriptive communities will be able to layer descriptive namespaces that support their respective requirements.
The declarations of the dc: and dcq: namespaces are to be found in appendices 1 and 2, although prospective users should always visit the Namespace URIs listed above in order to check for the most current versions.
The interaction of these namespaces to support resource description is the focus of the next section.
The basic definition of the fifteen Dublin Core elements [DCES] enshrined in the Dublin Core Namespace, dc:, is sufficient to enable creation of and interaction with Dublin Core metadata descriptions compliant with RFC 2413.
In order to support qualification of these elements, Element Qualifiers and Value Qualifiers associated with each of the elements must be defined. The Dublin Core Qualifier Namespace (dcq:) at <URL: http://purl.org/dc/qualifiers/1.0/> has been reserved for these declarations. The following table reflects these declarations.
The RDF instance of this declaration can be found in Appendix 2, although users and developers should always refer to the Namespace itself for the most definitive version.
It is worth noting that the following are the machine readable — and often effectively invisible — Element Qualifiers; the human readable labels are application specific, and will frequently be more user friendly in terminology.
| Element | Element Qualifier | Value Qualifier | Value Type |
| dc:title | dcq:titleType | dcq:titleScheme | rdf:type |
| dc:creator | dcq:creatorType | dcq:creatorScheme | rdf:type |
| dc:subject | dcq:subjectType | dcq:subjectScheme | rdf:type |
| dc:description | dcq:descriptionType | dcq:descriptionScheme | rdf:type |
| dc:publisher | dcq:publisherType | dcq:publisherScheme | rdf:type |
| dc:contributor | dcq:contributorType | dcq:contributorScheme | rdf:type |
| dc:date | dcq:dateType | dcq:dateScheme | rdf:type |
| dc:type | dcq:typeType | dcq:typeScheme | rdf:type |
| dc:format | dcq:formatType | dcq:formatScheme | rdf:type |
| dc:identifier | dcq:identifierType | dcq:identifierScheme | rdf:type |
| dc:source | dcq:sourceType | dcq:sourceScheme | rdf:type |
| dc:language | dcq:languageType | dcq:languageScheme | rdf:type |
| dc:relation | dcq:relationType | dcq:relationScheme | rdf:type |
| dc:coverage | dcq:coverageType | dcq:coverageScheme | rdf:type |
| dc:rights | dcq:rightsType | dcq:rightsScheme | rdf:type |
Implementation experience has shown that, whatever their background, the majority of implementors tend to come up with lists of qualifying values for the Dublin Core in which there is significant overlap with those lists developed by others.
Whilst not intending to constrict the ways in which implementors may link to their own terminologies utilising the enabling mechanisms provided by the dcq: Namespace, the Data Model group was keen to provide a means of allowing easy access to these commonly used qualifications in order to promote widespread interoperability.
The Dublin Core Terms Namespace (dct:) at <URL: http://purl.org/dc/terms/1.0/> has been reserved for these declarations, and the terms themselves are under discussion within the Dublin Core Working Group process.
The examples, below, are intended to illustrate aspects of the model outlined in this document.
The following example reflects the statement that "Joe Smith" is the creator of the resource http://doc.
| Figure 5: Diagrammatic RDF Representation |
 |
| Syntactic RDF Representation |
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/">
<rdf:Description rdf:about="http://doc">
<dc:creator> Joe Smith </dc:creator>
</rdf:Description>
</rdf:RDF>
|
The following example reflects the statement that "Joe Smith" is the illustrator of the resource http://doc. Illustrator is a type of Creator.
| Figure 6: Diagrammatic RDF Representation |
 |
| Syntactic RDF Representation |
<?xml version='1.0'?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc = "http://purl.org/dc/elements/1.0/"
xmlns:dcq = "http://purl.org/dc/qualifiers/1.0/">
<rdf:Description rdf:about = "http://doc">
<dc:creator>
<rdf:Description>
<rdf:value> Joe Smith </rdf:value>
<dcq:creatorType> Illustrator </dcq:creatorType>
</rdf:Description>
</dc:creator>
</rdf:Description>
</rdf:RDF>
|
The following example also reflects the statement that "Joe Smith" is the illustrator of the resource http://doc. Illustrator is still a type of Creator, but this time the term has been drawn from a controlled namespace of terms.
The value of creatorType, dct:Illustrator, utilised in this example has not yet been formally approved by the Dublin Core community, and is included for demonstration purposes only. This is an example of a Value Term, the definitive list of terms for which is currently under development within the Working Group process.
| Figure 7: Diagrammatic RDF Representation |
 |
| Syntactic RDF Representation |
<?xml version='1.0'?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc = "http://purl.org/dc/elements/1.0/"
xmlns:dcq = "http://purl.org/dc/qualifiers/1.0/">
<rdf:Description rdf:about = "http://doc">
<dc:creator>
<rdf:Description>
<rdf:value> Joe Smith </rdf:value>
<dcq:creatorType rdf:resource = "http://purl.org/dc/terms/1.0/creator/type/
Illustrator"/>
</rdf:Description>
</dc:creator>
</rdf:Description>
</rdf:RDF>
|
The following example also reflects the statement that "Joe Smith" is the illustrator of the resource http://doc. Illustrator is still a type of Creator, with the term drawn from a controlled namespace of terms.
The value of creatorType, dct:Illustrator, utilised in this example has not yet been formally approved by the Dublin Core community, and is included for demonstration purposes only. This is an example of a Value Term, the definitive list of terms for which is currently under development within the Working Group process.
In Example 9 the value of creatorType, dct:Illustrator, was expressed by means of a full URI as part of the rdf:resource qualification of dcq:creatorType. Expression of Value Qualifiers in this way can make them difficult for the human reader to interpret, so a shorthand notation may be used to make the same statement with direct reference to the additional dct: namespace. As may be seen by comparing Figures 7 and 8, the diagrammatic representation changes slightly in order to accommodate this enhanced readability for the syntactic form.
The exact manner in which terms will be drawn from the dct: namespace is still under discussion within the Working Group. The way in which the namespace is defined in this example, pointing specifically to the location (http://purl.org/dc/terms/1.0/creator/type/) from which the value will be drawn, does not scale well, and will probably be replaced by a more elegant solution. Nevertheless, the concept being demonstrated whereby terms from a namespace may be expressed in this shorthand fashion remains valid.
| Figure 8: Diagrammatic RDF Representation |
 |
| Syntactic RDF Representation |
<?xml version='1.0'?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc = "http://purl.org/dc/elements/1.0/"
xmlns:dcq = "http://purl.org/dc/qualifiers/1.0/"
xmlns:dct = "http://purl.org/dc/terms/1.0/creator/type/">
<rdf:Description rdf:about = "http://doc">
<dc:creator>
<rdf:Description>
<rdf:value> Joe Smith </rdf:value>
<dcq:creatorType>
<dct:Illustrator />
</dcq:creatorType>
</rdf:Description>
</dc:creator>
</rdf:Description>
</rdf:RDF>
|
The following example reflects the statement that "Joe Smith" is the creator of the resource http://doc. The character string representing "Joe Smith" is encoded according to the VCARD specification [VCARD].
The value of creatorScheme utilised in this example, dcq:vcard, has not yet been formally approved by the Dublin Core community, and is included for demonstration purposes only. This is an example of a Value Term, the definitive list for which is currently under development within the Working Group process.
| Figure 9: Diagrammatic RDF Representation |
 |
| Syntactic RDF Representation |
<?xml version='1.0'?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc = "http://purl.org/dc/elements/1.0/"
xmlns:dcq = "http://purl.org/dc/qualifiers/1.0/">
<rdf:Description rdf:about = "http://doc">
<dc:creator>
<rdf:Description>
<rdf:value> fn:Joe Smith </rdf:value>
<dcq:creatorScheme rdf:resource = "http://purl.org/dc/terms/1.0/creator/scheme/
vcard"/>
</rdf:Description>
</dc:creator>
</rdf:Description>
</rdf:RDF>
|
The following example reflects the statement that "Joe Smith" is the creator of the resource http://doc. This person has characteristics (which are defined by another community, in this case VCARD [VCARD]) which include a name "Joe Smith" and email address "joe@my.com" and an affiliation "My Company, Inc.".
Within the Dublin Core Data Model, these 'characteristics' of Joe Smith are known as Value Components.
The value of creatorType utilised in this example, dct:Illustrator, has not yet been formally approved by the Dublin Core community, and is included for demonstration purposes only. This is an example of a Value Term, and the definitive list of terms is currently under development within the Working Group process.
The VCARD Namespace proposed in this example remains hypothetical, although discussions are underway in order to make it reality.
| Figure 10: Diagrammatic RDF Representation |
 |
| Syntactic RDF Representation |
<?xml version='1.0'?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc = "http://purl.org/dc/elements/1.0/"
xmlns:vcard = "http://www.imc.org/vcard/3.0/">
<rdf:Description rdf:about = "http://doc">
<dc:creator>
<rdf:Description>
<vcard:fn> Joe Smith </vcard:fn>
<vcard:email> joe@my.com </vcard:email>
<vcard:org> My Company, Inc. </vcard:org>
</rdf:Description>
</dc:creator>
</rdf:Description>
</rdf:RDF>
|
The following example reflects the statement that a specific, uniquely identifiable person is the creator of the resource http://doc. This person has characteristics (which are defined by another community, in this case VCARD [VCARD]) which include a name "Joe Smith" and email address "joe@my.com" and an affiliation "My Company, Inc.".
In this case, the 'Joe Smith' in question is being identified in a less ambiguous manner than in previous examples. A hypothetical 'directory enquiries' service is being demonstrated using the 411.com URI, whereby the individual, Joe Smith, is associated with a single URI that might — or might not — provide such details as social security number, current employer, address, etc. Alternative URI's might include a link to a specific individual's entry in a corporate X.500 database or their social security or national insurance number, suitably qualified with an appropriate namespace declaration, all of which serve to allow a near-explicit declaration of which Joe Smith (out of the thousands likely to exist) is being described.
It is important to note that the 411.com URI is not the URI of Joe Smith's home page on the web, as it is unreasonable to suggest that an individual's personal home page could be considered to represent them in this fashion. Rather, the URI is simply a means by which the individual may be identified in as unambiguous a fashion as possible.
The value of creatorType utilised in this example, dct:Illustrator, has not yet been formally approved by the Dublin Core community, and is included for demonstration purposes only. This is an example of a Value Term, and the definitive list of terms is currently under development within the Working Group process. Also, the notion of a class, 'person', is proposed by the Data Model Group, but the exact method by which it will be implemented has yet to be agreed. Its use in this example should therefore be considered experimental at this time.
The VCARD Namespace proposed in this example remains hypothetical, although discussions are underway in order to make it reality.
| Figure 11: Diagrammatic RDF Representation |
 |
| Syntactic RDF Representation |
<?xml version='1.0'?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc = "http://purl.org/dc/elements/1.0/"
xmlns:dcq = "http://purl.org/dc/qualifiers/1.0/"
xmlns:vcard = "http://www.imc.org/vcard/3.0/">
<rdf:Description rdf:about = "http://doc">
<dc:creator>
<rdf:Description>
<rdf:type rdf:resource = "http://purl.org/dc/terms/1.0/creator/class/Person"/>
<dcq:creatorType rdf:resource = "http://purl.org/dc/terms/1.0/creator/type/
Illustrator"/>
<rdf:value rdf:resource = "http://411.com/JoeSmith"/>
</rdf:Description>
</dc:creator>
</rdf:Description>
<rdf:Description rdf:about = "http://411.com/JoeSmith">
<vcard:fn> Joe Smith </vcard:fn>
<vcard:email> joe@my.com </vcard:email>
<vcard:org> My Company, Inc.</vcard:org>
</rdf:Description>
</rdf:RDF>
|
The following example illustrates a more complete record, in this case a description of this document. The example differs from that given in Section 2.2 as it includes some limited qualification of the Dublin Core Element Set, as introduced from Section 3 onwards.
In grouping the editors' names, the <rdf:Bag> structure is used to indicate collective editorship of the document (i.e. that the three editors are related to the report as a group, rather than as individuals). Note that both this <rdf:Bag> structure and the repeating of <dc:creator> as in Example 4 are syntactically valid RDF, but the approach taken here is preferred as any possible ambiguity as to the relationship between the editors is removed.
A second RDF grouping mechanism is also used in this example, to offer alternative languages for some of the metadata. Use of <xml:lang> in this fashion is discussed in Section 2.2.2.
Note the addition of an encoding statement to the XML version declaration on the first line. This statement is necessary to allow correct display of the 'foreign' characters in the multilingual text.
| Example 14 |
<?xml version="1.0" encoding="ISO-8859-1"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.0/">
<rdf:Description rdf:about="http://www.ukoln.ac.uk/metadata/resources/dc/datamodel/
WD-dc-rdf/">
<dc:title>
<rdf:Alt>
<rdf:li xml:lang="en">Guidance on expressing the Dublin Core within the Resource
Description Framework (RDF)</rdf:li>
<rdf:li xml:lang="no">Veiledning å uttrykke Dublin Core innenfor rammen av
Resource Description Framework (RDF)</rdf:li>
<rdf:li xml:lang="de">Dublin Core in RDF: Eine Anleitung</rdf:li>
</rdf:Alt>
</dc:title>
<dc:creator>
<rdf:Bag>
<rdf:li>Eric Miller</rdf:li>
<rdf:li>Paul Miller</rdf:li>
<rdf:li>Dan Brickley</rdf:li>
</rdf:Bag>
</dc:creator>
<dc:description>
<rdf:Alt>
<rdf:li xml:lang="en">This document describes work carried out by the Data Model
Working Group of the Dublin Core Metadata Initiative.
Specifically, the document discusses means by which the fifteen elements of the
Dublin Core (as defined in RFC 2413) may be expressed using the Resource Description
Framework (RDF) and encoded with the eXtensible Markup Language (XML). RDF-based
mechanisms by which the 15 elements may be qualified are also introduced.</rdf:li>
<rdf:li xml:lang="no">Dette dokumentet beskriver arbeide utført av arbeidsgruppen
for datamodellering knyttet til Dublin Core-initiativet.
Spesifikt diskuterer dokumentet hvordan de femten elementene i Dublin Core (slik
disse er definert i RFC 2413) kan uttrykkes ved hjelp av Resource Description
Framework (RDF) og kodes ved hjelp av eXtensible Markup Language (XML). Videre
introduseres RDF-baserte mekanismer for å kvalifisere de 15 elementene.</rdf:li>
</rdf:Alt>
</dc:description>
<dc:subject> Dublin Core; Resource Description Framework; RDF; eXtensible
Markup Language; XML </dc:subject>
<dc:publisher> Dublin Core Metadata Initiative </dc:publisher>
<dc:contributor> Dublin Core Data Model Working Group </dc:contributor>
<dc:date>
<rdf:Description>
<dcq:dateScheme> WTN8601 </dcq:dateScheme>
<rdf:value> 1999-07-01 </rdf:value>
</rdf:Description>
</dc:date>
<dc:format>
<rdf:Description>
<dcq:formatScheme> IMT </dcq:formatScheme>
<rdf:value> text/html </rdf:value>
</rdf:Description>
</dc:format>
<dc:language>
<rdf:Description>
<dcq:languageScheme> RFC1766 </dcq:languageScheme>
<rdf:value> en </rdf:value>
</rdf:Description>
</dc:language>
</rdf:Description>
</rdf:RDF>
|
With the increasing availability of electronic information in a plethora of forms, the need for an effective means by which these resources might be described grows ever greater.
Existing mechanisms to describe particular forms of resource within individual communities continue to improve, but the need is most pressing between and across communities, as the barriers of old become less relevant to a modern information society and scholars attempt to move seamlessly across these communities on the trail of subject-spanning concepts and issues.
Originally developed from very separate ideas, the current convergence of the concepts behind Dublin Core with the syntactic and structural facilities offered by XML and RDF offers a powerful weapon in the arsenal of those manipulating and using the wealth of information with which we are surrounded.
Dublin Core offers a means by which diverse resources might be described for discovery in an interdisciplinary context, and XML/RDF provides the structure for unambiguous expression of this Dublin Core information, as well as the straightforward addition of more detailed descriptions from the communities concerned.
Documents forthcoming from the Dublin Core Metadata Initiative will serve to clarify the model upon which these potentials are based, and will begin to illustrate the manner in which Dublin Core-based metadata acts as a key capable of unlocking the riches of many disciplinary treasure chests.
[DC] Dublin Core Metadata Initiative Home Page <URL: http://purl.org/dc/>
[DCDM] Dublin Core Data Model Working Group <URL: http://purl.org/dc/groups/datamodel.htm>
[DCES] Dublin Core Metadata Element Set: Reference Description <URL: http://purl.org/dc/about/element_set.htm>
[DC-INTERNAT] Dublin Core Internationalisation Working Group, <URL: http://purl.org/dc/groups/languages.htm>
[HTML] HyperText Markup Language Home Page <URL: http://www.w3.org/MarkUp/>
[HTML-META] HTML 4.0 Specification — The META element <URL: http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4.4.2>
[IANNELLA] An Idiot's Guide to the Resource Description Framework by Renato Iannella, January 25, 1999.
[KUNZE] Encoding Dublin Core Metadata in HTML by John Kunze, March 18, 1999.
[LAGOZE] The Warwick Framework: A Container Architecture for Diverse Sets of Metadata by Carl Lagoze, July/August 1996.
[PICS] W3C Platform for Internet Content Selection (PICS) Home Page <URL: http://www.w3.org/pics/>
[RDF] W3C RDF Home Page <URL: http://www.w3.org/RDF>
[RDF-ABBREV] W3C Recommendation of Resource Description Framework (RDF) Model and Syntax; RDF Abbreviated Syntax <URL: http://www.w3.org/TR/REC-rdf-syntax/#abbreviatedSyntax>
[RDF-SPEC] W3C Recommendation of Resource Description Framework (RDF) Model and Syntax Specification <URL: http://www.w3.org/TR/REC-rdf-syntax/>
[RFC2396] Uniform Resource Identifiers (URI): Generic Syntax, Internet RFC 2396. <URL: http://info.internet.isi.edu/in-notes/rfc/files/rfc2396.txt>
[RUWF] Are You Well Formed? XML validation tool <URL: http://www.xml.com/xml/pub/tools/ruwf/check.html>
[SIRPAC] Simple RDF Parser And Compiler (SiRPAC) RDF validation tool <URL: http://www.w3.org/RDF/Implementations/SiRPAC/>
[VCARD] VCARD 3.0 specification, RFC 2425 <URL: http://www.imc.org/rfc2425> and RFC 2426 <URL: http://www.imc.org/rfc2426>
[W3C] World Wide Web Consortium (W3C) Home Page <URL: http://www.w3.org/>
[XML] W3C XML Home Page <URL: http://www.w3.org/XML>
[XML-LANG] W3C Recommendation of eXtensible Markup Language (XML) 1.0; Language Identification <URL: http://www.w3.org/TR/REC-xml#sec-lang-tag>
[XML-NAME] XML Namespace Working Draft: <URL: http://www.w3.org/TR/1998/WD-xml-names-19980802>, August 2, 1998.
[XML-SPEC] W3C Recommendation of eXtensible Markup Language (XML) 1.0 <URL: http://www.w3.org/TR/REC-xml>
This document is the work of the Dublin Core's Data Model working group. This working group has been most ably chaired by Misha Wolf of Reuters, with the face-to-face meetings bravely moderated by Ron Daniel.
The members of the working group who helped to develop the ideas expressed here include Youcef Amerouali, Ann Apps, J Azevedo, Tom Baker, David Bearman, Hans Becker, Dave Beckett, Barbera Bikker, Geri Bunker, Debbie Campbell, Daphne Charles, Robina Clayphan, David Cohen, Simon Cox, Michael Day, Lorcan Dempsey, Martin Dillon, Thierry Dufez, Erik Duval, Bernhard Eversberg, Jeremy Frumkin, Jonathan Furner, Tracy Gardner, Stephen Graham, Katrin Grosse, Hisakazu Hada, Juha Hakala, Gisle Hannemyr, Kazuo Haraoka, Rachel Heery, Christina Hengel, Diane Hillmann, Joanne Hooper, Alexander Hoshaba, William Hutchison, Renato Iannella, Erik Jul, Markus Klink, Jon Knight, John Kunze, Carl Lagoze, Karen Lang, Haimin Lee, Sigfrid Lundberg, Carl Mattocks, Cliff Morgan, Pramitha Munjandira, Loren Parker, Judith Pearce, John Perkins, Francisco Pinto, Andy Powell, Diann Rusch-Feja, Donnell Ruthenberg, Andre S, Lee Sang-Cheol, Roland Schwaenzl, Judy Silvasi-Patchin, Jane Sledge, Erin Stewart, Bill Stuart, Ed Summers, Ralph Swick, Benoit Thirion, Chris Thompson, Sally Tseng, Kimmo Tuominen, Yuri Volkov, Nigel Ward, Andrew Waugh, Lisa Weber, Stu Weibel, Berthold Weiss, and Hendro Wicaksono, and the editors apologise if any of their inputs have been misrepresented in this document.
The text, below, is offered as an illustration of the basic Dublin Core Namespace, dc:, as of 21 April 1999. Readers are reminded that the definitive version of this evolving namespace is available online at <URL: http://purl.org/dc/elements/1.0/>.
<? xml version='1.0'?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/TR/REC-rdf-syntax#"
xmlns:rdfs="http://www.w3.org/TR/WD-rdf-schema#"
xmlns:dc="">
<rdf:Description rdf:about = "">
<dc:title> The Dublin Core Element Set </dc:title>
<dc:creator> The Dublin Core Metadata Inititative </dc:creator>
<dc:description> The Dublin Core is a simple metadata element
set intended to facilitate discovery of electronic
resources. </dc:description>
<dc:date> 1995-03-01 </dc:date>
</rdf:Description>
<rdf:Description ID="title">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Title</rdfs:label>
<rdfs:comment>The name given to the resource, usually by the Creator
or Publisher.</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
<rdf:Description ID="creator">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Author/Creator</rdfs:label>
<rdfs:comment>The person or organization primarily responsible for
creating the intellectual content of the resource. For example,
authors in the case of written documents, artists, photographers, or
illustrators in the case of visual resources.</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
<rdf:Description ID="subject">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Subject</rdfs:label>
<rdfs:comment>The topic of the resource. Typically, subject will be
expressed as keywords or phrases that describe the subject or
content of the resource. The use of controlled vocabularies and
formal classification schemes is encouraged.</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
<rdf:Description ID="description">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Description</rdfs:label>
<rdfs:comment> A textual description of the content of the resource,
including abstracts in the case of document-like objects or content
descriptions in the case of visual resources.</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
<rdf:Description ID="publisher">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Publisher</rdfs:label>
<rdfs:comment>The entity responsible for making the resource
available in its present form, such as a publishing house, a
university department, or a corporate entity.</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
<rdf:Description ID="contributor">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Other Contributors</rdfs:label>
<rdfs:comment>A person or organization not specified in a Creator
element who has made significant intellectual contributions to the
resource but whose contribution is secondary to any person or
organization specified in a Creator element (for example, editor,
transcriber, and illustrator).</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
<rdf:Description ID="date">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Date</rdfs:label>
<rdfs:comment>A date associated with the creation or availability of
the resource. Such a date is not to be confused with one belonging
in the Coverage element, which would be associated with the resource
only insofar as the intellectual content is somehow about that
date. Recommended best practice is defined in a profile of ISO 8601
[Date and Time Formats (based on ISO8601), W3C Technical Note,
http://www.w3.org/TR/NOTE-datetime] that includes (among others)
dates of the forms YYYY and YYYY-MM-DD. In this scheme, for example,
the date 1994-11-05 corresponds to November 5, 1994.</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
<rdf:Description ID="type">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Type</rdfs:label>
<rdfs:comment>The category of the resource, such as home page,
novel, poem, working paper, technical report, essay, dictionary. For
the sake of interoperability, Type should be selected from an
enumerated list that is currently under development in the workshop
series.</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
<rdf:Description ID="format">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Format</rdfs:label>
<rdfs:comment>The data format of the resource, used to identify the
software and possibly hardware that might be needed to display or
operate the resource. For the sake of interoperability, Format
should be selected from an enumerated list that is currently under
development in the workshop series.</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
<rdf:Description ID="identifier">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Identifier</rdfs:label>
<rdfs:comment>A string or number used to uniquely identify the
resource. Examples for networked resources include URLs and URNs
(when implemented). Other globally-unique identifiers, such as
International Standard Book Numbers (ISBN) or other formal names are
also candidates for this element.</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
<rdf:Description ID="source">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Source</rdfs:label>
<rdfs:comment>Information about a second resource from which the
present resource is derived. While it is generally recommended that
elements contain information about the present resource only, this
element may contain a date, creator, format, identifier, or other
metadata for the second resource when it is considered important for
discovery of the present resource; recommended best practice is to
use the Relation element instead. For example, it is possible to
use a Source date of 1603 in a description of a 1996 film adaptation
of a Shakespearean play, but it is preferred instead to use Relation
"IsBasedOn" with a reference to a separate resource whose
description contains a Date of 1603. Source is not applicable if the
present resource is in its original form.</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
<rdf:Description ID="language">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Language</rdfs:label>
<rdfs:comment>The language of the intellectual content of the
resource. Where practical, the content of this field should coincide
with RFC 1766 [Tags for the Identification of Languages,
http://ds.internic.net/rfc/rfc1766.txt ]; examples include en, de,
es, fi, fr, ja, th, and zh.</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
<rdf:Description ID="relation">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Relation</rdfs:label>
<rdfs:comment>An identifier of a second resource and its
relationship to the present resource. This element permits links
between related resources and resource descriptions to be
indicated. Examples include an edition of a work (IsVersionOf), a
translation of a work (IsBasedOn), a chapter of a book (IsPartOf),
and a mechanical transformation of a dataset into an image
(IsFormatOf). For the sake of interoperability, relationships should
be selected from an enumerated list that is currently under
development in the workshop series.</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
<rdf:Description ID="coverage">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Coverage</rdfs:label>
<rdfs:comment>The spatial or temporal characteristics of the
intellectual content of the resource. Spatial coverage refers to a
physical region (e.g., celestial sector); use coordinates (e.g.,
longitude and latitude) or place names that are from a controlled
list or are fully spelled out. Temporal coverage refers to what the
resource is about rather than when it was created or made available
(the latter belonging in the Date element); use the same date/time
format (often a range) [Date and Time Formats (based on ISO8601),
W3C Technical Note, http://www.w3.org/TR/NOTE-datetime] as
recommended for the Date element or time periods that are from a
controlled list or are fully spelled out.</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
<rdf:Description ID="rights">
<rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/>
<rdfs:label>Rights</rdfs:label>
<rdfs:comment>A rights management statement, an identifier that
links to a rights management statement, or an identifier that links
to a service providing information about rights management for the
resource.</rdfs:comment>
<rdfs:isDefinedBy = ""/>
</rdf:Description>
</rdf:RDF>
The text, below, is offered as an illustration of the Qualified Dublin Core Namespace, dcq: as of 21 April 1999. Readers are reminded that the definitive version of this namespace is available online at <URL: http://purl.org/dc/qualifiers/1.0/>.
<? xml version='1.0'?> <rdf:RDF xmlns:rdf="http://www.w3.org/TR/REC-rdf-syntax#" xmlns:rdfs="http://www.w3.org/TR/WD-rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.0/" xmlns:dcq=""> <rdf:Description rdf:about = ""> <dc:title> The Dublin Core Qualifiers </dc:title> <dc:creator> The Dublin Core Metadata Initiative </dc:creator> <dc:description> The Dublin Core is a simple metadata element set intended to facilitate discovery of electronic resources. This RDF declaration supports the qualification of this simple set to support richer description. </dc:description> <dc:date> 1995-03-01 </dc:date> </rdf:Description> <rdf:Description ID="titleType"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Title Element Qualifier</rdfs:label> <rdfs:comment>The type of title.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="titleScheme"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Title Value Qualifier</rdfs:label> <rdfs:comment>The encoding scheme or processing hint associated with the title.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="subjectType"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Subject Element Qualifier</rdfs:label> <rdfs:comment>The type of subject.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="subjectScheme"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Subject Value Qualifier</rdfs:label> <rdfs:comment>The encoding scheme or processing hint associated with the subject.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="descriptionType"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Description Element Qualifier</rdfs:label> <rdfs:comment>The type of description.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="descriptionScheme"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Description Value Qualifier</rdfs:label> <rdfs:comment>The encoding scheme or processing hint associated with the desciption.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="dateType"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Date Element Qualifier</rdfs:label> <rdfs:comment>The type of date.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="dateScheme"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Date Value Qualifier</rdfs:label> <rdfs:comment>The encoding scheme or processing hint associated with the date.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="formatType"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Format Element Qualifier</rdfs:label> <rdfs:comment>The type of format.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="formatScheme"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Format Value Qualifer</rdfs:label> <rdfs:comment>The encoding scheme or processing hint associated with the format.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="identifierType"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Identifier Element Qualifier</rdfs:label> <rdfs:comment>The type of identifier.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="identifierScheme"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Identifier Value Qualifier</rdfs:label> <rdfs:comment>The encoding scheme or processing hint associated with the identifier.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="languageType"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Language Element Qualifier</rdfs:label> <rdfs:comment>The type of language.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="languageScheme"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Language Value Qualifier</rdfs:label> <rdfs:comment>The encoding scheme or processing hint associated with the language.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="relationType"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Relation Element Qualifier</rdfs:label> <rdfs:comment>The type of relation.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="relationScheme"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Relation Value Qualifier</rdfs:label> <rdfs:comment>The encoding scheme or processing hint associated with the relation.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="coverageType"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Coverage Element Qualifier</rdfs:label> <rdfs:comment>The type of coverage.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="coverageScheme"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Coverage Value Qualifier</rdfs:label> <rdfs:comment>The encoding scheme or processing hint associated with the coverage.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="rightsType"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Rights Element Qualifier</rdfs:label> <rdfs:comment>The type of rights.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> <rdf:Description ID="rightsScheme"> <rdf:type rdf:resource="http://www.w3.org/TR/REC-rdf-syntax#Property"/> <rdfs:label>Rights Value Qualifier</rdfs:label> <rdfs:comment>The encoding scheme or processing hint associated with the rights of the resource.</rdfs:comment> <rdfs:isDefinedBy = ""/> </rdf:Description> </rdf:RDF>
Last modified: Thu July 1 1999