RE: property paths

> 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

As your opinion seems to have changed in the meantime, does 
this apply to anyone else in the group? (it would be important to know this 
before answering to Jeen's and Jorge's comments, since my planend argument 
was that the majority of the group was backing the counting semantics as 
default)

Best,
Axel
 
-- 
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: Gregory Williams [mailto:greg@evilfunhouse.com] 
> Sent: 27 March 2012 00:04
> To: Polleres, Axel
> Cc: SPARQL Working Group
> Subject: Re: property paths
> 
> On Mar 26, 2012, at 5:29 PM, Polleres, Axel wrote:
> 
> > Hi Greg, all,
> > 
> > Indeed, what you write is some of the commenters argument.
> > However, last time we agreed on sticking - as the default - 
> with the 
> > counting semantics and having a switch to turn on non-counting 
> > semantics on full paths (DISTINCT()) rather than the other 
> way around 
> > (ALLPATHS()).
> 
> Ah. Based on the resolution text, it wasn't clear to me that 
> all of this was discussed.
> 
> > Unless you object to last week's decision, I'd prefer not to reopen 
> > the issue at this point and move on with the resolution from last 
> > week, putting proposals to default path semantics over the 
> whole query 
> > to noncounting or having finer grained distinction, such as 
> DISTINCT() 
> > at subpath-level to discussion for the future work items list.
> 
> I'm not sure about objecting, but I think it's crazy that 
> we'd spec two different path semantics, and then choose to 
> give one an obviously more desirable syntax, and the other a 
> less desirable syntax, when we have (to my knowledge) zero 
> data on how they are going to be used and whether one will 
> turn out to be more widely used than the other.
> 
> > We had the issue that common practice required syntax not directly 
> > available in the standard already in the previous addition 
> and fixed 
> > that now (MINUS). So, I guess it's fair enough to proceed 
> as we have 
> > resolved now on propoert paths and see how it's adopted, 
> whereupon a 
> > future WG can react, as necessary, as we did with MINUS.
> > Agreed?
> 
> No, I don't think it's like the MINUS case at all. In this 
> case, we're providing two alternative semantics for the same 
> feature, and giving one a better syntax. 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. We're treating one of the semantics 
> preferentially, and as far as I can tell, it's only because 
> we spec'ed one of them out earlier than the other. Are there 
> other compelling reasons to prefer counting semantics? Things 
> like Jeen's comments suggest to me that for many people it 
> might be the other way around.
> 
> I suspect I'm willing to be dragged along on this, but it 
> seems to me very much like we're making some big decisions 
> about the standard without any real-world experience to guide us.
> 
> .greg
> 
>

Received on Monday, 26 March 2012 23:12:21 UTC