Hi Ann,

Apologies for the very slow response....

> I would think intuitively one may want collections of events,
> of services, of collections. But I haven't studied Heaney's
> model in such detail.

When I first looked at it, that was my inclination too.... but I think
it is worth noting that the RSLP model does emphasise that it is using
"Item" in the sense that term is used in the FRBR model:

====
Collection: An aggregation of physical and/or electronic Items.
====

and

====
Item: The concrete (incorporating physical and electronic) realisation
of Content.
Note: In so far as this analysis is concerned with collections, the
entities Content and Item will be considered only to the extent that
their types and attributes impinge upon Collection Description. In the
vast majority of cases, too, the Items will coincide with what FRBR
calls Items, not Manifestations. 'Item' has been chosen as the most
neutral term in preference to other terms which have been used such as
'Document' or 'Document-like Object'. 'Item' can most easily embrace all
of the concepts of physical and electronic, text and non-text, and human
and natural creations.
====

So not all resources are items, I think. Certainly I had a discussion a
long time ago about RSLP CD where we decided that "abstract resources"
(concepts, points in time etc) could not constitute Items in the FRBR
sense. So a set of abstract resources wouldn't constitute a Collection
(as defined here). That's not to say that there aren't aggregations of
concepts, but those aggregations wouldn't be Collections.

So on that basis I wasn't convinced that an event, service or collection
could fit this definition and that's why they were left out of the type
list - I think I'm probably wrong for the case of "collection" and we
should allow a "collection of collections", but I'm still not sure about
an event or a service... but I'm open to persuasion, especially from
those more familiar with FRBR than I am!

> If we use this typelist I suggest its 'name' should be
> CLDType rather than just CLDT. That follows the DCMIType
> convention. It also avoids confusion with the RSLP CLDT list.
> I know they have a different namespace but people tend to
> just refer to 'CLDT'.

OK.

> However I'm wondering if we need this type list at all. I
> assume it is meant as a vocabulary to provide values for
> dc:type - the type of the collection.

Yes. And the current proposal uses the criteria of the type of the
constituent items as a means of defining a type of collection. I _think_
that's a reasonable thing to do, but I'm not massively in favour of it
or against it. And I agree that (as you suggest below) there may be
alternative ways of modelling/representing the information.

Just to recap - I know you know this ;-) - the main point is that we
need to maintain a clear distinction between saying

(1) my:resourceX dc:type dcmitype:Image .
(i.e. Resource X has-nature-or-genre "image", or Resource X _is_ an
"image")

and

(2) my:resourceX dc:type sometype:CollectionImage .
(i.e. Resource X has-nature-or-genre "collection of images", or Resource
X _is_ a "collection of images")

where

sometype:CollectionImage rdfs:subClassOf dcmitype:Collection .

> Would it be better to invent a new term eg cld:itemType (not
> necessarily suggesting that as a final name) for the type of
> the items in a collection. Then all the types included in
> this CLDType list would be covered by the DCMIType list.

I agree this would be another way of providing the information. (More
below!)

> Advantages would seem to be:
>
> - We don't need to worry about who would provide a namespace
> for and maintain this list.
>
> - It is extensible to be used with other typelists: eg:
> <cld:itemType
> xsi:type="someother:typelist">photographs</cld:itemType>. So
> avoids the never ending requests for more specific types.

I'd say that in your example here "photograph" is exactly a more
specific type; it's just defined in someone else's type vocabulary/list.


I don't think there's anything in the current proposal that prevents
people doing that, but they would define a collection type i.e. someone
could define a class for "collection of photographs" as a
subtype/subclass of the proposed "collection of images" or "collection
of still images".

But, yes, "photograph" and "collection of photographs" would be distinct
classes/types.

> The disadvantage is that we have to define yet another term.
> And that it would not be a property of the resource
> (collection) itself - rather a property of a component of the
> resource. But maybe that could be addressed by giving it an
> appropriate name / definition.

If we did take this approach, cld:itemType (or whatever we called it)
_would_ be a property of the collection, wouldn't it? The property would
convey the meaning: the subject resource (the collection) "contains
items of type" "image" (dcmitype:Image).

I accept that this fits the resource-property-value model, and, with a
suitable definition of the cld:itemType property, then dcmitype:Image
(or sometype:Photograph) becomes an appropriate value.

But (and this is just my own opinion!) I would find it hard to argue to
the Usage Board that DCMI needs a property with these semantics, because
it seems to me that the requirement should be met by modelling our
"world" more fully and saying

my:collection dc:type dcmitype:Collection .
my:collection some:contains _:x
_:x dc:type dcmitype:Image .
my:collection some:contains _:y
_:y dc:type dcmitype:Text .

> If we took this approach then maybe we'd want to drop dc:type
> / type of collection?

I think we would still want to make the statement that

my:collection dc:type dcmitype:Collection .

which is sort of implicit in the DC CD AP.

If we took the proposed approach of saying

my:collection dc:type cldtype:CollectionImage .

etc

then (as I think I argued in response to Douglas a while back) an
application could derive/infer the previous statement, from the fact
that cldtype:CollectionImage is declared as a subclass of
dcmitype:Collection. But if we drop the proposed subtype/subclass
approach then we would need to make the statement explicitly, I think.

> Not sure - I could envisage some valid
> collection types such as 'catalogue'.

OK, so that would be another basis for defining collection types e.g.
the RSLP model/schema defined types/classes for "Catalogue",
"Finding-Aid" and "Index".

> But the ones on this
> CLDT list just look to me like a quick fix to introduce item types.

The current proposed approach is using item type as the basis for
defining a set of collection types. It seems useful for discovery to
expose this information about the items in the collection somehow, I
think? But I agree with you that there are other ways of representing
that information (e.g. using a cld:itemType property or by saying
explicitly that the collection contains some item and the item has a
type). These two approaches remove the need to define new classes/types
but they do introduce other considerations e.g. new properties - and (at
the moment at least) I'm a bit uneasy about arguing for approach based
on a cld:itemType property.

> I can't remember if we've considerd this before. Sorry if I'm
> covering old ground.

I don't think we really had the discussion in as much detail as we
should, so it's worth revisiting it.

Pete