Re: [TF:DbE] The easiest keys there are

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