On Nov 11, 2010, at 8:00 AM, David Booth wrote: > On Thu, 2010-11-11 at 07:23 +0100, Jiří Procházka wrote: > [ . . . ] >> I think it is flawed trying to enforce "URI == 1 thing" > > Exactly right. The "URI == 1 thing" notion is myth #1 in "Resource > Identity and Semantic Extensions: Making Sense of Ambiguity": > http://dbooth.org/2010/ambiguity/paper.html#myth1 > It is a good *goal*, but it is inherently unachievable.
Well, no, careful. It is unachievable IF the only means we have to pin down a referent is to describe it. But that isn't the only way we have. In the 'real' world of ordinary language we often have the possibility of ostention. Q: "What do you mean by 'froogle'?" A: "This, here in my hand, this is a froogle" spoken while brandishing a teaspoon, say, leads to the hypothesis that 'froogle' means teaspoon, or at any rate some category which overlaps teaspoons. Arguably, this is at the root of how we learn language in the first place. (After all, if Quine were right about the indeterminacy of translation - 'gavagai' and all that - then it would be *impossible* to learn a language; and yet we all do it.) What http-range-14 does can be seen as allowing conventional HTTP GETting to be a form of ostention. If an http: IRI succeeds in GETting a representation of something with a 200 code attached, then that's the Web saying, in effect, A: "What I mean by <IRI> is this thing here" while it - the Web - is doing the closest it can GET to brandishing something, ie delivering you a Web awww:representation of it. (The question "What do you mean by <IRI>?" was your GET request, by the way, and a 303 response is the Web saying "I have no idea.") Since the identification performed by HTTP GET is indeed unambiguous and unique, just as holding and waving a teaspoon is, this really does succeed in unambiguously identifying something. Just as with holding and waving, it only works with some things. You can't hold and wave, or HTTP GET, a galaxy or a dead Roman emperor. But when it does work, it delivers unambiguous reference. And just as out here in the human linguistic world, we have evolved techniques for building on the near-at-hand examples to pin down relatively unambiguous referents for other things that are more remote, maybe we can start to do the same on the Web. It's a start, anyway. Pat > >> by some >> system (especially if you want to maintain RDF as one of supported >> structured data formats (I dare to say the major one)), as nothing can >> be completely unambiguous (in RDF) - that is something the publisher >> needs to keep in mind and work towards to. > > Right. And believe it or not, the RDF Semantics *already* accounts for > this inherent ambiguity by noting that an RDF graph will normally have > multiple interpretations. (An "interpretation" of a graph in RDF > semantics is a mapping from its URIs to resources.) To quote from the > RDF Semantics: > http://www.w3.org/TR/rdf-mt/#interp > [[ > Notice that there is no presumption here that any assertion contains > enough information to specify a single unique interpretation. It is > usually impossible to assert enough in any language to completely > constrain the interpretations to a single possible world, so there is no > such thing as 'the' unique interpretation of an RDF graph. > ]] > > For a fairly clear explanation of how this works, see "Resource Identity > and Semantic Extensions: Making Sense of Ambiguity": > http://dbooth.org/2010/ambiguity/paper.html > > The important thing to keep in mind is that ambiguity is *relative* -- > it depends on the application. An application that does not need to > differentiate the toucan from its web page will still produce correct > answers even if it uses a URI the ambiguously denotes both. However, > another application that needs to associate a different :hasOwner > property value with the toucan than the web page will need to use a > different URI for each. > > > > -- > 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. > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
