RE: Proposed issue: site metadata hook (slight variation)

> -----Original Message-----
> From: ext David Jacobs [mailto:djacobs@mitre.org]
> Sent: 12 February, 2003 19:28
> To: Stickler Patrick (NMP/Tampere)
> Cc: Costello,Roger L.
> Subject: Re: Proposed issue: site metadata hook (slight variation)
> 
> 
> Patrick.Stickler@nokia.com wrote:
> 
> >The Web methods GET, PUT, etc. enable you to interact
> >with the book.
> >
> >The SW methods MGET, MPUT, etc. enable you to interact
> >with the description of the book, with the card from
> >the card catalog, so to speak.
> >
> >If you *want* to give that card its own name, fine, but
> >usually folks just say "the card for book X". It's
> >normal behavior to refer to such bodies of knowledge
> >indirectly. That doesn't mean you have to, but it's
> >reasonable for the default mode of operation to do so.
> >  
> >
> IMHO, two aspects get lost by using the MGET, MPUT, etc for 
> retrieving 
> metadata.
> 
> I would argue that sometimes metadata about metadata is 
> required (e.g., 
> quality assertions about metadata assertions) .  This is why metadata 
> should be a first class citizen (i.e., have its own URI).

Ummm, but surely this is metadata about each assertion, not
about documents containing assertions.

And RDF has means to express such metadata about assertions.

And even if you wished to make the statements about the document,
there is no reason why a server *can't* provide a URI to denote
the body of knowledge returned by an MGET. It's just not
manditory.

> Secondly, there is a tremendous amount of metadata which would be 
> qualified as opinions (e.g., think of Moody bond ratings).  
> Furthermore, 
> metadata about a resource is often created by third parties 
> (i.e., not 
> the owner/publisher of the resource).

True, and there are other solutions needed for such extra-authority
assertions.

I've been working on just such a solution, called URIQA. See my
comments about it earlier in this thread.

> These were the reasons Roger Costello and I argued for adding the 
> Meta-Location and Meta-About HTTP headers.  Which support 
> those aspects.

But so does MGET. It simply doesn't *require* them. Thus it is
both more efficient and more flexible.

Cheers,

Patrick

Received on Wednesday, 12 February 2003 13:31:46 UTC