Dublin Core Collection Description Working Group

Dublin Core Collection Description Working Group

Pete Johnston, UKOLN, University of BathChair, DC Collection Description Working Group

DC CD WG Meeting, DC-2004,

Shanghai, China, Monday 11 October 2004

http://www.ukoln.ac.uk/



• Background– Summary of 2003/2004 activity

• Review of DC CD AP– Current issues

• Proposed work plan for 2004/2005• AOB


Background: Collections

• “An aggregation of one or more items”– aggregation by

• e.g. location, type/form of item, provenance of item, source/ownership of item, nature of item content, etc!

– varying size, degrees of permanence– varying types of items

• natural objects, created objects, digital resources, digital surrogates of physical objects, metadata records

– items may not be physically juxtaposed• "Functional granularity"

– Pragmatic choice– Based on what is "useful or necessary for the purposes

of resource discovery or collection management“ (Heaney)


Background: Collection-level description

• Collection-level description– information about the collection as whole, rather than the

items• Growing interest in use of CLD to support resource

discovery• Functional model in which searcher

– "Enters" information landscape• A set of collections

– "Surveys" landscape• Modifies landscape by adding/removing collections

– "Discovers" items of interest within collections• "Drills down" into selected collections


Background: from RSLP CD to DC CD AP

• Research Support Libraries Programme (UK, 1999-2002)– support for academic research– improve disclosure/discovery of library/archive

collections– also collaborative collection management

• RSLP CD Model & Schema– Entity-Relation model (Michael Heaney, University of

Oxford)– DC-based metadata schema (Andy Powell, UKOLN)– Significant influence on other initiatives

• But concerns over status, ownership, visibility, persistence, maintenance, etc

DC Collection Description Working Group

• Active 2001 (really 2003!) -• Provide forum for sharing information about

CLD activity• Develop a DC AP for collection-level

description• Develop supporting materials for use of AP

• Informed by experience of RSLP CD implementers and other CLD initiatives

http://dublincore.org/groups/collections/http://dublincore.org/groups/collections/


Functional Requirements for DC CD AP

• A "core" set of collection description properties– For simple collection-level descriptions – Suitable for a broad range of collections

• Allow a user to– Discover of collections of potential interest– Identify a collection– Select one or more collections from amongst a number

of discovered collections– Identify the location of the collection– Identify the services that provide access to the collection

DC Collection Description Application Profile (DC CD AP)

• Collection attributes (only) of RSLP CD Schema as starting point– excludes Location, Agent description– introduces Service as entity-type, but does not cover Service

description

• Draft 2004-08-20 covers– Identification of collection– Content of items in collection– Form of items in collection– Process by which items gathered into collection– Ownership of collection– Rights of access to/use of collection– Location of collection– Services that provide access to collection– Relationships between collections

http://www.ukoln.ac.uk/metadata/dcmi/collection-ap-summary/http://www.ukoln.ac.uk/metadata/dcmi/collection-ap-summary/

Activity 2003/2004

Jan-Mar 2004

Developed proposals for DCMI propertiesprovenance – accepted: dcterms:provenance

isAvailableAt – rejected.highlighted service/location model issues

Feb 2004 Presentation to CD Schema Forum, London, UK

Mar 2004 Data model issues

Apr 2004 - Interest from NISO Metasearch Initiative; presentation to NISO MI meeting, North Carolina, USA

Jun-Aug 2004

Amended use of language, identifier, logo

Revised approach to describing "accruals"; developed proposals for DCMI properties & classes

Jun 2004 - Work on Usage Guidelines started

Throughout Tracked DC Arch WG on DCMI Abstract Model, DCAPs

Deferred Syntax guidelines, crosswalks

Item

Collection

is-gathered-into

m

n

Location

is-located-in

m

n

Service

is-accessed-by

m

1

mprovides

n

administers

n

mAgent

collects

m

n

owns

m

n

CollectionDescription

is-described-by1 m


1. Collection – Location, Collection – Service Relationships

• Item– A physical or digital entity

• Collection– An aggregation of one or more items

• Location– A place where a collection is held

– Michael Heaney, Analytical Model

• Service– The provision of, or system of supplying, one or more functions of

interest to an end-user or software application.– Physical or digital– Digital services may be structured or unstructured

• Informational services– Provide access to, or metadata about, items and/or collections

– JISC Information Environment Architecture: Glossary

http://www.ukoln.ac.uk/metadata/dcmi/collection-model/http://www.ukoln.ac.uk/metadata/dcmi/collection-model/

http://www.ukoln.ac.uk/metadata/dcmi/collection-model/

http://www.ukoln.ac.uk/metadata/dcmi/collection-model/


