From: Bryan T. <br...@sy...> - 2015-05-15 17:22:02
|
Brad, can you publish that branch on Sourceforge git so people can play with it? Thanks, Bryan ---- Bryan Thompson Chief Scientist & Founder SYSTAP, LLC 4501 Tower Road Greensboro, NC 27410 br...@sy... http://blazegraph.com http://blog.bigdata.com http://mapgraph.io Blazegraph™ is our ultra high-performance graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints APIs. MapGraph™ is our disruptive new technology to use GPUs to accelerate data-parallel graph analytics. CONFIDENTIALITY NOTICE: This email and its contents and attachments are for the sole use of the intended recipient(s) and are confidential or proprietary to SYSTAP. Any unauthorized review, use, disclosure, dissemination or copying of this email or its contents or attachments is prohibited. If you have received this communication in error, please notify the sender by reply email and permanently delete all copies of the email and its contents and attachments. On Fri, May 15, 2015 at 1:20 PM, Michael Schmidt <ms...@me...> wrote: > Dear Lee, > > thanks for reporting the two issues! > > We have identified the problems causing the behavior (see my comment in the > parent task http://jira.blazegraph.com/browse/BLZG-1141). A correctness fix > for both issues is available in branch BLZG48and50, however the fix might > induce some performance regressions. We want to look at performance in more > depth before merging into master (probably as part of a more exhaustive > refactoring), so it might take a while until this will appear in master. > > Best, > Michael > > > On 13 May 2015, at 16:06, Bryan Thompson <br...@sy...> wrote: > > Lee, > > Many thanks. I will assign them to Michael (Cc) to take an initial look. > > Thanks, > Bryan > ---- > Bryan Thompson > Chief Scientist & Founder > SYSTAP, LLC > 4501 Tower Road > Greensboro, NC 27410 > br...@sy... > http://blazegraph.com > http://blog.bigdata.com > http://mapgraph.io > > Blazegraph™ is our ultra high-performance graph database that supports > both RDF/SPARQL and Tinkerpop/Blueprints APIs. MapGraph™ is our > disruptive new technology to use GPUs to accelerate data-parallel > graph analytics. > > CONFIDENTIALITY NOTICE: This email and its contents and attachments > are for the sole use of the intended recipient(s) and are confidential > or proprietary to SYSTAP. Any unauthorized review, use, disclosure, > dissemination or copying of this email or its contents or attachments > is prohibited. If you have received this communication in error, > please notify the sender by reply email and permanently delete all > copies of the email and its contents and attachments. > > > On Wed, May 13, 2015 at 10:03 AM, Lee Kitching <le...@sw...> wrote: > > Hi Bryan, > > I've raised these at http://jira.blazegraph.com/browse/BLZG-48 and > http://jira.blazegraph.com/browse/BLZG-50. > > Thanks > > On Wed, May 13, 2015 at 12:41 PM, Bryan Thompson <br...@sy...> wrote: > > > Lee, > > These definitely look like bugs. Can you please file tickets at > http://jira.blazegraph.com and include sample data and expected > solutions for each? We will try to get the fixes into the 1.5.2 > release. > > Thanks, > Bryan > ---- > Bryan Thompson > Chief Scientist & Founder > SYSTAP, LLC > 4501 Tower Road > Greensboro, NC 27410 > br...@sy... > http://blazegraph.com > http://blog.bigdata.com > http://mapgraph.io > > Blazegraph™ is our ultra high-performance graph database that supports > both RDF/SPARQL and Tinkerpop/Blueprints APIs. MapGraph™ is our > disruptive new technology to use GPUs to accelerate data-parallel > graph analytics. > > CONFIDENTIALITY NOTICE: This email and its contents and attachments > are for the sole use of the intended recipient(s) and are confidential > or proprietary to SYSTAP. Any unauthorized review, use, disclosure, > dissemination or copying of this email or its contents or attachments > is prohibited. If you have received this communication in error, > please notify the sender by reply email and permanently delete all > copies of the email and its contents and attachments. > > > On Wed, May 13, 2015 at 6:51 AM, Lee Kitching <le...@sw...> wrote: > > Hi, > > We are trying to migrate our native Sesame database to Blazegraph, > however > we are encountering a problem with the following query which returns no > results in Blazegraph: > > SELECT DISTINCT ?uri WHERE { > { > SELECT DISTINCT (?uri_d as ?uri) WHERE { > VALUES ?type { <http://type1> <http://type2> <http://type3> } > VALUES ?dg { <http://graph1> } > GRAPH ?dg { ?uri_d a ?type . } > } > } > MINUS > { > SELECT DISTINCT (?uri_l as ?uri) WHERE { > VALUES ?type { <http://type1> <http://type2> <http://type3> } > VALUES ?lg { <http://graph2> } > GRAPH ?lg { ?uri_l a ?type . } > } > } > } > > This returns a single result in Sesame since the first subquery returns > one > result and the subquery in the MINUS clause returns none. Executing the > first subquery > > SELECT DISTINCT (?uri_d as ?uri) WHERE { > VALUES ?type { <http://type1> <http://type2> <http://type3> } > VALUES ?dg { <http://graph1> } > GRAPH ?dg { ?uri_d a ?type . } > } > > returns 0 results in Blazegraph, however moving the single graph value > into > the GRAPH clause: > > SELECT DISTINCT (?uri_d as ?uri) WHERE { > VALUES ?type { <http://type1> <http://type2> <http://type3> } > GRAPH <http://graph1> { ?uri_d a ?type . } > } > > returns the expected result. Combining the two VALUES clauses into one: > > SELECT DISTINCT (?uri_d as ?uri) WHERE { > VALUES (?type ?dg) { (<http://type1> <http://graph1>) (<http://type2> > <http://graph1>) (<http://type3> <http://graph1>) } > GRAPH ?dg { ?uri_d a ?type . } > } > > also returns the result. Does Blazegraph support multiple VALUES clauses > in > the same query? I would expect the three queries above to be equivalent > (in > the case of a single graph). > > Another issue is that Blazegraph appears to be inconsistent when > projecting > variables from inner subqueries. The query: > > SELECT DISTINCT (?uri_d as ?uri) WHERE { > VALUES ?type { <http://type1> <http://type2> <http://type3> } > GRAPH <http://graph1> { ?uri_d a ?type . } > } > > returns the expected result, however wrapping this in another > projection: > > SELECT ?uri WHERE { > SELECT (?uri_d as ?uri) WHERE { > VALUES ?type { <http://type1> <http://type2> <http://type3> } > GRAPH <http://graph1> { ?uri_d a ?type . } > } > } > > causes no results to be returned. Surprisingly, projecting an unused > variable from the inner query: > > SELECT ?uri WHERE { > SELECT ?type (?uri_d as ?uri) WHERE { > VALUES ?type { <http://type1> <http://type2> <http://type3> } > GRAPH <http://graph1> { ?uri_d a ?type . } > } > } > > causes the result to be returned again. > > These two issues appear to be preventing the original MINUS query from > returning the expected results. Could you confirm these behaviours are > bugs? > I tried looking on the issue tracker but couldn't find anything directly > related. > > Thanks > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bigdata-developers mailing list > Big...@li... > https://lists.sourceforge.net/lists/listinfo/bigdata-developers > > > > |