Connecting food cooperatives

Integrations
1

As part of connecting OFN to existing alternative food systems, I’m investigating how this would work with food cooperatives who use other software. In my ideal world, different groups would use whatever is most useful to them, and are still able to work together with others, and with OFN.

This is an exploration of how OFN and and other food cooperative systems may integrate. It’s not fully worked out, it may not make sense to implement it all (or at all), but hopefully provides a starting point.

Connecting to OFN as a food cooperative

While there is an option in OFN to form buying groups, there may be various reasons for food cooperatives to use other software. It would be great if OFN would integrate with these as well; for the ecosystem
because everyone is more connected, for suppliers (and shops) because they have a larger market, and for food cooperatives, because they have easier access to more suppliers.

We’ll discuss some use-cases in increasing complexity.

Discovering producers

Foodcoops may use OFN to discover producers in their neighbourhood, that they otherwise would be unaware of. These would be OFN _Producer_s, and perhaps anyone who has a Shop.

Required endpoints

  • [OFN] listing and searching _Producer_s
  • [OFN] listing and searching _Shop_s
  • [OFN] showing _Producer_s and _Shop_s by id

It would be useful to search by name and location (distance to). Perhaps the listing and searching endpoint would work on _Enterprise_s, with the possibility to filter by ‘type’/‘features’.

At the very least, some basic info like name and location is needed, and an (OFN) link to read more and see the products (depends on #624).

Getting product information from producers

In OFN, the assortment of producers can be kept up-to-date. Food cooperatives could synchronize their product information with that in OFN.

Required endpoints

Foodcoop software needs to be able to find products by producer/shop and keep them synchronised.

  • [OFN] listing and searching _Product_s by enterprise
  • [OFN] listing _Product Variant_s
  • [OFN] showing _Product_s and/or _Product Variant_s by id

It could be considered flatten the product + variants to only product variants (as long as there remain references to group variants together). This depends on whether variants make sense for other systems as well.

OFN would probably need to return products that are in an order cycle that is open (or will be in the future). TODO figure whether it is useful to also show products not in an order cycle.

Placing orders at OFN

If a food cooperative wants to buy from a producer in OFN, it would be useful if it could go through OFN, both for OFN and for the producer. Without that in place, ordering needs to be done either by direct contact to the producer, or by entering an order manually in OFN.

Required endpoints

  • [OFN] CRUD for _Order_s, including adding/removing _Line item_s.
  • ?

TODO When a producer has no shop, I’m not sure how placing an order from a food cooperative would fit in. It may be a ‘normal’ user order (including the ability to directly order articles that only make sense when group buying), but also when the Producer has no Shop. That’s something to be worked out.

Keeping order information up-to-date

When a food cooperative has their own order cycle with an OFN supplier, it may be useful to update desired quantities in real-time (when there is only so much available at the producer, for example).

TODO work out in more detail (later)

Keeping OFN profile updated

Foodcoop software often has a place to enter details like name and address. If there is a profile in OFN, it would be useful if this would be synchronised automatically.

Related work

4 Likes
2

Great work, @wvengen - THANK YOU!

3

Greetings from the bus from Wellington to Napier, NZ! Great writeup, @wvengen. I have a couple of small comments to add.

Placing orders at OFN

  • Orders can be manually placed in OFN (see admin -> orders -> new)
  • Products need to be available through a distributor/order cycle to be purchased or manually added to an order. This means that producers will need to have their own shop or have their products distributed by someone.

General

Once this broad overview is worked out, it might be a good strategy to build towards a specific integration. Is there any particular food coop software for which an integration is most in demand?

4

Hi @RohanM,

@wvengen maintains open source (ruby on rails) foodsoft and its fork

Nice 15min video showcasing it - https://vimeo.com/145927538

1 Like
5

Thanks @RohanM. Good to see that orders can also be created manually.
In the second use-case of importing products into a food cooperative system, OFN would just act as an information system, providing info about producers and products. Foodcoop may just want to look at the available products, also when there is no open order cycle.
Or am I getting something wrong here? Does an order cycle need to be closed for products to be delivered, or is an open order cycle like a shop where one can buy things right away? For the former, it would be useful if food cooperatives could browse the products before an order cycle opens; for the latter, it’s ok to only show products in open orders.
(I’m still a bit new to OFN, so please bear with me if I’m asking obvious questions.)

6

ok, have watched the video and is awesome - very elegant handling of a bunch of useful things! Some of which ofn has basic implementation of, but often buried in more confusing ways. I am hoping to have some time to go through the video and map features / functionality at some point, particularly with a view to making decisions about where we respond to user demands for features within ofn and/or where having a beautiful clean integration with foodsoft would be better use of time/energy (or both). Me having time / brain power to do that will depend on the sleeping habits of our impending arrival . . so no promises

@wvengen - hope is ok, I’ve turned your page above into a wiki so that it can be updated by others, e.g. with @RohanM’s comments.

Hoping to find half an hour this week to just run through some very quick thoughts on interface and some of your questions / comments above e.g. I’m pretty sure that you use the word ‘order’ to mean both what we call an ‘order cycle’ (selection of products from range of producers available in x time period e.g. the things that your customers can choose from) as well as to describe the customer’s ‘order’ (which is what we call an order)

I think a key question for integration would be whether / where to have producers, inventory lists (product availability this week for example), order cycles / orders maintained etc. Some of this may become clearer as our shift to ‘inventory lists’ takes place . .

7

Thanks @Kirsten, no rush :slight_smile: Thanks for turning it in a wiki. Please feel free to edit and improve.

To get clarity on terminology, I’ve written up something at food-dashboard. If anyone with some knowledge of OFN terms would want to have a quick look to see if I got it right, that would be great (if you don’t want to create a PR there, feel free to comment here and I’d be happy to update).

I’ll have to read up on inventory lists, thanks for the pointers.

8

@sstead - here it is :smile:

9

Hi there!
I ha an amazing discussion with Tibor, Reunion Island, who is developping the open source project "Communecter"

(sorry that’s in French, but the images speak ;-))
He collaborates with @elf-pavlik and Simon (the guy I mentionned in that discussion)

