Open VladimirAlexiev opened 9 years ago
Above I write "triples" but I mean "results"... In this case the query returns straight triples, so I hope such imprecision may be excused :-)
The same problem probably affects most CSV tests, and some of the JSON tests (I've checked for jsonres02.rq)
You are not alone with this problem but in general, the editors implemented a specific solution. For example, I can put OFF the security in the config and so, I can use "CLEAR ALL" to delete all the triples of system.
If you give me a method to clear all the system's triples, I can add a preprocessing before each test for your software. You can also add a new flag for the security in your file config : "CLEAR_SYSTEM" with the command "CLEAR ALL".
You can see the function about the pretreatments before the tests for the other softwares : clearAllTriples()
I dont see what CLEAR has to do with it. These system triples are returned because that's mandated by the respective entailment regime. You can't "delete" them.
This is a basic unit test. There are specific tests for entailment for the other tests, the entailment regime has to be OFF.
NB the protocol to start or not the entailment is fuzzy for me (in the parameters GET/POST ? or in the config of server ? etc.)
The csv01 query is
In this result the system under test returns all required results but also some "system" triples, eg
Looking at the end, the test driver seems to make an attempt to allow extra triples, since it compares only 6 results. But the attempt is half-hearted, since it checks the first 6 results, but in this case the expected triples are in-between the extra triples.
The result comparison should be more flexible: it should check the expected triples in order, but allow other triples to be interspersed.
It's better to fix the query to ask only for the expected triples (eg by filtering on :p1..:p6) but that'd need approval by the W3C SPARQL group