- From: Polleres, Axel <axel.polleres@siemens.com>
- Date: Tue, 8 May 2012 14:35:43 +0200
- To: Andy Seaborne <andy.seaborne@epimorphics.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
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