Reconcile usage of "Impact" class with taxonomic enum

[clevinson]

In the schema we currently both have a linkml class for "Impact" as well as an enum explicitly managed in the taxonomy. Similarly, we should look at this for other taxonomic enums (ActivityType and EnvironmentType), as both are used in credit class & project slots, but we may want to evaluate transitioning them to LinkML's semantic enumerations.

The PR #11 from @paul121 already moved us in this direction, but we may want to evaluate going further by having values for fields be ontology terms with constraints like "subClassOf"

[paul121]

Yea, I think this makes sense. It just depends how exactly we want to use the Impact taxonomy, which was never very clear to me 😄 Also here is the Impact class now included on live docs!

My understanding is that currently there is a list of Impact terms + icons defined (out of band) in the Sanity CMS and the credit class + project metadata docs used some identifier associated with each term. The simple way to upgrade this would be to start managing the taxonomy terms here in this repo, also giving them more clear identifiers & documentation in the process.

For example, the primaryImpact from the C06 metadata could essentially stay the same, just use an updated an identifier for what "Soil Organic Carbon" most closely maps to in the new taxonomy?

regen:primaryImpact: {
    @id: "regen:SoilOrganicCarbon"
    schema:name: "Soil Organic Carbon"
}

---

But going forward, it seems that with this Impact class we're attempting to consolidate the existing concepts of impacts, primaryImpact and cobenefits all to reference an instance of the "Impact" class, which I see can now also optionally reference a list of SDGs

Is the intention for credit class + projects to remain fairly constrained to a single taxonomy of Impact types and have only the Impact Type term names listed on the website?

OR

Is the intention to allow more custom "impact names" to be listed and have them associated with related Impact types (singular/plural?) and SDGs? This would allow more flexible and specific text on project pages but still benefit from structured categorization (maybe sanity can provide generic icons for each impact type?) IIRC this type of thing had been asked for by some project developers?

As an example, "Increased Soil Organic Carbon" could then be associated with multiple impacts:

• Improved Soil Health
• Improved Water Holding Capacity
• Reduced Fertilizer Amendments
• Reduced Soil Erosion
• and SDG 13 Climate Action:

in pseudo-code it might look like:

"hasPrimaryImpact": {
  "id": "???"
  "name": "Soil Organic Carbon",
  "supportsSDG": [
     "SDG_13"
  ],
  "subClassOf": [
    "rft:ImprovedSoilHealth",
    "rft:ImprovedWaterHoldingCapacity",
    "rft:ReducedFertilizerAmendments",
    "rft:ReducedSoilErosion"
  ]
}

In this version I'm not sure what the id/identifier would really be used for

[clevinson]

I generally like this idea (the second one you illustrate). There's another challenge with us using the rft:... terms as actual identifier for the a given hasPrimaryImpact or hasCoBenefits value, in that if the rft:ImprovedSoilHealth term is used as the id and it is serialized as the RDF identifier, then you have a situation where multiple names and multiple supportsSDG values would get cross pollinated if they were used differently in diff projects / credit classes.

See this example:

CreditClass1:
  hasPrimaryImpact:
    - id: rft:ImprovedSoilHealth
      supportsSDG:
        - SDG_13
      name: "My improved soil health"

CreditClass2:
  hasPrimaryImpact:
    - id: rft:ImprovedSoilHealth
      supportsSDG:
        - SDG_11
      name: "My special improvement of soil heath"

When the above data gets imported into a triplestore / knowledge graph, it would result in a node rft:ImprovedSoilHealth that has multiple "name"s and also multiple supportsSDG values (the union of all the different SDGs from each credit class).

My inclination is that we should probably have both more granular taxonomy terms, and an easy way for team members to contribute to this, while also allowing individual credit classes & projects to have specific impact information that is unique to that credit class and project.

If we were to go off of your 2nd pseudo-code example @paul121, then we actually don't need an id term at all, which would mean each hasPrimaryImpact value would be a blank node, unique to each credit class. The blank node would have a name, supportsSDG values, and subClassOf relationships to each of the rft terms.

The one change I'd suggest to your example, is that I think a different field besides subClassOf would be more appropriate. the taxonomy's ImpactType terms are like abstract "types" of impact, and I think it's better to model these hasPrimaryImpact or hasCoBenefit as actual instances of these impacts, which also would allow us eventually add further quantitative or qualitative info about these impacts to describe the specifics of the impact in the context of this project.

[S4mmyb]

Per @paul121 and my conversaion on 4/17/2025, we were discussing how currently co-benenfits map to impact cards in the regen UI which limits people's ability to list co-benefits for credit-bearing project in the additional info section. We want to distinguish co-benefits as separate from impacts, we think, but this affects rendering. Also we don't really know how people perceive/use impacts vs co-benefits more broadly so we should do research into that, as well as ways to support UI rendering without hard-coding into the metadata