Summary

Precision agriculture is still limited by a lack of interoperability among different hardware and software systems. AgGateway, a nonprofit consortium of 200+ companies, leveraged its wide cross-section of precision agriculture stakeholders to propose a collaborative solution: its  ADAPT team created an open-source Application Data Model (ADM) representing a superset of field operations data. The goal: to replace the current reality, where farm management information systems (FMIS) must support multiple, incompatible data formats, with a single integration to the ADAPT Application Data Model and a system of manufacturer-specific format-conversion plug-ins. This enables the FMIS to read/write to new systems with little marginal development cost. The ADM fulfills requirements from AgGateway’s SPADE and PAIL projects, and pursues compatibility with the ISO11783-10 standard (ISOXML) and participating companies’ own systems.

Internationalization is an important aspect of this work, but several conflicting requirements must be reconciled: ADM developers must strive for universality, remaining free of regionally- specific clutter. However, business processes in different geographies involve geopolitical-context-specific data (e.g., USA EPA product numbers.) If these "context items" are not accommodated, the ADM’s relevance suffers. Additionally, using controlled vocabularies for context items is desirable. However, the multiple geographies involved make it necessary for these vocabularies to be easily extensible. ADAPT reconciled these contradictions by defining an object class, the ContextItem, that can be linked to various other objects in the ADM.

ContextItems consist of a code (an integer), a value (a string), an optional unit of measure (string) and optional lists of ContextItems and time stamps. The code indexes into a table defining what each ContextItem means; the RepresentationValue encapsulates a value along with data needed to interpret it (such as a unit of measure); the nested list enables complex multi-attribute ContextItems (e.g. PLSS cadastral information.)

AgGateway’s SPADE project implemented a RESTful API to provide a machine-readable dictionary of ContextItem codes and definitions; its Standards & Guidelines Committee created an ad-hoc group to manage dictionary contents.

Introduction

Challenge: Contradictory Requirements

  • AgGateway’s SPADE project operates in the context of ISO11783, an international standard.
  • This drives us to keep our work generic.
  • However, the processes we want to support include much geopolitical context dependent data (US FSA farm numbers, EPA numbers, EU-specific codes, and so forth.)
  • This drives us to make our work geopolitical-context-dependent.

More Contradictory Requirements

  • The Case for a Controlled Vocabulary: If data is only taken from a controlled vocabulary (think dropdown menu) then everyone can understand its meaning (no free-form stuff).
  • The case for flexibility / extensibility: There will continually be new things to keep track of. The system should readily accept new lists and new terms.
  • Questions: Who controls the vocabulary? Single or multiple-source? How are things added to it?

The Geopolitical Context Challenge

We’d like for our solution to simultaneously:
  • Support US, EU,, etc. geopolitical-context-dependent data, yet
  • Not clutter the standard that seeks to remain generic.
  • Support controlled vocabularies, yet
  • Allow for simple extensibility thereof.

Enter ADAPT (Open-source programming toolkit)

  • Common object model
  • Format conversion library
  • Manufacturer-specific “plug-ins” that convert to/from the common object model 

The ContextItem

  • ContextItems are generic tags that can be attached to the objects in the ADAPT common object model and ISOXML linklist file, containing geopolitical-context-dependent information.
  • ContextItems represent a solution to the contradictory requirements.
    • Used in conjunction with a controlled vocabulary.
    • This vocabulary is a collection of data from different sources such as WMO, USDA, etc.
    • Extensible: the vocabulary can be sourced through a reference data API.
    • Will require a streamlined process in AgGateway’s  Standards & Guidelines Committee's Controlled Vocabularies Working Group, analogous to the one we already set up for the AgGlossary at www.agglossary.org.

ADAPT's ContextItem Class

  • These objects can be nested (e.g., US PLSS cadastral data)
  • The ContextItemType is a code that identifies what a given ContextItem contains: think if it as a number that identifies what “Value” means: is it a PLSS Township number? An FSA Tract ID? An EPA Number? A PLSS Prime Meridian string?
  • The optional unit of measure is represented with a UN Recommendation 20 common code, the same as much of AgGateway's supply chain work (i.e., the Ag eStandards).


ContextItem Presentation made at 2016 Annual International Meeting of the American Society of Agriultural and BIological Engineers

ASABE ContextItem Presentation 2016 .pdf

ASABE ContextItem Paper 2016 (Short link to this: http://bit.ly/2rWH7Ds