Session 36 (Season 2, Episode 9 — May 2025) closes the Season 2 arc by addressing the structural challenge that emerges once you have more than one ontology: they partially overlap, use different naming conventions, define the same concept in slightly different ways, and may have conflicting property constraints. This session presents a catalogue of structural reconciliation patterns — from identifying equivalent classes usingDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/jbarrasa/goingmeta/llms.txt
Use this file to discover all available pages before exploring further.
owl:equivalentClass to merging sub-hierarchies and handling property definition conflicts — all implemented programmatically using Python and RDFLib.
Watch the Recording
Full live-stream replay on YouTube
Session Code
RDFLib reconciliation notebooks and scripts
Why Reconciliation Is Necessary
In real ontology management scenarios — especially after the agentic catalog-building workflow from Session 35 — you accumulate multiple ontologies that describe overlapping domains. APerson class in one ontology may be the same as a Human class in another. A worksFor property in one ontology may be equivalent to employedBy in another. Before these ontologies can serve as a unified schema for KG construction, the overlaps and conflicts must be resolved.
Reconciliation operates at three levels:
- Class equivalence — identifying classes across ontologies that describe the same concept
- Hierarchy alignment — deciding how sub-class trees from different ontologies should be merged
- Property conflict resolution — handling cases where two ontologies define the same or equivalent properties differently
Pattern 1: Declaring Equivalent Classes
The simplest reconciliation pattern is declaringowl:equivalentClass between concepts in two ontologies. This preserves both ontologies’ terms while asserting that they refer to the same real-world category.
Storing the equivalence declarations in a separate alignment file rather than modifying either source ontology keeps the originals intact. The alignment file can be loaded alongside both ontologies whenever a unified view is needed.
Pattern 2: Merging Sub-Hierarchies
When two ontologies define overlapping but non-identical class hierarchies, reconciliation may require inserting bridging classes or redirectingrdfs:subClassOf relationships.
Pattern 3: Detecting Equivalent Properties
Properties are often reconciled by function: two properties with different names may have the same domain, range, and semantic intent. RDFLib’s SPARQL interface makes it straightforward to query for candidates:owl:equivalentProperty:
Pattern 4: Handling Conflicting Property Definitions
Conflicts arise when two ontologies define what appears to be the same property but with incompatible domains or ranges. The reconciliation strategy depends on the nature of the conflict:| Conflict type | Reconciliation approach |
|---|---|
| Same name, different domain | Rename one property or introduce a disjointness assertion |
| Same name, compatible range | Declare owl:equivalentProperty and align the ranges with a broader shared class |
| Incompatible cardinality constraints | Keep both constraints; document the discrepancy in rdfs:comment |
| One property is a specialization of the other | Declare rdfs:subPropertyOf rather than equivalence |
Building a Merged View
Once the alignment graph is populated, aConjunctiveGraph (or a simple merge operation) assembles a unified view that can be passed to getSchemaFromOnto():
Reconciliation Workflow Summary
Load and compare ontologies
Parse both ontologies with RDFLib. Use SPARQL queries or Python iteration to find overlapping class names, shared local names, and compatible domain/range pairs.
Identify equivalences
For each pair of matching concepts, decide between
owl:equivalentClass, owl:equivalentProperty, or rdfs:subClassOf/rdfs:subPropertyOf. Document your reasoning with rdfs:comment.Resolve conflicts
For incompatible definitions, choose a reconciliation strategy: renaming, specialization, or a neutral bridging class/property. Record the decision in the alignment file.
Build the merged view
Use
build_merged_view() to produce a single RDFLib Graph that includes both source ontologies and the alignment. Pass it to getSchemaFromOnto() for downstream KG construction.Key Takeaways
Alignment files, not mutations
Store reconciliation decisions in a separate alignment Turtle file. Never modify source ontologies — the alignment is the artefact that records the design decision.
RDFLib as the reconciliation engine
Python + RDFLib provides full programmatic access to OWL axioms, SPARQL queries over multiple graphs, and straightforward triple-level manipulation for alignment authoring.
owl:equivalentClass vs rdfs:subClassOf
Choose equivalence when two classes describe exactly the same concept across ontologies. Choose subClassOf when one is a specialization of the other. The distinction matters for downstream reasoning.
Integration with agentic workflows
The reconciliation patterns here complement the ontology catalog from Session 35 — when the catalog holds multiple overlapping ontologies, reconciliation produces the unified schema for extraction.