« Return to Thread: Splitting vs. Interpreting
Sean B. Palmer wrote:Sorry, looks like I had an old address on file for you.---------- Forwarded message ----------From: Sean B. Palmer <sean@...>Date: Tue, Jun 16, 2009 at 8:23 PMSubject: Splitting vs. InterpretingTo: David Booth <dbooth@...>Cc: www-tag@...You write about ambiguous and specific references here:http://dbooth.org/2007/splitting/When I worked on EARL in 2002, we had to solve httpRange-14, and wedid it in a practical way which your splitting document reminds me of.We might want to evaluate a tool of some kind in EARL, say the W3CValidator. But then we didn't know whether validator.w3.org was thetool itself or a page about the tool. That's httpRange-14 in anutshell, before it was “solved” with the 303 hack.So what we did was this:<http://validator.w3.org/> earl:tool _:Validator .The clever bit is that the earl:tool property says: if the subject isa Document (i.e. an IR), then the object is the Tool described by thatdocument; whereas if the subject is a Tool, then the object is simplythe same thing as the subject.The solution is cleaver only because it pushes the ball to someone else. But it does not solve any problem at all. Whoever is to deploy the resource is still burdened with the impossible question: is what s/he is about to deploy is a Document or not because she needs the answer to know if s/he should 200 or 303. Or she needs
The real issue is that TAG, for whatever reason that I cannot understand, refuses to acknowledge such a simple truth: what you get from a URI is NOT what a URI denotes.
We never know what a URI denotes -- it is our purpose to share that knowledge. But the sharing is achieve from sharing what we get from the URI.
*Document* is what we get from a URI but *resource* is not. I have argued this in the past as well as in the upcoming paper at IR-KR2009 (http://ir-kr.okkam.org/workshop-program/ir-kr-ijcai-09-program).
Once we understand the above distinction. The remedy is simple. We need to solve it *syntactically* by using a URI convention to denote what is we get from a URI, which I have proposed in another manuscript to ISWC 2009 (which fate I don't know).
XiaoshuAnd as you can imagine, this is extensible to interpreting ambiguousresources in all kinds of ways. Now the TAG finding says that it'sremoved a certain level of ambiguity, but there are other ambiguitiesone might want to resolve when a page 303s and then still doesn'tdefine carefully what's at the end of it. So the EARL method is muchmore practical.You might also want to think a bit harder about statements such as“there is no architectural need for Person and IR to be considereddisjoint”. Consider if you were using Facebook and it startedconflating people with groups and games and so on. But of coursepeople break the rules of the web until they matter, and since there'sno Semantic Web User Agent this rule doesn't matter.I'm not saying that the TAG finding should be canned because you canuse the kind of interpretation properties that I've described as a wayaround it. The point is rendered moot by various architecturalproblems. But you ought to compare the 2002 and 2009 architecturalsolutions carefully.
« Return to Thread: Splitting vs. Interpreting
| Free embeddable forum powered by Nabble | Forum Help |