Dublin Core Collection Description Working Group Pete Johnston, Andy Powell UKOLN, University of Bath co-chairs, DC CD WG DC-2003, Seattle, Washington, USA 28 September – 2 October, 2003

Agenda Background Review Proposed DC CD AP Identify/Plan Work Items required to prepare AP for Usage Board review Identify/Plan Supporting Work Items Revision of Charter/Milestones AOB

Background

Collections Collection –“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

Collections and collection description "Functional granularity" (Heaney) –Pragmatic choice –Based on what is "useful or necessary for the purposes of resource discovery or collection management" Collection-level description –"unitary finding aid" (Heaney) –information about the collection as a whole, rather than the individual items

Why collection-level description? –Enable user to discover/locate collections select collections to explore/search on basis of summary description e.g. –content/coverage, access conditions, resource type compare collections as broadly similar objects (even where items heterogeneous) understand conditions of access & use interpret collections –provenance, context, relationships –Enable software agents to discover/locate/select collections to search on behalf of user control searches across collections

RSLP CD Schema Research Support Libraries Programme, –Support for academic research –Improve discovery of/access to collections –Improve collaborative management of collections –Primarily physical library/archive collections –Recognition of CLD as important mechanism for disclosure/discovery

RSLP CD Schema RSLP CD Project –means of consistent collection description in RSLP –Entity-Relationship model by Michael Heaney (Oxford) –Schema developed by Andy Powell (UKOLN) –simple, high-level schema, based on DC Model or Schema implemented by several UK initiatives Significant influence on other CLD schemas

RSLP CD Schema ContentCreator creates Collector Owner collects owns Administrator administers ItemProducer produces is-embodied-in Collection is-gathered-into Location is-located-in

DC Collection Description Application Profile Collection description attributes (only) of RSLP CD Schema as starting point for discussion –N.B. exclude Location, Agent description, for now… Informed by experience of RSLP, CD Focus (UKOLN), TEL, JISC IESR, IMLS, others Current draft,

Review DC Collection Description Application Profile

Current issues Summary to dc-collections, Collection – Location/Service relation 2.Rights 3.Subject and sub-properties 4.Format/Extent 5.Logo 6.Strength 7.Temporal Coverage 8.URI/namespace/vocabulary 9.Status/management of APs from DCMI WGs collections&T=0&F=&S=&P= collections&T=0&F=&S=&P=2038

1. Collection-Location/Service relation a)One property or separate for Physical Location/Digital Service? Proposal: Use one property b)Name(s) of property/properties? Proposal: hasLocation (and isLocationOf ) (URI tbc) c)Use of Encoding Schemes to indicate interfaces implemented by digital Service? Proposal: No, this is an attribute/property of the Service

2. Rights a)Legal Status required as separate property? Proposal: No, use dc:rights or dc:accessRights ? b)Need to distinguish a description of who holds IPR in the (items in the) collection; who has access rights; what rights are granted once the collection is accessed? –N.B. Need to align with any proposals on Rights/Agents from Agents WG

3. Subject and sub-properties a)Are the proposed Encoding Schemes for dc:subject (Concept) sufficient/appropriate? b)Sub-properties of dc:subject to indicate persons/organisations and objects as subjects of a Collection? Proposal: Yes, existing CLD implementations use such properties. Also, tighten up the definitions so that they are clearly "subject" sub-properties. c)If yes, what names for this these properties (???)

4. Format/Extent a)How to record the size of a collection? Proposal: Introduce separate property Size ( dcterms:extent ) to record number of items in collection, and revise description of Physical Characteristics ( dc:format ) to exclude size b)Need to capture the media-type of the items in the Collection (e.g. to indicate that a Digital Collection is a collection of MP3s, JPEGs etc)? Proposal: Yes, use dc:format with scheme dcterms:IMT (??)

5. Logo a)Need property to record (the URI of) a Logo associated with the Collection? Proposal: Yes (?) b)If yes, what name for this property? Proposal: logo (URI tbc)

6. Strength a)Permit free-text values for Strength or mandate the use of specified Encoding Schemes?

7. Temporal Coverage a)Ensure that recommended encoding scheme can cover BC dates Proposal: If dcterms:W3CDTF not sufficient, propose encoding scheme based on ISO8601 (N.B. This appears to be an issue for DC Libraries AP too, so should co- ordinate solution)

8. URI/namespace/vocabulary issues a)Identify terms in DC CD AP that are sufficiently generic to be candidates for inclusion in dcterms vocabulary/namespace –What changes need to be made to descriptions/definitions? b)What URIs to assign to terms in DC CD AP that are either collection-specific or not considered appropriate for dcterms vocabulary/namespace? –May wish to indicate collection-specific nature of attributes in names (e.g. collectionStrength rather than strength )?

9. Status/management of APs created by DCMI WGs DCMI UB reviews DC APs (from any source) Can accord AP status of "conforming" (to Grammatical Principles (Abstract Model?), good practice) DCMI WGs chartered only for specific tasks Who manages DC CD AP after work of DCMI CD WG complete? What is longer-term status of DC CD AP (and APs other DCMI WGs)?

Identify/Plan Work Items to Prepare DC CD AP for Usage Board Review

Usage Board Next meeting, Spring 2004? Impact of Abstract Model? Proposals of terms for dcterms vocabulary Application Profile specification for review –CEN MMI DC guidelines

Identify/Plan Supporting Work Items

Supporting Items Implementation Guidelines RDFS/RDFVDL descriptions of collection- specific terms XML Schema for XML encoding of collection-specific terms Crosswalks/mappings –EAD to DC CD AP –ISAD(G) to DC CD AP –RSLP CD to DC CD AP –XSLT transforms where possible?

Revision of Charter/Milestones

Any Other Business?

Acknowledgements UKOLN is funded by Resource: the Council for Museums, Archives and Libraries, 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.

Dublin Core Collection Description Working Group Pete Johnston, Andy Powell UKOLN, University of Bath co-chairs, DC CD WG DC-2003, Seattle, Washington, USA 28 September – 2 October, 2003