lschuetze / gueryframework

GUERY is a Java library that can be used to query graphs for instances of motifs (aka patterns). Guery supports motifs that are complex in the following sense: motifs describe sets of vertices connected by paths. Both the vertices and constraints have to satisfy constraints w.r.t. (vertex and edge) labels and the length of the paths.

GUERY is a Java library that can be used to query graphs for instances of motifs (aka patterns). Guery supports motifs that are complex in the following sense: motifs describe sets of vertices connected by paths. Both the vertices and constraints have to satisfy constraints w.r.t. (vertex and edge) labels and the length of the paths. This definition of motif is significantly more expressive than the concept of motif often used in bioinformatics where the vertices in the motif are only connected by edges.

Guery has the following features:

• Motif definitions describe patterns in terms of vertex roles and paths connecting them. I.e., unlike languages like SPARQL GUERY supports the transitive closure of relationships.
• Motif definitions can contain aggregation ("group by") clauses. When the solver is configured to find classes of motif instances modulo the group by clauses, back jumping can be used (instead of back tracking).
• GUERY has a motif finder ("solver") that uses multithreading. This means that GUERY can take full advantage of multicore processors.
• GUERY uses an observer based API. I.e., the solver produces a result stream, similar to the way SAX XML parsers work. Once an observer is notified, GUERY will dereference the result. This means that GUERY can evaluate queries on large graph with low constant heap space (unless the observers collect and aggregate the results in memory of course - but this is the responsibility of the application using query!). We found that memory usage is a big problem for many other graph query tools (neo4j/cypher, crocopat, jena)!
• By default, GUERY works on graphs represented in memory using the JUNG API. GUERY2 also supports working with distributed graphs that do not have to be completely loaded into memory.
• The solver uses a path finder to traverse the graph. There are two path finder implementations available: a simple online breath first path finder, and a path finder that caches reachable nodes using chain compression applied to the condensation of the graph computed using Tarjan's algorithm.

To be built you need to download DependencyFinder and install it into your local Maven repository:

mvn install:install-file -Dfile=<unzip-location>/lib/DependencyFinder.jar -DgroupId=net.sf.depfind -DartifactId=depfind -Dversion=1.2.1-beta4 -Dpackaging=jar

gueryframework's Issues

parsing fails when referencing static fields or enums in constraints

this is an mvel problem, when parsing expressions like:

"inherits.type==test.RelType.EXTENDS"

mvel will interpret the first token in a fully qualified type name as a 
variable - guery relies on this api to extract variables from expressions to 
cross-reference them with roles. 

solution: add a sanity check after parsing, warn and remove variables from 
property constraints that do not correspond to roles. Unfortunately, this 
requires an extension of the PropertyConstraint API.

A question has been posted to the mvel list pointing out this issue. 

This is critical to implement a graph adapter for log4j where enums are used to 
label relationships! 

Original issue reported on code.google.com by jens.dietrich on 24 Sep 2012 at 10:48

SemanticException while checking an edge for its type

Consider the following motif:

motif TestMotif
select A, B
connected by relation(A>B)[1,1] find all
    where "relation is MyJavaEdgeType"

The expression is evaluated by MVEL and according to [1] the left hand side 
(relation) is to be checked to be a member of the class from the right hand 
side (MyJavaEdgeType). But I get an SemanticException with the following 
message:

"The expression 'relation is MyJavaEdgeType' contains the variable 
MyJavaEdgeType which has not yet been declared as a role"

It seems that GUERY does some additional evaluation of the expression because 
MVEL doesn't have a concept like a 'role' but GUERY has, hasn't it? How can an 
edge be type-checked?

[1] http://mvel.codehaus.org/MVEL+2.0+Operators

Original issue reported on code.google.com by [email protected] on 17 Aug 2012 at 1:16

agenda pre-initialised in nz.ac.massey.cs.guery.impl.MultiThreadedGQLImpl.java

in line 78 - this will force a full iteration over all vertices and is 
therefore inconsistent with the load on demand philosophy of graph adapters

Original issue reported on code.google.com by jens.dietrich on 7 Mar 2012 at 8:04

Conjunction of 'connected by' is not interpreted

As can be seen in the ANTLR grammar in line 249 [1] several 'connected by' can 
be connected with 'and'. Small example:

motif Test
select A, B, C, D
connected by collaboration1(A>B)[1,1] find all
and collaboration2(C>D)[1,1] find all

In this case the motif solver only interpretes the first 'connected by'. When 
an instance is found only the first collaboration and roles A and B are bound 
but collaboration2 and C and D are not.

[1] http://code.google.com/p/gueryframework/source/browse/grammar/guery.g#249

Original issue reported on code.google.com by [email protected] on 16 Aug 2012 at 7:04

wrong results for queries with computeAll flag on path constraints

the deginh query does return false positives

Original issue reported on code.google.com by jens.dietrich on 7 Mar 2012 at 8:01