W3C home > Mailing lists > Public > www-tag@w3.org > February 2009

Re: Question on the boundaries of content negotiation in the context of the Web of Data

From: Jonathan Rees <jar@creativecommons.org>
Date: Wed, 18 Feb 2009 14:52:23 -0500
Cc: <www-tag@w3.org>
Message-Id: <2CD4ED21-1403-470D-B7C1-58F85BCD1CE3@creativecommons.org>
To: Michael Hausenblas <michael.hausenblas@deri.org>
I guess the practical problem I see with conneg-to-RDF delivering  
information that's not the same information as what's in other  
representations is that a user who has configured their browser to  
prefer RDF is not going to see the information that a typical  
referring page meant for him/her to see.

That is: The referring page says:

Notice the exquisite shape of the porch on <a href="U">my neighbor's  
house</a>.

and I go to U, and my browser gives a beautiful rendition of a pile of  
RDF that talks about the address of the house, who lives in it,  
latitude/longitude, links to mapping services and building permits and  
so on.  I can read the RDF because it's rendered nicely, I'm fluent in  
it, I can run an inference engine to determine whether it's logically  
consistent, I can do SPARQL queries, I can follow my nose and so on --  
this is why I give a higher priority to RDF when I conneg - but I  
can't for the life of me figure out what the porch looks like, because  
that information only lives in a different representation. I have been  
gratuitously deprived of information that I wanted.

Did the agent composing the referring page do something wrong? No -  
you're supposed to be able to link (or bookmark) casually like this,  
without first doing a detailed study of the target's conneg behavior -  
that's a fundamental design goal of the web.

Is the user agent shooting themselves in the foot by preferring RDF to  
PNG? I don't see why. It can handle both, and if the same information  
is available in both forms, why should either it, the server, or the  
referring page care what it gets?

Now you may argue that certain agents will have a difficult time using  
the image at all, so delivering RDF in this case is OK - but this is  
not the case I'm talking about. In order for the above scenario to  
work, each resource has to make a best effort to provide, with the  
help of or in spite of CN, the information that referrers are likely  
to desire the referee to see. So conneg between an image and any text- 
only format is a very iffy proposition. You'd have to make sure the  
text was carefully constructed in a way that would be useful to  
someone who thought they were being directed to an image (or someone  
who is being referred by a referrer who thinks they're being directed  
to an image) - maybe by linking to the image (really), with some kind  
of apology.

My 2 cents: Instead of CN I would use description resource discovery  
[1], when that becomes ready, and have that lead to a description, in  
RDF, of exactly what you think is going on - all the resources that  
are nearby (image, RDF source, mail message, UI, etc.), their types,  
and their relationships to one another. Then you can use different  
URIs for different things and say what you mean directly rather than  
recycling a baroque protocol feature that was designed for a  
completely different purpose.

Jonathan
[1] http://www.w3.org/mid/C5BA5EC1.12901%25eran@hueniverse.com
Received on Wednesday, 18 February 2009 19:53:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:12 GMT