Re: Comment about implementation of property paths

Hi Jorge,

Thanks for reporting on the behaviour of different implementations 
regarding property paths and apologies for the delayed reply.
Following the recent re-design of property paths, the group 
is currently working on a 2nd Last Call working draft. In the 
course of these changes we will also revise our test suite.
Particularly, we have included your suggested test case as

 http://www.w3.org/2009/sparql/docs/tests/data-sparql11/property-path/pp37.rq

in the test suite.

As a next step, i.e. to proceed to Proposed Recommendation stage,
we will also solicit implementation reports, to ensure that the 
expected behaviours of all features are covered by at least two 
implementations.

We would kindly ask you to acknowledge that you are happy 
with this response,

Axel, on behalf of the SPARQL WG

---------

 Hi,
 
 I just wanted to make an additional comment on this topic before the
 LC deadline. The comment is about current implementations of property
 paths.
 
 There are some property path queries that are currently being
 evaluated differently by some engines, in particular, KGRAM, Sesame
 (2.6.3) and ARQ give different results for the following example.
 
 data: 
 
 @prefix : <http://example.org/> .
 :A0 :P :A1, :A2 .
 :A1 :P :A0, :A2 .
 :A2 :P :A0, :A1 .
 
 query:
 
 prefix : <http://example.org/>
 select * where { :A0 ((:P)*)* ?X }
 
 The following are the results in each case:
 
 KGRAM:
 -------
 | X   |
 =======
 | :A0 |
 | :A1 |
 | :A2 |
 | :A2 |
 | :A1 |
 ------- 
 
 Sesame:
 -------
 | X   |
 =======
 | :A0 |
 | :A0 |
 | :A1 |
 | :A2 |
 ------- 

 ARQ:
 -------
 | X   |
 =======
 | :A0 |
 | :A2 |
 | :A1 |
 | :A1 |
 | :A1 |
 | :A2 |
 | :A2 |
 | :A1 |
 | :A2 |
 | :A2 |
 | :A2 |
 | :A1 |
 | :A1 |
 ------- 
  
 
 Please notice that my point is not to report a bug in the particular
 implementations, but to make an observation on the current semantics.
 From my point of view the above example shows that the semantics for
 the star (*) operator in property paths is somehow unnatural as at
 least three mayor engines that support SPARQL 1.1 evaluate expressions
 in different ways. Beside, as far as I know, there is no test case
 covering this example. 
 
 Cheers,
 - jorge 
 
 
-- 
Dr. Axel Polleres 
Siemens AG Österreich 
Corporate Technology Central Eastern Europe Research & Technologies 
CT T CEE 
 
Tel.: +43 (0) 51707-36983 
Mobile: +43 (0) 664 88550859
Fax: +43 (0) 51707-56682 mailto:axel.polleres@siemens.com

Received on Thursday, 24 May 2012 10:55:34 UTC