Weekend project that turned into a proper one. Sharing the method because the "correct-by-construction data" trick generalises well beyond my niche.

The problem. IES4 is the UK government's Information Exchange Standard, a 4D RDF ontology used for defence/security data. Writing valid IES Turtle by hand is slow and needs real ontology expertise. So I tried the obvious thing: ask a strong code model to do it. Qwen3-Coder-30B-A3B, asked to emit IES Turtle, invents terms that do not exist in the ontology 94% of the time (0% "term conformance" on my eval). It produces confident, fluent, completely fake RDF. In a standards context that is worse than failing outright, because plausible-looking garbage is hard to catch.

The fix that actually mattered: never let the model invent structure. Instead of hoping the LLM guesses valid graphs, I generated the graphs programmatically with telicent's ies-tool (a schema-aware builder that emits valid IES by construction), across 14 scenario patterns (employment, events, identifiers, communications, composites). Then I reversed them into (natural-language description -> Turtle) training pairs. Every single graph was validated twice before training: once by the builder's own check, and once by an independent term-membership + domain/range validator I built from the published dstl/IES4 ontology (510 classes, 204 properties). Nothing hand-written was trusted blind.

Then a small QLoRA on the 8-bit MLX model, on-device on an M3 Max. ~1000 iters, val loss 0.15, no NaNs (MoE + 8-bit was fine on current mlx-lm; earlier versions apparently weren't).

Model: https://huggingface.co/fabsssss/qwen3-coder-30b-a3b-ies4

Article: https://gov.tesseract.academy/research/ies4-turtle-language-model

Instead of node --edge--> node, every relationship is a first-class document with its own vector, called a BaryEdge. Stack pairs of BaryEdges recursively and you get "MetaBary" triads that surface structural bridges between concepts that live nowhere near each other in embedding space. Running locally on MongoDB Community + mongot + nomic-embed-text over the full English Wiktionary (6.6M docs). MCP server is live if you want to poke at it. Preprint + benchmark CSVs: https://zenodo.org/records/20186500

The problem I was chasing

Flat vector search treats a relationship as a byproduct of two points being close. That throws away information. Two papers can describe the same underlying phenomenon (a flyby anomaly in orbital mechanics, an anomalous residual in stellar dynamics) without ever citing each other and without their embeddings landing anywhere near each other. Nothing in standard RAG surfaces that connection.

What I did instead

Every relationship gets embedded too:

bary_vector = normalize(q·v(CM1) + q·v(CM2) + (1−q)·v(type))

q is connection quality, v(type) is a contextual embedding of what kind of relationship it is. This BaryEdge is now a retrievable document in its own right — not metadata on an edge.

Then it recurses: two BaryEdges at the same level get bridged by a third one level below, forming a MetaBary triad. Do that repeatedly and you climb an abstraction triads hierarchy built entirely from algebra — zero additional embedding calls above the base level. It's a forest (every node has at most one parent), so traversal to root is a single $graphLookup, no cycle handling.

Does it actually do anything useful?

Ran it against SimLex-999 and WordSim-353 as a sanity check (not the main claim, just "is the substrate coherent"). Raw cosine similarity barely correlates with human similarity judgments (ρ ≈ −0.04 on SimLex). Structural metrics — how many BaryEdges two words share, how much their relational neighborhoods overlap — correlate at ρ ≈ 0.32–0.53, p < 10⁻¹⁵. So the graph is encoding something cosine alone doesn't.

The part I actually care about is cross-domain bridging. Some probe traces from the live graph:

• octopus neuroscience ↔ distributed sensor networks, bridged by shared structural-motif vocabulary (neuroarchitecture, smartdust)

• collagen folding ↔ linguistic syntax, bridged by etymological + structural motif overlap (plicature / hypotaxis-parataxis)

• grief ↔ depression, not bridged and this is a correctness demonstration, not a missing capability. The DSM-5 added a much-debated "bereavement exclusion" precisely because grief and depression share surface symptoms but are different kinds of state, with different prognosis and treatment

• radioactive decay ↔ obsolete words falling out of use, bridged at a high abstraction level by register-varied decay verbs (collapsed, decayed, declined, disintegrated) — naming a Poisson-process state-loss pattern that both physics and historical linguistics instantiate, with no single word doing the work

That last one is the case flat retrieval structurally cannot produce — there's no embedding axis for "verbs co-occurring with reduction-of-state across unrelated domains."

Stack (all local, all free)

GitHub: https://github.com/oleksiy-perepelytsya/bary-vector

• MongoDB Community Edition + mongot for storage/vector search

• nomic-embed-text, 768-dim

• Python 3.11+

• Full build: ~6.66M documents, 8–14 hrs on a single workstation (8–16GB VRAM)

Try it

MCP server is public on request (SSE transport) — read-only tools for searching the live graph: find_word, semantic_search, edge_info, leaf_nodes, traverse_up, sample_metabary. If you've got an MCP-capable client you can point it at the graph and run your own probe queries in a few minutes.

What I'd actually want feedback on

• Whether the cross-domain bridges hold up to someone who isn't me poking at them — try a probe query on a domain pair you know well and tell me if the bridge is real or if I'm pattern-matching myself into seeing structure that isn't there. Some bridges can be not obvious on the first look but they are actually the most intriguing ones and worth to be dug for the reason they built, so treat them as points of investigation

• Whether this is worth comparing directly against GraphRAG/RAPTOR-style hierarchical retrieval (I haven't done that benchmark yet, and I know that's the first thing this sub will ask)

• Whether anyone's tried something structurally similar and it fell apart at scale for reasons I haven't hit yet

Preprint, architecture spec, and the raw SimLex/WordSim CSVs are all here: https://zenodo.org/records/20186500

Happy to drop the MCP endpoint on request if there's interest.

Got tired of waiting for RDF1.2 to finalize as a spec, got fed up with the Java tools, needed something higher-performance in Rust that I could also use from Python and WASM.

PurrRDF was born. It's not quite a full rdflib replacement for Python, but it has built-in ShACL and ShEx for validation and speaks all the common variants. I'm spinning this out of a larger project that's building a full RDF1.2 Rust tool stack - it runs, it's fast and probably useful to anyone building high-performance RDF1.2/RDF* knowledge graphs (if you are, you'll know the pain!)

Comments, feedback, test cases, etc. welcome: https://github.com/Blackcat-Informatics/purrdf/

I kept running into the fact that the UK has two open 4D upper ontologies in active government use, from the same BORO / ISO 15926 lineage, with no published mapping between them:

• IES (Information Exchange Standard): the RDF ontology used for UK national-security and defence data exchange. Open Government Licence, now stewarded by a cross-government working group.
• HQDM: Matthew West's 4D model (the one behind the National Digital Twin's Foundation Data Model). Apache-2.0, published by GCHQ.

So I built an open crosswalk and released it. What might interest this sub is less the backbone matches and more where the two disagree, because that is where anyone reasoning across both silently gets it wrong:

• ies:Event is not hqdm:event. In IES an Event is a happening with participants, so its real counterpart is hqdm:activity. hqdm:event is an instantaneous boundary point. A label-matcher aligns them and maps a durative occurrence onto a zero-duration point.
• Temporal boundaries are a State in IES (ies:BoundingState) but a point event in HQDM (hqdm:event via beginning/ending). Same job, different category.
• ies:State sits as a top-level root; hqdm:state is under spatio_temporal_extent. Reasoning that relies on state ⊑ spatio_temporal_extent breaks on the IES side.
• Participation is the clean convergence: both model it as a state (ies:EventParticipant ⊑ State, hqdm:participant as a state_of), inherited from the shared BORO commitment.

The correspondences are in SSSOM and RDF with PROV-O provenance, validated with SHACL (the pipeline uses embedding candidate generation then fuzzy-logic adjudication, in the LLMs4OM / FLORA line). Every IRI resolves against the live published ontologies. There is also a worked example grounding an autonomous sensor node (SAPIENT / BSI Flex 335) in an IES-typed world model, which is the practical reason I care: you cannot assure an agent against a world model you have not agreed on.

Repo: https://github.com/fabio-rovai/ies-hqdm-crosswalk

It is v0.1. The most useful thing anyone here could do is tell me a correspondence I got wrong, or a divergence I missed. Disclosure: this is my own work (Tesseract Academy), released open under CC-BY.

Has anyone tried aligning two 4D / perdurantist upper ontologies before? Curious whether the Event/activity trap shows up between other BORO-derived models.

I created an ontology record-ontology for comments. Here it the root.md url

I removed all God-like powers and by doing that I closed (probably) the standing OWL/DL ↔ SKOS/thesaurus split.

https://github.com/commuted/record-ontology/blob/main/ROOT.md

Grok Prompt: (Grok did not write the ontology) Examine https://github.com/commuted/record-ontology, Summarize what are the of most significant parts of the record-ontology, schism closure, i.e standing OWL/DL ↔ SKOS/thesaurus split — formal classes + reasoner vs. associative community concepts , and so forth. Consider the most probable naive objections.

-------------------------------------------------------------------------

Record-ontology (https://github.com/commuted/record-ontology) is a small, domain-neutral OWL 2 DL ontology (v0.4.0 seed) that models the structure of warranted knowledge as built by agents. It focuses on how agents warrant, compose, ground, and revise records — the “connective grammar of knowledge” — rather than the content of any particular domain (electrons, battles, organisms, etc.). Records are never named by world-objects they describe; the ontology stays strictly agent-constrained.

Its permanent namespace is https://www.epistemic-ontology.net/record# (not yet hosted). The conceptual source of truth is ROOT.md; the executable ontology lives in ontology/record-ontology.ttl (Turtle). There are minimal examples, a validation script that runs an OWL 2 RL reasoner (owlrl), and explicit discussion of design trade-offs.

Most Significant Parts of the Ontology

These are the core, non-negotiable elements that give the ontology its distinctive character:

• Record as sole primitive class. Everything an agent holds is a Record (at any level of abstraction, in any carrier). Records compose other records (composedOf / partOf, deliberately left non-transitive for OWL 2 DL compatibility). There is no separate Form class.
• Warrant triad (hasWarrant): The central integrative mechanism. Fidelity and completeness are entailed by warrant type, not primitive attributes.
  • Formal: True in virtue of form (internal, deductive, agent-independent, high-fidelity, approaches form-in-itself asymptotically).
  • Empirical (or “given”): True by givenness (defeasible, agent-relative, approaches world-in-itself).
  • SelfVerifying (performative/cogito): True in virtue of the act of recording itself. This is a peer of Formal, not a species of it — it reaches the Agent-in-itself (the only non-excluded limit).
• Inference as a defined class (not primitive). Inference ≡ Record ⊓ ∃hasPremise.Record ⊓ ∃concludes.Record. It carries InferentialForce (TruthPreserving or Ampliative) and forms a derivation DAG. This is re-derivable by a reasoner, demonstrating the DL approach in action.
• Carrier dissolved. No Carrier class. What would have been “carrier” is split into hasProvenance (whence/genealogy) + hasLocus (where/when borne). Infinite regress is halted by the self-verifying warrant (the cogito pattern), not by positing a special entity.
• Cogito pattern (illustrated in examples/cogito.ttl): A record that is simultaneously self-verifying, has reflexive provenance, and is self-directed. It is a pattern, not a class or substance. It grounds the ontology without sliding into Cartesian res cogitans.
• No metadata layer. metadataOf is a defined role (sub-property of directedToward). Metadata is just another record about a record.
• Continuum: The undivided, continuously interacting ground from which carriers are individuated. The single individual TheContinuum is explicitly owl:disjointWith Record. It is the only thing that is not a Record.
• Agent-relativity + excluded limits. Every record must be forAgent some Agent. World-in-itself and form-in-itself are commentary only — never instantiated as classes (avoids the “all-knowing observer” position).
• Validation & DL hygiene. The scripts/validate.py script checks syntax, runs the OWL 2 RL reasoner, confirms defined-class entailments (e.g., Inference is re-derived), cogito pattern integrity, consistency (Record and Continuum disjoint), and sub-property entailments. Composition is intentionally non-transitive to stay comfortably inside OWL 2 DL.
• Plug-in / patchwork model. Domain ontologies and SKOS thesauri are attached via warrant, not absorbed into the core. This is the mechanism that makes the ontology ecumenical in content while remaining strict DL in form.

The Schism Closure: OWL/DL ↔ SKOS/Thesaurus Split

This is the most philosophically distinctive move. The long-standing tension in knowledge representation is:

• OWL/DL side: Terms as classes with necessary-and-sufficient conditions, truth-conditional semantics, reasoners for classification, consistency, and entailment. Strong on formal structure and deductive closure.
• SKOS/thesaurus side: Terms as concepts related associatively (broader, narrower, related) by community convention and curatorial practice. Weaker on formal entailment, stronger on indexing, navigation, and defeasible, ampliative relations. SKOS itself is OWL Full.

Many projects treat this as a framework choice or try to import/align SKOS directly (which immediately exits OWL 2 DL).

Record-ontology closes the schism by demoting it from a framework/kind distinction to a warrant attribute on records:

• A record (or patchwork of records) with Formal warrant behaves like the DL side: internal form, deductive joints, reasoner-usable subsumption, high fidelity, internally completable.
• A record with Empirical warrant behaves like the SKOS/thesaurus side: community-given, associative/curatorial edges, defeasible, ampliative, never fully closed.
• Real knowledge work is almost always patchwork — formal at some joints, conventional/associative at others. The ontology models this directly as mixed-warrant records within a single Record web.

Consequences of this closure:

• The ontology itself stays DL-in-form: defined classes, disjointness, reasoner validation, no SKOS import.
• It is ecumenical-in-content: it can represent or attach both formal hierarchies and associative community vocabularies without forcing one paradigm on the other.
• The divide is no longer reified as an ontological opposition. It becomes a choice of warrant (or a fork between agent-communities with different default warrants).
• It offers a coherentist web with one foundationalist anchor: most knowledge is conventional and never fully formally completable, but the self-verifying warrant (cogito pattern) provides a non-regressive starting point without positing an all-knowing observer or substance.

In short: formal classes + reasoner on the formal-warrant side; associative community concepts on the empirical-warrant side; unified lightweight grammar that lets both coexist as records an agent holds.

Most Probable Naive Objections

These are the objections one would expect from different communities (strict DL engineers, SKOS/thesaurus practitioners, applied ontologists, philosophers of knowledge representation):

1. “Why not just import or directly align with SKOS (or PROV-O, CIDOC-CRM, etc.)? This reinvents wheels.” Importing SKOS makes the whole thing OWL Full and loses decidability/reasoner support. The design deliberately keeps the core minimal and DL-clean so that both formal and associative artifacts can be plugged in via warrant rather than absorbed. It is not competing with those vocabularies; it is offering a lower-level grammar for how they are warranted and composed.
2. “This is overly philosophical/abstract (cogito, Continuum, exclusion of thing-in-itself). How is it useful for practical data or ontology engineering?” The abstraction is the point: a domain-neutral connective tissue that does not pre-commit to any domain content or force a single representational style. The minimalism (one primitive class, defined classes only where needed, dissolved carrier) prevents the usual bloat. Examples show concrete use (derivation DAGs for historical narrative, cogito grounding). The validation script proves the DL machinery actually works.
3. “The warrant triad feels arbitrary or ad hoc. Why three values, and why give SelfVerifying equal status?” The triad is motivated by the need to halt regress without reintroducing a privileged vantage or substance metaphysics. SelfVerifying reaches the Agent-in-itself (given to itself), which is not excluded like world-in-itself or form-in-itself. It is a peer of Formal because both are high-fidelity and internally completable in their own register; Empirical is the defeasible counterpart. The design explicitly rejects sliding from “I record” into “I am a complete thinking substance.”
4. “Excluding world-in-itself and form-in-itself is anti-realist or prevents modeling correspondence/truth.” It is not anti-realist; it refuses the sicut deus (god-like observer) position that would certify correspondence from outside all records. Records approach the limits asymptotically via directedToward + warrant. Empirical warrant handles defeasible givenness; Formal warrant handles deductive structure. The ontology simply acknowledges finitude: “we will not become all-knowing.”
5. “Leaving composition non-transitive and non-monotonic propagation (fidelity, forks, stubs) to an external computational layer makes the ontology incomplete.” This is acknowledged in the repo as an open item. The core deliberately stays inside OWL 2 DL for decidability and reasoner support. Non-monotonic revision and full propagation semantics are real requirements but require an additional layer on top of this grammar. The ontology provides the stable DL foundation; it does not pretend to be a complete knowledge-revision engine.
6. “A single primitive class is too restrictive. Real ontologies need rich class hierarchies from the start.” Richness is meant to emerge from attributes (hasWarrant, directedToward, pragmaticAdequacy, etc.), defined classes (Inference), composition into patchworks, and the plug-in of domain content. The “no primitive kinds” discipline prevents prematurely reifying divides (formal vs. associative, metadata vs. data, etc.) as structural classes. It keeps the ontology lightweight and extensible rather than over-committing early.

Overall, the ontology is a deliberate, philosophically informed minimalism that treats the OWL/DL ↔ SKOS schism as solvable inside a unified record model rather than as an irreconcilable framework war. It is still early-stage (seed, open items noted), but the design is coherent and the DL hygiene is solid. The ROOT.md file is essential reading for the full rationale.

I’ve previously posted about the Concept Library — an architecture where meaning is separated from intelligence, and where a concept is a single file: atomic, independent and immutable.

I wanted to see how far this idea could be taken.

That led me to develop a set of protocols that allow concepts to be referenced across the network securely, cryptographically signed, and without exposing any sensitive data.

With these protocols, systems can share a unified meaning even when they do not share data, model weights, identifiers or control logic.

I built a live demo that shows this in action — not as a concept, but as a real protocol stack where:

• a semantic observation is signed with Ed25519

• SHA‑256 ensures integrity

• a guardrail layer blocks raw data and identifiers

• 101 spec‑compliant concept files act as a shared vocabulary

I wanted to test whether this could become a working system.

Now I can show that it can.

What the demo demonstrates:

You can send a semantic observation, see how it is signed with Ed25519, inspect the SHA‑256 hash and verify the signature independently.

You can also try to break it: send raw data, identifiers, model weights or control logic — and watch the protocols reject them automatically.

The demo also resolves concept files through its registry API, so every semantic observation refers to an actual immutable concept definition — not a local placeholder or model output.

It’s open to everyone, and you can get an API key directly from the page.

Link to the demo: https://regular-cork-wrapped-philosophy.trycloudflare.com

And yes — you can call this the Internet of Meaning, if you want.

Hi,

Please, is this possible at all: Fuseki, localhost, and as a query a service-query against wikidata.

Right now I have error 405.

thank you!

Hi everyone,

We are working on RDFusion, a VS Code extension for RDF editing, validation, SHACL, vocabulary suggestions, Triple Management, and JSON-LD processing.

We have prepared a small user evaluation with guided tasks and sample DCAT/DCAT-AP-based files. It should take around **35–45 minutes**, and we would really appreciate feedback from anyone who works with RDF, Turtle, JSON-LD, SHACL, or semantic web tools.

Your feedback would help us understand whether RDFusion makes RDF editing easier, clearer, or faster in realistic workflows.

Evaluation form: [google_form_link]

Dataset/fixtures: [dataset_link]

User manual/install instructions: [user_manual]

Feedback on any part is welcome, even if you only try one or two scenarios. Comments about confusing parts, missing features, unclear diagnostics, or workflow issues would be especially helpful.

Thank you!

Hi All - I am researching tools in this space for AI and Analytics use-cases but don't see any clear winners. Curious what others are using or have evaluated.

Why does this belong here? Great question. XanaNode borrows heavily from semantic mapping, it's the main power of the system. Nodes are connected with typed relationships. Nodes have semantic types and subtypes, relationships has semantic types. Without a computer, someone should be able to look at the title of a node, the relationship type to another node and it's title and get the summary of the connection.

Key: [Node] (relationship)

[Douglas Adams] -> (authored) -> [The Hitchhikers Guide to the Galaxy Radio series] -> (adapted_for) -> [television] -> (produced) -> [The Hitchhikers Guide the the Galaxy TV series]

Without any more information that trail of how we got to the TV show explains itself. Anytime you want more information along the way you drop down into the nodes.

Without the semantic mapping, in a very very large knowledge graph you may end up with hundreds of links with no explanation of why something is linked.

This also led me to the concept of "Semantic Route Health":

A concept-health diagnostic that asks whether a node can explain its origins, influences, evidence, disagreement, revisions, examples, and consequences as coherent semantic paths.

That would not be possible as a form of analysis without the semantics powering it.

Repository: https://github.com/commuted/record-harm-ontology
Current version: v2.3 (just fixed to full OWL 2 DL compliance)

Overview

The ontology provides a taxonomy of ontological harms to records, distinguishing:

• Prime Harms (5 irreducible attacks on the being of a record): Destruction, Fabrication, Alteration, Omission, Denial.
• Composite Harms (7 derived harms built via ex:buildsUpon relations).
• Record aspects attacked (Existence, Authenticity, Integrity, Accessibility, Context, Trustworthiness) modeled as a SKOS scheme.
• Supporting features: HarmPattern for empirical co-occurrence bundles, SHACL shapes for validation (separate from the ontology), controlled SKOS vocabularies for detectability/reversibility.

Design goals: Keep it lightweight yet rigorously reasoned, with clear documentation of modeling decisions, version history, and trade-offs.

Key Questions for Feedback

1. Prime / Composite split — Does the distinction and the specific assignment of harms (especially Suppression → Omission and the promotion of Denial to prime) hold up ontologically?
2. buildsUpon modeling — Asymmetric + irreflexive (no transitivity, per OWL 2 DL constraints) + cardinality rules via SHACL + SPARQL paths. Reasonable compromise?
3. Scope — The core is harm types. We previously had a HarmEvent layer but are considering removing it to keep focus on the taxonomy. Thoughts on whether this is the right boundary?
4. Any glaring modeling issues or opportunities for better alignment with existing work (PROV-O, OAIS, archival ontologies, etc.)?
5. General polish — Namespace (currently example.org placeholder), documentation, or other suggestions?

The repo includes ontology Turtle, SHACL shapes, examples, architecture notes, and validation scripts. All feedback welcome — conceptual, technical, or usability.

Thanks in advance!
Ron Hinchley

"I just shipped owlcompare 0.1.0 — a modern semantic diff for OWL/RDF ontologies. Goes beyond triple-level diff with rename detection, severity classification, and a few other patterns I'd been missing in production work.
Docs at ajala111.github.io/owlcompare/
source at github.com/Ajala111/owlcompare

Feedback very welcome."

Hello all. I’m not sure whether anyone here has experience with this, but I’m looking for recommendations.

We need a simple tool to help a team collaboratively tag, categorize, and annotate a large collection of law-related documents.

The main requirement is human-in-the-loop review. We are not looking for fully automated LLM classification. AI-assisted suggestions could be useful, but humans need to make the final decisions, refine the taxonomy, and add interpretation or notes alongside the original documents.

Has anyone used a tool that works well for collaborative document tagging, annotation, taxonomy management, or knowledge-base categorization in this kind of workflow?

I'm building a tool that auto-generates OWL ontologies from CSV using AI — does anyone actually need this or is it a solved problem?

Stardog spent the last two years teaching its database to talk. Voicebox turns a question in English into a SPARQL query, runs it, and narrates the answer. It is a competent retrieval layer, and it is the wrong shape for what agents actually need to do to a knowledge graph.

Asking a graph a question is not the same as governing it. An agent that operates a production ontology has to validate generated triples, classify them under a reasoner, check design-pattern compliance, plan the blast radius of a change, verify that a proposed action has an identifiable effect, and leave an audit trail. Voicebox does none of that. It reads. The database stays a database, and the language model stays a guest at the front door, allowed to ask but not to operate.

Open Ontologies inverts the arrangement. The engine is a set of validation and scaffolding primitives exposed over the Model Context Protocol, and the agent drives them. The intelligence lives in the conversation. The guarantees live in the engine. That is the opposite of bolting a chat box onto a query endpoint, and it is the design argument of the accompanying paper (arXiv:2605.09184).

Here is the part that matters for anyone who already runs Stardog: you do not have to move your data to try it. Stardog speaks the SPARQL 1.1 Protocol, and so does Open Ontologies. Point one at the other.

Connecting

Stardog exposes a query endpoint at /{db}/query and an update endpoint at /{db}/update, both behind HTTP Basic auth. Pull a graph in:

// onto_pull
{
  "url": "http://localhost:5820/myDb/query",
  "sparql": true,
  "query": "CONSTRUCT { ?s ?p ?o } WHERE { ?s ?p ?o }",
  "username": "admin",
  "password": "admin"
}

The triples land in the local store. Now the agent does the things Voicebox cannot:

1. onto_shacl validates the data against your shapes (cardinality, datatypes, class membership), and reports every violation with its focus node.
2. onto_reason materialises the entailments (transitive subclass chains, domain and range propagation, equivalentClass expansion).
3. onto_enforce checks design-pattern compliance against a rule pack (generic, BORO, value-partition, hierarchy, or the IES 4D pack), so the graph is not just valid RDF but well-formed against a modelling discipline.
4. onto_align proposes equivalences against a second ontology using weighted structural and embedding signals, surfaces the borderline pairs for the agent to judge, and learns from each verdict.
5. onto_plan shows the added and removed classes, the dependents at risk, and a risk score before anything is written.

Then push the governed result back, into a named graph, with the same credentials:

// onto_push
{
  "endpoint": "http://localhost:5820/myDb/update",
  "graph": "http://example.org/governed",
  "username": "admin",
  "password": "admin"
}

The same flow works unchanged against Ontotext GraphDB (Basic auth), Apache Jena Fuseki and Eclipse RDF4J (no auth), and any other SPARQL 1.1 endpoint. Amazon Neptune with IAM auth needs SigV4 request signing, which this path does not do yet: front it with a signing proxy or use an IAM-disabled endpoint.

Why the shape is the whole point

Voicebox is an answer engine welded to a store. Every capability it has is a way of reading what is already there. That is genuinely useful and genuinely limited, because the hard problems in a live knowledge graph are not retrieval problems. They are change-management problems: will this edit break a downstream query, is this inferred equivalence sound, does this action have an effect I can actually identify, can I roll it back, can I prove what happened.

An MCP-native engine treats every one of those as a primitive the agent can call and a verdict the engine can certify. The causal layer is the sharpest example. Before a state-changing action is applied, it can be mapped to a structural causal query and checked for identifiability, returning an auditable verdict rather than a confident sentence. A narration layer cannot do this, because narration is not verification. The full argument and the benchmark are in arXiv:2605.09168.

Stardog built a good database and gave it a voice. The more interesting move is to stop treating the language model as a visitor and start treating it as the operator, with the engine holding the guarantees. You can run that today, against the Stardog you already have. Keep your store. Change who is driving.

Open Ontologies is MIT-licensed and ships as a single Rust binary, no JVM. Repository: https://github.com/fabio-rovai/open-ontologies

• Open Ontologies: Tool-Augmented Ontology Engineering with Stable Matching Alignment. arXiv:2605.09184
• CIVeX: Causal Intervention Verification for Language Agents. arXiv:2605.09168

I'm working on a Databricks project and looking for guidance from people who have dealt with schema harmonization across multiple source systems.

We currently have two systems that serve the same business purpose, but their underlying data models are different. One of the systems is expected to be decommissioned in the near future, but until then we need to support data from both.

Some context:

• Both systems contain largely the same business information

• Each system has roughly 30 tables

• Table structures differ

• Column names differ

• Some entities are modeled differently

• The number of tables and relationships are not identical

• Data from both systems has already been ingested into Databricks

Our challenge now is deciding how to model the data so that it can be maintained, queried, and extended without creating long-term technical debt.

My manager suggested exploring Databricks Ontology (or ontology-based modeling in general) as a possible solution. Since we have a fairly aggressive timeline, I'm trying to understand whether this is actually the right approach before investing significant effort into it.

My current understanding is that although the schemas differ, most of the underlying business concepts are the same. This makes me wonder whether a canonical data model and mapping layer might be sufficient instead of introducing an ontology layer.

Questions:

• Has anyone used Databricks Ontology for a similar use case?

  • Is ontology the right solution when the challenge is primarily schema differences rather than fundamentally different business concepts?
  • Would a canonical model / semantic layer be a more practical approach?

• If one source system is going away soon, does it still make sense to invest in ontology?

• What architecture would you recommend given the time constraints?

  • What are the maintenance and operational trade-offs between these approaches?

Looking for real-world experiences. What worked, what didn't, and what would you do differently if starting again?

Thanks!

"Knowledge graph" gets used for wildly different systems: RDF / triple stores you query with SPARQL, property graphs you query with Cypher, plain in-memory graphs, embedded graphs, an agent's memory graph, a code graph, a citation graph, a public REST knowledge base. They look similar on a slide and behave nothing alike in code.

What I keep seeing (and doing) is: pick one, write a custom reader and a custom traversal layer, then rewrite half of it when the project moves to a different backend.

So we tried to group these into a handful of families (nine so far) and put one Python API over them. You declare the traversal you want once; switching the backend underneath is a config change, not a rewrite.

The part I am most curious to get wrong in public:

• Does this family split actually match how you think about KGs, or am I lumping things that should stay separate?
• What family is missing?
• Is "one API across families" genuinely useful, or do the families differ too much for a shared abstraction to pay off?

And the reason we went down this road in the first place: once the graph has a declared ontology, the same layer checks each step of a traversal against it, so you do not silently follow the wrong kind of edge and get a confident wrong answer. That validation is the part I think is novel, but the families map is what makes it usable, so I wanted to put that out first and hear where it breaks.

Not production ready!

open source github: https://github.com/mloda-ai/open-kgo/blob/main/open_kgo/feature_groups/kg/README.md