Dublin Core (Registered Trademark) Metadata Initiative logo and catchphrase: 
Making it easier to find information
Jump to main content: This Page
Jump to site map: New Page
The Metadata Community — Supporting Innovation in Metadata Design, Implementation & Best Practices
Dublin Core (Registered Trademark) logo innovation banner Join us logo


Criteria for the Review of Application Profiles

Creator: DCMI Usage Board
Date Issued: 2009-03-02
Identifier: http://dublincore.org/documents/2009/03/02/profile-review-criteria/
Replaces: http://dublincore.org/documents/2009/01/05/profile-review-criteria/
Latest Version: http://dublincore.org/documents/profile-review-criteria/
Status of Document: This is a DCMI Recommended Resource
Description of Document: This document articulates the criteria used by the DCMI Usage Board to review application profiles.

1. Object of Evaluation

The following guidelines articulate the criteria by which the DCMI Usage Board reviews an Application Profile. As of March 2008, the main points of reference for these review criteria are the Singapore Framework for Dublin Core Application Profiles [SINGAPORE-FRAMEWORK], Abstract Model [DC-AM], and a draft Description Set Profile specification [DC-DSP]. Best-practice examples of application profiles include Dublin Core Collections Application Profile [DC-CAP], which was reviewed by the Usage Board [DC-CAP-REVIEW], and Eprints Application Profile [EPRINTS].

An application profile is a document (or package of documents) which describes a metadata application in order to facilitate broader reuse of its metadata. A good profile provides enough detail and context to be of use to

An application profile documents the following:

Some of these components are considered to be "required", while others are simply "recommended". There is an overriding requirement for documentation to be semantically clear and internally consistent.

2. Areas of Evaluation

2.1. Objectives and Scope of the Application

The objectives and scope of an application MUST be described. The documentation MUST provide answers to the following:

The documentation SHOULD provide answers to the following:

2.2. Functional Requirements of the Application

The documentation MUST describe the functions of an application with regard to user needs. These functional requirements should be defined as general functions such as "find", "identify", or "select" but may be more specific.

The following question is required:

2.3. Domain Model

An application profile MUST provide a data model, if only a simple one, which describes the entities and relationships among the entities. The data model can be depicted in graphic form (e. g., as an UML class diagram) or in text. An application profile can be based on an externally defined data model. With regard to the data model the following questions have to be answered:

2.4. Description Set Profile

A description set profile specifies a metadata record in terms of "templates" and "constraints" [DC-DSP]:

2.4.1. Description Templates for the Entities of the Domain Model

If the Domain Model has only one type of resource (e.g., "book"), then all of the statements in the DSP document can be taken to be about that resource. In formal terms, the Description Template is implied and need not be explicitly labeled as such.

If the Domain Model has more than one described entity (e.g., "author" and "book"), the metadata needs to have separate Descriptions for each of those entities. Accordingly, the description set profile should provide separate, clearly delimited sections (Description Templates).

The header or introduction of a Description Template should provide the following information:

2.4.2. Statement Templates within a Description Template

Statement Templates are typically presented as small tables for each of the "terms used" in the metadata, together with information on how those terms are used (with what cardinality, encoding schemes, and the like), along with "cataloguing rules" or usage guidelines.

These tables may include the following information:

These tables must include one of the following property constraints:

Within a single Description Template, the Property Constraints should be constructed in such a way that a property URI in a statement can match the Property Constraint in at most one Statement Template. For example, it is not permissible to have two Statement Templates each with a Property List Constraint referring to the same property.

Statement Templates defining Literal Value Constraints: If only strings (i.e., literals) are allowable as values, then the Statement may be defined as referring to a Literal Value, which is represented by a Literal Value Surrogate. Allowable constraints (on a ''Literal Value Surrogate'') include:

Statement Templates defining Non-Literal Value Constraints: Allowable constraints (on a Non-Literal Value Surrogate) include:

2.4.3. Templates and Constraints as a Whole

About the templates and constraints (or their functional equivalents) as a whole, the reviewer should ask:

Not all of the information included in a Description Set Profile will fall into the typology delineated above. Any such information may be considered "annotations" -- user guidance falling outside the Description Set Profile in a formal sense. For these types of information, the reviewer should ask the following:

2.5. Metadata Terms Referenced in the Description Set Profile

The task of the reviewer is to identify the "terms used" in a description set profile and test whether the terms are suitable for use in metadata based on the DCMI Abstract Model. To be suitable, terms MUST be one of the four types of "metadata terms" with a defined role in the DCMI Abstract Model: Properties (also known as Elements), Classes, Vocabulary Encoding Schemes (VES), and Syntax Encoding Schemes (SES). The following questions test whether a given term fits this known typology:

