Dublin Core, the DCMI Abstract Model & DC Application Profiles

transcript

Pete Johnston, Eduserv Foundationpete.johnston@eduserv.org.uk

www.eduserv.org.uk/foundation

Dublin Core, the DCMI Abstract Model &DC Application Profiles

Images DC Application Profile WG meeting, London

29 October 2007Images DCAP WG meeting, London 2

Title slide photo of Banksy painting by Flickr user s0mmieSee http://www.flickr.com/photos/s0mmie/459881039//Made available under CC Attribution-NonCommercial-Share-Alike 2.0 license

An Introduction to the DCMI Abstract Model

• Why the DCAM?

• The DCMI Abstract Model

• The DCAM & “DC application profiles”

• Dublin Core in 2007

Why DCAM? Context & Motivation

• Some issues for DCMI c.2003– Metadata vocabularies

• … but what is a DC “element”?– Encoding guidelines

• … but what are we “encoding”?– DC application profiles

• … but what “terms” can we “use”?– “Simple” and “Qualified” DC– Grammatical Principles– DC & the Resource Description Framework

• Work on DCAM from mid-2003, initiated by Andy Powell• Initial Version, DCMI Recommendation, 2005-03-07• Second Version, DCMI Recommendation, 2007-06-04

– http://dublincore.org/documents/2007/06/04/abstract-model/

The DCMI Abstract Model

• DCAM concerned with description of resources• DCAM adopts Web Architecture/RFC3986 definition of

resource– the term "resource" is used in a general sense for whatever

might be identified by a URI. Familiar examples include an electronic document, an image, a source of information with consistent purpose (e.g., "today's weather report for Los Angeles"), a service (e.g., an HTTP to SMS gateway), a collection of other resources, and so on.

– A resource is not necessarily accessible via the Internet; e.g., human beings, corporations, and bound books in a library can also be resources.

– Likewise, abstract concepts can be resources, such as the operators and operands of a mathematical equation, the types of a relationship (e.g., "parent" or "employee"), or numeric values (e.g., zero, one, and infinity).

– RFC3986 URI Syntax

• DCAM describes– Components and constructs that make up an

information structure (“DC description set”)– How that information structure is to be interpreted

• Made up of three related “information models”

– Resource model– Description set model– Vocabulary model

• In this presentation, focus on description set model

• DCAM does not describe how to represent DC description set in concrete form

– “Encoding guidelines”– Updating of specs in progress (2007)

• DC-XML• DC in X/HTML link/meta elements

– Some formats defined outside of DCMI, e.g. Eprints DC-XML• DCAM describes various types of metadata term, but does

not specify the use of any fixed set of terms– Metadata vocabularies

• Define/owned by DCMI or by other agencies

• DCAM & RDF– Mapping of description sets to RDF graph specified by

Expressing DC metadata using RDFhttp://dublincore.org/documents/2007/06/04/dc-rdf

DCAM Resource Model

• The “view of the world” on which DC metadata is based

• a described resource is described using one or more property-value pairs

• a property-value pair is made up of – exactly one property and– exactly one value

• a value is a resource• a value is either a literal value or a non-literal value

• i.e. similar to RDF model of binary relations between resources; entity-relational model

DCAM Description Set Model

• The structure of DC metadata• Uses URIs to refer to resources & metadata terms (like RDF)

• a description set is made up of one or more descriptions, each of which describes one resource

• a description is made up of – zero or one described resource URI

• identifies described resource

– one or more statements

• a statement is made up of – exactly one property URI

• identifies property

– exactly one value surrogate

• a value surrogate is either a literal value surrogate or a non-literal value surrogate

Description Set

Description

Statement

Property URI

Resource URI

Literal Value Surrogate

Description

Statement

Property URI

Resource URI

Non-Literal Value Surrogate

Statement

Property URI

• a literal value surrogate is made up of – exactly one value string

• encodes value

• a non-literal value surrogate is made up of– zero or one value URIs

• identifies value– zero or one vocabulary encoding scheme URI

• identifies a set of which the value is a member– zero or more value strings

• represents value

• a value string is either a plain value string or a typed value string

– a plain value string may have an associated value string language

– a typed value string is associated with a syntax encoding scheme URI

Description Set

Description

Statement

Property URI

Resource URI

Description

Statement

Property URI

Resource URI

Statement

Property URI

Value URI

Vocab Enc Scheme URI

Value URI

Value string

