Merge pull request #14 from isrl-research/add/core-extension-log

Add/core extension log for metadata core/extension + slightly revise tone for other systems log

Author: lalithaar

logs/2026-03-log-t2-how_international_system_regulate_ingredient_names.qmd

@@ -17,15 +17,13 @@ Many countries maintain official "Ingredient Dictionaries" or "Common Name Lists
 
 While National Nutrition Databases (like the USDA's FoodData Central) focus on what's inside the food (vitamins, minerals), Regulatory Identity Lists — often part of a country's food law — define what the ingredient must be called.
 
-Here are the most prominent official systems used to make ingredient identity consistent.
-
 ---
 
 ## Canada: The "Common Names" List
 
 Canada is perhaps the most explicit. The Canadian Food Inspection Agency (CFIA) maintains a document called "Common Names for Ingredients and Components." It acts as a mandatory thesaurus for food labels.
 
-**The goal:** To prevent vague or deceptive labeling.
+**The goal:** To ensure ingredient groupings and generic names are applied consistently.
 
 **Example:** If a manufacturer uses a mix of butter, cream, and skim milk, they are legally allowed — and sometimes required — to group them under the official common name "Milk Ingredients" to simplify the label for the consumer.
 
@@ -67,10 +65,10 @@ FSANZ maintains Schedules within their Food Standards Code that act as the sourc
 
 ## Why these lists exist
 
-Without official lists, ingredient identity would be inconsistent. These databases address three structural problems:
+Without official lists, ingredient identity would be a mess. These databases address three structural problems:
 
 - **Allergen transparency:** Ensuring that "Casein" is clearly identified as a milk derivative.
-- **Fraud prevention:** Preventing a manufacturer from calling "High Fructose Corn Syrup" simply "Natural Sweetener."
+- **Name standardisation:** Establishing which name a substance must carry — so "High Fructose Corn Syrup," for example, appears under its regulated name and not under an informal descriptor.
 - **Data interoperability:** Allowing systems to understand that "Zucker," "Sucre," and "Sugar" all refer to the same substance.
 
 ---

logs/2026-04-log-t2-core-and-extension-a-design-principle-for-ifid-taxonomy.qmd

@@ -0,0 +1,105 @@
+---
+title: "Core and Extension: A Design Principle for IFID Taxonomy"
+description: "IFID taxonomy distinguishes between a fixed core and an open extension surface. The core holds what every use requires; the extension surface lets downstream users attach their own metadata without altering it."
+date: 2026-04-05
+author:
+  - name: Lalitha A R
+    affiliation: iSRL
+    orcid: 0009-0001-7466-3531
+    email: lalithaar.research@gmail.com
+    corresponding: true
+categories: [design-principles, taxonomy, ifid]
+tags: [core-extension, ifid, taxonomy-design]
+status: draft
+license: "CC BY 4.0"
+citation: true
+---
+
+## The principle
+
+IFID taxonomy has two layers: a fixed core and an open extension surface.
+
+The core holds what every use of the taxonomy requires — the minimum shared
+vocabulary that makes ingredient identity consistent across labels, datasets,
+and analyses. The extension surface lets anyone attach additional metadata
+suited to their specific question, without altering the core.
+
+## What this looks like in practice
+
+A diabetes foundation needs to know which ingredients contribute free sugars.
+A hospital canteen needs to flag high-sodium items. A sports nutrition brand
+needs to track protein-to-carbohydrate ratios. None of these needs are in
+scope for IFID, but all of them depend on stable ingredient identity before
+they can attach their own metadata.
+
+The core gives them that stable identity. They bring their own layer on top.
+
+## What belongs in the core
+
+The core covers what is legally required or necessary for ingredient identity
+to hold at all:
+
+- Ingredient identity (canonical name, variant strings, source)
+- Legal declarations required under FSSAI (allergen status, veg/non-veg
+  marking, source qualifiers where mandated)
+- Classification fields that the taxonomy uses to distinguish one ingredient
+  from another
+
+What specific values, tags, or categories the lab recognises within each of
+these fields — for example, which tags are valid under veg/non-veg declarations
+— is a separate question. That will be documented as each category is analysed.
+
+## What belongs in extensions
+
+Extensions are metadata that a specific use case adds to the core. They are not
+part of IFID and do not need to be. They only need to be compatible with it —
+attachable to a stable ingredient identity without redefining what that identity is.
+
+Examples of extension metadata a downstream user might add:
+
+- Glycaemic index values (diabetes nutrition)
+- Sodium content per standard serving (clinical dietary programmes)
+- Fermentation pathway (food technology research)
+- Carbon intensity estimates (sustainability reporting)
+
+IFID does not maintain these. The design only requires that the core is stable
+enough for others to attach to it.
+
+## Why the core must be bounded
+
+If the core tries to account for every possible use, it becomes unusable for
+any of them. A taxonomy that carries clinical, environmental, religious, and
+sports-nutrition metadata simultaneously has no coherent identity.
+
+The boundary also protects downstream users. If the extension surface is open
+and documented, a research group can add their layer without waiting for IFID
+to expand. The taxonomy does not become their bottleneck.
+
+## What this log does not settle
+
+Which fields belong in the core and which are extensions is not determined here.
+That requires working through each category — veg/non-veg declarations, allergen
+status, source qualifiers — and establishing what the legal minimum requires and
+what goes beyond it. Those analyses will be recorded as separate logs.
+
+This log records only the design principle: the taxonomy distinguishes between
+core fields and extension fields, and the extension surface is open by design.
+
+::: {.column-margin}
+**A parallel from web development**
+
+Web frameworks separate built-in features from optional add-ons using the same
+pattern. React ships with component rendering and state management; everything
+else — routing, form handling, data fetching — is a plugin you bring in.
+Django's ORM and URL routing are core; authentication backends, payment
+integrations, and admin themes are installed as apps. WordPress's post/page/taxonomy
+model is core; anything else is a plugin.
+
+The shared logic: the framework defines a stable object (a component, a model,
+a post) and leaves the surface open for extension. Downstream developers attach
+to that surface without modifying the object itself.
+
+IFID follows the same pattern. The ingredient record is the stable object.
+The extension surface is open. Third parties attach their metadata to the record
+— they do not redefine what the record is.
+:::