Keet notes, chapter 11: when is ontology work published?

Chapter 11 of Maria Keet’s ontology-engineering textbook is the release chapter: what has to be true before ontology work leaves the workbench. Our closing study passes pulled three lessons out of it that fit together as one discipline. Validation is not publication. The research loop that feeds the work needs a venue map, not a favorite feed. And no derivative surface, no summary, dashboard, or export, gets to become the contract. The common thread: publication is the moment another operator has to be able to trust the artifact without interviewing its builders.

Validation is a layer, not the verdict

Technical teams tend to assume that once the checks turn green, the work is ready. The build passes, a validator passes, a coverage number looks healthy, and the artifact starts to feel finished. Our Chapter 11 closeout argues for a harder standard. Hadto already runs logical checks, competency-question coverage, bounded governance audits, and artifact indexes; those reduce silent breakage. They do not answer the publication question: what would let another person trust that this ontology is ready to use, communicate, or rely on?

That question reaches past contradiction detection. An ontology can be formally valid while its purpose is unclear, its contributors and ownership invisible, its license and stable home unstated, and its structure hard to explain to the domain experts it is supposed to serve. The readiness elements from the closeout: purpose and use-case fit (an ontology that cannot explain its intended use is hard to review and harder to improve), quality beyond logical validity (the pitfall, relation, and question gates from the Chapter 5 note), publication metadata (who built it, how to cite it, what license applies, where its stable home lives, what version history exists), and communication posture (what documentation or summaries help a person understand the model). One practical surface, still a proposal rather than anything shipped: a short per-ontology governance page showing intended use, current owner, last review date, checks passed, and known limits, which a second operator could read before deciding to rely on the model.

Staying current needs a venue map

Publication runs in both directions: the program also has to keep reading the field, and Chapter 11’s context made us look at how. A research program becomes taste-driven when the team keeps returning to one familiar feed and calls the habit coverage. Ontology work does not live in one publication lane; useful advances show up across formal ontology and Semantic Web venues, logic and reasoning communities, tooling discussions, and application-heavy outlets where the paper may never use the word “ontology” in the title.

The transferable version is a venue map: the venue families the program watches, a maturity tag on each signal type (workshops and posters as early indicators worth watching, conference papers as patterns worth testing, journals and surveys as candidates for operating defaults), and, just as important, the deliberate gaps. A cycle focused on adoption mechanics may skip theory-heavy description-logic work on purpose; the next operator needs to know whether silence means “not relevant this round” or “not checked.” Publication type sets the decision weight: an early workshop signal adds a watchlist question, a repeated conference pattern may justify a prototype, and a journal synthesis may be strong enough to change a default method. A founder can compensate for a narrow feed from memory. A successor inherits only the visible system, so the map has to be the visible system.

The summary is not the contract

The third lesson arrived with a live warning attached. Hadto’s newest ontology research reporting produced a mismatch: the cycle history says research discovery added new competency questions, while the current ORSD view shows zero discovery-backed questions in the same areas. Which surface is right remains an open question. The report may overstate, the ORSD view may be stale, both may describe different transformation moments, or the evidence chain may be incomplete. The mismatch is useful precisely because it should not require archaeology to classify, and it did.

Keet’s Section 11.3.2 gives the category boundary underneath: an ontology expresses shared subject-domain knowledge across applications, while a conceptual model usually serves one application’s information needs, and a transformation from ontology into a model, schema, report, or summary can be useful without being lossless, complete, or safely reversible. So three artifact categories need names. The canonical contract governs shared meaning. A projection is a workflow surface derived from it. A summary is a time-bound account of recent change. All three help; only one governs, and most companies drift by trusting whichever surface is most convenient, because the next operator inherits whatever the system makes easiest to trust.

Our rule, stated once: every important derivative surface must say what it is derived from, what it leaves out, and whether edits are allowed to flow back. Five requirements make it usable: name the canonical contract; mark derivative surfaces as derivative; record the boundary loss or additions; declare the round-trip posture, because silence is how accidental governance gets created; and keep the evidence chain inspectable. The failure mode the rule prevents is well known: once a dashboard or generated model becomes the trusted memory, people edit it directly because that is faster than review, the local fix changes meaning another workflow depends on, and disagreement turns into screenshot archaeology.

If you run a business

Publication readiness is a business standard wearing ontology clothes. An owner should inherit systems with visible standards, not artifacts that feel trustworthy because the original builders vouch for them. The same test covers customer operations, finance, and training: can the next person see what this system is for, who owns it, what checks it survived, and where judgment still matters? Do not call the work published because the validators passed. Publish it when trust is readable, the intake map is inspectable, and every summary admits it is a summary.

---

Source evidence used in this note: Maria Keet’s ontology-engineering textbook, Chapter 11 (including Section 11.3.2 on the ontology versus conceptual-model boundary); Hadto’s internal Chapter 11 closeout and governance guidance (reviewed 2026-04-14 and 2026-04-18); internal ontology research-program operations guidance (reviewed 2026-04-20); and Hadto’s internal ontology research reporting showing the ORSD mismatch (reviewed 2026-04-18), whose cause remains undetermined. The per-ontology governance page is a proposal, not shipped work. This chapter note consolidates three earlier study posts on validation versus publication, the research venue map, and derivative surfaces versus the canonical contract.