This isn't really a comment on the proposal so I changed the
subject-line.

> 2. rightsHolder
>
> I'm wondering if this really should be a 'top-level' term. It
> doesn't feel right as such and I suspect could cause future problems.
>
> Could rightsHolder be a sub-property of publisher? Certainly
> the rightsHolder will be allowing the resource to be published.
>
> There seem to be other terms surfacing that are also loosely
> contributors in some way to a resource, but cannot be sub-
> properties of contributor because that is defined as
> contributing to the *content* of the resource. The
> Collections Working Group has 'owner'. I did wonder if
> rightsHolder and owner were the same but proabably not.
> Rights last for a fixed length of time whereas you could own
> something old.
>
> Perhaps what is needed is a new top-level term like
> associatedParty. Then rightsHolder, owner, etc. could be sub-
> properties of that.

My own feeling is that it's probably better _not_ to try to specify
sub-property/refinement relationships where the meaning conveyed by the
property is such that expressing a sub-property relation would be
inappropriate.

At the risk of going out on a limb....

I'd even suggest we should embrace the notion that it is perfectly OK
for DCMI to create properties in the DCMI metadata vocabularies ("DCMI
Namespaces") without specifying any direct relationship between those
properties and one of the original 15 elements in the DCMES (in some
slightly larger superset of "top-level terms" (e.g. DCMES + audience +
associatedParty)).

The existence of a sub-property relationship means that when I make a
statement using the "sub-property", I imply a statement using the
"super-property".

It may well be that the meaning conveyed by a new property determines
that it does make sense to describe it as a sub-property of one of the
15 elements, and if so, that's fine.

But if the meaning of a new property is such that stating a sub-property
relation to one of the 15 elements implies a relationship that we don't
really want to imply (e.g. I don't necessarily _want_ a "has-Owner"
relationship to imply a "has-Contributor" relationship, or a
"holds-Rights" relationship to imply a "is-made-available-by"
relationship), then it's fine not to state a sub-property relationship.

We shouldn't insist on the existence of a refinement/sub-property
relationship if the meaning of the property does not support it.

We should be thinking in terms of creating vocabularies of properties
that are useful for the functions DC metadata is intended to support,
not in terms of keeping everything tightly related to a fixed and/or
very small vocabulary of "top-level terms".

And that does _not_ mean the DCMES expands - the DCMES is still composed
of exactly those 15 elements, because DCMI and the various standards say
so.

And it doesn't mean that the larger DCMI vocabulary explodes suddenly -
proposals for new terms are still rigorously evaluated by Usage Board in
line with their criteria for usefulness for cross-domain resource
discovery, whether they exist in other vocabularies etc.

But it does mean we avoid struggling to make sub-property statements
just for the sake of it and then having to grapple with the consequences
because they imply something we don't want to imply ;-)

It seems to me that creating a term called associatedParty would serve
very little purpose - except to have something to use as an object of
sub-property statements!! An associatedParty property tells me nothing
about the nature of the association, except maybe that the object is a
"Party". So being able to infer that a rightsHolder statement implies an
associatedParty statement isn't very helpful. In fact, we already have
one top-level term which could serves the purpose, in dc:relation - if
we really need to specify a sub-property relation for a new property, it
seems to me every property you can think of can be a sub-property of
dc:relation! ;-)

Cheers
Pete