Re: Property Paths Cardinality

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Fri, 28 May 2010 10:54:54 +0100
Message-ID: <4BFF92EE.7060302@talis.com>
To: Steve Harris <steve.harris@garlik.com>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>
```

On 28/05/2010 8:10 AM, Steve Harris wrote:
> Overall seems pretty sensible, but there's one proposal that I'm not
> clear on:
>
> "PROPOSED: The cardinality of solutions to fixed-length paths
> is the same as the cardinality of solutions to the path expanded into
> triple patterns (with all variables projected); the cardinality of
> solutions to variable-length paths is the cardinality of solutions
> via paths that do not repeat nodes; the cardinality of solutions to
> paths combining fixed and variable length (elt{n,} ) is a combination
> of the fixed definition plus the variable definition for paths longer
> than the fixed length."
>
> I've read the minutes, but it's a little hard to interpret this proposal
> without known-good examples.
>
> I'm guessing this means that ?x :p/:q* ?y is variable length path and so
> that part of the solution is effectively distinct? Another
> interpretation is that the :p sub-path is fixed length, so only the :q
> part of the path is distinct.
>
> - Steve

Steve - this particular proposal is more of an outline of how to attack
the problem, rather than a choice between alternative designs.

"?x :p/:q* ?y" a path combining fixed and variable length parts.  The
cardinality should reflect that (e.g. not be less that ?x :p ?y because
that's a subcase :p/:q*).  Where it says "plus", I think that "plus" is
English "and also" - in technical terms, it's multiply: all the
possiblities of the first part multipled by all the possiblities of the
second part and :q* is distinct so it's multiple by one, but this is
detail to be explored.

The principle reflected in the proposal, is that

{?x :p/:q* ?y} === {?x :p ?z . ?z :q* ?y}

with ?z projected away.  Now we have a design principle, I'm hopeful
that we can answers these sorts of questions from that point of view.

What we need is (lots of) test cases.  (Hint, hint :-)

Andy
```
Received on Friday, 28 May 2010 09:55:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:00 UTC