Re: Thoughts about backwards compatibility (and DESCRIBE)

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:37:21 UTC