W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > February 2009

Re: Google adds another link type

From: Simon Reinhardt <simon.reinhardt@koeln.de>
Date: Sun, 15 Feb 2009 14:24:24 +0000
Message-ID: <49982598.5050301@koeln.de>
CC: RDFa <public-rdf-in-xhtml-tf@w3.org>
Julian Reschke wrote:
> Or if they had just used HTTP's Content-Location header.

I don't really think Content-Location can be used here. That header is kind of "reserved" for conneg, i.e. if you do conneg then you can't re-use it for that purpose. Maybe the use in conneg is what you want anyway? Well, I don't really think so. In conneg you link from the generic resource to the specific resource. But don't you want the generic resource to appear in search results? After all the goal is to "merge" pagerank and all that to one URI rather than spread it to those of different formats. So I think actually you want to link the other way round, from the specific resources to the generic resource.
Content-Location also sets the base URI to the resource it links to which has an effect on relative URIs in your document. And you have to use an absolute URI for that header - which you don't have to do with rel="canonical". (Actually I often set the base URI back to the generic resource when doing conneg).
If you can live with the effect on relative URIs and having to put an absolute URI there then simply using the <base> element in HTML would have done the same trick I guess, but without the problem of Content-Location already being used for something else. But maybe those effects on URIs were already more than they wanted to expect of HTML authors. Understandable I think, better to start with a fresh solution than to overload an existing one for another purpose.

However you're right in that they shouldn't "do their own thing" but go through the standard processes instead.

Regards,
  Simon
Received on Sunday, 15 February 2009 14:26:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 15 February 2009 14:26:05 GMT