In my current project I have a situation where I would need to use an edge collection as vertex collection. I would like to find a way to avoid it. This is the (reduced) scenario.

These are the vertexes: Pupil, School, Holiday These are the edges: visitsSchool

  |   {from}
  +-------------> Holiday
  |   {to}
  +-------------> Holiday
 \ /

I want to make it possible for the user to maintain holidays or other events. It should be possible that a pupil visits a certain school from the beginning of the year till summer holiday. In the summer holidays the pupil visits another school. After that it should go back to the original school again. The problem is, that the holiday (or other date events) may be maintained very unregularly. To prevent the usage of a service that updates all my visitSchool edge collections, it seemed to be the best way to connect the edge with the holiday vertex.

  • 1
    Not sure what you mean exactly. If you want to represent a graph, you should have a collection of node1 to node2 with perhaps a relationship between the two. From this you should have all information you require from a graph. Notice that if you wanted an edge from node2 to node1, it would be a second line if you didn't want symmetrical edges. Could you please clarify your problem and write a concise question? – Neil Aug 29 '17 at 12:28
  • No, the example shows an edge document that is also used as vertex document. – Richard Burkhardt Aug 29 '17 at 12:32

There is the Thematic Approach to modeling.

I believe using the thematic approach with graph constructs (i.e. binary relationships) is also sometimes referred to as the Davidsonian or Neo-Davidsonian approach.

This approach calls for creating an identity for an event, as a simple node, and then describing the event by using as it as the subject of a number of individually simple thematic relationships like has-patient, has-agent, etc... You can have time relations as well, perhaps in your case has-begin-time and has-end-time.

One advantage of this approach is that it works with primitive modeling environments, like RDF, that don't support any more than binary subject-verb-object relationships, and also ones that don't support higher order statements (e.g. statements about statements). This approach supports optional/missing information quite well (and without use of nulls as you might find an relational model with lots of attributes in table where nulls might be found for missing/optional information).

However, a disadvantage is the explosion of edges, and possible increase in complexity of queries.

All-in-all from a mathematical point of view this is similar to your approach using higher order vertexes (a vertex that can refers to another vertex), so it comes down to standardizing on terminology, and on the capabilities of your modeling environment (e.g. whether higher order is supported).

However, if your modeling system does not support multiple edges between the same subject and object (in the same direction, using the same verb/relation), then using your vertex-based approach you would not necessarily be able differentiate between different attendances of the same person to the same school — whereas with the thematic approach you could (since using nodes for events instead of edges, assuming you can simply create a new node unique to other nodes).

  • Your answer was helping a lot. I prevented the explotion of complexity with the arangoDBs capability of addressing documents directly without the usage of joins. This way I could keep the has-relations but directly joined (without using a cross join but a direct allocation) them to the time document. It seemed to be best of both worlds. – Richard Burkhardt Sep 1 '17 at 9:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.