The function of a Dublin Core Application Profile (DCAP) is to specify which terms an organisation, information provider, or community uses in its metadata. A DCAP identifies the ‘properties’ (also known as elements and element refinements) used by an application to describe a resource. A DCAP should reference a property it uses by citing the globally unique identifier as assigned to the property by its owner. Optionally the DCAP documents how other terms (in particular encoding schemes) constrain, encode, or interpret the values of ‘properties’ for application-specific purposes. A DCAP should also reference these encoding schemes by citing a globally unique identifier.

The intended effect of documenting usage of properties and other terms in this manner is to promote interoperability within the constraints of the Dublin Core model and to encourage harmonisation of usage and convergence on "emerging semantics" around its edges.

In order for DCAPs to be used effectively, it is essential that the content of the DCAP is structured in a precise and rigorous way, and that the content is based on sound modelling. In order to move forward consensus on a common data model, the CEN MMI-DC Working Group has drawn up these guidelines, which propose a detailed data model as the basis for both human readable and machine-processable DCAPs. These guidelines build on and extend the previous CEN Workshop Agreement (CWA) 14855: Dublin Core Application Profile Guidelines [CWA 14855].

CWA 14855 gives guidance for representing a DCAP as a document specifying the metadata terms used in an application. It describes a normalized documentational form for presenting usage information in a readable and well-structured manner. Such DCAPs are intended primarily for human consumption, whether "as plain text files or as Web pages, word-processing files, PowerPoint, or indeed as ink on paper". With an eye towards the potential for machine-to-machine use of DCAPs, however, CWA 14855 mandates "enough structure to ensure that DCAPs will be convertible as straightforwardly as possible into expressions that use schema languages, such as [the Resource Description Framework] RDF, for automatic processing by machines." However, it should be noted that CWA 14855 states "there can be no assumption that documentational DCAPs will be convertible into machine-understandable forms without the use of ad-hoc heuristics or manual intervention."

Building on CWA 14855, this CWA suggests a machine-processable representation of a DCAP using the conventions of the Resource Description Framework [RDF] in order to enable the DCAP to be exchanged between applications.

As a formalisation of the relationships between metadata properties, RDF lends itself to providing information about usage of properties within applications. So, for example, DCAPs expressed as RDF might be indexed in registries to provide usage information amongst a federation of data providers or even within a single organisation. Initial experiences in a research context suggests that "application profile registries" might be constructed on the basis of a distributed architecture in which content providers maintain schemas for their own metadata, and those schemas are harvested and merged into a central index for discovery and re-use by others. Such processes remain the object of ongoing experimentation and research. The deployment of such systems presupposes the existence of an underlying common data model.

Proposing such a model with regard to the expression of DCAPs is the object of this CWA. After some background discussion, this CWA outlines a DCAP data model indicating the characteristics of an Application Profile. The attributes of the various entities within the data model are listed, and some examples are given of machine-processable schemas constructed using RDF conventions. As an appendix, the guidelines address interoperability issues between DC and IEEE/LOM [IEEE/LOM], identifying areas of commonality and areas of difference. Guidance will be given as to current positions of the two communities regarding re-use of data elements. Within a further appendix, observations will be given from a GIS perspective.

1 Scope

Since the release of CWA 14855, significant work has been carried out defining a DCMI Abstract Model. This has been made available as a DCMI Working Draft [POWELL]. The DCMI Abstract Model provides a reference model against which guidelines for encoding DC metadata can be compared. Although, at the time of writing this CWA, there are some outstanding issues related to the Abstract Model, this work has clarified many aspects of the nature of a Dublin Core description.

Alignment with this work suggests the use of more precise terminology when describing DCAPs. CWA 14855 defines a DCAP as a declaration specifying which metadata terms an organisation, information provider, or user community uses in its metadata. A DCAP identifies the source of metadata terms used. Optionally, CWA 14855 states, a DCAP may provide additional documentation on how the terms are constrained, encoded, or interpreted for application-specific purposes.

However, taking the DCMI Abstract model into account we can be more precise in our language within the definition of a DCAP. A DCAP is primarily concerned with declaring ‘property usages’, and the DCAP specifies and optionally constrains or restricts the use of properties. These changes in terminology are outlined in the Definitions section below.

Given the limited timescale and effort, these DCAP Guidelines are concerned with modelling DCAPs that are used as the basis for metadata describing a single resource, and do not address the more complex case relating to metadata describing multiple resources as outlined in the DCMI Abstract Model. In summary, this CWA will focus on the expression of stable, well structured, non-complex DCAPs.

Both human readable DCAPs as discussed in CWA 14855, and machine-processable representations of DCAPs outlined in this CWA are intended to relate to the same DCAP model. However, due to the difference in the underlying representations, there are some differences in the information provided by each. CWA 14855 permits some flexibility in the presentation of human readable DCAPs by introducing a Principle of Readability that allows for additional prose to be included in the representation of the DCAP to provide context.

The Principle of Readability allows for redundant inclusion of information within a DCAP in order to enable the reader to gather comprehensive information from one single document. Following this principle, the human-readable representation of a "property usage" can include information about the property that is "used". Therefore, for a usage of dc:title that makes the Title property mandatory but keeps the DCMI definition of this property, it is helpful for a human-readable representation to include the DCMI definition of Title, rather than just a terse URI Reference [URI], whereas in a machine-processable DCAP, such information regarding the definition of dc:title would be redundant.

Similarly, a human-readable DCAP might include details of the relationships between properties, whereas this information is redundant in a machine-processable DCAP. However, in both cases these relationships should also be expressed in the metadata vocabulary from which the property usages are derived.

The presence of contextual information within a human readable DCAP means there can be no assumption that such DCAPs will be convertible into machine-understandable forms without the use of ad-hoc heuristics or manual intervention.

2 Definitions and terminology

2.1 Definitions

Existing definitions have been taken from CWA 14855:

Dublin Core Application Profile (DCAP): A DCAP is a declaration specifying at a minimum which metadata terms an organisation, information provider, or user community uses within a particular application. Optionally the DCAP may describe how those terms have been customized or adapted to a particular application. By definition, a DCAP is based in part on Dublin Core metadata vocabularies and follows the DCMI Grammatical Principles [DCMI-PRINCIPLES].

DCMI Grammatical Principles: As maintained by the Dublin Core Metadata Initiative, DCMI grammatical principles specify a typology of metadata terms – Elements, Element Refinements, Encoding Schemes, and Vocabulary Terms – along with their interrelationships and functions [DCMI-PRINCIPLES]. A DCAP is based on the simple model of a resource described with a flat set of properties. This is consistent with DCMI grammatical principles, which do not themselves specify models that are more elaborate.

Additional definitions for the DCAP Data Model:

Resource. A Resource is anything that has identity.

Metadata vocabulary. A Metadata Vocabulary is a set of metadata terms (properties, classes, and instances of those classes) managed as a coherent unit by an agency.

Property. A Property is a type of relationship between two resources. A Property is declared as a term within exactly one Metadata Vocabulary. A Property may be related to another property by a sub-property relationship: this states that all resources related by the first property are also related by the second property.

Property Usage. A Property Usage is a description of how a previously declared property from a metadata vocabulary is deployed in the context of an application.

Class. A Class is a set of resources. A Class is declared as a term within exactly one Metadata Vocabulary. A Class may be related to another class by a sub-class relationship: this states that all instances of the first class are also instances of the second class. A Resource is related to one or more Classes by a Type relationship, and is said to be an instance of those classes. If a class represents a controlled vocabulary, then the individual terms or values in that controlled vocabulary are instances of that class.

Datatype. A datatype consists of a set of character strings (the lexical space), a set of values (the value space) and a mapping from the lexical space to the value space.

