Dublin Core for Museums Day 2 Paul Miller UK Office for Library & Information Networking...

Dublin Core for MuseumsDay 2

Paul MillerUK Office for Library & Information Networking

p.miller@ukoln.ac.uk

Thomas HofmannAustralian Museums On-Line

thomash@amol.org.au

CIMI

John Perkins jperkins@cimi.org

Overview for Friday March 26 The Dublin Core in 1999 Break CIMI and the Dublin Core Lunch Beyond Dublin Core Discussion, Review Q&A

Stabilising the Dublin Core

Dublin Core has evolved rapidly; six international, interdisciplinary workshops

Dublin, Ohio, USA. March 1995 http://purl.oclc.org/metadata/dublin_core_reporthttp://purl.oclc.org/metadata/dublin_core_report

Warwick, United Kingdom. April 1996 http://www.dlib.org/dlib/july96/07weibel.htmlhttp://www.dlib.org/dlib/july96/07weibel.html

Dublin, Ohio, USA. September 1996 http://www.dlib.org/dlib/january97/oclc/01weibel.htmlhttp://www.dlib.org/dlib/january97/oclc/01weibel.html

Canberra, Australia. March 1997 http://www.dlib.org/dlib/june97/metadata/06weibel.htmlhttp://www.dlib.org/dlib/june97/metadata/06weibel.html

Helsinki, Finland. October 1997 http://www.dlib.org/dlib/february98/02weibel.htmlhttp://www.dlib.org/dlib/february98/02weibel.html

Washington DC, USA. November 1998 http://purl.org/dc/workshops/dc6conference/index.htmhttp://purl.org/dc/workshops/dc6conference/index.htm

Stabilising the Dublin Core

Dublin Core has evolved rapidly; expression in 27 different languages, including

English, Arabic, Burmese, Czech, Danish, Dutch,

Finnish, French, German, Greek, Indonesian,

Japanese, Korean, Thai, and Turkish. http://purl.org/dc/groups/languages.htmhttp://purl.org/dc/groups/languages.htm

Chinese (‘Big 5’) version of 都柏林核心集 at

http://dimes.lins.fju.edu.tw/dublin/

Chinese (simplified characters) version under

development.

Stabilising the Dublin Core

Dublin Core has evolved rapidly; with a wealth of implementations, all interpreting

the evolving Core slightly differently, and making

it improve each time

Australian Government Locator Service (AGLS)

http://www.naa.gov.au/govserv/agls/http://www.naa.gov.au/govserv/agls/

Arts & Humanities Data Service (AHDS)

http://ahds.ac.uk/public/metadata/discovery.htmlhttp://ahds.ac.uk/public/metadata/discovery.html

http://prospero.ahds.ac.uk:8080/ahds_live/http://prospero.ahds.ac.uk:8080/ahds_live/

and many more…

http://purl.org/dc/projects/index.htmhttp://purl.org/dc/projects/index.htm

Stabilising the Dublin Core

Dublin Core has evolved rapidly; from Thirteen initial elements

to Fifteen today

by adding Rights, splitting Subject & Description in two,

and renaming Author to Creator.

(Re–) Introducing the Dublin Core

TitleTitle CreatorCreator SubjectSubject DescriptionDescription PublisherPublisher ContributorContributor DateDate TypeType

FormatFormat IdentifierIdentifier SourceSource LanguageLanguage RelationRelation CoverageCoverage RightsRights

http://purl.org/dc/

Stabilising the Dublin Core

Attempts are now being made to draw

upon all this knowledge in a controlled

manner, and to guide the development of

Dublin Core a little bit more… .

Directorate

A ‘Directorate’ has been formed at OCLC,

consisting of Stu Weibel and Eric Miller.

They are responsible for driving the whole

process forward in consultation with the

Advisory Committees.

Advisory Committees

A Policy Advisory Committee has been

established, consisting of significant

