Technical Summary of the OADA Approach
The following sections contain technical details and are written for architects and engineers.
To address the farmer’s data interoperability and security concerns, a set of common, extensible REST API specifications will be defined. Precision ag systems that want to take advantage of this data interoperability and want to securely access farmer data will build their systems to match the OADA API specification. While a precision ag system will create an implementation of the open source OADA API specification, the implementation itself is the IP of the entity implementing the OADA API. Building an implementation that adheres to the OADA API specification in no way requires the implementation to be open sourced. The open source OADA API specification is merely a vehicle to facilitate interoperability between both open and closed precision ag systems.
The REST API specification will focus on data exchange that allows data from any precision ag platform in any format to be easily transferred between platforms. The API will not be concerned with the details of the data format of the files being exchanged beyond including information about which kind of format they are. This will allow APIs to easily evolve over time with new features and still remain backwards compatible. Combined with the industry standard OAuth 2.0 authorization protocol and successor versions, the API specification will have common data sharing semantics that ensure only farmer approved trusted agents or vendors can have access to the farmer’s shared data. The API will have operations that allow data to be shared both permanently and temporarily as the farmer sees fit.
A verification suite will be created that can automatically be run against vendor implementations of the OADA API specification. Results of the verification suite will be used to measure a platform’s compliance with the OADA API specification and ensure interoperability across the industry. Development of the above will occur openly in the community for all to see. An open source agile development approach will be used. Code will be placed in publicly available source code repositories released under the MIT License for everyone to freely contribute and use.
The community will drive the ultimate roadmap and specific features of the API specification. Through this open, community-driven effort, farmers will get precision ag platforms that are able to easily integrate despite the diversity of data formats. Support for future, yet to be defined industry data standards will be enabled. An environment that facilitates the creation of innovative services that benefit the farmer will be created by lowering the cost of entry to integrate among precision ag platforms and by having common security mechanics.
OADA will naturally facilitate a discussion in the industry of what proper privacy and security practices are for ag data. Community guidelines will be developed that third party auditors can use to evaluate varying levels of OADA compliance, and the industry as a whole can use as a common language to properly and easily relate the ramifications of complex technical details. For example, OADA “level 1” and “level 2” compliance will have a definite meaning, and the industry can begin with that definition as a means to communicate and compare business practices.
The features described here are a starting point and will eventually be finalized through involvement of the broader OADA technical community. A first draft of the API can be found on GitHub at https://github.com/OADA/oada-api-spec/blob/master/oada-api.raml
Building a common, extensible, interoperable REST API that allows data to be stored and transformed in any format requires defining a standard mechanism from which farmer data can be referenced. To simplify integration the API will expose the data through a file system paradigm. Farmers and external systems will reference farmer data through file paths and unique file identifiers. The underlying implementation of the API does not need to store files and paths: it only needs to provide the interface. A given implementation can use a distributed file system, database, or any other storage mechanism that works best for their needs. No detailed knowledge of the files’ underlying storage format will be required to store or transfer data. The API would initially have the following key capabilities:
A reference implementation of the API specification in a yet to be identified programming language will be developed and maintained by the OADA technical community and hosted on GitHub.
Accompanying the reference implementation will be a verification suite. The verification suite will contain a set of functional tests to validate each feature of the API. The verification suite will be automated and can be run on a repeated basis to measure the compliance of any implementation with the OADA API specification.
Other potential community driven technical artifacts include transformation libraries that convert data between the different proprietary industry data formats and existing open standard formats such as shape, GeoJSON, etc.