John:

I think your questions are very relevant, and I offer a practical 
perspective from the point of view of an aggregator of metadata--one 
step removed from the collection holder.

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

 From an aggregator's perspective, you can definitely have a 
collection without items. If you're not the collection holder and you 
are looking at an available collection (say, a website containing 
educational materials), you may choose to describe that collection AS 
a collection (or others may describe it for you), even if you have no 
immediate way to know what those items are or to have metadata about 
them. You may be able to get a service to provide a listing of the 
items and some  metadata for them, if the collection can't (or 
won't), or you may not be able to do anything.  It could certainly be 
said that the collection exists even if all you know is that someone 
created it, but from a practical perspective, there may be no extant 
list of items or metadata for them. This is sort of a "tree falling 
in the forest" notion, but helpful to consider.

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

I agree with this, wholeheartedly. The usefulness of the information 
about the formats represented in a collection is not really the 
issue--we can all agree on that. What we don't want to do is muddy 
the water so that it's not clear what we're describing where.  This 
conundrum is really why the one-to-one rule exists.

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

Lovely example, and I'd contend that we we could say, yes, the 
collection format is CD, but the item format is  image/jpeg. If the 
same collection were available on the web, though--would it have a 
collection format?  Would the fact that all the images were jpegs 
allow us to convey an aggregate notion of format for the collection? 
It might well be that the relationship between the items and the 
collection would allow us to do that aggregation where we need to 
within our applications, without having to include it in the 
collection description. That would certainly be my preference.  But 
then, of course, I might want to tell someone else down the chain 
what I know about the aggregated formats of the items, and I still 
have a problem.

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

Oh, gosh, I hope we're not going there!  ;-)

Diane

>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