Collection Description

Collection Description Meeting

Board Room, British Library
2 September 1998

In attendance:
Mo Bains (Music Libraries Online)
Verity Brack (RIDING)
Dan Brickley (ROADS)
Ric Collins (COPAC)
David Cooper/Jessie Hey (MALIBU)
Lorcan Dempsey (UKOLN)
Matthew Dovey (MALIBU & Music Libraries Online)
Helena Gillis (CAIRNS)
Agnes Guyon (EEVL)
Katharine Hogg (Music Libraries Online)
David Kay (Fretwell-Downing)
Darryl Kirk (M25 Link)
Thomas Krichel (BibEc/WoPEc)
Maria Kulas (RIDING)
Dennis Nicholson (CAIRNS)
Stephen Pinfield (BUILDER)
Andy Powell (UKOLN)
Neil Prockter (M25 Link)
Sandy Buchanan (SCRAN)
Jill Russell (University of Birmingham)
Rosemary Russell (UKOLN)
Mike Stapleton (System Simulation)
Richard Wellings (BLCMP)
Peter Wynne (HyLife)

Lorcan Dempsey (LoD), chairs. He would like to find out what are the areas that need concerted attention.

Thomas Krichel (ToK) appointed minutes keeper.
Daniel Brickey (DaB) to act as editor/spellchecker.

Andy Powell (AnP) introduces collection description study that UKOLN are doing for eLib. The study starts by examining what a 'collection' is from the point of view of libraries, museums, the archive community and on the Web. The study then looks at formats and technologies used. Final draft of study to be available early October.

