Agenda and Minutes

Main Topics

Use decide tag for any decisions taken

1. Main goals for serialization of ADAPT

   1. Topic Leader:

   2. The desired outcome is that we have agreement on the purpose, scope and overall goals for serializing ADAPT.

   3. Pre-meeting notes and references:

      1. Is the serialization effort specific to the standard version of ADAPT begin done in SCORE or would it apply to existing .net toolkit as well?

   4. Minutes

      1. Still too much room for interpretation within ADAPT. Still requires a lot of one off interpretation per OEM.

         1. Kelly’s three principles seems general agreement to these principles

            1. Should be open format and semantics, if it cant be translated keep it out. Everything in ADAPT should be open and readable by anyone authorized to have the data

            2. Data has to be flexible. Cannot mandate what must be serialized, ie spatial data can be a point or polygon

            3. Should be as human readable as possible. Balance file size, some form of zipped GeoJSON maybe. If we go to Protobuff or some binary path we should consider developing some tools for industry to use to make data more accessible/human readable

               1. Is possible to have both GeoJSON and Protobuff combination - yes

               2. ADAPT standard effort will deliver a schema (JSON)

               3. Maybe enhance SCORE to deliver a Proto schema as well as JSON?

               4. Tool exists to convert JSON to Proto already that could facilitate this

               5. Human readable = drop into QGis easily to trouble shoot issues in the data

               6. QGis plugin may be difficult to manage due to open source license QGis is under

         2. What are we serializing?

            1. All of ADAPT?

            2. Requiring standard names? DDI’s, other things that may not be in an “approved” industry vocabulary list

               1. We need to STRONGLY encourage folks to use WG00-mediated controlled vocabularies, BUT give them an option to use proprietary ones.

               2. Need to do a better job of making sure people know when Agrisemantics Subcommittee meets

2. Key deliverables for Serialization project

   1. Topic Leader:

   2. The desired outcome is that the main deliverables required for serialization of ADAPT are identified and agreed to in order to scope a project/charter a working group

   3. Pre-meeting notes and references:

      1. Can serialize subsets of model “it is chunk-able”

      2. File sizes are reasonable

   4. Minutes:

      1. Main use cases

         1. Organizations to store data internally (persistent data storage) Not in scope

         2. Sharing data sets between systems

            1. Trend in industry seems to be OEM’s store data and share somewhat “processed” data

               1. ie three combines in a field, but share yield map without any DDOP, or machine identifiers, all data merged

               2. Is that ok, do we need the “original” data generated by each machine and the implement geometry etc. that comes with it

               3. Some concerns over being able to fix/understand data that has been lumped/processed together

         3. One file, side car files ok?

            1. ie Summary vs logged data in ADAPT

         4. Strictly time-series logged data

         5. Spacial representations

         6. I need to transfer data to someone else efficiently and they need to be able to understand it Primary Use Case

      2. Technical solution

         1. Proto buff, …

         2. Ideally will be determined by requirements, ie human readability

            1. Conduct some experiments to make informed decision on file size, human readability

         3. Corteva/Granular open sourced Geostream, a compressed geojson format https://github.com/granular-oss/geostream

3. Proceed as an AgGateway working group

   1. Topic Leader: @Ben Craker

   2. The desired outcome is that the group agrees to how the serialization effort will be managed

   3. Pre-meeting notes and references:

      1. Preference is to run as a normal AgGateway working group, this provides the clear charter, tools, and process for creating a digital resource

      2. Also would be under AgGateway’s antitrust and IP policies making it clear how any contributions (code, or general knowledge) would be handled

      3. Can still utilize GitHub repo or confluence pages or other tools, whatever makes sense to achieve the deliverables laid out in topic 2.

      4. Only limitation is would be limited to AgGateway members

   4. Minutes:

      1. To build off what ADAPT currently is as an open source project, it may hinder participation/adoption if working group is limited to AgGateway members

      2. Working group could produce serialization and contribute to/as open source project

      3. Question if Europe is aware since most have been off the last ~month to voice opinion either way

4. Project Leadership

   1. Topic Leader: @Ben Craker

   2. The desired outcome is that the group agrees to who will be the chair/vice chair of the working group

   3. Pre-meeting notes and references:

   4. Minutes:

      1. Chair: @Bryce Hemme

      2. Vice-Chair: @Stuart Rhea (Deactivated)

5. Meeting time and cadence

   1. Topic Leader:

   2. The desired outcome is that the group agrees on the time, dates, duration, and location for subsequent meetings assuming there is consensus to move forward with the project

   3. Pre-meeting notes and references:

      1. Meet weekly, bi weekly, for an hour, two hours, schedule a couple day face-to-face?

   4. Minutes:

      1. Meet virtually to get started, in-person during/around annual conf.

         1. 9-12 Monday 14 Nov Clear Water Beach, FL AgGateway Annual Conf.

         2. Tuesdays at 1:30 central for one hour starting Sept 6

Closing Topics