This post feels as long overdue and I apologize for that.
What is Data Food Consortium? It’s an initiative started and currently hosted by Open Food France to create and use an interoperability standard for short food chains tools / platforms.
What is interoperability? The ability for tools to “communicate” together.
You will find here the slides I’ve used during this gathering session:
And here the link to the recording:
It’s not a topic that is super easy to understand at first, and I don’t want to write a novel. So I really encourage people to try to follow at least the first 30min of the recording to understand what this is all about.
Here in discourse I would like to talk about the next steps for OFN.
Why is it interesting for OFN to follow a standard ?
As mentioned in the presentation they are many use cases, but we could argue that this would only be achieved once many other platforms and tools do accept the standard.
True. But I believe that the main thing that got me excited about it is the potential for current OFN instances to become interoperable.
That means plenty of stuff :
Network without borders. Producers would only need 1 account in OFN and sell through as many OFN instance as they wish. You may argue that this only works for Europe, but that also means we can forget about our rule that says 1 country = 1 instance. We could have many instances within a given geographical perimeter. This could enable local instances, but also instances with particular rules. For example in France the organic association contacted us to launch their own instance, but they want to accept only organic producers on their instance. In a world where all OFN instances can communicate together, this is not an issue: producers selling on this instance could also be selling on the “national” platform with the same profile. The “national” instance would not “loose” them.
Mapping! Once v1 of the DFC standard implemented, we could build an OFN Map on the global website with all shops all over the world Yes this means we will need to map our taxonomies against a standard taxonomy. I will publish a dedicated post on that as soon as I have worked out the details
Following a standard might require us to change our login system (in order for tools to communicate easily, they need to know that the user is correctly authenticated in all tools). Sounds boring but this actually opens up the opportunity to offer more easy solution to login to the platform. The discussion on this particular point is happening here: OpenID / OAuth2 authentication solution for DFC (and maybe more)
Challenges for DFC’s within OFN next steps
Interaction with global core dev team
During the 2019 gathering, it was decided that @paco should become the OFN dev lead within DFC. It means that François became in charge to build the first brick of the DFC standard within OFN. This was chosen because we didn’t want to impact the OFN pipe with DFC work.
The first idea of DFC was to implement full semantic API . So the original idea was to develop OFN’s API and use a tools called Semantic Bus to convert OFN’s API into a semantic API.
After some iteration, the DFC tech standard evolved to something more easy to handle: simple JSON-LD format.
As this was more easy, François developed the v1 of the DFC engine directly on the database.
From the discussion with @luisramos0 it appears it would have been better to develop the DFC API on top of the OFN API, to be able to develop the OFN API at the same time.
So having François working totally separated from the OFN core team of developers might not be a good solution. We need to find a better way of communicating (maybe discourse + a monthly call?)
Amount of work to deliver
DFC is currently funded. It means that the work making OFN “compliant” with DFC can be paid for. But this funding is limited in time. If OFN is not capable to show progress (finish step 1 by mid 2021), we might loose the funding opportunity to another platform.
I think it would be ok to leave DFC make its own journey without OFN for now because we have other priorities. But DFC will need to know soon if OFN does not want to be implement the prototype.
So I don’t see any other choice than speaking about it at a product curation meeting and make a plan (either we make room for review /strategic decision and sometimes developments within our pipe, or leave it aside for now) ping @Kirsten @sauloperez @Jana @lin_d_hop But happy to discuss to see if they are other options.
The case of the DFC engine
DFC compliance is currently developed in an engine separate from the OFN main app. I think we could start to think in the future about the way we want to maintain engines. We could say for example that some engines become “core” engines, so the core team maintains them. But we could also choose that the maintenance of the engine is externalize to another team.
Today the DFC engine is maintained by the OFN core team (yeah we never managed something that would never impact the pipe). Should we continue to do so?