Pete,

Thanx for your detailed explanations.

> Maybe... But as I say above, I think that we may find we are dealing
> with slightly different types of relationship in different cases. So,
> for the moment at least, I'm inclined to settle for coining the specific
> properties we need here. If the Usage Board or another party wants to
> create a more generalised set of properties then they can do so - but if
> they were tied to the dcterms:hasPart/dcterms:isPartOf properties then
> we wouldn't be able to use them in the DC CD AP because the "Part" is
> the Sub-Collection, not the Item. 

I don't feel strongly against this.  You are basically saying in collection descriptions we want to differentiate the parent-child relationships of a "collection and sub-collection" vs. "collection and item".

However, I want to get a couple of things off my chest (more to air them rather as niggling thoughts at the back of my mind than to say we are doing it wrong)...

1. The Relation hierarchy qualifiers are non-specific anyway - "The described resource includes the referenced resource either physically or logically", so at that level of thinking hasPart could happily be used for both sub-collections and items.  For the AP we may want to differentiate them, but I would think in DCMES-15 they would probably both be considered "hasPart".  Though hasPart is already a qualifier, so we probably can't further qualify this (or is it acceptable to use "refines" to a third level?).

2. To me the spirit of DC/resource discovery is "we understand there are differences (eg. artist vs author), but in the interests of accessing heterogeneous resources, let's agree to call these the same thing (eg. creator) as they are more or less similar".  I guess we need to be careful we aren't creating a complex metadata scheme in our APs to support resource "use" rather than just resource "discovery".  Is making a new element for this collection-item relationship that sits _outside_ the DCMES-15 really improving resource discovery?

Douglas