Create a script adding "Countries where sold" to products as prices are added

[teolemon]

Problem

• Create a script adding "Countries where sold" to products as prices are added
• This requires
• deducing the country from the associated stores
• checking whether the product already has this country in "Countries where sold"
• if not adding it.

Why

• We currently add countries yearly using scan statistics
• Prices allow us doing that in almost real time, much more aggressively and reliably than scan statistics

Related

discussion "Send data to Open Food Facts" : #223

[raphodn]

These contributions to OFF would be attributed to which user ? Is there a good practice ?

[teolemon]

• We could attribute them to the user adding the price (there's a mechanism build for Robotoff to do that)
  • https://github.com/openfoodfacts/robotoff/pull/350/files (sorry, at this point, I couldn't find a convincing auth method guide in the API ref or in the python package doc: https://openfoodfacts.github.io/openfoodfacts-python/usage/)
• We could add a comment to the edit ("added France because a price point was added in Open Prices")

[teolemon]

Here's an example: https://prices.openfoodfacts.org/app/products/8711200454464

[raphodn]

We could add a few rules :

• City, state & country where purchased : real-time
• Stores : real-time
• Countries where sold : after at least X prices in Y different locations in a given country ?

[raphodn]

For the auth, we could also create an openprices user, and pass a uuid per user in the comments.

I feel its simpler, and also better because the user didn't actually edit the product, its done in the background, so it would be weird for many users to have these products pop up in their "recently modified" list

foodvisor seems to have this mecanism

[teolemon]

@stephanegigandet @aleene @alexgarel @raphodn @raphael0202 would like your opinions on the matter.

• It would be very interesting to delegate the handling of those fields to Open Prices or Open Food Facts events (we have 3 kind of competing systems to store "Where it is sold" info, and 2 main sources (Scans and Prices)

[raphael0202]

The issue with the 'Stores' field is that it's dynamic: especially as we don't have any date associated to it, there is no way to know whether the information is still valid. I would be in favor of dropping completely the Stores field, along with the City, state and country of purchase, which I find of very limited interest (at least comparing to the kind of data Open Prices can provide).

Updating periodically the Countries field using Open Prices data sounds like a good idea to me though!

[alexgarel]

IMO, for the stores data, it is a data of interest, even if contrarily to Open Prices, this is not a "sold now" data, so I would keep it, as complementary to what Open Prices provides.

[aleene]

The discussion should be broaded to the question how Prices can and should be integrated into OFF. Although the shops and locations (and thus countries) from Prices offer more accurate and recent info, it should not be the only sources. OFF needs to be more strict and move away rrom the text fields, to structured data.