Does the order of the triples in a sparql query affect the result?

200 views Asked by At

I'm making an sparql query using pellet and I'm getting different results according to the order of the triples in the query, it's that correct?

For example, given the following N-Triples data input:

<http://example.com/thing1> <http://example.com/hasDefinition> <http://example.com/def_thing1> .
<http://example.com/thing1> <http://www.w3.org/2000/01/rdf-schema#label> "Thing 1" .
<http://example.com/def_thing1> <http://www.w3.org/2000/01/rdf-schema#comment> "thing 1 it's awesome".

<http://example.com/thing2> <http://example.com/hasDefinition> <http://example.com/def_thing2> .
<http://example.com/thing2> <http://www.w3.org/2000/01/rdf-schema#label> "Thing 2" .
<http://example.com/def_thing2> <http://www.w3.org/2000/01/rdf-schema#comment> "thing 1 it's cool".

<http://example.com/thing3> <http://example.com/hasDefinition> <http://example.com/def_thing3> .
<http://example.com/thing3> <http://www.w3.org/2000/01/rdf-schema#label> "Thing 3" .
<http://example.com/def_thing3> <http://www.w3.org/2000/01/rdf-schema#comment> "thing 3 it's fine".

<http://example.com/thing4> <http://example.com/hasDefinition> <http://example.com/def_thing4> .
<http://example.com/thing4> <http://www.w3.org/2000/01/rdf-schema#label> "Thing 4" .
<http://example.com/def_thing4> <http://www.w3.org/2000/01/rdf-schema#comment> "thing 4 it's exactly what i need".

The following query:

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX example: <http://example.com/>

SELECT * WHERE {
    ?thing ?rel "Thing 4".
    ?thing example:hasDefinition ?def.
    ?def rdfs:comment ?definition.
}

Returns:

Query Results (1 answers): 
thing  | rel   | def        | definition                        
================================================================
thing4 | label | def_thing4 | "thing 4 it's exactly what i need"

But the following query (just an alteration of the previous one):

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX example: <http://example.com/>

SELECT * WHERE {
    ?thing example:hasDefinition ?def.
    ?def rdfs:comment ?definition.
    ?thing ?rel "Thing 4".
}

I get the following answer:

Query Results (5 answers): 
thing  | def        | definition                         | rel                
==============================================================================
thing4 | def_thing4 | "thing 4 it's exactly what i need" | _TOP_DATA_PROPERTY_
thing4 | def_thing4 | "thing 4 it's exactly what i need" | label              
thing1 | def_thing1 | "thing 1 it's awesome"             | _TOP_DATA_PROPERTY_
thing2 | def_thing2 | "thing 1 it's cool"                | _TOP_DATA_PROPERTY_
thing3 | def_thing3 | "thing 3 it's fine"                | _TOP_DATA_PROPERTY_

I didn't expect this behaviour and I don't know if it's correct and I'm the one making the wrong query. Can anyone explain this to me?

3

There are 3 answers

0
Jan On

You should definitely get the same results with those two queries, changing the order of triple patterns like that should make no difference. This could be a bug in the query engine.

0
RobV On

As Jan suggests a pure SPARQL engine should not give different results given that data and that query.

However you are using Pellet (though you don't say which version) which has a SPARQL engine with an embedded reasoner. This means that the SPARQL engine may legitimately return additional results if it can derive them via the reasoner (see Extending SPARQL Basic Graph Pattern matching in the spec).

The fact that one version of the query causes the reasoner to kick in and another doesn't is somewhat odd and something you should likely ask the Pellet developers about.

0
AndyS On

The order of triple patterns should not change the results.

What is unusual about your query, is the use of ?rel in the property position.

_TOP_DATA_PROPERTY_ is possible something the Pellet engine will suppress internally - but if the ?thing ?rel "Thing 4". is last pattern, the data does not go through Pellet again, just comes from the database.