W3C home > Mailing lists > Public > public-sparql-dev@w3.org > July to September 2013

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

From: Steve Harris <swh@ecs.soton.ac.uk>
Date: Thu, 1 Aug 2013 12:29:40 +0100
Cc: "jerven.bolleman@isb-sib.ch" <jerven.bolleman@isb-sib.ch>, "public-sparql-dev@w3.org" <public-sparql-dev@w3.org>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>, Kingsley Idehen <kidehen@openlinksw.com>, Bryan Thompson <bryan@systap.com>
Message-Id: <E198F4BA-FBA5-4821-8026-C41B662850F1@ecs.soton.ac.uk>
To: william greenly <william_greenly@hotmail.com>
I strongly disagree.

For end users it's very significant if they have to re-write all their old SPARQL 1.0 queries or not, saying it "just told people that there were no breaking changes" is undervaluing the importance of that information IMHO.

There are a group of people that follow this stuff closely, and there are a group of people that use these technologies regularly, but don't follow the "community" - mostly in industry. We're doing those people a disservice by sweeping the fact that 1.1 is back-compatible under the carpet.

- Steve

On 2013-08-01, at 12:16, william greenly <william_greenly@hotmail.com> wrote:

> 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
> > -------------------------------------------------------------------
> >
Received on Thursday, 1 August 2013 11:30:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:15:52 UTC