You have reach the entry point to start working on the Data Food Consortium project: a digital commons for producers in short supply chains.

Here you will find all our technical information and resources. All of our work is open source and new contributors are welcome 🤓.

You can chat with us on our Slack workspace.

To discuss about technical subjects, please use our GitHub discussions.

You can also contact us by email.

We meet on Zoom, these are our regular working groups:

Please contact us through our Slack workspace if you would like more information (or to join) any of the calls.

• The big picture
• Frequently Asked Questions
• Technical prerequisites
• Standard
• Ontology
• Taxonomies
• Prototype
• Data model
• Connector
  • TypeScript
  • Ruby
  • PHP
  • Source code generator
• Working Repositories

• What is the DFC?

The Data Food Consortium (DFC) is , currently, both a data-interoperability standard working in the short food systems space, and also name of the (original) French project implementing that standard. This website relates to the DFC Standard, for more information on the French project see the Data Food Consortium website

The DFC Standard facilitates data-interoperability between platforms used by producers in short food systems. The end user is able to manage their own data on every DFC compliant platform. For example, when products are sold on one platform, the stock for the same products can be automatically adjusted on every other platforms the producer is selling on. The producer can update all of their data like product information on all DFC platforms, from only one platform.

To make this possible, all the platforms must follow an agreed standard. That is the role of the DFC: provide on open standard to define the way platforms work together. Our standard is itself based on other open standards like RDF, JSON-LD, Linked Data Platform (LDP), and OpenID Connect (OIDC).

The DFC Standard requires that the data exposed by the platforms is always data of an authenticated user, who is either the data owner or has explicit consent of the data owner to view/manage data on their behalf.

• Who is it for?

The DFC Standard is provided for Producers in Short Supply Chains, and is intended for implementation by platforms that support that user community. We are particularly aligned with the Elements of Agroecology

• I have a short food chain project. Can I work with you?

To work with the DFC Standard, you'll need to utilise an aligned platform. We are currently aware of implementations in the United Kingdom and France, check out the project websites for more details of local platforms that are aligned with the DFC Standard.

• I'm a developer. Can I help out?

Yes! We welcome community contributions. Give us a shout in the #tech-discussions channel on our slack space, or comment on an issue here on GitHub to start a conversation.

• I have a website or platform for short food chains. Can I integrate with you?

Definitely. We are currently developing documentation to give a clear roadmap for integrating. In the meantime, start a discussion and we'll try our best to support your journey. Some local projects have funding to support platforms to integrate, you'll need to contact your local project to discuss that.

As the DFC standard is based on the Semantic Web, a good understanding of Semantic Web principles is strongly recommended, in particular the notion of linked data.

code | issues | PR | doc | AGPL-3 licence

The DFC standard defines how the DFC compliant platforms must authenticate and exchange data to be able to work together.

To be DFC compliant a platform must:

• authenticate the user with OpenId Connect (OIDC) and provide the received token in requests;
• express the data using the concepts from the DFC's ontology in the JSON-LD format;
• provide Linked Data Platform (LDP) endpoints to access data.

To view a human readable version of our standard please visit our Gitbook.

code | issues | PR | doc | AGPL-3 licence

In order to be interoperable, data exchanged between DFC compliant platforms must be expressed with a common language: the DFC's ontology.

Our ontology expresses concepts like Product, Order, Agent and so on.

To view a human readable representation of our ontology please visit our ShowVOC server.

code | issues | PR | doc | AGPL-3 licence

The DFC standard uses Simple Knowledge Organization System (SKOS) taxonomies to reference:

• Product Types (like vegetable, tomato, cow's milk, dried peas etc);
• Measures (units, dimensions);
• Facets (allergens, labels, etc).

You can explore the existing taxons, through our ShowVOC instance here.

To add a new taxon, please refer to our Contributing Procedures, or open an discussion.

code | issues | PR | doc | MIT licence

When a producer uses multiple platforms to manage its products, equivalent data is hosted on multiple platforms. We must be able to express these equivalent relations in order to operate synchronously. A common use case is to update the stock.

Our prototype allows to:

• manage the equivalent links between data hosted on different platforms;
• view and update data on multiple platforms at a time;
• provide a dedicated API to query the equivalent links.

Our prototype is a Proof Of Concept. You can host it by yourself although we provide a managed instance at proto.datafoodconsortium.org.

More information can be found on our wiki.

code | issues | PR | doc | AGPL-3 licence

We have built an Unified Modeling Language (UML) data model in order to generate the source code of our connector.

The UML model can be opened with tools like Eclipse.

We have developed a tool called the "connector" to help developers to implement the DFC standard. This tool allows to easily manipulate DFC compliant data and make the exchange of data easier. The connector does not help with authentication nor authorization as this is out of scope and must be handled with dedicated tools.

As all the DFC platforms are not built using the same programming language, we decided to make a source code generator to ease the development and the maintainance of the connector.

We have already produced a TypeScript and a Ruby version of the connector.

code | issues | PR | doc | MIT licence

This is the TypeScript version of the connector. You can use it in your platform to implement the DFC standard easier.

It provides:

• TypeScript objects that comply with the DFC ontology (they are mapped). For instance you can create SuppliedProduct or Offer;
• Functions to easily import data from another platform (supplied in the DFC Standard JSON-LD format);
• Function to easily export data in the DFC standard JSON-LD format.

code | issues | PR | doc | MIT licence

This is the Ruby version of the connector. You can use it in your platform to implement the DFC standard easier.

It provides:

• Ruby objects that comply with the DFC ontology (they are mapped). For instance you can create SuppliedProduct or Offer;
• Function to easily export data in the JSON-LD format.

code | issues | PR | doc | MIT licence

This is the Php version of the connector. You can use it in your platform to implement the DFC standard easier.

It provides:

• PHP objects that comply with the DFC ontology (they are mapped). For instance you can create SuppliedProduct or Offer;
• Function to easily import and export data in the JSON-LD format.

code | issues | PR | doc | AGPL-3 licence

As all the DFC platforms are not built using the same programming language, we decided to make a source code generator to ease the development and the maintainance of the connector. We are able to generate the connector source code from an UML model thanks to a model-to-text transformer (Acceleo).

This source code generator uses:

• Acceleo: a tool to perform model-to-text transformation;
• An Unified Modeling Language (UML) data model as input.