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

Jonathan Rees wrote:
> 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.
>   
If you conneg the URI with both HTML and RDF and I have deployed all my 
ontologies in the same way because it will cater to all kinds of users, 
whether RDF-literal or not. If you don't want to bother writing the 
human description, you could, at least, say in your HTML page that to 
know more about the house requires fluent RDF.  Then, I don't think the 
user would be disappointed.

This is what I said before that the RDF, RDFS, OWL spec should do the 
same. The meaning of rdfs:Resource is independent of the language it is 
being used to specify RDF/OWL or N3. An ordinary person should know what 
the URI means from the same URI.  But to look for some other 
specification document and then understand it.
> 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?
>   
This is another important points of making clear the role of content 
negotiation. 
(1) Currently, no browser allows a human user to select their content 
negotiation.  Firefox has a plug in.  If the role of CN is cleared, I 
believe the browser will make that some options that a user can choose. 
(2) It will also affect the design of HTML code.  The current design of 
the HTML <a> tag, for instance, seems to have a "type" attribute.  But 
it is designed for client to specify their desired type.  There is no 
semantics for the URI owner.  From what the limited knowledge that I 
have on Javascript, this cannot be done either.  (I believe Javascript 
seems can change CN the language but not format). In other words, as a 
URI owner, I can write a piece of HTML code to show a particular 
representation of the same URI.  If the role of CN is clarified, such 
behavior would/should be added to HTML, JavaScript, so that browser will 
be developed to work with them accordingly.
> 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.
>   
Description Resource Discovery is no different from Representation 
Discovery.  There are three kinds of discovery. One is implicit, i.e., 
the current model of client-directed. The second is the 
provider-directed (which is  in essence that I want to make it 
non-negotiable for a link that I write).  The third one is the 
transparent negotiation, such as those discussed in [1].   But I don't 
like [1] because the message is wrongly put in HTTP. Which should be 
expressed in a document, much more like the example that you were given. 
IMHO, transparent conneg should be done with a standard URI syntax, 
something like what I have proposed in [2]. To give it a standard URI 
syntax allows all kind of agents to perform the discovery step. That is, 
a human user would discover it very likely through HTML, an aural 
browser would probably do it by audio, and other kind of  machine agents 
would probably do it in XML, or RDF, or YAML etc.

[1]. http://www.ietf.org/rfc/rfc2295.txt
[2]. http://dfdf.inesc-id.pt/tr/uri-issues
> Jonathan
> [1] http://www.w3.org/mid/C5BA5EC1.12901%25eran@hueniverse.com
>
>

Received on Thursday, 19 February 2009 14:22:23 UTC