Another latecomer joining in. I presume that not voting doesn't preclude
me from commenting ;-)

First, I fully agree that you can have a collection with one item, and
that the collection is different from the item. (If pushed, I may even
argue that you could  have a collection with no items, but I haven't
though that through yet. Conceptually, it would be like Pete's example
of a Gallery collection that sells its last painting, in order to get
money to buy some more, but asserts a continuity of 'the collection'
through the period when there are no paintings in it. But that's by the
by, I think)

I don't think anyone is arguing that it isn't useful to be able to
readily tell what formats are represented in a collection. But a
collection of things of format x does not mean that the collection is of
format x. The question (it seems to me) is whether it is possible,
within the definition of format, to talk about the format of a
collection? 

If I collect a bunch of digital images and store them on a CD, is the
collection format CD? Or is it something to do with any index structures
I may have added? Or do we need new a property, defined in language that
is clear for a collection? 

Still musing on this question - though I note Douglas's suggestion that
the format of a collection may in some way relate to its arrangement (or
lack thereof). 

John



-----Original Message-----
From: DCMI Collection Description Group
[mailto:[log in to unmask]] On Behalf Of Pete Johnston
Sent: Saturday, 2 July 2005 8:16 p.m.
To: [log in to unmask]
Subject: Re: Results of poll on expressing format of items

On Fri, 1 Jul 2005 21:12:33 +0100, Pete Johnston
<[log in to unmask]> wrote:

>If we say the collection is the aggregation, and the aggregation is 
>something concrete, not simply an abstract/conceptual resource (which I

>think is the argument I was making to Andrew a few minutes back!), then

>I think in that case the use of dc:format to describe a collection 
>_does_ become a possibility.
>
>But I come back to my point that the relationship type that you want to

>express using dc:format in statements like
>
>collection:C dc:format _:y .
>_:y a dcterms:IMT .
>_:y rdf:value "audio/mp3" .
>
>is a different type of relationship from the one expressed by dc:format

>in
>
>file:F dc:format _:y .
>_:y a dcterms:IMT .
>_:y rdf:value "audio/mp3" .
>
>The latter set of statements gives me enough information to conclude 
>that I can take the resource file:F and give it to an application that 
>consumes the format "audio/mp3"; if I make that assumption from the 
>second set of statements, I'm in trouble. My mp3 player can't process 
>collection:C. It can process some of the items that make up 
>collection:C, but that's a different thing. So it seems to me we have 
>two different interpretations of dc:format in the two statements, and I

>think that is problematic.

Just to argue against myself, we've done pretty much exactly the same
with the use of dc:language and I've gone along with that so far, so I
withdraw that as an argument in principle - though I'm still uneasy
about the practical consequences of applying it to the dc:format case.

I think my initial concern was this: if an application queries a set of
Dublin Core descriptions - including descriptions of different types of
resource - for resources for which the value of dc:format is the
audio/mp3 MIME type, given the definition of the dc:format property and
the dcterms:IMT class, is it appropriate that the result set includes
both a description of a collection which includes items of format
audio/mp3 and an audio file which is of format audio/mp3?

(OK, I've said too much on this thread - I'll shut up now!)

Pete