-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blueprint: generate an Ingredient database #135
Comments
+1 |
I support this. We could use the HowToSupply model, if I'm reading it right. |
meal planning and a shopping list would be great :-) |
I’m not sure if such a detailed database is necessary (like differentiating between different brands selling pineapples). But I’d really like to have some auto-fill option / maybe searchable dropdown list for ingredients for (a) faster editing and (b) a unified ingredient style. |
Necessary may not in every case. And the development in this direction would need some time, I know. It would be great if the developers could hold this idea in mind while they develop this great app.They have her an app with a great potential. |
Ok, let's be a bit fancy here. I get your point when typing in the recipes manually. How would you want the app to behave when importing a URL? The URL will have something like In the recipes we cannot link it back to the ingredients. The recipes are stored in a JSON file that is compatible with the standard form given by https://schema.org/Recipe. It would therefore not be 100% compatible. Do not get me wrong here: I am not saying this is impossible at all to create a database but first we/I need to know what you have in your mind and then check if this is realizable and what are the cost of if (in terms of functionality). |
If someone creates an ingredient with the name or alias "ham" cookbook should detect the word and recognize it as ingredient "ham".
If I understand it right, this JSON are the database and not an export of the database stored in Nextcloud? In my mind I see also/alternatively the possibility to edit a recipe, select a word like "ham", and get a dropdown list of ingredients and have, either the possibility to create a new one or replace it with one in the database. |
The
Not really. The JSON is just an except of this meta information that is easily parsable for a machine. Each recipe is saved as a single file withing the nextcloud. Additional files like images are downloaded as well and everything is packed up and stored in one folder. So far there was no database involved (except for the management of the NC's files). To allow for quick search and organization, these JSON files are once more parsed and cached in the main database. This allows to use the database whenever a quick operation is needed (page reload) but the whole data is saved in the JSON files. So if you just throw away the database and reread the JSON files from a backup everything is back on track.
For the manual inserting I am full with you. There a dropdown of something similar might be very useful. The biggest problem is the automatic import from a URL (which is most probably the more common case btw). |
I'm not sure If I understand it right. Why do you see a need for machine learning to be able to recognizing e.g. "ham" in a Text? Why do you not save the recipes into the NC Database if the JSON is a limitation for some enhancement? |
Because the text in the imported (!) JSON is not structured. It could read like If it was structured this was much easier in the first step because the amount would be clear at least. Still, this is not well-defined due to synonyms, trademarks in the ingredient's name or other semantic. A human can understand this easily but parsing requires quite some work. I just want to outline this comment that describes a shortcoming of schema.org standard and the concrete usage of a neuronal network to parse exactly that sort of data.
This has multiple reasons:
|
There is an old NY Times project for parsing ingredients, https://open.blogs.nytimes.com/2015/04/09/extracting-structured-data-from-recipes-using-conditional-random-fields/ Source: And a more up to date fork of it: |
Just as pointed out in the section takeaway of the first link you provided:
Unfortunately, the two provided projects run in python and a bit of ruby which is not PHP as we use in NC. Also we have no training data at the moment (which would be highly language-dependent). All in all I see the problem to solve the parsing as a whole separate point that might need to be addressed later. For now I see the priority to have a UI representation (especially for the editing part) and a backend storage implementation. To stick with the credo of JSON files as data storage and DB as cache, I see multiple ways:
Here I am open for discussion. Once we have the backend store the data and the frontend show the data, we can consider how to insert it (last resort: manual typing). |
There is an "old" project phprecipebook (https://github.com/nazgul26/PHPRecipebook) with a "self-filling" ingredient database on the background. It's not that detailed, but for the recipe it doesn't matter whether the ham is from trader a or b. This information is only neccessary for shoping. |
I feel like an ingredient database could be generated if the https://schema.org/Recipe actually uses the Cookbook might then try to convert The UI might offer this functionality, maybe offer a button to "convert" a field from a free-form to structured field. This would replace the free-form input with a set of inputs pre-filled with the information a parser would have extracted from it. The user can then easily correct errors. Cookbook could maintain a database of "known HowToSupply", but stored as a list of https://schema.org/Thing. This database can then be referenced when a user add a recipe, so that the same "thing" is referenced. A UI element like a searchable dropdown would be a good candidate. |
Let me try to summarize and extend on the ideas in this thread and add an example of how it might be done. I think we agreed on the fact that it might be helpful to have structured ingredients (amount, unit, name, ...) for the ingredients. As mentioned in schemaorg/schemaorg#882 one idea to give ingredients more structure is to use The schema.org properties I have in mind are listed below. Properties which I think should be stored with the recipe as a fallback but should be overwritten with data from the database when the JSON is delivered from the API. This would ensure names and prices getting updated in the database to cover all ingredients with the same identifier.
|
I could see this sort of thing becoming extremely useful when combined with sharing between users. UserA has 3 ingredients for the recipe Might be a wild idea, but would be awesome. |
Generate an Ingredient Database based on the recipe. Allow to enhance the Data about the Ingredient.
eg.
Toast Hawaii -> Ingredient: Toast, Ananas, Ham
Now you could enhance it with Data.
At the end you could calculate the material cost per meal. #116
You may connect to https://world.openfoodfacts.org/data to get additional Data.
You may search a meal by Ingredients or filter by allergies.
You may send a set of Ingredients to Nextcloud Tasks for a Shopping-list #127 #11
The text was updated successfully, but these errors were encountered: