General story line

We built the ADAPT model to help improve hardware/software systems interoperability.

In building it, we first put in everything we could think of. Many stakeholders contributing items from their own internal models.

Then we realized that it was just too fat to be useful. In addition, there was a lot of US-centric stuff in it.

We wanted this model to be relevant on a global scale since many of our stakeholders operate internationally.

So we downsized the model, keeping only the "lowest common denominator" properties for each business object.

We came up with the ContextItem system as a way to hold the chunks of data that weren't common to everyone.

This turned out to be a good idea because it allowed us to make progress in solving other problems inherent to the domain like:

"Everybody uses different terms for the same thing" - this system provides a controlled vocabulary that will improve data quality
"I don't know where to put this" - this system lets you filter for only the data points relevant to "what" and "where" you're need to use it
"Data requirements keep changing" - this system is inherently dynamic; new data points are easily added and distributed

We also realized that this could be applied to other models like ISO11783.

A ContextItem is a key/value structure that can be attached to an object from the ADAPT or ISO11783 data model.

A ContextItemDefinition is a structure that defines what that "key" means, and what a valid "value" looks like.

We recognized that there will eventually be a lot of ContextItemDefinition(s) so we designed in attributes to help us classify them.

There is a process for submitting new ContextItemDefinitions through AgGateway's Standards and Guidelines committee.

ContextItemDefinition(s) are available from a RESTful web service, but you could cache them locally.

We know people won't always wait for approval, so there is a way to use them in an ad-hoc fashion.

Right now this is just a code list, but in the future we will add a way to assert relationships between ContextItemDefinitions, ContextItemEnumItems, and external sources of information.

Opening Statement

AgGateway, a nonprofit consortium of 240+ companies, leveraged its wide crosssection of PA stakeholders to propose a collaborative solution.

General Problem

The broad adoption of precision agriculture (PA) is still limited by a lack of hardware/software systems interoperability.

The ADAPT project addressed this issue by creating a field operations common object model that satisfies data requirements contributed by a cross section of industry stakeholders.

The common object model meets requirements from AgGateway’s SPADE and PAIL projects, including compatibility with the ISO11783-10 standard (ISOXML) and participant companies’ own systems.

Current trends in sustainability, traceability, and compliance reporting demand an ever-increasing amount of data be gathered as part of everyday operations in modern production agriculture.

Specific requirements for what data is collected, how often, and in what format are constantly evolving and highly geo-political context dependent.

This makes fulfilling all the requirements for a common object model a moving target, unless it is possible to decouple the infrequently and frequently changing aspects.

The relatively static core components of the ADAPT framework are minimalist in nature, but contain placeholders for attaching ContextItems (which are supported by a dynamic, data-driven system).

Consider the humble key / value pair; both beautiful and powerful in its simplicity. It has a weakness however. The key is limited in how much shared meaning it can effectively communicate without compromising the brevity that is another feature of the key / value approach. The solution was to create a controlled vocabulary of "keys" that would allow for the detailed description of the data point of interest while being kept separate from its usage.

AgGateway’s SPADE project implemented a RESTful API to provide a machinereadable vocabulary of CI definitions; its Standards & Guidelines Committee created an adhoc group to manage the vocabulary.

This same approach can be used to graft additional, sematically-rich data onto objects from other data models such as ISO 11783-10. The CI system can be used jointly with ISOXML’s feature of associating unique IDs to its own locally scoped IDs (defined in ISO1178310 Annex E) This enables adding geopolitical context dependent data to ISOXML’s otherwise generic and highly machine specific scope, with no modifications.

Specific Problem

Can include here the material about conflicting sets of requirements. The PPT can be found HERE.

The need for the unified object model to simultaneously be

simple and compact enough to be easily understood and used, but broad enough to not leave out something someone needs to conduct business (simple vs complete)
generic enough to be accepted from an international perspective, but still be able to support the capture & communication of necessary region-specific data (generic vs specific)
able to express data in a controlled vocabulary (so everyone can understand what it means), but still allow that controlled vocabulary to be continually changing to match the nature of data requirements (static vs dynamic)

Internationalization is important for this work, but conflicting requirements must be reconciled:

ADM developers must seek universality, staying free of regionally specific clutter. However, different geographies’ business processes involve context specific data (e.g., USA EPA product numbers.) If this data not accommodated, the ADM’s relevance suffers.

Additionally, it is desirable to use a controlled vocabulary. However, the dynamic nature of business and regulation requires this vocabulary to be easily extensible. If this controlled vocabulary is allowed to become "stale", again, the ADM’s relevance suffers.

General Goal (of the paper)

Demonstrate the proposed Context Item system as a method for satisfying these conflicting requirements.

The goal: replace current systems’ need to support multiple, incompatible data formats, with a single integration to the ADM and a system of manufacturer specific format conversion plugins.

This enables reading/writing to new systems with little marginal development cost.

Specific Objectives (of the paper)

asdasd

Section Breakout

asdasdd

Browser not supported