Considering adding a 'type' (?) to activity logs (or maybe all logs)

Development
1

Hi folks, here’s my situation:

We are building conventions over at the still infant convention builder git repo. The goal is to create a baseline convention in JSON schema that many groups can build ‘on top’ of - meaning, they can build schemas which are complain with this as a ‘parent’ convention. Thus, we want it to be more opinionated than farmOS’s API, but not so opinionated that it’s not flexible down the line.

Good news: mostly it’s working well :sunny:

But of course, we’ve identified something that’s likely to be a problem :cloud_with_rain:.

We have Conventions for the following activities:

  • mowing
  • tedding
  • raking
  • flaming
  • pruning
  • thinning
  • solarization / tarping

The convention itself allows for some added stuff like an area quantity (% of the field the activity was applied) and doesn’t prevent additional relationships or attributes - thus it’s a nice parent in not limited it’s children :slight_smile: . However, it doesn’t have an good place to store these Activity sub-types.

So, my proposal is (and I’m going to speak in FarmOS API speak because that’s how I understand FarmOS’s data structure) to add to relationships an activity field, linking to a taxonomy term, which would allow the creation and addition of specific activity types. This is nice because:

  1. it uses existing, common structures (relationships)
  2. it’s typed (taxonomy term) but flexible (it’s easy to add a new one) and easier to share than a hard coded array in attributes.

We had a conversation about this during the weekly call, and I feel I’m not doing it justice but at least I’ll get this idea out there, feel free to add your remembrances / ideas from there.

2 Likes
2

I remember talking about something like this with @paul121 a while back. Seems like a good idea to me, and it wouldn’t be hard to add. We might just need to think through the implementation details a bit.

I would probably recommend calling it activity_type to make it clear that it is a relationship to a type, not to another activity. This would also follow the existing convention we have with assets that have a sub-type field (eg: plant_type, animal_type, land_type, etc).

The difference between this and the existing asset *_type fields is that this would would need to be optional, whereas all (I think?) of the asset fields are required (you can’t make a plant asset without defining the plant_type).

Considering adding a ‘type’ (?) to activity logs (or maybe all logs)

I agree we should also consider whether other log types need something similar at the same time. Perhaps observation_type would be useful too, for example. What about input_type and harvest_type? Maybe those don’t need it?

I could also see an argument for only adding these to activity and observation logs as a first step. The way I have always thought about log types myself is that they are either an “active” or “passive” event. Activity logs are the default “active” event, and Observation logs are the default “passive” event. Other types, like Input, Harvest, etc are just more specific “active” events. You could argue that Lab Tests are an example of a “passive” event - yes there is an action taken to gather the sample and send it to the lab… but the end result is an observation of soil properties. None of this thinking is explicitly codified anywhere, it’s just how I think about it. All of this is just to say: adding activity_type and observation_type give us another option for making Activity and Observation logs more explicit, without requiring new log types.

Question: should these activity_type and observation_type fields allow multiple values? I can’t see any reason not to. You may be doing multiple things at once in the same activity, so categorizing it under multiple types would be useful.

3

I would probably recommend calling it activity_type

:+1: I think that makes sense

Perhaps observation_type would be useful too, for example. What about input_type and harvest_type?

I think observation and input potentially, but because we are using log_category pretty extensively for “intent” we end up capturing those pretty well (like fertilizer versus manure versus wood chips versus rocks… those can be related to amending the soil, preventing weeds, and bed prep or all three!). The problem with activity is you have several activities with the same intent, so there’s really very little to distinguish it.

Question: should these activity_type and observation_type fields allow multiple values?

I think for sure. There’s no real value in limiting it and it may be you’re doing multiple things in a single pass.

One last note - it did also occur to me that part of the problem I was solving is I couldn’t tell what something was without Regex-ing the name, which isn’t great. However, if we have a convention field (as we discussed in the weekly meeting) then maybe it’s less of an issue - that is, I can always determine what the thing is by looking at the convention id or whatever we call it. I’d love to also get that in place - I think we came to some reasonable conclusions on that as well.

1 Like
4

Ah yea! I was talking with @paul121 a bit about our conversations and he made a good point: if “intent” is what you’re trying to achieve with activity_type, maybe the new convention field would accomplish that goal without any additional fields necessary.

I still think there’s a good argument for activity_type for folks who aren’t using conventions explicitly, but it was worth mentioning that maybe for your particular problem convention would be enough!