> What happens when the collection is a mixture of types?
>
> This situation can be accommodated if type is repeatable in
> the CLD. I wouldn't advocate a catch-all of 'mixed'; it
> doesn't help the presumed functionality of this attribute.
Yes, the intention is that the dc:type property is repeatable. Sorry
that isn't clear at the moment. So, yes, you could indicate that a
collection had items which were images, texts, sound etc
> But if type is repeatable in a CLD, then why have the
> 'collective' type 'image' in the list?. A collection of still
> and moving images has the types still image/moving image.
This is really inherited from the DCMI Type Vocabulary where the two
subtypes/subclasses were introduced relatively recently. Yes, as you
say, a statement that a resource is of type dcmitype:MovingImage implies
that it is also of type dcmitype:Image (and the same would apply for the
proposed "collection of images" etc classes)
> Reasonable guidance might be to include all types where they
> are substantially represented in a mixed collection. I.e.
> ignore types which are in a significant minority.
Yes.
> This depends on collection size: a collection of one movie,
> one book, and one piece of interactive software would have
> types moving image/text/interactive resource; but a
> collection of 10000 images and one book would have type image only.
Agreed. We need some guidelines on this.
> It is absolutely important to be able to specify type as
> 'catalogue' (as opposed to 'collection').
>
> SCONE depends on this for displaying CLDs in the user
> interface: CLDs for catalogues are filtered out, because the
> primary CLD is for the collection. SCONE uses functional
> granularity to create a CLD for a collection which is
> described by a given catalogue, so there is always a primary CLD.
OK, so I suggest at a minimum we introduce a type/class of Catalogue
(collection of metadata records)
Is that one type/class sufficient or should we introduce the three-way
Catalogue (Analytical Finding Aid)/Finding Aid (Hierarchical FA)/Index
(Indexing FA) distinction used in the RSLP model and the initial RSLP
CLDT Type list?
> But this is a different kind of collection type, and a CLD
> needs to accommodate both kinds, as allowed in the RSLP CDLT.
> It's no good suggesting a type of 'metadata' as this itself
> can come in different types (text, image).
Yes, agreed. That's covered by the ability to include multiple dc:type
statements.
> The RSLP CLDT is pretty effective for SCONE, although some
> definitions need clarification. E.g. 'special' can be defined
> on a subject basis, and SCONE distinguishes this from
> 'subject' type by confining it to non-topical subjects (e.g.
> persons, places). In practice, I've found the 4 categories of
> type in CLDT essential for creating useful filters in the
> SCONE interface (e.g. limiting collections to Library,
> Archive, Museum, or Internet in a common information environment).
OK, we can extend to include type lists based on other criteria if
required, though I think we should aim to keep the number as small as
possible, and to take care not to "overload" this mechanism with
information that should really be represented as another property.
And, yes, agreed, we need good clear definitions of each type/class we
provide, and we need to be clear about how statements using those
types/classes are to be encoded. The dotty notation for RSLP CLDT was
really a shorthand for multiple types, and I think it is probably
preferable to say explicitly
my:resourceX dc:type sometype:CollectionImage .
my:resourceX dc:type sometype:CollectionLibrary .
If we do adopt types based on different criteria, I'm tempted to say we
should separate them out into distinct type vocabularies.
So, leaving aside the criteria of item type for a moment, what other
criteria for collection type/class should we be considering?
- type of catalogue (catalogue/index/hierarchical)
- all of the others used in RSLP CLDT?
http://www.ukoln.ac.uk/metadata/rslp/types/
I was kinda hoping we could settle on a shorter list ;-)
Pete
|
