- From: John Black <JohnBlack@kashori.com>
- Date: Thu, 28 Dec 2006 08:36:37 -0500
- To: "Sandro Hawke" <sandro@w3.org>
- Cc: "Joshua Tauberer" <jt@occams.info>, <semantic-web@w3.org>
> > >> > This probably isn't the best way to design any real system, though. >> >> Why not? This sounds to me like the context of Instant Messaging IM, or >> text >> messaging on a cell phone. I can imagine use cases where two cell phones >> are >> set up to exchange data, one phone to another phone. >> >> I've added a new StatementContext individual to my ontology: >> "IMtoSandro". >> This is a very narrow and specific context. >> >> @prefix contexts < http://www.kashori.com/ontology/contexts.owl# > . >> @prefix ex < http://example.com# > . >> >> contexts:IMtoSandro >> a contexts:StatementContext ; >> contexts:heardByHearer contexts:SandroHawke ; >> contexts:messageRepeatability "1"^^xsd:int ; >> contexts:utteredBySpeaker contexts:JohnBlack . >> >> But within this context I can efficiently state, say in acknowledgement >> of your previous data sent: >> >> contexts:IMtoSandro { >> _:I ex:comprehend _:you . >> } >> >> In this context, http://www.kashori.com/ontology/contexts.owl#IMtoSandro >> it is understood that the message cannot meaningfully be repeated more >> than >> once. But other contexts could be defined that are closer to that of web >> page >> publication. > > I'm not saying this wouldn't work -- I haven't tried to think it through > carefully -- but it just seems like an awkward approach, like it's more > complex than necessary. When you have a technology in search of a > problem to solve, in fairness you should probably compare it to other > approaches to solving that problem. (I can't really tell what user > problem you might be trying to solve here.) This is not a case of "technology in search of a problem to solve". Tracing back through the steps that led me here, one major user problem I am trying to solve is to avoid programming my web server to return different http responses based on how I classify the referent of my URI names. To me, the above means of disambiguating an indexical with the context of its use is far less awkward than returning a 303 redirect code. I agree with Pat Hayes, the editor of RDF Semantics [1], who said of the http-range-14 solution in his presentation at IRW2006 [2], "In Defense of Ambiguity": "WebArch http-range-14 seems to presume that if a URI accesses something directly (not via an http redirect), then the URI must refer to what it accesses. This decision is so bad that it is hard to list all the mistakes in it, but here are a few. [...snip...] It uses a distinction in how a text is delivered (an http code) to disambiguate the text itself; a category mistake analogous to requiring the postman dance a jig when delivering an official letter. Since the text bears no trace of its delivery, no disambiguation is achieved by this." [3] As I was thinking about my motivation for focusing on context as a better way to deal with URI-ambiguity than WebArch http-range-14, I came up with the following suggestions that I hope further illustrate Pat's point about this being a category mistake. 1. For distinguishing URI that refer to things that do not actually exist, dead presidents, extinct species, and unicorns, for example, first return a "404 Not Found" code, then if the client requests the same URI within 0.5 seconds, return a document describing the non-existent thing. 2. For URI that refer to things that are bad for you, such as cigarettes and high fat foods, return a "403 Forbidden" code and then if they repeat the request, a document about that thing. 1. http://www.w3.org/TR/rdf-mt/ 2. http://www.ibiblio.org/hhalpin/irw2006/ 3. http://www.ibiblio.org/hhalpin/irw2006/presentations/HayesSlides.pdf John Black www.kashori.com > > -- Sandro > > >
Received on Thursday, 28 December 2006 13:36:58 UTC