- From: james anderson <james@dydra.com>
- Date: Sat, 30 Jan 2016 17:40:50 +0000
- To: public-sparql-dev@w3.org
- Cc: w3c/rdf-tests <rdf-tests@noreply.github.com>
- Message-ID: <00000152939f8270-af8edef5-d64b-4eb8-a09c-3e9a36a3aede-000000@eu-west-1.amazonse>
good evening; > On 2016-01-30, at 17:47, Andy Seaborne <andy@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 | james@dydra.com | http://dydra.com
Received on Saturday, 30 January 2016 17:41:22 UTC