Alan:

As the Editor of "Using Dublin Core"
(http://dublincore.org/documents/2001/04/12/usageguide/) I'm happy to see
these broader issues brought up for discussion.  It's really only when
people come in and tell us where the gaps are that we can begin to address
them.

That being said, let me try and mention some of the constraints that tend
to limit what sort of information goes into "Using Dublin Core."

1. Like most of DC, this is a volunteer effort, so necessarily must depend
on time freed from other activities.
2. "Using Dublin Core" is designed to be broad in its application, in other
words, we want it to be usable as a BASIC document, to be augmented by
specific projects where needed. For instance, we don't want the prejudices
and traditions of librarians to be too much in evidence, *particularly when
those traditions do not serve a purpose outside of the library community.*
3. We want the guidance provided to be practical, ergo it is of necessity
"bottom up" rather than "top down."

As you say: "The use of DC metadata will become much more valuable if we
can achieve a
high degree of commonality." How high we can expect to reach, however, is
somewhat limited by our willingness to subsume what we see as our
individual needs to the common good. It's a tough balance, not really ever
achieved fully, though we keep at it.

Based on your points and those made by others I see two areas that should
be addressed:

1. Repeatability--when to repeat, when to separate within an element
2. Separators within elements

I also know we need more/better examples, and would welcome some assistance
with this from Alan or anyone else who would like to help.  The provision
of RDF examples is awaiting the finalization of the DC-Architecture
documentation, but there are definitely other holes in our example sets.  A
couple of volunteer reviewers would be particularly welcomed.

Anything else?

Diane

At 10:16 PM 9/17/2001 -0400, Alan Lillich wrote:

>It has been very interesting to watch the recent discussion on repeating
>elements.  I think the focus on personal choices is missing some important
>broader issues.
>
>The use of DC metadata will become much more valuable if we can achieve a
>high degree of commonality.  Like the standardization of railroad gauges,
>it is not so important that you have a semicolon separated list of keywords,
>repeated simple keyword elements, or in the case of RDF one keyword element
>containing a bag of individual words.  It is more important that metadata
>written by one piece of software be understood by another.
>
>There are (at least) two established and one emerging class of participants
>in the DC metadata game.  The established players are the DCMI and
>significant end users of DC metadata.  The end users are largely
>distinguished by defining their own databases and producing their own custom
>implementations.  They are often in a situation where the metadata is the
>goal.
>
>The emerging participants are the volume software vendors and their
>customers who can benefit from reliable metadata for all of their electronic
>documents.  Adobe finds itself in this situation.  We are in the process of
>adding RDF and DC-based metadata support to all of our applications.
>Acrobat 5 is the first to ship with some of this support.  (For those who
>have used Acrobat 5, it does not embody the final or definitive
>implementation.  It was first, and as usual for software it does not do
>everything we want to do.)
>
>Adobe needs to make choices about the UI we present and the metadata we
>write.  We can't afford to spend the time and money to provide ultimate
>flexibility.  Much as we might wish, we can't canvas all or even a
>significant portion of our users ahead of time.  We need to provide a common
>approach in all our applications that is useful for our customers, and that
>can be utilized by other software to provide additional value.
>
>We think it would be tremendously helpful for the DCMI to provide guidance
>and suggested good practice for the use of DC metadata in unclear areas like
>repeating elements.  These should not have the weight of standards, but
>guidance to help choose a representation and to transform among
>representations.  Policy for logically equivalent representations so that
>software recognizes all legitimate forms.  Perhaps standard qualifiers to
>denote encodings like semicolon separated keywords.
>
>For those of us using RDF, localization through the xml:lang attribute is
>another area where it is easy to construct ambiguous examples.  Suppose you
>have a book with two authors, one American and one Japanese.  And the book
>is published in both the U.S. and Japan.
>
>For the title an rdf:Alt container makes the localization explicit, although
>repeated title properties with xml:lang attributes should be clear at least
>to a human (but only because of the semantic knowledge that books don't have
>multiple titles).
>
>Suppose the Japanese author wishes to have separate Romanji and Kanji names
>for the US and Japan.  Use of simple repeated properties would be ambiguous,
>indistinguishable from a case of three authors.  Again use of an rdf:Alt
>container for the Japanese author makes things clear.  And use of an rdf:Bag
>or rdf:Seq container for both authors makes it clear whether there is any
>hierarchy.
>
>Alan Lillich
>Adobe Systems Incorporated.
>
>--- end forwarded text

*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Diane I. Hillmann
Metadata Specialist
National Science Digital Library Project at Cornell
Department of Computer Science  Voice: 607/255-5691
419 Rhodes Hall                         Fax: 607/255-4428
Ithaca, NY 14853                        Email: [log in to unmask]
*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*