This may be of interest to the Usage Board. 

Confidentially, I can tell you that I have been working with these 
people in the past and tried to explain that metadata values should 
be about the resource described and not (like in the case mentioned) 
about the publisher of the resource.

They are struggling with this because they want to be able to ask
questions like "give me all resources published by a municipality"
without having to go through a thesaurus of organisations.

Please also note that they still use HTML, not XHTML and double dot 
syntax although I told them this is obsolete.

Makx.

--------------------------------------------------------------------
Makx Dekkers                            e-mail: [log in to unmask]

-----Original Message-----
From: Dublin Core Element Set government and public sector resource
[mailto:[log in to unmask]] On Behalf Of Raph de Rooij
Sent: Wednesday, 23 February 2005 16:41
To: [log in to unmask]
Subject: Inverted refinement


Greetings from the Netherlands,

Mij name is Raph de Rooij and I am involved in the development a metadata
standard that is based on DCES. I have a question regarding element
refinements. On
http://dublincore.org/usage/documents/principles/#element-refinement I read:

2.2.1.  Element Refinements.
An Element Refinement is a property of a resource which shares the meaning
of a particular DCMI Element but with narrower semantics.  In some
application environments (notably HTML-based encodings), Element Refinements
are used together with Elements in the manner of natural-language
"qualifiers" (i.e., adjectives) [3].  However, since Element Refinements are
properties of a resource (like Elements), Element Refinements can
alternatively be used in metadata records independently of the properties
they refine [9].  In DCMI practice, an Element Refinement refines just one
parent DCMI property.

Mty question is: is it allowed (or wise) to use a refinement for a term with
wider semantics than the element itself?
An example: when the value of DC.publisher is 'Amsterdam', will it create a
problem when you also have a refinement OVERHEID.publisher.typePublisher
with the valuse 'municipality'?
Our aim is to base the OVERHEID namespace on the same definitions as the DC
namespace. Because we want as few extra elements as possible in OVERHEID and
want to maintain a sound relationship between elements and 'refinements',
the construct OVERHEID.publisher.typePublisher (and also
OVERHEID.creator.typeCreator and OVERHEID.contributor.typeContributor) has
our preference. Moreover, a separate element is in my opinion not desirable,
since it is not only related to the content that is described, but also to
more related to 'DC.publisher'.
For us, a guideline in our thinking was the Dumb-Down Principle, as
described on http://dublincore.org/usage/documents/principles/:

2.3. Dumb-down Principle
The qualification of Dublin Core Elements is guided by a rule known
colloquially as the Dumb-Down Principle. According to this rule, a client
should be able to ignore any qualifier and use the value as if it were
unqualified.  While this may result in some loss of specificity, the
remaining term value (minus the qualifier) must continue to be generally
correct and useful for discovery.  Qualification is therefore supposed only
to refine, not extend the semantic scope of an Element.

In the example, 'municipality' leads to some loss of specificity, but the
value remains generally correct and useful for discovery.

Opinions of the DC-GOVERNMENT members regarding the use of 'inverted
refinements' are much appreciated.


With kind regards,

Raph de Rooij
Advies Overheid.nl

E [log in to unmask]
I www.overheid.nl / www.advies.overheid.nl / webrichtlijnen.overheid.nl
T +31-070-8887857