CommentResponse:JP-5

From SPARQL Working Group
Revision as of 07:42, 1 May 2012 by Apollere2 (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Hi Jorge,

Thanks for reporting on the behaviour of different implementations regarding property paths. 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