Closed stephanegigandet closed 9 months ago
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
I've been looking at the code and reading the document and it seems like the following could be significant factors in the development:
New algorithm for beverages (2023): https://www.santepubliquefrance.fr/determinants-de-sante/nutrition-et-activite-physique/documents/rapport-synthese/update-of-the-nutri-score-algorithm-for-beverages.-second-update-report-from-the-scientific-committee-of-the-nutri-score-v2-2023
New algorithm for food (2022): https://www.santepubliquefrance.fr/determinants-de-sante/nutrition-et-activite-physique/articles/nutri-score/documents/rapport-2022-sur-les-modifications-de-l-algorithme-de-calcul-pour-les-aliments-solides-proposees-par-le-comite-scientifique-du-nutri-score
- 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.
Initial ideas:
don't you want to transform to an inner structure @stephanegigandet ? nutriscore_v2: {grade:…, data:…, score:…} ?
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.
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
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.
:tada:
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
5517