Dear all

This is in response to the "What is the question" thread (given that the answer
is 42). I've used a different subject because I agree with what Pete is saying
and I'm happy with the results of the poll.

However, the discussion has exposed a number of issues which I suspect would
resurface, so this is my attempt to keep them bobbing along:

The idea of Collection-as-concept is similar to the abstract scope or rationale
of the Collection, the collecting parameters which might take the form of a
statement: 

"Digital publications of the Centre for Digital Library Research"
"Music CDs available in the Resource Centre"

This information can only be accommodated in the Description property, am I right?.

But note that the collecting parameters might take the form of a
machine-readable encoding. When I carry out a Google search, I am collecting
items which match the search term, and the search term plus Google syntax can be
considered an instantiation of the abstract scope of this collection.

Heaney "takes the view that ownership, administration and location are relevant
to the definition of a collection" when considering collections created
dynamically and on-the-fly, and there is, I think, a general assumption that
collection-level description will not usually be applied to them.

However, Collection-Descriptions in the form of analytic finding-aids such as
catalogues are increasingly using pre-encoded searches to isolate records for
items belonging to specific Collections. For example, Strathclyde University
Library has an integrated catalogue of items in its organizational collection,
but provides URL-encoded searches to identify items from the catalogue which
belong to specific special collections.

Since the analytic finding-aid can be treated as a Collection (of metadata
records), the encoded URL is accommodated in the isLocatedAt property (of the
collection-level description of the Collection-Description).

So in some circumstances information about the collection parameters/scope may
be stored in either or both of Description and isLocatedAt.

The examples given above show that the physical characteristics of Items can be
a significant collecting parameter.

And there is a functional requirement to respond to user requests for Items with
a specific physical characteristic (often combined with other parameters such as
subject, creator, etc.).

I would argue that users aren’t usually interested in the Collection per se, but
the Items it contains. A collection-level description is not the end of a
typical user search; rather, it helps the user identify good places to go look
for items meeting their requirements.

Hence the need for the structured identification of the physical characteristics
of Items in the Collection.

Other Collection properties derived from Item properties, such as language, are
allowed for by Heaney:

5.1.3 "Some attributes of a Collection arise from the aggregation of the
attributes of its constituent Contents and Documents."

But Heaney also points out "A Collection may have Physical Characteristics
additional to those of the documents (e.g. prints kept in guardbooks)."

It is not clear whether Heaney is implying that a Collection can inherit
physical characteristics from its Items (to be "added" to the physical
characteristics of the Collection itself), or that the Collection
characteristics are not the same (and cannot be the same) as the Item
characteristics, as we have agreed (I think) in earlier discussions.

Information about the physical characteristics of Items in a Collection may be
accommodated in either or both of:

Description (A summary of the content of the collection = dcterms:abstract):
"Collection of recorded music including 2000 mp3 files and 30 files in other
formats."

Size (The size of the collection = dcterms:extent):
"2000 mp3 files"
"1000 mp3 files; 500 wav files"

Information about the physical characteristics of a Collection, without
reference to constituent Items, may be found in:

Physical characteristics (The physical or digital characteristics of the
collection = dc:format): e.g. "CD"

Or should this be dcterms:medium (The material or physical carrier of the
resource)? In this example, the term "CD" is ambiguous, as it can refer to the
container and the format of its content.

Finally, we should remember that collections of Collections have to be
accommodated; i.e. a Collection can be an Item (in a super-collection). This
begs the question: is it useful to inherit Collection properties from more than
one level of sub-granularity? If I have a collection (A) of digital resources
which contains a sub-collection (B) of digital music which contains a
sub-collection (C) of lossy-compressed digital music which contains items in mp3
and ATRAC, then do we record Collection A as having items in mp3 format?

Or does Collection A have "items" in the format of its immediate sub-collections
(e.g. B1, B2, etc.); that is, the dc:format/physical characteristics of B1, B2,
etc.?

I don't expect this helps!

Cheers.

Gordon