Hi all esp. @mstenta, have been working through the api switchboard and plant data service ontology work recently, and thinking a lot about how we can use the aggregator to better visualize results back to farmers and others interested in reviewing aggregated farm data.
In talking to Richard from Rothamstead, we are both doing similar work which is needed to move forward - we are creating a standard ‘interpretation’ layer on top of the core farmOS schema. What does that mean? It means:
- Fully explaining how and why we use each variable… like log_category… what exactly is the end use of that variable? How do we represent ‘intention’ (tillage for weed control) versus ‘action’ (tillage is a machine operation), what is a ‘material’ versus a ‘quantity’? What is the intent behind the ‘quantity’ ‘name’ field… how will it get used?
- Hard define certain lists so that comparing data across farms is more likely to be successful. So I would put log_category, units (in quantity fields) and a few others in this category.
- Creating a framework for what this ‘interpretation’ layer is and how it’s implemented.
On item (3)… here’s what I mean:
- Who is this data going to be used by (ie who’s interpreting it?).
- Modelers (they care about actions, minimal but very specific details)
- Farmers looking at their own farm data (they also care about actions, need all details)
- Farmers comparing data from their farm to others (they are interested in intent, need to summarize things for effective comparison)
- Certifiers looking at many farms (they are interested in actions, but a limited set, and may also need the ability to summarize differently than others)
- Purchasers or marketers comparing many farms (they are interested in highly summarized data, and the organization of logs / assets may need to be different).
- How will the farmOS data be merged or organized by the person using it
- modeler, API to Python for example
- dashboard, API from aggregator to JS for example
- … etc.
If we can agree on a process by which we can evaluate this ‘interpretation’ layer, then those already doing it (RFC, Rothamstead) could begin to create a common interpreation layer and maybe even implement it as a … farmOS module (mike is that how we’d do it???).
I could be totally off here… any thoughts ideas would be great.