Collection Level Description

Issues list

Issue #1: Conspectus
The current list of attributes doesn't explicitly have a space for conspectus type information.

There are four options:

  1. live without this kind of information
  2. add a free text Conspectus attribute
  3. try to formally model conspectus information using several attributes
  4. put conspectus information into a Subject attribute using a SCHEME qualifier to indicate that the description has been constructed using the conspectus methodology.

Proposal None.

There is currently no agreement on how best to handle conspectus. CAIRNS have a requirement to use conspectus. They:

The working group hope to consider how best to meet these requirements in the near future.

Issue #2: Admin, Owner, Publisher
The current set of attributes list Admin, Owner and Publisher. Are these sufficiently different? Can we remove one or more of these attributes?

All three are required.

Issue #3: DC qualifiers
Recent work on the DC data model indicates that there are two kinds of qualifiers, currently refered to as Type A and Type B qualifiers (previously these tended to be known as TYPE and SCHEME). Type A qualifiers modify (typically refine) the semantics of the element. Type B qualifiers say something about the value (typically that the value is drawn from some enumerated list or external scheme).

Is this notion of qualification useful for the collection attribute set?

It is.

Issue #4: Admin, Owner and Publisher values
Admin, Owner and Publisher define organizations and/or people. What structured or unstructure values these attributes might take?


  1. keep it simple and leave the value as plain text string (for now)
  2. follow DC lead and propose values based on vCard.

Keep it simple for now and leave value as plain text string.

Issue #5: Relation
What are the relationships between collections and between collections and items in those collections?

Dublin Core currently defines the following relationship types:


Use the DC list of relations above (noting that IsPartOf and HasPart look to be most useful in the context of collection description) and add:


Issue #6: Enumerated list for Type
An enumerated list of collection types (for the Type attribute) is required. Dan's proposed list:
SBIG - subject-based internet catalogue with a quality policy
SBIG-WebIndex - large web index based on contents of an SBIG or
managed list of resources to index.
WebIndex - big, undescriminating big search engine
WebCatalogue - Yahoo and friends?
MultimediaDatabase - eg. images etc. could be more fine grained
WebsiteIndex - index of a single web service's HTML content
OPAC - books and stuff ;-)
Software - software catalogue
DocumentCollection - eg. working papers
the list of Dublin Core types and the what is a collection section of the eLib supporting study could form a useful starting point.

This list of collections types is proposed.

Note: the current definitions for some of these are unsatisfactory and need improvement.

Issue #7: Enumerated list for Protocol
An enumerated list for Protocol is required. Given a particular protocol, several other attributes may be required, for example Whois++ requires a Host and a Port, Z39.50 requires a Host, a Port and a Database.
Could use protocol specific URLs instead? See issue #11.

The following list is proposed:


Issue #8: Rights vs. Use-Constraints
Is there any useful distinction between Rights and Use-Constraints?

Yes, both are required.

Issue #9: Access and Terms and conditions groupings
It is assumed that any implementation based on this set of attributes will allow the 'access' attributes to be grouped and repeated to associate multiple access protocols with the same collection.

So, in ROADS terms we might create an ACCESS cluster.

Are terms and conditions associated with the collection or with a particular way of accessing that collection?

Issue #10: What does Date mean?
Date is currently very vague (as per the Dublin Core). We probably need to associate one or more particular dates with a collection? Dublin Core has developed the following list of date TYPEs:
Are these useful in the context of (discovery of) collections?

Issue #11: URIs vs. explicit host, port, database attributes
Currently we have attributes for which are typically used to give access information for Z39.50 and Whois++ based services. An alternative to this approach would be to simply provide URIs. Standard (or proposed standard) URIs exist for Here's some examples (note, some of these aren't supported by your common or garden browser!):

Given this, do we need attributes for Host, Port, Database?

Issue #12: Long names and short labels
We probably need to think about long names and short (one word?) labels for our collection attributes, much as DC has. For example, DC has 'Subject and Keywords' with the label 'Subject' (which is embedded in HTML META tags using 'DC.Subject').

Issue #13: Web pages about physical collections
Some physical collections may have a Web page or set of Web pages that are 'about' the collection but that do not constitute a digital surrogate for the collection.

Is Identifier a sensible place to put such a URL?

Where else could it go? Notes?


Issue #14: What does coverage mean?
What does temporal coverage mean in the context of collections?

Issue #15: Agent vs. Owner, Admin, Publisher
Dublin Core currently has separate Creator, Contributor and Publisher elements. However, recent work on the DC data model may lead to the collapse of these into a single Agent element - using a TYPE qualifier to indicate different kinds of Agents. It may be sensible for the proposed collection description attribute set to use a single Agent attribute in place of the current Admin, Owner and Publisher attributes.

Maintained by: Andy Powell
$Id: issues.html,v 1.7 1998/10/12 22:07:31 lisap Exp $

[Collection Level Description] [Metadata] [UKOLN]