We'd like to invite interested folk to a session on sharing data between FarmOS instances – specifically to enable organisations to create a portfolio or aggregated view of many individual farms.
Description
We’re seeing strong demand for this use case in Australia – as there are range of organisations (from banks to farmer groups to government) that have a need to collate data across farms. By way of example, we’re seeking to enable a bank to create a portfolio view of data from their client’s farm digital twins (AgData Wallets) to better understand their scope 3 carbon emissions.
The 3 hour session would be across an afternoon – with a vegemite sandwich break at half-time. We’d aim to include:
Needs Assessment – we’d map the different use cases, and the pains and gains this capability could deliver
Features scoping – we can collectively imagine the way this capability could work
Given the interest from corporates and government, we’d like to explore whether we could invite some Australian representatives to attend an online hookup at the tail-end of the session – where we can present our findings and gather feedback, as a quick way to test and iterate on this group work.
Who should attend?
Those interested in sharing data between FarmOS instances – to support research, risk management, impact reporting, portfolio analysis etc. Also anyone exploring how to create sustainable business models around farm data management. Or anyone who likes vegemite…
The basic idea is to build a web application (separate from farmOS), which uses the farmOS Aggregator in the background to communicate with any/all farmOS instances that volunteer to be connected. The app would request high-level summary info from each instance, such as general location, and then display this on a map, as a way for farmOS users to opt-in and share that they are using farmOS.
This feels like something that could be generalized, so that it could support other use-cases as well, like the ones you describe @Rohan. Or at the very least follow a similar pattern: multiple farmOS instance => farmOS aggregator => app w/ summary dashboards. FWIW this is the same pattern that the CoffeeShop uses, where the CoffeeShop is the “app” pulling data from multiple instances through a farmOS Aggregator.
Alternatively (and maybe this is more what you were thinking): I can imagine a single “high-level” farmOS instance that aggregates data from multiple other instances. I think this would probably follow the same pattern as described above, though. In this case, the “high-level” farmOS instance would be the “app” that pulls data from other instances, most likely through a farmOS Aggregator.
That would be the best way to architect this, I think. Then it’s just a matter of answering the question: does the “app” need to be a full-fledged farmOS system itself? Or can it be simpler/more specialized for the summarization/reporting it wants to do? I think this will depend largely on the use-case, but my gut says most of the time the latter would be true, and a simpler reporting app would be easier to build/maintain.
I would love to see something like that built in a general way, so that it could be applicable in multiple use cases! I imagine the outcome of this team activity would go a long way to informing those requirements and considerations.
Looking forward to seeing what ideas come out of this!!
Also if folks missed it a VEGEMITE SANDWICH I mean really you can’t beat that.
Super excited to attend, I think for so many groups using or thinking about using this tooling @cjospe and crew, the BFA folks (not sure who’s coming but @DanT can represent), probably @courtney.king to help manage many instances in CEMAs or related type projects, PASA, @zweig716 at GM, probably also @snapp at MSU among others.
