Within the parent-child metaphor that we have been using, it is entirely logical to navigate to a parent object (vertex) and add a new child in-context to that object's child (successor set). For example, adding a phototo a work can easily be understood by navigating to the work and adding a photo.
But when we switch into more abstract relates-to metaphors, this way of working doesn't always make sense. For example, if I have several artists that participated in several shows, which artist do I navigate to first to add the first show? Why should the user have to make this decision? And more importantly, if I need to add an existing show to a new artist that I add months later, how do I remember which artist has that reference.
I believe we both agree that the best solution to this problem is to have the backend maintain a "bucket" reference list for each vertex type.
I don't believe at the moment that these should be part of the graph. I think they should be available via a new endpoint in the api. But I think both of these questions should be discussed before proceeding.
Within the parent-child metaphor that we have been using, it is entirely logical to navigate to a parent object (vertex) and add a new child in-context to that object's child (successor set). For example, adding a
photo
to awork
can easily be understood by navigating to thework
and adding aphoto
.But when we switch into more abstract relates-to metaphors, this way of working doesn't always make sense. For example, if I have several
artists
that participated in severalshows
, which artist do I navigate to first to add the firstshow
? Why should the user have to make this decision? And more importantly, if I need to add an existingshow
to a newartist
that I add months later, how do I remember which artist has that reference.I believe we both agree that the best solution to this problem is to have the backend maintain a "bucket" reference list for each vertex type.
I don't believe at the moment that these should be part of the graph. I think they should be available via a new endpoint in the api. But I think both of these questions should be discussed before proceeding.