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:33:08 UTC