Pete

See comments below.

Cheers.

Gordon

Quoting Pete Johnston <[log in to unmask]>:

> 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))

This seems sensible. It will help to clarify the similarity/distinction for
implementors and operators. As we know, vocabulary can be confusing: a
collection-description (in Heaney's usage) is a finding-aid; a collection-level
description is the metadata record for the collection; a collection description
is what you put in the description element. A collection description in a
collection-level description of a collection-description is quite _normal_!

> 
> 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)).

Will this work for a collection-description of a collection-description? E.g. a
title index in a catalogue is a valid collection-description of type index, but
it describes a collection of type catalogue (which in turn describes a collection).

> 
> 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).

I think it's often useful to know what is the content type of the records in a
collection-description; that is, the cld:itemType of catalogue. While most
catalogues would records expressed as text, we have to consider non-textual
metadata records in finding-aids. E.g. image thumbnails or every-nth-frame of
items in a video collection. So I think cld:itemType would be a property of both
 (i) and (ii). I can't think of equivalent examples for cld:itemFormat unless we
consider the need to record metadata format. E.g. a catalogue with records in DC
format, or MARC21, etc. This of course is a quite different vocabulary set ...

dcterms:audience might also be useful for collection-descriptions; e.g. a kid's
catalogue.

And, I guess, dcterms:provenance might also be useful for catalogues aggregated
from smaller catalogues (i.e. union catalogues); this overlaps with discussions
on the DC eprints AP.
 
> 
> 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).

I find it difficult to conceive of the subject of a catalogue as distinct from
the subject of the collection it describes, so I think these properties should
be 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.

SCONE uses identical metadata structures (tables, fields) to record collections
and associated collection-description. The distinction is made by the
relationship collection:isDescribedBy:collection(-description), and by using the
RSLP CLDT types schema.

As far as I can recall, we have usefully applied the other RSLP CLDT types (for
format and usage) to both kinds of collection-level description. Ditto for agent
and location entities, but not subject and other entities applicable only to
collections in category (i). Note that much of this pertaining to
collection-descriptions (ii) is invisible in the public SCONE interface because
the primary focus is on collections (i)

> 
> 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
>