Schema Document. A Schema Document is a document containing a machine-readable description of a Metadata Vocabulary or a DCAP.

Agency. An Agency is an entity responsible for managing one or more Metadata Vocabularies or Application Profiles and their components

Binding Schema. A Binding Schema is a document containing a machine-readable description of how to structure a metadata record conforming to a DCAP.

2.2 Terminology

There have been some changes in terminology since CWA 14855, to align the proposed DCAP Data Model with the draft DCMI Abstract Model, and to achieve more precision. Moving towards consensus on metadata related terminology is currently a topic of discussion in the wider Semantic Web community [SW-PRACTICE], and there may need to be further re-alignment of terminology in future. Whereas CWA 14855 refers to a DCAP as consisting of ‘term usages’, covering usage of the various terms as defined by the DCMI Grammatical Principles, (Elements, Element Refinements, Encoding Schemes), these guidelines prefer to characterise a DCAP as a set of ‘property usages’, where the values of the properties can be constrained by encoding schemes. Note that the objects of "usage" statements in the DCAP model are always properties.

As stated in the DCMI Abstract Model [POWELL], within DCMI the word element is typically used as a synonym for property; and element refinement is a property of a resource that shares the meaning of a particular DCMI property but with narrower semantics.

The concept of "property" is therefore narrower than "term", however the same constraints can be described within a property usage as those outlined in ‘term usage’ within CWA 14855. Additional documentation, labels, constraints, and obligations can be associated with such a property usage, including specification of constraints on the permitted values for the property, in other words it is possible to specify encoding schemes as part of the property usage.

3 Usage scenarios

Human-readable DCAPs as specified in CWA 14855 provide a recommended common format to assist users to declare DCAPs in documents in a well-structured way. This enables new implementers, system designers, and metadata creators to find information about existing DCAPs by comparing documents with a similar structure. In addition, expressing DCAPs in an agreed common structure supports input to simple database tools for comparing DCAPs.

Achieving consensus on expressing application profiles in a machine-processable way will encourage exchange of DCAPs in a machine-to-machine manner between applications. Enabling predictable exchanges of application profiles will encourage re-use of existing application profiles, and provide means for tools to automatically download and process such profiles.

Example use cases that rely on well-structured machine-processable DCAPs are:

- A federation of service providers want to share their metadata by means of an aggregator service. The aggregator will convert between instance metadata based on a variety of DCAPs in use across the federation. The service providers build a central store of machine-processable DCAPs in use across the federation. This registry of DCAPs informs development of transformations of instance metadata to a normalised view.

- A large corporation wishes to provide a registry of application profiles in use across the organisation to encourage re-use of existing data elements. The aim is for the registry to harvest machine-processable DCAPs and automatically ingest them into the registry store.

4 Choice of representation language for DCAPs

It is possible to represent a DCAP in different ways. The decision will depend on the functionality required: representations for a human reader will differ from representations for a computer program, as will representations for different automated processes. So, a DCAP might be structured as a MS Word document, or within an MS Access database for cataloguers to access for informational purposes. A DCAP might also be expressed as an XML Schema as a means of constraining the structure of an XML document (e.g. for validation of instance metadata), or a DCAP might be represented using RDF conventions specifying the use of properties in RDF statements about resources (e.g. for building a registry of DCAPs).

There are several reasons why RDF has been chosen as a basis for the data model and sample schemas in these guidelines. Historically, RDF has informed the development and clarification of a data model for DCMI (indeed, to a certain degree the reverse might be said as well). In particular, several research projects have experimented with using RDF to model application profiles [BAKER, MEG-REGISTRY, CORES, JISC-REGISTRY]. This CWA focuses on providing machine-processable identification of the property usages within a DCAP. A language is required which allows statements to be made about resources and to express constraints on use of properties. RDF offers a framework for this. However, it should be noted that the RDF Vocabulary Description Language, RDF Schema [RDFS], does not include the concept of ‘usage’ central to DCAPs, so DCAP schemas need to include application specific language that is not part of RDFS.

There may be functional requirements for other expressions of a DCAP within an application. For example, an XML Schema [XML-SCHEMA] could provide a structured expression of the terms identified by a DCAP to support validation of instance metadata. An XML Schema provides a document "template" for metadata instances and it may make sense to express a given DCAP as an XML schema - for example, to support the validation of metadata records or to dynamically configure a metadata-editing environment. It should be noted that XML Schema is not capable of expressing property usages; rather it supports description of the structure of instance metadata conforming to a particular DCAP.

There is also potential for representing DCAPs using OWL (Web Ontology Language) [OWL] - a W3C schema language with a vocabulary of modelling constructs richer than those provided by RDF Schema. Specifically, OWL supports the formal expression of usage constraints of the sort often described in DCAPs. However adopting OWL for representation of DCAPs would be innovative, the sort of work perhaps better done in the context of basic research. See Appendix C for more discussion of the use of OWL within the context of DCAPs.

5 Good practice

5.1 Declaring property usage

The distinguishing feature of a DCAP is the declaration of property usage. Whilst DCAPs declare usage of properties, the properties themselves are identified, declared, and defined ‘elsewhere’ in a metadata vocabulary. The ‘property’ is distinct, specified in a metadata vocabulary, and should be distinguished from the property usage, specified in the DCAP. Specification of the property usage includes information that is not logically associated with the property itself, such as obligation, occurrences, which will vary across different usages of the same property.

The guidelines provided in this CWA, therefore, also cover the notion of metadata vocabulary, but do not give detailed guidelines for declaring metadata vocabularies. Emerging practice suggests that properties should be declared and identified in metadata vocabularies expressed as RDF Schemas.

5.2 Identifying terms

All references to terms within a DCAP (both the properties used and the encoding schemes) should be in the form of URI references [URI]. Unless a term is assigned a URI reference, it cannot be referred to unambiguously in a DCAP, whether represented within a human readable or machine-processable form.

For identification of terms to which a URI has been officially assigned, for example by DCMI or by another organisation, that URI should be used to identify the term. For example, the Dublin Core element “Audience” should be cited as “http://purl.org/dc/terms/audience”.

It may be that, in constructing the DCAP, it is the first time a URI has been required to identify a term. For identification of terms that have not already been assigned a URI, the term must be identified and declared (whether by the organisation constructing the DCAP, or another organisation) in a metadata vocabulary elsewhere by means of a document or schema. Within that document or schema it might be appropriate to annotate such a term with a "status indicator" indicating that the term is being used in a particular application, but is not yet stable.

6 DCAP Data Model and Property Usage

This DCAP data model is rooted in the DCMI Grammatical Principles and the draft DCMI Abstract Model, and builds on experience within various projects [MEG-REGISTRY, CORES]. However, it is not endorsed nor published as a DCMI document. Deployment of this model is currently being explored within the context of an application profile registry [JISC-REGISTRY].

6.1 Characteristics of DCAP Property Usage

A DCAP is a set of Property Usages. Each Property Usage must reference an existing Property from a Metadata Vocabulary. A Property Usage

- must use at least one property from an existing metadata vocabulary;

- may provide additional documentation on how the property is interpreted in the context of this application;

- may provide an application-specific label for the property

- may specify obligation for the use of the property (whether it is mandatory, optional, conditional)

- may specify constraints on the occurrence of the property

- may specify constraints on the permitted values of the property, i.e. may specify "encoding schemes" for the property. Values may be specified to be either:

- instances of specified classes; or

- instances of specified literal datatypes (Note: DCMI currently models all DCMI-recommended encoding schemes as classes, not datatypes)

- A schema document describes one DCAP and its constituent property usages.

- A DCAP may be associated with one or more binding schemas (e.g. a set of XML Schemas) that describe the structure of a metadata record conforming to this DCAP

The relationships between the entities above are illustrated in Figure 1.