Value string Syntax Enc Scheme URI

Language

Value string Language

• a value may be described by another description

Description Set

Description

Statement

Property URI

Resource URI

Description

Statement

Property URI

Resource URI

Statement

Property URI

Value URI

Value string

Syntax Enc Scheme URI

Language

Description Set

Description

Statement

Property URI

Description

Statement

Property URI

Resource URI

Statement

Property URI

Value URI

Value string

Syntax Enc Scheme URI

Language

Description Set

Description

Statement

Property URI

Resource URI

Example: Description set with two descriptions, statements with non-literal value surrogates & literal value surrogates

Statement

Property URI

Value URI

Value string

Value URI

Language

Description

Resource URI

Statement

Property URI

Value string Language

Description Set

Description

Statement

<http:/purl.org/dc/terms/subject>

<http://example.org/terms/mySH>

“Metadata”

"Métadonnées"

<http://purl.org/dc/terms/publisher>

<http://dublincore.org/documents/abstract-model/>

<http://example.org/org/DCMI>Property URI Value URI

<http://example.org/org/mySH/h123> Value URIProperty URI

Value String

Description

Statement

<http://example.org/org/DCMI>

<http://xmlns.com/foaf/0.1/name>

“Dublin Core Metadata Initiative” en Value StringProperty URI

Example: Description set with two descriptions, statements with non-literal value surrogates & literal value surrogates

@prefix dcterms <http://purl.org/dc/terms/> .@prefix foaf <http://xmlns.com/foaf/0.1/> .DescriptionSet ( Description ( ResourceURI ( <http://dublincore.org/documents/abstract-model/> ) Statement ( PropertyURI ( dcterms:publisher ) ValueURI (<http://example.org/org/DCMI> ) ) Statement ( PropertyURI ( dcterms:subject ) ValueURI (<http://example.org/mySH/h123> ) VocabEncSchemeURI (<http://example.org/terms/mySH> ) ValueString ( “Metadata” Language (en ) ) ValueString ("Métadonnées" Language (fr ) ) ) ) Description ( ResourceURI ( <http://example.org/org/DCMI> ) Statement ( PropertyURI ( foaf:name ) LiteralValueString ( “Dublin Core Metadata Initiative” Language (en) ) ) ))

The DCAM & “DC application profiles”

• DCAM does not specify the set of terms referenced in a description set

• Notion of “DC application profile” widely used within DCMI and by DC implementers

– Typically annotated lists of terms used in DC metadata so as to meet some domain/community requirements

– Terms defined by DCMI or by other agencies

• Specification of how to construct description sets (descriptions, statements) to serve some purpose

• Based on – functional requirements– domain model

DCMI Description Set Profile (DSP)

• A way of describing structural constraints on a description set

– the resources that may be described by descriptions in the description set

– the properties that may be used in statements– the ways a value surrogate may be given

• Description templates, statement templates• Model & XML Syntax for DSP

– Working draft by Mikael Nilsson (Royal Institute of Technology, Sweden)

– http://dublincore.org/architecturewiki/DescriptionSetProfile• Wiki Syntax for DSP

– Working draft by Fredrik Enoksson (Royal Institute of Technology, Sweden)

– http://dublincore.org/architecturewiki/DSPWikiSyntax

What is a DC Application Profile?

• A DCAM-conformant Application Profile (“DC Application Profile”) is packet of documentation which consists of:

– Functional requirements (desirable)

– Domain model (mandatory)

– Description Set Profile (DSP) (mandatory)

– Usage guidelines (optional)

– Encoding syntax guidelines (optional)

29 October 2007Images DCAP WG meeting, London 26Foundation standards

Domain standards

Application Profile

The “Singapore Framework”

Dublin Core in 2007

• a framework (the DCAM)– which describes how to use certain types of terms– ... to make statements...– ... that form descriptions (of resources)– … that can be grouped together as description sets

• a set of specifications for encoding description sets using various formats

• a managed vocabulary of widely useful terms– which can be referenced in statements

• support for defining additional vocabularies of terms• which can be referenced in statements

• support for defining DC application profiles– which describe how to construct description sets for some

particular set of requirements• extensibility, modularity, compatibility with Semantic Web

Pete Johnston, Eduserv Foundationpete.johnston@eduserv.org.uk

www.eduserv.org.uk/foundation

Images DC Application Profile WG meeting, London

Dublin Core, the DCMI Abstract Model & DC Application Profiles

Education