W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2010

Re: [TF-PP] Moving forward

From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Date: Wed, 23 Jun 2010 09:20:02 +0100
Message-Id: <ED968A61-8BD7-42F1-B3A2-EAE31B092C50@gmail.com>
Cc: "matthew.perry@oracle.com" <matthew.perry@oracle.com>, "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
To: Andy Seaborne <andy.seaborne@talis.com>

On 15 Jun 2010, at 19:18, Andy Seaborne <andy.seaborne@talis.com> wrote:

> On 15/06/2010 1:46 PM, Matt Perry wrote:
>> Andy Seaborne wrote:
>>> Matt,
>>> When we had:
>>> [[
>>> 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.
>>> ]]
>>> it looked reasonable at the time but I'm finding that it isn't do
>>> clear cut a distinction of variable and fixed length paths.
>>> :p{n}
>>> which is similar or the same as p{n,n}
>>> which is similar or the same as :p/:p/..../:p
>>> :p{n,m}
>>> using the text above it is :p{n} / :p{0,(m-n)}
>>> which is similar or the same as :p/:p/:p?/:p?
>>> (n times :p and (m-n :p?)
>>> :p+
>>> which is also :p{1,}
>>> Birte suggests that
>>> :p{n,m} is
>>> :p{n} UNION :p{n+1} ... UNION :p{m}
>>> although this is problematic because it goes round loops multiple
>>> times if fixed length paths are the same as their triple pattern
>>> expansion.
>> You make a good point about allowing arbitrary repetition of loops when
>> evaluating the triple pattern expansion of a fixed length property path.
>> Because all of our proposals prevent repetition of loops when evaluating
>> unbounded property paths, we will always have some awkwardness in corner
>> cases. Take the following example:
>> :a :p :c
>> :c :p :c
>> :c :p :z
>> { :a :p{4} ?y } finds the path :a -:p-> :c -:p-> :c -:p-> :c -:p-> :z,
>> but { :a :p{3,} ?y } misses this path.
>>> :p{1,} needs to have a relationship to :p{1,X} as X tends to infinity.
>>> When X is larger than the longest path in the graph, it's going to odd
>>> (but possible) to have :p+ and :p{1,X} returning different answers.
>>> I can see that :p{n,m} defined as a union for small n and large m is
>>> going to an implementation burden for some systems using a pure
>>> expansion.
>>> The closest consistent view point with the text above on cardinality
>>> seems to me, currently, to be the form that counts all paths,
>>> including once round loops, which is the triple matching and
>>> backtracking. Intuitively, it's like trying to create triple
>>> expansions but limiting loops to once round. It feels as if it is
>>> consistent possible future returning path lengths.
>> I would argue that node marking with backtracking also makes sense and
>> is much easier to implement than edge marking with backtracking. Node
>> marking is easier to implement because when we encounter two nodes with
>> the same URI, we know that they are the same node, but when we encounter
>> two edges with the same URI, we can't say anything about their equality.
>> This fact makes cycle detection based on node repetition easier in my
>> opinion, especially when using disk-based storage and joining triples
>> tables.
> Minor: edge equality is possible: if a triple has same subject predicate and object, it's the same triple because an RDF graph is a set of triples.
>> As an example of node marking with backtracking, consider the following
>> dataset and query.
>> :a :p :b
>> :b :p :z
>> :b :p :c
>> :a :p :c
>> :c :p :c
>> :c :p :z
>> { :a :p+ ?y }
>> With node marking with backtracking, we get:
>> :a -:p-> :b
>> :a -:p-> :b -:p-> :z
>> :a -:p-> :b -:p-> :c
>> :a -:p-> :b -:p-> :c -:p-> :z
>> :a -:p-> :c
>> :a -:p-> :c -:p-> :z
>> This is exactly all simple paths that match the path expression and also
>> what we would get by doing a recursive SQL query against an s,p,o
>> triples table.
> To make sure we understand each other: node marking with backtracking is determining a path such that it passes a node only once but the same node can be part of another path.
> As the algorithm backtracks, it removes a record of nodes passed through from some working set (the visited set).  It never looks at a node if it finds it in the visited set.
> A simple path.
> http://en.wikipedia.org/wiki/Path_%28graph_theory%29
> This is not finding distinct solutions.  Your example shows it finds simple paths :a to :z several times so the cardinality of :z would be 3.
> (The distinct case is node marking and adding visited nodes to a set, not removing them from the set during traversal)
>> With edge marking with backtracking, we get the following additional paths:
>> :a -:p-> :b -:p-> :c -:p-> :c
>> :a -:p-> :b -:p-> :c -:p-> :c -:p-> :z
>> :a -:p-> :c -:p-> :c
>> :a -:p-> :c -:p-> :c -:p-> :z
> Determining cardinality by simple path should make extension to more complex path expressions easier although there is some checking to do here.  Does the entire segment 'path' of
> :A (path)* :B
> e.g.
> :A (:p1|:p2)* :B
> need to be repeated? I think the rule of simple path determination extends to this case more easily because the edges are not just fixed constant terms any more.
> Birte - you suggested edge marking.  How does node marking with backtracking and unwinding, that is "simple paths", work for you?
I am not insisting on edge marking. If node marking fits the overall picture better, that's fine. 

>    Andy
Received on Wednesday, 23 June 2010 08:21:03 UTC

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