Martin Junghanns

At the moment, there are two classes for each unary operator, e.g. `Aggregation` and `ApplyAggregation`. Instead, `Aggregation` should also implement ApplicableUnaryGraphToGraphOperator. This makes the API call `GraphCollection.apply(new Aggregation(...)) consistent.

Replace GradoopId with Either<GradoopId, NullValue> in VertexGroupItem

2

Summarization creates a `VertexGroupItem` in the first step which is further used in the algorithm implementations. This tuple type contains the vertex representative id, which is a `GradoopId`. When initializing...

Implement tuple based Gradoop model

3

Currently, model entities (vertices, edges, logical graphs) are represented as Pojos. We want to evaluate the performance compared to tuple implementations. Tuple classed need to use interface located in gradoop-core...

Refactor LogicalGraphTest / GraphCollectionTest

1

Both classes include tests that use manual validation of graph heads and graph elements. This can be replaced by the corresponding equality methods.

Just an idea for a convenience function that I'm sketching down here: Subgraph is basically a pattern match, formulated like so: ``` MATCH (n)-[e]->(m) WHERE vertexPredicate(n) AND vertexPredicate(m) AND edgePredicate(e)...

Grouping is currently a unary graph to graph operator and it's is not possible to apply it to a graph collection. However this use-case is interesting, especially in combination with...

If the label predicate is the only predicate for a query vertex/edge, we don't need to run `FilterAndProjectVertices` / `FilterAndProjectEdges` but rather `ProjectVertices` / `ProjectEdges` since #671 pushes the predicate...