I’ve just refreshed myself on OADA and Trellis… Thanks @sam_uk for putting some of these links out there! Here are definitions of the two projects from their github repos:
The purpose of the Open Ag Data Alliance is to develop a standard API framework for data exchange in agriculture. If a farmer or agronomist has data stored in one place, and would like an app or service to be able to access it, they need only know the top-level domain where their data sits in order for the app or service to use it.
The Trellis Framework builds on the Open Ag Data Alliance API standards. The core of this framework is an API spec for creating data connections between platforms. Any platform or app can be made “Trellis conformant” or “OADA conformant” by supporting that API. Trellis adds a document signature process for document integrity to the OADA standard as well.
Some of these docs look a little old, but I imagine the goals of the projects haven’t changed. It would be great to hear from more folks at Purdue! Here’s my take
- Trellis is more concerned about the interoperable audit-ability for Food Systems and automating this process (especially after looking at their website http://trellisframework.org/). It’s built on top of OADA.
- Becoming OADA Conformant would help us in passing data between our platforms. I like the concept that we “need only know the top-level domain where their data sits in order for the app or service to use it.” Each project adapts their own backend, provides their configuration in the top level
https://localhost/.well-known/oada-configuration, and other projects can start consuming…
So this conversation seems to split between low-level and high-level.
- OADA might be a solution for how we pass data between platforms. (low-level)
- Trellis might offer some (high-level) definitions for “data formats” used for audits in the food system. Mapping out these data formats, and others (general farm record keeping, GHG calculations, ecological claims, etc) is another concern
I hope this is of use to others. I’m particularly interested in low-level, and how we’ll pass around the high-level formats. As for your question @carlvt I’m not sure a best way to start mapping these various formats. Let’s start by defining the different categories of formats? Data for audits, GHG calc, general record keeping, ecological claims, etc?