DCMI: Criteria for the Review of Application Profiles

Creator:	DCMI Usage Board
Date Issued:	2009-03-02
Identifier:	http://dublincore.org/specifications/dublin-core/profile-review-criteria/2009-03-02/
Replaces:	http://dublincore.org/specifications/dublin-core/profile-review-criteria/2009-01-05/
Latest Version:	http://dublincore.org/specifications/dublin-core/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

information providers who may need to integrate metadata from multiple sources, and
developers who may want to build applications using the same (or similar) metadata.

An application profile documents the following:

objectives and scope of the application,
functional requirements of the application,
data model of the entities described by the application, and
a description set profile detailing the classes and properties used in an application, together with constraints on their usage.

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:

Is there a description of the context in which the application profile is used (or can be used)?

The documentation SHOULD provide answers to the following:

Is the target user group for the application profile identified and described?
Are the organizations and individuals who participated in the development of a profile identified and described?
Are any arrangements, guidelines, or intentions regarding the future development and maintenance of the profile described?

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:

Are the functional requirements defined?

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:

Does the model depict the set of entities to be described and the relationships among those entities?
If an application profile uses an externally defined data model:
- Is the externally data model identified?
- Are deviations from the externally defined data model documented?

2.4. Description Set Profile

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

A Description Template is a container for constraints on the described resource and for all of the statements made in a Description. (In the DCMI Abstract Model, a Description applies to about one, and only one, resource).
A Statement Template is a container for all of the constraints that apply in a particular Statement. (In the DCMI Abstract Model, a Statement is comprised of a Property URI and a Value Surrogate.)

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:

