Example difference in LC1 and LC2 semantic framework

From:
	http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/ 
0081.html

(Jorge strikes again!)

Data (I convert back to turtlish):
	:a :p :a.
	_:x :p _:y.

SELECT * WHERE {?q :p ?q}

LC1/implementation hint:
	?q
	:a

LC2:
	?q
	:a
	_:x
	_:y

Why? Because :a :p :a simply entails _:x :p _:x and _:y :p _:y and  
the scoping set will contain both _:x and _:y (so they are legit  
values) and no coreference blocks them. This set is DISTINCT (though  
not REALLYREALLYDISTINCT).

See also:
	http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Jun/ 
0052

Everyone (well, at least andy and Fred in email above) prefers the  
smaller set of answers. Which is sensible. I note:

"""To avoid this sort of "problems" (surely there are more examples  
like the
one i showed you) in our paper we made the (strong) assumption that the
dataset is lean. I think it is a good starting point, this simplify a  
lot
the definitions in the case of simple entailment. Another more  
theoretical
form of defining a solution is that the solution must be the same *as if
the dataset were lean*, this avoid the (strong) assumption and pass the
problem to implementors... but, who cares about implementation  
anyway? ;-)"""

In this case, clearly the lean version of the graph suffices, but  
perhaps not for other cases. Oh, well, it'd give you fewer answers  
than you might expect, as in Pat's case:

	:a :p :a.
	_:x :p _:y.
	_:x :p _:x.

But ugh.

Anyway, seems clear enough. I don't imagine anyone wants three  
answers instead of the one above?  And would like to see two answers  
in the second case? If this is consensus (i.e., on the behavior) we  
can see if the specification can be fixed using the current  
framework, and whether the fixed version is worth it.

The above can be tests cases, if they haven't already been made so.

I'll note that this, again, is an issue where the name like thinking  
about BNodes conflicts with their existential variable nature. At  
least, IMHO.

Pat's suggestion:
	http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/ 
0087.html

is reasonable. I.e., the entailment based bit provides an upper bound  
on the answers (i.e., the specified answers must be a subset of the  
answers even restrictedly entailed).

In part we're seeing interaction between using entailment as the  
definition and term-distinct. Well, it's funny. If we had LC2 +  
reallyreallydistinct, then, in this case, reallyreallydistinct would  
be *cheaper* than "all" :)

Ok, I find that *waaaaaaay* to amusing.

I think we'd need to see how the constraint approach applies to RDFS.

(Personally, I still hold the bug is in the semantics of RDF/S.)

Cheers,
Bijan.

Received on Tuesday, 10 October 2006 01:29:31 UTC