Changes

Jump to navigation Jump to search
workshop result in french
== French ==
'''Participants:''' Yassine, Antoine, Gustave, Anthony et Heyman

=== Discussion ===

==== Sur les données et leur organisations ====
OFF n'est pas seulement sur l'alimentaire aujourd'hui.

Penser à ça depuis le début.

BDD actuellement orientée food.

GS1 - données GDSN --> mais pas vraiment bon format

GS1 voc --> extension de schema.org pour mapper tous les champs du GDSN - 400 propriétés

OpenBATRA - donnons le même format aux petits producteurs (GSDN + extension schema.org)

OpenFoodFacts --> mongodb, schema moins fort, c'est un choix qui pourrait être gardé.

Car on ne sait pas les projets qui seront ajoutés, donc être évolutif.

À l'heure des LLM, la donnée structurées (quelque soit la donnée), est ce qui est important.

Proposer aux producteurs un repository de données : fiche PDF, photo, données GS1 --> et en déduire les données structurées

Aujourd'hui identifiant unique = GTIN

À venir passeport digital du produit: de sa début de vie au tri des déchets. Avec un registre central.

C'est surement le format GS1 qui va s'imposer.

Forum du GS1 en ligne cette semaine, note: il sont à fond dans l'IA (répondre à des questions de l'utilisateur).

Note: Retour d'expérience sur la mise en norme du co-voiturage,

qui a été difficile à supporter pour des acteurs existants,

mais l'interopérabilité à la fin gagne.

==== Plus haut niveau ====
Quel est l'objectif d'Open Food Facts:

<nowiki>*</nowiki> initialement le but est transparence des données

<nowiki>*</nowiki> aujourd'hui -> la fiabilité est un peu plus importante

<nowiki>*</nowiki> mais le but ultime: répondre à une problématique, à une prise de décision

Ce produit est il bon ou pas bon - selon mon contexte.

Mais il serait important aussi d'avoir des indices de fiabilité (en croisant des informations par exemple).

Nutriscore: n'est pas intra-catégorie

En Angleterre - un score intra catégorie -

L'EREN a pensé que pour changer les habitudes le non intra-catégorie est le mieux.

Sur l'environnement c'est très important de ne pas faire de l'intra-catégorie, car les ordres de grandeurs sont encore plus grand.

OFF est au carrefour de plein de sources de données et d'usages.

OFF est déjà sur plein de niveaux, rien qu'en voulant avoir les données sur plein de produits du monde,

Faire des indicateurs est encore une autre niveau, tout le niveau accès au public et facilité de contribution est aussi important.

Regarder du côté d'Open Street Map qui a aussi des données très hétérogènes: heure d'ouverture d'un magasin, prix de la bière, dénivelé.

Ils ont laissé les contributeurs créer leurs données et leurs applications. Par exemple sur l'escalade on a plein de données super précise.

Peut être séparer:

<nowiki>*</nowiki> collecte donnée et qualité

<nowiki>*</nowiki> création des algos etc.

<nowiki>*</nowiki> création de nouveaux cas d'usage

Question à se poser suis je B2C ou plutôt un écosystème avec des start-up, les producteurs, le grand publique.

Ici OFF était plutôt grand publique: mettre de l'info fiable à destination du grand publique pour ses décisions (surtout d'achats)

dans des domaines ou les enjeux sont vraiment importants.La qualité de donnée est ici supérieur par rapport à Open Street Map.

Le modèle très centralisé de Open Food Facts aura peut être du mal à passer à l'échelle.

L'aspect crowdsourcing + données directes restera.

Si on est flexible sur les données c'est à celui qui ré-utilise qui doit filtrer.

Il faut une norme tout de même pour structure la données.

Stack technique d'Open Food Facts est aujourd'hui un frein à la contribution.

Fiabilité: sur Open Street Map on doit indiquer dans quel context on a eu la donnée.

(sur Open Food Facts c'est encore dans les cartons de mieux poser cette information)

Indicateur dépend vraiment aussi du contexte: par ex nutri-score peu important pour un diabétique.

La contextualité est très importante.

Open Food Facts est une brique de l'aide à la décision, pas forcément son rôle.

Comme ré-utilisateur ça me donnè accès à un grand nombre de donnée.

Et la notion de qualité dépend du context aussi et de ce qu'on cherche.

Est-on un point nodale ou une solution utilisateurs finaux.

Remplir les trois est trop difficile.

En même temps aujourd'hui l'app mobile aide à sécuriser la contribution et l'impact d'Open Food Facts.

Food data centrale aux USA (publique). Mis à jour tous les mois, avec GS1.

USDA est aussi assez important.

Peut on avoir des prises d'initiatives publiques.

La verticalité du processus est un enjeu intéressant. Mais aussi permettre aux acteurs extérieurs de se plugguer au niveau de leur choix.

Ouverture: Peux-on avoir des choses plus politiques dans Open Food Facts ? Matcher par exemple les déclarations correspondent (vérification).

Faut-il intégrer ce genre d'informations ?

Politique actuelle de OFF: le plus important fact base

Exemple aussi, de la répartition de la valeur.

=== Conclusion ===
Open Food Facts ne doit pas gérer tous les flux entrants (acquisition) et sortant (applications)

Au moins une verticale pour la survie du projet (capturer les données) et en facilitant aussi le boulot de ré-utilisateur.

(ex Aujourd'hui un problème est que le site d'openstreetmap.org ne révèle pas du tout l'ensemble du projet)

Important de garder les deux cannaux acquisition: producteurs, crowd-sourcing.

Se baser vraiment sur le GTIN (et ses évolutions) et la compatiblité GS1 pour préparer le futur.

La marque Open Food Facts doit être synonyme de fiablité de l'information,

pour porter aussi à plus de contributeurs grand publique.

Avoir aussi ce côté aussi contre pouvoir / indépendance, aide à la recherche et confiance.

Continuer la componentisation du projet, pour favoriser la ré-utilisation à différents niveaux.

== English (automatic translation) ==
229

edits

Navigation menu