- From: Andy Seaborne <andy@apache.org>
- Date: Sun, 31 Jul 2016 15:30:01 +0100
- To: public-sparql-exists@w3.org
On 30/07/16 18:05, james anderson wrote:
> good afternoon;
>
>> On 2016-07-14, at 12:57, Peter F. Patel-Schneider
>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>
>> On 07/14/2016 06:19 AM, Andy Seaborne wrote:
>>> For issue 3, what the spec says and what users expect are different.
>>> [...]
>>> I'm not sure of the way to address this.
>> [...]
>>>
>>> Any other ideas?
>>>
>>> Andy
>>
>> Both expectations and behaviour here are consistent with joining a
>> single-element multiset of solution bindings to the unmodified BGP. Given
>> this, my view is that EXISTS should be defined in this way.
>>
>> That is, the pattern that is evaluated for this EXISTS should be
>>
>> Join( { { (?s, _:s1) } }, BGP(?s :p 1) )
>>
>> instead of
>>
>> BGP(_:s1 :p 1)
>
> why is this it necessary to follow an indirect path?
> why not, just admit, the process takes place on a data model rather than
> a lexical representation and leave it at that?
In spirit, I agree with you. We need to find ways in which the blank
nodes behave like ordinary constants just like an URI or literal
substituted.
BGP matching is however not part of the lexical or syntax
representation. It in the evaluation.
It so happens (and it was intentional as part of SPARQL 1.0) that
replacing blank nodes by generated variables, then treating as normal
joins gives the right answers for BGP evaluation for simple entailment
(and probably other entailments that are equivalent to expanding the
virtual graph - that does not cover OWL-DL for example).
Andy
>
>
>
> ---
> james anderson | james@dydra.com <mailto:james@dydra.com> | http://dydra.com
>
>
>
>
>
Received on Sunday, 31 July 2016 14:30:34 UTC