Opening Statement
AgGateway, a nonprofit consortium of 240+ companies, leveraged its wide crosssection of PA stakeholders to propose a collaborative solution.
General Problem
In building the ADAPT model we first threw in everything we could think of.
Then we realized that it was just too fat to be effectively used. In addition, there was a lot of US-centric stuff in it.
We wanted this model to be useful 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 place to dump all the rest of the stuff that was needed.
This turned out to be a good idea because it allowed us to solve 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
- "Data requirements keep changing" - this system is inherently dynamic; new data points are easily added and distributed
- Local business process
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