Data Food Consortium
Data Food Consortium
A common digital language to make life easier for producers, create cooperation and develop short food chains

Our standard

To meet our mission, we are building a common digital language through which we can pool data and connect players and initiatives.

For this we need:

  • Data following a commmon semantic standard

This standard functions as a common language where one agrees on a terminology, on the meaning of the terms and on the relations between them.

It can then be shared between the various associated platforms, even if these platforms are keeping their own languages and own data models.

  • Technical specifications

They describe how the data must be exchanged between the actors who set up the standard. This is the technical language that allows platforms to communicate (share or pool data)

  • An architecture allowing the ecosystem to work in a decentralized manner.

OUR STANDARD

DFC standard structure

The Data Food Consortium (DFC) standard is made up of three complementary blocks (3 ontologies):

  • a business ontology (itself grouped together with a product ontology under a semantic ontology)
  • a product ontology
  • a technical ontology

1- SEMANTIC ONTOLOGY

There is a common description of the activity on which we have agreed and which is presented both in a format readable by the human (model) and by the machine (ontology).

This ontology is made up of 2 interdependent modules:

  • on the one hand, a business ontology (what we do, how, who and where), independent of the nature of the products concerned
  • And on the other hand, a product ontology (how to describe the nature of the products handled by the model).

The idea here is to separate:

  • What the entities do. For example, these entities produce, sell etc …
  • From the nature of the things traded (the type of products).

Together, they make up the common language that allows players using short supply chain platforms to communicate with each other.

We published a first version of our semantic standard in November 2017, then a second in June 2018 and a third in May 2019.

Discover the latest version of the semantic standard here! 

 

2. TECHNICAL ONTOLOGY

It describes how the data must be exchanged between the actors who set up the standard. This is the technical protocol that allows platforms to communicate with each other.

To learn more about our standard, visit our guide

STRATEGY FOR BUILDING THIS STANDARD

OUR VALUES

At each stage of building our standard, we make sure to follow our vision and our values ​​such as collaboration, independence, horizontality and fairness.

Example 1: A catalog of links rather than a unique identifier

When we looked for a way to link the data together, we were tempted by solutions based on unique identifiers (eg: unique product identifiers, unique producer or distributor identifiers), through collaborations with GS1 (which creates and manages EAN codes for the food industry) or Open Food Facts (an open data platform that uses GS1 EAN codes when they exist or creates product identifiers for free when they do not exist).

But in doing so, we should have (together with all producers using services build on the standard) become GS1 members, thus losing our independence and the idea of ​​a common standard, open at the center.

And if the use of unique identifiers with Open Food Facts was closer to our values, we decided not to confirm this solution either, for various reasons including the fragility of a system based on a central actor.

So we changed our strategy and decided, rather than linking catalogs to each other using a unique identifier, to manage a catalog of links. We therefore manage a file that says that product A at Socleo = product B at CoopCircuits = product C at Alilo etc, all the information can be stored in a distributed manner on all platforms.

Example 2 : Hosting our prototype data on “Les Communs”

We needed a neutral actor to authenticate producers on our prototype, so we are using Les communs (the commons) – a French organization promoting the use and creation of commons – OIDC server.

 

AN ITERATIVE PROCESS BASED ON A PROTOTYPE

Building semantic and technical specifications of our standard quickly requires to be challenged by real cases.

With this in mind, we are developing a prototype on one possible use case: MyCataLog. This prototype is focused on sharing product catalogs between platforms and pooling logistics flows.

The aim of this prototype is to create a “proof of concept” to show the potential of the standard. But also to build and improve the semantic and technical standard in an iterative mindset.

Learn more about our prototype
Use our standard!