- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Tue, 27 Mar 2012 13:23:44 +0100
- To: public-rdf-dawg@w3.org
> On Mar 26, 2012, at 7:11 PM, Polleres, Axel wrote: >> Gregory Williams wrote: >>> If it turns out that basically everybody wants the DISTINCT >>> semantics by default, and the counting semantics are rarely used, >>> based on our current decision we *can't* come back later in >>> another WG and decide to change the default semantics to align >>> with what people want. >> >> Whereas Jeen's comment, as well as JP-4 prefer non-counting as >> Default, we had a strawpoll on this earlier where the vote was in >> the direction of sticking with the counting semantics as default: >> >> http://www.w3.org/2009/sparql/meeting/2012-02-07#line0111 and also: http://www.w3.org/2009/sparql/meeting/2012-02-28 [[ Axel Polleres: Strawpoll, would anyone object to {*} and {+} counting operators and * and + default to non-counting? ]] where we had 8 x +1, and 1 x 0 Greg wrote: > I know there was concern from some that DISTINCT() is a rather wordy > way of asking for the distinct semantics. I'm concerned that we may > end up in a situation where it turns out that most people do end up > wanting the distinct semantics, and with our current design, we will > have done the Huffman coding all wrong -- distinct semantics will > require a long keyword, while the counting semantics won't. And on Jeen's comment, JB-10, I don't think we have done anything significant to reflect his feedback. Looking at F&R the examples are: + Retrieving all the elements of an RDF collection + Retrieve all of the names of people linked to me transitively via the ex:mother and ex:father relationships (i.e. all my known ancestors) + What are all of the direct and indirect superclasses of a given owl:Class? which amount to: rdf:rest* (counting or non-counting) (ex:mother|ex:father)* (non-counting *) rdfs:subClassOf* (non-counting *) and also: foaf:knows* (non-counting *) None of these require counting; rdf:rest* because in a well-formed list, counting and non-counting are the same. The natural interpretation of "/" and "|" is as rewrites to graph patterns. In the resolution [R], we said we'd add to the future work list; we have always noted this for path lengths and this seems prudent. But we need to make sure we have not obviously stamped on syntax. I think making * and + normally counting is a mistake. There 2 major concerns around implementation: 1/ Burden of too many things to implement and optimize 2/ The computation cost of an operation (hence need to invest in optimization) I would observe that there is a 3rd cost of implementation which is the consequent support; if the natural interpretation of syntax is not what semantics says, there is a recurring cost to implementers. So ... option 6: 6.A: /, |, ! as there are in 2LC. 6.B: *, +, ? are non-counting 6.C: No DISTINCT 6.D: No {} forms: {n}, {n,m}, {n,}, {,m} Notes: N1: No DISTINCT: with sub-queries and named variables, this can be done other ways. It's less important if * and + are non-counting. N2: It leaves all {} syntax free for more modifiers. (Note that {n,} and * interact currently.) {n,m} has also been noted as difficult. N3: This proposal is the least-cost in implementation terms and, I believe, in support costs. N4: It covers many (not all) use cases and does cover the F&R examples. The rest is left to future work. I feel quite safe defining * and + as non-counting and don't think it will block future work. Andy [R] http://www.w3.org/2009/sparql/meeting/2012-03-20#resolution_1
Received on Tuesday, 27 March 2012 12:24:19 UTC