250 likes | 437 Views
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 2004. http://www.ukoln.ac.uk/. Dublin Core Collection Description Working Group.
E N D
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/
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, 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 concernsover 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/
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/
m is-gathered-into n m 1 is-described-by n Collection CollectionDescription n m 1 collects owns is-located-in is-accessed-by m n Service Location m m n n m provides administers Agent m Item
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/
is-located-in Location is-located-in Physical Repository is-located-in Electronic Repository 1. Collection – Location, Collection – Service Relationships Collection – Location (RSLP CD model/schema) Collection Collection Collection Network Service Is Service a subtype of Location? Is relation between Collection and Locationsame as relation between Collection and Service?
is-Made-Available-By Collection Service is-located-in Location is-Made-Available-By Collection Physical Service is-located-in Physical Repository is-Made-Available-By Collection Network Service is-located-in Electronic Repository 1. Collection – Location, Collection – Service Relationships
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 "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?
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/
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/