Figure 1: Dublin Core Application Profile

6.2 Attributes of DCAP Property Usage

Note: The names of RDF Classes, Properties, and Datatypes are listed below as QNames [QNAMES]. The prefixes are assumed to be associated with Namespace Names as follows:

- dc: http://purl.org/dc/elements/1.1/

- dcterms: http://purl.org/dc/terms/

- dcmitype: http://purl.org/dc/dcmitype/

- rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns#

- rdfs: http://www.w3.org/2000/01/rdf-schema#

- xsd: http://www.w3.org/2001/XMLSchema#

- dcap: http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/

Attribute Name	Definition	RDF property	Obligation	Occurrence	Value
Property Usage URI	A URI Reference which identifies the property usage		Mandatory	Max=1	URI
Used Property	A property which is used in this DC Application Profile	*dcap:uses*	Mandatory	Max=1	rdf:Property
Label	A human-readable label assigned to the property, in the context of this DC application profile	*rdfs:label*	Optional	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Status	An indicator of the status of the property usage.	*dcap:status*	Optional	Max=1	dcap:TermStatus
Definition	A statement of the concept and essential nature of the property, as it is used in this DC Application Profile	*rdfs:comment*	Optional	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Comments	Additional information about the property or its use specific to this DC Application Profile	*dc:description*	Optional	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Obligation	An indication of whether a statement using the property is required to occur in a metadata description conforming to this DC Application Profile	*dcap:obligation*	Mandatory	Max=1	dcap:Obligation
Condition	A description of the condition or conditions according to which a statement using the property should be present in a metadata description conforming to this DC Application Profile	*dcap:condition*	Conditional (Mandatory if Obligation = Conditional)	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Occurrences	The maximum permitted number of occurrences of statements using the property in a metadata description conforming to this DC Application Profile	*dcap:maxOccurs*	Mandatory	Max=1	Literal, xsd:int or "unbounded"
Uses Encoding Scheme (Datatype)	A datatype of which the literal value of the property is an instance, when the property is used in a metadata record conforming to this DC Application Profile	dcap:encoding Scheme	Optional	Max=unbounded	rdfs:Datatype
Uses Encoding Scheme (Object Type)	A class of which the value of the property is an instance, when the property is used in a metadata record conforming to this DC Application Profile	dcap:encoding Scheme	Optional	Max=unbounded	rdfs:Class
Is Member Of	The DCAP of which this Property Usage is a member.	*dcap:isMemberOf*	Mandatory	Max=1	dcap:DCAP

7 Bibliography

[BAKER] Thomas Baker, Makx Dekkers, Rachel Heery, Manjula Patel, Gauri Salokhe, What terms does your metadata use? Application profiles as machine-understandable narratives. Journal of Digital Information 2:2 (November 2001), http://jodi.ecs.soton.ac.uk/Articles/v02/i02/Baker.

[CORES] Rachel Heery, Pete Johnston, Csaba Fulop, Andras Micsik, Metadata schema registries in the partially Semantic Web: the CORES experience, http://www.siderean.com/dc2003/102_Paper29.pdf

[CWA 14855] Dublin Core Application Profile Guidelines, CEN Workshop Agreement CWA 14855, November 2003, http://www.cenorm.be/isss/cwa14855/

[CWA 14858] CWA 14858:2003 Dublin Core Spatial Application Profile, CEN November 2003. http://www.cenorm.be/isss/cwa14858/

[DCES] Dublin Core Metadata Element Set, Version 1.1: Reference Description, http://dublincore.org/documents/dces/

[DCMI-PRINCIPLES] DCMI Grammatical Principles, http://dublincore.org/usage/documents/principles/

[GEMINI] UK GEMINI standard version 1.0. Cabinet office and e-Government Unit, 2004-10-12. http://www.gigateway.org.uk/metadata/pdf/UK_GEMINI_v1.pdf

[IEEE-LOM] IEEE 1484.12.1–2002 Standard for Learning Object Metadata.

[ISO 19115] ISO 19115 Geographic Information: Metadata. Available from ISO at http://www.iso.org/. See also the Programme of Work of ISO/TC211: http://www.isotc211.org/pow.htm

[JISC-REGISTRY] JISC IE Metadata Schema Registry, Model for Dublin Core Application Profile (DCAP), Draft 6 June 2004. http://www.ukoln.ac.uk/projects/iemsr/wp2/dcap/

[JOHNSTON] Pete Johnston. Functional Requirements for MEG Registry. http://www.ukoln.ac.uk/metadata/education/regproj/funcreq/

[MEG-REGISTRY] Rachel Heery, Pete Johnston, Dave Beckett, Damian Steer, The MEG Registry and SCART: Complementary Tools for Creation, Discovery and Re-use of Metadata Schemas. In: Proceedings of the International Conference on Dublin Core and Metadata for e-Communities, 2002. Florence: Firenze University Press, 2002, pp. 125-132. http://www.bncf.net/dc2002/program/ft/paper14.pdf.

[OWL] OWL Web Ontology Language Semantics and Abstract Syntax. W3C Recommendation, 10 February 2004. http://www.w3.org/TR/owl-semantics/

[POWELL] Andy Powell, Mikael Nilsson, Ambjörn Naeve, Pete Johnston. DCMI Abstract Model. DCMI Working Draft, 24 November 2004. http://www.ukoln.ac.uk/metadata/dcmi/abstract-model/. Future versions will be published at http://dublincore.org/documents/abstract-model/.

[QNAMES] Qualified Names, in: Namespaces in XML. World Wide Web Consortium 14 January 1999 http://www.w3.org/TR/REC-xml-names/#dt-qname

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

[RDN] The Resource Discovery Network http://www.rdn.ac.uk/

[RDN-CAT-GUIDE] Michael Day and Peter Cliff. RDN cataloguing guidelines. Version 1.1. http://www.rdn.ac.uk/publications/cat-guide/

[SW-PRACTICE] Semantic Web Best Practices and Deployment Working Group: Vocabulary Management Task Force Description. http://www.w3.org/2001/sw/BestPractices/VM/

[URI] T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, August 1998. http://www.ietf.org/rfc/rfc2396.txt

[XML-SCHEMA] Thompson, Henry S. et al., editors. XML Schema Part 1: Structure. W3C Recommendation 2 May 2001, http://www.w3.org/TR/xmlschema-1/

Appendix A. Attributes of data model entities

A.1 Dublin Core Application Profile

Attribute Name	Definition	RDF property	Obligation	Occurrence	Value
URI Reference	A URI Reference which identifies the DC application profile		Mandatory	Max=1	URI
Title	The name or title of the DC application profile	*dc:title*	Mandatory	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Version	An indicator of the version of the DC application profile	*dcap:version*	Optional	Max=1	Literal, xsd:string
Status	An indicator of the status of the DC application profile	*dcap:status*	Optional	Max=1	dcap: Vocabulary Status
Description	A summary of the scope and purpose of the DC application profile	*dc:description*	Mandatory	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Specification	A human-readable document that provides more information about the DC application profile	*dcap:seeAlso*	Optional	Max=unbounded	Document
Administrator	An agency that manages the DC application profile	*dc:publisher*	Mandatory	Max=unbounded	dcap:Agency
Expressed By	A binding schema used to structure metadata records conforming to this DC application profile	*dcap:isExpressedBy*	Optional	Max=unbounded	dcap: BindingSchema
Is Defined By	A schema document that describes this DC application profile	*rdfs:isDefinedBy*	Mandatory	Max=1	dcap: SchemaDocument

A.2 Agency

