Looking for Advice

[Brian Twardzik]

Hi folks,

I am working on some data interoperability and data integration problems in agriculture. This lead me to looking into AgGateway's ADAPT model as well as Open Ag Data Alliance. I recently was able to get the sample oada-srvc-docker microservice api reference implementation working and began walking through the oada-docs "hello world" examples.

My goal is to determine the best way for my organization to make it easy for growers to make their data accessible to multiple organizations in a secure manner. So there are multiple problems in that statement, some of which is addressed by common data formats. Some of it is addressed by OADA's federated identity and data mastering system. The "product sheet" description of OADA suggests that it can form the basis of an Agricultural Data Hub where formats can be converted from one to another. A large chunk of those format conversions may be geospatial data, based on my experience, and what I've seen out of precision agriculture and agronomy.

OADA's reference implementation seems rather ... empty. Very flexible! Interesting messaging backbone with kafka. But when one looks in /bookmarks its rather empty. No suggested resources. Just a really really nice resource graph capability.

Can someone tell me what OADA is, and what it is not?

Can someone be frank and tell me if OADA's goal is the same as AgGateway Global's MVP 2 or 3, since they're mixed into the EU's IOF 2020 ambitions?

If I wanted to model AgGateway's common data model and mix in some converters to make it ESRI / Mapbox / QGIS geospatial agnostic, how would I pursue that goal?

Aside from the basic Org->Grower->Farm->Field entities, we need the FieldBoundary, MyJohnDeer.FieldOperation / CNH.Task / AgGateway.LoggedData geospatial information and attribute data. And sadly that information doesn't appear to be approaching a standard, it appears to be diverging all over the place.

My goal would be to make a website where a grower could allow their data to move between John Deere's MyJohnDeer site, the CNH site, and other potential up-and-comer Agronomy sites, and into our own site. Hopefully we can standardize it, but I think we should assume thats not 100% possible ,which is why OADA's capabilities are promising for that goal.

I just need to... figure out how to do it.

[Scott Nieman]

Hi Brian, the OADA specifications and the ADAPT framework are different yet complementary.  Your observations are quite accurate, OADA is more generic resource/ property graph API with Open ID Connect sprinkled on top for cloud-to-cloud interoperability, whereas ADAPT is a runtime library that allows plug-ins to be created that map proprietary file formats off machinery to the ADAPT common/canonical application data model (ADM) and to other formats -- it does not dictate file formats.  Plug-ins are available from Deere and CNH, as well as ISOBUS and more being developed by FMIS and farm machinery / implement manufacturers.  Having said that, ADAPT does support geospatial information in the ADM, work order and work record, logged data, products, equipment, and classic grower/farm /field aspects.  The downside of ADAPT is that it is currently file-based with import and export functions from the root ADM.  A FMIS <-> FMIS PoC has been on-going to allow REST JSON APIs into the ADAPT object model, picking and choosing subset views off the model versus serializing the whole model (which was needed v1 for power-off, restart reasons).

There has been discussions in AgGateway about using OADA resource APIs to do that as well, interacting with the run-time over REST.  Since this is has a voluntary effort by Purdue University (OADA) and AgGateway (ADAPT), features are all dependent on the clock-cycles and priorities of people.  Personally, I think there is a great opportunity to harmonize.

Did you post a similar question to the ADAPTFramework.org site?  

Scott Nieman

Enterprise Integration Architect

Land O'Lakes

(using my personal email for this note )

[Brian Twardzik]

Hi Aaron, Scott, 

Thanks for answering and great to meet you. And thanks again Aaron for your help with that recent issue. My github handle is Arkanon007.

Answering the questions in order. I work for Saskatchewan Crop Insurance Corporation, although I'm pursuing this on my own time as well out of intellectual curiosity and maybe seeing an opportunity to make things better. I will keep the Chicago idea in mind and see if I can get support for that. Low probability without some kind of tangible results to show.

The kind of data that would be most beneficial for a crop insurance company would be field boundary, seeding and harvest data -- perhaps facility information like grain bin yards. Within precision ag / agronomy tools, this amounts to geospatial data types combined with no standard schema of fields / attributes. For our needs, the Corp/Grower/Farm/Field/FieldBoundary/ GIS Entity + Attribute blob is what makes the ADAPT common data model attractive. Problem being that once you get  beyond 'Field' / 'Field Boundary' then every FMIS cloud goes off on its own schema. For example, even within seeding data, they may refer to the crop by a character name. But there are a lot of ways to represent the various crops. You say 'Hard Red Spring Wheat' and they say 'HRSW', and yet another one just says '1 - Wheat'. That makes the data interoperability suffer. Data integrations become more expensive to maintain and the chance of semantic translation errors increases. Thus data quality suffers. One might not find that kind of thing that big of a problem but some organizations are very sensitive to the cost of integrating APIs.

AgGateway gave some hope in that regard with their ContextItem concept. It stands a chance of mastering data between FMIS and government bodies like the EPA in the USA and the CRA in Canada. There are commodity codes for each product, for example. But, yes, for some odd reason they advocate for trading around serialized C# objects. I'd much rather see them do exactly as you've suggested and have a referential integral schema, and JSON is everywhere these days. I was hoping their Minimal Viable Product round #2 would be just that, as some of their youtube media suggested.

I was hoping OADA had conversion logic already present (multiple libraries of format converters) that would push down the cost of data integration -- making the complexity of data interoperability someone else's problem / cost, hehe :). And while OADA as a data platform has that capability and a potential for expansion, it seems the investments haven't been made yet.

A FMIS to FMIS PoC is something I'd see succeed if I could help make it happen. For my part, I'd like to see a FMIS to FMIS PoC centered around Org/Grower/Farm/Field/FieldBoundary & Seeding Data (or other operations) and canonical product identifiers similar to ADAPT's ContextItem. I'm not certain how I would go about pursuing that goal, exactly.    

I do have a lot of questions.

CNH says its OADA compliant on its website. What about John Deere? How can that be demonstrated? Their APIs don't appear to be OADA implementations from what I can read. Even if I wanted to approach them for app keys and developing an OADA sync between them, and then microservice ETLs for convering JD's JSON and CNH's JSON into an AgGateway-based canoncial JSON schema... how the heck would I go about doing that?

If OADA is a data platform, what makes it especially about Agriculture and not Medicine? What sets it apart from, say, running Azure Cosmos DB and having an integration platform as a service running, like Mulesoft or writing a number of Azure Logic Apps shipping and syncing information with some form of differential sync?

--
You received this message because you are subscribed to the Google Groups "OADA Developers Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oada-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.