- From: Steve Harris <swh@ecs.soton.ac.uk>
- Date: Thu, 1 Aug 2013 12:29:40 +0100
- To: william greenly <william_greenly@hotmail.com>
- 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>
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