- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 24 Apr 2019 18:46:05 -0400
- To: Bob DuCharme <bob@snee.com>, public-sparql-12@w3.org
How strict? And to what? The strictest I can think of is only allowing extensions to the query language (syntax and semantics) where extensibility is explicitly allowed in SPARQL 1.1 Query Language http://www.w3.org/TR/2013/REC-sparql11-query-20130321/ and similarly for the other parts of SPARQL 1.1. peter On 4/24/19 6:36 PM, Bob DuCharme wrote: > I agree that people should be able to assume strict backward compatibility > until we're talking about SPARQL 2.0. > > Boris's comment did remind me of something that would be nice to add to the > 1.2 wishlist: a clear specification about what the DESCRIBE keyword should > return instead of just leaving it up to the "information publisher" > (https://www.w3.org/TR/sparql11-query/#descriptionsOfResources) to decide. > This is vague enough that as far as I know no one even uses this keyword, > because if using one query processor is going to give you different triples > from another processor when you make the same request, you may as well just > use a CONSTRUCT query so that you know what you're getting. (As a former > employee of a company that marketed an RDF platform, though, I know that > employees of such companies don't worry so much about how other query > processors would handle their queries.) > > Thanks, > > Bob > > > On 4/24/19 10:58 AM, Boris Pelakh wrote: >> Given that this is SPARQL 1.2, semantic versioning would require strict >> backward compatibility, since the major version is not changing. Nor have I >> seen any proposals that would require a compatibility-breaking change. >> >> In the cases where the previous standard behavior is undefined, or vendor >> dependent, or non-existent, the new standard can mandate anything without >> breaking compatibility. >> >> Boris Pelakh >> Ontologist, Developer, Software Architect >> boris.pelakh@semanticarts.com >> +1-321-243-3804 >> >> >> -----Original Message----- >> From: Jerven Tjalling Bolleman <Jerven.Bolleman@sib.swiss> >> Sent: Wednesday, April 24, 2019 6:15 AM >> To: SPARQL 1.2 Community Group <public-sparql-12@w3.org> >> Subject: Thoughts about backwards compatibility >> >> Hi All, >> >> I thought to quickly write about my thoughts regarding backwards compatibility. >> These are just my thoughts and I am just providing them for discussion. >> >> My feelings on the matter are that there are two kinds of backwards >> compatibility. >> The first is "formally" not backwards compatible, i.e spec A says a certain >> kind of query should return a specific result and spec A+ defines a second >> different result, then it is not formally backwards compatible. >> >> Second is the "marketplace" backwards compatible. >> Same situation as above, but no one ever implemented A as specified or >> no-one ever send that kind of query. >> Then while there is a formal change in behaviour no one is impacted because >> no one used the behaviour. >> >> I am OK with breaking "formal" backwards compatibility but I am not at all >> keen on breaking "marketplace" backwards compatibility. >> In that regards I see as an example to follow the Java language stewards >> whom have the same kind of problem. >> There is a lot of code in the wild, doing even wilder stuff, making money >> and solving problems. >> Breaking such code should only be done in extremis and after careful >> evaluation. >> >> Being a very small community I think we can't afford splits like python2 to >> 3 or even worse Perl5 to 6. >> >> Regards, >> Jerven >> >> -- >> Jerven Tjalling Bolleman >> SIB | Swiss Institute of Bioinformatics >> CMU - 1, rue Michel Servet - 1211 Geneva 4 >> t: +41 22 379 58 85 - f: +41 22 379 58 58 Jerven.Bolleman@sib.swiss - >> http://www.sib.swiss >> >
Received on Wednesday, 24 April 2019 22:46:30 UTC