I’m working on a pantry app. I want to use recipes compatible with Umai, but connected with a record of what ingredients are in the house. I have a more or less functional version that I’ve started using in my home. It’s rough around the edges and I keep thinking of new functionality that would improve its usability. But that’s a key part of why I’ve built it the way I have - the idea of enabling user control over both their data and the interfaces used to interact with it.
Rather than simply sharing my current version, I’m experimenting with writing a blog series that will break the app down and built it back up, step by step.
Three parts of the series are already published, covering showing an Umai-compatible recipe, browsing recipes and other resources in both the app and a data browser with dynamically registered panes, and connecting a pantry collection of groceries with recipes in which they are used.
I’d welcome any discussion related to making food-related apps interoperable, broader issues around interoperability that the blog series might raise, any thoughts about pantry app functionality - and anything else that might come to mind!
It’s great to see this, I love that we’re getting more apps working on the same data :D.
Regarding the duplication of ingredients/supplies; at first I wasn’t too convinced, but looking at my own recipes I agree that sometimes ingredients listed in a recipe are not enough to discern whether you can make a recipe or not. For example, in many recipes I have some ingredient as just “vegetables”, and I may use different vegetables every time I cook the recipe. So it would be very difficult to map vegetables to all the actual vegetables in the pantry. And sometimes, a particular vegetable may not be suitable to a given recipe.
Given this situation, I really like the UX of your app :D. I think it’s a good approach to show supplies in that way, and take advantage of the auto-complete to link them to the pantry. I could also see a way to auto-generate supplies for a recipe in the UI using some text parsing to have an initial version, and people can then amend whatever wasn’t parsed correctly.
Maybe the only improvement I’d suggest is to separate the “supply-driven” recipe from the recipe itself. Meaning, I may want to do a recipe multiple times, but each time I make it I use different ingredients. You could think about it as the recipe being a class definition, and the rendition with the supplies as an instance (I actually have something similar to this in Umai’s “kitchen” and I distinguish them by calling them “recipe” and “dish” respectively). Though honestly, you can just edit the supplies next time you make the recipe again. I’m just thinking out loud, food for thought .
Finally, I have some comments about interoperability that I just wrote in GitHub, in case we want to get more technical. But TLDR, even though it would be very difficult to get the Pantry data model interoperating with Umai, I think it’s great that different applications cover different use-cases. And the recipes themselves are interoperable, so that’s awesome :D. This would only be a problem if I were to implement a Pantry in Umai, or one of my other apps, but I don’t have any plans to do it at the moment so it’s nice to see other people covering different use-cases. It’s a perfect example of the power of Solid!
Thanks! I agree that the linking with ingredients could be further streamlined.
In a future part of the blog series I’ll actually be talking about the idea of specifying a “context” for the pantry that allows switching out different supply definitions, pantry product list, cookbooks and shopping lists. That might come close to separating the “supply-driven” recipe, though the focus is still on expressing the ingredients using a user-defined vocabulary rather than on describing a specific occurrence of making the recipe. For the latter, it might be interesting to think about how the Umai kitchen “dishes” might be persisted and shared between users? The BBC food ontology might be interesting in the way it uses a menu to combine multiple recipes ( Food Ontology )
I think any obstacle to interoperability is worth exploring - at the very least to identify how app requirements should be documented to enable cooperative interoperability, and perhaps even to identify practices that enable or prevent “interoperable serendipity”
They are already persisted to local storage, but I don’t think there is any value in sharing them because at this point the only thing they have different from the recipe is the number of servings (to recalculate ingredient quantities), and a checklist of whether an ingredient is ready or not. I don’t think any of this is useful beyond assisting during cooking, so it’s fine that this information is trapped on a single device.
I guess the ingredients checklist could be useful whilst shopping, but since you’re already doing that in the pantry app with the exact supplies, you’ve got it covered :D.
Two more parts of the pantry app blog series are now available.
The fourth part adds location and cookbook panes to answer the questions:
What can I cook?
What do I need to buy?
The fifth part introduces a pantry history event log as a point of truth - recognising that pantry data will only ever be a partial snapshot because updates are likely to be occasional and incidental as part of other activities.
Why not just look in the fridge?
Because a pantry app can act as a memory aid for what was in the fridge last time it was checked or used.
It turns out I have a specific use case for this, because as part of the pantry history event log I now want to be able to easily say that a recipe was cooked, check off which ingredients were used - and update both those that are no longer available and those that need to be added to the shopping list.
It looks like a CookAction - Schema.org Type is the most appropriate existing vocab.
I would use schema:recipe, schema:endTime, schema:supply for ingredients (as a sub property of schema:instrument) and schema:actionStatus to indicate whether it’s a potential, active or complete action.
@NoelDeMartin - any thoughts on how I might make sure this is Umai dish compatible? - the ideal would be that instead of just “completing” the dish, Umai could detect that a user has some kind of index of cook actions and offer to save it there.
I’d also imagine being able to annotate the cook action in other ways (perhaps in other apps), including through a schema:foodEvent, e.g. about who was there, comments from them, photos of the dish, notes for next time.
Umai only knows about schema:Recipe, so if you’re going to model this as a schema:CookAction I don’t think there’s any way to make it show up in Umai :(. But I think that’s fine, if you’re linking to the recipe with schema:recipe, that’s the recipe you could have in Umai, and use this document only for the ingredients spent with the schema:supply. This is actually how I’m modeling my Calories Tracker app as well, with a schema:ConsumeAction that points to a recipe with nutritional information, and also points to the “real” recipe with schema:sameAs. You can see an example here: create-meal.sparql.
.