RE: Wishlist for SPARQL 1.2: Compatible query-hints, extra math operators

Semver is a good guideline and generally tells you the conditions under which you must increment minor a major versions.
 
It does not stipulate at any point that you must not increase the Major version unless you introduce incompatible API changes.
 
I know you guys discussed this with regards to SPARQL 1.1, but generally if there are a lot of majors changes then increase the major version number even if they are not breaking. You won't be wasting vendors time - they are still going to test their products and probably re-read the specs even if you tell them there are no breaking changes. Equally, adopters across the board won't disqualify something that has a great set of new features (look at HTML5)
 
Calling it SPARQL 1.1 just told people that there were no breaking changes (but omitted to tell them anything else).
 
Many Thanks,
 
Will
 

 
Subject: Re: Wishlist for SPARQL 1.2: Compatible query-hints, extra math  operators
From: swh@ecs.soton.ac.uk
Date: Thu, 1 Aug 2013 09:57:08 +0100
CC: jerven.bolleman@isb-sib.ch; public-sparql-dev@w3.org; public-rdf-dawg-comments@w3.org; kidehen@openlinksw.com; bryan@systap.com
To: william_greenly@hotmail.com

Que?
If it breaks back-compatibility then it should be SPARQL 2, if not 1.2. http://semver.org/
- Steve
On 2013-07-30, at 15:15, william greenly <william_greenly@hotmail.com> wrote:Excellent - Yes! SPARQL 1.2. If we want to follow in the footsteps of SPARQL 1.1 we should ensure 1.2 has lots of major changes in protest against semantic versioning.
 
> Date: Tue, 30 Jul 2013 16:05:27 +0200
> From: jerven.bolleman@isb-sib.ch
> To: public-sparql-dev@w3.org; public-rdf-dawg-comments@w3.org; kidehen@openlinksw.com;bryan@systap.com
> Subject: Wishlist for SPARQL 1.2: Compatible query-hints, extra math operators
> 
> Dear Workgroup, All,
> 
> Maybe not the best moment to bring this up as the ink on SPARQL 1.1 is 
> not even dry yet. But looking to the future could we start thinking 
> about SPARQL 1.2 and what could be standardized there.
> 
> The first need I am seeing is the need to standardize query hints.
> 
> Oracle uses extra prefix declarations for query hints [1].
> BigData uses magic BGP's [2]
> Virtuoso introduced a new keyword ASSUME [3]
> 
> The BigData and Virtuoso approach introduce query incompatibilities 
> which is unfortunate. Oracle is ok in this respect as the unused 
> prefixes won't affect any strictly compatible sparql engine. I like the 
> idea that any SPARQL query will run on any store the only thing changing 
> is speed. Extra keywords or non existing BGP's break this utopia :(
> 
> The second is an expansion of the basic math operators to include at 
> least (square)root. (square)root is very hard to implement using the 
> current SPARQL constructs yet is a very useful function. (even if not exact)
> 
> Regards,
> Jerven
> 
> 
> 
> [1] 
> http://docs.oracle.com/cd/E18283_01/appdev.112/e11828/sem_jena.htm#CBBIAGAF
> [2] http://sourceforge.net/apps/mediawiki/bigdata/index.php?title=QueryHints
> [3] 
> http://sourceforge.net/mailarchive/forum.php?thread_name=51F67BB8.7030302%40openlinksw.com&forum_name=virtuoso-users
> 
> 
> 
> 
> -- 
> -------------------------------------------------------------------
> Jerven Bolleman Jerven.Bolleman@isb-sib.ch
> SIB Swiss Institute of Bioinformatics Tel: +41 (0)22 379 58 85
> CMU, rue Michel Servet 1 Fax: +41 (0)22 379 58 58
> 1211 Geneve 4,
> Switzerland www.isb-sib.ch - www.uniprot.org
> Follow us at https://twitter.com/#!/uniprot
> -------------------------------------------------------------------
>