-
Issue #1: Conspectus
-
The current
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
conspectus methodology.
Proposal
None.
There is currently no agreement on how best to handle conspectus.
CAIRNS have a requirement to use conspectus. They:
-
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
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?
Proposal
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?
Proposal
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?
Options:
- keep it simple and leave the value as plain text string (for now)
- follow DC lead and propose values based on
vCard.
Proposal
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:
IsPartOf
HasPart
IsVersionOf
HasVersion
IsFormatOf
HasFormat
References
IsReferencedBy
IsBasedOn
IsBasisFor
See http://purl.oclc.org/metadata/dublin_core/wrelationdraft.html
Proposal
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:
IsCataloguedBy
IsCatalogueFor
-
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
similar
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
here
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.
Proposal
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.
Proposal
The following list is proposed:
Z39.50
Whois++
LDAP
HTTP
Telnet
-
Issue #8: Rights vs. Use-Constraints
-
Is there any useful distinction between Rights and Use-Constraints?
Proposal
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:
Created
DataGathered
Valid
Issued
Available
Accepted
Acquired
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!):
z39.50s://edward.ilrt.bris.ac.uk:2102/sosig
telnet://bids.ac.uk/
http://www.sosig.ac.uk/
ldap://ldap.bath.ac.uk/
whois++://sosig.ac.uk:8237/
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?
Proposal
-
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
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.
