Changing Graph Structure

[abrobbins90]

The Node - Edge organization is too limiting and needs to be modified, or fully replaced.

[abrobbins90]

The Problem

The current system has nodes of various types, connected by edges. Edges are all the same and are fully symmetric. It is not presently possible to have more complex interactions between nodes. Everything about the relationship between two nodes is determined from the respective node types, which are always different.:

One major capability that is lacking is being able to connect meal nodes.
Here are two examples:
A) A meal with a sauce, where the sauce is defined as its own meal node. In this case, two meal nodes are connected, however the relationship is asymmetric. One is a part of the other, but not vice versa.
B) A meal with a side. One meal might always have a specific rice dish as a side with a larger meal. Or one might have a few side options with a meal, such as mashed potatoes or baked potatoes. Again, this is an asymmetric relationship between meal nodes. Furthermore, the exact role of the connected second meal may vary.

Under the current system, connecting two meal nodes is allowed, and could be used for searching, etc. however if the goal was to populate the side for example into the main dish, programming it as such would also populate the main dish into the side. You could maybe get rid of this by tagging one as an entrée and the other as a side. But what about optional/recommended sides vs persistent things like a sauce? Or what about recipes that are sometimes standalone sides and other times a direct ingredient. For example, mashed potatoes are a side, but in Shepherd's pie, it serves as the top layer of the pie. Is mashed potatoes a side or an ingredient? I'd certainly want it displayed differently to the user in each of these cases. And maybe we could slap enough band-aids on to this, but why not just have more complex relationships.

Possible Solutions:

1. Hard-coded edge types
   Instead of each node having a list of edges, it could have several lists of edges. For meals, there could be tags, ingredients, sides, sub-meals (like sauces), etc.

2. Intermediate nodes
   We could add new types of nodes that act as intermediates between other nodes. Edges would remain the same, but nodes would be added to facilitate more complex relationships between normal nodes.

3. Add edge objects
   Instead of just node objects, we could have edge objects too. These objects would come in many flavors and essentially act as links between specific node types.

• Note, options 2 and 3 are similar in practice, but conceptually distinct.

My Current Thoughts:

Personally, I like option 3, but I'm open to a discussion.

Expanding more on what edge objects might look like:
Any given edge subclass could be designed specifically for a given node pair, like meal-ingredient, meal-tag, meal-meal, etc. It enriches the relationship between nodes and allows many possibilities. Reasons I like this:

1. There can still be a single list of edges per node. The code for a node does not need to change much. Edges can be queried to return an appropriate list as needed.
2. New subclasses can be added as needed, making this highly flexible. All edges can have the same basic functionality, like responding to searches. They can be customized to respond appropriately to any situation.
3. I think it could merge into the ingrQuantities idea, but far more naturally. There has been this fundamental problem so far that a meal has a list of ingredients, but those are immutable, so we also need a separate list of quantities for each meal. This seems to fly against having a single source of truth. These two lists must be kept in sync. Danger! Danger! Instead, we could have meal-ingr edges hold that information natively. This way, the edge object itself is like a series of bowls on the table. Each bowl has an ingredient, or maybe it has a dish you already made (which itself was made earlier from a series of bowls). Each bowl represents an already measured quantity. One does not have bowls of the concept of broccoli, which is what we had before. Now we can have bowls of an amount of broccoli. We can have optional bowls, suggested bowls, etc. That brings me to my next point.
4. It's far more natural this way. The ingredient nodes are like the grocery store. But when an ingredient appears in a recipe, there are so many modifiers. You take an ingredient out of the refrigerator or whatever, and then you do stuff to it, and then THAT goes in the recipe. Maybe it's one diced onion. Sure that's in the recipe instructions, but it's often relevant to see that information attached to the ingredient (certainly the quantity). That information belongs to that ingredient. Current recipe websites often list it this way (1 diced onion, etc.), rather than 1 onion, and then later on they tell you to dice it. This likely will be on a spectrum, but for many standard ingredients, a modifier makes more sense than a line in the recipe. I'm not going to devote a line of the instructions to mincing your garlic. I'm just going to say minced garlic. It's likely not a part of prep, it's just the (modified) ingredient. A lot of people have it pre-minced for example.