Is Service a subtype of Location?

Is relation between Collection and Locationsame as relation between Collection and Service?

Collection – Location (RSLP CD model/schema)

Electronic Repositoryis-located-in

Network Service

Collection Locationis-located-in

Collection Physical Repositoryis-located-in

Collection


Collection

Location

is-located-in

Collection

Physical Repository

is-located-in

Collection

Electronic Repository

is-located-in

Serviceis-Made-Available-By

Physical Serviceis-Made-Available-By

Network Serviceis-Made-Available-By



• Do we need to distinguish between – the Location of the Collection and – the Service that provides access to the Collection– And describe both

• the relationship between Collection and Location?• the relationship between Collection and Service?

• Or do we need to consider only the provision of access?

– And describe only • the relationship between Collection and Service?

• (Or some other option!)



• If option 1– a) Is there also a relation between Location and Service?

• e.g. Is a Service accessed-at a Location?

– b) Is it possible to distinguish a digital Location from a digital Service?

• Or do we describe only digital Services (and not digital Locations)?

– c) Can the Resource-Location-Service model be generalised to other classes of resource?

• physical item: OK; digital item?– d) What is the nature of the two relationships?

– e) How should the two relationship types be represented in DC metadata?

• What are the implications for "dumb-down"?



• If option 2– a) Can the Resource-Service model be generalised to

other classes of resource? • physical item, digital item?

– b) What is the nature of the relationship? – c) How should the relationship type be represented in DC

metadata? • What are the implications for "dumb-down"?


2. "One–to–One" Rule

• A DC metadata description should describe exactly one resource

• a) how to represent media-type of items in collection?– my:collection dc:format "img/jpeg"

[dcterms:IMT] ?– No, the media-type applies to the item(s)

• b) how to represent dates of creation of items in collection– my:collection dcterms:created "2004-01-01"

[dcterms:W3CDTF] ?– No, the creation of the collection is not the creation of the items;

we've used dcterms:created for the dates of accumulation


3. Date/date range issues

• DC CD AP currently recommends use of ISO8601 for dates – (dcterms:ISO8601 (in process))

• Clarification required on whether – DCMI date encoding scheme(s) support date ranges; or– Need to define new scheme which explicitly supports date

ranges

• Also – Open-ended date ranges– Approximate dates– BCE dates

• Need advice from DC Date WG and/or DC Usage Board


4. Identifiers for Collections

• DC CD AP says– The presence of an identifier is "Optional, but

recommended"– If present, "A collection identifier must be a URI, and the

use of a URI scheme that has been registered with IANA is preferred".

• Proposal to develop collection identifier scheme (ISCI) under ISO TC 46 – based on ISIL


5. Encoding Scheme for dc:language

• Initially DC CD AP permitted either – RFC 3066 (two-letter codes preferred to three-letter

codes) or – ISO 639-2 (three-letter codes only)

• Concerns about– Potential confusion– Compatibility with MARC & library systems

• Recent change to mandate use of ISO 639-2 (three letter codes)

• Some subsequent disagreement


6. Logo / Thumbnail / Graphical Representation

• a) Do we need to describe a relationship between a Collection and an image (logo/thumbnail)?– What functional requirement does it address?

• b) What is the nature of that relationship?– Is the logo/thumbnail always "a graphical representation of the

content" (of the collection)?– Is a logo different from a thumbnail?

• c) What property should be used to represent the relationship?– dc:description?– a new sub-property of dc:description?– some other new/existing property?


7. Additional attributes required?

• Do we need to describe any additional – attributes of the collection?– relationships between the Collection and other

entities?

Work Plan for 2004/2005

Item Start End

1 Review Collection Type Vocabulary 2004-10 2004-11

2 Collection attributes/relationships 2004-10 2005-01

3 Examples 2004-10 2005-01

4 Terms/URIrefs 2005-01 2005-03

5 DCAP 2005-01 2005-04

6 Syntax 2005-03 2005-05

7 Crosswalks 2005-03 2005-05

8 Usage Guidelines 2004-10 2005-08

9 Usage Board Review 2005-10 2005-10


Acknowledgements

• UKOLN is funded by the UK Museums, Libraries and Archives Council (MLA), the Joint Information Systems Committee (JISC) of the UK higher and further education funding councils, as well as by project funding from the JISC and the European Union. UKOLN also receives support from the University of Bath where it is based.

• http://www.ukoln.ac.uk/


Pete Johnston, UKOLN, University of BathChair, DC Collection Description Working Group

DC CD WG Meeting, DC-2004,

Shanghai, China, Monday 11 October 2004


Documents

Dublin Core Collection Description Working Group