(cc'ing RDF Tests Community Group) After reading this thread, I noticed that the SPARQL 1.1 test suite doesn’t do much (any?) to test aggregation when error/unbound values are in the group multiset. I’ve created two potential tests for SAMPLE and COUNT:
https://github.com/kasei/rdf-tests/commit/389617a278b737ef6d61af12dfb94f9175923cc0 thanks, .greg > On Jan 30, 2016, at 9:40 AM, james anderson <ja...@dydra.com> wrote: > > good evening; > >> On 2016-01-30, at 17:47, Andy Seaborne <a...@apache.org> wrote: >> >> On 30/01/16 14:24, Jörn Hees wrote: >>> Hi, >>> >>>> What was RDFLib producing? >>> >>> VALUES (?x ?ys ?zs) { >>> (3 UNDEF 15) >>> (5 UNDEF 25) >>> (2 6 UNDEF) >>> } >>> >>> >>>> Both are right, though the Virtuoso one is pragmatically more useful in >>>> this specific case. There is no one "right" in general when SAMPLE is >>>> involved. Aggregation calculation retains errors and ?z of UNDEF is an >>>> error. SAMPLE picks any value from the choices, and at that point, errors >>>> are "values". See ListEval. >>> >>> I understand that sample can pick an arbitrary value from its choices. >>> When it comes to error cases though, it seems this causes confusion as >>> people might not expect an UNDEF to be a solution if there are other values >>> to pick from... (undef has to be picked: (5 UNDEF 25) vs. can pick an >>> actual value: (2 6 10)). >>> >>> As you put it yourself it's pragmatically more useful, so would it hurt to >>> put a preference like that into the standard? >> >> The v1.1 standard is now fixed - but good suggestion for a prospective >> change. I've added it to the errata document, linked to your report, which >> is the best I can do. >> >> https://www.w3.org/2013/sparql-errata#errata-query-16 >> >> Changing the recommended behaviour of systems, even if "better", was >> something the 1.1 WG was loath to do, and chartered not to in the case of >> SPARQL 1.0 -> 1.1. In other words, any system that has faithfully >> implemented the standard up to now should be respected and not be impacted. >> >> In the meantime, getting the implementations to agree is the way forward. If >> that choice is the same everywhere, then it is a better case for future >> errata/clarification. > > this would do well to go into the regression tests as a test profile > parameter and service description property. > >> >> I have raised JENA-1126 for Jena and proposed a change to pick a defined >> value. >> >> Thanks >> Andy >> >>> In any case it would be cool if there was a small example (like the one >>> above) that clarifies the behaviour. >>> >>> Jörn >> >> >> [JENA-1126] >> https://issues.apache.org/jira/browse/JENA-1126 >> >> > > --- > james anderson | ja...@dydra.com | http://dydra.com
