The DCMI Metadata Framework DCMI Abstract Model Vocabularies Application Profiles Mikael Nilsson <mikael@nilsson.name>

DCMI Abstract Model

Vocabularies

Application Profiles

Mikael Nilsson <mikael@nilsson.name>

The DCMI Metadata Framework Fundamental notion: the one-to-one principle ” One resource – one description” History: 1994: 15 ”core” elements 2000: Qualifiers => need for a model 2002: Grammatical principles 2005: DCMI Abstract Model

Fundamental notion: the one-to-one principle

” One resource – one description”

History:

1994: 15 ”core” elements

2000: Qualifiers => need for a model

2002: Grammatical principles

2005: DCMI Abstract Model

DCMI Abstract Model Defines the core constructs used in DC metadata: properties , vocabulary encoding schemes, etc... Refined and formalized version of the “DCMI Grammatical Principles” Built on the one-to-one principle Basis for defining vocabularies, profiles and syntaxes Basis for interoperability with other initiatives RDF & the Semantic Web IEEE LOM etc.

Defines the core constructs used in DC metadata: properties , vocabulary encoding schemes, etc...

Refined and formalized version of the “DCMI Grammatical Principles”

Built on the one-to-one principle

Basis for defining vocabularies, profiles and syntaxes

Basis for interoperability with other initiatives

RDF & the Semantic Web

IEEE LOM

etc.

Basic structure of DCAM Value Resource Property Property/value pair Non-literal Literal

The Manzanillo Framework

Creating metadata using DCAM Description Set Profile Description Set Metadata record Interoperable interpreter transfer usage DMCI Abstract Model Functional Requirements Vocabulary (existing and new) Domain Model (Entities and relationships) Resources Syntax

Remaining Questions 1: What is RDA? Framework? Abstract Model? Vocabulary? Application Profile? Syntax?

Framework?

Abstract Model?

Vocabulary?

Application Profile?

Syntax?

Remaining Questions 2: Who's RDA for? Librarians? Application developers? Database managers? Users? Vocabulary creators? Application Profile creators?

Librarians?

Application developers?

Database managers?

Users?

Vocabulary creators?

Application Profile creators?

The ”values” of the DCAM Two sorts: Values ”in” the description itself = Literals (not the same as value strings) Other values Literal = string + language or datatype (=SES) Non-literals are described ” inline” by 0 - 1 URI for identification 0 – 1 VES for identifying controlled vocabulary 0 – many value strings (= string + language or datatype) in a separate description

Two sorts:

Values ”in” the description itself = Literals (not the same as value strings)

Other values

Literal = string + language or datatype (=SES)

Non-literals are described

” inline” by

0 - 1 URI for identification

0 – 1 VES for identifying controlled vocabulary

0 – many value strings (= string + language or datatype)

in a separate description

Interoperability for DC metadata Reusing existing properties... in new application profiles in new syntaxes Adding new properties to... existing application profiles existing syntaxes Introducing new values to existing properties Expressing existing APs in new syntaxes

Reusing existing properties...

in new application profiles

in new syntaxes

Adding new properties to...

existing application profiles

existing syntaxes

Introducing new values to existing properties

Expressing existing APs in new syntaxes

Vocabulary Model (elements) Example: http://dublincore.org/documents/dcmi-terms/

Vocabulary Model (values) No real consensus on how to describe value vocabularies. Value vocabularies come in many kinds simple lists thesauri taxonomies ontologies etc. SKOS?

No real consensus on how to describe value vocabularies.

Value vocabularies come in many kinds

simple lists

thesauri

taxonomies

ontologies

etc.

SKOS?

Profile Model Example: CEN/ISSS CWA 14855

Where we are (DC family)

Where others are (IEEE LOM family)

Where others are (RDF family)

Cross-framework interoperability How about interoperability between DC <==> IEEE LOM <==> RDF <==> MPEG-7 etc.? All follow the same basic pattern BUT – very different abstract models In general: cross-framework is hard DC <==> RDF works – as models are intentionally compatible See also “ The Future of Learning Object Metadata Interoperability” , in Koohang A. (ed.) Learning Objects: Standards, Metadata, Repositories, and LCMS, in press.

How about interoperability between

DC <==> IEEE LOM <==> RDF <==> MPEG-7 etc.?

All follow the same basic pattern

BUT – very different abstract models

In general: cross-framework is hard

DC <==> RDF works – as models are intentionally compatible

See also “ The Future of Learning Object Metadata Interoperability” , in Koohang A. (ed.) Learning Objects: Standards, Metadata, Repositories, and LCMS, in press.

Terminology Stop using “metadata standard” or “schema” Start using either abstract model metadata format/syntax metadata vocabulary application profile “ What kind of specification am I trying to produce?” Most: application profile (+ some vocabulary)

Stop using “metadata standard” or “schema”

Start using either

abstract model

metadata format/syntax

metadata vocabulary

application profile

“ What kind of specification am I trying to produce?”

Most: application profile (+ some vocabulary)

Take home message Formalized models (DCAM, vocabs, profiles) pave the way for interoperable processing A clear framework helps us fill in the blanks Much progress over the last year! See DC-ARCH... The word ”schemas” is overused...

Formalized models (DCAM, vocabs, profiles) pave the way for interoperable processing

A clear framework helps us fill in the blanks

Much progress over the last year! See DC-ARCH...

The word ”schemas” is overused...