On Wed, 6 Jun 2001, Andy Powell wrote:
> I am happy with
>
> http://purl.org/dc/elements/1.1/
> http://purl.org/dc/terms/
> http://purl.org/dc/dcmitype/ ...
Dear all,
I believe we are moving closer to consensus on the above, so I'd like
to review where I think we stand:
1) As recommended so strongly by Dan, Harry, and others, we
accept that http://purl.org/dc/elements/1.1/ is a legacy URI. I
believe we also agree that it should refer to the set of fifteen
elements known as Dublin Core Metadata Element Set Version 1.1 and
that -- for now at least -- it should not grow to 16 elements and
beyond.
2) We largely agree on combining elements and qualifiers into
one namespace, called "terms", though some would like to maintain
separate sub-spaces for elements and qualifiers. In favor of one
namespace, it has been pointed out that the Element/ElementQualifier
distinction is not quite the same as RDF's Property/Sub-Property,
suggesting problems in both the short and long term.
3) We do not quite agree about the desirability of having separate
namespaces for "domain-specific" elements. The case in point is
Education, as the Usage Board on May 22 approved one education
element and two qualifiers, which could be declared in a new
namespace schema at http://purl.org/dc/ed/. However, it has been
pointed out that we may decide later that some of those terms are of
"cross-domain" significance, or that at any rate "education" is not
the best label for them. Hard-wiring our initial categorization
into the URI string makes the terms awkward to reclassify later. If
names are not supposed to change, metadata creators in fields far
away from education would be adding http://purl.org/dc/ed/ to their
namespace inclusion blocks simply in order to use, say, "audience".
The analogy was drawn to the carefully designed directory trees of
Web sites, which seem right at the time but inevitably end up
feeling wrong.
4) We agree on http://purl.org/dc/dcmitype/ though, as Aaron points
out, it is not as terse as it could be. However, the vocabulary is
called DCMI Type, and this name does help avoid a confusion between
http://purl.org/dc/type and http://purl.org/dc/elements/1.1/type.
Open issues:
1) If we go the route of the "big namespace", it implies richer
administrative, versioning, and grammatical metadata annotating the
terms in this one big flat space. Furthermore, if some terms are
"domain-specific" this implies a to-be-created ontology of domains
(cross-domain, education, etc) that should be machine-understandably
dereferenced in the namespace schema.
2) Ordinary people do not want to look in X locations to put together
a metadata set, but creating a DCMI Education namespace does not
solve that problem as it would contain only three terms and not the
full recommendation of the Education Working Group, which was to use
DCMES + the three new terms + some IEEE-LOM terms in creating
education metadata. Perhaps we need to define such hybrid sets as
Application Profiles and index them as such in the registry.
Tom
_______________________________________________________________________________
Dr. Thomas Baker [log in to unmask]
GMD Library
Schloss Birlinghoven +49-2241-14-2352
53754 Sankt Augustin, Germany fax +49-2241-14-2619
|