atom feed151 messages in org.w3.public-lodRe: Is 303 really necessary? (dealing...
FromSent OnAttachments
82 earlier messages
Ian DavisNov 5, 2010 4:02 am 
NathanNov 5, 2010 4:15 am 
Mischa TuffieldNov 5, 2010 4:47 am 
Norman GrayNov 5, 2010 5:11 am 
Dave ReynoldsNov 5, 2010 5:38 am 
NathanNov 5, 2010 5:52 am 
NathanNov 5, 2010 5:57 am 
Vasiliy FaronovNov 5, 2010 6:00 am 
Vasiliy FaronovNov 5, 2010 6:33 am 
NathanNov 5, 2010 7:18 am 
David WoodNov 5, 2010 7:18 am 
Pat HayesNov 5, 2010 7:27 am 
Ian DavisNov 5, 2010 8:12 am 
Kingsley IdehenNov 5, 2010 8:18 am 
NathanNov 5, 2010 8:40 am 
Kingsley IdehenNov 5, 2010 9:36 am 
Pat HayesNov 5, 2010 10:29 am 
Kingsley IdehenNov 5, 2010 10:31 am 
NathanNov 5, 2010 10:37 am 
Hugh GlaserNov 5, 2010 10:50 am 
David BoothNov 6, 2010 1:42 pm 
Norman GrayNov 6, 2010 3:45 pm 
Kingsley IdehenNov 6, 2010 4:08 pm 
David BoothNov 7, 2010 10:27 pm 
David BoothNov 7, 2010 10:28 pm 
Tore ErikssonNov 7, 2010 11:18 pm 
Toby InksterNov 8, 2010 12:37 am 
Toby InksterNov 8, 2010 2:11 am 
David BoothNov 8, 2010 6:40 am 
David BoothNov 8, 2010 6:42 am 
Norman GrayNov 8, 2010 7:51 am 
Toby InksterNov 8, 2010 8:03 am 
David BoothNov 8, 2010 12:34 pm 
Lars HeuerNov 8, 2010 1:17 pm 
David BoothNov 8, 2010 1:35 pm 
Dave ReynoldsNov 8, 2010 1:50 pm 
David BoothNov 8, 2010 3:34 pm 
Tore ErikssonNov 8, 2010 5:51 pm 
Dave ReynoldsNov 9, 2010 6:36 am 
Lars HeuerNov 9, 2010 8:00 am 
Kjetil KjernsmoNov 10, 2010 7:13 am 
Jason BorroNov 11, 2010 11:47 am 
David BoothNov 18, 2010 2:10 pm 
Kingsley IdehenNov 19, 2010 4:26 am 
David BoothNov 19, 2010 1:55 pm 
Kingsley IdehenNov 19, 2010 2:07 pm 
NathanNov 19, 2010 2:57 pm 
Kingsley IdehenNov 19, 2010 5:55 pm 
Bob FerrisNov 26, 2010 6:15 am 
NathanNov 26, 2010 6:30 am 
19 later messages
Subject:Re: Is 303 really necessary? (dealing with ambiguity)
From:David Booth (dav@dbooth.org)
Date:Nov 7, 2010 10:28:02 pm
List:org.w3.public-lod

On Fri, 2010-11-05 at 10:59 +0000, Ian Davis wrote:

On Thu, Nov 4, 2010 at 10:10 PM, David Booth <dav@dbooth.org> wrote:

2. only one description can be linked from the toucan's URI

True, but that's far better than zero, if you only have the toucan URI and it returns 404!

It could return 204.

I don't understand where you're going with that. How would a 204 permit more than one description to be linked from the toucan's URI?

3. the user enters one URI into their browser and ends up at a different one, causing confusion when they want to reuse the URI of the toucan. Often they use the document URI by mistake.

Yes, that's a problem. The trade-off is ambiguity.

I don't think so. The ambiguity is not present because the data explicitly distinguishes the two URIs (and content-location header does too).

I would say that the ambiguity *has* been created, but your heuristic (of looking at the provenance of whether the information came from the HTTP response code permits that ambiguity to be resolved.

There are millions of people that use URIs to identify billions of web pages, and the vast majority have never heard of RDF. If your toucan URI returns a 200 response just like billions of other URIs then it *does* identify a web page, even if you are also using that URI in some RDF document to identify a toucan -- a document that would just be gobbledygook to most of the world. And others may well make statements about that web page. For example, someone crawling the web may make a statement saying that <http://iandavis.com/2010/303/toucan> returned 1027 bytes in response to a GET request. They may not say it in RDF -- they might say it in XML or any other language. (Indeed, they may know nothing about RDF.) But they still use http://iandavis.com/2010/303/toucan to identify the web page, and no amount of RDF can change that fact. Furthermore, their statements may eventually be translated to RDF -- perhaps by someone else -- and merged with other assertions that use <http://iandavis.com/2010/303/toucan> to refer to the toucan.

So I don't think it is reasonable or realistic to think that we can *avoid* creating an ambiguity by returning additional RDF statements with the 200 response. Rather, the heuristic that you propose is a way for applications to *deal* with that ambiguity by tracking the provenance of the information: if one set of assertions was derived from an HTTP 200 response code, and another set of assertions was derived from an RDF document that you trust, then ignore the assertions that were derived from the HTTP 200 response code.

7. it mixes layers of responsibility - there is information a user cannot know without making a network request and inspecting the metadata about the response to that request. When the web server ceases to exist then that information is lost.

I don't buy this argument. While I agree that explicit statements such as

<Utoucan> :isDescribedBy <Upage> .

is helpful and should be provided, that does *not* mean that links are not *also* useful. Just because links do not *always* work does not mean that they are useless.

But you agree that under the current scheme, some things are knowable only by making a network request. It's not enough to have just the RDF description document?

Sorry, I may have been unclear. I *do* think that if the client app already has enough RDF data about <Utoucan> then the client app should not waste a network access dereferencing Utoucan.

However, I think the URI owner of Utoucan *should* still make Utoucan dereferenceable (either directly or indirectly) to RDF data, because this may be useful to the client app for cases when it either doesn't have sufficient RDF data about <Utoucan> or if it wishes to verify that it has the correct or current RDF data about <Utoucan>.

Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.