Attribute Name	Definition	RDF property	Obligation	Occurrence	Value
URI Reference	A URI Reference which identifies the DC application profile		Mandatory	Max=1	URI
Title	The name or title of the DC application profile	*dc:title*	Mandatory	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Version	An indicator of the version of the DC application profile	*dcap:version*	Optional	Max=1	Literal, xsd:string
Status	An indicator of the status of the DC application profile	*dcap:status*	Optional	Max=1	dcap: Vocabulary Status
Description	A summary of the scope and purpose of the DC application profile	*dc:description*	Mandatory	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Specification	A human-readable document that provides more information about the DC application profile	*dcap:seeAlso*	Optional	Max=unbounded	Document
Administrator	An agency that manages the DC application profile	*dc:publisher*	Mandatory	Max=unbounded	dcap:Agency
Expressed By	A binding schema used to structure metadata records conforming to this DC application profile	*dcap:isExpressedBy*	Optional	Max=unbounded	dcap: BindingSchema
Is Defined By	A schema document that describes this DC application profile	*rdfs:isDefinedBy*	Mandatory	Max=1	dcap: SchemaDocument

A.3 Schema Document

Attribute Name	Definition	RDF property	Obligation	Occurrence	Value
Identifier	A URI Reference which identifies the schema document		Mandatory	Max=1	URI
Title	A title for the schema document	*dc:title*	Mandatory	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Description	A description of the schema document	*dc:description*	Optional	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Date modified	The date on which this schema document was last modified	*dcterms:modified*	Mandatory	Max=1	Literal, xsd:date
Publisher	An agency that publishes this schema document	*dc:publisher*	Mandatory	Max=unbounded	dcap:Agency

A.4 Metadata Vocabulary

Attribute Name	Definition	RDF property	Obligation	Occurrence	Value
URI Reference	A URI Reference which identifies the metadata vocabulary		Mandatory	Max=1	URI
Title	The name or title of the metadata vocabulary	*dc:title*	Mandatory	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Version	An indicator of the version of the metadata vocabulary	*dcap:version*	Mandatory	Max=1	Literal, xsd:string
Date modified	The date on which this metadata vocabulary was last modified	*dcterms:modified*	Mandatory	Max=1	Literal, xsd:date
Status	An indicator of the status of the metadata vocabulary	*dcap:status*	Optional	Max=1	dcap: Vocabulary Status
Description	A summary of the scope and purpose of the metadata vocabulary	*dc:description*	Mandatory	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Specification	A human-readable document that provides more information about the metadata vocabulary	*dcap:seeAlso*	Optional	Max=unbounded	dcap:Document
Preferred XML Namespace Name	The preferred XML Namespace Name to be used when using terms from this vocabulary in an RDF/XML document	dcap:preferred XML Namespace Name	Optional	Max=1	Literal, xsd:string
Preferred XML Namespace Prefix	The preferred Namespace Prefix to be used when using terms from this vocabulary in an RDF/XML document	dcap:preferred XML Namespace Prefix	Optional	Max=1	Literal, xsd:string
Administrator	An agency that manages this metadata vocabulary	*dc:publisher*	Mandatory	Max=unbounded	dcap:Agency
Is Defined By	A schema document that describes this metadata vocabulary	*rdfs:isDefinedBy*	Mandatory	Max=1	dcap:SchemaDocument

A.5 Property

Attribute Name	Definition	RDF property	Obligation	Occurrence	Value
URI Reference	A URI Reference which identifies the property		Mandatory	Max=1	URI
Label	A human-readable label assigned to the property	*rdfs:label*	Mandatory	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Status	An indicator of the status of the property	*dcap:status*	Optional	Max=1	dcap:TermStatus
Definition	A statement of the concept and essential nature of the property	*rdfs:comment*	Mandatory	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Comment/Usage Note	Additional information about the property or its use	*dc:description*	Optional	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Subproperty Of/Refines	A property of which this property is a subproperty	*rdfs:subpropertyOf*	Optional	Max=unbounded	rdf:Property
Is Member Of	The metadata vocabulary of which this property is a member term	*dcap:isMemberOf*	Mandatory	Max=1	dcap: MetadataVocabulary

A.6 Class

Attribute Name	Definition	RDF property	Obligation	Occurrence	Value
URI Reference	A URI Reference which identifies the class		Mandatory	Max=1	URI
Label	A human-readable label assigned to the class	*rdfs:label*	Mandatory	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Status	An indicator of the status of the class	*dcap:status*	Optional	Max=1	dcap:TermStatus
Description	A statement of the concept and essential nature of the class	*rdfs:comment*	Mandatory	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Comment/ Usage Note	Additional information about the class or its use	*dc:description*	Optional	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Subclass Of	A class of which this class is a subclass	*rdfs:subclassOf*	Optional	Max=unbounded	rdfs:Class
Is Member Of	The metadata vocabulary of which this class is a member term	*dcap:isMemberOf*	Mandatory	Max=1	dcap:Metadata Vocabulary

A.7 Instance/Individual

