Thanks for keeping us on track Pete!

Without doubt 
"How (if at all) should we represent the information that a collection C
includes some items of media-type M or physical form P?" 

Is _a_ question ;-) and a question well worth answering, so let's stick
with it (for now!).


There is a certain purity about (a) which is appealing. Though I would
rephrase the position as "you cannot directly represent this information
in a description of the collection - but it could be inferred from
descriptions of the items and the relationships between the items and
the collection." Of course, his would mean that Diane's aggregator - who
doesn't know about the individual items - couldn't convey the
information.  The information is, in this view, actually comprised of
multiple statements:
Collection C includes item i1
Collection C includes item i2
Etc And 
Item i1 has the format media-type M1 or physical form P1
Item i2 has the format media-type M2 or physical form P2
Etc 
For each of the "some items"

For me, the collection is more than just the sum of its parts. In all
this, I think we need to be careful about other elements too. Perhaps
another question of relevance is "what do we understand to be the
content of a collection"? I raise this, because several other terms in
the CDAP also reference the items, rather than (apparently) the
collection directly - e.g subject, language, contents date range ... 

Other terms clearly relate directly to the collection - e.g. creator
(interestingly the AP seems to take a different interpretation of
"content of the resource" in this case).

On the other hand, there is a pragmatic appeal in (c). Its imple, it
meets the functional requirement, and as a new property it can have
pretty much whatever semantics we want. Perhaps it is a property worth
defining and using even though it is may be inconsistent with the
one-to-one rule and ther abstract model. If its of sufficient utility,
does that matter? 

John


-----Original Message-----
From: DCMI Collection Description Group
[mailto:[log in to unmask]] On Behalf Of Pete Johnston
Sent: Wednesday, 6 July 2005 6:15 a.m.
To: [log in to unmask]
Subject: What is the question we need to answer? (Was RE: Results of
poll on expressing format of items)

I think maybe we need to take a step back and remember what problem we
are trying to address here.

The "functional requirement" that was identified was that it was useful
to be able to discover/select collections according to the media types
(or other indications of item form - including physical form) of _items_
within the collection. i.e. to say collection C contains some items of
media type audio/mp3, or collection C contains some audio cassettes.
That was the clear requirement expressed by Ann C and Sarah way back at
[1] and [2] (and by others on and off since then).

John said:

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

That is _a_ question, certainly, but I'm not sure it is the key question
that we need to answer.

IMHO, the question we have to answer is not (at least in the first
instance):

"What does it mean when we have a statement using the property dc:format
and the subject of the statement is a resource of type collection?". 

Diane said:

> Agreed--I think I tried to say that, but perhaps didn't do so very 
> successfully. I think my point was that the perspective of someone NOT

> the collection holder was necessarily a bit different, and though 
> conceptually the notion that a collection always had items, an 
> aggregator didn't necessarily have any idea what those items were or 
> what their format was.

Again, I don't think this is the problem we are trying to address. i.e.
the question we have to answer is not:

"How can I construct a value that makes sense in a statement using the
property dc:format when the subject of the statement is a resource of
type collection, and I don't know anything about the items?"

The "functional requirement" is to represent information about the
media-types/forms of items within the collection. 

So the question is: 

"How should we represent the information that a collection includes some
items of media-type M or physical form P?" 

If you haven't got access to that information (for whatever reason),
then you can't provide it within the collection description. That's
fine. 

The problem we need to solve is to enable someone who _does_ have access
to that information to represent it. 

There is no requirement that that means using the dc:format property,
though it may be an option.

I think the suggestions that have been put forward are:

(a) it is impossible to represent the information that a collection
includes some items of media-type M or physical form P without breaking
the one-to-one principle (Andrew's argument)

(b) this can/should be done using the dc:format property 

collection:C a dcmitype:Collection .
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" .

because the "physical or digital manifestation" of a collection is the
"the union of physical or digital manifestations of the resources which
constitute the collection." (Tom's argument)

(c) this can/should be done using a new property (cld:itemFormat or
whatever we decide to call it), which is not a subproperty of dc:format,
and which is defined to describe the relationship between the collection
and a media-type/format of some items within the collection

collection:C a dcmitype:Collection .
collection:C cld:itemFormat _:x .
_:x a dcterms:IMT .
_:x rdf:value "audio/wav" .
collection:C cld:itemFormat _:y .
_:y a dcterms:IMT .
_:y rdf:value "audio/mp3" .

because this relationship is a different relationship from that
represented by the dc:format property. Of the options I put forward in
the poll, this was the one that gathered the most support from those who
voted (though it's clear that not everyone who has an interest expressed
their opinion at the time).

(d) this can/should be done using a new property (cld:itemFormat or
whatever we decide to call it), which is a subproperty of dc:format
(this was Tom's option (f), I think)

(e) this can/should be done using a new property (cld:itemFormat or
whatever we decide to call it), which is a subproperty of dc:description
(Douglas' suggestion)

Now then, I agree that discussion of option (b) and option (c) may well
lead us into discussion of what the statement

collection:C dc:format _:x .

really "means". 

But first I think we need to agree what problem we are trying to
address. 

Do we agree that the question to be answered is

"How (if at all) should we represent the information that a collection C
includes some items of media-type M or physical form P?" 

Cheers
Pete
 
[1]
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0309&L=dc-collections&P
=2131
[2]
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0309&L=dc-collections&P
=2672