Re: Is 303 really necessary? (dealing with ambiguity)

On Fri, 2010-11-05 at 10:59 +0000, Ian Davis wrote:
> On Thu, Nov 4, 2010 at 10:10 PM, David Booth <david@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>. 


-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)
http://dbooth.org/

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

Received on Monday, 8 November 2010 06:28:31 UTC