- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Thu, 08 Mar 2012 13:32:38 +0000
- To: "Polleres, Axel" <axel.polleres@siemens.com>
- CC: "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
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:33:08 UTC