I would say it is not just "a good thing" to make the distinction
between the two cases, but fundamental. If I have both a collection of
items (my institutional holdings), and a collection of descriptions of
those items (my institutional catalogue) then, while the semantics of
the elements may be equally applicable to both, the values that would be
appropriate would be different in many instances. The creator of the
finding aid will quite possibly be different to the creator of the
collection, similarly for dates etc. So I guess I'm agreeing with Pete's
view that a collection description is itself often a special case of a
collection, i.e. a collection of item descriptions.
And I assume that we are now sufficiently clear about the differences
between describing the collection as a single aggregated resource, and
aggregating the descriptions of the constituent component items. I think
we have dealt with this, but I suggest we the DC CD AP will need some
clear explanatory material to avoid confusion during implementation.
Knowing what resource you are describing is _the_ most fundamental point
in getting robust metadata.
John
John Roberts
Group Manager, Archives Management
Archives New Zealand
PO Box 12 050
Wellington
NEW ZEALAND
email: [log in to unmask]
phone: +64 4 496 1392
mobile: +64 21 776 232
-----Original Message-----
From: DCMI Collection Description Group
[mailto:[log in to unmask]] On Behalf Of Pete Johnston
Sent: Thursday, 27 July 2006 12:32 a.m.
To: [log in to unmask]
Subject: Re: Type of items within collection
Gordon said:
> Fine. I suggest making this explicit by changing the title to
> "Collection Description Type vocabulary" (and would it be worth
> changing the name of the element to cld:CDType or some such, if
> possible? - it would avoid abbreviation confusion between "cld" and
> "CLD").
Yes, I think it would be a good idea to change the name of the type
vocabulary as you suggest.
I'm inclined to retain the use of the dc:type element because we are
still capturing the "type" of the resource - the resource being
described _is_ a resource of type "Hierarchic finding-aid" etc - and I
think it's quite common for some generic metadata applications to
filter/search DC metadata records using a query on the value of dc:type.
There is another question here (that was raised in the context of the
NISO Metasearch work on collection description) of whether we should
amend/refine the profile to specify the use of two separate sets of
properties:
(i) a set of properties for the description of collections (i.e. more or
less what we have now)
(ii) a set of properties for the description of those collections which
are also collection-descriptions/catalogues (which I think would be a
subset of (i))
And a description set conforming to the DC CD AP could contain one or
more descriptions of collection-descriptions (using the properties
listed in (ii)) as well as a description of the (described) collections
(using the properties listed in (i)).
The use of the Collection Description Type Vocabulary would apply for
the dc:type property in (ii) but not in (i).
And I'd be inclined to say we'd use properties like cld:itemFormat,
cld:itemType, dcterms:provenance(?), dcterms:audience(?) in (i) but not
in (ii).
For properties like dc:subject, dcterms:spatial, dcterms:temporal, I'm a
bit less sure. I think an argumeant could be made that it's not the
collection-description/catalogue which has the subject or coverage but
rather the collection described by the collection-description/catalogue,
and on that basis they would be included in (i) but excluded from (ii).
If the feeling of the group is that making this distinction is a good
thing, I'll draft suggested lists of properties for the two cases, along
the lines above.
However, I'm concious that we are aimimg to submit the DC CD AP for
review, the deadline for which is 24 August, and this change may raise
some issues that aren't quickly resolved. If it seems difficult to reach
consensus on the set of properties for (ii), I'd suggest we go ahead and
submit the version based on "collections only", and keep the option of
specifying the collection-description properties as a revision to the DC
CD AP at some point in the future.
But it would be good to have some initial feedback on whether you think
making this separation in the DC CD AP is desirable/necessary/feasible.
Cheers
Pete
|