Ontology Revision Session¶
Facilitated revision session — instantiates Meta-Symbolic Rule Reflection
A facilitated working session that revises the entities, relations, and boundary rules of an ontology when its structure is constraining reasoning — and maps the old model onto the new so nothing in flight breaks.
An Ontology Revision Session is a facilitated working meeting that revises an ontology — the entities, the relation types between them, and the boundary rules that say what is one thing versus two — when that structure has started to constrain reasoning. Its defining move is that it works on a graph of entity types and relations, not a hierarchy of categories and not a class of models: the questions on the table are "is this really one entity or two?", "do we need a new relation type between these?", "where does this entity end?". Because an ontology is usually already wired into live systems, the session's second obligation is continuity — it produces an explicit old-to-new mapping and a versioned change record so that revising the model does not silently orphan the data and code that depend on it.
Example¶
An e-commerce company's catalog ontology has three entities — Product, Variant, SKU — and one relation, has-variant. It keeps generating problems: a "bundle" of three items has no clean representation, a refurbished unit of the same product needs a different warranty but isn't a new Variant, and gift cards fit nowhere. The team convenes an ontology revision session. On a shared board they map the current entities and the single relation, then surface the assumption baked into the model: that every sellable thing is a physical variant of one product. Working through the misfits, they propose adding a Bundle entity with a contains relation to Products, promoting condition from a hidden attribute to a first-class relation, and giving gift cards their own entity outside the product graph entirely.
Crucially, they do not stop at the redrawn diagram. They build a legacy mapping table — every existing SKU's old representation to its new one, including the awkward cases where one old record becomes two — and open a versioned change record noting what changed, why, and which downstream services (pricing, fulfillment, tax) must migrate. The revision improves the model and leaves a trail that lets the rest of the company move onto it without a data break.
How it works¶
- Work the entity-relation graph. The session's unit of work is entities and the typed relations among them — splitting an entity, adding a relation type, redrawing where one entity ends — not category nesting or model class.
- Facilitate the misfits into the model. Live discussion pushes the anomalies (bundles, refurb units) against the current entities until the group agrees on the entity or relation the model was missing.
- Map old to new, entity by entity. Every existing record's old representation is mapped to its new one, including one-becomes-two splits, so continuity is explicit rather than hoped for.
- Version the change on the record. A change record captures what changed, the rationale, and which dependents must migrate, so the revision is traceable and reversible.
Tuning parameters¶
- Revision scope — one entity's boundary, or the whole graph. Narrow scope is safe and fast; whole-graph revision fixes systemic misfit but multiplies migration work.
- Relation richness — how many typed relations you allow; more relation types express more but make the ontology harder to learn and query.
- Continuity strictness — whether every old record must map cleanly to a new one, or some may be marked legacy-only. Strict mapping protects downstream systems but constrains how boldly the model can change.
- Facilitation formality — an open whiteboard session or a structured change-proposal review. Structure suits high-dependency ontologies; openness suits early exploratory ones.
When it helps, and when it misleads¶
Its strength is fixing structural misfit in a shared model while keeping everything that depends on it intact — the mapping table and change record are what turn a clever new diagram into a revision the organization can actually adopt. It is the mechanism that respects ontological commitment[n1]: it takes seriously that the entities a system admits determine what it can even talk about, so it changes them deliberately and traceably rather than by drift.
It misleads when the session mistakes richness for rightness — every misfit case gets promoted to a new entity or relation until the ontology is a baroque graph nobody can hold in their head, the archetype's overcomplication failure. The other classic failure is skipping the mapping: a beautifully revised model that silently breaks reporting, integrations, and history because the old-to-new correspondence was never written down — lost continuity. The classic misuse is a design session that redraws the diagram and adjourns before anyone builds the migration. The guarding discipline is to require the legacy mapping table and change record as deliverables of the session, not follow-up work, and to add an entity only when a real case cannot be expressed without it.
How it implements the components¶
symbol_system_map— the session opens by rendering the current entities, relations, and boundary rules as the shared object everyone revises.revision_proposal— its primary output: a concrete revised graph — new entities, promoted or added relations, redrawn boundaries.legacy_mapping_table— it builds the explicit old-to-new correspondence for every existing record, including one-becomes-two splits, preserving continuity.change_control_record— it versions the change with rationale and the list of dependents that must migrate, so the revision is traceable and reversible.
It does not swap the underlying class of representation itself or trace a revision's downstream_consequence_trace — that is Model-Class Revision; this session revises the entities and relations within a representational system, not the system's kind.
Related¶
- Instantiates: Meta-Symbolic Rule Reflection — it revises an explicitly ontological framework (a domain model, product taxonomy, or knowledge graph) whose entity-relation structure constrains reasoning.
- Sibling mechanisms: Model-Class Revision · Taxonomy Redesign Workshop · Category Boundary Audit · Edge-Case Walkthrough · Language / Rule Critique · Governance Rule Review · Paradigm Review · Meta-Cognitive Reflection Prompt · Versioned Schema Change
Editorial Notes¶
Form Classification¶
Form family: Intervention, Treatment & Transformation
Rationale: The session directly changes ontology entities, typed relations, and boundary rules and maps existing records into the revised model.
Nearest alternative: Communication, Facilitation & Learning — Facilitation enables agreement, but success is the transformed ontology rather than dialogue alone.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Revision with migration mappings is characteristic of ontology engineering and schema evolution in computing.
Related originating lineages:
- Library & Information Science — Ontology Revision Session also draws materially on library and information science's traditions of classification, metadata, retrieval, preservation, and archival stewardship, which shaped this mechanism rather than merely adopting it as an application.
- Philosophy — Ontology Revision Session is most directly rooted in philosophy's traditions of conceptual analysis, ontology, logic, epistemology, and normative reasoning. The lineage fits its defining practice: A facilitated working session that revises the entities, relations, and boundary rules of an ontology when its structure is constraining reasoning — and maps the old model onto the new so nothing in flight breaks.
Review resolution: Authoritative-source research resolves the primary-origin disagreement in favor of computer science. OWL 2 Web Ontology Language Document Overview — W3C documents the formative practice or theory represented here. The retained alternate domains identify material co-development or translation, while current applicability is recorded separately as domain_reach=multi_domain; origin_mode=cross_disciplinary_synthesis describes the historical relationship among lineages.
Attribution caveat: The session packages established ontology revision concerns into a facilitated mechanism.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
Notes¶
[n1] Ontological commitment — Quine's principle that a theory's ontology is whatever its variables must range over for its statements to be true ("to be is to be the value of a variable"). Applied here, it is the reason an ontology revision is consequential rather than cosmetic: changing the entities a system admits changes what the system is capable of asserting at all. ↩