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

Patrick.Stickler@nokia.com wrote,
> Miles Sabin wrote,
> > 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.

I have no problem with nameless resources, but that doesn't seem like 
the right response to the problem. And a standardized URI infix has 
many of the same problems as some of the QName -> URI mapping 
proposals.

Like I said, your response makes sense, but it's ugly and/or 
impractical.

> > > 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?

I don't see that it has any impact on REST. It only implies a change to 
the semantics of GET where both the client and the server understand 
the header. There's no impact (that I can think of) on clients, servers 
or proxies which don't understand it (eg. a server which doesn't 
understand the Meta: request header will simply ignore it and respond 
as normal; the absence of a Meta-Location: response header will inform 
the client of this fact). 

> 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.

Well, it's a representation, but a representation of something else ;-)

> > 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 ;-)

I disagree ... I think there are serious technical obstacles to 
deploying a new request method.

> > > 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 ;-)

Actually, I'd like to qualify my agreement a bit. Descriptive knowledge 
about a resource isn't _necessarily_ a representation of that resource. 
But in some cases it might be.

> > > 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.,
[snip: example]

> 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).
<snip/>

Maybe, maybe not. But the question of whether RDDL works as namespace 
metadata is orthogonal to the question of how that metadata is to be 
retrived given a namespace URI. One thing I think we both agree on is 
that an RDDL document isn't an appropriate representation of an 
abstract namespace, so an unqualified GET would be the wrong way to 
retrive it.

If you'd like to see a different Content-Type for the response then I 
have no objection.

> 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.

That seems very restrictive. Even tho' namespaces are just punctuation 
it seems reasonable to want to be able to say something about that 
punctuation (even if there's not very much interesting to say). In 
which case you might want an RDF fragment that makes assertions with a 
namespace URI as subject. And then you might what to associate that RDF 
fragement with the namespace URI as its metadata.

> 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?

See above ... a representation would be returned, but not a 
representation of the resource identified by the request URI. It'd be a 
representation of a metadata resource corresponding to the resource 
identified by the request URI, whether or not the metadata resource has 
a name of its own or not.

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

Well, it might be better to include an empty Meta-Location header in 
this case. That would allow a client to distinguish between a server 
which doesn't understand Meta and one which does but doesn't want to 
give a distinct name to the metadata.

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

I don't see why not.

> 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]

Again, I don't see why not.

Wrt this question and the previous one: in both cases you're talking 
about what the metadata is, rather than how to get hold of it. So I 
think both are orthogonal to my proposal (or your original MGET 
proposal for that matter).

> 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)?

Yes, with the proviso that a server which doesn't understand Meta will 
ignore it, and treat the PUT/DELETE as applying directly to the 
resource identified by the request URI rather than to it's metadata. As 
I said at the outset, this means that in general only GET/HEAD would be 
safe. However, I don't see why a client couldn't probe for Meta support 
via OPTIONS or HEAD or GET before attempting a Meta-qualified PUT or 
DELETE.

> 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

Err ... was this supposed to illustrate (5)?

Whatever, this looks fine to me as a Meta-qualified GET.

Cheers,


Miles

-- 
Miles Sabin
miles@milessabin.com                          http://www.milessabin.com/

Received on Wednesday, 12 February 2003 09:03:11 UTC