Re: Meta Data Redux

At 09:49 PM 3/18/97 -0800, Yaron Goland wrote:

>Ron - Generic object model based meta-data handling [...]

Is not what I am suggesting.


You seem very concerned that "overly general" solutions will take too
much time and require too much invention. You seem to think that by
"keeping it simple", namely using attribute/value headers, that the
group will be able to accomplish its task more quickly. This certainly
sounds reasonable, however, I believe it is wrong on several counts.

First, the approach I suggest does not require a massive amount of
invention. LINKs, multipart/related, media types, and existing metadata
formats can all be used.

Second, I think the attribute/value approach is going to lead you directly
into one of the IETF's most infamous ratholes - metadata hell. Here is
a rather detailed explanation of how.
 

Although the functionality of getting, setting, and deleting headers
is useful, it is not the minimum work that has to be accomplished for
interoperability. At some point this group is going to have to decide on
a minimal set of headers. Some of them, such as Content-type, Content-length,
etc. are already well-known and standardized already. Some, dealing with
distributed authoring and versioning, are unavoidably in the remit of this
group. No matter how much we wish they would go away, they are going to
come back again and again until the group reaches rough consensus. Some
of these "headers" look simple. What's so hard about "Author"? Why not
just use a comma-delimited list of strings and declare victory?

Take a look at the return address of this message. If I put my name into a
comma delimited list, it breaks. You get two authors, one of whom is my
father. Changing the delimiter character doesn't help. One of my friends
has a middle name with a ':' in it. No kidding. No doubt there are people
who have ';' or any other character you want to use in their names.
(Honesty compels me to admit that I don't usually use the ',' in my name,
but others do.)

The point of that example is not to discuss "Author", it is to warn you
that if you get into a discussion of "Author" it will not reach consensus
for a long time. This is not the first IETF group that has
thought about headers like "Author". Every time they do, all sorts of
fun sub-topics, like direct vs. sorted order, international character sets,
culture-dependent name orderings, etc. get raised. Then we get to talk about
Title and discover that there are all sorts of titles out there (former
title, translated title, main title, continued title, working title, ...);
Subject (a *total* nightmare), other forms of contribution (Editor,
Illustrator, Compiler, Translator, ...) and on and on and on. I18N and
the use of non-English attribute names will probably put in yet another
appearance during all these discussions, because they always have.
Talk about a total time sink.

Or, just maybe, we can avoid that particular rathole by acknowledging its
presence and taking a different tack. We don't specify those sorts of
headers. Instead we state that bibliographic descriptions, while of great
interest to this group, are really SEP, and we merely want to use the
product of the deliberations of those other parties. What we do is
agree on one label, perhaps "DAV.bibliographic-description", and use it
in LINKs to external resources. With multipart/related, we can send the
source document and the external description around together if we need.
We agree on a typing mechanism, namely IMTs, to allow people to use
different descriptive formats. Let the librarians define and use
application/marc, while newspapers use application/whatever-the-heck-
standard-newspapers-use. For broad interoperability in relatively simple
situations, this group "blesses" one format and schema. It might be SOIF,
it might be Dublin Core, it might be IAFA, it might be MARC for all I know.
The vendors then get to go off and do their proprietary schemes, in
order to improve on the "blessed" on in various ways. Great. Just as long
as ths group doesn't roll its own. The attempt to do so is where the
real time sink for this group lies.

With that background, let me reiterate what I said yesterday:


>1) Neither headers or separate resources meet all the requirements on
>   metadata in WEB-DAV, so we will need a combined solution.

Do you agree or disagee with that statement?

Ron Daniel Jr.              voice:+1 505 665 0597
Advanced Computing Lab        fax:+1 505 665 4939
MS B287                     email:rdaniel@lanl.gov
Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545

Received on Wednesday, 19 March 1997 13:03:53 UTC