We shared a common vision of integrating the Open Food France data within the Communectez platform, that would be a first case on interoperability :slight_smile: The idea would be to display the informations about the farmers profiles on the Communecter map, where they can also gain reputation, but we also would like to display the hubs and if there is an order cycle openor when it will open.

So he asked me if there were an API so that he can display those infos, is there any kind of stuff like that available? The work you did @wvengen in that direction, is it usable? I saw tha on GitHub but it’s a bit Chinese for me :wink: https://github.com/openfoodfoundation/openfoodnetwork/wiki/API-documentation
Is it what I should share with him so that he can display the data?

Ping @maikel @RohanM

1 Like
10

To get started, for each profile page we could just add some RDFa or Microdata using http://schema.org terms. This would also give some SEO benefits. I can check with Tib what data he would need. Or for now we could even just piggiback on http://ogp.me/ (RDFa based) which we already started adding for getting nice links in facebook posts…

11

Exciting discussion here!

After all an open decentralized federated food network is all about interoperability and networking…

A full data sync can be quite complicated and expensive. Apart from an initial sync I could imagine most of the time two systems connect, they would already be (almost) in sync. E.g. farming offline and getting connectivity again, syncing up the changes made in the meantime and downloading the latest order updates.

Afaics spree/ofn offers a REST-style API, i.e. request/response PULL-based data retrieval. In a dezentralized network of food participants, maybe some event-driven messaging could be “easier” to keep everything in sync? Kind of a PUSH-based publish/subscribe API, where updates get pushed proactively to connected subscribers?

E.g.: subscribe to change-feed since timestamp:

  • new producer…
  • new product…
  • updated price…
  • deleted product…
  • updated order status…

kind of a stream of changes to subscribe to
ordered by time and stays open for realtime updates

What do you think?

12

I see different requirement when we need to work with read&write vs. read only interop. Communecter most likely can start with read only API and doesn’t need to write. While we work on full read/write API we may already get started with read only by embedding structured data with https://schema.org and/or http://ogp.me

BTW for more broad approach to interoperability please check out https://valueflo.ws which I would like to make a core of https://github.com/ouisharelabs/food-dashboard experiment.

13

Ping @oceatoon, I think the discussion is for you :slight_smile:

14

Great to se some discussion on interoperability. I agree with @elf-pavlik that a read-only API may be sensible to start with, and a lot easier. It is good to know that Spree has an API supporting more advanced use-cases too. Still OFN has introduced quite some changes so I’m not sure how well this is usable (e.g. I wonder if access control for enterprises is present in the API).
OFN’s API documentation is probably (somewhat?) up-to-date as it was, as far as I know (also see the current routes file).

Interesting to mention RDFa or Microdata. It would certainly help search engines and spiders to access the data in a structured way (schema.org has a Product schema). I do wonder if developers of apps wanting to connect are familiar with this approach, where I feel REST is more prevalent.

15

e.g.
a mobile phone downloads (read-only) enterprises to the phone book
or two OFN instances share (read-only) enterprises in both directions

Which use cases do you have in mind?

how to detect deleted enterprises?
delete everything and re-download?
a REST query since=last_modified?

How “cheaply” detect that you are already in sync?

16

microformats, valueflows, ogp and schema.org products look exciting! A common shared vocabulary and compatible data types makes interoperability. Standards seem to emerge out of widely used best practices.

Beside data formats is the question of how to communicate updates (protocol).
Would we simply (restfully) http put/post/delete each other in real-time for everyone to stay up-to-date? What if someone goes offline for some time and then reconnects to catch up? Or would we constantly poll each other? How to handle participants joining and leaving an open food network?

Maybe we can (re)use some ideas from dat https://github.com/maxogden/dat Like git but for data. Similar to event sourcing or kappa architecture the main idea is to have an immutable append-only log of data changes that enables versioning and branch/merge synchronizing data (in a merkle DAG structure) like with git pull/push.

17

Rather than have to insert Microdata or RDFa into HTML, what about to generate JSON-LD and insert that into pages? Many of the OFN pages now pull JSON from the server anyway. This could make overall implementation easier?

18

:+1:

19

Ping @sylvain :slight_smile: You have some ideas about this tech part I guess?

20

Absolutely. I totally agree with @pmackay, as using json-ld would make the API understandable by other web applications. If LesPaniers bio du Val de Loire do the same, you’re compatible!