METPO metals cohort: MetalElement + RareEarthElement + MetalRelevance

proposals/metpo_communitymech_metals_v1/metpo_proposal_classes_robot.tsv

@@ -0,0 +1,10 @@
+proposed_id	label	definition	definition_source	parent	synonyms	xrefs	subset	priority	observations	traits_addressed
+ID	LABEL	A IAO:0000115	>A IAO:0000119	SC %	A oboInOwl:hasExactSynonym SPLIT=|	A oboInOwl:hasDbXref SPLIT=|	A oboInOwl:inSubset			
+METPO:1008000	community-relevant metal context	A top-level framing class for metal- and rare-earth-element interactions of a microbial community, capturing which metals are present, which are rare-earth elements, and how relevant metals are to the community's function.	CommunityMech:communitymech.yaml#MicrobialCommunity.metals_present	METPO:1007100	community metal context|community metals framing		metpo_communitymech_metals_2026_05	HIGH		top-level domain class for the metals cohort
+METPO:1008001	community-relevant metal element	A METPO grouping class for metal elements relevant to microbial community function: metals (atoms or cations) that community members are present in, oxidize, reduce, sequester, leach, or otherwise metabolize.	CommunityMech:communitymech.yaml#MetalElementEnum	METPO:1008000	community-relevant metal|metal element category|community metal element		metpo_communitymech_metals_2026_05	HIGH	Per-element leaves are CHEBI IRIs (recorded upstream in metpo_existing_aliases.tsv) rather than fresh METPO classes; this parent provides the METPO-side grouping anchor. See proposal.md hierarchy decisions.	enum-parent for MetalElementEnum; CHEBI IRIs are the per-element leaves (see proposal.md)
+METPO:1008002	community-relevant rare earth element	A METPO grouping class for rare-earth elements (lanthanides plus Y, Sc) relevant to microbial community function: REE atoms or cations that community members sequester, bioleach, or otherwise process.	CommunityMech:communitymech.yaml#RareEarthElementEnum	METPO:1008000	community-relevant REE|rare earth element category|community REE element		metpo_communitymech_metals_2026_05	HIGH	Per-element leaves are CHEBI IRIs (recorded upstream in metpo_existing_aliases.tsv) rather than fresh METPO classes; this parent provides the METPO-side grouping anchor. See proposal.md hierarchy decisions.	enum-parent for RareEarthElementEnum; CHEBI IRIs are the per-element leaves (see proposal.md)
+METPO:1008003	community metal relevance level	A grouping class for the qualitative severity with which metal or rare-earth-element cycling characterizes a microbial community, ranging from primary defining function through significant participation to incidental or non-applicable.	CommunityMech:communitymech.yaml#MetalRelevanceEnum	METPO:1008000	metal relevance category|metal/REE relevance level		metpo_communitymech_metals_2026_05	HIGH		enum-parent for MetalRelevanceEnum
+METPO:1008010	primary metal relevance	A metal-relevance level indicating that metal or rare-earth-element extraction or cycling is a primary function of the microbial community (e.g., biomining communities, acid mine drainage chemolithoautotrophs).	CommunityMech:communitymech.yaml#MetalRelevanceEnum.PRIMARY	METPO:1008003	primary metal-cycling relevance		metpo_communitymech_metals_2026_05	HIGH		MetalRelevanceEnum.PRIMARY
+METPO:1008011	significant metal relevance	A metal-relevance level indicating that the microbial community participates significantly in metal or rare-earth-element metabolism but it is not the community's primary function.	CommunityMech:communitymech.yaml#MetalRelevanceEnum.SIGNIFICANT	METPO:1008003	significant metal-cycling participation		metpo_communitymech_metals_2026_05	HIGH		MetalRelevanceEnum.SIGNIFICANT
+METPO:1008012	incidental metal relevance	A metal-relevance level indicating an incidental metal or rare-earth-element interaction in the microbial community (e.g., trace metals are present but not actively cycled).	CommunityMech:communitymech.yaml#MetalRelevanceEnum.INCIDENTAL	METPO:1008003	incidental metal interaction		metpo_communitymech_metals_2026_05	MEDIUM		MetalRelevanceEnum.INCIDENTAL
+METPO:1008013	not-applicable metal relevance	A metal-relevance level indicating that the microbial community has no significant metal or rare-earth-element relevance (default for communities focused on non-metal substrates).	CommunityMech:communitymech.yaml#MetalRelevanceEnum.NOT_APPLICABLE	METPO:1008003	no metal relevance		metpo_communitymech_metals_2026_05	MEDIUM		MetalRelevanceEnum.NOT_APPLICABLE

