RE: SPARQL TC 2012-05-08 (today) agenda

I have read the draft reply now and think it's overall message is ok, 
although I am not sure whether it wouldn't be possible to tighten it up a bit.
Two suggestions to shorten:

1)

s/
using DISTINCT in the sum() aggregation.  This shows it's possible to 
write a SPARQL query with non-counting results given the current 
proposed design (option 6).  A subquery with DISTINCT is the more 
general case but it does suggest that the short syntax ought to favour 
the application writer task.  The converse is not possible - starting 
with unique results and modifying the results for duplicates.
/
using DISTINCT in the sum() aggregation.  This shows it's possible to 
write a SPARQL query with non-counting results given the current 
proposed design.  A subquery with DISTINCT is another alternative. 
Note that the converse is not possible - starting with unique results 
and modifying the results for duplicates.
/

2)

s/
Property paths can be divided into syntactic short forms and 
connectivity operators.  There are distinct features; they could have 
been described in two different sections of the query spec.

The connection is that short forms can be used as a sub-part of a 
connectivity property path expression.  The working group could have 
decided not to cover that and only have connectivity via a single 
property.

When combined, the semantics of the connectivity wins and { ?x (:a/:b)* 
?y } returns a *set* of matches for (?x, ?y).  Computational complexity 
is not increased because the "/" operator can be evaluated in context to 
only yield the necessary unique results which is a simple optimization.

So there is a choice for the sequence property path operator - syntactic 
short cut, or connectivity operator (putting everything as a 
connectivity path).  Which is the best choice is not a technical issue - 
it's a judgement.  The analogous equivalence is aa* and a+ (assuming"/" 
for the sequence on connectivity use cases - it could be a different 
operator) needs to be treated with care - it's not automatic that it is 
desirable when the whole collection of desirable features for SPARQL 1.1 
is considered.

If considered in isolation, and considering only whether a pattern 
matches or not, then connectivity semantics (non-counting), can be 
justified on design symmetry grounds.

Looked at in wider context other factors come into play: there has been 
a lack of recognition of this wider context.  SPARQL 1.1 is a not a 
fundamental redesign of SPARQL around property paths.

/
Property paths can be divided into syntactic short forms and 
connectivity operators.  In the current design, we opted - in favor of the presented 
use cases - for connectivity operators + and *, and syntactic forms for /
When combined, the semantics of the connectivity wins and { ?x (:a/:b)* 
?y } returns a *set* of matches for (?x, ?y).  Computational complexity 
is not increased because the "/" operator can be evaluated in context to 
only yield the necessary unique results which is a simple optimization.

This decision was made on the basis that SPARQL 1.1 is a not a 
fundamental redesign of SPARQL around property paths, and that we don't preclude 
that further connectivity operators may be added in future designs. 
/


HTH, best regards,
Axel


________________________________________
From: Andy Seaborne [andy.seaborne@epimorphics.com]
Sent: Tuesday, May 08, 2012 1:42 PM
To: SPARQL Working Group
Subject: Re: SPARQL TC 2012-05-08 (today) agenda

 > Time allowed, or next time otherwise

Last week, we agreed to decide what to do about a reply to WW-1:

So this time:
http://lists.w3.org/Archives/Public/public-rdf-dawg/2012AprJun/0072.html

        Andy

On 08/05/12 11:35, Polleres, Axel wrote:
> Dear all,
>
> apologies for only sending this now, I am out of office/stuck in meetings and will only get back to my desk short before the Telco today.
> Anyways, as far as I can tell, the most pending issues for today are:
>
> - Assign reviews for the new parts of PP in Query spec, cf. http://lists.w3.org/Archives/Public/public-rdf-dawg/2012AprJun/0108.html
>     (thanks Andy&  Greg for their efforts and also on starting to update test cases)
> - See whether we can directly (re-?)approve any test cases in this context
> - Go through open ACTIONS, http://www.w3.org/2009/sparql/track/actions/open
> - Go through pending comments and see whether we can approve some response drafts http://www.w3.org/2009/sparql/wiki/Comments
>
> Time allowed, or next time otherwise, I would like to start running through the editor's of the other drafts soon
> to check whether/what is open wrt. going to PR,
> i.e.
>    * address open comments, if any
>    * editorial changes since LC and summary of those, if any
>    * roadmap for implementation reports
>
> talk later,
> Axel

Received on Tuesday, 8 May 2012 12:36:16 UTC