Attribute Name	Definition	RDF property	Obligation	Occurrence	Value
URI Reference	A URI Reference which identifies the instance		Mandatory	Max=1	URI
Label	A human-readable label assigned to the instance	*rdfs:label*	Mandatory	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Status	An indicator of the status of the instance	*dcap:status*	Optional	Max=1	dcap:TermStatus
Description	A statement of the concept represented by the instance	*rdfs:comment*	Mandatory	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Type	The class of which this instance is a member (the controlled vocabulary of which this instance is a term	*rdf:type*	Mandatory	Max=1	rdfs:Class
Is Defined By	A schema document that describes this instance	*rdfs:isDefinedBy*	Mandatory	Max=1	dcap:Schema Document

A.8 Binding Schema

Attribute Name	Definition	RDF property	Obligation	Occurrence	Value
Identifier	A URI Reference which identifies the binding schema		Mandatory	Max=1	URI
Title	A title for the binding schema	*dc:title*	Mandatory	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Description	A description of the binding schema	*dc:description*	Optional	Max=1 Max=unbounded if allowing for multiple languages	Literal, xsd:string
Type	The type of the binding schema	*dc:type*	Mandatory	Max=1	dcap: Binding SchemaType
Date modified	The date on which this binding schema was last modified	*dcterms:modified*	Mandatory	Max=1	Literal, xsd:date
Publisher	An agency that publishes this binding schema	*dc:publisher*	Mandatory	Max=unbounded	dcap:Agency

Appendix B. Example DCAPs expressed using RDF Schema

The description of a DCAP using the conventions described in this document requires some additional RDF properties and classes to those provided by RDF Schema. No decision has been taken on the URI references to be used for terms in this vocabulary. For the purposes of these examples they are represented in RDF/XML as XML QNames where the prefix “dcap” is associated with the XML Namespace Name http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/.

B.1 The RDN-DC Dublin Core Application Profile

The Resource Discovery Network [RDN] is a collaborative service provided for the UK Further and Higher Education communities. The RDN provides access to high quality Internet resources selected by subject specialists for their value in learning and teaching. Within the RDN, a number of independent service providers ("hubs") develop and maintain subject-based catalogues of resources. To share metadata records between hubs, the RDN makes use of a DCAP sometimes referred to as the RDN-DC Application Profile [RDN-CAT-GUIDE].

Using the conventions described in this document, the RDN-DC Application Profile might be represented in RDF/XML as follows:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rdf:RDF [

<!ENTITY rdfns 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>

<!ENTITY rdfsns 'http://www.w3.org/2000/01/rdf-schema#'>

<!ENTITY xsdns 'http://www.w3.org/2001/XMLSchema#'>

<!ENTITY dcapns 'http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/'>

<!ENTITY dcns 'http://purl.org/dc/elements/1.1/'>

<!ENTITY dctermsns 'http://purl.org/dc/terms/'>

<!ENTITY rdntermsns 'http://purl.org/rdn/terms/'>

<!ENTITY megtermsns 'http://purl.org/meg/terms/'>

<!ENTITY rdntypens 'http://purl.org/rdn/rdntype/'>

<rdf:RDF xml:lang="en"

xmlns:rdf="&rdfns;"

xmlns:rdfs="&rdfsns;"

xmlns:dcap="&dcapns;"

xmlns:dc="&dcns;"

xmlns:dcterms="&dctermsns;"

xmlns:rdnterms="&rdntermsns;"

xmlns:megterms="&megtermsns;"

xmlns:rdntype="&rdntypens;"

<dcap:SchemaDocument rdf:about="">

<dc:title>Schema for the RDN Record Sharing (rdn_dc) Application Profile using DCAP vocabulary</dc:title>

<dc:description>This schema contains descriptions of the RDN OAI (rdn_dc) Application Profile using the conventions of the CEN CWA for DCAP.</dc:description>

<dcterms:modified>

<dcterms:W3CDTF>

<rdf:value>2004-07-10</rdf:value>

</dcterms:W3CDTF>

</dcterms:modified>

<dc:publisher rdf:resource="http://www.rdn.ac.uk/#"/>

</dcap:SchemaDocument>

<dcap:Agency rdf:about="http://www.rdn.ac.uk/#">

<dc:title>Resource Discovery Network (RDN)</dc:title>

<dc:description> The Resource Discovery Network [RDN] is a collaborative service provided for the UK Further and Higher Education communities. The RDN provides access to high quality Internet resources selected by subject specialists for their value in learning and teaching.</dc:description>

<dcap:seeAlso rdf:resource="http://www.rdn.ac.uk/"/>

</dcap:Agency>

<dcap:AppProfile rdf:about="http://www.rdn.ac.uk/ap/rdn_dc">

<dc:title>The RDN Record Sharing (rdn_dc) Application Profile</dc:title>

<dcterms:modified>2003-03-23</dcterms:modified>

<dc:description>The RDN Record Sharing (rdn_dc) Application Profile is used in metadata records shared between partners within the Resource Discovery Network using the OAI-PMH. Detailed guidance on the values for metadata elements is provided by the RDN Cataloguing Guidelines http://www.rdn.ac.uk/publications/cat-guide/.</dc:description>

<dc:publisher rdf:resource="http://www.rdn.ac.uk/#"/>

<dcap:status rdf:resource="&dcapns;VocabStatus/recommendation"/>

<dcap:seeAlso rdf:resource="http://www.rdn.ac.uk/publications/cat-guide/"/>

<dcap:seeAlso rdf:resource="http://www.rdn.ac.uk/publications/cat-guide/fe-addendum/"/>

<dcap:isExpressedBy rdf:resource="http://www.rdn.ac.uk/oai/rdn_dc/20030323/rdn_dc.xsd"/>

<rdfs:isDefinedBy rdf:resource=""/>

</dcap:AppProfile>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#1">

<dcap:uses rdf:resource="&dcns;title"/>

<rdfs:label>Title</rdfs:label>

<dc:description>Transcribe the title preserving the original wording, order and spelling. Either only capitalize proper nouns or: Capitalize titles. The former is in accordance with AACR2 and is preferred. The latter is to ensure conformance of existing records. Punctuation need not reflect the usage of the original. Subtitles should be separated from the title by <space>colon<space></dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/recommended"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#2">

<dcap:uses rdf:resource="&dcns;creator"/>

<rdfs:label>Creator</rdfs:label>

<dc:description>Enter personal names, where possible, in the order suggested by AACR2 chapter 22 for headings of persons. Enter corporate names, where possible, in the order suggested by AACR2 chapter 24 for headings for corporate bodies. The inclusion of personal and corporate name headings from authority lists constructed according to AACR2, e.g. the Library of Congress Name Authority File (LCNA), is also acceptable.</dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/optional"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#3">

<dcap:uses rdf:resource="&dcns;subject"/>

<rdfs:label>Subject and Keywords</rdfs:label>

<dc:description>For keywords either enter terms as free-text with a semi-colon separating each keyword; or as multiple (repeating/variant) fields. There are no requirements regarding the capitalization of keywords though internal (within Hub) consistency is recommended. The RDNC can provide scripts to convert records that use alternate separators, eg. commas. Where terms are taken from a standard subject scheme: enter a shortened version of the scheme used as a value qualifier and then enter the term/s. The shortened version of the scheme used should be taken from this enumerated list. The value(s) consist(s) of the subject term(s). Transcribe complete subject descriptor according to the relevant scheme. Use the punctuation and capitalisation used in the original scheme.</dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/recommended"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:encodingScheme rdf:resource="&dctermsns;LCSH" />

<dcap:encodingScheme rdf:resource="&dctermsns;LCC" />

<dcap:encodingScheme rdf:resource="&dctermsns;DDC" />

<dcap:encodingScheme rdf:resource="&dctermsns;UDC" />

<dcap:encodingScheme rdf:resource="&dctermsns;MESH" />

<dcap:encodingScheme rdf:resource="&rdntermsns;NLM"/>

<dcap:encodingScheme rdf:resource="&rdntermsns;EI"/>

<dcap:encodingScheme rdf:resource="&rdntermsns;MSC"/>

<dcap:encodingScheme rdf:resource="&rdntermsns;HESA"/>

<dcap:encodingScheme rdf:resource="&rdntermsns;APA"/>

<dcap:encodingScheme rdf:resource="&rdntermsns;CABI"/>

<dcap:encodingScheme rdf:resource="&rdntermsns;RCN"/>

<dcap:encodingScheme rdf:resource="&rdntermsns;IBSS"/>

<dcap:encodingScheme rdf:resource="&rdntermsns;HASSET"/>

<dcap:encodingScheme rdf:resource="&rdntermsns;CareData"/>

<dcap:encodingScheme rdf:resource="&rdntermsns;LIR"/>

<dcap:encodingScheme rdf:resource="&rdntermsns;Bized"/>

<dcap:encodingScheme rdf:resource="&rdntermsns;JACS"/>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#4">

<dcap:uses rdf:resource="&dcns;description"/>

<rdfs:label>Description</rdfs:label>

<dc:description>Free-text description of resource in the context of the describing Hub.</dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/recommended"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#5">

<dcap:uses rdf:resource="&dcns;publisher"/>

<rdfs:label>Publisher</rdfs:label>

<dcap:obligation rdf:resource="&dcapns;Obligation/optional"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#6">

<dcap:uses rdf:resource="&dcns;contributor"/>

<rdfs:label>Contributor</rdfs:label>

<dcap:obligation rdf:resource="&dcapns;Obligation/optional"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#7">

<dcap:uses rdf:resource="&dcns;date"/>

<rdfs:label>Date</rdfs:label>

<dc:description>Either: Dates should be entered in ISO 8601:1988 format. Or: Dates should be entered in a consistent format that can quickly and easily be converted for external (cross-searching, etc.) presentation.</dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/optional"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:encodingScheme rdf:resource="&dctermsns;W3CDTF" />

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#8">

<dcap:uses rdf:resource="&dcns;type"/>

<rdfs:label>Resource Type</rdfs:label>

<dc:description>Resource type should be a value selected from either DCMIType or RDNType. Multiple terms should be separated by a semi-colon ';' or be put in repeated attributes.</dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/recommended"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:encodingScheme rdf:resource="&dctermsns;DCMIType" />

<dcap:encodingScheme rdf:resource="&rdntermsns;RDNType"/>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#9">

<dcap:uses rdf:resource="&dcns;format"/>

<rdfs:label>Format</rdfs:label>

<dc:description>Recommended best practice is to select a term from IANA registered list of Internet Media Types (or MIME types).</dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/optional"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:encodingScheme rdf:resource="&dctermsns;IMT" />

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#10">

<dcap:uses rdf:resource="&dcns;identifier"/>

<rdfs:label>Resource Identifier : URI</rdfs:label>

<dc:description>When the resource has an URI, enter the complete string with regard to correct spelling, punctuation and capitalisation.</dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/recommended"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:encodingScheme rdf:resource="&xsdns;anyURI" />

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#11">

<dcap:uses rdf:resource="&dcns;identifier"/>

<rdfs:label>Resource Identifier</rdfs:label>

<dc:description>Where identifiers other than URIs are present, their presence should be noted using a DC value qualifier (scheme), possibly taken from an enumerated list.</dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/optional"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#12">

<dcap:uses rdf:resource="&dcns;source"/>

<rdfs:label>Source</rdfs:label>

<dc:description>Free-text description of the original version of a resource.</dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/optional"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#13">

<dcap:uses rdf:resource="&dcns;language"/>

<rdfs:label>Language</rdfs:label>

<dc:description>Use the language codes defined in RFC 3066.</dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/recommended"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:encodingScheme rdf:resource="&dctermsns;RFC3066" />

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#14">

<dcap:uses rdf:resource="&dcns;relation"/>

<rdfs:label>Relation</rdfs:label>

<dc:description>Where the resource being described is a JISC collection or is part of a JISC collection, enter the following URI: http://www.jisc.ac.uk/collections/</dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/recommended"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#15">

<dcap:uses rdf:resource="&dcns;coverage"/>

<rdfs:label>Coverage</rdfs:label>

<dc:description>Where a term taken from an existing controlled vocabulary has been used (e.g. the Getty Thesaurus of Geographic Names), enter a shortened version of the scheme used as a value qualifier (e.g. TGN) and then enter the term/s. Where more than one term is used, a new element should be used for each one. The shortened version of the scheme used should be taken from an enumerated list. Either: free-text field, or: selected from a list.</dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/optional"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#16">

<dcap:uses rdf:resource="&dcns;rights"/>

<rdfs:label>Rights</rdfs:label>

<dc:description>A free-text statement about the rights held in and over the resource or the URI of such a statement.</dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/optional"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#17">

<dcap:uses rdf:resource="&rdntermsns;maintainer"/>

<rdfs:label>Maintainer</rdfs:label>

<dc:description>The email address (encoded as a mailto: URI) or Web page of the administrator of the site or resource being described.</dc:description>

<dcap:obligation rdf:resource="&dcapns;Obligation/optional"/>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#18">

<dcap:uses rdf:resource="&dctermsns;educationLevel" />

<rdfs:label>Audience Education Level</rdfs:label>

<dcap:obligation rdf:resource="&dcapns;Obligation/conditional"/>

<dcap:condition>Mandatory for RDN records targetted at FE (RDN4FE)</dcap:condition>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:encodingScheme rdf:resource="&megtermsns;UKEL" />

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#19">

<dcap:uses rdf:resource="&dcns;subject"/>

<rdfs:label>Subject : Learndirect</rdfs:label>

<dcap:obligation rdf:resource="&dcapns;Obligation/conditional"/>

<dcap:condition>Mandatory for RDN records targetted at FE (RDN4FE)</dcap:condition>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:encodingScheme rdf:resource="&rdntermsns;Learndirect"/>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

<dcap:PropertyUsage rdf:about="http://www.rdn.ac.uk/ap/rdn_dc#20">

<dcap:uses rdf:resource="&rdntermsns;annotation"/>

<rdfs:label>Annotation</rdfs:label>

<dcap:obligation rdf:resource="&dcapns;Obligation/conditional"/>

<dcap:condition>Mandatory for RDN records targetted at FE (RDN4FE)</dcap:condition>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://www.rdn.ac.uk/ap/rdn_dc"/>

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

</rdf:RDF>

B.2 The Renardus Dublin Core Application Profile

The Renardus service at http://www.renardus.org/ grew out of a project funded by the EU's Information Society Technologies 5th framework programme. The service is hosted at Niedersächsische Staats - und Universitätsbibliothek (SUB), Göttingen, Germany, on behalf of the Renardus Consortium.

Renardus aims to provide a trusted source of selected, high quality Internet resources for those teaching, learning, and researching in higher education in Europe. Renardus provides integrated search and browse access to records from individual participating subject gateway services (data providers) across Europe.

The metadata scheme used to homogenize the contributions from the different partners is the "Renardus Application Profile".

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE rdf:RDF (View Source for full doctype...)>

- <rdf:RDF xml:lang="en" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dcap="http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:renterms="http://renardus.sub.uni-goettingen.de/renap/" xmlns:rmesqns="http://renardus.sub.uni-goettingen.de/renap/rmesq" xmlns:rdntype="http://purl.org/rdn/rdntype/">

- <dcap:SchemaDocument rdf:about="">

<dc:title>Renardus Application Profile using DCAP vocabulary</dc:title>

<dc:description>This schema contains descriptions of the Renardus Application Profile using the conventions of the CEN CWA for DCAP.</dc:description>

- <dcterms:modified>

- <dcterms:W3CDTF>

<rdf:value>18-04-2002</rdf:value>

</dcterms:W3CDTF>

</dcterms:modified>

<dc:publisher rdf:resource="http://renardus.sub.uni-goettingen.de/renap/" />

</dcap:SchemaDocument>

- <dcap:Agency rdf:about="http://www.renardus.org/">

<dc:title>Renardus - The Academic Subject Gateway Service in Europe</dc:title>

<dc:description>Renardus allows you to find Internet resources selected according to quality criteria and carefully described by Subject Gateways from several European countries.</dc:description>

<dcap:seeAlso rdf:resource="http://www.renardus.org/about_us/" />

</dcap:Agency>

- <dcap:AppProfile rdf:about="http://renardus.sub.uni-goettingen.de/renap/">

<dc:title>Renardus Application Profile</dc:title>

<dcterms:modified>2002-06-24</dcterms:modified>

<dc:description>The Renardus Application Profile is used to exhibit metadata records collected at several European subject gateways. The format of the original aplication profie is available at http://renardus.sub.uni-goettingen.de/renap/format.html</dc:description>

<dc:publisher rdf:resource="http://www.renardus.org/" />

<dcap:status rdf:resource="http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/VocabStatus/recommendation" />

<dcap:seeAlso rdf:resource="http://renardus.sub.uni-goettingen.de/renap/rmes.html" />

<dcap:seeAlso rdf:resource="http://renardus.sub.uni-goettingen.de/renap/rmesq.html" />

<rdfs:isDefinedBy rdf:resource="http://renardus.sub.uni-goettingen.de/renap/renap.html" />

</dcap:AppProfile>

- <dcap:PropertyUsage rdf:about="http://renardus.sub.uni-goettingen.de/renap/renap.html#title">

<dcap:uses rdf:resource="http://purl.org/dc/elements/1.1/title" />

<rdfs:label>Title</rdfs:label>

<dc:description />

<dcap:obligation rdf:resource="http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/Obligation/conditional" />

<dcap:conditon>mandatory if present</dcap:conditon>

<dcap:maxOccurs>1</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://renardus.sub.uni-goettingen.de/renap/" />

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

- <dcap:PropertyUsage rdf:about="http://renardus.sub.uni-goettingen.de/renap/renap.html#alternative">

<dcap:uses rdf:resource="http://purl.org/dc/terms/alternative" />

<rdfs:label>Alternative Title</rdfs:label>

<dc:description />

<dcap:obligation rdf:resource="http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/Obligation/optional" />

<dcap:maxOccurs>unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://renardus.sub.uni-goettingen.de/renap/" />

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

- <dcap:PropertyUsage rdf:about="http://renardus.sub.uni-goettingen.de/renap/renap.html#creator">

<dcap:uses rdf:resource="http://purl.org/dc/elements/1.1/creator" />

<rdfs:label>Creator</rdfs:label>

<dc:description>Renardus: Creator(s) are person(s) which are responsible for the intellectual content of the document(s), webmasters are no creators. For personal names use the following cataloging rule: last name and first name in separate tags.</dc:description>

<dcap:obligation rdf:resource="http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/Obligation/recommended" />

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://renardus.sub.uni-goettingen.de/renap/" />

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

- <dcap:PropertyUsage rdf:about="http://renardus.sub.uni-goettingen.de/renap/renap.html#subject">

<dcap:uses rdf:resource="http://purl.org/dc/elements/1.1/subject" />

<rdfs:label>Subject</rdfs:label>

<dc:description>Unqualified information for keywords and/or classification system(s) (notations and captions) used by partners.</dc:description>

<dcap:obligation rdf:resource="http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/Obligation/conditional" />

<dcap:conditon>Ren-DDC is mandatory and at least one additional subject (unqualified or qualified) is required.</dcap:conditon>

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:encodingScheme rdf:resource="http://purl.org/dc/terms/LCSH" />

<dcap:encodingScheme rdf:resource="http://purl.org/dc/terms/LCC" />

<dcap:encodingScheme rdf:resource="http://purl.org/dc/terms/DDC" />

<dcap:encodingScheme rdf:resource="http://purl.org/dc/terms/UDC" />

<dcap:encodingScheme rdf:resource="http://purl.org/dc/terms/MESH" />

<dcap:encodingScheme rdf:resource="http://renardus.sub.uni-goettingen.de/renap/rmesq.html#Ren-DDC" />

<dcap:encodingScheme rdf:resource="http://renardus.sub.uni-goettingen.de/renap/racr.html#BC" />

<dcap:encodingScheme rdf:resource="http://renardus.sub.uni-goettingen.de/renap/racr.html#EIC" />

<dcap:encodingScheme rdf:resource="http://renardus.sub.uni-goettingen.de/renap/racr.html#DEFFC" />

<dcap:encodingScheme rdf:resource="http://renardus.sub.uni-goettingen.de/renap/racr.html#NOVASC" />

<dcap:encodingScheme rdf:resource="http://renardus.sub.uni-goettingen.de/renap/racr.html#DDC2" />

<dcap:encodingScheme rdf:resource="http://renardus.sub.uni-goettingen.de/renap/racr.html#GOK" />

<dcap:encodingScheme rdf:resource="http://renardus.sub.uni-goettingen.de/renap/racr.html#SWD" />

<dcap:encodingScheme rdf:resource="http://renardus.sub.uni-goettingen.de/renap/racr.html#NLM" />

<dcap:encodingScheme rdf:resource="http://renardus.sub.uni-goettingen.de/renap/racr.html#MSC2000" />

<dcap:encodingScheme rdf:resource="http://renardus.sub.uni-goettingen.de/renap/racr.html#ZADISC" />

<dcap:isMemberOf rdf:resource="http://renardus.sub.uni-goettingen.de/renap/" />

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

- <dcap:PropertyUsage rdf:about="http://renardus.sub.uni-goettingen.de/renap/renap.html#description">

<dcap:uses rdf:resource="http://purl.org/dc/elements/1.1/description" />

<rdfs:label>Description</rdfs:label>

<dc:description>For the Renardus normalization process it is not enough to provide only a URL, for cross-search reasons the field description must contain free text. Use text (and not only a URL) to describe the resource.</dc:description>

<dcap:obligation rdf:resource="http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/Obligation/mandatory" />

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://renardus.sub.uni-goettingen.de/renap/" />

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

- <dcap:PropertyUsage rdf:about="http://renardus.sub.uni-goettingen.de/renap/renap.html#identifier">

<dcap:uses rdf:resource="http://purl.org/dc/elements/1.1/identifier" />

<rdfs:label>Identifier</rdfs:label>

<dc:description>URI required, meaning URL, URN, DOI, ISBN, ISSN etc. For Renardus normalization process DOI, ISBN and ISSN must be displayed in a URN syntax. In the prototype system no distinction will be made between resource URL, mirrored, copied resource URL(s) and URL(s) for archive reasons.</dc:description>

<dcap:obligation rdf:resource="http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/Obligation/mandatory" />

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:encodingScheme rdf:resource="http://www.w3.org/2001/XMLSchema#anyURI" />

<dcap:isMemberOf rdf:resource="http://renardus.sub.uni-goettingen.de/renap/" />

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

- <dcap:PropertyUsage rdf:about="http://renardus.sub.uni-goettingen.de/renap/renap.html#language">

<dcap:uses rdf:resource="http://purl.org/dc/elements/1.1/language" />

<rdfs:label>Language</rdfs:label>

<dc:description>The language code is ISO 639-2, three letter terminology code. A mapping between two letter and three letter language codes is available by LoC at http://lcweb.loc.gov/standards/iso639-2/englangn.html</dc:description>

<dcap:obligation rdf:resource="http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/Obligation/mandatory" />

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:encodingScheme rdf:resource="http://purl.org/dc/terms/ISO639-2" />

<dcap:isMemberOf rdf:resource="http://renardus.sub.uni-goettingen.de/renap/" />

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

- <dcap:PropertyUsage rdf:about="http://renardus.sub.uni-goettingen.de/renap/renap.html#type">

<dcap:uses rdf:resource="http://purl.org/dc/elements/1.1/type" />

<rdfs:label>Type</rdfs:label>

<dc:description>Subject Gateways should provide their original types without any encoding scheme. SUB provides a mapping of all types used in partners' subject gateways to DCMI Type Vocabulary.</dc:description>

<dcap:obligation rdf:resource="http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/Obligation/recommended" />

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:encodingScheme rdf:resource="http://purl.org/dc/terms/DCMIType" />

<dcap:seeAlso rdf:resource="http://db1-www.sub.uni-goettingen.de/servlets/RenardusType?Table=Renardus_Type&Head=Renardus+Type+List" />

<dcap:isMemberOf rdf:resource="http://renardus.sub.uni-goettingen.de/renap/" />

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

- <dcap:PropertyUsage rdf:about="http://renardus.sub.uni-goettingen.de/renap/renap.html#country">

<dcap:uses rdf:resource="http://renardus.sub.uni-goettingen.de/renap/renap.html#country" />

<rdfs:label>Country</rdfs:label>

<dc:description>Country in which the publisher of the resource is located or the country which represents the cultural context of the resource. Code for the representation of names of countries.</dc:description>

<dcap:obligation rdf:resource="http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/Obligation/recommended" />

<dcap:maxOccurs>Unbounded</dcap:maxOccurs>

<dcap:encodingScheme rdf:resource="http://purl.org/dc/terms/ISO3166" />

<dcap:encodingScheme rdf:resource="http://renardus.sub.uni-goettingen.de/renap/renap.html#country" />

<dcap:isMemberOf rdf:resource="http://renardus.sub.uni-goettingen.de/renap/" />

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

- <dcap:PropertyUsage rdf:about="http://renardus.sub.uni-goettingen.de/renap/renap.html#fullrecord">

<dcap:uses rdf:resource="http://renardus.sub.uni-goettingen.de/renap/renap.html#fullrecord" />

<rdfs:label>Full Record URL</rdfs:label>

<dc:description>A URL that leads to a detailed display of each record at the originating service site.</dc:description>

<dcap:obligation rdf:resource="http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/Obligation/mandatory" />

<dcap:maxOccurs>1</dcap:maxOccurs>

<dcap:encodingScheme rdf:resource="http://www.w3.org/2001/XMLSchema#anyURI" />

<dcap:isMemberOf rdf:resource="http://renardus.sub.uni-goettingen.de/renap/" />

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

- <dcap:PropertyUsage rdf:about="http://renardus.sub.uni-goettingen.de/renap/renap.html#SBIGID">

<dcap:uses rdf:resource="http://renardus.sub.uni-goettingen.de/renap/renap.html#SBIGID" />

<rdfs:label>SBIGID</rdfs:label>

<dc:description>A stable unique acronym also well defined in the Collection Level Description.</dc:description>

<dcap:obligation rdf:resource="http://www.ukoln.ac.uk/metadata/cen/ws-mmi-dc/terms/Obligation/mandatory" />

<dcap:maxOccurs>1</dcap:maxOccurs>

<dcap:isMemberOf rdf:resource="http://renardus.sub.uni-goettingen.de/renap/" />

<rdfs:isDefinedBy rdf:resource="" />

</dcap:PropertyUsage>

</rdf:RDF>

Appendix C. Expressing DCAPs using OWL

The OWL Web Ontology Language is a W3C schema language with a vocabulary of modelling constructs richer than those provided by XML, RDF, and RDF Schema. Specifically, OWL supports the formal expression of usage constraints of the sort often described in DCAPs.

Whilst RDFS can describe simple relationships between classes, between properties, and between properties and classes (subPropertyOf, subClassOf, range, domain), using RDFS alone all of the statements made about classes and properties are global in scope. In contrast, OWL enables one to express constraints locally to a class of resources being described, offering the potential for imposing constraints on descriptions of particular classes of resource. OWL allows one to describe a range of properties and cardinality constraints locally with respect to a class.

As a relatively new language, OWL is comparatively untested in applications, so its use in expressing DCAPs would by definition be of an innovative and experimental nature. Areas of uncertainty regarding use of OWL for expressing DCAPs include the following:

- There is little re-use of properties across OWL ontologies, whereas describing the re-use of properties is the single most important function of a DCAP. Suggesting innovative uses of OWL in this regard is not an appropriate role for a CWA such as this.

- It is open for debate as to whether a DCAP describes a particular "class" of resources in the way that OWL expects. The theoretical question is further complicated by the fact that Documentational DCAPs, in practice, serve a wide range of uses in a wide range of application scenarios.

- In OWL, "localisation" is based on associating property restrictions with specific classes and types; there is in OWL no other way to specify cardinality and value-space constraints. DCAPs typically do not express constraints explicitly with respect to type and class, so the use of OWL to model constraints would seem to entail a modelling effort which goes beyond that of the DCAP.

- The OWL specifications say that Dublin Core properties can be used as annotation properties, i.e., to describe classes and properties in an ontology. There is some doubt as to whether Dublin Core properties can be used in the ontology itself. Discussion on www-rdf-logic mailing list suggests that Dublin Core properties can be used in OWL Full (see http://lists.w3.org/Archives/Public/www-rdf-logic/2004Apr/0014.html).

- OWL makes a distinction between DatatypeProperties (which take literal values) and ObjectProperties (which take resources as values), whereas the values of Dublin Core properties can be literals or resources. There is a danger, therefore, that a DCAP represented in OWL might contradict the usage expressed in the same DCAP modelled in another syntax (see http://lists.w3.org/Archives/Public/www-rdf-logic/2004Feb/0042.html).

- In OWL, care must be taken not to contradict existing declarations, and existing usage. In Dublin Core practice, existing usage is so varied (with respect to using literals as opposed to resources as values) that the risks of introducing contradictions are high.

- Some dialects of OWL do not support some of the RDF constructs used by DCMI (such as classes of classes).

Appendix D. Comparison of the IEEE/LOM and DC data models

The essential difference between the two models can be summarized as follows:

- The Dublin Core data model is a simple flat list of 15 data elements [DCES].

- The Learning Object Metadata data model is a simple hierarchy, where composite data elements do not have values directly, i.e. only the “leafs” in the hierarchy can carry values [IEEE-LOM].

In principle, it is not so difficult to transform flat DC instances into hierarchical LOM instances or vice versa. Indeed, as an example, an instance of DC:creator can be mapped into LOM: LifeCycle.Contribute.Entity where LOM:LifeCycle.Contribute.Role equals “Author.” Likewise, LOM:Technical.Format can be mapped to DC:Format. The LOM standard actually includes a table that defines a complete mapping of the DC metadata element set into equivalent LOM data element structures.

However, when one considers the situation in more detail, some additional complexities become apparent.

- Besides the unqualified DC element set, the DCMI metadata terms also include

- other elements (Audience);

- element refinements (Alternative for Title, tableOfContents or Abstract for Description, etc.); and

- encoding schemes (LCSH, MeSH, DDC, LCC, UDC for Subject, DCMIType for Type, etc.)

- type vocabulary (Collection, Dataset, Event, etc.)

- Besides the basic hierarchical structure, the LOM standard also defines for each element

- The value space: the set of allowed values, defined in a conceptual, binding and data type independent way;

- Datatype: LangString, DateTime, Duration, Vocabulary, CharacterString or Undefined.

The LOM standard does not define how values are represented in a concrete binding. In fact, several such bindings are under development for LOM.

Moreover, the LOM data element set is considerably more numerous than the DC one.

Although a simple first analysis suggests that DC data elements can be mapped to LOM in a rather straightforward way, the reverse operation is more complex, as LOM defines a more elaborate structure than DC. Moreover, once we take into account information about DC element refinements, encoding schemes and type vocabularies, as well as the value space and datatype information of LOM, semantically consistent mappings become more difficult to define.

Appendix E. Geographic requirements for DCAP

Geographic information is of increasing interest across a wide range of disciplines and applications. Various groups are working to increase the use of metadata to support discovery of geographic resources. Central to this activity is the international standard ISO 19115 – Geographic Information - Metadata [ISO19115], a detailed metadata standard designed for comprehensive description of geospatial data. There have been various initiatives to adapt this standard to support simple, interoperable resource discovery by creating DCAPs i.e. by extending qualified DC with data elements drawn from the standard. The CEN CWA 14858 [CWA 14858] outlines a Dublin Core Spatial Application Profile to support the discovery of geographical datasets in general-purpose, cross-domain repositories and portals; and secondly, within the UK, the GEMINI application profile [GEMINI] has been drawn up to support creation of 'discovery metadata' within e-government applications.

ISO 19115 provides information about the identification, extent, quality, spatial and temporal schema, spatial reference, and distribution of digital geographic data. It is important to note that the following comments on the suitability of the machine-processable DCAP model are limited to the specific case of a DCAP designed to support resource discovery of geographic resources. Specifically, the comments do not assume that the DCAP model would be used for detailed description of a dataset in its full complexity. In other words, it does not assume that the DCAP model would be used for full implementations of the ISO 19115 standard.

The most important issue with regard to the machine-processable DCAP model as presented in this CWA is its limitation to the description of a single resource. In contrast, an ISO 19115 description covers multiple entities. For example, ISO 19115 metadata can include descriptions of the sources and suppliers of the data, the provenance of datasets, appropriate use of the data, and a description of the quality and accuracy of the data.

In terms of the DCMI Abstract Model, such entities would need to be presented as "rich values" or even modelled as separate resources requiring "related descriptions," which are not supported by the simpler DCAP model presented in this CWA. The single-resource constraint means that only a limited set of properties can be extracted from ISO 19115 metadata for presentation as one flat set of attributes in the DCAP. In doing so, application designers must bear in mind that a single-resource DCAP will present these as stand-alone properties outside of the hierarchical context of the ISO 19115 data model.

A second important issue is that the maintainers of ISO 19115 have not assigned URIs to the 300-plus data elements of the standard, nor have they provided guidelines on how one might do so. The problem of referencing such a URI out of the context of a hierarchical model would be similar to that outlined in Appendix D (above) with respect to the IEEE LOM.