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 <[email protected]
<mailto:[email protected]>>
Date: Tuesday, July 30, 2013 10:15 AM
To: "Jerven. Bolleman" <[email protected]
<mailto:[email protected]>>, "[email protected]
<mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>, "[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>, Kingsley Idehen
<[email protected] <mailto:[email protected]>>, Bryan Thompson
<[email protected] <mailto:[email protected]>>
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:[email protected] <mailto:[email protected]>
To:[email protected] <mailto:[email protected]>;
[email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>; [email protected] <mailto:[email protected]>
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 [email protected] <mailto:[email protected]>
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 [email protected]
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
-------------------------------------------------------------------
