Dublin Core Collection Description Working Group Pete Johnston, UKOLN, University of Bath Chair, DC Collection Description Working Group DC CD WG Meeting, DC-2004, Shanghai, China, Monday 11 October

Dublin Core Collection Description Working Group 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, ) –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

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 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

Activity 2003/2004 Jan-Mar 2004 Developed proposals for DCMI properties provenance – accepted: dcterms:provenance isAvailableAt – rejected. highlighted service/location model issues Feb 2004Presentation to CD Schema Forum, London, UK Mar 2004Data model issues Apr 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 Work on Usage Guidelines started ThroughoutTracked DC Arch WG on DCMI Abstract Model, DCAPs DeferredSyntax guidelines, crosswalks

Item Collection is-gathered-into m n Location is-located-in m n Service is-accessed-by m 1 m provides n administers n m Agent collects m n owns m n Collection Description is-described-by 1 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

1. Collection – Location, Collection – Service Relationships Is Service a subtype of Location? Is relation between Collection and Location same as relation between Collection and Service? Collection – Location (RSLP CD model/schema) Electronic Repository is-located-in Network Service Collection Location is-located-in Collection Physical Repository is-located-in Collection

1. Collection – Location, Collection – Service Relationships Collection Location is-located-in Collection Physical Repository is-located-in Collection Electronic Repository is-located-in Service is-Made- Available-By Physical Service is-Made- Available-By Network Service is-Made- Available-By

1. Collection – Location, Collection – Service Relationships 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!)

1. Collection – Location, Collection – Service Relationships 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"?

1. Collection – Location, Collection – Service Relationships 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 " " [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 (three-letter codes only) Concerns about –Potential confusion –Compatibility with MARC & library systems Recent change to mandate use of ISO (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 ItemStartEnd 1Review Collection Type Vocabulary Collection attributes/relationships Examples Terms/URIrefs DCAP Syntax Crosswalks Usage Guidelines Usage Board Review

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.

Dublin Core Collection Description Working Group Pete Johnston, UKOLN, University of Bath Chair, DC Collection Description Working Group DC CD WG Meeting, DC-2004, Shanghai, China, Monday 11 October