Afin de répondre à notre mission, nous construisons au sein de notre consortium un langage numérique commun grâce auquel nous pouvons mutualiser les données et connecter les acteurs et les initiatives.

Pour cela, nous avons besoin :

• Que les données suivent un standard sémantique commun

Ce standard fonctionne comme une langue commune où l’on se met d’accord sur une terminologie, sur la signification des termes et sur les relations entre eux.

Il peut ensuite être partagé entre les différentes plateformes associées , même si celles-ci conservent leurs propres langages et propres modèles de données.

• De spécifications techniques

Elles décrivent comment les données doivent être échangées entre les acteurs qui mettent en place le standard. Il s’agit du langage technique qui permet aux plateformes de communiquer (de partager ou de mutualiser des données)

• D’une architecture permettant à l’écosystème de travailler de manière décentralisée

NOTRE STANDARD

Le standard de Data Food Consortium (DFC) est composé de trois blocs (3 ontologies) complémentaires : 

• une ontologie métier (elle- même regroupée avec l'ontologie produit sous une ontologie sémantique)  
• une ontologie produit
• une ontologie technique 

1- ONTOLOGIE SEMANTIQUE

Il s'agit d'une description commune de l’activité des circuits courts sur laquelle nous nous sommes mis d’accord et qui se présente à la fois sous un format lisible par l’humain (modèle) et par la machine (ontologie).

Cette ontologie se compose de 2 modules interdépendants  :

-d’une part, une ontologie métier (ce que nous faisons, comment, qui et où), indépendante de la nature des produits concernés

-Et d’autre part, d’une ontologie produit (comment décrire la nature des produits manipulés par le modèle).

L'idée est ici de découpler :

• Le métier (ce que les entités font). Par exemple, ces entités produisent, vendent etc…
• De la nature des choses échangées(ce que les produits sont).

A eux deux, ils composent le langage commun qui permet aux acteurs utilisant les plateformes de circuits courts de communiquer entre eux.

Retour d'expérience … 

Construire une ontologie sémantique a été pour nous une première étape importante dans Data Food Consortium.

Le cœur de notre travail est en effet de nous accorder entre plateformes des circuits courts sur une façon commune de décrire notre métier, de clarifier les concepts et le vocabulaire.

Nous avons en effet réalisé que chacun manipule des concepts de façon inconsciente, utilise des termes différents de l’autre pour définir les mêmes choses ou a contrario utilise des termes identiques pour designer des choses différentes.

Ce travail n’est pas technique, il est plus lié à une réflexion commune pour décrire notre métier.

Cette description commune a ensuite été modélisée dans un schéma (le modèle sémantique métier).

Nous avons édité une première version de notre standard sémantique en novembre 2017, puis une seconde en juin 2018 et une troisième en mai 2019.

Découvrez ici la dernière version du standard sémantique ! 

2. ONTOLOGIE TECHNIQUE

Elle décrit comment les données doivent être échangées entre les acteurs qui mettent en place le standard. Il s’agit du protocole technique qui permet aux plateformes de communiquer entre elles (= de partager ou de mutualiser des données).

Pour en savoir plus sur notre standard, visitez notre page gitbook

STRATÉGIE POUR CONSTRUIRE CE STANDARD 

RESPECT DE NOS VALEURS

A chaque étape de la construction de notre standard, nous nous assurons de respecter notre vision et nos valeurs comme la collaboration, le respect de l’indépendance de chacun, l’horizontalité et l'équité. 

Exemple 1 : Un catalogue de liens plutôt qu'un identifiant unique

Quand nous avons cherché un moyen de relier les données entre elles pour pouvoir les mutualiser, nous avons pu être tentés par des solutions autour d’identifiants uniques (ex : identifiants produits uniques, identifiants producteurs ou distributeur uniques), via des collaborations avec GS1 (qui crée et gère les codes EAN pour l’industrie agro-alimentaire) ou encore Open Food Facts (une plateforme en open data qui utilise les codes EAN de GS1 quand ils existent ou créent gratuitement des identifiants produits quand ils n’existent pas).

Mais en faisant cela, nous aurions du adhérer au standard de GS1, perdant ainsi notre indépendance et l’idée d’un standard commun, ouvert au centre.

Et si l’emploi d’identifiants uniques avec Open Food Facts se rapprochait davantage de nos valeurs, nous avons décidé de ne pas confirmer cette solution non plus, pour diverses raisons dont la fragilité d'un système basé sur un « pivot » central .

Nous avons donc changé de stratégie et décidé, plutôt que de lier les catalogues les uns aux autres au moyen d'un identifiant unique, de gérer des catalogues de liens . On gère donc un fichier qui dit que produit A chez Socleo= produit B chez CoopCircuits = produit C chez Alilo etc , toutes les infos pouvant être stockées de façon distribuée sur toutes les plateformes.

Cela a impliqué une revue de tout le travail déjà effectué, une modification de l'ontologie, etc. Mais cette solution est au final plus résiliente et fidèle à l’inscription de notre projet dans une logique d’indépendance, d'équité et de web décentralisé. 

Exemple 2 : Stockage partagé des données sur la plateforme « Les Communs »

Fidèles à notre valeur d’horizontalité (=absence de hiérarchie au sein du consortium), nous avons choisi un agent “neutre” pour héberger nos données communes : le catalogue produits universel DFC. Cela évite de quelconques conflits d’intérêts au sein du consortium.

Et d’un point de vue pratique, l’idée ici est de permettre à l’utilisateur de se connecter avec un identifiant unique et de récupérer les données de différentes plateformes, sans avoir à se connecter à chacune d’entre elles. Cela permet in fine des gains de temps et une plus grande simplicité pour l’utilisateur.

UN PROCESSUS ITÉRATIF ET BASÉ SUR UN PROTOTYPE

Construire des spécifications sémantiques et techniques de notre standard nécessite rapidement une application à des cas réels.

L’idée est de prendre des cas d’usage concrets pour vérifier si ce que nous avons imaginé est adapté à nos besoins et facilite réellement notre travail.

Dans cette optique, nous développons un prototype sur un cas d’usage possible de DFC :  MonCataLog. Ce prototype est axé sur le partage de catalogues produits entre plateformes et la mutualisation des flux logistiques.

L’objectif de ce prototype est de créer une « preuve de concept » pour montrer le potentiel du standard. Mais aussi de contribuer à construire et améliorer le standard sémantique et technique dans une logique itérative.

Ce prototype MonCatalog n’est qu’un cas d’usage possible du standard Data Food Consortium : d’autres cas d’usage, comme les portails de recherche de produits de circuits courts ou ceux axés sur la production ou encore la gestion des produits alimentaires sont possibles…