In the last farmOS monthly call, we put some more thought into the #2469109: [META] Discussion: Asset Groups/Hierarchy discussion. The ability to create assets that represent groups of things is a frequently requested feature. Herds, flocks, etc will be much easier to manage as a whole when farmOS has an asset type specifically dedicated to representing groups.

The "Group" asset type (as I'm envisioning it currently) would be able to exist standalone, or it would also be able to "contain" other assets. So for example, if you don't track individual birds in your poultry flock, you could just have a single "Group" asset to represent them. Or, if you are dealing with cattle, you could create a "Group" to represent the herd, and you could ALSO create individual "Animal" asset records for each cow - and they would be "members" of the herd group.

One important point that was made on the monthly call is that we need to be able to track "movements" from one group to another. For example, if you have calves that have not been weaned, they may be in one group, but once they are weaned they will move to another group. This movement needs to be tracked as its own event. Currently, the "Animal group" taxonomy that we are using to group animals does not provide this level of tracking. When you change an animal's group, there is no tracking of the groups that it was in previously.

To solve this, we should treat "Group membership" in the same way that we treat "Location" of assets - membership should be assigned via logs, so that there is a specific date and time (and other meta information) about the membership assignment, and therefore membership can be traced back in time so all the changes can be seen.

The term "membership" was suggested by Stephen Woodbridge over the weekend:

I think the concept that you are missing when thinking about hierarchical assets is that you need to ask two different questions about an asset:

1. location
2. membership

So for example:

Where is "cow 1"? farm1.field27.paddock2
What is "cow 1" membership? herd3.group4

Move "cow 1" to "paddock3". - change location
Move "cow 1" to "herd2" - change of membership

While you can treat location as membership to an area, I think adding the location vs membership distinction will great clarify things.

It would probably mean you would want to kept a flag location=t|f to separate location from membership.

This relates to two other feature requests: #2363393: Make "Area" into a type of Farm Asset and #2540560: Asset hierarchy

In #2363393: Make "Area" into a type of Farm Asset, we are discussing converting "Areas" in farmOS from simple taxonomy terms to full-fledged asset type(s). This will greatly expand the level of record keeping available to areas, and will allow them to be treated like assets themselves, which makes a lot of sense. It will also allow areas to be archived by making them inactive (see also: #2630218: Define asset lifespan via logs - we will want this so that there is a log associated with it, or at the very least change the "active" boolean to a timestamp or date range in the db).

One big question that remains is: how does this affect the concept of "asset hierarchy" (see #2540560: Asset hierarchy). Areas are currently represented as taxonomy terms, which can be arranged hierarchically. How will that be handled when areas become assets? Will "membership" be used to build the hierarchy instead? And if so, does that mean we lose the ability to easily drag-and-drop hierarchies? Or does the drag-and-drop UI create a bunch of logs in the background the re-assign membership? Or is it better to say goodbye to the drag-and-drop and just recommend that membership be assigned when areas are created? How do we deal with "weight" (as in sort order of the hierarchy), or do we just make it always alphabetical (that could be a good thing)? Also, is "membership" too confusing of a term when you're talking about areas being inside other areas?

Then, with regard to specific implementation: do we use the existing "Movement" fields to represent both types of movements (location and membership)? Or do we need a separate set of fields for "location movements" vs "membership movements"? Or maybe just an additional field that lets you toggle whether or not you're moving the location vs the membership. That raises another import set of questions: can an asset have BOTH a membership AND a location? Or, does it only have one or the other? If it only has location, we can display the asset's location like we do currently. If it has a membership, we can display the membership, and also try to infer the location from the membership, by tracing up the assets until we find one with a location, and assume that any assets that are members of that asset have the same location? This is an important distinction. Are there cases where an asset needs to have a separate location from the asset it is a member of?

Hmm, and I just thought of another consideration: can assets be members of more than one group? Currently, with the "Animal groups" taxonomy, animals can be assigned to more than one group. So we either need to replicate that functionality, or keep "Animal groups" alongside this new concept of "membership". It would be a lot simpler if assets could only be members of one group, but that makes the migration more complicated, because there are existing installations that have assets in multiple groups. Perhaps we could rename "Animal groups" to "Asset category" and repurpose it as a general categorization feature (applicable to other asset types too perhaps).

Comments

m.stenta created an issue. See original summary.

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented

While all of this sounds overly complicated, it's really just an effort in reducing duplicate code and functionality. There are clear similarities between the way assets need to move between both areas and groups, so there is potential to share a lot of the same code. The challenge is mainly in how we present that so it makes sense, and also thinking through potential use-cases to make sure we don't limit ourselves. This is a really powerful way to organize assets, I believe - and will enable some really interesting features down the line - and some very granular record keeping.

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented
Issue summary: View changes

Hmm, and I just thought of another consideration: can assets be members of more than one group? Currently, with the "Animal groups" taxonomy, animals can be assigned to more than one group. So we either need to replicate that functionality, or keep "Animal groups" alongside this new concept of "membership". It would be a lot simpler if assets could only be members of one group, but that makes the migration more complicated, because there are existing installations that have assets in multiple groups. Perhaps we could rename "Animal groups" to "Asset category" and repurpose it as a general categorization feature (applicable to other asset types too perhaps).

Scratch that whole paragraph... I forgot that farmOS can already have movements to multiple areas. So it would already be possible to have a movement to multiple groups.

This does make "hierarchy" representation hard (or impossible), though. If all the code is shared, this would mean it would be possible to have a sub-area inside more than one parent area. That can't be represented hierarchically.

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented

It seems the most important question to answer first is:

Should it be possible for an asset to have BOTH a "membership" relationship to another asset AND a "location" relationship to another asset at the same time?

Choices:

  1. No, an asset with have EITHER a location OR a membership (and the location will be inferred from the asset that it is a member of)
  2. Yes, an asset needs to have a location that can be different from the asset it is a member of

An answer of "no" is a lot simpler than an answer of "yes", because it means that we are basically done already. We already have the ability to assign location via logs. If assets don't need to have a membership and a separate location simultaneously, then that means we can consider membership == location. So movements are simply used to represent that one asset is "in" another asset (representing both membership and/or location depending on the context).

An answer of "yes" means that we need to maintain both "location" and "membership" separately for each asset... and all the UI considerations along with that.

What are some arguments or use-cases for keeping them separate?

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented

Given the following example:

"Betty the cow" (an animal asset) is a member of "Bred heifers" (a group asset). "Bred heifers" is located in "Paddock 1" (an area asset (for the time being let's just assume that #2363393: Make "Area" into a type of Farm Asset is done and areas are already assets in farmOS)).

In this example, we can infer that "Betty the cow" is in "Paddock 1", because "Bred heifers" are in "Paddock 1". So "Betty the cow" doesn't really need her own "Location" - it can be inferred from the location of the group she's in.

That's pretty simple.

If "Betty the cow" gets sick, or is about to give birth, and she get's moved to the barn, she's no longer in the same place as the other cows in the "Bred heifers" group. But she's still technically a member of the "Bred heifer" group. While she's in the barn, though, she has a different location than the rest of her group.

I think this use-case illustrates a common example where an asset needs BOTH a membership AND a location, separate from one another.

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented

Discussed this a bit with Stephen today. Here is our chat transcript for reference:

Stephen:

I think an answer to some of the questions regarding both membership and location, that you have to consider general versus specific.
For example:
Ranch vs area vs building
and asset might have a specific location or not, if not then you look upward in the hierarchy and see if you can infer from that.

Me:

i like that
so for example:
you might have an asset that has membership, but doesn't have location... so you can look to the membership for location
is that what you mean?

Stephen:

yes

Me:

that brings up an important consideration: we will need the ability to REMOVE location from an asset

Stephen:

or it might have a location like paddock #1 or lat-log
yup or set it to unknown
which in effect removes it

Me:

ie: if you have an asset that is in a group (membership), but doesn't have a location... and then you give it a location separate from the membership (so it has both)... then you want to move it back to the group... you'll need to be able to say "this asset no longer has a specific location, just use the group again"
that shouldn't be too hard

Stephen:

then you can ask what was the last known location

BruceDawson’s picture

BruceDawson CreditAttribution: BruceDawson commented

Progress is being made! THe above discussion sounds pretty good and I like it!

Now, what about membership and location hierarchies?

For example: Water Trough#1 is a member of "Portable Water Troughs". And it has a location in Farm #2/NorthField/Paddock #3.

Of course, assets could be hierarchical too! For example: Equipment/Troughs/2inchHose, Equipment/Troughs/GardenHose, ...

The question is: Where are my water troughs?, Will filter work with these hierarchies?

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented

@BruceDawson Great question... I think hierarchies will be a natural result of the relationships created... but the name "hierarchy" might not be exactly right... because it will be possible for things to be in more than one group, and more than one location.

Currently, we're using Drupal Taxonomies to represent both "Areas" and "Animal groups" in farmOS. Assets can currently be located in more than one area at the same time (ie: a planting that is spread out over a few beds), and similarly Animal assets can be in more than one Animal Group. So we will be maintaining that in the new approach as well: when you are creating a log to assign membership or location, you'll be able to select more than one group or area.

I'm thinking that membership will ONLY be assignable to "Group" assets, and location will ONLY be assignable to "Area" assets (or maybe we'll have a flag on asset types that say "assets of this type are locations" - so you could have different asset types for Building, Field, Paddock, etc).

So in your examples:

For example: Water Trough#1 is a member of "Portable Water Troughs". And it has a location in Farm #2/NorthField/Paddock #3.

Of course, assets could be hierarchical too! For example: Equipment/Troughs/2inchHose, Equipment/Troughs/GardenHose, ...

... "Portable Water Troughs" would be a "Group" asset, and "Water Trough #1" would be a member of that group. The location of "Water Trough #1" would be "Paddock #3", which would itself be located in "NorthField".

So you could create chains of relationships that way too. And you could create groups within groups. Ie: you could also create an "Equipment" group if you wanted, and make the "Portable Water Troughs" group a member of it.

We will probably also need to prevent circular relationships (ie: Field A is in Field B, which is in Field C, which is in Field A). That won't usually happen in practice, but nothing would prevent you from doing something like that - which may cause issues - so we'll have to add some sort of logic to prevent it I think.

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented
Title: [META] Discussion: Asset membership, hierarchies, etc » [META] Discussion: Asset membership vs location

Renaming this because it was largely about the defining the relationship and differences between the concept of asset "membership" and "location".

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented
Related issues: +#2915217: Group asset type with membership tracking

I started a new issue that I'll use to outline the specific implementation details for the "Group" asset type, based on this discussion. We can continue to use this issue for general discussion around the topic. I'll incorporate/organize final decisions over there...

#2915217: Group asset type with membership tracking

m.stenta’s picture

m.stenta
he/him
Primary language English
CreditAttribution: m.stenta commented
Status: Active » Fixed

Closing this as because we have both location and group membership, and will continue to in farmOS 2.x.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.