ContextItem Discussion - 2016 ASABE AIM

Owned by R. Andres Ferreyra (Unlicensed)
Last updated: 2016-06-09 by Stuart Rhea (Unlicensed)

Enabling incremental progress

The ContextItem system provides a way to preserve the simplicity of data models that utilize it by allowing these models to first focus on expressing "universal" ideas with their core objects and then enhancing those objects with geopolitical-context-dependent specifics through ContextItems. New models (like ADAPT) can thus start simple and grow organically over time.  Likewise, existing models (like ISO11783) can be extended in a dynamic, data-driven way. This is all possible because the system provides a powerful test bench for data model improvements: a ContextItemDefinition (conceivably not restricted to geopolitical-context-dependent attributes) can be proposed, tested in real world usage, and subsequently either incorporated into the data model as an object class attribute, kept for use as a ContextItem, or abandoned entirely.

Extensibility is decoupled from data model versions

The ContextItem system allows for the common object model (and other standards) to be extended without requiring the release of a new version of the standard. This is crtically important in industrial IT environments, where updating to a new version of a data standard generally represents a huge expenditure of resources in migration, training, security audits, and so forth. Following a data-driven approach enables users to retain the same standard version implementation for a longer period while also allowing progress outside of the traditionally slow standards making process.

The use of external code lists to support data exchange in an industry is not a novel cocept: a prime example of their use is the ISO20022 standard used internationally by the financial industry. There is usually a tradeoff in such usage, in that using external code lists makes it harder to validate a particular instance of the data model (because the code list is not built into the model itself.) We believe that the impact of this problem is minimized in the ContextItem system, because all of the ContextItemDefinitions (and their associated enumeration items) are readily available through the ContextItem API in a single-format. Thus, implementing the mechanism to validate a ContextItem against all of the (limited number of) possible ContextItem value types enables validating all possible ContextItems. This makes for very efficient and scalable use of the system. 

To-Do: (Would be nice to include an Annex with pseudo-code for validating all of the current version's value types)

Minimal a priori knowledge needed for use

FMIS developers have heretofore often been forced to hard-code geopolitical-context-dependent  attributes (often in rapidly-changing regulatory contexts), and have had to manage multiple geopolitical-context-specific versions of their software. This increases costs, and limits the implementation scalability (and market expansion) of FMIS products.

The ContextItem system should bring welcome relief, because it allows for the collection and communication of data yet does not require the facilitating software to understand what that data means. This has rather revolutionary implications for farm management information systems (FMIS):

  • When allowing the user to enter data to describe a given object (say, a person, a field, or a document) the FMIS can search the ContextItem API by ModelScope and/or GeoPoliticalContext to find what ContextItemDefinitions are available for the object being entered.
  • The ContextItem API can then deliver, for each of the available ContextItemDefinitions for that ModelScope, all the data the FMIS needs to present the user with a user interface to populate the ContextItem.
  • Thus, by virtue of integrating once with the ContextItem system, FMIS can allow users in multiple geographies to enter data specific to those geographies, without making any changes to the code of the FMIS. Moreover, as the list of ContextItemDefinitions for a given GeoPoliticalContext grows, the FMIS becomes progressievly able to enter more and more data pertaining to the local business processes.

A starting point for richer semantics in field operations data exchange

 

Business-process-specific data exchange among different FMIS is currently very limited by proprietary implementations of geopolitical context dependent data. In practice this translates to inter-FMIS data exchange being very infrequent The ContextItem system is a major step toward building a semantically-rich vocabulary for industry-supported, local-business-process-aware, data exchange in production agriculture field operations. The authors hope this will translate into greater electronic data exchange between growers and their trusted partners, a corresponding greater accuracy and efficiency, and less opportunity for error. 

Enabling the use of existing controlled vocabularies

General point to make: lots of collective effort has gone into producing controlled vocabularies, but use has been limited by the need for ad-hoc implementations. One-size-fits-all system means if you can encode your vocabulary as a ContextitemDefinition, everybody can instantly use it. 

German crop list example

EPPO example

Encoding proprietary payloads

During the development of the AgGateway Reference Data API system, several manufacturers expressed interest in being able to leverage the investment in Reference Data API infrastructure to deliver premium content to selected subsets of users ot the API (e.g., paying or otherwise special customers.)

The ContextItem system is consistent with this idea of enabling premium content delivery

Proposed syntax for Code:

Pr_[GLN]_[Proprietary suffix]

Example:  Pr_1234567890123_T45  would represent a proprietary code created by an organization with a Global Location Number or GLN () of 1234567890123. The meaning of the code, presumed known by the sender and receiver of the data, is represented by the alphanumeric suffix T45. Note that only the initial "Pr_" prefix is required; organizations lacking GLNs, or who choose not to include them into the code, can use any arbitrary alphanumeric syntax following the initial underscore ("_") character.