Re: "Hash URIs" and content negotiation

On Nov 9, 2006, at 9:09 PM, Karl Dubost wrote:

>
> Le 8 nov. 2006 à 01:32, Alan Ruttenberg a écrit :
>> On Nov 7, 2006, at 10:50 AM, Dan Brickley wrote:
>>> You're very right of course, it's problematic to conneg in  
>>> context of such URIs. This is why I always preferred slash URIs!  
>>> Ah well...
>>
>> Personally, I can't tell why content negotiation is a good idea in  
>> any context. To my mind it's hiding interesting information in the  
>> innards of a network protocol instead having it explicitly  
>> available, in say, OWL or RDF.
>

First, thanks for your comments. I've responded with some of my  
thoughts.

> because there are cases where it is difficult to do in another way.  
> Content-Negotiation is a tough issue with many faces. It is not  
> only a linear list of choices, but a multi-dimensional matrix
> 	- languages (fr, en, ja, …)

As I have pointed out, the problem is one of naming. I argue that  
these are not the "same" and so shouldn't be named the same. The  
intent is certainly that they are rdf:about the same thing. But don't  
you think that in the context of teaching people about what it would  
mean to have machines understand the web by communicating in RDF,   
conneg, in confusing the different between "x == y" and "x about z &  
y about z" undermines the cause?

> 	- format of representation (png, gif, html, …)

Unless the html has no other content than an image tag for the png or  
gif, it can not even be contemplated to be the "same". They are  
possibly both rdf:about the same thing.

> 	- format of transport (gzip)

This is the only one that seems uncontroversial to me.

> 	- …
>
> * Discoverability depending on formats
> For example, there is no obvious linking mechanism in PNG, GIF or  
> JPEG to list alternate URIs of the "same" content *inside* the  
> content. How do I say inside a PNG, that there is a GIF version.

Why can't our agents retrieve RDF (and RDF only) when they need  
discovery information like this.

Here is another proposal. Conneg is vastly simplified: For uri U, the  
only option is to retrieve RDF instead of the resource. That rdf  
would itself be given a name(URI) distinct from U. That rdf returned  
neither describes U, nor what U is about (so if U names an rdf  
document, the conneged RDF is not the same as the RDF resource U  
names). Rather it is RDF that describes the set of documents that the  
server considers relevant to serve in place of U. These can either be  
rdf:about the same subject (such as translations in different human  
languages), or same as the document, where sameas means there is a  
lossless, unambiguous, machine implementable translation between the  
two documents (same size gif->png ok gif->jpeg quality 8 not ok). The  
RDF would use some standard set of relations to describe the  
relationship of the proposed documents to U, and
various properties of these documents (like their file formats,  
languages, etc).  Based on this information, the agent can decide  
whether the original document, or some other, is relevant to retrieve  
for the task at hand. In a browser, I would expect the browser to  
show me a different URI in the address bar if an alternate document  
was chosen.

> * Keeping up to date - Cost of management
> Another issue is updating. For example, with languages, if we got  
> let's say a version of our HTML document in French, then it has  
> been translated in Japanese and Korean later on. We have to update  
> 3 files,
>
>    <link rel="Alternate"
>          href="index.html.ja"
>          hreflang="ja"
>          title="Version japonaise"/>
>
> then when we add another one, we have now to update 4 files, and so  
> on. It becomes very difficult to update.

Unless the RDF in the html says : go to xxx for a comprehensive list  
of translations of this document.

> * Wrong Content-Type
> I was wondering how the "hash uris" proposal is working in the  
> context of wrong content-type sent by the server. Is there someone  
> who played with this a bit making cases with obviously bogus files  
> and then thinking about which mechanisms, we could put in place to  
> recover or notify of the problems
>
> There is something missing which could help a Web site to expose  
> its information space map, a bit ala sitemap of Google.
>
> * On Linking Alternative Representations To Enable Discovery And  
> Publishing
>   http://www.w3.org/2001/tag/doc/alternatives-discovery
>   TAG Finding 1 November 2006
> * Transparent Negotiation - the Missing HTTP Feature
>   http://www.w3.org/QA/2006/10/missing_http_feature
>   QA Weblog 20 October 2006
> * Google Sitemap Gen
>   http://goog-sitemapgen.sourceforge.net/
>
>
> -- 
> Karl Dubost - http://www.w3.org/People/karl/
> W3C Conformance Manager, QA Activity Lead
>   QA Weblog - http://www.w3.org/QA/
>      *** Be Strict To Be Cool ***

Received on Monday, 13 November 2006 05:03:55 UTC