- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Wed, 3 Oct 2007 11:15:24 +0100
- To: "Obrst, Leo J." <lobrst@mitre.org>
- Cc: Owl Dev <public-owl-dev@w3.org>
Leo, If people want to pursue this, I suggest relocating under a different thread. I'll tie this back to keys as a wrap up. On 3 Oct 2007, at 03:17, Obrst, Leo J. wrote: > Ah, I never realized this, but I think you are quite right: > > "... then all bnodes are existentially bound by quantifiers "at > infinity", > i.e. with a scope which effectively extends over the entire Web. > Which makes them indistinguishable from names, semantically." If this is true (and relevant), then there is no harm in changing the semantics to one I favor (i.e., that they *are* names). If this were true (*and* relevant), why not simply accommodate my quirkiness? In point of fact, we don't work with the quantifiers at infinity. If you want to evaluate a query, for example, the variables in the query are distinct from the variables in the dataset, and you often (always?) scope the dataset. If this were relevant, then I would have no worries. BNodes wouldn't make reasoning (and specification) so much harder. No one would or should care about using skolem constants, for example, since it wouldn't be detectable. There are always circumstances wherein you can detect a feature or a feature of a logic has impact and circumstances where it does not. In point of fact, BNode semantics have distorted such simple logics as RDFS (i.e., certain obvious entailments don't hold because of accomodations made for Bnodes...domain and range inheritance come to mind; plus, bnodes can make query answering much harder esp. in RDFS circumstances). If no one minds that we treat: s p _:x. radically differently from: s rdf:type [a owlRestriction; onProprety p; someValuesFrom owl:Thing]. (And, to be clear, we're treating them differently when considered as separate, closed graphs and testing for logical equivalence. The fact that I have to make such qualifications speaks *volumes* about this debate.) Then, frankly, I don't care *what* you call the bnode semantics. Similarly, if we allow bnode to be bound to the variables of DL Safe rules, we need to explain why there is *no* such binding in certain equivalent cases (see above). In order for the DL Safe rule semantics for keys to work for the very common foaf case, we need to explain why we can bind to _:x (or to []) but not to anything coming from owl existential quantifiers *and* to explain why this doesn't affect the various desirable properties of DL Safe rules. If the answer is "Because they are indistinguishable from 'local' names" then we must show that this is *in fact* the case in the circumstances that we face. Frankly, it's a non-trivial story given the current semantics since the above two cases are semantically indistinguishable. So this ripples throughout everything we do, making us have to do lots of work that is really unnecessary. What's the benefit? If they act like local names, let's make that *clear* by using a semantics that aligns exactly with how they act. If you use a semantics that is *stronger* than how they act in some (paradigm cases) then you are telling people who are building extensions that they should respect that semantics in circumstances where they are distinguishable. Cheers, Bijan.
Received on Wednesday, 3 October 2007 10:14:03 UTC