W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2011

Re: 18. consequences.

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 20 Apr 2011 13:59:31 +0100
Message-ID: <4DAED8B3.1090303@epimorphics.com>
To: Ivan Herman <ivan@w3.org>
CC: RDF-WG <public-rdf-wg@w3.org>

On 20/04/11 13:34, Ivan Herman wrote:
> On Apr 20, 2011, at 13:35 , Andy Seaborne wrote:
>> On 20/04/11 10:56, Richard Cyganiak wrote:
>>> The consequence of the decision are, as I see it:
>> ...
>>> b) It is a change that breaks compatibility between SPARQL 1.0
>>> and SPARQL 1.1, in a *minor* and *easily characterized and
>>> motivated* way.
>> I don't think it's minor.  Evidence to show it is would be good.
>> One way would be to add a WG note (highlighted box) to the Turtle
>> spec as it is published as WD and in LC to make sure the change is
>> noticed.
>> For people with deployed queries, a software upgrade will now
>> either silently change the meaning of a query (only occurs for BGP
>> trailing 18.) or creates a syntax error in otherwise working
>> systems (the case of "18. .").  That's a big deal for them and
>> their software suppliers.
>> It's because of the success that these things become significant.
>> Establishing a message somehow that further changes to existing
>> systems would be good.
> The way I read these lines is as if you were opposed to make any
> change here. Is that correct? (Just want to understand.)

No problem - my position isn't yes/no.  I am not opposed; I do not 
wholeheartedly support it though.

The change is better from a design point of view.

But that is no longer the only issue - the semweb world is a lot larger 
than it was.

My concern is costs to deployed systems and data, and the lack of 
determination of that.  The costs are, in the main, on people who aren't 
in the working group; there is no factual determination of the effect on 
them [*].  Hence my suggestion to adding a highlighted box to the Turtle 
spec to make sure that people see it before the spec is frozen.

Care should be taken to not jeopardize exisiting (sic) RDF deployment 
efforts and adoption. In case of doubt, the guideline should be not to 
include a feature in the set of additions if doing so might raise 
backward compatibility issues.

Lack of doubt can come from lack of evidence :-)

I wish to highlight the consequences which I see as being 
under-recorded.  There seems to have been a lack of determination of the 
consequences before the decision (did anyone in this WG check the SPARQL 
1.0 test suite?)

The related plain literal/xsd:string decision also has consequences:

What about OWL tools that extensively use xsd:string?
What about the RDF test suite?
   datatypes/test011 whch requires DT(xsd:string)
   (panic not - it's OKish - but did anyone check?)


[*] I know what the direct cost on Jena is, both positive and negative - 
and I'm putting that to one side.  We, the developers, know the 
decisions are coming down the line.  Our users do not.

The prospect of spending the next few years explaining all this on 
support lists when we have just about managed to find a set of words 
that works for the current situation is not appealing.

> Ivan
>>> Overall that's a change for the better, I think.
>>> Best, Richard
>> Andy
> ---- Ivan Herman, W3C Semantic Web Activity Lead Home:
> http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key:
> http://www.ivan-herman.net/pgpkey.html FOAF:
> http://www.ivan-herman.net/foaf.rdf
Received on Wednesday, 20 April 2011 12:59:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:58 UTC