Mission Engineering 10: Building a Reusable Business Ontology from Coffee Brewing

The article continues a series on mission engineering by formalizing a business ontology around a coffee‑brewing scenario. It argues that a reusable ontology must separate six distinct concepts: recipe & version (the guiding specification), execution plan (when, who, what for a single run), actual brew (the real‑world process instance), execution record (description, readings, sources, gaps), coffee product (the concrete output), and evaluation (feedback tied to a specific product and evaluator).

Six Core Content Types

A table maps each type to its meaning in the example and its relationships:

Recipe & version – dosage, stages, conditions; one version can be used by many brews; changes create new versions with rationale retained.

Execution plan – schedule, assignee, resources for one run; links to scenario, chosen recipe, and plan version; adjustments keep history.

Actual brew – the real process occurrence; has a unique brew ID, links to actual participants, equipment, materials, and what happened.

Execution record – describes a brew; may be corrected or supplemented, but original content and revision basis are preserved.

Coffee product – the specific coffee produced; linked to its brew; the example treats one cup per brew, not a universal rule.

Evaluation – a person’s feedback at a point in time; linked to evaluator, product, verbatim comment, and conditions; not a permanent attribute of the coffee.

The article stresses that selecting a recipe version and actually executing per that version are separate acts. Querying “how many times was this recipe followed?” requires clarity on whether selection or confirmed execution counts.

Teaching Examples: Two Brews from the Same Recipe

Two demo brews (CF‑DEMO‑BREW01 and CF‑DEMO‑BREW02) both use recipe CF‑RECIPE01 v1 and plan CF‑PLAN02. A table shows their distinct IDs, scenario, candidate plan, chosen recipe, execution plan, record IDs, record completeness (Demo A has all segment sources; Demo B misses an end timestamp), product IDs (CF‑DEMO‑CUP01, CF‑DEMO‑CUP02), and evaluations (Demo A rated “acceptable”; Demo B unevaluated). The author verifies three questions against the table:

Which brews used CF‑RECIPE01 v1? Both, but that doesn’t confirm they met the recipe.

How long did Demo B’s segment actually take? Only start time known; planned duration cannot substitute measured duration.

Which cup did the family accept? Only Demo A; Demo B must show “not evaluated,” not inherit the rating.

Missing fields (like Demo B’s end time) are left as “pending verification” with reason; they are not filled with planned values.

Record Revision Without Altering History

When a missing timestamp is later sourced, the record is revised: what was added, the source, who added it, and when. The original record version remains accessible. The article references W3C PROV‑O: the new record version wasRevisionOf the old, both describing the same brew; the revision activity links the source evidence and responsible agent. A diagram illustrates this revision chain.

Ontological Foundations

Terminology note: In BFO (Basic Formal Ontology), people, equipment, and coffee are Material Entities (Continuants); brewing is a Process (Occurrent). Recipe, written plan, and record content are Information Content Entities (ICE) per IAO – generically dependent continuants, not a third top‑level category. These classifications help separate physical things, processes, and information without requiring full mastery of the ontologies.

The author explains why earlier OPM (Object‑Process Methodology) models need supplementation: OPM diagrams show types (e.g., “kettle” as a class), but runtime instances (this specific kettle, this brew) must be explicitly linked. Each brew gets its own execution record; a process definition does not imply a single shared execution log.

Concept Cards for Each Definition

Definitions are captured in structured “concept cards” covering: name, stable ID, definition version; scope (what is included/excluded); instance identity criteria; relationships and their semantics; applicable scenarios, units, time semantics; source and confirmer; validation rules and who checks them; positive, negative, and insufficient‑evidence examples.

Validation Responsibilities

A table assigns checks to human reviewers (during curation) and future software (on save/completeness change):

Record must trace to brew and its recipe version – human verifies; app checks links and version references. Failure: keep as pending, not counted as “recipe‑confirmed” sample; reference existence ≠ actual compliance.

Before claiming completeness, verify against a required‑field checklist (CF‑R01) – human cross‑checks; app validates on completeness‑status change. Missing items listed; plan values never substitute measured values; extra plan‑B segments tracked separately.

Evaluation must link to product and evaluator – human confirms attribution; app validates links. No feedback → “unevaluated”; unverifiable attribution → “pending verification,” never auto‑filled as satisfied.

SHACL can validate structural constraints (fields, types, relations) but cannot prove factual truth (e.g., that a reading is accurate or feedback genuine). Data‑validation pass and “source pending verification” can coexist; both are recorded separately.

Practical Exercise

The article suggests practicing with two real spare‑parts issuance cases: identify the issuance standard, plan, actual handoff, log entry, and physical items. Use the concept cards to structure them, then test whether a handoff can answer “which issuance does this log describe?” and detect a deliberately mislinked log. Keep test copies separate from production records.

Conclusion

“Make another cup like yesterday’s” – the recipe is reused, but today’s start time, missing logs, and taster’s verdict are recorded separately. Only when definitions let future readers distinguish the specification, the execution, the product, and the evaluation does the ontology serve its purpose. The next installment will separate model verification, record reliability, and actual coffee quality into distinct acceptance criteria.

References

BFO‑2020 (ISO/IEC 21838‑2:2021) – Continuant, Occurrent, Material Entity, Process definitions.

https://github.com/BFO-ontology/BFO-2020/blob/master/21838-2/owl/bfo-core.owl

, https://committee.iso.org/standard/74572.html.

IAO – Information Content Entity (IAO_0000030) and Generically Dependent Continuant (BFO_0000031).

https://github.com/information-artifact-ontology/IAO/blob/master/iao.owl

.

W3C PROV‑Overview – entities, activities, agents for provenance. https://www.w3.org/TR/prov-overview/.

W3C PROV‑O – prov:wasRevisionOf for record versioning. https://www.w3.org/TR/prov-o/.

W3C SHACL – constraint validation and reports. https://www.w3.org/TR/shacl/.