W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2011

Re: draft response MK-1 (Fwd: Proposal for simplifying FILTER semantics)

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Fri, 06 May 2011 15:17:38 +0100
Message-ID: <4DC40302.9070604@epimorphics.com>
To: public-rdf-dawg@w3.org
Looks fine to me.

	Andy

On 06/05/11 13:11, Axel Polleres wrote:
> Any support for sending out the modified
>     http://www.w3.org/2009/sparql/wiki/index.php?title=CommentResponse:MK-1
> which should address both
>    http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011May/0000.html
> and
>    http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011May/0003.html
> ?
>
> thanks,
> Axel
>
> On 3 May 2011, at 13:51, Axel Polleres wrote:
>
>> I didn't send that yet, since Markus sent another comment in between.
>> I edited the answer to a combined answer for both comments.
>>
>> the main thing I changed was pointing out that his propose to change the semantics affects backwards compatibility, which our charter forbids.
>> This also addresses Andy's point 1/ below. As for points 2/ - 5/,  though I do appreciate
>> the additional thoughts, I think they don't need to be mentioned explicitly in the reply.
>>
>> Please let me know whether ok with the modified reply
>>   http://www.w3.org/2009/sparql/wiki/index.php?title=CommentResponse:MK-1
>>
>> best,
>> Axel
>>
>> On 2 May 2011, at 20:29, Andy Seaborne wrote:
>>
>> 5/
>>> And fairly obviously, it changes queries using bound().
>>>
>>>          Andy
>>>
>>> On 02/05/11 17:16, Axel Polleres wrote:
>>>> thanks andy,  fair points, let me know if you want to edit any of those into the draft reply,
>>>> otherwise, I'd send tomorrow whatever I find on the wiki then.
>>>>
>>>> best,
>>>> Axel
>>>> On 2 May 2011, at 16:34, Andy Seaborne wrote:
>>>>
>>>>> Fine although I'd note:
>>>>>
>>>>> [[Comment:
>>>>> I am aware that this proposal comes at a very late stage, but I think it is still feasible to do it.
>>>>> ]]
>>>>>
>>>>> 1/ Worth pointing out that this is outside the charter of the WG - the web page notes it but trivialises it.
>>>>>
>>>>> 2/ He raised this on the 4store list where it was pointed out that
>>>>>
>>>>> :locatedIn+
>>>>>
>>>>> would work.  That only addresses the specific example, but then much of argument seems to be that messy data leads to messy queries.
>>>>>
>>>>> 3/ Inference can address "locatedIn" as a transitive relationship.
>>>>>
>>>>> 4/ DAWG did consider binding filters.  The style in the spec was preferred.
>>>>>
>>>>>       Andy
>>>>>
>>>>> PS The proposal, as I understand it, returns junk answers if it can bind to anything in the graph that might solve the filter.  It confuses a common optimization technique with language design.
>>>>>
>>>>> On 02/05/11 15:28, Lee Feigenbaum wrote:
>>>>>> I agree with this response.
>>>>>>
>>>>>> Lee
>>>>>>
>>>>>> On 5/2/2011 9:02 AM, Axel Polleres wrote:
>>>>>>> I drafted a response for this
>>>>>>>
>>>>>>> http://www.w3.org/2009/sparql/wiki/CommentResponse:MK-1
>>>>>>>
>>>>>>> Axel
>>>>>>>
>>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>> *From: *Markus Krötzsch<markus.kroetzsch@comlab.ox.ac.uk
>>>>>>>> <mailto:markus.kroetzsch@comlab.ox.ac.uk>>
>>>>>>>> *Date: *2 May 2011 14:00:12 GMT+01:00
>>>>>>>> *To: *"Polleres, Axel"<axel.polleres@deri.org
>>>>>>>> <mailto:axel.polleres@deri.org>>
>>>>>>>> *Subject: **Re: Proposal for simplifying FILTER semantics*
>>>>>>>>
>>>>>>>> On 02/05/11 13:39, Axel Polleres wrote:
>>>>>>>>>
>>>>>>>>> On 2 May 2011, at 10:53, Markus Krötzsch wrote:
>>>>>>>>>
>>>>>>>>>> On 01/05/11 20:40, Polleres, Axel wrote:
>>>>>>>>>>> OfflIist: warum funkt BIND fuer deinen use case nicht?
>>>>>>>>>>
>>>>>>>>>> Fuer FILTER "=" koennte das eventuell funktionieren (fuer andere
>>>>>>>>>> Funktionen natuerlich nicht, aber da ist auch die praktische
>>>>>>>> Motivation
>>>>>>>>>> nicht so stark). Was mir da nicht so klar waere ist allerdings wie
>>>>>>>> man
>>>>>>>>>> BINDINGS disjunktiv mit (Sub-)Queries kombinieren wuerde. So wie
>>>>>>>> ich die
>>>>>>>>>> Semantik verstehe werden sie immer konjunktiv mit dem
>>>>>>>> GroupGraphPattern
>>>>>>>>>> verbunden. Man haette dann also wieder das gleich Problem, eine
>>>>>>>>>> Disjunktion zwischen der Gleichheit mit den Bindings (FILTER) und
>>>>>>>>>> etwaigen anderen Patterns (BGP) im WHERE-Teil auszudruecken.
>>>>>>>>>
>>>>>>>>> ja, aber das geht doch mit EXISTS im FILTER (auch ein neues feature
>>>>>>>> in SPARQL1.1, dass genau deinen use case abzudecken scheint... nicht?)
>>>>>>>>
>>>>>>>> Das habe ich noch nicht gefunden -- wo ist denn die Semantik von EXISTS
>>>>>>>> definiert?
>>>>>>>>
>>>>>>>> Markus
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From:
>>>>>>>> public-rdf-dawg-comments-request@w3.org<public-rdf-dawg-comments-request@w3.org
>>>>>>>>
>>>>>>>> <mailto:public-rdf-dawg-comments-request@w3.org>>
>>>>>>>>>>> To:
>>>>>>>> public-rdf-dawg-comments@w3.org<public-rdf-dawg-comments@w3.org
>>>>>>>> <mailto:public-rdf-dawg-comments@w3.org>>
>>>>>>>>>>> Sent: Sun May 01 20:29:37 2011
>>>>>>>>>>> Subject: Proposal for simplifying FILTER semantics
>>>>>>>>>>>
>>>>>>>>>>> Dear WG,
>>>>>>>>>>>
>>>>>>>>>>> when working with SPARQL recently, I noticed that certain
>>>>>>>> disjunctive
>>>>>>>>>>> queries are most cumbersome/inefficient to formulate due to the
>>>>>>>> special
>>>>>>>>>>> post-processing semantics of FILTER expressions. I have written up a
>>>>>>>>>>> detailed explanation [1]. In a nutshell: it is *really* hard to
>>>>>>>> combine
>>>>>>>>>>> FILTERs and BGPs in disjunctions.
>>>>>>>>>>>
>>>>>>>>>>> But the problem has a simple fix:
>>>>>>>>>>>
>>>>>>>>>>> * Define FILTER in such a way that it can *create* new solution
>>>>>>>>>>> mappings, just like BGP. A FILTER would create all variable
>>>>>>>> bindings (to
>>>>>>>>>>> terms from the active graph) that make the filter condition true.
>>>>>>>>>>> * Instead of applying filters after matching, the generated solution
>>>>>>>>>>> mappings of a FILTER would directly be joined with other parts of
>>>>>>>> the query.
>>>>>>>>>>>
>>>>>>>>>>> Putting it like this simplifies the whole algebra, both formally and
>>>>>>>>>>> conceptually. Moreover, I think that practical implementation are
>>>>>>>>>>> already working like that anyway (using FILTER conditions such as
>>>>>>>> "=" to
>>>>>>>>>>> pre-generate results instead of waiting until the very end before
>>>>>>>>>>> "checking" them).
>>>>>>>>>>>
>>>>>>>>>>> The only negative effect that I see is that this would change the
>>>>>>>>>>> meaning of variables that occur in filters but in no BGP. Currently,
>>>>>>>>>>> such variables are considered "unbound". With the change, they
>>>>>>>> would be
>>>>>>>>>>> instantiated to all terms that match. Experimenting with FILTER-only
>>>>>>>>>>> variables in some RDF stores, I merely got error messages (and
>>>>>>>> rightly
>>>>>>>>>>> so, since a variable that can never be bound is of little use in a
>>>>>>>>>>> filter). So I assume that this is a corner case of little practical
>>>>>>>>>>> relevance.
>>>>>>>>>>>
>>>>>>>>>>> AFAICT, all other queries would give exactly the same results
>>>>>>>> (joining
>>>>>>>>>>> having the same effect as filtering). So it seems that I am
>>>>>>>> suggesting a
>>>>>>>>>>> largely formal algebra change, but one that would make hitherto
>>>>>>>> useless
>>>>>>>>>>> queries very helpful (e.g. to solve the problem in [1]).
>>>>>>>>>>>
>>>>>>>>>>> I am aware that this proposal comes at a very late stage, but I
>>>>>>>> think it
>>>>>>>>>>> is still feasible to do it. I could help with updating the formal
>>>>>>>> parts
>>>>>>>>>>> of the algebra. In any case, I would like to hear the opinion of
>>>>>>>>>>> implementers/practitioners, also re [1]. Note that I am writing this
>>>>>>>>>>> largely as a user (and teacher) of SPARQL, so when I am investing my
>>>>>>>>>>> time here it is merely because I am convinced that it would greatly
>>>>>>>>>>> benefit the language.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> Markus
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [1] http://korrekt.org/page/The_State_of_the_UNION
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>
>
Received on Friday, 6 May 2011 14:18:10 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:46 GMT