individuals in communities aligned to the Dublin

Core. Their job is to represent the interests of

their communities and to guide the evolution of

DC.

John Perkins advocates cultural heritage

issues on this group.

Advisory Committees

A Technical Advisory Committee has been

established, consisting of the chairs of

various Dublin Core working groups, as well as

some other people.

Paul Miller advocates cultural heritage issues

on this group.

DC–GENERAL

The main discussion forum for Dublin Core is a mailing list

called dc–general.

http://www.mailbase.ac.uk/lists/dc–general/

In order to minimise discussion on this list, most of the work

associated with moving Dublin Core forward has been

devolved to a series of working groups. Some of these

groups deal with issues specific to one or more Dublin Core

elements, whilst others address more generic topics

All of these lists are open for anyone to join, and they are

the Dublin Core

All previous DC lists no longer used.

Element Working Groups

DC–AGENTS Deals with Creator, Contributor and Publisher

http://www.mailbase.ac.uk/lists/dc–agents/

DC–COVERAGE Deals with the Coverage element

http://www.mailbase.ac.uk/lists/dc–coverage/

DC–DATE Deals with the Date element

http://www.mailbase.ac.uk/lists/dc–date/

Element Working Groups

DC–FORMAT Deals with the Format element

http://www.mailbase.ac.uk/lists/dc–format/

DC–RELATION Deals with the Relation element

http://www.mailbase.ac.uk/lists/dc–relation/

DC–SUBDESC Deals with the Subject and Description elements

http://www.mailbase.ac.uk/lists/dc–subdesc/

Element Working Groups

DC–TITLE Deals with the Title element

http://www.mailbase.ac.uk/lists/dc–title/

DC–TYPE Deals with the Type element

http://www.mailbase.ac.uk/lists/dc–type/.

Issue Working Groups

DC–CITATION Deals with issues related to expressing

bibliographic citations in Dublin Core

http://www.mailbase.ac.uk/lists/dc–citation/

DC–DATAMODEL Deals with formalising the underlying data model for

Dublin Core. Currently concentrating on RDF.

http://www.mailbase.ac.uk/lists/dc–datamodel/

http://www.w3.org/TR/REC-rdf-syntax/.

Issue Working Groups

DC–GUIDES Deals with issues related to creating generic and

community–specific documentation for use of

Dublin Core

http://www.mailbase.ac.uk/lists/dc–guides/

DC–IMPLEMENTORS For discussion of issues arising whilst trying to

implement Dublin Core in real environments

http://www.mailbase.ac.uk/lists/dc–implementors/.

Issue Working Groups

DC–INTERNATIONAL Deals with issues related to expressing

Dublin Core in languages other than English

http://www.mailbase.ac.uk/lists/dc–international/

DC–ONE2ONE Deals with formalising the assumptions behind the

Dublin Core’s “1:1 model”

http://www.mailbase.ac.uk/lists/dc–one2one/.

Issue Working Groups

DC–SCHEMA Attempting to clarify the relation between Dublin

Core and similar models from groups such as

IFLA and INDECS

http://www.mailbase.ac.uk/lists/dc–schema/

DC–STANDARDS Deals with the standardisation process for Dublin

Core, concentrating specifically upon CEN, NISO

and ISO accreditation.

http://www.mailbase.ac.uk/lists/dc–standards/.

Formalisation

Dublin CoreWeb Sitepurl.org/dc/

Dublin CoreDirectorate

DC Policy Advisory Committee

DC Technical Advisory Committee

Working Groups

Stakeholder Communities

DC-General Dublin Core Mail Server

www.mailbase.ac.uk/lists/dc–general/

Based on a slide by Stu Weibel

Clarification and Stabilisation

Fifteen Dublin Core elements currently

defined by RFC 2413 ftp://ftp.isi.edu/in–notes/rfc2413.txt

Element working groups currently trying to clarify

these definitions will produce a new RFC (‘DC 1.1’)

