- From: David Booth <david@dbooth.org>
- Date: Mon, 08 Nov 2010 01:28:02 -0500
- To: Ian Davis <me@iandavis.com>
- Cc: "public-lod@w3.org" <public-lod@w3.org>
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