RE: property paths

Dear all, 

We have had several strawpolls on the issue, but AFAIR we have only one binding resolution, the onw from last time [1].

My understanding is that the agreement last time came from the understanding that 
we do not want to mix counting and non-counting semantics within a path at this point, 
that is - with Option 3 -  we have voted for an operator on the level of the whole path, rather than fine-grained choice.

If I understand Grag correctly, the alternative he proposes, let's call it Option 7 (a variation of Option 3, which we actually voted on) is also on path level:

 Option 7: add ALLPATHS(full-path) only (and make DISTINCT(full-path) the default)

This is in fact the option that comment JP-4 suggested originally.


Andy's proposed Option 6 is IMO orthogonal to both Option 3 and Option 7, 
in that it mixes non-counting and counting semantics on the path level. 
E.g. in 

   (:p/:q)*

or alike, and that our commenters have already indicated that they would 
find a mixed semantics confusing.

As it stands, we still hold with the resolution [1] with the caveat 
that Greg is worried that it's a lock-in preventing a later "syntactic" fix.

Best,
Axel

1. http://www.w3.org/2009/sparql/meeting/2012-03-20#resolution_1
 
-- 
Dr. Axel Polleres 
Siemens AG Österreich 
Corporate Technology Central Eastern Europe Research & Technologies 
CT T CEE 
 
Tel.: +43 (0) 51707-36983 
Mobile: +43 (0) 664 88550859
Fax: +43 (0) 51707-56682 mailto:axel.polleres@siemens.com 
 

> -----Original Message-----
> From: Andy Seaborne [mailto:andy.seaborne@epimorphics.com] 
> Sent: Dienstag, 27. März 2012 14:24
> To: public-rdf-dawg@w3.org
> Subject: 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 13:57:23 UTC