If the term in question is not clearly defined as one of these four types, it has no recognized function in metadata based on the DCMI Abstract Model.

2.5.1. Discussion

Declaration in an RDF schema. RDF schemas state how a given terms fit into typologies defined by standard specifications such as "RDF Vocabulary Description Language 1.0: RDF Schema" [RDFS] and DCMI Abstract Model [DC-AM]. Example schemas include those of DCMI Metadata Terms [DCMI-TERMS], the SKOS vocabulary [SKOS-VOCABULARY], and the RDF Vocabulary Description Language (RDF Schema) itself [RDFS-VOCABULARY]. For example, the term "Publisher" is declared to be an "RDF property" in the RDF schema for DCMI Metadata Terms as follows:

  <rdf:Description rdf:about="http://purl.org/dc/terms/publisher">
  <rdfs:label xml:lang="en-US">Publisher</rdfs:label>
  <rdfs:comment xml:lang="en-US">An entity responsible for making the 
  resource available.</rdfs:comment>
  <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>

Best-practice RDF schemas. Best practice examples of well-declared terms are DCMI Metadata terms [DCMI-TERMS], Dublin Core Collection Description Terms [DC-CDT], and Eprints Terms [EPRINTS-TERMS]. Terms must also be declared in RDF schemas (e. g. for DCMI metadata terms [DCMI-TERMS-RDF]. and Dublin Core Collection Description Terms [DC-CDT-RDF].

Making RDF schemas available. The W3C note "Best Practice Recipes for Publishing RDF Vocabularies" [RECIPES] describes how HTTP redirects should be used to redirect from term URIs to the RDF schemas used to describe those terms. As described in the note, RDF schemas should ideally be made available on servers configured to provide HTML Web page or RDF schema representations of term declarations via content negotiation on the basis of browser preferences (`text/html` or `application/rdf+xml`).

"Proper" URIs. By convention, new terms coined during the creation of an application profile are often assigned temporary URIs using the domain name `http://example.org`. As `http://example.org` URIs cannot be made to resolve to term declarations, such provisional URIs should be replaced by proper URIs on which metadata can be based. "Proper" URIs are URIs under a domain in which the authors of the terms are authorized to coin such URIs.

Types of terms and subclasses thereof. Types of terms defined as subclasses of the classes listed above can be used in DC-AM-based metadata -- e.g., from the Web Ontology language [OWL]: http://www.w3.org/2002/07/owl#Class is a subclass of http://www.w3.org/2000/01/rdf-schema#Class and http://www.w3.org/2002/07/owl#ObjectProperty is a subproperty of http://www.w3.org/1999/02/22-rdf-syntax-ns#Property.

2.6. Syntax Guidelines

Guidelines on syntax options and data formats may optionally be provided in an application profile. If such materials are provided, the reviewer should ascertain whether the syntax (or syntaxes) chosen support the constraints expressed in the Description Set Profile. For example, if a given encoding syntax does not support the DC-AM construct Vocabulary Encoding Scheme URIs, and constraints on Vocabulary Encoding Scheme URIs are defined in the Description Set Profile, then the reviewer should flag this inconsistency. Reviewers should consider the possibility that a Description Set Profile is not expressed in a data format directly, but by way of a transformation (e.g., GRDDL).

The reviewer should ask the following:


Dublin Core Collections Application Profile, 9 March 2007.
DCMI Usage Board Review of Collections Application Profile, 20 July 2007.
Dublin Core Collection Description Terms, 9 March 2007.
RDF schema for Dublin Core Collection Description Terms, 9 March 2007.
Nilsson, Mikael. Description Set Profiles: A constraint language for Dublin Core Application Profiles.
Powell, Andy, Mikael Nilsson, Ambjörn Naeve, Pete Johnston, Thomas Baker. DCMI Abstract Model.
DCMI Metadata Terms.
RDF schema for http://purl.org/dc/terms/.
Eprints Terms.
Web Ontology Language (OWL) Reference Version 1.0.
RDF Vocabulary Description Language 1.0: RDF Schema.
RDF schema for RDF Vocabulary Description Language (RDF Schema).
Best Practice Recipes for Publishing RDF Vocabularies.
Nilsson, Mikael, Thomas Baker, Pete Johnston. The Singapore Framework for Dublin Core Application Profiles.
SKOS Core Vocabulary Specification.

Change history

2009-03-02. Corrected optionality of "type of value surrogate" in Section 2.4.2, first set of bullet points (from "mandatory" to "optional") as per resolution of 28 January 2009. Added sentence about checking for multiple statement templates with shared property list constraints as per resolution of 26 February 2009.

Copyright © 1995-2017 DCMI. All Rights Reserved.