- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Wed, 20 Apr 2011 13:59:31 +0100
- 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?) Andy [*] 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