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

> -----Original Message-----
> From: ext Miles Sabin [mailto:miles@milessabin.com]
> Sent: 12 February, 2003 16:02
> To: www-tag@w3.org
> Subject: 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.

That's all I wanted to clarify. You seemed to be saying that
it did not sufficiently dispel the assertion that MGET had
a meta-meta problem.

I agree that it is ugly and impractical, and would expect servers
to do something more elegant, BUT note that the same issue exists
for the Meta: approach. MGET and GET+Meta: are equivalent in semantics,
and in either case, you'd have to come up with some URI to denote the
body of knowledge known about the resource, if you wanted to say anything
about it, etc.

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

Well, a *big* problem I can see is that the client won't *know* that
the server has not understood it -- unless it is a requirement that
the server always return a Meta: tag (even if empty) to indicate that
it is returning a description of the resource rather than a representation.

Still, I'd think that using MGET and getting back an explicit failure
response code would be cleaner.

Can you ask a server which tags it understands, similar to Accept: ?

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

Exactly. And we *don't* want to confuse that issue.

It needs to be crystal clear to clients that they are *not* getting
back a representation of the resource denoted by the URI of the request,
and the Meta: tag approach seems pretty weak on that point.

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

I'd love to hear them.

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

Well.... no. Not generally. But I agree there is a (very narrow) gray zone.

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

Amen.

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

Well, it's the way RDF is. You will find no namespaces in an RDF
graph that are defined as namespaces by the RDF MT, even if some
property or class might be used to assert "the resource denoted
by this URI is an XML Namespace". 

Namespaces have no meaning in RDF or RDFS.

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

If you like. But semantically, it is irrelevant. Once you get past
the misunderstanding that there is any architectural correspondence 
between namespaces, vocabularies, models, schemas, etc. then
there's little reason to say anything interesting about namespaces.

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

Well, you could also assert which characters are members of each
URI string, and for some application, that might be interesting,
but I don't think it will be of general interest to the majority
of folks on the web or semantic web...

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

Fair enough, if it is formally defined as such.

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

Well, if it is crystal clear to the client that it is getting a
representation of the body of knowledge describing the resource
rather than of the resource itself, fine. Call it Blargh: for all
I care. I just want the semantics of the response to be formally defined.

> > 3. Can the Meta: tag be specified with no parameter to indicate a
> > default RDF/XML encoded response?
> 
> I don't see why not.

That's what I presumed. But it's good to be sure.

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

I agree.

I actually see MGET and GET+Meta: as equivalent ways to capture
the same distinction between interacting with representations
versus descriptions.

The arguments for/against each seem to come down to the effort
required to change the HTTP specs and/or change HTTP servers.

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

Here's where my alarm bells go off. That would be a catestrophic
failure and a head on collision between the Web and Semantic Web.

I'm beginning to see MGET as being safer and better than GET+Meta:,
even if the latter would have been easier to implement.

It's just too dangerous and confusing and risky to mix the Web
behavior of a server with the semantic web behavior of the same
server. Best to have clear and distinct methods to differentiate
between them.
 
> 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.

No. Too risky. And again, it imposes two system calls on the agent,
one to see if the server is semantic web enabled and the second
to actually get the metadata -- for *every* call. Nope. No thanks.

Sorry, I return to my MGET proposal. Using GET, PUT, etc. is simply
too troublesome and risky. And that's based simply on the few
pitfalls identified above regarding misunderstanding by either
server or client.

By using new, semantic web specific methods, it is safe and clear
if the server understands the semantic web extensions and will
behave accordingly.

The Web and Semantic Web are two distinct sides of the same
coin, and trying to force them onto the same side is just going
to give us all premature gray hair.

Patrick

--
Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com

Received on Wednesday, 12 February 2003 10:06:56 UTC