James Leigh suggested that I should add my problem with sparql [1] 'describe' to this issue.

With "sesame 2.2 beta2" a DESCRIBE query is quite fast but delivers dublicate statements.

When using "sesame 2.1.2" the performance is rather bad on big data sets, i.e. about 100.0000 triples.

The behavour of the dublicate returns with 2.2 beta 2 can be reproduced with the attached JUnit test.

Actually dublicate statements as result of a describe query are not really wrong, but are not very handy, too.



[1] http://www.openrdf.org/forum/mvnforum/viewthread?thread=1770

I also noticed a problem with duplicate statements in CONSTRUCT queries.
That is: it returns duplicate statements when there are none in the store!
The query has the following form:

CONSTRUCT
{
<http://example.org/x> <http://example.org/someProperty> ?a .
?a <http://example.org/someOtherProperty> ?b .
}
WHERE
{
<http://example.org/x> <http://example.org/someProperty> ?a .
?a <http://example.org/someOtherProperty> ?b .
}

The data has the characteristic that there are multiple statements in the store matching both the first and the second statement. Now it seems like that for every solution it finds for ?b it will repeat ?a thus giving me the first statement multiple times for the same ?a.

I'm also no expert in SPARQL to be able to say if that's correct or not. But when I tried this pattern against the DBpedia endpoint it did not contain duplicates.

The SeRQL and SPARQL parser now add REDUCED modifiers to the generated query model where appropriate. The query engine handles this by removing _consecutive_ duplicates from the query result.

SPARQL describe still does not work perfectly.
There are (some) dublicates returned.

See the attach JUNIT test.

The REDUCED modifier doesn't guarantee that there aren't any duplicates, it just indicates to the query engine that duplicates can/should be removed if it doesn't add too much overhead. On the other hand, it might make sense to change this into an actual DISTINCT for ASK queries (but not for CONSTRUCT).