I started sketching out another post for the blog that I was hoping to get some early feedback on. The later parts are just an outline and I’m not totally sure where I’m going with it. All feedback welcome. Please feel free to tear it apart 
Thinking about Organizing Agricultural Data with farmOS
Any kind of record keeping should serve a purpose. Record data itself is useless unless it can provide some insight, shape future decisions, or satisfy external requirements.
In agriculture some example drivers of record keeping are tracking the pedigree/lineage of animals/plants to help manage genetic diversity or breeding goals; tracking yields inputs and crop rotations to detect patterns in what practices are working; and gathering data required by regulatory bodies for permit or certification purposes.
Unfortunately, one can’t always predict what data will be needed for these things. Thus, a common strategy is to keep some sort of records even when the exact purposes to which they’ll be put aren’t yet known.
There are a lot of options when it comes to what tools that can be used for agricultural record keeping. Among these options is farmOS. farmOS lands in a sweet spot on the gradient between on one hand free-form tools like paper notebooks or spreadsheets and on the other hand purpose-built tools that target specific market/livestock/regulatory niches.
farmOS lands in that sweet spot by providing a structure of record primatives while remaining largely unopinionated about how data is organized within that structure. On top of that farmOS is highly open and extensible which allows for more opinionated consistency rules to be added on a use-case by use-case basis. It is also possible to use farmOS’ API to programmatically restructure large amounts of data as one’s recording keeping requirements evolve.
Where to Start?
It is clearly critical to determine what granularity of data to capture. Even if one could easily track the movements and growth of every macroscopic organism in an area with technology, the data wouldn’t be very useful by itself. Yet more technology could probably be used to infer some types of meaning from all that data, but the complexity of such a system would be enormous and very costly from a sensing-hardware, storage, and computational standpoint.
Fortunately, by working backwards from some hypothetical goals for the data, we can arrive at a much more reasonable strategy. We don’t need to track every ant and native shrub to have useful records for a market garden or a goat farm. The market garden might want to keep track of what is planted where, when it was planted, and harvest dates/yields. The goat farm might want to keep track of age, sex, breeding events, and so on about the goats.
It is easy to get overwhelmed imagining all the things that one might want to keep track of, however with farmOS it is easy to start small and - with a few reasonable assumptions - the patterns will scale to capturing more and more types of data as it is warranted.
Often it is helpful to look at one’s goals for the agricultural operation as a whole. If the goal is to raise animals, then perhaps tracking the individual animals or herds of animals is the core primitive to start with. Similarly if one’s goal is to grow vegetables perhaps the core primitive is plants or land areas (fields, or beds) of plants. In farmOS the first step would be to create assets for these core primitives.
Part of that process is determining how to connect between the physical reality and the records on the computer. Chances are there is already some sort of naming strategy and this tends to form the first layer of connection.
Asset Type and Granularity
- When to use an existing asset type vs a custom one
- Pros and cons of fine/coarse granularity assets. i.e. animals vs herds
Naming Assets
- Ideas for designing naming patterns or adapting existing physical naming/tagging systems to farmOS.
Log Type, Purpose, and Frequency
- When to use an existing log type vs a custom one
- Tradeoffs with fine/coarse granularity logs. i.e. play-by-play activities/observations vs the minimum set of logs to capture only key changes
Naming Logs
- Ideas for designing naming patterns or adapting existing task tracking/naming to log names
Next Steps
Allude to future posts about capturing data via quantities, inventory, sensors, and more