proposals/metpo_communitymech_metals_v1/metpo_proposal_properties_robot.tsv

@@ -0,0 +1,5 @@
+proposed_id	label	definition	definition_source	type	domain	range	xrefs	subset	priority	traits_addressed	observations
+ID	LABEL	A IAO:0000115	>A IAO:0000119	TYPE	DOMAIN	RANGE	A oboInOwl:hasDbXref SPLIT=|	A oboInOwl:inSubset			
+METPO:2008000	has metal element present	A relation between a microbial community and a CHEBI chemical entity that represents a metal element (atom or cation) present in or processed by the community.	CommunityMech:communitymech.yaml#MicrobialCommunity.metals_present	owl:ObjectProperty	METPO:1007100	CHEBI:24431		metpo_communitymech_metals_2026_05	HIGH	metal-element membership of community	0..* cardinality. Range is the broad CHEBI:24431 (chemical entity) because the schema-side MetalElementEnum mixes atom-form (e.g., CHEBI:27214 uranium atom, CHEBI:29287 gold atom) and cation-form (e.g., CHEBI:29033 iron(2+) cation) values; a narrower CHEBI parent would reject some valid existing data.
+METPO:2008001	has rare earth element present	A relation between a microbial community and a CHEBI chemical entity that represents a rare-earth element (atom or cation) present in or processed by the community.	CommunityMech:communitymech.yaml#MicrobialCommunity.rare_earth_elements_present	owl:ObjectProperty	METPO:1007100	CHEBI:24431		metpo_communitymech_metals_2026_05	HIGH	rare-earth-element membership of community	0..* cardinality. Range is the broad CHEBI:24431 (chemical entity) for consistency with the metal-element predicate; the per-REE leaves in RareEarthElementEnum are all CHEBI cation-form entities (e.g., CHEBI:32359 lanthanum(3+) cation).
+METPO:2008002	has metal relevance	A relation between a microbial community and a metal-relevance-level class indicating how central metal or rare-earth-element cycling is to the community (primary defining function vs significant participant vs incidental vs not applicable).	CommunityMech:communitymech.yaml#MicrobialCommunity.metal_relevance	owl:ObjectProperty	METPO:1007100	METPO:1008003		metpo_communitymech_metals_2026_05	HIGH	metal-relevance assignment	0..1 cardinality

proposals/metpo_communitymech_metals_v1/proposal.md

