Developers, share your schemas!

3wordchant · September 29, 2019, 4:13pm

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

dornawcox · September 30, 2019, 1:16pm

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

sam_uk · September 30, 2019, 2:47pm

I like the way that the https://www.growstuff.org/crops references a Wikipedia link.

Eg
https://www.growstuff.org/crops/cucumber
https://www.growstuff.org/crops/cucumber.json

Gregory · September 30, 2019, 3:54pm

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

paul121 · September 30, 2019, 11:26pm

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 farmOS.org API Documentation.

The farmOS.js and farmOS.py 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.

mstenta · October 1, 2019, 8:00pm

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

sam_uk · October 4, 2019, 10:46pm

Guess it’s worth mentioning this too

http://openag.io/

github.com

OADA/oada-docs/blob/master/README.md

## Welcome to the **Open Ag Data Alliance** (OADA).

[![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/OADA/oada-docs?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)

## The important stuff: API Docs


|   Getting Started       |       Specs                 |
|:-----------------------:|:---------------------------:|
| [Intro to the OADA API: Irrigation](https://cdn.rawgit.com/OADA/oada-docs/master/intro/OADA_API_Intro_Irrigation.html) | [Rest API Spec](rest-specs/README.md)
| [Intro to the OADA API: Trellis](https://cdn.rawgit.com/OADA/oada-docs/master/intro/OADA_API_Intro_Trellis.html) | 
| [Intro to OADA Authentication and Authorization](getting_started/auth/README.md) | [Authorization and Authentication](rest-specs/Authentication_and_Authorization.md) |

## The Latest - Cache published!
Sam and Servio have been hard at work on the awesome oada-cache library(s).  It's on NPM under the `@oada` organization [https://www.npmjs.com/org/oada](https://www.npmjs.com/org/oada).  We'll be adding some docs soon explaining how they work, but the basic idea is that you can just import a top-level module for a type of information (fields, yield, notes, etc.) and you have an automatic local cache of data with live change feeds with built-in authorization and identity: whether you're in node or in the browser!  We published a pure javascript implementation [(oada-cache)](https://github.com/oada/oada-cache), as well as some great [cerebral.js](https://cerebraljs.com/) providers [(cerebral-provider)](https://github.com/OADA/cerebral-provider) and modules [(cerebral-module)](https://github.com/OADA/cerebral-module) on top of the pure javascript that really streamline React.js-based development.

## Overview
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

This file has been truncated. show original

3wordchant · October 6, 2019, 4:45pm

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).

paul121 · October 6, 2019, 10:27pm

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:

OADA: GitHub - OADA/oada-docs: OADA API Related Documentation and References

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.

Trellis: GitHub - trellisfw/trellisfw-docs: Documentation for the Trellis framework

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 @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?