|The Metadata Community — Supporting Innovation in Metadata Design, Implementation & Best Practices|
Global navigation options:
|Creator:||DCMI Usage Board||Date Issued:||2009-03-02|
|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.|
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.
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:
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:
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:
A description set profile specifies a metadata record in terms of "templates" and "constraints" [DC-DSP]:
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:
http://xmlns.com/foaf/0.1/Person) (Resource Class Membership Constraint).
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:
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:
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:
http://www.w3.org/1999/02/22-rdf-syntax-ns#Propertyor a subclass thereof). Used in: Property List Constraints, Sub-Property Constraints.
http://www.w3.org/2000/01/rdf-schema#Classor a subclass thereof). Used in: Resource Class Membership Constraints, Class Membership Constraints.
http://www.w3.org/2000/01/rdf-schema#Datatypeor a subclass thereof). Used in: Syntax Encoding Scheme List Constraints.
http://purl.org/dc/dcam/VocabularyEncodingSchemeor 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.
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
is a subproperty of
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:
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.