Re: property paths

> 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