Hi, Most of the cases where Marmotta does not have 100% conformance is in relation to result datatypes derived from the datatypes of the nodes where a function has been applied to. An example is the REPLACE function; according to the test, a REPLACE on a literal of datatype xsd:string should again have datatype xsd:string, while a REPLACE on a literal without type should again have no type. Many other cases are quite similar (e.g. MIN() of all xsd:integer nodes should again be xsd:integer).
Some of these cases could probably be solved with some effort (by projecting the original type along with the result), others probably not so easily (because implementing type coercion can be tricky). The question for me is, since most result values are correct, whether solving the datatype problem is really worth the effort. If you want 100% SPARQL 1.1 compliance, choose the Sesame Java API (BTW, it is also not fully compliant). If you want performance and can live with some minor non-conformance, choose the KiWi SPARQL implementation. Beyond this: - some of the tests are simply wrong SPARQL (e.g. using the file name in place of a named graph URI is invalid), so these tests fail - some of the tests fail at the Sesame level (BNODE(), URI(), IRI(), ...) - some of the tests use property paths which we will not be able to properly support in SQL without relying on recursive SQL Greetings, Sebastian 2014-11-04 15:13 GMT+01:00 Sergio Fernández <[email protected]>: > On 04/11/14 14:44, Sergio Fernández wrote: > >> It'd be great why the current development version (3.3.0-SNAPSHOT) gets >> worse results, even if the performance should be significantly better. >> > > Performance, nut not conformance. Then is clear. > > > -- > Sergio Fernández > Partner Technology Manager > Redlink GmbH > m: +43 660 2747 925 > e: [email protected] > w: http://redlink.co >
