Developers, share your schemas!

As a step towards data format standardisation among OpenTEAM members’ software, @Gregory suggested that we all upload our data formats (and ideally format documentation).

So, the Cool Farm Alliance presents “DOSS”, Data Object Schema Sharing:

Our standard input and output format is there already, and I’ll be working on formatting and uploading more of our API documentation as I manage to convince the rest of the CFA to open-source it :wink:


Great post @3wordchant! We will then be able to map to the documentation in several different ways. Looking forward to seeing the documentation flow!


I like the way that the references a Wikipedia link.



Thanks @3wordchant! I am sharing with @aaronc and we will dig in!

1 Like

A great start, @3wordchant! As for farmOS, it stores a few different types of data with optional attirbutes that can get to be quite extensive. I don’t know if we have existing JSON files that map all of this out, but it is pretty well documented in the API Documentation.

The farmOS.js and client libraries may be of interest as well. The JavaScript library has particularly great documentation (thanks to @jgaehring!)

@mstenta and @jgaehring, do we have existing JSON files that describe Assets, Logs, Areas, etc? Should be easy to create if not.


I second what you said @paul121 - the farmOS API docs are the best place to find a lot of that info right now:

1 Like

Guess it’s worth mentioning this too


I spoke to the OADA people at the TechStars meeting; my understanding is that OADA has developed into a general specification of a filesystem-based API for data storage, and Trellis is the Ag-specific implementation of OADA we might want to focus on.

@mstenta @paul121 thanks for the replies, and for the pointers to specific parts of FarmOS. Any suggestions on the best way to start mapping between the various formats? A grid of inputs, noting accepted data type, seems like a decent start, but I haven’t yet investigated how far the schemas overlap (if at all).

1 Like

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 :slight_smile:

  • Trellis is more concerned about the interoperable audit-ability for Food Systems and automating this process (especially after looking at their website 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 @3wordchant 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?