concerned only with the 15 elements; not with any

qualification or subelement structure

will not substantially change the elements

will clarify definitions in order to make them say what we

always meant them to say.

Qualification and Substructure — Syntax

There have been many attempts to develop

a syntax for expressing substructure within Dublin

Core. For example; <META NAME=“DC.Creator” CONTENT=

“(TYPE=personal) (SCHEME=LCNAF) Kipling, Rudyard”>

<META NAME=“DC.Creator.personal”

CONTENT=“(SCHEME=LCNAF) Kipling, Rudyard”>

<META NAME=“DC.Creator”

TYPE=“personal”

SCHEME=“LCNAF”

CONTENT=“Kipling, Rudyard”>

Qualification and Substructure — Syntax

All are being used somewhere, but the

Dublin Core community as a whole is yet to

wholeheartedly endorse one approach.

The Data Model group is working with the

Resource Description Framework (RDF) in

order to both clarify the underlying model for

DC and to offer an XML–based means of

expressing the elements, their values, and any

desired substructure.

Qualification and Substructure — Syntax

R“CIMI Presentation”

Title

Creatordc:

dc:

“Paul Miller”

<RDF xmlns = “http://www.w3.org/TR/WD-rdf-syntax#” xmlns:dc = “http://purl.org/dc/elements/1.0/”> <Description about = “R”> <dc:Title> CIMI Presentation </dc:Title> <dc:Creator> Paul Miller </dc:Creator> </Description></RDF>

Qualification and Substructure — Syntax

RDF specification http://www.w3.org/TR/REC-rdf-syntax/

XML specification (RDF is usually

expressed in XML) http://www.w3.org/TR/REC-xml/

Draft RDF Schema specification (will make it easier

to express DC substructure) http://www.w3.org/TR/REC-rdf-syntax/

Dublin Core data model specification expected in

April.

Element Qualifiers and Value Qualifiers

rdf:Valuedc:Element

R

dcq:Type(element qualifier)

dcq:Scheme(value qualifier)

(previously known as TYPEs, SUBELEMENTs, and SCHEMEs)

Element Qualifiers and Value Qualifiers

“Created”

dcq:DateType

“1999–03–26”

rdf:Valuedc:Date

Resource

“ISO 8601”

dcq:Scheme

Qualification and Substructure — Values

Dublin Core community advocates use of

existing term lists where possible, rather

than the invention of new ones so use AAT if it has the terms you need, rather than

inventing a new thesaurus of museum terms

http://www.gii.getty.edu/aat_browser/

Continuing pressure to create ‘approved’ lists

of element and value qualifiers, but it is proving

difficult to make these sufficiently generic.

DC and CIMI

Paul MillerUK Office for Library & Information Networking

p.miller@ukoln.ac.uk

Thomas HofmannAustralian Museums On-Line

thomash@amol.org.au

CIMI

John Perkins jperkins@cimi.org

Dublin Core and the museum community

Challenges for museums Emphasis on attributes of the physical object (artefact) Need to associate the physical object with persons, places

and events Need to account for collections Need to account for surrogates such as photographs Historical lack of content standards

Assumptions regarding DC DC is useful to describe artefacts and associated

information resources in the museum community DC is simple to use and learn Adequate technical infrastructure exists to support use of

resource discovery

Testbed Phase I

Goals Evaluate feasibility of DC for museum

community Identifying and resolving operational,

technical and intellectual issues Promote international consensus on DC

practices in museum community

Introducing the CIMI testbed project (I)

Milestones Involvement of over 18 participants

(Software vendors, Museums, Consultants, Cultural Heritage Gateways)

Over 300,000 record repository (museums, collections, artefacts) using DC Simple, both created from scratch and exported from legacy systems

Guide to Best Practice: Dublin Core

Introducing the CIMI testbed project (I)

Outcomes DC is easy to use DC simple is a machete, not a

