Re: Improving EXISTS

good morning;

> On 2016-07-02, at 12:40, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> On 07/01/2016 10:20 PM, james anderson wrote:
>> 
>>> On 2016-07-01, at 22:47, Peter F. Patel-Schneider <pfpschneider@gmail.com
>>> <mailto:pfpschneider@gmail.com>> wrote:
>>> 
>>> On 07/01/2016 01:34 PM, james anderson wrote:
>>>> good evening;
>>>> 
>>>>> On 2016-06-30, at 15:05, Peter F. Patel-Schneider <pfpschneider@gmail.com
>>>>> <mailto:pfpschneider@gmail.com>
>>>>> <mailto:pfpschneider@gmail.com>> wrote:
>>>>> 
>>>>> On 06/30/2016 04:50 AM, Axel Polleres wrote:
>>>>>> Dear Andy,
>>>>>> 
>>>>>> [...]
>>>>>> 
>>>>>> I have to admit I couldn't follow the whole discussion but is there a
>>>>>> mail/link which summarizes the issues (I am aware of the bnode injection
>>>>>> issue, which more there are?)
>>>>>> 
>>>>>> Thanks & best regards,
>>>>>> Axel
>>>>> 
>>>>> Hi Axel:
>>>>> 
>>>>> I don't think that there is an email that is exactly what you asked for so I
>>>>> have tried to put together a simple list of problems with EXISTS.  The first
>>>>> two problems are directly problems with the spec.  The last three are cases
>>>>> where the spec produces what can be considered to be counterintuitive results
>>>>> and some implementations diverge from the spec.
>>>>> 
>>>>> […]
>>>> 
>>>> note that, in the issue descriptions which followed, the conclusions are
>>>> subject to discussion, as they follow from interpretations of the
>>>> recommendation which are not universal.
>>>> 
>>>> best regards, from berlin,
>>> 
>>> Which conclusions and interpretations of the recommendation are not universal
>>> in this message?
>> 
>> the ones which follow from an interpretation of the recommendation’s authors
>> intent, which stipulates mechanisms which are oblivious to thirty year old
>> insights into variable capture and identifies parser and run-time data models.
>> 
>> in light of the demonstrated deficiencies of the results implied of that
>> interpretation, it may be more fruitful to explore alternatives which yield
>> results more in keeping with the recommendation’s intent.
>> a summary of the disagreement appears at the top of an early post in the thread: 
>> 
>>    https://lists.w3.org/Archives/Public/public-sparql-dev/2016AprJun/0047.html
>> 
>> best regards from berlin,
>> ---
>> james anderson | james@dydra.com <mailto:james@dydra.com> | http://dydra.com
> 
> […]
> 
> I believe that a successful attempt to produce errata to the spec that has
> general backing is going to have to start with a description of what the spec
> says that is problematic.  That is what I tried to do in my message to Axel.
> Are you saying that some of these cases are not problematic?  Are you saying
> that I said something counter to what the spec says?  If so, please say which
> parts of my message you think are incorrect.

please excuse that i repeat myself.

there is agreement, as noted in numerous messages over the past week, that the recommendation language is deficient in many regards.
in particular, with regards to exists.
as demonstrated by this thread, the language permits interpretations which, although plausible, lead to consequences which were unlikely to have been its intent.
there is agreement, that, where the intent of the recommendation is to achieve interoperability, those cases are problematic.

alternative to the “broken” interpretation, however, it is possible to read the description of exists in a way which is consistent with other aspects of the recommendation, consistent with the general state of the art of query processor implementation (see please, https://www.researchgate.net/profile/Thomas_Neumann2/publication/47863714_Scalable_Join_Processing_on_Very_Large_RDF_Graphs/links/00b7d51d1687cae740000000.pdf <https://www.researchgate.net/profile/Thomas_Neumann2/publication/47863714_Scalable_Join_Processing_on_Very_Large_RDF_Graphs/links/00b7d51d1687cae740000000.pdf>) and, which yields neither run-time type errors nor unreasonable results.

from that perspective, the definition is not “broken”.
it should be clarified.


best regards, from berlin,
---
james anderson | james@dydra.com | http://dydra.com