Graph data models can be expanded to encompass complex relationships. The whole graph can be digested better if subgraphs are considered. The recipe data model can be modified to include new layers of data.

Consider an ingredient. Many additional properties can be added to an ingredient:

While it may seem simple to choose the property values for an ingredient, there can be more to consider. For instance, consider category. Depending on the number of categories used to describe the ingredients, it can be more advantageous to create a vertex label or a property for category. Vertices can be the starting point for a graph traversal, but vertex properties cannot. In order to ask the question "what ingredients are dairy products?", a starting point at the dairy vertex requires one edge hop per ingredient to find all the ingredients categorized as dairy.

However, if too many ingredients are dairy, a super node, or node that is a hotspot with too many edges attached, can slow down queries that are searching for dairy ingredients. Using property indexing, an ingredient category can be better modeled as a property rather than a vertex label.

Nutrients are a set number of items, such as vitamin C, vitamin D, calcium, and sodium. Creating a vertex label for nutrient and weighting the edges between ingredient and nutrient with the percentage adds another dimension to the graph.

Look at the relationships that result for just one ingredient:

and imagine the graph resulting for even one hundred ingredients, let alone thousands of ingredients. Examine whether it is better to create a nutrient vertex label or nutrient vertex properties.

Imagine the possibilities for applications built using the ingredient properties. Look in the refrigerator and discover that you have mushrooms and beef, and query the graph database to find a recipe to cook, such as Beef Stroganoff. With the coming possibility of tagged food in your refrigerator, you could even have your fridge tell you what’s for dinner tonight, given the items stored.