Re: SPARQL WG action on property paths

Hi Jorge,

My apologies for being unclear -- I had meant to more emphasize that I'm 
trying to understand whether this design addresses the concerns that 
were raised about the previous design.

On 4/6/2012 1:21 PM, jorge perez wrote:
> Lee,
>
> I was not trying to start a discussion. I just reply to your requirement on
>
>>   let me know what you think.
>
> That is what I did. Moreover, I would have said at the end of my email
> that I personally feel a bit uncomfortable replying these things
> off-list.

I've no desire to make anyone uncomfortable. Please feel free to wait 
for an official response from the Working Group rather than engaging in 
this discussion, in this case.

thanks,
Lee

>
> On Fri, Apr 6, 2012 at 6:35 AM, Lee Feigenbaum<lee@thefigtrees.net>  wrote:
>> Jorge,
>>
>> Can you please let me know if you believe that the current consensus design
>> addresses your concerns about the evaluation performance challenges of the
>> Last Call design that you raised in your original message to the -comments
>> list?
>>
>> While I understand that there are a variety of considerations that relate to
>> the particular design and that you may not be in favor of that design, I'm
>> not in a position currently to have that discussion. If the group proceeds
>> with this design direction, there will be--as always--opportunity to comment
>> on it, and if you disagree with the outcome--to object to the
>> specification's advancement towards W3C Recommendation. For the purposes of
>> this email, I'm simply trying to understand if this design addresses the
>> original concerns with performance evaluation of property paths.
>
> Please understand that we are talking here about open research
> questions and I cannot give you a definitive answer. It required a lot
> of research effort from our side to reach to some concluding results
> regarding the previous proposal. So if you ask me this, I can just say
> that our previous results are no longer applicable and that we need to
> do real research to see whether the new design addresses all the
> issues. Anyway, if an official response is required, I would say that
> "I do not agree with the current design, but I acknowledge that the
> group considered the issue raised by my comment".
>
> Cheers,
> - jorge
>
>>
>> thank you,
>> Lee
>>
>>
>> On 4/6/2012 1:30 AM, jorge perez wrote:
>>>
>>> On Tue, Apr 3, 2012 at 11:19 AM, Lee Feigenbaum<lee@thefigtrees.net>
>>>   wrote:
>>>>
>>>> Hi Wim, Jorge, Jeen, Marcelo, and Sebastian,
>>>>
>>>> (Please note that this is not an official working group response to your
>>>> respective comments on property paths in the current SPARQL 1.1 Query
>>>> last
>>>> call working draft.)
>>>>
>>>> I want to thank you all again for your research, experiences,
>>>> suggestions,
>>>> and comments on SPARQL 1.1 property paths. They've been very valuable to
>>>> the
>>>> working group.
>>>>
>>>> The group has spent some time in the past few weeks considering various
>>>> options in an attempt to address the implementation and evaluation
>>>> challenges that you have all raised while still respecting our group's
>>>> schedule, implementers' burdens, and the use cases we've identified for
>>>> property paths.
>>>>
>>>> Today, we reached consensus within the group on an approach that we feel
>>>> addresses your concerns while still leaving room for implementation
>>>> experience going forward to inform additional design decisions in the
>>>> future.
>>>>
>>>> We haven't yet worked this design into the query document, which is why
>>>> this
>>>> isn't an official WG response to your comments. Yet before we go ahead
>>>> and
>>>> publish a new Last call, we'd like to know if you support this new design
>>>> and if you believe that it does indeed address your comments.
>>>>
>>>> The design is summarized in these two emails by Andy Seaborne:
>>>>
>>>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0285.html
>>>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0286.html
>>>>
>>>> I'd very much appreciate it if you can take a look at this and let me
>>>> know
>>>> what you think.
>>>
>>>
>>> Hi Lee,
>>>
>>> I have followed the discussion regarding property paths in detail for
>>> more than one year, including the two links mentioned above. Regarding
>>> what I think about this last proposal, I think that it is not a good
>>> design decision. Making some property-path operators counting and some
>>> others not is just not natural. From my point of view, it would be
>>> really difficult to tell the users what is exactly going-on with the
>>> semantics. Thus, I am not Ok with this new proposal. Personally, I
>>> still do not understand the need for counting at all. If I can be
>>> honest with you, I cannot see any really strong use case for making
>>> counting a default (and, moreover, Marcelo in his previous email
>>> showed that all the use cases proposed so far can be more naturally
>>> expressed with an existential semantics plus ordinary SPARQL
>>> operators). As far as I can see, having a counting semantics for
>>> property paths was just "an accident" when the group decided to define
>>> property paths by translating them into SPARQL 1.0 operators. At that
>>> time the group did not have enough information to make a clear choice.
>>>
>>> On the other hand, and as opposed as what I think it has been said in
>>> some discussions, there is a lot implementation experience in
>>> different contexts on path queries with existential semantics, and
>>> also a huge amount of research. Even there is implementation
>>> experience in SPARQL. Please see:
>>>
>>> Gleen: http://sig.biostr.washington.edu/projects/ontviews/gleen/
>>> PSPARQL: http://exmo.inrialpes.fr/software/psparql/
>>> RPL: http://rpl.pms.ifi.lmu.de/
>>>
>>> The three of them implement path queries with existential semantics
>>> (non counting), and they work great!
>>>
>>> In contrast, there is no experience on implementing path queries that
>>> count, and current implementations of SPARQL 1.1 spec give different
>>> results for the same queries (see
>>>
>>> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2012Feb/0006.html).
>>> This shows that a counting semantics is difficult to understand even
>>> for experienced developers. Moreover, this topic is still an open
>>> research question. Please notice that the two papers that we have made
>>> public to the group are going to be presented in two of the most
>>> important conferences on the subjects of Web (WWW 2012) and databases
>>> (PODS 2012), and are only the first efforts in trying to understand
>>> the issue.
>>>
>>> On the positive side, and only if the group insists in the need for
>>> counting for some property path operators, I personally like more the
>>> proposal of DISTINCT/ALL over path expressions (that was also in the
>>> mailing list), but only if DISTINCT is the default. Please notice that
>>> this kind of design is not really different to some SQL operators.
>>> Just recall the "UNION ALL" in SQL. The rationale is that UNION is
>>> essentially a "set" operator, and this is the natural way to be
>>> defined. Thus if you want to retain duplicates in a SQL UNION query,
>>> an additional keyword should be provided. My personal view here is
>>> that for path queries it should be similar: the natural semantics
>>> (used for years in graph databases, XML and also in the RDF/SPARQL
>>> context) is an existential semantics (no duplicates), thus if you want
>>> to retain duplicates (in whatever form the group decide to count
>>> duplicates) you should provide an additional keyword such as ALL.
>>>
>>> Please let me know if it is OK with you if I forward this response
>>> together with your message to the public-rdf-dawg-comments list (I
>>> think we can attract more commenters and opinions to this subject if
>>> we openly discuss it).
>>>
>>> Cheers,
>>> - jorge
>>>
>>>
>>>>
>>>> thanks,
>>>> Lee
>>>
>>>
>>
>

Received on Friday, 6 April 2012 22:04:32 UTC