Folksonomy: Prix

1

Bonjour,

Je ne sais plus si une discussion au sujet de l’ajout des prix avait été commencée sur Slack.
Je viens de commencer et je voulais savoir ce que vous en pensiez.

Sur Cônes vanille - Carrefour

J’ai ajouté
price_w58722141_1646490566

Le w58722141 correspond au magasin dans OpenStreetMap : Way: ‪Carrefour Contact‬ (‪58722141‬) | OpenStreetMap

La limite que je vois à ça, c’est pour les livraisons de course. Typiquement, j’utilise de plus en plus PicNic pour avoir mes courses, et je ne pourrais donc pas associer de magasin.

Le 1646490566 c’est le timestamp Unix du moment où ça a été acheté.

ça permettra de voir l’évolution du prix dans le même magasin et de voir s’il est vendu au même prix ailleurs aussi.

Pour la valeur j’ai mis EUR2.27 pour indiquer que c’est un prix en euro et j’ai utilisé un point plutôt qu’une virgule pour que ça soit plus facile à traiter ensuite

Des avis ?

2

Utiliser un identifiant OSM pour le magasin va poser un problème car ces identifiants ne sont pas stables dans le temps.

Pour la France, le mieux ce serait le SIRET de l’établissement… mais c’est pas transposable à l’étranger (ou alors en préfixant avec FR, comme les identifiants de TVA, potentiellement présent sur le ticket de caisse). Le SIRET permettrai de prendre en compte les livraisons.

Pour le timestamp… l’epoch unix c’est quand même pas le plus lisible: YYYYMMAA ça pourrait être préférable, non ?

Vraiment pas évident d’ajouter une info multi-facettes comme ça !

3

Je suis un peu dubitatif sur notre capacité à gérer simplement les prix. Mais c’est un bon exercice pour comprendre les limites de Folksonomy Engine et l’améliorer.

Tout d’abord je n’aurais pas ajouté des variables à la propriété. Ça va conduire à créer autant de propriétés qu’il y a de sessions de relevés de prix. Au pire il faudrait utiliser les espaces de noms (namespaces) qui pourraient éventuellement permettre de lister tous les prix :

price:w58722141:1646490566 -> EUR2.27

L’espace de nom price:w58722141 permettrait ainsi de lister tous les prix d’un magasin ou tous les prix d’un produit dans un magasin dans le temps (ce n’est pas encore possible). Le problème des namespaces c’est que l’ordre compte : tu ne peux pas avoir facilement tous les prix d’une date donnée dans tous les magasins.

Peut-être pourrait-il être plus sage de renvoyer la partie variable dans la partie réservée aux données :

price ->  {date: 1646490566, shop: "w58722141", amount: "EUR2.27"}

À propos du prix, il semble y avoir une norme ISO récente qui traite du sujet, ISO 21041:2018 : https://www.sis.se/api/document/preview/80008035/

En tenant compte des judicieuses remarques de @cquest on aurait :

price:FR:82773344500015:2022-03-08T09:02 -> EUR2.27

ou bien

price -> {shop: "FR:82773344500015", date: "2022-03-08T09:02", amount: "EUR2.27"}

Ou alors il faudrait introduire une forme de réification ou des quadruplets. Exemple :

p1 -> tel_ean -> price -> EUR2.27
p2 -> tel_ean:p1 -> date -> 2022-03-08T09:02
p3 -> tel_ean:p1 -> shop -> FR:82773344500015
4

Merci à tous les deux pour vos remarques très pertinentes.

L’idée du SIRET me plait beaucoup, oui. D’autant plus qu’elle répond à la problématique des services de livraison de course.

J’avais pensé à utiliser OSM et les timestamp Unix parce que dans mon esprit les données dans la folksonomy ne sont de toute façon pas destinée à être lue sans traitement.
De la même façon qu’on ajoute les codes Wikidata dans les taxonomies pour afficher un lien vers Wikidata sur les pages OFF, je me dit que mettre un id OSM ou un timestamp Unix servira ensuite à afficher l’information en remplaçant l’id OSM sur une page par une carte directement.

Ce que montre Charles dans son exemple me convient aussi pour les dates, à mon avis on peut même squeezer un peu plus et enlever l’heure pour ne garder que la date.

5

Si on peut utiliser un format qui permet le traitement tout en étant plus compréhensible par un humain, autant lui donner la priorité. Les dates ISO sont une norme, plus forte de plus qu’un standard comme l’epoch unix.

Je pencherai pour:
price:FR82773344500015:2022-03-08 = 2.27 EUR

  • le FR (ISO 3166 — Wikipédia “alpha2”) est partie intégrante du code qui suit, donc pas de séparation
  • je ne vois pas l’intérêt d’avoir plus que la date au niveau précision, et ça évite le problème des “:” (ISO 8601 — Wikipédia)
  • le montant me semble plus généralement indiqué avec le code monnaie en suffixe (ISO 4217 — Wikipédia)
6

Merci Christian.

J’en prend bonne note. Je vais modifier ce que j’ai fait et continuer avec ce nouveau modèle.

7

J’ai voulu ajouter plusieurs prix aujourd’hui mais

" Can countain only minus letters, numbers, “_”, and “:” "

donc tirets impossibles

8

Bonjour,
Je viens de tomber sur votre discussion qui m’intéresse beaucoup.
Dans les grandes lignes je suis en train de développer une application pour connaitre les prix. Je me sers de l’api https://world.openfoodfacts.org/api/v0/product/xxx pour avoir juste la désignation et une base sur un serveur perso pour les non référencés (lampes/produits d’entretiens et j’en passe)
J’ai aussi plusieurs table pour les enseignes puis magasins (entrer par géolocalisation). Puis les prix.
Pour le moment c’est en béta, beaucoup de chose a voir.
Mais j’attache une importance sur le fait que je ne veux en aucun me faire tenir vous voyez ce que je veux dire par tel ou tel distributeur pour mettre en avant leur promo, c’est l’utilisateur qui donnera l’info.
Cela serait un plaisir d’échanger
Amicalement
Christophe

