W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2011

Re: Review of revised property path tests

From: Matthew Perry <matthew.perry@oracle.com>
Date: Tue, 01 Mar 2011 09:20:20 -0500
Message-ID: <4D6D00A4.4060407@oracle.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
CC: public-rdf-dawg@w3.org
Those new definitions look good to me.

- Matt

On 3/1/2011 8:03 AM, Andy Seaborne wrote:
>
>
> On 28/02/11 13:22, Matthew Perry wrote:
>> Hi Andy,
>>
>> Sorry for the confusion. I agree with the revised answer set for the property paths. I had a problem with a definition in the spec that I noticed when reviewing the test cases.
>>
>> My problem is with this sentence in the doc (from the definition of ZeorOrMorePath and OneOrMorePath in Section 18.4):
>> "An intermediate node is one which does not form an endpoint of the path match"
>>
>> Result paths are defined as not repeating intermediate nodes, but I believe that with the semantics we have, the end point of the path should also be categorized as an "intermediate" node because only the start node is allowed to appear again on the path. I was pointing out that, according to this definition, those additional solutions were valid paths because the node that is repeated is an endpoint (the end node).
>>
>> In other words, the definition should be "An intermediate node is one that is not the starting point of the path match."
>
> Yes, that needs to be made better.
>
> I think the concept of "intermediate node" is getting it the way now.
>
> For :p+, the path can still include the start and that will stop graph traversal for that possibility.
>
> How about removing "traversed" and taking about the outcome of "matched"
>
>
> --------
> Definition: ZeroOrMorePath
>
> An arbitrary length path P = (X (path)* Y) is all solutions from
> X to Y by repeated use of path such that any nodes in the graph are matched once only. ZeroOrMorePath includes X.
>
> Definition: OneOrMorePath
>
> An arbitrary length path P = (X (path)+ Y) is all solutions from
> X to Y by repeated use of path such that any nodes in the graph are matched once only. This does not include X, unless repeated evaluation of the path from X returns to X.
> --------
>
>
>     Andy
>
>>
>> - Matt
>>
>> ----- Original Message -----
>> From: andy.seaborne@epimorphics.com
>> To: matthew.perry@oracle.com
>> Cc: public-rdf-dawg@w3.org
>> Sent: Monday, February 28, 2011 6:43:47 AM GMT -05:00 US/Canada Eastern
>> Subject: Re: Review of revised property path tests
>>
>>
>>
>> On 21/02/11 22:07, Matthew Perry wrote:
>>> Hi Andy,
>>>
>>> I took a look at the revised property path tests.
>>>
>>> I have a questions about pp16 and pp25.
>>>
>>> The text definition in Section 18.4 allows an endpoint to appear as an
>>> intermediate node on the path.
>>>
>>> In pp16, if we allow this, shouldn't we get these additional solutions:
>>> {X=:e, Y=:e} for :e - foaf:knows ->  :f - foaf:knows ->  :e
>>> {X=:d, Y=:e} for :d - foaf:knows ->  :e - foaf:knows ->  :f - foaf:knows
>>> ->  :e
>>
>> I'm a bit lost here - are we talking at cross purposes somehow?
>>
>>
>> {X=:e, Y=:e} are in the solutions pp16.srx once.  Is that right for
>> foaf:knows*? Previously, we did have multiples here but you argued
>> against that.
>>
>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2011JanMar/0158.html
>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2011JanMar/0169.html
>>
>> Ditto
>> {X=:d, Y=:e}
>>
>> ---------------------------------------------------
>> | X                      | Y                      |
>> ===================================================
>> |<http://example.org/a>  |<http://example.org/a>  |
>> |<http://example.org/a>  |<http://example.org/b>  |
>> |<http://example.org/a>  |<http://example.org/c>  |
>> |<http://example.org/a>  |<http://example.org/c>  |
>> |<http://example.org/b>  |<http://example.org/b>  |
>> |<http://example.org/b>  |<http://example.org/c>  |
>> |<http://example.org/c>  |<http://example.org/c>  |
>> |<http://example.org/d>  |<http://example.org/d>  |
>> |<http://example.org/d>  |<http://example.org/e>  | **
>> |<http://example.org/d>  |<http://example.org/f>  |
>> |<http://example.org/e>  |<http://example.org/e>  | **
>> |<http://example.org/e>  |<http://example.org/f>  |
>> |<http://example.org/f>  |<http://example.org/e>  |
>> |<http://example.org/f>  |<http://example.org/f>  |
>> |<http://example.org/h>  |<http://example.org/h>  |
>> | "test"                 | "test"                 |
>> ---------------------------------------------------
>>
>> (this is the srx file, reformatted; not evaluating the query).
>>
>>> In pp25, we would get this additional solution
>>> {z=:c} for :a - :p ->  :c - :p ->  :c
>>
>> I see the test results for pp25 (<diamond-loop-2.srx) in CVS as:
>>
>> ----------------------
>> | z                  |
>> ======================
>> |<http://example/c>  |
>> |<http://example/z>  |
>> |<http://example/b>  |
>> |<http://example/z>  |
>> ----------------------
>>
>> (this is the srx file, reformatted; not evaluating the query).
>>
>>>
>>> I don't think we should allow the endpoint to appear as an intermediate
>>> node on the path, I would rather keep the results as they currently are
>>> in the tests. From my understanding, the semantics in Section 18.5 do
>>> not allow an endpoint to appear as an intermediate node.
>>>
>>> Thanks,
>>> Matt
>>>
>>
>>     Andy
>>
>
Received on Tuesday, 1 March 2011 14:22:04 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:45 GMT