How to detail position data from node a and node b when we have (a)-[rel_1]->(b) and (b)-[rel_2]->(a)

VERSION NEO4J 4.0.4

I wrote this on a subset of the Movie db:
MATCH (P:Person{name:"Diane Keaton"}),(P2:Person{name:"Julia Roberts"}) merge (P)-[:KNOW]-(P2) MERGE (P2)-[:FOLLOW]->(P)

The results are :
(Diane)-[:Know]>(Julia)
(Julia)-[:Follow]->(Diane)

I ask cypher relations a-to->b:
MATCH (P1:Person{name:"Diane Keaton"})-[R]-(P2:Person{name:"Julia Roberts"})
RETURN startNode(R) as NodeA, type(R) as Relation, endnode(R) as NodeB

The results are:

"NodeA" "Relation" "NodeB"
{"name":"Julia Roberts","actorId":"2","born":1967} "FOLLOW" {"name":"Diane Keaton","actorId":"6","born":1946}
{"name":"Diane Keaton","actorId":"6","born":1946} "KNOW" {"name":"Julia Roberts","actorId":"2","born":1967}

I can do the same query in more general way:
MATCH (P1)-[R]-(P2)
RETURN startNode(R) as NodeA, type(R) as Relation, endnode(R) as NodeB

I would like to know if a reciprocal relation between node can be classified as "left" AND "right-
You know a better way to ask the same question?
And, finally, is a right question?

Thank you
Alessio

Fun question. I go over a couple things and I hope I'm clear enough to answer your question. I'm not 100% sure I understand it, but I'll give it a try.

The bottom line: arrow direction matters. I think this is the root of your final question. When you talk about "the results are", Diane knows Julia but in graph-terms, Julia does not know Diane because the arrow points left to right. BUT, in your MERGE statement, you have no such bias. This is significant. I'm one who wishes Neo would be overly explicit, but I understand their convenience argument. If we have a MERGE (a)-[r]-(b), we really have two statements: (a)-[r]->(b) AND (a)<-[r]-(b) and that reality lives in a strange state. The direction of the relationship in a graph is a very important part of graph theory. "a" and "b" have, in the real world, explicit relationships. A path algorithm, for example, must have a clear means to determine if there is a path or not. So when you have say (a)--(b)-->(c), there IS a path from "a" to "c" but NOT from "c" to "a". And the portion of the path that's less explicit ("a" to "b"), becomes explicit in the algorithm but remains in that non-explicit state. This can be a source of bugs in algorithm creation, for example. All this does become somewhat clearer if/when you use an adjacency matrix to show your graph data - where the direction of the "arrow" really begins to make mathematical sense. In Neo's compromise for convenience, I hope that there's a "1" in a-b and b-a. But that's not always clear. But I build my graph based on that assumption. If that's what you mean by "left" and "right", I'd look more toward "ab" and "ba" and how those are defined in your models - and enforce that!

To stress this point, in your example, Julia following Diane is very clear as Diana does NOT follow Julia. So with all this in mind, it should be clear that there's a "1" in the juncture between Julia to Diane and a "0" in the reverse. So again, that's not left/right, rather ab/ba.

Finally and why I labor on here is because there's a danger in the query "MATCH (P1)-[R]-(P2)" that exemplifies why I struggle with the convenience of allowing a sort-of, non-directional graph facility. This query will return both the directional and non-directional results. If that's in the midst of a question that depends on the direction, it will return invalid assumptions - such as Diane possibly following Julia. And because that's allowed in Neo, there's coupling needed between you knowing the data and the data telling what you need to know. Sure, if you need direction, you can ensure that by your Cypher, but that has obvious risks.

Not so important if it's about movies, but if it's a query about the CORONA virus, asking billions of nodes questions, that could be significant :slight_smile:

HTH.

1 Like

Dear Llewellyn,

The big problem is: Is a direction owned by nodes or relationship?

I have thought a lot about this problem and my functional point of view is that we can think about a relationship as a layer outside nodes.

Fortunally we haven't relationship between relationship, node haven't a spin and we draw information in 2d...for now.

Thank you for your time.

Alessio

Sorry for the absence. Took a nasty fall that made typing impossible so, have been recouping. I'm better enough :slight_smile:

I think this level of question needs to move away from the "tool" (Neo) and into the math or graph theory. Love the question about "who owns" the "direction" whose answer is "both" and/or neither. Let me explain.

A "graph" is visual to humans starting with the now famous bridge problem. But the math of graph theory is not a visual rather than a model and a means to ask questions of the nodes and relationships. The best way to see how this looks for the "ownership" understanding, is to see a graph as a matrix.

Let's keep it super simple and imagine a 2 node graph. In this case, we can add a relationship...but remember, a graph G can have nodes and NO relationships. So I can't inset a table it seems but imagine my matrix[a,b] with cells [a,a],[a,b],[b,a],[b,b]. These are the four "points of view" of the two nodes. I saw POV because 'a' can look at itself and at 'b'. And 'b' can look at itself and at 'a'. NOTE: while 'a' and 'b' can ONLY see themselves from a single POV, they can see each other from two perspectives a->b and b->a. I'm not addressing direction yet, just POV. Simple graph theory is rather basic but this elegance of design enables very complex ideas. But for now, let's stick to the basics.

Assuming (arbitrary rule I'm saying here because it's consistent with how Neo is designed but NOT how graph theory limits the math) that any POV in our graph G can have either a "0" or a "1" as the value. The matrix then, can range from all zeros to all ones. Each cell that has a "1" in it moves from the column label to the row label (you could do either direction, just be consistent). And that "1" is THE DIRECTION.

So you can see how ownership of the direction is intimate with the matrix that represents it. This also addresses how you can NOT have a relationship to a relationship (i.e., when limited by this design concept of using a matrix.

So, hopefully this is helpful. I like how you are exploring graph issues like a graph's dimensionality. I do know of tons of work in graph DB design around adding to this most elegant matrix foundation. But most of these efforts, IMHO, are lazy and miss out on what I think is more the "next step". Instead of adding dimensions to the model, I'd say we should spend way more time addressing matrix multiplication, dot product, vector involvement, etc. This you can see in the graph algorithm work being done at Neo and other places in the graphista community. This is a huge need in the ML and AI work where graphs are going to become so key. Once we have that in place and performant, then the ideas of exploring multi-dimensions beyond what all that will uncover, will be useful to explore (if needed which I debate BTW).

Thanks and HTH.

1 Like

Thanks Llewellyn, your answer is enough :-)

I had just read this article on matrix and graph https://towardsdatascience.com/matrices-are-graphs-c9034f79cfd8.
On the dimensionality of the graphs I developed a small project that you can see here: From Neo4j graph to Virtual Reality concept map.