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

Jonathan,

> ... rather than recycling a baroque protocol feature that was designed for a
> completely different purpose.

Very well, why not? :)

I'm in favour of trying our best to do this (recently started to gather
stuff, see also [1]). However, still, I guess we/the TAG needs then to say
precisely this in clear words. So, to sum up: I'm not around to fight for
CN, but to *understand* and being able to teach about CN unambiguously when
used for this purpose.

Tough, dunno if your answer, Jonathan, counts as a request in the sense of
what Noah asked for ;)


Cheers,
      Michael

[1] 
http://webofdata.wordpress.com/2009/02/14/an-attempt-of-a-web-discovery-stac
k/

-- 
Dr. Michael Hausenblas
DERI - Digital Enterprise Research Institute
National University of Ireland, Lower Dangan,
Galway, Ireland, Europe
Tel. +353 91 495730
http://sw-app.org/about.html
http://webofdata.wordpress.com/


> From: Jonathan Rees <jar@creativecommons.org>
> Date: Wed, 18 Feb 2009 14:52:23 -0500
> To: Michael Hausenblas <michael.hausenblas@deri.org>
> Cc: <www-tag@w3.org>
> Subject: Re: Question on the boundaries of content negotiation in the context
> of the Web of Data
> 
> 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 20:11:52 UTC