Re: Is 303 really necessary?

Hi Ian,

You raise two issues: 1. Whether there is need to use different URIs for
the toucan versus the toucan's web page; and if so (2) how to get from
one URI to the other.

ISSUE 1: Whether there is need to use different URIs for the toucan
versus the toucan's web page.  Some time ago I showed that there is no
*architectural* need to distinguish between the two:
http://dbooth.org/2007/splitting/
(Sorry that page is a bit messy, but the reasoning is sound.)  The
essential reason is that the ambiguity created by using the same URI for
both is not fundamentally different from the ambiguity that *always*
exists when a resource is defined.  Ambiguity depends on the
application: a description (or "URI declaration") that is perfectly
unambiguous to one application may be ambiguous to another application
that needs to make finer distinctions.

For a fairly clear explanation of how ambiguity works in RDF semantics,
see "Resource Identity and Semantic Extensions: Making Sense of
Ambiguity":
http://dbooth.org/2010/ambiguity/

However, given that many applications *will* wish to distinguish between
the toucan and its web page (or between the toucan's age and the age of
it's web page), it is a *good* *practice* to use a different URI for
each, as recommended, for example, in both the W3C Architecture of the
World Wide Web:
http://www.w3.org/TR/webarch/#URI-collision 
and in Cool URIs for the Semantic Web:
http://www.w3.org/TR/cooluris/#distinguishing 

ISSUE 2: How to get from the URI of the toucan to the URI of the
toucan's web page.  You state that "we should link the thing to its
description using a triple rather than a network response code".  While
I agree 100% that a triple like 

  <Utoucan> :isDescribedBy <Upage> .

is far more efficient than a network response code, and *should* be used
when available, it is *also* useful to make the Utoucan URI
dereferenceable for those times when: (a) you have Utoucan but not that
triple; or (b) you wish to verify that Upage *is* the correct page for
the Utoucan declaration.

Also please note that if you mint your URIs using a 303-redirect service
such as http://thing-described-by.org/ then the extra network hop from
the 303 redirect could be optimized away by parsing the URI, as
described here:
http://thing-described-by.org/#optimizing
For example, you would have the relationship:

  <http://t-d-b.org/?http://example/toucan-page>
      :isDescribedBy
           <http://example/toucan-page> .

so if the toucan were denoted by the URI
http://t-d-b.org/?http://example/toucan-page
the you know that its description is located at
http://example/toucan-page
and there is no need to actually dereference the other URI.

Your blog post states:
> http://iand.posterous.com/is-303-really-necessary 
> There are several disadvantages to the 303 redirect 
> approach:
>  1. it requires an extra round-trip to the server for
>every request

Not if you use a 303-redirect service such as
http://thing-described-by.org/ and optimize them
away as described at
http://thing-described-by.org/#optimizing

>  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!

>  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.

>  4. its non-trivial to configure a web server to issue
>the correct redirect and only to do so for the things that
>are not information resources.

It is trivial to mint your URIs if you use a 303-redirect 
service such as
http://thing-described-by.org/ 

>  5. the server operator has to decide which resources
>are information resources and which are not without
>any precise guidance on how to distinguish the two (the
>official definition speaks of things whose "essential
>characteristics can be conveyed in a message"). I enumerate
>some examples here but it's easy to get to the absurd.

I addressed the server configuration issue above, but
the other issue -- how do I know whether something
should be considered an "information resource" or
not -- does cause confusion.  But in fact it boils
down to the inherent problem of ambiguity that will
never go away: what's ambiguous to one application
may be ambiguous to another application that requires 
finer distinctions.

>  6. it cannot be implemented using a static web server
>setup, i.e. one that serves static RDF documents

Agreed, but it can be done using a standard service, as
mentioned above.

>  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.

>  8. the 303 response can really only be used with
>things that aren't information resources. You can't serve
>up an information resource (such as a spreadsheet) and
>303 redirect to metadata about the spreadsheet at the
>same time.

Of course you can, but you do it the opposite way:

  UspreadsheetMetadata  --303--> Uspreadsheet

Or in RDF:

  <Uspreadsheet> :isDescribedBy <UspreadsheetMetadata> .

>  9. having to explain the reasoning behind using 303
>redirects to mainstream web developers simply reinforces
>the perception that the semantic web is baroque and
>irrelevant to their needs.

Yes, that is a problem.



-- 
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 Thursday, 4 November 2010 22:10:32 UTC