DC Application Profile
This page is to summarize the DCMI specifications and concepts of DC Metadata profiles and howto create them.
DCMI Description Set Profile
Resources, properties and values are given in a Description set which can be defined in a Description Set Profile (DSP). A Description Set Profile (DSP) basically consists of Templates and Constraints. Templates are to express structures and Constraints limit those structures. The following graphic from DCMI shows the basic structure of a DSP:
In the left part of the graphic all kinds of Templates are given. Templates describing
- resources (Description Template)
- statements or properties (Statement Template, Literal Statement Template, Non-literal Statement Template)
The right part of the graphic shows the different kinds of constraints that can occur in a DSP.
Constraints are used to define limitations on
- resources e.g. only resources of type foaf:person are allowed (Resource Constraints)
- properties e.g. a person has a property called foaf:name (Property Constraints)
- two ways: giving an explicit list of allowed properties, requiring the property to be a sub-property of a given property
- values e.g. the value of a special property must be a Literal (kinds of Literal Constraints, Value Constraints and Vocabulary Encoding Schemes)
Terms and Definitions
Statement Literal An entity which uses a Unicode string as a lexical form, together with an optional language tag or datatype, to denote a resource (i.e. "literal" as defined by RDF [RDF].
Dublin Core Abstract Model A generic syntax for metadata records.
DCMI syntax guidelines/DCMI Encodings Which use the generic syntax for concrete implementation encodings.
DCMI Application Profile (DCAP)
What is DCAP?
Dublin Core Application Profile (DCAP) is a description and specification of the metadata used in a particular application. It consists of one or more documents and contains:
- Functional Requirements of the application (mandatory)
- Domain Model - types of things that are described my metadata and relationships (mandatory)
- Description Set Profile (DSP) - catalogue with metdata terms and constraints (mandatory)
- Usage Guideline - describes how to apply the application profile, how the used properties are intended to be used in the application context etc.(optional)
- Encoding Syntax Guidelines and Data Formats - which syntax/format is used to encode the data (optional)
- Different applications have different metadata needs and use several formats and vocabularies.
- need to provide metadata across applications and semantic interoperability.
- DCAP is a framework that meets specific application needs while providing semantic interoperability with other applications on the basis of globally defined vocabularies and models (DCMI Profile Guidelines).
- DCAP is generic and you can use it with any metadata terms that are defined in accordance with the RDF.
DCMI Abstract Model
What is DCAM?
- it is an information model that specifies the components and constructs used in DC metadata
- it defines how the components can be combined to create information structures
- it is syntax independent
- it uses the RDF concepts
DCAM deals with three basic concepts:
- DCMI Resource Model
- DCMI Description Set Model
- DCMI Vocabulary Model
The DCMI Resource Model
What is a Resource?
- DCMI uses the RDF idea of a resource: RDF defines a resource as anything that is identifiable by a URI reference 
- each resource is described by one or more property-value pairs e.g. dc:creator "Hans Müller"
- a property-value pair consists of one property (e.g. dc:creator) and one value (e.g. "Hans Müller")
- each value can be a non-literal value (or resource: a physical, digital or conceptual entity) or a literal value
- a literal is a Unicode String with an optional language tag or datatype e.g. "2005-03-06"^^xs:date
The DCMI Description Set Model
What is a Description Set?
- set of one or more descriptions (each description describes a single resource)
What is a Description?
- description is made of one or more statements (about one resource) and zero or one URI
What is a Statement?
- instance of a property-value pair (property-URI and a value), e.g. dc:creator "Max Müller"
The DCMI Vocabulary Model
DCMI Process of Building an DCAP
Step 1: Defining Functional Requirements
- involved people: service manager, experts in the material being used, technical application developers and potential endusers of the service
- content: general goals and specific tasks.
- user tasks that must be supported
- developer needs
Ideally, functional requirements should address the needs of metadata creators, resource users, and application developers so that the resulting application fully supports the needs of the community
- methodologies: e.g. business process modeling, methods for visualizing requirements (such as UML), definition of use cases and scenarios for a particular application
Step 2: Selecting or Developing a Domain Model
The Domain Model describes the entities or things appear in the application and the relationships between them. Picture 2 shows a sample.
Step 3: Selecting or Defining Metadata Terms
In this step all entities identified by building the Domain Model have to be described using Metadata Terms as properties.
Define a Description Set for each entity of the Domain Model
Each entity of the Domain Model is described by a Description Set , which contains of a list of Statements. A Statement is a property-value surrogate pair (e.g. dc:title = SimpleLiteral).
Description Set: Book Statement: title Statement: creator Statement: date ...
Assign properties to Metadata Terms
Each Statement-property needs to be assigned to a Metadata Term. If no pre-defined term fits to the property intention, create a new one. Within a Description Set Metadata Vocabularies can be mixed up. Most metadata vocabularies are intended for a special purpose or special kinds of entities.
Description Set: Book Statement: title Property: http://purl.org/dc/terms/title Statement: creator Property: http://purl.org/dc/terms/creator ...
Describe the property value
The property value have to be configured by considering the following issues:
- is the value a free text or controlled vocabulary
- does it have a special syntax format (Syntax Encoding Scheme, e.g. YYYY-MM-DD for date)
- for controlled vocabulary: is there already a pre-defined list available?
- Do you want to use the complete list as it is or use a customized version with extended or limited elements?
- is the value a single string value like "text" (literal) or is it a composition of more values like "name, address, email" (non-literal)?
- is it intended to store a URI to the value or refer to a value description?
Step 4: Designing the Metadata Record with a Description Set Profile
- Description Set Profile (DSP) describes the metadata record in detail
- DSP is a constraint language for DCAPs
- DSPs are based on the Description Set Model, which is part of the DCAM
- DSP contains one Description Template for each thing/entity in the domain model
DescriptionSet: MyExample Description template: Book minimum = 1; maximum = 1 Statement template: title minimum = 1; maximum = 1 Property: http://purl.org/dc/terms/title
Step 5: Usage Guidelines
- instructions to the person who creates the metadata records
- the "how" and "why"
- explain each property and decisions regarding the metadata record
- some infos are also in the DSP, but more human-readable
- Usage guideline can be included in DSP or a separate document
Step 6: Syntax Guidelines
Syntax Guidelines should help the developer to implement the Application Profile in a specific language. The DCMI has developed/is developing some encoding guidelines  in HTML/XHTML, XML, RDF/XML. But any other syntax can be used as long as the data conforms to the foundation standards defined in DCAP.
Appendix: Metadata Vocabularies
The following links refer to specifications of some common metadata vocabularies sorted by their purpose:
- Publications and Documents
- Photo Metadata
- Description Set Profiles: A constraint language for Dublin Core Application Profiles
- DCMI Abstract Model
- EPrints Application Profile
Powell, Andy, Mikael Nilsson, Ambjörn Naeve, Pete Johnston and Thomas Baker. DCMI Abstract Model. DCMI Recommendation. June 2007. http://dublincore.org/documents/2007/06/04/abstract-model/
Mikael Nilsson. DCMI Description Set Profile Model. Working Draft, December 2007. http://dublincore.org/architecturewiki/DescriptionSetProfile
Generic handling of metadata MPDL Draft