RE: "Hash URIs" and content negotiation

-- Alan, 

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

I don't see any reason why this strategy will not be implemented in a subset
of resources in the web. It does not inccur any conflict with Conneg, don't
you think? You can ignore the content negotiation and simply return RDF
document.  But there is no reason to "wrong" or "bad mouth" about the
approach that uses Conneg.  Conneg only adds values to, but does not take
away anything from, your proposed approach.  

But in any cases, I don't see your proposed approach is being enforced to
the entire web.  You have to remember, semantic web is an extension to, but
not an replacement of, the existing web. 

Xiaoshu

Received on Monday, 13 November 2006 14:47:12 UTC