Talk:Food Logging Data Standard
Comments from stevepburgess
Hi John. This looks very interesting / valuable and is something I would want to support in my PWA should my user base ever extend beyond just me :slight_smile:
The data model I have developed is based on my needs as a user. As such it is similar to the model you have outlined, but my model also allows for shared and non-shared user amendments to food metadata, categories and photos.
Some points of note:
- ingredients of individual food items are not recorded in a separate table with a one-to-many relationship. ingredients are available for review (if supplied by Open Food Facts in the âingredients_text_with_allergensâ field) as human readable text (allergens highlighted). Ingredients for McCance and Widdowson entries are not available.
- Depending on the data available from Open Food Facts, users can specify a quantity of a food item (e.g. ml or grams) or can specify a number of servings. For example, they can say they had 2 large Asda Free Range Eggs and this will be recorded as 2 servings in the Servings field and 136g in the quantity field of the diary table. This is not supported for McCance and Widdowson where the data available is just per 100g or ml. I may allow users to specify serving sizes to augment the M&W dataset.
- Meal Types. I have opted for Breakfast, Morning Snack, Lunch, Afternoon Snack, Dinner, Evening Snack and âDaily Allowancesâ. For example, users can allocate a certain amount of (say) milk to consume (e.g. in tea) throughout the day without having to record every usage of a spash of milk. Users can label these meals as they prefer (e.g. many folk in the North would have breakfast, dinner, tea rather than breakfast, lunch, dinner). I may allow further meal types to be added. Time of consumption is not recorded.
- Users can change meal names, brands and photos to their own preferences. For example, McCance and Widdowson uses quite an technical sounding convention for naming foods (e.g. Pepper, Capsicum, Red, Raw). The user may just want to specify âRed Bell Pepperâ. Open Food Facts, as a user-contributed data source, is prone to spelling, stylistic, other typographical or omission issues (e.g. item 0037600209571 is listed as Chopped Pork and Ham but the name doesnât include the word SPAM :slight_smile: ). User changes are user specific and do not affect the data seen by other users (though I may allow other users to accept âsuggested changesâ from other users).
- Open Food Facts and McCance and Widdowsonâs categories are ignored and if the user doesnât specify a category their food diary remains uncategorised (except for meal selected). Users can categorise by a limited but (I hope) sufficiently differentiated category list: âBreads, Grains, Seeds and Starchy Vegâ,âCondiments and Add Onsâ,âDairy and Dairy Alternativesâ,âDrinks/Beveragesâ,âFats and Oilsâ,âFruitâ,âPrepared and Ready Mealsâ,âProteins (Meat, Fish, Eggs)â,âProteins (Plant Based)â,âSavoury Snacksâ,âSweets and Dessertsâ,âVegetables (Non-Starchy)â. I suspect this will develop/be refined over time.
- Users can maintain a list of favourite items which allows for rapid re-use of frequently used products without having to scan the barcode or perform a search each time.
I suppose my question, in light of the above, is do you envisage the ânameâ of the food item being that from the original data source or the user preferred value (or both)? Similarly, the URL of the image. Images are generated dynamically (then cached) and there are different URLs for user provided images and those from the Open Food Facts. If the URL provided cannot find an image, a placeholder image is returned. With a user provided image, the URL will show an image to all users if the uploader has allowed sharing. If they havenât only they see the image - others will see a placeholder.
I guess developers may have concerns about other apps continuing to retrieve images from their servers if the user has migrated away?
Sorry Iâve waffled on a bit. Hope this all makes sense and offers a useful perspective.
Response from JohnGom
Thanks for the feedback. Responding to the points in turn:
- Ingredients: The Conceptual Data Model diagram shows these to show the development of the design, but they are not included in the final model. I'll try and clarify this
- Servings: I think it might be a good idea to capture the unit that the user selected for input (e.g. serving) in addition to the unit that was derived from this for analysis. This could potentially all removal of the unit metadata which could make things simpler
- Meal Types: I'm guessing you can map your meal types onto any received as long as the list doesn't get too long. I like the idea of a "daily allowance" meal type too. Will add that in
- User customisation: The idea if including the names in the meal log is to show what was presented to the user when they selected the food from the source. Allowing users to rename that is potentially outside the scope of a common standard as it's more of a value add for individual apps. However, I was thinking of adding a placeholder for custom metadata so that apps can use the core format but extend it as required. I'm assuming that user-specified names for food are "global", i.e. not specific to an individual meal, i.e. the extension could be part of the Metadata format rather than needing to be in the Meal format
- Categories: I don't think I want to introduce categories into the core standard as there are so many variations on these. Perhaps an extension to the Metadata would allow this to be recorded?
- Favourites: I considered this but it feels like it is again something app-specific. When importing data from another app I would hope that favourites could be determined automatically from historic diary entries
- Images: As for the product name this should be the image that the user initially used when identifying the product from the source. I think the ability to store a custom image is app-specific and I wouldn't expect apps to have to expose their images to other apps to support data exchange. It may be you could store your own image URLs in custom metadata and maybe obfuscate this somehow if you don't want other apps to be able to use that data.
Further comments from stevepburgess
I take the points about some functions are value-added features specific to apps that may be implemented in different ways.
Although my app allows users to explicitly add food items to favourites (and optionally categorise them) I like the idea of having the top diary items available too so have implemented that in my app. Thanks!
The issue of names of food items is an interesting one. For example with my app, if the user doesnât customise the product name or brand then the one provided by the latest version of the data source is used. The product name isnât stored in the diary. Only the the unique ID for the food item is saved to the diary (in addition to date, meal, quantity and servings).
My app retrieves the Open Food Facts JSONL file and refreshes my appâs database every evening. This means that if the source (e.g. Open Food Facts ) for a particular food item is changed by someone in the OFF community and they have updated the Name or Brand, then the name/brand displayed in the app would change wherever/whenever it was used. The same applies to images. And,indeed, nutritional info (I want the user to benefit from corrections even retrospectively). If the user customises the name, brand for a particular food item then changes to the original data source for these items are ignored for that user.
The thing I forgot to mention is in addition to showing a traffic light graphic based on the established recommended UK ranges PER PRODUCT (Food labels - NHS) users can also specify their own colour coded DAILY thresholds. For example, users following the late Dr Moselyâs Fast 800 Keto diet could have Carbs show as red if they eat more than 50g in a day. Protein show in Green if they eat more than 50gâŚetc. The user can set traffic light thresholds for any of the main nutrients (e.g. fat, sat fat, sugar, carbs, protein, salt, fibre). Again this is probably not for the model.
If youâre interested in seeing it in action, the app is at https://nutrit.app/. It is a PWA that can be installed on Android and Windows and âadded to homeâ on iPhone (I havenât tested it in iPhone thought). It is completely free and I have no plans to add to app stores at the moment.
Response from JohnGom
Regarding the name I guess if you have a local database then looking up the name and nutrients on-the-fly won't be a big concern when generating an import.
I think it should be possible to add your traffic light thresholds by extending the metadata.
Further comments from stevepburgess
The example you have given of âwhite coffee powderâ raises another question about using volume instead of mass particularly for products whose nutritional info is probably given in grams.
In the JSON example the user has said they had 15ml of coffee (1tsp) but apps would need to know the mass unless the data source provided a conversion formula.
McCance and Widdowson provides the specific gravity of liquids and some semi-fluids (e.g. yoghurt) but not âflowingâ solids like granulated sugar.
Response from JohnGom
This is a valid concern. I guess it is the responsibility of the food logging app to do these conversions, but in terms of importing data from another app you would want the unit to correspond to the unit used in the source, i.e. if the source quoted nutrition per 100g then the unit should always be g, but if nutrition is quoted per 100ml then the unit should also be ml.
Comments from haowang-bioinfo (transcribed from Slack)
Brief Comments:
- Itâs a great idea to enable user control over data transfer between applications.
- Overall, the standard is well thought out and provides a strong starting point.
- The points listed under the Drivers section are excellent.
Suggestions and Questions (according to law of Occamâs razor):
- I really like the Conceptual Data Model. However, the diagram is a bit unclear. For example, it seems that âMeal Typeâ could logically be part of the âMealâ table.
- Consider supporting only English for column names and string values initially, as translation could be the work of UI/UX development.
- It may be more practical to focus on a unified JSON format that includes both meal and metadata information. CSV could be excluded at this stage, since it can easily be derived from JSON for human-readable needs.
- In a meal-based food logging context, Facet/Type values might be more useful as absolute quantities rather than per 100g/ml.
- Why are both the Source and Code fields needed? Could their roles be clarified or consolidated?
- Detaching recipes from the core model might make the food diary more lightweight in the early stages.
- I like the idea of including macronutrient groups by default, while allowing extension to micronutrients later.
Response from JohnGom
I really like the Conceptual Data Model. However, the diagram is a bit unclear. For example, it seems that âMeal Typeâ could logically be part of the âMealâ table.
- I've separated out Meal Type so the model follows third normal form, even though it only has a name attribute
Consider supporting only English for column names and string values initially, as translation could be the work of UI/UX development.
- I still think we will need "short cut" identifiers for fields so that we don't have to provide the metadata for every single Meal entry. Hance supporting different languages comes for free
It may be more practical to focus on a unified JSON format that includes both meal and metadata information. CSV could be excluded at this stage, since it can easily be derived from JSON for human-readable needs.
- I would like to cover this too as I think this will be important for a REST API. The main thing I'm not sure about for an API is whether to combine the meatadata and meals in a single payload or pre-register the metadata in advance so it doesn't have to be supplied every time. I think the latter would be safer but will result in bigger payloads.
In a meal-based food logging context, Facet/Type values might be more useful as absolute quantities rather than per 100g/ml.
- That was my intention, so in the example the first like is 30g of Corn Flakes, i.e. the total value
Why are both the Source and Code fields needed? Could their roles be clarified or consolidated?
- The source is where the code came from, e.g. USDA database, OpenFoodFacts, etc. so it is needed in order to understand whatthe code means
Detaching recipes from the core model might make the food diary more lightweight in the early stages.
- That is why I just added a single field for Recipe
I like the idea of including macronutrient groups by default, while allowing extension to micronutrients later.
- To be clear, nothing is by default, it is all defined in the metadata