History | Log In     View a printable version of the current page. Get help!  
Issue Details [XML]

Key: SES-834
Type: Bug Bug
Status: Resolved Resolved
Resolution: Cannot Reproduce
Priority: Major Major
Assignee: Jeen Broekstra
Reporter: Peter Ansell
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

SPARQL 1.1 Construct query fails to generate full results

Created: 16/Sep/11 05:33 AM   Updated: 19/Sep/11 04:06 AM
Component/s: SPARQL
Affects Version/s: 2.5.0, 2.5.1
Fix Version/s: 2.5.1

File Attachments: 1. Java Source File SesameConstructQueryBug.java (4 kb)

Environment: Ubuntu 11.04

$ java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)

The following SPARQL Construct query, using SPARQL 1.1 query features, generates 0 results when using sesame 2.5.0, and 1 result using sesame 2.5.1 (the second of the two expected result triples, ie, the one containing owl:sameAs)

    ?subjectUri ?predicateUri ?normalisedObjectUri .
    ?normalisedObjectUri <http://www.w3.org/2002/07/owl#sameAs> ?objectUri .
    ?subjectUri ?propertyUri ?objectUri .
    filter(isIRI(?objectUri) && strStarts(str(?objectUri), \"http://bio2rdf.org/po:\")) .
    bind(iri(concat(\"http://oas.example.org/plantotology:\", encode_for_uri(substr(str(?objectUri), 23)))) AS ?normalisedObjectUri)

The test repository contains 1 triple:

<http://bio2rdf.org/po:0000198> <http://bio2rdf.org/po:is_a> <http://bio2rdf.org/po:0009089> .

The expected query results are:

<http://bio2rdf.org/po:0000198> <http://bio2rdf.org/po:is_a> <http://oas.example.org/plantontology:0009089> .
<http://oas.example.org/plantontology:0009089> <http://www.w3.org/2002/07/owl#sameAs> <http://bio2rdf.org/po:0009089> .

I am attaching a JUnit test case as well.

 All   Comments   Change History      Sort Order:
Comment by Peter Ansell [16/Sep/11 05:36 AM]
A JUnit test that illustrates the issue.

Comment by Peter Ansell [16/Sep/11 05:43 AM]
Please ignore the slashes in the query, I forgot to delete them after copying them out of the test case.

Comment by Peter Ansell [19/Sep/11 03:43 AM]
Sorry about this. I had two mistakes in my query,

    ?subjectUri ?propertyUri ?objectUri .

should have been:

    ?subjectUri ?predicateUri ?normalisedObjectUri .



should have been:


I fixed the spelling mistakes in the query and it executes properly in 2.5.1-SNAPSHOT

It is a little suspicious that the query engine hasn't been throwing exceptions relating to bindings in the construct template not being named.

You may want to investigate why an exception wasn't thrown when the construct template contained a variable that wasn't defined anywhere else in the query.

Comment by Jeen Broekstra [19/Sep/11 03:53 AM]
Thanks for the update Peter.

The reason bind currently fails silently is that it is implemented as an Extension, and this is designed to fail silently whenever a (type) error occurs. I will have a look at better behavior for this as clearly the current setup is not helpful for figuring out what's going wrong :)

Comment by Peter Ansell [19/Sep/11 04:06 AM]
Thanks for looking into this further. I am used to having parse or query execution exceptions when something goes wrong.

You may want to take into account the fact that the query generated 1 result, which included the bound variable, using the current 2.5.1-SNAPSHOT build, as that would (naively) seem to indicate that bind was working okay and there was a deeper issue with generating results sets.

Since the first triple pattern in the construct pattern was not optional in the where section, the entire results set shouldn't have been output without it being attached to something, unless I do not understand Sparql 1.1 properly.