RE: Defining property paths

Hi Andy,

I am happy, if DISTINCT() is in anyways... Sorry, I had misunderstood that the new operators where an alternative to DISTINCT(), thanks for the clarification! 

I think my confusion came from the fact that your
proposal to change the default semantics of '*' and '+' to non-counting.
This seemed for me like a "mix" of counting and non-counting 
as the default, sinde 

  ?x :p/:p ?y

would potentially cause duplicates, likewise would 

 ?x :p{2,2} ?y 

but 

 ?x :p* ?y 

wouldn't ... However, after re-thinking it a bit, I think I understand now where you're coming from: If you view it in a way that '{*}' and '{+}' are essentially shortcuts for something like '{0,inf)' and '{1,inf}' then actually your proposed syntax makes 
sense to me.

Short version: thanks for the clarifications, I will get back with concrete comments on the current spec proposal for DISTINCT() shortly.

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: Andy Seaborne [mailto:andy.seaborne@epimorphics.com] 
> Sent: 08 March 2012 14:33
> To: Polleres, Axel
> Cc: public-rdf-dawg@w3.org
> Subject: Re: Defining property paths
> 
> 
> 
> On 08/03/12 12:48, Polleres, Axel wrote:
> > Dear Andy, all,
> >
> >> The "?" path operator can also generate a duplicate.  If 
> it's defined 
> >> as the union of {0} and {1} and the path loops back to the start 
> >> exactly.
> >
> > As we discussed already in an earlier thread [1], also "/" 
> can cause 
> > duplicates... and likewise can {n,m}, etc.
> > So, we'd end up having lots of more operators, right?
> 
> No, not directly.
> 
> "/" and the {,} forms remain as they currently are.
> 
> I think it's important that:
> 
> { ?x :p/:q ?y } == { ?x :p ?_a . ?_a :q ?y }
> 
> { ?x :p|:q ?y } == { ?x :p ?y } UNION { ?x :q ?y }
> 
> I am planning on adding DISTINCT(path) as well.
> 
> > Taking one step back, I am asking myself whether we should really 
> > produce counting and non-counting *operator* versions of all 
> > operators,
> 
> what is the suggested syntax for these?  This is an important 
> issue here and to-date there isn't a complete suggestion for 
> a systematic syntax for all operators to produce both kinds.
> 
> > and personally come more and more to the conclusion that it would 
> > probably be easier to resort - in this spec round of SPARQL - to 
> > either the DISTINCT() or ALL-PATHS() proposal (depending on the 
> > default semantics we choose).
> 
> I am planning on adding DISTINCT(path) as well.
> 
> > I am worried that the combination of * and + defaulting to 
> > non-counting in combination with other operators that can 
> cause duplicates (i.e. counting) is more confusing than a 
> clear-cut switch *around* paths.
> >
> > Do we actually have use-cases for mixing counting and non-counting 
> > semantics in the same path expression? It seems that - 
> correct me if I 
> > am wrong - the use cases discussed so far were either in the one or 
> > the other category, but mixing both semantics wasn't really 
> a use case, was it?
> 
> Maybe - the discussions have mainly been around individual operators.
> 
> What I think matters is natural interpretation without 
> massive amounts of syntax.
> 
> > If you agree, then I'd suggest to conentrate on the path "Spec'ing 
> > DISTINCT(path)" in your original mail.
> 
> I have said that's the plan.  I raised some matters to do with how
> DISTINCT(path) is spec'ed and presented - input there from 
> you would be most appreciated.
> 
> > BTW, one alternative I'd like to propose would be to 
> default overall 
> > to non-counting semantics and, instead of the (in my taste ugly) 
> > keyword ALL-PATHS() allow {...} around whole path 
> expressions only to 
> > denote counting semantics,
> 
> I don't see any new evidence from the earlier discussion so 
> -1 from me.
> 
> (Just above you suggesting specing DISTINCT(path) -- I don't 
> fully understand your position.)
> 
>  From seeing property paths in action, the strongest support 
> has been as a compact way to express triple patterns.  
> Altering the cardinality based on form therefore seems a 
> negative step.
> 
> { ?x :p/:q ?y } == { ?x :p ?_a . ?_a :q ?y }
> 
> { ?x :p|:q ?y } == { ?x :p ?y } UNION { ?x :q ?y }
> 
> > That'd be somewhat along the lines of your proposed {*} and {+} 
> > proposal, but keeping the switch on the entire path level 
> (and leave 
> > refinde versions With having { } around parts of paths for 
> future specs.
> >
> > Opinions?
> >
> > Best,
> > Axel
> >
> > 1. 
> > 
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar
> /0144.html
> >
>

Received on Thursday, 8 March 2012 13:54:58 UTC