Family Relations among plants

Using farmOS
,
1

Now that i’ve got all my Crop data migrated into v2 (uploaded via API) and am exploring what views are available in the UI, i can see that- of those Plant asset attributes by which one can filter & sort records- i.e.:
ID,Asset name,Crop/variety,Season,Flags,Parents,Group,Location,Status
… There is one one (Crop/variety) that i’ve not been using to best advantage, and two (Parents and Group) that i’ve not yet used at all, mainly because those attributes were not available in the v1.x “Import CSV” template (that being the way that all our farm records, maintained in spreadsheets, were previously being entered into farmOS).

So: to better understand what is now possible in v2, i’m looking at the Terms section of Data Model docs, which does help some, but could i think benefit from a practical example. Here’s one:

Let’s consider Chard -a species with several varieties that we grow (Ruby, Yellow, Rainbow)- which belongs to the Chenopod (i.e. Amaranth) family, along with Beetroots and Spinaches and probably some others (not to get any deeper into botanical nuances than necessary, to know how best to map such relations).

Until now, for simplicity of management, we’ve not been distinguishing between varieties of Chard in our crop record keeping; they are all identified simply as “Swiss chard” in our Plant asset naming convention (e.g. 2021-W19 Swiss chard SGH2-S was the crop transplanted in Week#19 of 2021 into SummerGreenHouse Bed#2, South section).

To enable a more nuanced view, i guess we might name each of the 3 Chard varieties as own Plant type, each of which could then have its own related Image file, according to those docs, along with its own “Days to transplant” (integer) and “Days to maturity” (integer), according to the docs. In fact those intervals would be the same across Chard varieties, so that’s not the best example… But in case of “Beetroot” varieties, e.g. Chioggia and Kogel, those intervals would differ across varieties, so that could be a useful distinction. To decide about how granular to go in our Plant type definitions, there’s a cost/ benefit analysis we’ll need to run on these different examples.

In any case: i need to better understand how best to apply these other terms, namely:

  • Companions: references some other term(s?) in the ‘Plant type’ vocabulary," i gather; as in “Companion cropping,” like baby lettuces planted under an overstory of chards? Or is this rather for “siblings” in a family of plants?
  • Crop family: defined as referring to some other term in the “Crop Family” vocabulary: would that that best be used here as a pointer from say “Ruby chard” variety to “Swiss Chard” family? but then…
  • Parent: Is this where we should declare Chenopod as the parent? Must that be declared at level of Swiss chard, and at level of all it’s 3 child varieties? or is this a multi-inheritance relation, where only the immediate parental relation need be declared, and subsequent generation(s) are included?
  • Group: I get no clue about this one from that “Terms” page (docs could benefit from a search widget, b/t/w)… But as it is available as a filter in the UI -like Parent, but unlike the previous two terms- Group looks to me like being even more useful in that sense. This being one of those attributes available as an “Action” in the UI: is this intended to be used for “tagging” records that might not be classifiable along any other dimension?

Sorry for the length of this post; feel free to parse out whatever bits are easily answerable, or else needing more clarification, as the case may be… But if anyone can shed more light about how family relations among plants might be best represented in farmOS, i should be most grateful.

2

Hi @walt - great questions… I’ll try to shed some light on what each of these relations is intended for.

First, just to give some historical context, when Plant assets were initially created (originally called Planting assets in v1) a long time ago, two taxonomies were created alongside them: “Crop/variety” (we changed this to “Plant type” in v2, although still refer to it as “Crop/variety” sometimes for consistency and out of habit) and “Crop family”. Crop/variety terms were given some extra fields, including “Companions”, “Days to maturity”, “Days to transplant”, etc - with the goal of eventually being able to use these in a crop planning application. This never ended up happening (although we took some steps towards it more recently with the v1 Crop Plan module), so the data in those fields don’t really get used anywhere. Nevertheless, we kept them during the move from v1 to v2, just in case anyone had any data in them.

One important point, because it seems to cause confusion often: the intention of the “Crop family” vocabulary was for scientific families, as you describe, like “Solanaceae”, “Amaranthaceae”, etc. Terms in the “Crop/variety” (“Plant type”) taxonomy can reference a single term in the “Crop family” taxonomy, to designate their botanical family. The thought was that this could eventually be used for rotation planning, to provide some kind of warning/planning tools to help avoid planting the same family in the same place each year. This is still a future possibility.

However, I think the distinction between these two taxonomies was confusing, and in practice some people have used “Crop family” for things like “Chard”, and then put the varieties in “Crop/variety”. That’s not how it was intended to be used, unfortunately. It doesn’t sound like you are doing that yourself, but I just wanted to flag that in case anyone else reads this later.

Companions : references some other term(s?) in the ‘Plant type’ vocabulary," i gather;

Correct - the idea here was to allow crop/variety terms to reference other crop/variety terms that might be good for companion planting. Again, this was thinking ahead to future planning tools that haven’t materialized yet. If I could go back, I might have left this field out until it was actually used/needed somewhere. Alas, it’s much harder to remove a field than add one. :slight_smile:

Crop family : defined as referring to some other term in the “Crop Family” vocabulary

(Hopefully my description above clarifies this one.)

Parent : Is this where we should declare Chenopod as the parent?

Nope! Parent actually refers to literal parent asset in this case. :slight_smile:

If, for example, you propagate your own seed/cuttings/etc you can reference the previous Plant asset that they came from as their Parent. I do this with my garlic when I transplant cloves I harvested from the previous year’s crop, so that I can trace back over the years.

Notably, this is the exact same Parent field that exists on Animal assets (for tracking lineage), and all other asset types! It is also used for defining hierarchy of “location” assets.

More info: Assets | farmOS

Group : I get no clue about this one from that “Terms” page

Group assets allow you to “group” assets together underneath a higher-level asset. The original reason they were added was to represent “Herds”, which were comprised of multiple individual Animal assets. So you can make all your Animals a “member” of a Group asset, and then “move” that Group asset from pasture to pasture.

Others have used Groups to organize things like Equipment or Plant assets. You may or may not find it useful. I would probably recommend against using it for plants unless there’s a very good reason to. There are still some limitations in the implementation - for example you have to go to the Group asset to see logs that are associated with the overall group - those are not (yet) visible on the member assets individually.

–

So, to summarize: Parent and Group are asset relationships, whereas Crop family and Companions are term relationships (and are not really used anywhere currently).

Hope that helps to clarify some of these things!

1 Like
3

Not to make things more confusing, but for our use case it made sense to add fields to the plant type taxonomy entries to model genus, species, and “general common name” since the crop family taxonomy seemed a bit too coarse.

image
image510×782 59.7 KB

3 Likes
4

Nice, @Symbioquine ! That (plus an accompanying image) is exactly the sort of profile i’d like to have for each of the Plant assets we are managing.

I don’t know if this template can be deployed on my instance at Farmier, and whether images can be hosted on that server, or rather should be hosted & linked from elsewhere; can you advise about this, @mstenta ?

5

Regarding the image, I think it can just be uploaded to the existing plant type term “photos” field. That would look something like this;

image
image534×1069 147 KB

2 Likes
6

farmOS already supports uploading images to Crop/variety (Plant type) terms (and so Farmier does too)!

As for the other fields, those are custom ones that @Symbioquine added to his instance - they are not part of farmOS core, and therefore are not available on Farmier. However, if it makes sense to bring them into farmOS core, then perhaps it’s worth opening a new topic/issue/PR to discuss that. They seem like logical next steps to me!

1 Like
7

Indeed: i’ve gone to Administration | Structure | Taxonomy | Plant types, selected “Swiss Chard”, clicked “edit” : “add new file” , upload… And it does indeed appear on that page. So far so good.

Thing is: if i’m going to do all that clicking & uploading for each of the 200-odd plant types i am managing, i’d like it to show up on each Plant asset page where that Plant type is invoked -or at least be just one link away. The way it is, Plant type of “Swiss Chard” appears on the Plant asset page as cold type, and the non-admin user has no way of viewing the Plant type page.

Am i missing something, or is this indeed not possible?

1 Like
8

It is possible, but not implemented yet.

At some point here I need to get back to my pull request that (among other things) changes those to links.

2 Likes
9

GMTA, @Symbioquine : from what i see on your PR (must give it due attention during my off-duty hours, but based on quick scan), it appears we are after essentially the same thing here.

Gotta run ATM, but suffice it to say for now: i’m very interested in this line of development, and will do what i can to support it.

1 Like
10

FYI @walt, my pull request has now been merged so it should be included in the next release.

2 Likes
11

w00t! Celebrations are in order :partying_face:

Irony is: i got email notification of this update, in the very same minute that i just finished a big data wrangling process (with some help from a little @paul121 script) to track down all the links related to each ‘Plant type’

Anyway: this will make life much easier going forward- and not only for us parties to this discussion, i expect -so thanks to you @Symbioquine and contributing devs for bringing more joy into this world.

3 Likes
12

I started using this Crop Family taxonomy in the way you described but it is a taxonomy that is a bit off the standard data model and maybe it doesn’t give enough functionality to compensate for the work of loading the data.

Maybe this taxonomy could be converted into a “Tree of life” and used as a standard in other modules. The Animal or mushroom type (or a future pest type) taxonomies could also be related to the “tree of life”. This new taxonomy could have an AGROVOC_ID field and should be possible to make a script for loading the Fao Agrovoc hierarchy with some degree of automation in a lot of languages, reducing the amount of work to start a new installation.

As an extra, adding the same kind of navigation in this “tree of life” that @Symbioquine recently added to the Plant Type (huge thanks, very helpfull) and make quick forms to help manage different plant/animal types that are related (aplly Bacillus Thuringiensis to all Brassicas, weigh all meat chickens regardless of breed, …)

What do you all think about??

1 Like
13

Great points @c4ndel4 - and that idea of a “unified taxonomy” came up before. We discussed it in this issue during the farmOS v2 development process: https://www.drupal.org/project/farm/issues/3191115

Ultimately that was closed as “won’t fix” - but only because we ran out of time to figure something out, and there were some valid reasons for keeping things as-is too. That doesn’t mean we aren’t open to exploring more options though!

One of the challenges is old data… anything we do needs to include a pathway from point A to point B for old data too.

14

@mstenta I swear that I’m not this person : https://www.drupal.org/project/farm/issues/3191115#comment-13960328

But that’s exactly what I was doing at this moment: a species taxonomy: https://github.com/c4ndel4/farmOS/tree/species

And that’s exactly what stopped me: I don’t want to loose all the actual data on crop_family, and I’m not sure on how to make the transition from one to other taxonomy. Having both fields at the same time in the plant_type is a total mess. And in my case I have the scientific name in the actual crop_family name but other people will have a common name in this field, so there is no homogeneous migration for all users. And if I do the migration from the existing taxonomy, why add the agrovoc_id or how I’m going to fill this field after the migration?

I will keep working in this idea, if I come up with any reasonable solution will report

1 Like
15

As I mentioned above, my strategy has been to add the genus/species as plain text fields in the instance I manage. I felt like having Drupal taxonomy terms for those was overkill since I didn’t really want to maintain any related data at the genus/species level directly in farmOS - but having the fields lets me grab external data where available.

That agrovoc_id sounds like a really interesting approach too @c4ndel4 ! I wonder if perhaps it would make more sense to pursue that as a farmOS contrib module (at least initially)? It seems like there are probably other taxonomic databases folks could integrate/link with instead - e.g. USDA Grin - so I wonder if it’s wise to integrate a specific one at a core farmOS level.

2 Likes
16

Yes, and also makes sense. But if you generalize from plant crops to things that grow under human supervision the species taxonomy evolves from itself. If you look at the current farmOS, speciation has already ocurred: we have an asset and a taxonomy for each kingdom (plants, animals, fungi, …), and if you include pests and/or natural predators the other kingdoms will appear. This species taxonomy would be a way to avoid adding that text fields in all the other taxonomies, and to provide an optional extra layer (of data, of work keeping this data, of functionality) for those interested in. If you only have plants, probably the plant_type taxonomy is enough

The idea for the agrovoc came from an old farmOS issue about integration with OpenFarm.cc. I’m so lazy that I would import data by any means. But, yes, you are right. It’s not a core thing, and it should be done as other module. This way even the migration should be easier.

2 Likes
17

I tried to make this changes, but I don’t know how to make the migration step.
I made some branches in my github, maybe some code is useful to somebody.

First, a taxonomy-images branch that adds image fields to the other asset-related taxonomies (animal and material types), to make them homogeneous with plant_type. This have no update problems, new fields with optional info.

Second, a taxonomy-species branch that adds a species taxonomy and adds a relation to plant, material and animal types. Also deletes crop_family. Works with a clean install, breaks otherwise.

Third, a 2.x-custom branch where I merged the two previous branches with origin/2.x. Also little change in the Dockerfile to build this custom image. This is what I plan to deploy on a raspberry pi as production server, and use the API to migrate from my actual 2.0.4-beta folder in a pen-drive.

Not the best solution, but if I spend the time trying to make that migration work I can’t spend the time using the tool. Sorry. If I manage to understand how to migrate from crop_family to species taxonomy I will update the branch and make a pull request, meanwhile it stays like this

2 Likes
18

In my opinion this first one is a great candidate for a pull request (to contribute the change back to core farmOS) right away if you’re interested/willing.

Second…

Third…

These other two probably don’t make sense for farmOS itself.

In that case, the recommended strategy is to make your changes in a slightly different way so that you’ll have a clearer upgrade path as the farmOS codebase itself continues to grow/improve.

For the taxonomy-species branch changes, the recommended strategy is to put your new fields/relations into a contrib module which lives in its own repository. That module probably wouldn’t delete the crop_family since that could break things easily, but it could hide the fields so they don’t get used inadvertently.

For the 2.x-custom branch changes, I would recommend creating a Dockerfile and/or composer.json file(s) in a “project” repository of your own and having those capture just the “custom” parts of your installation (rather than copying/modifying the core farmOS versions of those files).

2 Likes
19

Thank you for the advice @Symbioquine !
I started with all the changes in one branch but finally divided it to have something to contribute back. If the taxonomy-images branch is accepted as a PR, I’ll be happy.
I didn’t try to make the taxonomy-species branch as a contrib module because the core taxonomies will depend on this. Maybe it works, I should test… Also, hidding the crop_family without deleting it could be better for migration.
The third branch makes some sense if the second is a non standard core change. If it works as a module, I’ll delete it.

3 Likes
20

I’m not making much progress, but I’m still making progress.
I followed @Symbioquine advice and:
1 - I’ve submited the taxonomy-images branch as a Pull request (Add images to asset-related taxonomies by c4ndel4 · Pull Request #536 · farmOS/farmOS · GitHub) but @mstenta and @paul121 pointed out some issues to solve before being accepted. Most challenging for me is the update_hook, but I think now I’m in the way of solving this point.
2 - I created a custom module (GitHub - c4ndel4/farm_species: Species taxonomy in farmOS) with the taxonomy-species branch and it’s nearly working, including a hook_install that can be easily converted into a hook_update. The only problem are the configuration of the existing views:

Unable to install farmOS Species vocabulary, core.entity_form_display.taxonomy_term.plant_type.default, core.entity_view_display.taxonomy_term.plant_type.default already exist in active configuration

I implemented the hook_preinstall in order to delete this config before installing the module (the hook_install will create them again with the new configuration), but looks like this preinstall never runs. If I delete that configuration with drush, I can install the module and works fine.

So, I have a few questions on installing/uninstalling/updating:

  • In which hook should the configuration be deleted?
  • Are the configuration files going to be on the same place (sync directory) for a core update?
  • In case of uninstalling, well, maybe I should try this first before making questions… But are the original views yml going to be also in the sync directory?

Thanks in advance

2 Likes