[Discussion] Edge-to-Edge Edges Modeling Scenarios

[Cecil New]

In my problem domain (Product Lifecycle Management [PLM]), I encounter the need to connect edges to edges frequently. While PLM data models are Object Relational Models over relational databases, they bear a strong resemblance to graphs, specifically, directed property graphs.

I know you could uniformly insert a vertex between all pairs of vertices in order to provide a place to connect an edge, but this seems unnatural. Is this a common need? Are there other ways to handle it?

I can model edge to edge edges in an RDBMS, but as you can imagine, it takes a lot of joins to make it work.

Here are couple of ASCII art diagrams to illustrate where edge-to-edge connections are beneficial. (not all edges are labelled)

• The first shows an assembly of parts (only one shown). It shows the difference between the concept of an equivalent part, which is one that can be used in place of the prime part anywhere the prime is found; and the concept of a substitute part, which can only replace the prime part in the context of a given assembly. This is a vertex to edge to edge case.
  

    assembly

      |

      |---> substitute part

      |

      v

    prime

    part ---> equivalent part

• The second shows how one part is superseded by another in a given assembly. This is an edge to edge to edge case. Note that you can't just connect the part to the new part, since it is an instance of the part in the assembly that is being superseded, not necessarily all of them.
  

    assembly                              assembly

     rev A   --- has next revision --->    rev B

      |                                     |

      |------------ supersedes ------------>|

      |                                     |

      v                                     v

     part                                 new part

[Stephen Mallette]

As you probably know, TinkerPop doesn't support edges having edges, so you really have no choice but to add a resolving vertex in those cases. That's generally the approach I think most folks take with that. I wouldn't consider that wrong.

                   

--
You received this message because you are subscribed to the Google Groups "Gremlin-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gremlin-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/782e698a-35af-4eaa-9564-476a52b72d65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Dale]

There's a really great article on exactly this type of modelling by Matthias (et al) but I can't seem to find it again.

To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/CAA-H438Sw94fHp2opJW8gAuG_6dqb4XcZLXcSBYCgKD-EtFAXA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Robert Dale

[Max De Marzi]

An alternative to creating a node in between you can stick a node id or a set of node ids in the relationships.

If the model is fairly static then no big deal, if not then you have to make sure to keep them in sync.

Also works if they are "one way" relationships (if you don't have a good reason to traverse from the other side).