@@ -0,0 +1,192 @@
+# METPO ROBOT Template Proposal — CommunityMech Metals Cohort (v1, 2026-05)
+
+## Context
+
+CommunityMech's metal-related schema slots
+(`MicrobialCommunity.metals_present`, `.rare_earth_elements_present`,
+`.metal_relevance`) are populated across the biomining, AMD,
+metal-reduction, and metal-tailings community YAMLs in
+`kb/communities/`. Lifting these into METPO lets KG-Microbe consumers
+filter communities by metal/REE membership and by how central metal
+cycling is to community function.
+
+A scoping choice deserves emphasis at the top: **the per-element enum
+values in `MetalElementEnum` and `RareEarthElementEnum` already carry
+`meaning: CHEBI:xxxxx` cross-references in the schema, so this proposal
+does NOT mint per-element METPO classes**. Doing so would duplicate
+CHEBI's `Iron(2+) cation` (CHEBI:29033) etc. as parallel
+`METPO:iron`-style identifiers, contradicting the upstream kg-microbe
+SKILL.md rule that "if the lifted concept already exists in METPO
+under a different label, use the existing IRI; record the alias in
+mappings/metpo_existing_aliases.tsv". This proposal instead lifts
+only:
+
+- The two **grouping parents** (`community-relevant metal element`,
+  `community-relevant rare earth element`) that anchor the METPO side
+  of the alias mapping.
+- The 4 **MetalRelevanceEnum** leaves (PRIMARY / SIGNIFICANT /
+  INCIDENTAL / NOT_APPLICABLE), which have no CHEBI equivalent — they
+  are qualitative severity categories, not chemical entities.
+- Three **predicates** wiring all of the above to
+  `MicrobialCommunity`.
+
+The per-element CHEBI IRIs flow upstream into
+`kg-microbe/mappings/metpo_existing_aliases.tsv` when this proposal is
+copied to the kg-microbe pipeline.
+
+## Scope
+
+| CommunityMech enum / slot | METPO parent | Leaves |
+| --- | --- | --- |
+| `MetalElementEnum` (17 values) | `community-relevant metal element` (`METPO:1008001`) | none in METPO — reuse CHEBI IRIs |
+| `RareEarthElementEnum` (16 values) | `community-relevant rare earth element` (`METPO:1008002`) | none in METPO — reuse CHEBI IRIs |
+| `MetalRelevanceEnum` (4 values) | `community metal relevance level` (`METPO:1008003`) | 4 leaves (`METPO:1008010`–`METPO:1008013`) |
+
+Plus one new top-level domain class:
+
+| ID | Label | Lifts |
+| --- | --- | --- |
+| `METPO:1008000` | community-relevant metal context | the metal-context framing of `MicrobialCommunity` (parent `METPO:1007100`) |
+
+Total class rows: **8** (1 top-level + 3 enum-parents + 4
+MetalRelevance leaves).
+
+## Hierarchy decisions
+
+### Why no per-element METPO classes
+
+The kg-microbe upstream SKILL.md states:
+
+> If the lifted concept already exists in METPO under a different
+> label, use the existing IRI; record the alias in
+> `mappings/metpo_existing_aliases.tsv`.
+
+Each `MetalElementEnum` value (e.g., `IRON: meaning: CHEBI:29033`)
+already exists in CHEBI as a chemical entity. Minting a new METPO IRI
+per metal would:
+
+1. Force downstream consumers to choose between two competing IRIs
+   for the same chemical.
+2. Multiply maintenance burden when CHEBI updates labels or adds
+   synonyms.
+3. Leak the schema-internal enum design into the public ontology
+   without semantic justification (an enum is a serialization
+   convenience, not a new ontological category).
+
+The same reasoning applies to `RareEarthElementEnum`. Both
+grouping-parent METPO classes (`METPO:1008001`, `METPO:1008002`) are
+included so the alias-mapping table has a METPO-side anchor; the
+actual per-element edges are CHEBI IRIs.
+
+### Why mint METPO leaves for MetalRelevanceEnum
+
+`MetalRelevanceEnum`'s four values (PRIMARY / SIGNIFICANT /
+INCIDENTAL / NOT_APPLICABLE) are **qualitative severity categories
+specific to CommunityMech**. They do not exist in CHEBI, PATO, GO,
+or other ontologies we cross-reference, and they describe the
+community's relationship to metal cycling rather than a chemical
+entity. Minting fresh METPO leaves under
+`community metal relevance level` is the right call.
+
+### Flat hierarchy under each enum-parent
+
+None of the three enums has internal `is_a` structure in the schema
+(no comments indicating one value is a specialization of another).
+The 4 MetalRelevance leaves are mutually exclusive severity bins.
+Kept flat.
+
+## Predicate proposals
+
+3 object properties, all in the `METPO:2008NNN` placeholder range.
+All have `MicrobialCommunity` (`METPO:1007100`) as domain.
+
+| Property | Range | Source slot |
+| --- | --- | --- |
+| `has metal element present` (`METPO:2008000`) | `CHEBI:24431` (chemical entity) | `MicrobialCommunity.metals_present` |
+| `has rare earth element present` (`METPO:2008001`) | `CHEBI:24431` (chemical entity) | `MicrobialCommunity.rare_earth_elements_present` |
+| `has metal relevance` (`METPO:2008002`) | `METPO:1008003` (metal relevance level) | `MicrobialCommunity.metal_relevance` |
+
+The first two predicates use the broad `CHEBI:24431` (chemical
+entity) as range because the schema-side enums mix atom-form and
+cation-form CHEBI values: `MetalElementEnum` includes atom-form
+entries (`URANIUM` → `CHEBI:27214` uranium atom, `GOLD` → `CHEBI:29287`
+gold atom, `CHROMIUM` → `CHEBI:28073`, `TITANIUM` → `CHEBI:33341`,
+`PALLADIUM` → `CHEBI:33373`) alongside cation-form entries
+(`IRON` → `CHEBI:29033` iron(2+) cation, etc.); narrower CHEBI parents
+like `CHEBI:33521` (metal cation) or `CHEBI:33709` (metal atom) would
+reject some valid existing data. The intent is to keep per-element
+edges as CHEBI IRIs (no METPO per-element leaves minted); the range
+type-hint is deliberately loose to accommodate the heterogeneous
+schema values.
+
+## ID space and subset
+
+- **Classes**: `METPO:1008000`–`METPO:1008013` (placeholder, in a
+  fresh `1008NNN` block to keep the metals cohort cleanly separated
+  from the `metpo_communitymech_v1` cohort which uses `1007NNN`)
+- **Properties**: `METPO:2008000`–`METPO:2008002` (placeholder)
+- **Subset tag** on every row: `metpo_communitymech_metals_2026_05`
+- **Definition source**: `CommunityMech:communitymech.yaml#<EnumName>.<VALUE>`
+  for enum lifts; `CommunityMech:communitymech.yaml#MicrobialCommunity.<slot>`
+  for the top-level domain class.
+- **Priority**: `HIGH` on all enum-parent and PRIMARY/SIGNIFICANT
+  rows; `MEDIUM` on `INCIDENTAL` and `NOT_APPLICABLE` leaves (these
+  are catch-all categories).
+
+## Files
+
+| File | Rows | Notes |
+| --- | --- | --- |
+| `metpo_proposal_classes_robot.tsv` | 1 column header + 1 ROBOT header + 8 class rows = 10 lines | mirror of `kg-microbe/mappings/metpo_proposal_classes_robot.tsv` schema |
+| `metpo_proposal_properties_robot.tsv` | 1 column header + 1 ROBOT header + 3 property rows = 5 lines | mirror of `kg-microbe/mappings/metpo_proposal_properties_robot.tsv` schema |
+| `proposal.md` | (this file) | narrative for reviewer |
+
+## Verification
+
+```bash
+# Column-count sanity
+awk -F'\t' 'NF != 11 {print NR": "NF" cols"}' proposals/metpo_communitymech_metals_v1/metpo_proposal_classes_robot.tsv
+awk -F'\t' 'NF != 12 {print NR": "NF" cols"}' proposals/metpo_communitymech_metals_v1/metpo_proposal_properties_robot.tsv
+
+# Parse with ROBOT if available
+robot template --template proposals/metpo_communitymech_metals_v1/metpo_proposal_classes_robot.tsv --output /tmp/metals_classes.owl
+robot template --template proposals/metpo_communitymech_metals_v1/metpo_proposal_properties_robot.tsv --output /tmp/metals_properties.owl
+```
+
+Round-trip check: pick two metal-relevant community YAMLs that
+exercise the enums:
+- `kb/communities/Alaska_Tundra_Permafrost_Iron_Redox_Community.yaml`
+  (Fe-redox, `metal_relevance: SIGNIFICANT`, single-metal IRON)
+- `kb/communities/Bayan_Obo_REE_Tailings_Consortium.yaml`
+  (rare-earth elements + `metal_relevance: PRIMARY`)
+
+Confirm that every `MetalRelevanceEnum` value cited in these YAMLs
+maps to a leaf class in this proposal, and that each
+`MetalElementEnum` / `RareEarthElementEnum` value resolves to its
+CHEBI IRI (which sits under the METPO grouping parent via the
+alias-table mapping).
+
+## Upstream path
+
+When this cohort is approved here:
+
+1. Copy both TSVs to `kg-microbe/mappings/`.
+2. Generate an `metpo_existing_aliases.tsv` entry for every
+   `MetalElementEnum.<X>` and `RareEarthElementEnum.<X>` value,
+   mapping the schema-side enum name to the existing CHEBI IRI from
+   the schema's `meaning:` annotation. Format follows the existing
+   `kg-microbe/mappings/metpo_existing_aliases.tsv` rows.
+3. METPO maintainers mint real IDs to replace the `METPO:1008NNN`
+   placeholders for the 8 minted classes; CHEBI IRIs need no minting.
+4. The CommunityMech `datamodel/communitymech.py` regeneration can
+   later emit either the METPO IRI (for grouping queries) or the
+   CHEBI IRI (for chemical-entity queries) when serializing
+   `metals_present` and `rare_earth_elements_present` values.
+
+## Change log
+
+- **v1, 2026-05**: Initial proposal for the metals cohort. 8 class
+  rows (1 top-level + 3 enum-parents + 4 MetalRelevance leaves) +
+  3 property rows. Per-element CHEBI IRIs deferred to
+  `metpo_existing_aliases.tsv` upstream rather than minting fresh
+  METPO leaves.