9

Bonjour Christophe

Ravi de te lire.

Si tu as besoin de beta-testeur n’hésite pas.

Je suis sur iPhone

10

Bonsoir,
Merci pour ta proposition, petit soucis pour le moment c’est sous android, j’ai peut être trouver moyen de le faire aussi sous IOS, a tester.
Par contre, c’est une version Beta (fonctionnelle)
dans mes to-do
Authentification (pour le moment il y a rien )
Voir toutes les solution openfact, car j’ai découvert par hasard qu’il y a aussi product / beauty… donc je doit gérer cela.
Pour les lieux d’achat pas de restrictions cela ira de la grande surface au distributeur (j’ai prévu mes bases pour cela )
Par contre je travail beaucoup avec la géolocalisation, ne pas travailler avec, me pose soucis, mais a voir.

Dés que je peux mettre un lien je le fait

11

J’ai ouvert le bug et lancé un appel pour un dev python qui nous coderait ça. C’est pas grand chose à faire (2 lignes à modifier plus les tests). Les 2 lignes je sais faire mais pas les test (et c’est important).

12

Le bug est corrigé et en production, ça doit donc être possible, je vous laisse tester.

13

Very interesting feedbacks and information in this thread about prices in Austria, Germany, Slovenia, …

The text is a bit long, but well worth reading.

1 Like
14

Bonjour !

Je m’intéresse en ce moment au sujet de l’ajout des prix dans OpenFoodFacts. J’ai posté un message dans le Slack - canal #prices - et j’ai commencé à regarder les keys déjà présentes dans https://api.folksonomy.openfoodfacts.org

@Tacite tu as pu continuer ton travail ? Je ne vois que 7 products avec la key “price” :sweat_smile: Dont 1 que je viens d’ajouter.
J’ai choisi le format suivant :

price:1.85€, 03/10/2023, Grenoble, L'éléfàn
  • mais si je vais dans un autre magasin et je repère un autre prix, cela va l’écraser, alors qu’1 produit peut très bien avoir 2 prix dans 2 magasins différents…
  • pareil pour suivre l’evolution du prix dans le temps, c’est faisable mais difficilement (en regardant les versions)

@Info_Prix tu as dans l’idée de faire aussi du push des données récoltées via ton application, pour continuer à enrichir OFF ? Je suis partant pour tester ton app si jamais :slight_smile: Et tu as opté pour quel modèle de données ?

Je serais au OpenFoodFact days le samedi 21 octobre au moins si jamais des personnes souhaitent en discuter de vive voix. J’imagine que cette question a déjà été discutée et débattue, mais avec l’inflation actuelle, et le besoin des utilisateurs (nous y compris) de comparer les prix et voir leur évolution (comme le message au dessus :point_up_2: ) ca peut être cool d’y réfléchir au sein d’OFF :slight_smile:

Raphael

15

Bonjour Raphaël / @bcd4e6 !

On avait essayé de converger vers le standard suivant, mais ça n’empêche pas la discussion :wink: :

  • une propriété qui utilise des namespaces permettant de faciliter la saisie ou bien d’effectuer des recherches plus précise :
    • d’abord le namespace price permettant de rechercher tous les prix
    • ensuite le namespace du vendeur, typiquement le magasin, sous une forme non-ambiguë : pour cela on avait choisi l’identifiant SIRET, par exemple FR82773344500015 mais peut-être peut-on trouver plus simple ; on n’avait pas choisi les coordonnées GPS car elles peuvent poser plein de problèmes (trop précises, ne convenant pas aux sites web marchands, etc.)
    • ensuite la date au format international ISO 8601 (2023-09-25) qui le plus répandu et le moins ambigu au niveau international ; il est facile à trier et permet plus facilement d’extraire des prix par année, puis mois, puis jour
    • Cette propriété serait donc par exemple : price:FR82773344500015:2022-03-08
  • la valeur, quant à elle, est le prix avec son unité : ici on peut se permettre d’être assez souple parce qu’il y a peu d’éléments signifiants : la monnaie, les entiers, le séparateur décimal, et les chiffres après le séparateur décimal ; tout ça c’est facile à traiter

Au final ça donnerait donc par exemple : price:FR82773344500015:2022-03-08 = €2,67

Si tu es là le 21 ce serait en effet une bonne idée de proposer un atelier sur ce sujet. Je suis persuadé que ça va intéresser d’autres contributeurs.

16

Merci pour ta réponse détaillée !

Dans vos discussions, avez-vous évoquez la création d’une table dédiée ? Je crains que le format Folksonomy soit un peu limité pour le besoin ici… :sweat:

J’ai commencé à tester un format de données + DB + API avec Supabase, pour voir un peu les possibles difficultés. Le format v0.1 est le suivant

Screenshot from 2023-10-09 19-53-25

  • product_code : code barre
  • product_source : food, beauty, pet…
  • location : en effet le plus compliqué à remplir facilement…
  • j’ai séparé price (ou amount ?) et currency pour plus facilement requêter et filtrer
  • en regardant la DB folksonomy, il reste peut-être à rajouter des champs comme owner et editor
  • et savoir si l’entrée est modifiable, ou pas

Bref je vais proposer un atelier en effet :slight_smile:

17

For those of you in this thread interested in storing price data, there’s a new OpenFoodFacts project to create a separate database & API, named “Open Prices”.

More info in this wiki page, as well as the #prices Slack channel.