What does it mean to implement ?

This page outlines the technical considerations for platforms joining the UK Food Data Collaboration Commons.

There are other considerations for partners in the FDC Commons:

  • We require partner organisations to align with the values outlined in our Vision and Mission, listed on our About page.
  • We also invite all platform partners to consider whether they’d be willing (and have capacity) to participate in our Governance circle.
  1. Background

The UK Food Data Collaboration project aims to leverage the work of the (French-initiated) Data Food Consortium (DFC) project. This project is defining an interoperability web standard for short supply chain food data.

The documentation of the DFC standard, including information on its evolution and documentation of various decisions that have been taken along the way is available on gitbook: https://datafoodconsortium.gitbook.io/dfc-standard-documentation/ 

A lot of useful links relating to the DFC project are consolidated on this DFC page.

  • Ontology

The Data Food Consortium has defined an ontology that we align to. The DFC ontology provides a general knowledge framework that maps the concepts used to provide short supply chain food retail platforms in a machine readable format. It is a more logically rigorous form than an application Model but for our purposes it can be thought of as similar.

It is not necessary to understand the ontology in order to implement. 

However, if you’d like to take a look, the technical details of the ontology are available here:

Some useful tools for viewing/understanding ontologies:

  • Prototype

The Data Food Consortium have also built a prototype, this facilitates product data testing for platforms and is currently the primary interface between the systems – as per the DFC standard

In the longer term it is intended that any member of the Data Commons will be able to directly push reads and changes (record create, update and delete statements), for the data they own and control, to all other platforms within the Commons, via a JSON-LD API that conforms to the DFC ontology. 

The prototype provides an intermediary step to facilitate systems debugging their interfaces and further development of the standard. The prototype is published under an MIT licence and code is available on github. The current instance of the prototype is available here: https://proto.datafoodconsortium.org/ 

  1. FDC Phase 1 

There are 3 major technical steps in Phase 1 (the currently funded phase) of the FDC project:

  • Interface the platforms with an Open ID Connect (OIDC) provider: currently the DFC project manages a realm on the Les Communs (website in French) Keycloak server. 
    • This involves implementing OIDC interface technology within the platform. Further information on this can be found here, briefly:
      • Your platform will need to be authorised to connect to the DFC realm of Les Communs and supplied with a client secret.
      • Your platform will need to integrate Open ID Connect functionality. There are supported libraries in all major programming languages & web application frameworks. A list of certified OIDC libraries can be found on the website here, and there are some uncertified libraries also available.
  • A producer or hub user on your platform will need to be able to either:
    • Login & set-up a hub/supplier account with a Les Communs ID, or
    • Link an existing producer/hub account to an OIDC account provided by Les Communs.
    • It is not necessary for shoppers/customers to have access to the OIDC logins or a Les Communs account.
  • Users must also be able to opt out of data sharing via the FDC.
    • This requirement would be supported by using the link/delink existing accounts on your platform strategy outlined above.
  • In addition FDC Commons Governance requires all platforms to have the ability to exclude individual users from the Commons (in cases of extreme or repeated breaches of Commons Rules). The FDC does not seek to control who can or cannot use individual platforms, however we have a duty to protect the integrity of the Commons.
    • This could take the form of a superadmin override that allows you to restrict access to the OIDC functionality/account linking.
    • If you wish to allow users to create accounts with Les Communs IDs, it may be more complex to implement these controls whilst continuing to allow banned users to access your platform.
    • This functionality potentially overlaps with the functionality required for the planned pilot roll-outs to specific geographic areas/subsets of users.
  • Create and publish a CRUD API for Products (Supplied Products and Catalog Items in DFC terms) data utilising the DFC JSON-LD standard (example here). 
    • Including:
      ❇ A bulk GET of all Products (for all Enterprises linked to a User)
      ❇ Create an individual Product (for a specific Enterprise and User)
      ❇ Read an individual Product (for a specific Enterprise and User)
      ❇ Update an individual Product (for a specific Enterprise and User)
      ❇ Delete an individual Product (for a specific Enterprise and User) 
    • The API will need to be authenticated against an OIDC user, and access control managed so that only products controlled by that user are visible/updateable.
    • The API responsiveness will need to be within agreed timeliness and availability criteria (these are to be agreed with Tech Partners).
  • Exposure (and consumption) of Product data from anywhere else in the Food Data Collaboration Commons within the platform’s shopfront.
    • Enabling querying of DFC Product data from other platforms
    • Displaying that data in the shopfront of your platform
    • Ensuring any caching (for performance) is managed, esp. within checkout processes such that only up to date stock is sold from any source platform.
    • Ensuring any stock updates (sales and returns) are pushed to the source platform within the commons in a timely manner (SLA’s will be agreed within the Technical working group).
  • All testing is currently conducted via the DFC Prototype. Your test server will need to interface with this prototype to verify your API is working currently.
    • You will need to provide a URI for your endpoint, so that we can configure the prototype to access your platform.
    • The prototype will bulk import product data from your platform.
    • Products can be edited and manually linked to products from other platforms.
    • The prototype can push data updates to platforms (e.g. a linked product can have description and/or stock updates pushed to align multiple platforms)
  • The current recommended standard version is v1.7:  
  • A DFC Connector library is currently under development, to facilitate implementation of the DFC Ontology as a Model within applications. See a short demo here
    • This library allows an application to access the DFC structures as any other model object – create and populate instances of the various classes in the ontology and output as JSON-LD, compliant with the DFC standard.
    • Initially this is available in TypesScript/NodeJS. Other languages would be implementable (using a code generator) with development costs (typically 1-2 days) being borne by the associated project.

Implementation

The FDC project is funded to rollout into 2 pilot regions in the UK. The first pilot region is SW England, the second pilot region is still to be confirmed. This has implications for platforms – specifically they must be able to turn on/off the DFC functionality (or access to it) for specific regions/hubs/users.

Conclusion

So, a brief overview of the journey…

  • Implement the Open ID Connect functionality to enable your platform to authenticate across the commons
  • Expose your data in a REST API that fits the DFC Standard
  • Consume the same data from other platforms in your shopfront
  • Test this functionality using the DFC Prototype
  • Rollout in the 2 pilot areas

We hope you’re inspired to join us on this journey. We anticipate more complexity and will update this (and other documents) with more accurate information based on our findings and failures as we progress. We believe this digital infrastructure has the potential to change the face of local food systems in the UK (and beyond) – if you agree please get in touch.