Pete Johnston said:
"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"
I find this possibility confusing? Scary?
I just had a question from a client setting up a database for DC metadata: what are the valid qualifiers for dc.publisher?
I went to www.dublincore.org and http://dublincore.org/documents/dcmi-terms/ Because the terms are listed independent of the elements they refine and not in any obvious order, it was difficult to determine if there were any refinements for publisher. I had to go to the Usage Guide to determine that there were none.
So in my view having terms listed independently of elements is bad enough. Having terms with no specified relationship to an element is going way too far.
My immediate reaction. Friday afternoon thoughts in a snowstorm in Canada.
Nancy
Nancy Brodie
613.946.5039 | [log in to unmask] | Facsimile/Télécopieur: 613.946.9342
Information Management Division, Treasury Board of Canada Secretariat
Division de la Gestion de l'information, Secrétariat du Conseil du Trésor du Canada
2745 Iris St., 4th Floor | 2745, rue Iris, 4e étage | Ottawa Canada K1A 0R5
.
-----Original Message-----
From: Pete Johnston [mailto:[log in to unmask]]
Sent: February 20, 2004 10:47 AM
To: [log in to unmask]
Subject: Top-level terms (Was RE: [UB Proposal "DC Rights-related Terms"])
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
|