RE: Valid representations, canonical representations, and what the SW needs from the Web...

> -----Original Message-----
> From: ext Jeffrey Winter []
> Sent: 04 February, 2003 15:40
> To: Stickler Patrick (NMP/Tampere);
> Cc:;;; 
> Subject: RE: Valid representations, canonical 
> representations, and what
> the SW needs from the Web...
> > > > Or far better, 
> > > > 
> > > > GET gives you a representation of 
> > a resource
> > > > MGET gives you knowledge of a resource
> > > 
> > > I'm not sure that this is far better - making a 
> separation between 
> > > 'resource knowledge' and 'resource snapshot' seems somewhat 
> > > arbitrary.
> One problem that I see is that one person's metadata is another 
> person's data.  

I don't really think that applies here. The definition of what
metadata is in this case is pretty specific -- RDF statements
which have the resource URI as subject (providing as well for
arbitrary subgraphs of connected bnodes, terminating at literals
and urirefs). Yes, to a SW agent, that is "data". So what.
That's the point. For SW agents to get at what is data to them
without conflict with, or in spite of, what the Web considers

> One could imagine an AOP tool that would only 
> ever care about dealing with metadata; forcing it to work
> with only special methods would be overly restrictive.

I don't follow. If all it wanted to do was deal with knowledge,
*why* would it ever want to do anything else but work with
special methods optimized for dealing with knowledge?

> Also, how 
> could you ever express meta-metadata?

I don't see a problem. Presuming you mean that
meta-metadata is metadata about the terms used to express
metadata about a resource, that's easy. The terms themselves
are resources. If the metadata returned by MGET
for contained the RDF statement

   <> rdf:type <> .

and you wanted to inquire about what
meant, you'd just do an MGET on and
so forth, interatively, for any resource you needed additional 
knowledge about until satisfied (or you run out of memory ;-)

Or did you mean something else by "meta-metadata"?

> Some mechanism that binds a resource to another resource via
> a relationship expressed either through a header, or through a 
> convension applied to the OPTIONS method would seem more 
> expressive and adaptable.

Well IFF the OPTIONS method reflects the resource and not a
representation (and RFC 2616 is IMO not clear on that point)
then I could imagine it would be possible to implement the
same functionality as MGET, MPUT, and MDELETE as proposed,
but not as intuitively as distinct verbs analogous to those
used with representations.

And if the OPTIONS method reflects representations, which I
suspect it actually does, then that simply won't work. Period.



Patrick Stickler, Nokia/Finland, (+358 40) 801 9690,

Received on Tuesday, 4 February 2003 09:08:51 UTC