AnP introduces 4 issues:

  1. Granularity. A collection is a grouping of resources. Collections may be grouped together into more collections. E.g. a library is typically a collection of collections of books and/or serials, each serial is a collection of issues, each issue a collection of articles etc.
  2. Data vs. metadata. (Though the name 'data vs. metadata' is one that UKOLN don't like because people get confused about it). Collections may be groupings of first class (often physical) items or may be groupings of descriptions of first class items. Any collection description mechanism will have to differentiate between these two.
  3. What kind of attributes are needed. UKOLN propose an attribute grouping. It distiguishes collection attributes (title description, subject), access attributes (way to access the collection for example web telnet), and terms and conditions.
  4. Terminlogy. Useful to agree on some terminology. UKOLN propose:
    Item, object, resource, 'stuff', unit of use(?) (difficult).
    Collection is a grouping of items. May be nested.
    Application is an access protocol for the collection.
    Service provider is the organisation that provides access to the collection.
AnP also wonders if it is useful to distinguish search, browse and navigate, where browse implies browsing within a collection while navigate implies browsing up and down a heirarchy of collections.

David Kay (DaK): notes that level data is very difficult to measure. All you can do you can do with level is moving up and down within, but you can not move levels within distinguished collections. A level concept is not what could bring the world together.

Steven Pinfield (StP): If this is not possible what is the point of collection level description.

DaK: well it will have to be keywords, rather then level data.

Mike Stapleton (MiS): If users wish to seach such a collecion, that will be in the domain of object database. The response is to provide tagging. The structure is only used to navigate.

Mathew Dovey (MaD): should Web pages be catalogued? Say a page is a link to a subject gateway. Then the page is an item and a collection at the same time.

LoD: this is an academic issue.

Dennis Nicholson (DeN): we do need our terminology more closely defined.

LoD: wishes to know if "collection description" is an appropriate label. In some instances it is appropriate, in some it is not.

MaD: the world consists of resources, some time you use as an item and some time you use it as a collection.

LoD: this is where we started from. Let us look around the table at what sort of collections we are dealing with.

DeN: views collection as a physical collection of elements in a library. The clumps projects do that. That would be a library resource to the person that visits the place.

LoD: in many cases you will have collections that are not catalogued. There is a distiction between the items in the catalogue and the items that are actually in the library.

AnP: we do have a requirement to describe the logical and physical description.

DaK: the collection description would be a wonderful opppotunity to raise awareness of uncatalogued items.

ToK: describes a hierachical structure of archive series and papers.

MaD: then a collection is in the eye of the beholder. Levels are also in the eye of the beholder.

Peter Wynne (PeW) : wonders if the absence of physical collection can be put back retrospectively. If he says that library materials are a collection does that have any meaning more than just a collection of access.

LoD: resoures may be collections or items. Collection can collection of items or collection of description of items.

Neil Protor (NeiP): need to distinguish logical from physical collection.

A splinter group, lead by DeN, suggests to add relationship to the attribute group on slide 4.

MaD: on a conceptual level that would be useful, but if the list on slide 4 is application oriented, then it would not fit.

Richard Wellings (ReW): if we have relationships, we need a relationship types.

DaK: if we have links we have type of links

Ric Collins (RiC): trouble with the access condition. Keeping that at a collections level is difficult.

MaD: access conditions may be applicable only at different levels.

ReW: all these things depend on who you are.

LoD: yes these concepts are situational.

DaK: that is why we strongly need human understandable user level collecitions.

NeiP: regarding access, in a physical collection the cost of access would be the cost of the resource.

MaD: not necessarily. Think of the lending of a CD, where you have to pay one pound to borrow the CD.

Conclusion: the meeting breaks out for lunch. We agree it is useful to relate collections. There are particlar elements to be included in the blocks on page 4 of AnP's presentation.

AnP: gives a list of existing collection description formats and technologies:
Conspectus: a subject scheme. developed by ARL in the late seventies. For the kind of descriptions that it does it is the best thing to do. Useful for collabarative cataloguing.

ISO 2146: to provide directories of libaries and archives. Not much used at all.

Z39.50 profile for access to collections: developed in 1995.

ISAD(G) is the General International Standard for Archive Description. Serves same function as AACR2. It has a strong view of multilevel data.

EAD SGML DTD to describe archive. Is a manifestation of ISAD(G)

Z39.50 Explain: is a Z39.50 protocol to describe collections

GILS: Government Information Locator Service, a Z35.50 profile to initially describe government information but now used for all sorts of things

ROADS service template: often used to describe whole collections (Web sites, etc.) though not their machine-searchable interfaces, as Web services tend not to have these.

centroid: a low-level description of a database - list of all known values for all known attributes of all searchable record types in some database. Centroids were developed as part of the WHOIS++ protocol but are, as the Common Indexing Protocol (CIP), now becoming less tied to a specific search protocol.

Dublin Core: started out on the description of items only but increasingly usaed to describe whole variety of things.

Web Collections: arbitrary grouping of web pages. ('Web Collections' names a now obsolete Microsoft sponsored web metadata vocabulary.)

AnP: lists a list of possible mechanisms for application description:

LDAP: one could do application descriptions here.

WASRV: is a proposed IETF working group to work on description for server location - not clear what status of this group is?

ROADS service template: can be used to describe services,

Z39.50 Explain: is a Z39.50 protocol that case be used to describe databases, profiles, etc. supported by particular Z39.50 server.

Discussion followed...

DeN: Z35.50 explain can not do collection description well based on CAIRNS experience.

DaK: not many people will use Z39.50 Explain

PeW: we will use it.

[DaK leaves the meeting! (unconnected with this exchange)]

LoD: suggests that since there is a pressing requirement, we need an agreed standard. We need a working group to make decisions that can be built upon.

ToK: suggests ROADS service template

LoD: a new proposal could be drafted quickly when a working group is established.

Meeting concludes with arrangements for taking things forward: a small working group is set up...

AnP, DeN, MaD, Verity Brack, DaB volunteer. DaK is co-opted in his absense. Aim is to get a draft specification circulated within four weeks, initially in the lis-elib-tech Mailbase forum.

Page content by: Thomas Krichel (Dan Brickley, Andy Powell)
Last updated: 19-Sep-1998