Quality facet - Nutrition - serving_size="serving" for data-quality

[TaciteOFF]

What

Hello,

It seems that a few users (or applications) sometimes mistakenly indicate "serving" as the portion size.
A facet to detect and correct this could be useful.

Thanks

Bonjour,

Il semblerait que quelques utilisateurs (ou applications) indiquent parfois par erreur "serving" comme taille de portion.
Une facette pour détecter et corriger ça pourrait être utile.

Merci

Part of

• 🧽 Data quality (tracker) #5538

[teolemon]

• See also Expose portion size as a facet #1008

[github-actions]

This issue is stale because it has been open 90 days with no activity.

[stephanegigandet]

corresponding code is in DataQualityFood.pm

[CharlesNepote]

• There are more than 11,200+ products with "serving" as serving_size. It is not brought by a particular app, it's just users.
• 1900 of 11,200 do not have fat value (and probably no nutritional values at all), so serving_size containing "serving" should be deleted in this case
• Probably many products with "serving" have nutrition facts for 100g and not for a serving size.
• 990+ of them have a data quality error already detected, en:nutrition-data-per-serving-serving-quantity-is-0 for nearly half of them

This would lead to increase data quality errors from 5.78% to ~6.16% for an issue that is having no impact on Nutri-Score, Nova, etc. for at least more than 10%.

So I would be in favour to:

• 1. Delete all the value "serving" in the serving_size as:
  • when users are often seeing this value they can think it's a good value
  • it's easier to complete an empty field than a completed one
  • it's not worse to have an empty field than a false one
• 2. Create the data quality error facet to manage the new ones

Maybe 2 can be done before 1.

[benbenben2]

Create the data quality error facet to manage the new ones
@CharlesNepote Do you want only the case when serving_size="serving"?
Or do you want to generalize for all strings? (just thinking there..., we always expect some number in this field - like 20g, 20ml, for example - right? If yes, then, we could raise an error when there is no integer/number in this field. What do you think?

Just checked with Mirabelle, that could include some values like "-" (6), "une tranche" (1), "une noisette" (1), "une pression par narine" (1), "une cuillere à café" (1), "une biscotte g" (1), "tbsp" (1), "servingg" (1), etc.
But occurrence of those values (written in parenthesis) is nothing comparable to "serving" (11 199)

[CharlesNepote]

@benbenben2 yes why not. There are 227 different values for this field. Most of them are given once but it would be nice to detect it.

The hyphen (-) should not be included. I think it could be a good practice to always use it when we want to precise that there is no value (null).

@stephanegigandet can you confirm there is no reason not to have at least one number in this field?

[stephanegigandet]

It's a free form field, so we can have anything in it. We could have a warning when there isn't a number, but I wouldn't make it an error.

What would be interesting is a quality warning when we don't have a value for serving size, or we have a value that we can't convert to g/ml, AND we have nutrition facts indicated per serving. In that case, while we have nutrition facts, we can't compute Nutri-Score etc

[CharlesNepote]

@stephanegigandet

It's a free form field, so we can have anything in it. We could have a warning when there isn't a number, but I wouldn't make it an error.

Do you see some examples where a value without a number would be relevant?
If we look at what the users already entered, in the list I mentioned earlier, there are:

• "Non indiquée" (7), "Non précisé" (6), "Non précisée" (1), "Non spécifié (1)", "non communiqué" (1), "N.A" (1), "Not mentioned" (1), "No indica" (1), "nicht angegeben" (1), etc. => IMHO they should be converted to "-"
• "tbsp" (1) or "cuillère à soupe" (1) (but we're not sure if it's "one" tbsp, so I would say it's an error)
• to me, all the other values appear to be either errors, either values that can't be converted into a size in grams or ml.

So I would tend to conclude that:

• either there are values which should be converted into "-" (manually or automatically)
• either there are values that are not relevant, and, as such, should be "data quality errors"

So I would count all these values as "data quality errors" and, while we don't do it automaticaly, let people manually fix "non communiqué" into "-".

What would be interesting is a quality warning when we don't have a value for serving size, or we have a value that we can't convert to g/ml, AND we have nutrition facts indicated per serving. In that case, while we have nutrition facts, we can't compute Nutri-Score etc

At least we could do this. But honestly, currently quality warnings are not read by anyone (or so few). And there is currently no easy way to tag a warning as "checked". So for all the reasons I mentioned in this comment, I think it should be a data quality error.

[stephanegigandet]

I think it should be a data quality error.

OK.

[benbenben2]

@CharlesNepote, is it solved by this PR #8091?

[alexgarel]

I think so, let's close it :-)