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

> -----Original Message-----
> From: ext Miles Sabin [mailto:miles@milessabin.com]
> Sent: 12 February, 2003 13:59
> To: www-tag@w3.org
> Subject: Re: Proposed issue: site metadata hook (slight variation)
> 
> 
> 
> Patrick.Stickler@nokia.com wrote,
> > > * It doesn't address TimBLs "meta meta" problem.
> >
> > Not true. MGET has no "meta meta" problem.
> 
> Well, I guess we differ here. I thought that TimBLs challenge was a 
> resonable one and that your response was coherent but unconvincing.

Can you point to a particular flaw in my response? The example
approach offered might not be pretty, but certainly demonstrates
that there is no meta meta problem.

> > Can GET return anything other than a representation of the specified
> > resource? I don't think it can.
> 
> A Meta: request header would provide a way of allowing a client and a 
> server to negotiate a variation on the normal GET semantics. 

But wouldn't that require a change to the present definitions
of both HTTP and REST?

If that can be done, i.e. to formally state that the entity returned
from a GET request having the Meta: tag is *not* a representation
of the resource denoted by the URI in the GET request, fine. I could
live with that.

But *only* if it were formally specified that it was not a representation.

> There's no 
> obvious _technical_ obstacle to doing this.

Well...  I don't think there are technical obstacles to any of the 
recent proposals. It seems to all boil down to a combination of
philosophy, convenience, preference, and politics ;-)

> > And descriptive knowledge about a resource is not IMHO a
> > representation of the resource.
> 
> Agreed.

Glad to hear it. I was worried I was the only one with this view ;-)

> > And what about abstract or non-web accessible resources? If there is
> > no representation available, GET will return 404, No?
> 
> Sure, but assuming the existence of metadata, that could be 
> returned in 
> response to a Meta:-qualified GET, eg.,
> 
>   GET /some-namespace-uri HTTP/1.1
>   Host: whatever
> 
>              HTTP/1.1 404 Not found
> 
>   GET /some-namespace-uri HTTP/1.1
>   Host: whatever
>   Meta: application/rddl+xml
> 
>              HTTP/1.1 200 OK
>              Content-Type: application/rddl+xml
>              Meta-Location: 
> http://whatever/whereever/some-namespace-uri
>                 
>              ... RDDL stuff ...

Errr... bad choice of example, since XML namespaces are just
punctuation, and most/all of the knowledge expressed in a RDDL
instance associated with a namespace URI is *not* about the
namespace (the set of names).

It is particularly because of such nonsense (and I choose that
term specifically ;-) that I would like to see a formal definition
of a concise and bounded description of knowledge about the resource
(see [4] below).

Being able to ask a server about a description of a resource named
per the authority of that server removes all need for RDDL!

If you want to know what a term means, you ask about *that* term,
not for some huge document that describes *other* resources which
presumably describe the term -- but possibly in some encoding that
an RDF savvy SW agent can't understand.

No thanks...

Oh, and by the way, there are *no* namespaces on the semantic web.
Namespaces are strictly an XML convention, and RDF graphs only have
absolute URIs, not qnames.

So if you have a URI, you *can't* get to a namespace URI. You might
guess, but guessing is hardly an optimal practice to base the
very foundational architecture of the semantic web on ;-)

> Again, there's no _technical_ obstacle to this: I could build a client 
> and server with this behaviour using standard toolkits today.
  
OK, in the interest of convergence...

A few questions needing 'yes' answers in order for me to buy into this:

1. Can HTTP/REST be redefined so that GET + Meta: can return something
   other than a representation?

2. Can the Meta-Location: tag be optional, if the server owner does not care
   to name that body of knowledge explicitly?

3. Can the Meta: tag be specified with no parameter to indicate a default
   RDF/XML encoded response?

4. Can that default RDF/XML response be, by formal definition, a 
   concise/bounded description consisting only of statements having
   the specified resource as subject, and recursively, for each
   blank node object, all statements with that blank node as subject?

   [it would be *possible* to ask for and return a RDDL instance that
    is a gross superset of or even disjunct with the body of knowledge
    about the resource, but that would not be the default response]

5. Can the semantics of PUT and DELETE (at least) also be modified to
   take the Meta: tag and thus allow the manipulation of knowledge
   on the server (permissions allowing, of course)?

Thus:

   GET /some-resource-uri HTTP/1.1
   Host: whatever
   Meta:

returns
 
           HTTP/1.1 200 OK
           Content-Type: application/rdf+xml
                 
           ... concise/bounded RDF description specific to resource ...


If we can agree to all of that, I'd be a very happy camper ;-)

Cheers,

Patrick

Received on Wednesday, 12 February 2003 08:09:54 UTC