Re: 18. and consequences

On 22/04/11 11:45, Sandro Hawke wrote:
> On Wed, 2011-04-20 at 08:36 +0100, Andy Seaborne wrote:
>>
>> On 19/04/11 19:19, Steve Harris wrote:
>>> On 2011-04-19, at 16:28, Andy Seaborne wrote:
>>>> Resolutions:
>>> ...
>>>
>>>> 2. Unquoted decimal literals in SPARQL 1.1 must have at least one digit to the right of the decimal point&   add note about this change to LC draft
>>>
>>> Good.
>>>
>>
>> Be careful what you wish for.
>>
>> The following, from the DAWG/SPARQL-1.0 test suite, break because of this.
>>
>> http://www.w3.org/2001/sw/DataAccess/tests/data-r2/basic/term-6.rq
>> http://www.w3.org/2001/sw/DataAccess/tests/data-r2/basic/term-7.rq
>> http://www.w3.org/2001/sw/DataAccess/tests/data-r2/syntax-sparql1/syntax-lit-08.rq
>>
>> Breaking the conformance suite is quite serious.
>>
>> and what about
>>     .1
>> ?
>>
>> and what about doubles -- this really does not make sense to me any more:
>>
>> 2.e57
>>     and
>> .2e66
>>
>> Earliest Turtle spec: 2006-12-04 [1] which refers back to SPARQL WD
>> 2005-11-23 and that followed N3 IIRC.
>>
>> While I prefer the 18.0 style, it has consequences.
>
> I think this speaks more to the high quality of the SPARQL test suite
> than it does to real-world consequences.   A good test suite tests the
> odd little corner cases, even those perhaps no one uses in real life.

Implementations report SPARQL compliance against the test suite.

> While I agree there's a kind of Hippocratic Oath for standards bodies
> ("First, do no harm"), I think the long-term benefits vastly outweigh
> the short-term costs.   By analogy, doctors often have to do harm to
> prevent greater harm, as in making a cut to remove a tumor.  What makes
> it hard for us is obtaining consent, and sometimes the people harmed are
> not the same as the people helped.

This argument does not work for me.  We're not stopping anyone writing 
18.0.  We are just stopping them writing 18. for a decimal and 
potentially from decimal to integer.

FILTER (?x < 18. ) becomes a parse error.

We do not force layout of queries in any other way.  You don't write 
SPARQL the same way I do.

"Do no harm" suggests to leave it as it is.

> Has anyone come forward and shown a case where existing deployed
> hard-coded queries will break and the people behind them feel strongly
> that this change isn't worth it for them and their users, in the long
> run?

Yes.  There was a user question on jena-dev last months about this. 
They have fixed their query to work ... and now it may stop working.
(yahoo search index is not working currently - it 6+ months out of date)

> I agree we should highlight this change to get such people to come
> forward, if they exist, so we can weigh that real cost against the
> weight of the long-term benefit of this change.

That I do agree with.

It would be extremely helpful to have RDF-WG make a commitment on the 
other differences.

If we end up with SPARQL a superset of Turtle, the argument for making a 
change to SPARQL 1.0 is weaker.

 Andy

>
>     -- Sandro
>
>>  Andy
>>
>> [1] http://www.dajobe.org/2004/01/turtle/2006-12-04/
>>
>>
>
>

Received on Friday, 22 April 2011 16:19:21 UTC