scalpel All Elements depend on Resource

Type DC can be applied to both physical

and electronic resources Further user evaluation necessary

Introducing the CIMI testbed project (I)

Testbed Phase II

Goals Finalisation and publication of “Guide to

Best Practice: Dublin Core” Identification of proposed qualified

elements (sub–structure) Examination of RDF Initial effort in mapping DC elements to

CIMI Access Points New set of sample records (at ADLIB) User evaluation

Introducing the CIMI testbed project (II)

Milestones

There are four meetings scheduled for 1999. Please see http://www.cimi.org/ for updates on the testbed phase II

Introducing the CIMI testbed project (II)

Outcomes The schedule for 1999 for sees the following

deadlines:Guide publication (April)DC recommendation (December)DC to CIMI Access Points

mapping (November)RDF examination (July)Choreographed demonstration/

user evaluation (October)Final report and

recommendations (December) For updates please see http://www.cimi.org/

Introducing the CIMI testbed project (II)

About the Guide to Best Practice: Dublin Core

Basis for the Guide: Based on Dublin Core 1.0 (RFC 2413) Recommendations based on testbed experience, not large scale

production efforts Syntax used in examples and testbed based on XML

Document structure: 15 DC simple elements starting with TYPE to assist in following

the 1:1 rule (original vs. surrogate) Each element:

- Introduced with standard DC Definition (RFC 2413)

- Explained with CIMI Interpretation- Manifested with CIMI Guideline- Illustrated through Examples

Appendices contain sample records for different types of museum describing a variety of resource types

Beyond Dublin Core

Paul MillerUK Office for Library & Information Networking

p.miller@ukoln.ac.uk

Thomas HofmannAustralian Museums On-Line

thomash@amol.org.au

CIMI

John Perkins jperkins@cimi.org

The Dublin Core in context Dublin Core was originally developed as

a tool for the discovery of electronic

resources although now extended to physical objects,

it is still about resource discovery

Other initiatives fulfil similar niche roles, such as rights

management metadata, administrative metadata, etc.

Some initiatives are far more complex, and encompass

many of these roles within a single implementation.

How do we integrate and interoperate?

Extending the Dublin Core

The fifteen basic elements of the

Dublin Core are extensible,

optional, and repeatable. Many implementors have extended these elements through

the addition of substructure (AMICO…)

Others have added whole new elements to the core in order to

meet their needs

The ‘Admin Core’, for example, is aimed specifically at the

metadata kept in order to manage data

http://metadata.net/admin/

where do we stop extending and use something else instead?

Other ‘niche metadata’ markets

Resource Discovery is one ‘niche’

market

Others include rights (INDECS…)

description of educational content (IMS, GEM…)

ratings (PICS…)

How do these relate to Dublin Core?

Detailed museum approaches

There are several cultural heritage developments

which attempt to encompass far more than

resource discovery

How can they be interconnected,

whether semantically or technically?

SPECTRUM

The Dublin Core ‘filter’

A User A Resource

spatially discrete?

Dublin Core‘filter’

DC.title

DC.creator

DC.subject

DC...

mapping/ crosswalk

The Dublin Core ‘filter’

Working together, we can map from detailed descriptions and methods ‘up’ to the Dublin Core.

Creator

Subject

Coverage...

Artist’s NameType of Work

Period depictedPlace depicted

...

SurnameForename

Title...

The Dublin Core Filter

Assuming that a satisfactory mapping can be

defined, the Dublin Core therefore becomes a

common language of access to more detailed

resources, without the need for institutions to

change their systems.

The Warwick Framework and RDF

The Warwick Framework concept from the second Dublin

Core workshop is realised in RDF

Under this model, it becomes possible to bolt ‘packages’

of metadata together in a near–seamless fashion.

Description Archival Management

Terms & Conditions

Based on a slide by Stu Weibel

http://www.cimi.org/

© CIMI 1999