The graph-relational database, defined

When I had to build a little special graph system, it was because I wanted to traverse a given graph and, given a set of detail subgraphs return a set of node pairs of type A and B and an edge A->B in which: * Each node of type A and of type B was a group-by of a small set of patterns of source data nodes. Because each query filters the source data nodes differently, these synthesized A and B nodes are query-specific. A query might return any number of pairs based on the data and the filters. * Each node of type A and node of type B had as its name the value of a specific attribute shared by subgraph elements (node name was a group-by) and contains attributes that were counts and sums of attributes of the subgraph elements. * The edge between each A -> B pair was itself an aggregation of patterns of nodes that connected between certain detailed elements collected by A and certain detailed elements collected by B, with attributes related to the count of patterns connecting the A and B nodes.

I was unable at that time to locate a system that allowed queries that aggregate patterns via node constructors and edge constructors.

One of the arbitrary choices in the modeling is when to create an edge and when to perform a retrieval by seach with attribute filters. Realistic systems seem to use a mix of both- why? Now I need to keep in mind the difference between reaching a vertex via edge with the correct labeling/attributes and just reading via an index. And which aspects of things like transaction attributes are attributes and which things need an edge traversal to reach. Being unable to define edges from an edge in some systems is silly. Who says the set of things connected by edges cannot include edges? Some graph systems allow this, others don't. That's arbitrary. It means edge can't therefore aggregate anything via edge relationships.

And, simple things like return count of nodes and sum of particular attribute values grouped by attributes, where the nodes and edges meet some criteria, wasn't available. The systems imposed a need to return nodes and edges. Nothing in set theory or graph theories prevent math from being performed on a graph and reasoning based on the math, and I don't want the database preventing it either.

I'm sure I haven't kept up with the latest developments. Query-specific synthesizing of graph constructs and non-graph data together are probably my main issues, and the DB that makes those convenient is of somewhat more interest.