Defining Planned & Prescribed Documents

[knelson-farmbeltnorth]

As implemented, a plan and recommendation are simply two names that describe a collection of work items. A Work Order as implemented is an aggregate concept that provides an alternate data path to work items and status updates.

We should define a single concept to describe a collection of work to be done and communicate variation via a property on it vs. having separate types

[knelson-farmbeltnorth]

@strhea Per our conversation, can you provide definitions for Plan and Recommendation, and also clarify how WorkOrder may or may not be different.

[knelson-farmbeltnorth]

This document provides substantial context. These objects arose out of earlier AgGateway work and while not much exercised in current ADAPT use cases, provide a lot of collective insight into modeling agronomic activities beyond Field Operations recording.

http://s3.amazonaws.com/aggateway_public/AgGatewayWeb/About%20Us/CommunicationsKit/AgGateway_core_documents_72616.pdf

I'm closing this issue since the concepts are not redundant; they are simply lacking definition and implementation guidance in the current C# codebase, which we will fix going forward.

The collection of work items is not redundant when you consider the context of each of the 3 parent objects. That work items exist independently in a collection at the root of documents foreseeably facilitates the same WorkItem being Planned or Recommended and subsequently Ordered.

[knelson-farmbeltnorth]

Reopening this issue to fix meaning on these concepts which today are ill-defined. Most of my proposals ultimately map to CropZones vs. allowing implementers any number of conceivable approaches to modeling the data. See issue #66

Plan: Optional document collecting operational intent for a growing season. A plan will define a collection of intended Crop Zones, defining a crop for each field/partial field and may further define dates and intended operations (WorkItems). Multiple mutually exclusive plans may exist for a single season to allow for runtime flexibility. A plan documents management intent.

Recommendation: Optional document collecting agronomic actions prescribed by agronomic advisors or decision makers for a single antecedent plan or mutually exclusive set of agronomic advice. A recommendation will define a collection of Work Items. Parent Document Id maps to any antecedent Plan. A recommendation documents agronomic advice given.

Work order: Optional document summarizing the final collection of agronomic instructions (Work Items) to be acted upon once operational decisions are taken. 
Parent Document Id maps to any antecedent Plan or Recommendation. A work order documents operational decisions taken.

Work Item: A collection of defined agronomic instructions for a single Crop Zone at a single time. E.g., a CropZone should be planted and fertilized on a particular date/date range, utilize a prescribed rate (manual prescription) or rates (variable rate prescription). In the case of single pass applications/operations, each operation is a WorkItemOperation. Any realized work item takes the form of a Summary (manually or automatically recorded) or LoggedData object (spatial data recorded)

Work Item Operation: A single agronomic instruction for a single Crop Zone. E.g.s, reference to a variable rate prescription or simply that the Crop Zone should be fertilized as of a certain date. Any WorkItemOperation realized takes the form of an OperationSummary (manually or automatically recorded) or OperationData object (spatial data recorded)

[strhea]

I think CropZone is a little stickier. Not everybody uses that lowest level of the hierarchy. Many systems document their field operations exclusively at the field level. While I am a strong advocate for the CropZone concept, I don't think we can mandate its use that way. The description of land/area usage in a field operation needs to support both the Field & CropZone objects.

In my opinion, WorkItems was supposed to be used by value inside a containing Document. It should have never been given a "by reference" place in the Documents "catalog". The biggest hazard of using it by reference is that it complicates the need to support the reality of last minute changes (usually at the work order level) that would change the meaning of previous records referencing the same work item.

[knelson-farmbeltnorth]

@strhea That concept of different systems modeling differently is at the heart of my question (/implicit opinion) in #66 . It is fine to support Fields and CropZones because some Field Operations (tillage) don't have a Crop. It is not ok, IMO, to allow different systems to model data differently due to how their internal models may be.

Either ADAPT has CropZones or it doesn't. If ADAPT uses a CropZone, and source system X doesn't have a CropZone, but they need to reference a Crop on their Field, then they make a CropZone in ADAPT. If we allow different implementers to do different things based on preference, we have no standard. We are then in the same boat as today where consumers need to have conditional logic based on identification of the source.

[knelson-farmbeltnorth]

The Sept 14 meeting accepted the above definitions as valid for the objects as they exist today.