Hi all - broad question here. I’m trying to find a good structure to store information about the presence of conservation practices in a way that’s reportable to an external body. In my particular case, ESMC has questions relating to conservation practices like drainage, grass waterways, vegetative buffers, etc. etc. (let’s use grass waterway as an example going forward) Conservation practices are commonly used for applications through conservation districts or even the USDA. Basically, those institutions want to know ‘for this field/planting/building/etc., in any given year, does it contain a (ie grass waterway)?’.
Here’s some thoughts…
-
I could create these as assets which are associated with a field (so grass waterway asset, associated with the field being asked about). When ESMC or other institution wants to know ‘how long has this conservation practice been in place’… I would need to look up the date created… but that’s not very accurate because it’s possible I entered the information in 2022 but the waterway was present in 2018. So I’d need an extra field for ‘date created’ that was more visible in the UI. If the waterway goes away, we’d need to be able to note that - probably by archiving the asset. Probably also you’d want to have a flag listing the conservation practices themselves (flags make more manageable lists than just sticking the practice name in the name field).
-
Or… we could create a log describing the practice (so grass waterways log) and then assign a season to it. So each year, you would add another season. This is more explicit (seasons need to get added, rather than time simply passing and assuming that the grass waterway is still in place). There’s pluses and minuses to this.
→ Quick question… where do I even find seasons? I can’t find see them in the API and didn’t find info about them in the documentation… ←
So what do you think? What’s a good way to manage this type of data which has a common use (conservation practice data is widely used across many programs) but it’s actual implementation varies a lot on the ground (look at this list… pretty variable! → Conservation Practice Standards | Natural Resources Conservation Service).
1 Like
Seasons are a taxonomy, and the only thing that references them right now are Plant assets.
That’s just a carry-over from v1, but it makes sense to me to apply it to more records as well. Although I’m not sure it would make sense to apply them to Logs…
What about a new taxonomy (“Conservation Practices”), provided by a custom/contrib module, which can be referenced from assets/logs?
Or… perhaps just a new set of flags, with a “Conservation Practice: …” prefix to group them all together?
(Looking at the list… nah… too many to add as flags.) 
In the UI they’re under /admin/structure/taxonomy/manage/season/overview and under roughly that same path from the menus (under taxonomy);
Then click “List terms” from the list of taxonomies.
They’re in the API under /api/taxonomy_term/season
Another strategy could be to just have two logs. One for the start of the management practice (perhaps together with Mike’s idea of a new taxonomy term type “Conservation Practice”) and another log for the end of it. That way the list of seasons on the first log/asset doesn’t need to grow indefinitely and it can capture any time range using the existing log timestamp field.
1 Like
I saw them in taxonomy, but couldn’t see them in the api (I wanted to push stuff there potentially). But yes! I see them now, sorry about that – I had been looking in logs but didn’t look in assets, thank you!
Yeah @Symbioquine I think that’s a good third option. It’d be easy to externally query the state of any given field… just say ‘do I see any “start” logs for ?’… if yes, then assume that practice is in place. If no or a “end” log exists then no… That’s doable.
I think these are all good options, I’m sure @mstenta we can talk about this as we re-evaluate the USDA data structure also and refine the right answer.
2 Likes
This is exactly how “asset location”, “group membership”, “inventory”, etc work…
We’ve talked about generalizing some of the logic so that it is easier to reuse this method for other type of “log-based properties” of assets. This could be a good one to explore as well.
It may come down to a simpler question though: how does this need to be queried/used?
Do we need to ask “is this log/asset part of a particular practice”? If so a simple term reference field on the log/asset is enough.
Do we need to ask “is this particular practice currently being employed”? That is a bit tougher to be certain of, even with the above logic, because it also assumes/requires that the records are up to date, which they may not be. But it could work!
1 Like
