RE: Meta Data Redux

>>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 disagree with that statement?

I disagree. I believe that my proposal, which handles what Jim Whitehead
has called "small chunk" meta-data, will completely meet the DAV group's
needs. While I do believe that there is a strong need for a richer
meta-data system I also believe that this group can produce a useful,
fully interoperable standard, with nothing more than LINK/UNLINK and the
META* methods.

		Yaron

> -----Original Message-----
> From:	Ron Daniel, Jr. [SMTP:rdaniel@acl.lanl.gov]
> Sent:	Wednesday, March 19, 1997 10:00 AM
> To:	Yaron Goland; w3c-dist-auth@w3.org
> Subject:	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 17:33:44 UTC