FoodOn ↔ FoodEx2 / HESTIA crosswalk + food footprints

Read this before you compute — scope & honesty

The crosswalk is entirely close_match — semantic alignment (lexical + Jaccard-gated token overlap), NOT curated 1:1 owl:sameAs identity. Treat each edge as a strong candidate alignment, not a proof of equivalence. Confidence runs 0.725–0.90 (median 0.90).

Footprint tiers — trust only the defensible rows:

• foodex2_sediment_exact (145) and foodex2_name (1,076) are real food-LCA matches — the FoodOn item resolves to a FoodEx2 term that the EDB → BAFU sediment mapping carries with a genuine inventory. Use these.
• proxy (2,066) rows exist for traceability only. The gwp100 there is a category-level stand-in — DO NOT use its magnitude as a product footprint. It tells you which bucket a FoodOn item falls in, not how much.

If FCM / CHFDM has curated owl:sameAs FoodOn ↔ FoodEx2 links, we would adopt them as ground truth and lift the affected edges from close_match to exact_match — and promote the corresponding footprints out of the proxy tier. That is the intended next iteration of this bridge.

Nutrients — what they are, and what they are not

Why this layer exists. A nutrient-density or calorie-allocation calculation needs an impact and a nutrient content for the same food. Both now hang off the same FoodOn item, so no downstream name-matching is required: 641 items carry a GWP100 and a per-100 g profile on one row.

Where the numbers come from. National food-composition databases (FAO/INFOODS tagnames) via lci-nutrients, joined on FoodEx2 as the pivot — the same pivot the footprints layer uses. They are not derived from any LCA and carry no impact; the gwp100 and the nutrients on a row are independent facts about the same food.

A nutrient profile is at best as good as the identity edge that reached it. The crosswalk is close_match, not curated owl:sameAs, so every row repeats its crosswalk_confidence — read it together with identity_verified (rare, but ~100% precise when false) and match_confidence (advisory only: ~56% precision against a 41% base rate).

27 candidates were refused — they ship with their evidence and no numbers, because a wrong nutrient value published next to a GWP value is worse than an absent one. Refused when the canonical is_same_food check says it is a different food; when the matched label is a bare state (“raw”, “fresh”) carrying no food identity; or when the item names a de-watered form but the matched row holds fresh-food water content. That last rule matters more than it sounds: drying removes water and rescales every other per-100 g value, so a dried herb given its fresh row is a wrong quantity, not a near miss.

FoodEx2 is the pivot; HESTIA is a fallback. 574 FoodOn items carry no FoodEx2 edge at all and were previously skipped outright. Where their HESTIA term is keyed by the nutrient layer they are now resolved through it — 19 items (rabbit, coconut milk, lard, gelatin …), each put through exactly the same guards. The target_namespace column says which vocabulary answered, so the two paths are never conflated.

Processed foods are matched on FoodEx2 facets, not on names. FoodEx2 keys fresh Tomatoes (A0DMX) and Sun-dried tomatoes (A00ZG) as separate terms that share one source commodity (facet F27) and differ only in the process (facet F28). So when a dried or pressed item resolves to the fresh term, we follow that link to the processed sibling instead of discarding the row — 37 items are matched this way, each landing where the physics says it should: olive oil 899 kcal/0 g water, egg powder 537/4.1, potato flakes 354/7.1, against fresh values of 75/79.9 for the potato. The same facets work in reverse: two terms whose F27 differs are a different food however close the names read, which is how “boneless veal” matched to “Veal liver” was caught.

Values are a multi-country weighted-median blend. National tables genuinely differ in energy conversion factors and recipe-calculation procedure, so the spread in nutrient_uncertainty is irreducible — it is reported, not averaged away. Per-source licences differ; see lci-nutrients/DATA_LICENSES.md.

Related open inventories

This bridge is the identity + footprint sibling of Eaternity's open, ecoinvent-free LCI libraries:

• Processing LCI library (the gold-standard self-contained package, also built for FCM): lci-food-processing-00a0cc.gitlab.io · repo gitlab.com/eos-lci/lci-food-processing
• BAFU/UVEK background catalogue: gitlab.com/eos-lci/lci-bafu-catalog
• Food-loss tributary: gitlab.com/eos-lci/lci-food-loss

Inventory annotation only — no characterised impacts

These recipes are inventory annotation only: ingredient + processing + transport + emission line items with their amounts and units. No line_item carries a characterised impact — no GWP100, CO₂eq, EF or UBP score field anywhere in the structure. They tell you what a food item is made of and how, not how much impact it has.

One honest caveat: a recipe's derivation text is a verbatim copy of the source inventory's own method note, and some of those notes mention a GWP figure for context (e.g. “GWP metadata ≈ 0.42 kg CO₂eq/kg”). That is source-authored prose passed through unchanged — not a recipe-level impact claim, and it is method-specific (mind the GTP-vs-GWP distinction). Treat the recipe as inventory; for defensible GWP100 magnitudes use the footprints layer above.