DC Application Profile
This page is to summarize the DCMIDublin Core Metadata Initiative specifications and concepts of DCDublin Core Metadata profiles and howto create them.
- 1 DCMI Description Set Profile
- 2 DCMI Application Profile (DCAP)
- 3 DCMI Abstract Model
- 4 DCMI Process of Building an DCAP
- 4.1 Step 1: Defining Functional Requirements
- 4.2 Step 2: Selecting or Developing a Domain Model
- 4.3 Step 3: Selecting or Defining Metadata Terms
- 4.4 Step 4: Designing the Metadata Record with a Description Set Profile
- 4.5 Step 5: Usage Guidelines
- 4.6 Step 6: Syntax Guidelines
- 5 Appendix: Metadata Vocabularies
- 6 External Links
- 7 References
DCMIDublin Core Metadata Initiative Description Set Profile
Resources, properties and values are given in a Description set which can be defined in a Description Set Profile (DSPDescription Set Profile). A Description Set Profile (DSPDescription Set Profile) 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 DSPDescription Set Profile:
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 DSPDescription Set Profile.
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 RDFResource Description Framework [RDFResource Description Framework].
Dublin Core Abstract Model A generic syntax for metadata records.
DCMIDublin Core Metadata Initiative syntax guidelines/DCMIDublin Core Metadata Initiative Encodings Which use the generic syntax for concrete implementation encodings.
DCMIDublin Core Metadata Initiative 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 (DSPDescription Set Profile) - 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.
DCMIDublin Core Metadata Initiative Abstract Model
What is DCAMDublin Core Abstract Model?
- it is an information model that specifies the components and constructs used in DCDublin Core metadata
- it defines how the components can be combined to create information structures
- it is syntax independent
- it uses the RDFResource Description Framework concepts
DCAMDublin Core Abstract Model deals with three basic concepts:
- DCMIDublin Core Metadata Initiative Resource Model
- DCMIDublin Core Metadata Initiative Description Set Model
- DCMIDublin Core Metadata Initiative Vocabulary Model
The DCMIDublin Core Metadata Initiative Resource Model
What is a Resource?
- DCMIDublin Core Metadata Initiative uses the RDFResource Description Framework idea of a resource: RDFResource Description Framework defines a resource as anything that is identifiable by a URIUniform Resource Identifier 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 DCMIDublin Core Metadata Initiative 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 URIUniform Resource Identifier
What is a Statement?
- instance of a property-value pair (property-URIUniform Resource Identifier and a value), e.g. dc:creator "Max Müller"
The DCMIDublin Core Metadata Initiative Vocabulary Model
DCMIDublin Core Metadata Initiative 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 UMLUnified Modeling Language), 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 URIUniform Resource Identifier to the value or refer to a value description?
Step 4: Designing the Metadata Record with a Description Set Profile
- Description Set Profile (DSPDescription Set Profile) describes the metadata record in detail
- DSPDescription Set Profile is a constraint language for DCAPs
- DSPs are based on the Description Set Model, which is part of the DCAMDublin Core Abstract Model
- DSPDescription Set Profile 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 DSPDescription Set Profile, but more human-readable
- Usage guideline can be included in DSPDescription Set Profile or a separate document
Step 6: Syntax Guidelines
Syntax Guidelines should help the developer to implement the Application Profile in a specific language. The DCMIDublin Core Metadata Initiative has developed/is developing some encoding guidelines  in HTMLHypertext Markup Language/XHTMLExtensible HyperText Markup Language, XMLExtensible Markup Language, RDFResource Description Framework/XMLExtensible Markup Language. 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
ReferencesDCAMDublin Core Abstract Model
Powell, Andy, Mikael Nilsson, Ambjörn Naeve, Pete Johnston and Thomas Baker. DCMIDublin Core Metadata Initiative Abstract Model. DCMIDublin Core Metadata Initiative Recommendation. June 2007.
DSPDescription Set Profile
Mikael Nilsson. DCMIDublin Core Metadata Initiative Description Set Profile Model. Working Draft, December 2007. http://dublincore.org/architecturewiki/DescriptionSetProfile
Generic handling of metadata MPDL Draft