- From: Jerven Bolleman <jerven.bolleman@isb-sib.ch>
- Date: Tue, 30 Jul 2013 17:10:12 +0200
- To: Bryan Thompson <bryan@systap.com>
- CC: william greenly <william_greenly@hotmail.com>, "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>
Hi Bryan, Thank you for the reply. Just to note I would be happy with a convention before standardization as well :) On 30/07/13 16:25, Bryan Thompson wrote: > A few points: > > * Prefix hints alone are not sufficiently rich. We use "virtual > triples" so we can influence specific joins, sub-groups, > sub-selects, etc. > * We use a namespace for hints so people can identify any bigdata > specific dependencies in their queries. > * Query hints sometimes are necessary for an application to "work". > This might mean having reasonable performance, but it also might > mean accessing a vendor specific functionality. A very similar > problem arises if you have a SERVICE that interprets the graph > pattern as having specialized semantics. E.g., as supporting full > text, geospatial search, other sorts of "extension" services. > * Even if you have standard hint syntax (which would be nice), the > semantics of the hints will not be standard and hence applications > will still not be portable. > All very good points > One suggestion would be to introduce a marker (similar to the "#" > character for comments) that indicates that the triple pattern is a > query hint. This would make it possible for the hints to be > automatically ignored if they do not pertain to a specific platform > (e.g., because the hints are not in an understood namespace for that > platform). > > To draw an example from the link to our wiki below [1], you might use > the "%" character to mark the triple pattern as a query hint (we do not > currently recognize that syntax – this is just an example to indicate > what I mean). I would choose something like a special comment such as #hint as that should be backwards compatible i.e. an ignored comment to a strict 1.1 engine. > > PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> > PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> > PREFIX foaf: <http://xmlns.com/foaf/0.1/> > > SELECT ?x ?o > WHERE { > > # disable join order optimizer for this group graph pattern. > % hint:Query hint:optimizer "None" . > > ?x rdfs:label ?o . > ?x rdf:type foaf:Person . > } > > > Thanks, > Bryan > [1] http://sourceforge.net/apps/mediawiki/bigdata/index.php?title=QueryHints > > From: william greenly <william_greenly@hotmail.com > <mailto:william_greenly@hotmail.com>> > Date: Tuesday, July 30, 2013 10:15 AM > To: "Jerven. Bolleman" <jerven.bolleman@isb-sib.ch > <mailto:jerven.bolleman@isb-sib.ch>>, "public-sparql-dev@w3.org > <mailto:public-sparql-dev@w3.org>" <public-sparql-dev@w3.org > <mailto:public-sparql-dev@w3.org>>, "public-rdf-dawg-comments@w3.org > <mailto:public-rdf-dawg-comments@w3.org>" > <public-rdf-dawg-comments@w3.org > <mailto:public-rdf-dawg-comments@w3.org>>, Kingsley Idehen > <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>>, Bryan Thompson > <bryan@systap.com <mailto:bryan@systap.com>> > Subject: RE: Wishlist for SPARQL 1.2: Compatible query-hints, extra math > operators > > 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 <mailto:jerven.bolleman@isb-sib.ch> >> To:public-sparql-dev@w3.org <mailto:public-sparql-dev@w3.org>; > public-rdf-dawg-comments@w3.org > <mailto:public-rdf-dawg-comments@w3.org>; kidehen@openlinksw.com > <mailto:kidehen@openlinksw.com>; bryan@systap.com <mailto: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 BollemanJerven.Bolleman@isb-sib.ch <mailto: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 athttps://twitter.com/#!/uniprot >> ------------------------------------------------------------------- >> -- ------------------------------------------------------------------- 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 Tuesday, 30 July 2013 15:10:58 UTC