Re: problem with blank nodes in EXISTS solution mappings

I believe that the intuitive model that most users have is that blank 
nodes in the data are concrete RDF terms like URI and literals.

SPARQL could/should have been defined to reflect that - i.e. based on an 
algebra throughout.

An active community wanted something else but it has turned out that a 
majority of real users have not engaged with that idea.

     Andy

On 17/06/16 01:39, Jeremy J Carroll wrote:
> I agree with the intuitive understanding but as a user, I prefer if the specification supports me when I am disappointed in a vendor’s implementation.
>
> I think Peter is calling out that in this particular case, it does not.
>
> Jeremy
>
>
>
>
>> On Jun 16, 2016, at 5:08 PM, Gregory Williams <greg@evilfunhouse.com> wrote:
>>
>> On Jun 16, 2016, at 4:32 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>>
>>> So consider
>>> BGP( _:x :p ?y )
>>> against the active graph G = { :s :p _:x . }
>>>
>>> The RDF instance mapping is σ = { ( _:x, :s ) }.
>>> The solution mapping is μ = { ( y, _:x ) }.
>>> The pattern instance mapping is P = { ( _:x, :s ), ( y, _:x ) }.
>>> This is a solution because P( _:x :p ?y ) = (:s :p _:x) which is a subgraph
>>> of G.
>>>
>>> The point is that the _:x that came from the EXISTS substitution is a blank
>>> node and can be itself substituted for in the RDF instance mapping.  This is
>>> counter to what I think is the desired meaning for EXISTS.
>>>
>>> Note that this is all just a little bit sloppy.  To make it all precise
>>> would require an extra injection from blank node names to real blank nodes
>>> but this extra precision doesn't make any difference here.
>>
>> That’s an interesting case. I haven’t gone through the definitions in depth in a while, but I think you’re right that the discussion of matching BGPs in §18.3 and the evaluation semantics of EXISTS in §18.6 probably don’t do the expected thing. The existing errata surrounding EXISTS evaluation shows that this was an area where the spec fell a bit short.
>>
>> Do you have a system that is actually giving you the results you describe?
>>
>> My intuitive understanding, and one which I suspect most if not all implementations use, is that the “blank nodes” that §18.3 references are the syntactic blank nodes in the *query*, and shouldn’t apply to blank nodes that come from the *data* that are used in an EXISTS filter evaluation. Unfortunately, I don’t think there’s any way for substitute() to express a (non-syntactic) blank node in the algebraic representation.
>>
>> Does that align with what you think the expected behavior is?
>>
>> thanks,
>> .greg
>>
>>
>
>

Received on Friday, 17 June 2016 10:00:06 UTC