- From: Mikael Nilsson <mikael@nilsson.name>
- Date: Thu, 11 Oct 2007 11:03:43 +0200
- To: Ed Davies <edavies@nildram.co.uk>
- Cc: Dan Connolly <connolly@w3.org>, www-tag <www-tag@w3.org>
tor 2007-10-11 klockan 09:18 +0100 skrev Ed Davies: > Mikael Nilsson wrote: > > ... > > It worries me slightly that we now have a mechanism for getting RDF > > information about non-info resources, but we have no way of getting > > similar information about information resources, such as > > ... > > For symmetry, WebArch would be well served if there would be a > > well-defined way to trigger such "See Other" responses. > > ... > > I think this is the same point I made in a message about > ISSUE-57 [1]. The ensuing discussion, particuarly the post > by Tim BL [2], is worth a read though, given Dan Connolly's > response [3], I'm not convinced the point has really been > made. Thanks, yes, that's exactly what I was after. Though the discussion led to a long "IR vs nonIR" later on... I'm coming at this from a pragmatic perspective, which I know is very different from the HttpRange-14 topic. The HttpPrange-14 is about (AFAIU) what a web server is supposed to answer in the non-IR case. My question comes from the other end -- What sequence of requests is a web *client* supposed to emit in order to get information *about* a resource? -- Looking at http://lists.w3.org/Archives/Public/www-tag/2007Aug/0106.html it's pretty obvious that 303's is *not* the answer to this question. Even for a non-information resource, you don't really know if you get metadata or something else. So I'm after something more predictable, dependable, and with a more precise meaning, namely: "please get me metadata for this resource". It seems to me timbl's answer in [2] makes a lot of sense - this needs to be carried in the HEAD response (which I also mentioned in my reply to DanC). I personally feel the "webarch" way to do it is to link to a *resource* carrying metadata, and where you can do content negotiation if you want. Nothing wrong with allowing a HTML representation, as long as there is a HTTP-defined relation between the original URI and the linked URI, that relation needs to say "metadata" and not just "SeeOther" / "SeeAlso". In short, +1 for timbl's Link: rel=meta suggestion. I'd encourage the TAG to produce a statement to the effect that using HTTP Link: is the right way to link to metadata for a resource. Is there a formal definition of a Link: header somewhere? I only found a mention in RFC 2068 [M1], and a note in RFC 2616 [M2]: "The [...], Link, [...] header fields were defined in previous versions of this specification, but not commonly implemented. See RFC 2068". Time to revive "Link"? /Mikael [M1] http://www.w3.org/Protocols/rfc2068/rfc2068 [M2] http://www.w3.org/Protocols/rfc2616/rfc2616.html > > Ed Davies. > > [1] http://lists.w3.org/Archives/Public/www-tag/2007Aug/0075.html > [2] http://lists.w3.org/Archives/Public/www-tag/2007Aug/0089.html > [3] http://lists.w3.org/Archives/Public/www-tag/2007Oct/0004.html > > -- <mikael@nilsson.name> Plus ça change, plus c'est la même chose
Received on Thursday, 11 October 2007 09:03:47 UTC