Re: Semantic Web Statement Contexts (was: Can there be a URI for the concepts "I", "you",...)

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