- From: David Booth <david@dbooth.org>
- Date: Thu, 04 Nov 2010 18:10:02 -0400
- To: "public-lod@w3.org" <public-lod@w3.org>
- Cc: Ian Davis <me@iandavis.com>
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