Apologies for not responding sooner....

I think we are mostly agreeing that

1. If the subject resource is the collection, then a statement made using
the dc:format property provides the format of the collection, not the format
of the items within the collection. (I think Sarah was acknowledging that
their use of dc:format for the latter was a bit of a stretch).

2. The format of a collection - even if we aren't quite sure what we mean by
that! - is something distinct from the format of the items within the
collection. Even in the case where a functional granularity approach is used
to delineate collections according to the format of the items, these are
still different: my collection of items of format mp3 files is not itself a
resource with format mp3.

3. The format of the collection is not significant in terms of meeting the
functional requirements for the DC CD AP. This was Simon & Steve's point and
I don't think anyone has argued against it. I must admit I've often
struggled to provide decent examples of what "The physical or digital
characteristics of the collection" really means (other than extent).

So, on this basis, I propose that we drop the "Physical
Characteristics"/dc:format property from the DC CD AP.

So

Q1. Do you support the proposal to drop the "Physical
Characteristics"/dc:format property from the DC CD AP. Answer Yes/No


I'm less sure that we have consensus on whether describing the format of the
items within the collection is significant in terms of meeting the
functional requirements for the DC CD AP or not.

If we do need to describe the format of the items within the collection,
then we need to do that using some other mechanism than a statement about
the collection using the dc:format property. Suggestions so far have included

(a) use a property to represent the notion that the collection contains
items of some format (e.g. cld:itemFormat)
(b) use a new property to represent the notion that the collection contains
some item, and then use dc:format to represent the format of the item
(c) use some other mechanism like a type vocabulary

I think (c) really overloads the type mechanism.

I think (b) is OK but moves us away from the approach of describing the
collection only. That isn't necessarily a showstopper, but it would be a
fairly substantial change.

I was uneasy about (a) initially but having thought about it a bit more, I'm
a bit less so (e.g. it compares reasonably with something like FOAF's
workplaceHomepage property - that is used as a property of an agent to
indicate that the agent has a workplace that has the homepage X)

But I'm really not sure that we have agreement either on the requirement or
on this mechanism.

So three more questions:


Q2. Is recording the format of the items within the collection significant
for meeting the functional requirements of the DC CD AP? Answer Yes/No.

If you answered "Yes" to Q2, then answer Q3 and Q4

Q3. How should information about the format of the items within the
collection be represented? Select from:

(a) use a property to represent the notion that the collection contains
items of some format (e.g. cld:itemFormat)
(b) use a new property to represent the notion that the collection contains
some item, and then use dc:format to represent the format of the item
(c) other (please specify)
(d) other (don't know but we need to do it somehow!)

Q4. Should we shelve this issue for the initial version of the DC CD AP?
i.e. note it as an "open issue" that needs work in the future, but not
incorporate this in the first version of the DC CD AP. Answer Yes/No.

I'd welcome responses to Q1-4, bearing in mind that if we are to complete a
version of the DC CD AP within the current working year, we need to make a
decision on this issue pretty quickly.