ADAPT / Standard

ADAPT Standard data model issue management
https://adaptstandard.org
MIT License
8 stars 1 forks source link

Relationships between Grower, Company and Person #7

Open knelson-farmbeltnorth opened 2 years ago

knelson-farmbeltnorth commented 2 years ago

Brand currently has a mapping to Manufacturer which I'm interpreting as required.

Neither Grower nor Manufacturer has any relationship to Company, which is the mapping from Facility and PersonRole.

We need to clarify these or they will be used without consistency.

My initial thinking is that a Manufacturer and Grower are both Companies and what is applicable to any Company can be applicable to Manufacturers or Growers.

brycehemme commented 2 years ago

Manufacturer and Brand make sense.

The first gap I see is a grouping mechanism for people that farm together (Farming Operation) although that is sort of handled via Grower through the GrowerId on the PersonRole class.

The other gap is the potential need to model out a hierarchy within a company. If we think of Company being something like an ag retailer, is there a need to model out organizational hierarchies within the company? For example, BigAgRetailer might want to track all of their employees (Person/PersonRole) into separate territories such as western IA vs. eastern IA. If this is something we think is an in-scope use case then I'd question if a generic concept of Organization would be a better solution in order to track an organizational tree (recursive Organization objects) where Person/PersonRole objects can be attached to any level in the tree.

knelson-farmbeltnorth commented 2 years ago

We discussed on the Aug 10 call.

There was general agreement that Manufacturer and Brand are good as they are. They should not be anything other than textual reference information by which one can categorize inputs or equipment. As ADAPT doesn't model the manufacturing process of inputs or equipment, it would be excessive to tie these into richer objects intended for the agricultural production process.

Company is intended to mean an entity working with the grower in some way. I.e., a retailer, cooperative, crop consultant or custom applicator/harvester.

@brycehemme and @strhea both have brought up the need for additional hierarchy above GFF, and there was agreement on the call that we should rethink the relationships between Person, PersonRole, Company & Grower.

knelson-farmbeltnorth commented 2 years ago

Updating title for clarity moving forward.

knelson-farmbeltnorth commented 2 years ago

I'm proposing that we collapse Person and Company into a single object called Party. In many cases, the assignment of responsibility is to a company without knowledge of individuals. In other cases, a sole proprietor is indistinguishable from his business.

The Party object will have a Parent Party Id allowing for n-levels of hierarchy. E.g., an individual can map to his business or business subsidiary, the subsidiary to its parent and so on.

PersonRole becomes PartyRole and dtPersonRole becomes dtPartyRole in the RepresentationSystem.

Lastly, we need to add an "Other" type to dtPartyRole. While the below list is long, there are certainly types of business relationships we cannot anticipate.

Authorizer Crop Advisor Customer Custom Service Provider Data Services Provider End User Farm Manager Financier Fixed Asset Supplier Government Agency Grower Input Supplier Insurance Agent Irrigation Manager Laborer Market Advisor Market Provider Mobile Asset Supplier Operator Owner Transporter

strhea commented 2 years ago

Is there a need for a "party type" property to distinguish between Person & Company in defining the resource? That distinction would be separate from the "party role" property used in explaining how the resource is used in the context of a field operation.

zwing99 commented 2 years ago

+1 for Party! 🎉

I would agree with @strhea that we need to have a Party Type. I am open to it being a boolean (IsPerson) if that is easier with a default of false. Or as an Enum with values of Company, Person, and more to be added later. I would, however, suggest that we want to avoid having an "Unknown" type of Party. I think it risks being overly defaulted and unuseful in communicating information between FIS systems. I would suggest that we instead default to Company or IsPerson=false.

knelson-farmbeltnorth commented 2 years ago

Agreement on Oct 19 2022 call for condensing Person & Company into Party, with the addition of the Party Type. For now, there is no consensus on Party Type Unknown so we leave that as an open issue.

Further agreement that PartyRole should be a value and not a reference type, and its id and name be removed. In the call we validated the usages of PartyRole in the system and confirmed a single role is appropriate on a Summary Value, with multiple roles appropriate elsewhere. We decided to avoid adding PartyRole-Other, choosing instead to encourage additions to the list rather than misclassified data.

knelson-farmbeltnorth commented 2 years ago

PartyType is currently defined as follows. "Business", "Individual"

Whether or not to add Unknown is the one remaining item on this issue.

knelson-farmbeltnorth commented 2 years ago

November 30, 2022 meeting resolution: PartyType should be "Organization," "Individual," and "Unknown"