I said:

> > If we state
> > 
> > collection:C dc:format _:x .
> > _:x a dcterms:IMT .
> > _:x rdf:value "audio/wav" .
> > collection:C dc:format _:y .
> > _:y a dcterms:IMT .
> > _:y rdf:value "audio/mp3" .
> > 
> > (either by stating it explicitly or because it is inferred 
> based on a 
> > subproperty relation involving another property) then it 
> seems to me 
> > that we are saying collection:C _is_ a resource of format 
> wav and it 
> > is _also_ a resource of format mp3.

Tom said:
 
> I guess this is exactly what I am saying, and I don't really have a 
> problem with it because it _is_ what I wanted to say.
> 
> Lets use some creative definitions to make this work. ;-)
> 
> FORMAT => "The physical or digital manifestation of the resource."
>
> In our case the resource is a "collection" which by definition is an 
> abstract concept.

(I'll come back to that point!)

> First lets differentiate the container from the 
> collection.  A filing cabinet full of documents is not a collection 
> (even though it might contain a collection). 

Agreed.

> Likewise a zip or tar file is not a collection, it is a container.

OK, I can go along with that (so my previous example of collection
having dc:format application/zip would not apply because that would only
apply to the description of the container).
 
> Collections are abstract and containers are concrete. 

As I say, I'm not quite sure that it follows from the fact that
collections are not containers that collections are abstract, but let's
suppose for now it does!

> Because collections are abstract you could 
> argue that they don't really have a "physical or digital 
> manifestation."  Therefore, format is a totally irrelevant property.

OK.

> However, (this is 
> where I move onto shaky ground) I would argue that since there is no 
> existing definition this allows us to create a definition for what is 
> the "physical or digital manifestation" of this abstract 
> object called "collection."
>
> The definition I would like to use for the "physical or 
> digital manifestation" of a collection is the "the union of 
> physical or digital manifestations of the resources which constitute
the 
> collection."
> 
> How's that for a twisted argument? :-)

Not bad, not bad at all! ;-)

But if we accept the argument that a collection is an abstract resource,
then I think I'd argue that we can't make statements about this resource
using the dc:format property - dc:format can only be used to describe
resources which are "manifest". (Though to be honest the definition of
dc:format is so hopeless, I'm not sure I'm on firm ground saying that!
From the wording of the definition alone you might conclude that
dc:format should be used to describe the relationship between a FRBR
expression and a FRBR manifestation, but that isn't how it has been
used...) 

Now then, the DCMI Type definition of collection is

> A collection is an aggregation of items.

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.

Now, I'm presuming my interpretation in the file:F example is "the"
interpretation sanctioned by the DCMI definition! But I do think that is
the way the dc:format property has been used: the "comment" does include
"Format may be used to determine the software, hardware or other
equipment needed to display or operate the resource", and I think that
usage is borne out by DCMI recommending the use of IMT as an "encoding
scheme".

> Because I've separated containers from collections, the ambiguity of 
> what is really meant by format is eliminated unless someone 
> is violating 
> the one-to-one rule and trying to describe the collection and its 
> container as the same resource?

Pete