Skip to content
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

Support for updated Nutri-Score formula and comparison between old and new Nutriscore #7450

Closed
Tracked by #5517
stephanegigandet opened this issue Oct 6, 2022 · 10 comments
Assignees
Labels
✨ Feature Features or enhancements to Open Food Facts server 🚦 Nutri-Score 🎯 P0 ⏰ Stale This issue hasn't seen activity in a while. You can try documenting more to unblock it.

Comments

@stephanegigandet
Copy link
Contributor

stephanegigandet commented Oct 6, 2022

Problem description

The Nutri-Score formula is going to be updated:
https://www.aesan.gob.es/AECOSAN/docs/documentos/Nutri_Score/2022_main_algorithm_report_update_FINAL.pdf

The EREN research team is very interested in having the new formula computed on OFF.

Desired solution

Compute both the old and new Nutri-Score, enable comparisons.

Part of

@stephanegigandet stephanegigandet added ✨ Feature Features or enhancements to Open Food Facts server 🚦Nutri-Score https://world.openfoodfacts.org/nutriscore labels Oct 6, 2022
@stephanegigandet
Copy link
Contributor Author

The PDF contains a summary of the changes:

− In the main algorithm
o A modified Sugars component, using a point allocation scale aligned with the FIC
regulation of 3.75% of the 90 g reference value, with up to 15 points [1]
o A modified Salt component, using a point allocation scale aligned with the FIC
regulation of 3.75% of the 6 g reference value, with up to 20 points
o A modified Fibres component, using a point allocation scale of 3.75% of the 30 g
reference value (as recommended in various EU countries), and with a starting point
set at the value aligned with the claims regulation for the claim of “source of fibre”,
with up to 5 points
o A modified Proteins component, using a point allocation scale aligned with the
claims regulation of “source of proteins” of 3.75% of the 64 g reference value, with
up to 7 points
o A modified ‘Fruit, vegetables, legumes’ component, with the removal of nuts and
oils from the ingredients qualifying for the component
o A simplification of the final computation, with a removal of the protein cap
exemption for products with A points ≥11 and fruit and vegetable points ≥5
o A modified final threshold between A and B, set at -1/0 points
6
− In the ‘fats, oils, nuts and seeds’ component
o The inclusion of nuts and seeds within this category, based on their nutritional
composition in fats
o A modified Energy component, set as an ‘Energy from saturates’ component, with
a point allocation scale of 120KJ/point
o A modified protein cap threshold, set at 7 points for proteins to be taken into
account
o A modified ‘fruit, vegetables and legumes’ component, with oils from ingredients
qualifying in the component included as qualifying (e.g. avocado and olive)
o A modified final threshold between A and B, set at -6/-5
− Specific rules for red meat products within the main algorithm for general foods
o Based on their position in FBDG
o A modified protein component, with a reduction in the maximal number of points
attributed for red meat and products thereof, proportionate to the ratio of heme
iron to total iron content in meat and products, set therefore at 2 maximal points
for proteins

@john-gom
Copy link
Contributor

I've been looking at the code and reading the document and it seems like the following could be significant factors in the development:

  1. Work on revisions for the beverages category is incomplete so these would need to continue to use the old algorithm. Also, milk beverages are being moved out of the main category so we'd need to still use the old main category algorithm for these. Is it going to confusing to be using the old algorithm of some products and the new one for others? Should we wait for the beverages work to be completed first?
  2. The change of the "fruits, vegetables and nuts" category to be "fruit, vegetables, legumes" will need updated ingredients analysis in order to determine the correct algorithm to use

@stephanegigandet stephanegigandet self-assigned this May 29, 2023
@stephanegigandet
Copy link
Contributor Author

  • Work on revisions for the beverages category is incomplete so these would need to continue to use the old algorithm. Also, milk beverages are being moved out of the main category so we'd need to still use the old main category algorithm for these. Is it going to confusing to be using the old algorithm of some products and the new one for others? Should we wait for the beverages work to be completed first?

The new beverages algorithm is now available, so it's a good time to implement both new algorithms. In practice there will be a period of 2 years starting from end of december 2023 where both versions will co-exists on products. We will need to compute both versions for some time.

  • The change of the "fruits, vegetables and nuts" category to be "fruit, vegetables, legumes" will need updated ingredients analysis in order to determine the correct algorithm to use

Right, in practice we will need to compute both.

@stephanegigandet
Copy link
Contributor Author

Initial ideas:

  • suffix _v2 to nutriscore fields: nutriscore_v2_data, nutriscore_v2_score, nutriscore_v2_grade
  • create new /nutri-score-v1 and /nutri-score-v2 facets, to ease comparisons
  • create a new /nutri-score facet, that we map to v1 first, and that we can switch to v2 when we decide to prioritize it over v1

@teolemon teolemon added this to the Nutri-Score v2 milestone May 29, 2023
@alexgarel
Copy link
Member

don't you want to transform to an inner structure @stephanegigandet ? nutriscore_v2: {grade:…, data:…, score:…} ?

@stephanegigandet
Copy link
Contributor Author

stephanegigandet commented Jun 5, 2023

don't you want to transform to an inner structure @stephanegigandet ? nutriscore_v2: {grade:…, data:…, score:…} ?

@alexgarel It's definitely an option. Maybe something like nutriscore{version : v1, v2}[grade,score,data} with a way to be able "current" and "latest" as the version in API requests.

Copy link
Contributor

This issue has been open 90 days with no activity. Can you give it a little love by linking it to a parent issue, adding relevant labels and projets, creating a mockup if applicable, adding code pointers from https://github.com/openfoodfacts/openfoodfacts-server/blob/main/.github/labeler.yml, giving it a priority, editing the original issue to have a more comprehensive description… Thank you very much for your contribution to 🍊 Open Food Facts

@github-actions github-actions bot added the ⏰ Stale This issue hasn't seen activity in a while. You can try documenting more to unblock it. label Dec 31, 2023
@stephanegigandet
Copy link
Contributor Author

We now compute both versions of the Nutri-Score and have facets to compare them.
Also see https://docs.google.com/document/d/1gmUY4AKJ1I6w19VjH4gk3ducqZBVAe0mwVtPsI3QaMM/edit#heading=h.p341d8ptwjy for details.

@alexgarel
Copy link
Member

🎉

@teolemon teolemon added 🚦 Nutri-Score and removed 🚦Nutri-Score https://world.openfoodfacts.org/nutriscore labels May 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ Feature Features or enhancements to Open Food Facts server 🚦 Nutri-Score 🎯 P0 ⏰ Stale This issue hasn't seen activity in a while. You can try documenting more to unblock it.
Projects
Status: Done
Development

No branches or pull requests

4 participants