Collection Level Description
Issue #1: Conspectus
list of attributes doesn't explicitly have a space for
conspectus type information.
There are four options:
- live without this kind of information
- add a free text Conspectus attribute
- try to formally model conspectus information using several attributes
- put conspectus information into a Subject attribute using a SCHEME
qualifier to indicate that the description has been constructed using the
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.
feel that the hierarchy of Conspectus needs to be extractable
from the data in a reliable way
feel that the collection level indicator should be stored somewhere
feel that CAIRNS will want structured attributes
for Conspectus as such and a 'summary subject
description' in the Subject attribute
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?
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?
- keep it simple and leave the value as plain text string (for now)
- follow DC lead and propose values based on
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
the list of
Dublin Core types
what is a collection section of the
eLib supporting study could form a useful starting point.
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
list of collections types is proposed.
Note: the current definitions for some of these are unsatisfactory and need
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++
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
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?
Abstracting and indexing services may use coverage to indicate the date of
publication of items in collection.
For example, the 1997 ISI collection.
A library might use it to
indicate date of accession of items in collection.
For example, the pre-1920 collection.
Other collections may
use it to indicate the temporal coverage of items in the collection.
For example, a collection of items about World War I (1914-1918).
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
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]