Conventions Call June 20th 2024 - cross project updates & discussion on Location, Planting, Geometry

Convention convention - using a standardized reference to refer to a convention [taxonomy_term–convention]

When we hold an in-person meeting…that would be a convention convention convention :smiley:

Updates

  • Vic - early conversations across partners at Qlever/AFT/OpenTEAM/farmOS around using & sharing minimal data models for PCSC
    • Reorienting from talking about partnership & integration after groups have decided how to collect & store data, exploring the idea of using the Minimal Data Model they’ve built to support the development of data collection & storage systems → using that model as a translation layer to build with rather than waiting until partners have all their data ready in a csv for ingestion
      • If there’s a call about querying farmOS api directly – Greg has thoughts! About aligning w conventions
  • Greg - update from Alex from Startin’Blox & OFN developments
    • Using Solid protocol in Startin’Blox to make lists of farm products available to public - want to integrate this with farm information management systems (early option= litefarm), & want a common data model \
    • & great chance to build out accessible introductions to conventions stuff / building out FAIR documentation :smiley:
  • Rose - Making examples for every potential Activity & documenting conversations & errors necessary for building
    • E.g. ‘fertilizer’ - standardizing to a single convention^2
    • Updates to API Compose
    • Building examples of what is correct & what isn’t and validating those = building confidence that convention does what we expect it to do
      • Uri that resolves to schema (yay)
      • Design concept in base convention is that we don’t restrict base attributes - may need to chuck in additional information that would still pass
      • Conventions audit table as source of minimal set of examples - as we discover edge cases, add a new example
  • Juliet - Holding CCD steady in prep for forthcoming presentation

Discussion

Location, Plant, Geometry - ongoing convo for last years with farmOS, USDA, etc - what are the baseline attributes for any data object that we need for end use (analysis, benchmarking, comparison, database querying, etc). These include:

  • Timestamp
  • Geometry (area, point, or line) - farmOS does not require this
  • Reference to a field
  • Planting

Some of this you can collect through a conversation– some, like geometry, you cannot. But in order to tell a story about an event, need to connect information to each other. You can do this without geometry (in fact, you may want that if you want anonymity) - if you have a consistent field name. Other cases include something like JDOpps that understands nothing except geometry associated with a piece of equipment. For USDA needs, they wanted the ability to start with ONLY geometry and deduce from it what happened.

Problem with creating a baseline convention is that these two extremes are opposed - requiring all of these three will exclude one of these cases.

Proposed solution is a baseline convention that requires NONE of geometry, planting, location. From there, make two child conventions that are updated as something changes in parent conventions, but one is geometry-only for every defined log & asset, and the other is field & planting based but does not require geometry (there are things that can happen on a field without a planting associated, like winter tilling).

This also allows for a piece of data that requires both child conventions, or builds on top of them. (i.e. could require geometries for soil test logs but not other kinds of data). Reduces forking & breaking changes, keeps alignment high.

Benefit of distinguishing up front which of these things is important for your data to require -

Challenges - You don’t know enough about what you need until after you’ve made it

Unfortunately you can’t know things before you know them!

Classic problem of convention development is that engaging with other people around data decisions sucks! It’s so boring! As the data facilitator/curator, it’s fascinating. But as the SME who has the data in their brain, it’s so hard to keep paying attention until your thing is relevant. But you have to be there to know & build consensus & find the points of conflict!!

1 Like