There is currently circulating within the DC Advisory Committee a proposal
that will help to rationalize the process of registering, proposing, and
recommending Interoperability Qualifiers.
One aspect of this proposal involves a registry that will help make visible
qualifiers used in various DC projects, whether or not they are official
DC-recommended qualifiers. Part of the motivation for this is simply to
publicize what people are doing, with the assumption that as others see and
use these qualifiers, adoption of the generally useful ones will promote
their use and convergence will take place.
The same principal can obtain with additional elements (yes, AUDIENCE seems
a good example).
So, I agree with John's suggestion -- its a good idea to keep in the back of
our minds as we tune the procedure for recommending qualifiers for the
current 15 elements.
stu
-----Original Message-----
From: John A. Kunze [mailto:[log in to unmask]]
Sent: Wednesday, September 29, 1999 2:27 AM
To: [log in to unmask]
Subject: DC as seedbed, not as namespace? [was Re: Audience]
> Date: Wed, 29 Sep 1999 08:00:53 +1000
> Subject: Audience
> From: Warwick Cathro <[log in to unmask]>
> ...
> I think that we need to face up to the fact that the concept of intended
> audience has a different meaning to that of any of the existing 15
elements.
>
> In my view we need to decide whether Audience is a significant enough term
> for "simple resource discovery" to warrant adding to the existing 15. If
it
> is, we should extend the list of 15 fields to 16. ...
[A little off topic, but it seems like time for me to go at this again.]
Most real applications require one or more elements beyond the core 15,
even if those additional elements are not "domain specific".
I hope that we may soon seriously to discuss ways to diffuse the pressure
we've been feeling to develop a basic, extensible element set that subsumes
the "core", but is not the "core". This is a direction that I think would
be broadly useful and would prevent us from driving some of our most basic
applications off into the cold isolation of a "do-it-yourself namespace" for
no other reason than that we don't really have an extensibility mechanism
for the huge territory that exists between "core" and "domain specific".
As I imagine it, such a set would not need to use "DC" as a separate
namespace, but instead use the 15 elements as a seeds for a more general,
but still non-domain-specific metadata dictionary which would have its
own namespace. At first, such a dictionary would start with exactly 15
elements (you know which 15). Over time, this starter set would be
augmented by additional elements (eg, Audience) through processes and
policies that we might begin to define within the DCMI.
-John
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|