Updates from our-sci side:
- Currently have a set of good examples of pass & edge cases, now working on fail cases
- Location vs Geometry - Location is a reference to another asset; geometry is the actual shape (they can be related - e.g. if you have an input log, it can say ‘this is an input to Field A’ which is a location, but it could be referring to half a field, a point, or a set of lines–that’s the geometry)
- This structure makes it possible to record data that has no fixed place (can tell a story about a corn crop & how it was treated and when it was harvested without telling where precisely it happened - easier for sharing)
- Input via surveystack (then export via api-compose), then use json export thru a verifier (2-fold system) which worked (setup was good for showing if OG data or validator needs to get fixed)
- this showed lots of the trickiness of working with json-schema - roles & ID were tough
- Also made a tiny tool that recognizes which convention you’re using (mostly works) - space for improvement - general category for taxonomy term has to be manually determined
- Use cases - COMET for USDA, can use generally for validating (something) via API,
- doing something essentially similar for PASA (comparing to existing data – but would be awesome to make a convention based on PASA entities & be able to validate each submission - could be a sub-convention of current conventions, but they use different base schemata. The gap or custom work needed is…around custom attributes, quantity types, relationships such as Planting that are missing in their data, etc)
- Goal is to use them as starting point - if we can’t match them to core convention, we’re doing something off
- Greg’s goal in the future is Convention Driven Development (:D) - do more feedback gathering for convention itself, then make something like a pasa module based on that convo.
- When yr moving from a strict data model → flexible data model, could be worth starting with conventions & documenting them first
Descriptions digression
An ideal description would work in every context - in farmOS UI, in API, and for data scientists reading the convention (hard!) - can do this some in comment.attribute - but one description for every audience = the worst for everyone. Decision point where we split in 2 between label & description? Or name, api description, data description? Make a really long description with the first sentence being UI?
- Addl complication where everything in farmOS is translatable - don’t want to make breaking changes
- Adding additional description just for data model seems like a good fit
- Drupal is working toward including json into drupal.core (in umm 10 years)
Cost data & related conventions
- Current options in farmOS core - Quantities are the place that most makes sense for cost data - activity log, add quantity, set measure to ‘price’, enter cost there. - Can also use add-on module called farmOS Ledger - adds 2 new log types, ‘purchase’ and ‘sale’ to refine. Also adds new Quantity type ‘price’ which can be total price value, also adds unit price & unit quantity
- Can use in conjunction with ‘inventory’ also, or can use for things like equipment etc
- What are the implications for CCD?
- Discussion of energy convention - similar to cost - energy as quantity relationship describing what is consumed. Then convention is any log + . I.e., i purchased amount diesel which increases my diesel quantity, then you track how much is used (without purchase information, just use) - so would need to track purchases & average across price for inventory in order to get cost data
- Level of detail needed by user is highly variable
- Calculated vs recorded information is hard to track (may know a transaction happened but not details of that transaction - may let you calculate, may not )