[MANDATORY] The class (or classes) of which resources described in this description may be an instance (e.g., foaf:Person, or http://xmlns.com/foaf/0.1/Person) (Resource Class Membership Constraint).
[OPTIONAL] A string used to identify the description in a metadata record.
[OPTIONAL] An indication of whether descriptions based on the template are allowed to stand alone (e.g., "an author may not be described in the absence of a described book").
[OPTIONAL] Minimum and maximum numbers of times this kind of description may appear in a description set.

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:

[OPTIONAL] Minimum and maximum numbers of times this kind of Statement may appear in the enclosing Description.
[OPTIONAL] The type of value surrogate (literal/non-literal) that is allowed in the statement.

These tables must include one of the following property constraints:

[OPTIONAL] Property List Constraint: A list (which may be a list of one member) of allowable properties used in the statement (to be given as URIs or abbreviated URIs, e.g., dcterms:creator or http://purl.org/dc/terms/creator).
[OPTIONAL] Sub-Property Constraint: A property of which any sub-property may be used; this constraint is rare.

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:

[OPTIONAL] A list of literals, such as "animal, vegetable, mineral..." (Literal List Constraint).
[OPTIONAL] An indication whether language indicators for the literal are "mandatory", "optional", or "disallowed".
[OPTIONAL] An indication of which languages are allowed for literals.
[OPTIONAL] An indication whether Syntax Encoding Schemes for the literal are "mandatory", "optional", or "disallowed".
[OPTIONAL] Syntax Encoding Scheme List Constraint: A list of allowed Syntax Encoding Schemes, identified by URI.

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

[OPTIONAL] The identifier of a Description Template that may be used to describe the value (Description Template Reference).
[OPTIONAL] Class membership constraint: A list of classes (identified by URI) of which the value may be an instance.
[OPTIONAL] Constraints on value URIs: whether a value URI is "disallowed", "optional", or "mandatory".
[OPTIONAL] Value URI List Constraint: a list of URIs that are allowed as value URIs.
[OPTIONAL] Vocabulary encoding scheme occurrence constraint: whether a vocabulary encoding scheme is "disallowed", "optional", or "mandatory".
[OPTIONAL] Vocabulary encoding scheme list constraint: a list of URIs that are allowed as Vocabulary Encoding Schemes.
Value String Constraints
- [OPTIONAL] Minimum occurrence constraints: the minimum number of times this kind of value string must appear in the enclosing Statement.
- [OPTIONAL] Maximum occurrence constraints: the maximum number of times this kind of value string is allowed to appear in the enclosing Statement.

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:

Do the constraints presented in the Description Templates and Statement Templates reflect the content of the domain model?
Are the constraints presented in the Statement Templates consistent with the definition of the property provided by its owner?
- The reviewer should verify whether the property declared in a Property Constraint has been declared with a literal or non-literal range and flag any contradictions to usage in the DSP.

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:

Is the recommended use of the term consistent with the definition provided by the term owner?
Is the usage of these terms in the description set profile consistent with their declared semantics?

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:

1. The DCMI Abstract Model requires that instances of Property, Class, SES, and VES be identified with Uniform Resource Identifiers (URIs). Has the term been assigned a "proper" URI (see discussion below)? If not, the term is not citable in RDF statements and is therefore not usable in metadata based on the DCMI Abstract Model.
1. Has the term been explicitly declared, in an RDF schema or other forms of documentation, to be one of the following:
- 1. an RDF Property, also known (in Dublin Core™ usage) as an Element (http://www.w3.org/1999/02/22-rdf-syntax-ns#Property or a subclass thereof). Used in: Property List Constraints, Sub-Property Constraints.
- 1. a Class (http://www.w3.org/2000/01/rdf-schema#Class or a subclass thereof). Used in: Resource Class Membership Constraints, Class Membership Constraints.
- 1. an RDF Datatype or (in Dublin Core™ usage) Syntax Encoding Scheme (http://www.w3.org/2000/01/rdf-schema#Datatype or a subclass thereof). Used in: Syntax Encoding Scheme List Constraints.
- 1. a Vocabulary Encoding Scheme (http://purl.org/dc/dcam/VocabularyEncodingScheme or a subclass thereof). Used in: Vocabulary Encoding Scheme List Constraints.

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"/>
  ...
  </rdf:Description>

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 andhttp://www.w3.org/2002/07/owl#ObjectPropertyis a subproperty ofhttp://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:

Does the application profile provide guidance on syntax (whether in the form of schemas or of human-readable user guidelines)?
If yes, does the syntax clearly support the DC-AM entities used in the application profile?

References

DC-CAP: Dublin Core™ Collections Application Profile, 9 March 2007.
<http://dublincore.org/specifications/dublin-core/collection-description/collection-application-profile/2007-03-09/>
DC-CAP-REVIEW: DCMI Usage Board Review of Collections Application Profile, 20 July 2007.
<http://dublincore.org/usage/reviews/2007/collections-ap/>
DC-CDT: Dublin Core™ Collection Description Terms, 9 March 2007.
<http://dublincore.org/specifications/dublin-core/collection-description/collection-terms/2007-03-09/>
DC-CDT-RDF: RDF schema for Dublin Core™ Collection Description Terms, 9 March 2007.
<http://dublincore.org/specifications/dublin-core/collection-description/collection-terms/2007-03-09/cldterms.rdf>
DC-DSP: Nilsson, Mikael. Description Set Profiles: A constraint language for Dublin Core™ Application Profiles.
<http://dublincore.org/specifications/dublin-core/dc-dsp/2008-03-31/>
DC-AM: Powell, Andy, Mikael Nilsson, Ambjörn Naeve, Pete Johnston, Thomas Baker. DCMI Abstract Model.
<http://dublincore.org/specifications/dublin-core/abstract-model/2007-06-04/>
DCMI-TERMS: DCMI Metadata Terms.
<http://dublincore.org/specifications/dublin-core/dcmi-terms/>
DCMI-TERMS-RDF: RDF schema for http://purl.org/dc/terms/.
<http://dublincore.org/2008/01/14/dcterms.rdf>
EPRINTS-TERMS: Eprints Terms.
<http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Terms>
OWL: Web Ontology Language (OWL) Reference Version 1.0.
<http://www.w3.org/TR/2003/WD-owl-ref-20030221/>
RDFS: RDF Vocabulary Description Language 1.0: RDF Schema.
<http://www.w3.org/TR/2004/REC-rdf-schema-20040210/>
RDFS-VOCABULARY: RDF schema for RDF Vocabulary Description Language (RDF Schema).
<http://www.w3.org/2000/01/rdf-schema#>
RECIPES: Best Practice Recipes for Publishing RDF Vocabularies.
<http://www.w3.org/TR/swbp-vocab-pub/>
SINGAPORE-FRAMEWORK: Nilsson, Mikael, Thomas Baker, Pete Johnston. The Singapore Framework for Dublin Core™ Application Profiles.
<http://dublincore.org/specifications/dublin-core/singapore-framework/2008-01-14/>
SKOS-VOCABULARY: SKOS Core Vocabulary Specification.
<http://www.w3.org/2004/02/skos/core>