Ontology Refactoring¶
Structural refactor — instantiates Schema Update Protocol
Restructures the entities, relations, and logical constraints of a formal ontology when its type structure misrepresents the domain, mapping old identifiers to new so machine consumers keep resolving.
Ontology Refactoring restructures a formal ontology — a machine-readable model of entities, the typed relations among them, and the logical constraints that govern them — when its structure has come to misrepresent the domain. Its defining feature is that the object is a graph of typed things and relations with inference rules, not a filing scheme: a refactor may re-parent a class in the is-a hierarchy, promote an attribute to a first-class entity, change the domain or range of a relation, or repair a constraint that a reasoner now flags as inconsistent. Because downstream systems query and reason over the ontology, the refactor must both fix the structure and provide a mapping from every retired identifier to its successor, so that machine consumers holding old identifiers do not silently break.
Example¶
A biomedical research group maintains a knowledge graph in which Disease has always been modeled as a single class with a free-text cause attribute. New data on infection-driven cancers makes this untenable: queries cannot follow causal chains because "cause" is a string, not a link, and a reasoner keeps deriving nonsense because has-symptom was declared to range over Disease rather than Phenotype. An Ontology Refactoring names the mismatch precisely — the model conflates a causal relation with a descriptive attribute, and one relation's range is mistyped — because a formal ontology's faults are stated in terms of entities, relations, and constraints, not merely "wrong categories." The refactor promotes cause to a first-class causes relation between Pathogen and Disease, re-ranges has-symptom onto Phenotype, and re-parents two disease classes that were sitting under the wrong genus. It ships a compatibility map from every deprecated class and property IRI to its replacement, so the dozens of queries, dashboards, and downstream graphs that reference the old identifiers can be migrated deterministically. A reasoner is re-run to confirm the constraints are now consistent.
How it works¶
Refactoring a formal model differs from editing a hierarchy because relations and constraints carry inferential weight:
- State the mismatch structurally. The fault is expressed as a defect in entities, relations, or constraints (a mistyped range, an overloaded attribute, an inconsistent axiom), not just a misnamed bucket.
- Restructure the graph, not just the labels. Promote attributes to entities, re-range or re-domain relations, re-parent classes, and repair the axioms — changes that alter what can be inferred.
- Emit an identifier crosswalk. Every retired class or property identifier maps to its successor, because machine consumers dereference identifiers, not display names.
- Re-run the reasoner. Check that the refactored constraints are logically consistent and that no unintended entailments were introduced.
Tuning parameters¶
- Refactor depth — from a single re-parenting to a wholesale re-typing of relations; deeper fixes root misrepresentation but ripples through more inference and more consumers.
- Identifier policy — mint new identifiers and deprecate old ones, or rewrite in place; minting preserves auditability but forces every consumer to migrate.
- Constraint strictness — how tightly domains, ranges, and axioms are enforced after the refactor; stricter catches more errors but rejects more legacy data.
- Reasoner scope — how much of the graph is re-checked for consistency; full re-checks are safest but costly on large ontologies.
When it helps, and when it misleads¶
Its strength is that it repairs the modeling substrate other mechanisms take for granted: when the problem is that the domain's relations and constraints are mis-modeled, only a structural refactor of the entities and relations will fix what queries and reasoners get wrong. The discipline it draws on is OntoClean-style analysis — checking that each class's identity and subsumption is metaphysically well-formed rather than a convenient bucket — which is what keeps a refactor from trading one malformed hierarchy for another.[1]
Its failure mode is over-engineering: a refactor that pursues formal elegance the domain does not need, multiplying entities and relations until the ontology is precise, consistent, and unusable by the people who must populate it. The classic misuse is refactoring for the modeler's sense of cleanliness rather than a demonstrated query or reasoning failure — changing structure because it feels wrong, which the archetype names as churn without evidence. The guarding discipline is to tie every structural change to a query that failed, an inference that went wrong, or a reasoner inconsistency, and to run the reasoner and a sample of real queries before and after so the refactor is judged by restored function, not by aesthetic tidiness.
How it implements the components¶
schema_mismatch— names the fault in the model's own terms: a mistyped relation range, an overloaded attribute, an inconsistent axiom — the structural gap the refactor targets.category_revision— restructures the graph: re-parents classes, promotes attributes to entities, re-ranges relations, and repairs constraints, changing what can be inferred.backward_compatibility_map— the crosswalk from every retired class or property identifier to its successor, so machine consumers migrate deterministically.
Ontology Refactoring restructures a formal graph but does not run the bulk relabel of instance data or the staged cutover: it performs no migration_rule execution over stored records (that is Knowledge-Base Retagging). Its nearest twin is Taxonomy Revision, with which it shares the category-revision role; the separator is that a taxonomy revision reorganizes a single subsumption hierarchy of terms, whereas this restructures a graph of typed relations and logical constraints over which a reasoner infers, and it leaves continuity_constraint and current_schema_snapshot framing to that page.
Related¶
- Instantiates: Schema Update Protocol — refactoring is the schema-change step specialized to formal, machine-reasoned models.
- Consumes: Classification Audit supplies the failing queries and inconsistencies that evidence the structural mismatch.
- Sibling mechanisms: Classification Audit · Category Split/Merge Review · Coding-Frame Revision · Glossary Update · Knowledge-Base Retagging · Schema Change Review Board · Schema Migration Workflow · Taxonomy Revision
Editorial Notes¶
Form Classification¶
Form family: Intervention, Treatment & Transformation
Rationale: Ontology Refactoring operates as a direct treatment or transformation applied to a target to change its state or condition because it restructures the entities, relations, and logical constraints of a formal ontology when its type structure misrepresents the domain, mapping old identifiers to new so machine consumers keep resolving.
Independent corroboration: The frozen evidence defines Ontology Refactoring as 'Restructures the entities, relations, and logical constraints of a formal ontology when its type structure misrepresents the domain, mapping old identifiers to new so machine consumers keep resolving', so its operative form is Intervention, Treatment & Transformation.
Nearest alternative: Structure, Architecture & Configuration — Ontology Refactoring includes features of a configured physical, technical, or logical arrangement whose structure creates the effect, but its defining operation is a direct treatment or transformation applied to a target to change its state or condition.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Ontology Refactoring is most directly rooted in computer science and software engineering's formal and practical treatment of computation, interfaces, data, and reliable systems. The lineage fits its defining practice: Restructures the entities, relations, and logical constraints of a formal ontology when its type structure misrepresents the domain, mapping old identifiers to new so machine consumers keep resolving.
Related originating lineages:
- Philosophy — Ontology Refactoring also draws materially on philosophy's traditions of conceptual analysis, ontology, logic, epistemology, and normative reasoning, which shaped this mechanism rather than merely adopting it as an application.
Review resolution: Both independent reviews agree on primary origin computer_science; reconciliation resolves encyclopedia_synthesis_disagreement. Formative alternate lineages retained: philosophy. The broader reach of later applications is kept separate as domain_reach=multi_domain; origin_mode=cross_disciplinary_synthesis records how the formative lineages relate. Confidence is conservatively reconciled to high, and encyclopedia_synthesis=true preserves the reviewers' boundary judgment.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] OntoClean, developed by Guarino and Welty, is a methodology for evaluating ontological hierarchies using formal notions such as identity, rigidity, and unity — catching subsumption relations that are convenient labels but metaphysically ill-formed. It is the standard defense against a refactor that merely rearranges a malformed hierarchy. withdrawn registry ↩