Knowledge graphs

Research valid as of 2026-08-23. “Resonansia” is treated as a proposed Dataheart component because no independent technical specification was supplied.

Executive thesis

Dataheart should not be designed as one universal enterprise graph. It should be a customer-owned semantic and evidentiary contract that can be compiled into several operational representations:

1. A canonical claim graph containing stable identities, temporal validity, provenance, contradictions, confidence, and policy scope.
2. An RDF/JSON-LD representation for semantic interoperability and exchange.
3. A labeled-property-graph representation for traversal and analytics.
4. Sparse, vector, and graph indexes for workload-specific retrieval.
5. An authorization-aware evidence bundle for every recommendation or action.

The canonical unit should be a claim, not a naked triple. A claim must retain:

• the source assertion;
• the canonical entities it concerns;
• supporting and contradicting evidence;
• business-valid time and system-recorded time;
• extraction or transformation provenance;
• confidence and epistemic status;
• the authorization policy governing its use.

The strongest durable standards boundary is presently RDF 1.1/JSON-LD 1.1, lightweight OWL 2 profiles, SHACL, PROV-O, and canonical RDF exports. RDF 1.2 adds useful statement-level terms, but as of the cutoff it remains a Candidate Recommendation, while SPARQL 1.2 is still a Working Draft. ISO GQL is now a published property-graph query standard, but query syntax portability does not make RDF and labeled property graphs semantically equivalent. RDF 1.2, SPARQL 1.2, ISO GQL.

GraphRAG is best understood as a selective retrieval strategy, not the foundation of the knowledge layer. Evidence since 2024 shows advantages for multi-hop and global sensemaking, while conventional sparse/vector RAG often remains better for single-hop questions and fine detail. Microsoft’s original GraphRAG implementation is now explicitly a research demonstration in maintenance mode, not a supported Microsoft product. Microsoft GraphRAG paper, systematic comparison, repository status.

The recommended role for Resonansia is therefore a semantic control plane and evidence registry—not a proprietary graph database. It should source-control semantic contracts, preserve claims and lineage, compile profile-specific projections, run conformance tests, and return authorized evidence subgraphs with proof traces.

State of the art 2024–2026

Area	Assessment	State
RDF semantics and exchange	RDF, JSON-LD, SPARQL 1.1, OWL 2, SHACL, and PROV-O are mature interoperability foundations.	Established
Statement-level metadata	RDF 1.2 triple terms and SPARQL 1.2 reification constructs reduce reification friction, but both suites are not yet final together.	Emerging
Property-graph interoperability	ISO/IEC 39075:2024 established GQL, with a July 2026 corrigendum. Implementations still vary in supported features, types, extensions, and administration.	Established standard, emerging portability
Dataset integrity	RDFC-1.0 provides deterministic RDF canonicalization suitable for reproducible hashes and snapshot comparison. It proves dataset equivalence/integrity, not truth or authorship.	Established
Ontology reasoning	Lightweight OWL profiles and bounded rules are operationally viable. Full expressive reasoning remains costly and frequently mismatched with closed-world business validation.	Established within limits
Constraint validation	SHACL is mature for schema-like graph validation, semantic data contracts, and machine-readable validation reports. Recursion and implementation extensions require care.	Established
Temporal knowledge	Modeling intervals and temporal relations is mature; reliable enterprise operation additionally requires valid time, transaction time, retractions, and ontology-version time. No single graph standard supplies the complete bitemporal operational contract.	Established pattern; fragmented implementation
Entity resolution	Probabilistic record linkage, blocking, clerical review, and measured false-match rates remain the dependable approach. LLM-based entity linking is useful for candidate generation, not authoritative merging.	Established core; emerging LLM augmentation
GraphRAG	Demonstrated value for global summarization and multi-hop retrieval; broader evaluations support workload routing or hybrid retrieval rather than graph-only retrieval.	Emerging
Graph memory	HippoRAG 2 reports gains using passage nodes, Personalized PageRank, and online model use. This is primary research evidence, not proof of enterprise reliability, security, or cost.	Emerging
Provenance-aware retrieval	PROV-O supplies a vocabulary, but claim confidence, contradictory evidence, policy evaluation, retrieval paths, and answer citations still require an application profile.	Emerging engineering practice
Retrieval security	RAG stores are a material poisoning and indirect-prompt-injection surface. PoisonedRAG achieved a reported 90% attack success rate with five malicious texts per target question in its test setting; tested defenses were insufficient.	Established risk; immature defense
Microsoft graph profile	Fabric Graph provides an LPG projection over OneLake with GQL and Fabric governance integration. Natural-language graph reasoning is preview, schema evolution currently requires a new model and reingestion, and scale claims lack independent public validation.	Vendor capability and vendor claim
Open/self-hosted profile	Standards-complete components exist, but customers must assemble HA, backup, policy enforcement, observability, indexing, model serving, and upgrades. Apache Jena, for example, implements SHACL but its graph ACL support is read-only and coarse.	Established components; integration burden

Microsoft estimates that entity and relationship extraction accounts for roughly 75% of standard GraphRAG indexing cost. Its documentation also warns that indexing can consume substantial model resources. This is a strong argument for incremental, evidence-preserving graph construction rather than periodic full-corpus regeneration. GraphRAG indexing methods.

Load-bearing concepts

1. Knowledge graph versus graph database

A knowledge graph is a semantic and evidentiary model. A graph database is one possible physical projection.

Dataheart must not let the chosen database define:

• business identity;
• truth status;
• ontology versioning;
• provenance granularity;
• temporal behavior;
• access semantics;
• export fidelity.

Those belong to the customer-owned contract.

2. Claims, evidence, and contradictions

Represent every material fact as a first-class claim. A claim may be:

• directly asserted by a governed system of record;
• extracted from a document;
• inferred by a deterministic rule;
• predicted statistically;
• proposed by an LLM;
• retracted or superseded;
• contradicted by another claim.

“Supported by three documents” is different from “true.” Source independence, authority, freshness, extraction quality, and contradiction must remain visible.

PROV-O can express entities, activities, agents, derivation, and responsibility, but Dataheart needs a stricter application profile for source spans, extraction runs, model versions, policy decisions, and retrieval traces. PROV-O.

3. Reversible entity resolution

Never merge source records destructively.

Use three identity levels:

• source-record identity;
• resolution-cluster identity;
• governed canonical entity identity.

Candidate matches should preserve comparison features, match probability, model version, review state, and supporting evidence. A probabilistic match must not become owl:sameAs; reserve identity equivalence for an exceptionally strong, governed assertion. False merges have a larger blast radius than missed matches because they contaminate traversal, summaries, recommendations, permissions, and actions.

4. Bitemporal—and sometimes tritemporal—knowledge

At minimum, every material claim needs:

• valid_from / valid_to: when it was true in the business world;
• recorded_from / recorded_to: when Dataheart believed or stored it;
• observed_at: when the evidence was observed;
• ontology_version: which meaning was used to interpret it.

This permits questions such as:

• “What was actually true on 1 May?”
• “What did we believe on 10 May about 1 May?”
• “Which conclusion changed after a backdated correction?”
• “Would the old ontology have classified this differently?”

OWL-Time supplies reusable interval semantics, but remains a 2022 Candidate Recommendation Draft. It does not replace the operational bitemporal contract. OWL-Time.

5. Ontology, glossary, validation, and policy are different things

• A glossary assigns human meaning and stewardship.
• A taxonomy organizes concepts.
• An ontology defines formal classes, relations, and logical consequences.
• SHACL expresses conformance constraints.
• A semantic metrics layer defines computations.
• A policy model governs permitted use.
• A physical schema describes storage.

Collapsing these into one “enterprise ontology” produces semantic debt and organizational deadlock. Use a small stable core plus customer-owned bounded-context modules. Version every module and test it against competency questions and representative data.

Use OWL RL or QL where their reasoning characteristics match the workload. Keep business completeness and mandatory-field rules in SHACL or explicit closed-world rules; OWL’s open-world semantics means absence does not normally imply falsehood. OWL 2 profiles, SHACL.

6. Context engine

A context engine is not merely a prompt assembler. It is a query-time decision system that:

1. resolves the requester, purpose, time, and policy context;
2. classifies the query;
3. selects sparse, dense, SQL, graph, or hybrid retrieval;
4. retrieves claims and primary evidence;
5. traverses only authorized edges;
6. exposes conflicts and uncertainty;
7. emits a bounded evidence bundle;
8. records the retrieval and policy trace.

Community summaries or embeddings may guide discovery, but final grounding should return to primary evidence.

7. Reasoning levels

Dataheart should distinguish:

• deterministic entailment;
• validation;
• graph algorithms;
• statistical link prediction;
• LLM synthesis;
• action authorization.

Only deterministic entailments can safely inherit the status of their premises—and even then only if all premises, rule versions, time scopes, and permissions are retained. Statistical predictions and LLM conclusions should remain hypotheses until accepted through a governed process.

8. Interoperability boundary

Use RDF 1.1-compatible first-class claim resources as the baseline. This maps reliably into RDF, JSON-LD, relational tables, and LPG nodes. RDF 1.2 triple terms may later be offered as an additional serialization.

Use RDFC-1.0 to canonicalize exported RDF snapshots, then hash or sign them at the application layer. The canonicalization hash demonstrates that two datasets are structurally equivalent; it does not establish that their statements are correct. RDFC-1.0.

Reference patterns

Pattern A: Canonical claim-and-evidence graph

Source artifact
  → source span / record version
  → extraction or mapping activity
  → claim
  → subject / predicate / object
  → temporal interval
  → policy scope
  → supporting and contradicting claims
  → supersession or retraction

Use immutable evidence identifiers and content digests. Keep the source artifact outside the graph when appropriate, but retain a resolvable, versioned pointer.

Pattern B: Canonical model with replaceable projections

The canonical log should feed:

• an RDF/SPARQL semantic projection;
• an LPG/GQL traversal projection;
• a sparse text index;
• a vector index;
• an analytics/table projection.

Each projection records its source checkpoint, mapping version, build activity, and conformance result. A projection is disposable; the canonical claims and source evidence are not.

Pattern C: Virtual-first, materialize selectively

Map governed source systems into the semantic contract and materialize only:

• cross-source canonical identities;
• relationship-heavy hot domains;
• expensive derived structures;
• authorized retrieval indexes;
• immutable evidence references.

This reduces duplication and stale copies. It also avoids converting every warehouse row into an expensive LLM-derived graph.

Pattern D: Hybrid retrieval router

Route queries by evaluated characteristics:

Query class	Preferred starting point
Exact identifier, number, date, or clause	SQL, sparse search
Fine-detail factual question	Sparse + dense passage retrieval
Multi-hop relationship question	Entity anchors + graph traversal + primary passages
Corpus-wide themes	Community or hierarchical summaries, followed by source verification
Temporal question	Bitemporal claim query first
Conflicting evidence	Claim/evidence graph with explicit contradiction retrieval
Recommendation or action	Authorized graph query plus fresh source-of-record confirmation

This follows the counter-evidence: conventional RAG retains an advantage for single-hop detail, while graph methods help with multi-hop and global structure. RAG versus GraphRAG evaluation.

Pattern E: Authorization-preserving derivation

Every derived object—embedding, summary, community, inferred edge, cached answer—needs an effective policy derived from all inputs.

A safe default is policy intersection: the derived object is visible only if every supporting input required to reconstruct its meaning is visible. More permissive behavior must be explicitly justified and tested for information leakage.

Filtering only the final graph nodes is insufficient: edge counts, missing paths, rankings, embeddings, summaries, and inferred classifications can leak protected facts.

Pattern F: Controlled action boundary

A graph-derived recommendation is not execution authority. Before action:

• re-fetch mutable facts from authoritative sources;
• evaluate current policy and purpose;
• validate required evidence and confidence;
• require approval where necessary;
• apply idempotency and bounded parameters;
• record the action request, authorization decision, execution, and result as provenance.

Failure modes and counter-evidence

Failure mode	Consequence	Control
Treating an LLM-extracted graph as truth	Hallucinated relations and omitted qualifiers become authoritative	Keep extraction output as unverified claims; require evidence spans and validation
Destructive entity merges	Cross-customer or cross-person contamination, permission leakage, invalid recommendations	Reversible clusters, calibrated probabilities, abstention, review queues
Using owl:sameAs for fuzzy matches	Unbounded identity propagation	Use narrower match predicates and governed promotion
Last-write-wins facts	Loss of historical truth and inability to reconstruct decisions	Bitemporal claims, supersession, explicit retractions
Global enterprise ontology	Long governance cycles and brittle downstream coupling	Small core, bounded modules, versioned mappings and competency tests
Unbounded OWL reasoning	Latency spikes and unintuitive entailments	OWL RL/QL or bounded rules; offline materialization; proof limits
Applying authorization after retrieval	Protected content reaches embeddings, summaries, model prompts, or counts	Policy-aware ingestion, projection, traversal, ranking, generation, and caching
Summary-only grounding	Generated summaries recursively validate one another	Return to source spans for final evidence
Poisoned retrieval corpus	Attacker-chosen answers or tool behavior	Trust zones, quarantine, provenance, corroboration, injection tests, human gates
Stale graph communities	Old organizational structure or revoked facts continue to dominate retrieval	Incremental invalidation, dependency tracking, freshness SLOs
RDF-to-LPG lossy mapping	Lost qualifiers, blank-node structure, language tags, or provenance	Explicit mapping specification and round-trip conformance
Assuming GQL guarantees portability	Queries or behavior fail across engines	Supported-subset profile and cross-engine test suite
Fabric Graph schema changes	Full model recreation and reingestion	Treat it as a projection; preserve canonical model outside it
Self-hosted component assembly	HA, backups, auth, upgrades, and capacity become customer obligations	Reference deployment, tested operational runbooks, managed upgrade path
Cryptographic hash interpreted as truth	Tamper evidence is confused with epistemic validity	Separate integrity, authorship, source authority, and claim confidence

Counter-evidence to broad GraphRAG claims is substantial:

• Microsoft’s 2024 result addressed global sensemaking over corpora around one million tokens, not every enterprise retrieval workload.
• A 2025 systematic comparison found conventional RAG stronger on single-hop and detail, with GraphRAG stronger on multi-hop and diversity.
• HippoRAG 2 reports better benchmark performance, but its result remains sensitive to dataset, model, graph construction, and evaluation design.
• Microsoft’s GraphRAG repository now describes itself as largely in maintenance mode and explicitly not a supported product.
• Microsoft Fabric’s scale and portability statements are vendor claims; its own documentation acknowledges absent schema evolution and preview natural-language graph reasoning.
• Formal ontologies do not solve poor source data, incorrect identity resolution, missing stewardship, or authorization.

PoisonedRAG demonstrates that a small amount of adversarial content can dominate retrieval in a large corpus. Graph construction can amplify rather than eliminate this: poisoned entities and relationships may enter communities, summaries, path rankings, and derived recommendations. PoisonedRAG.

Implications for Dataheart

Vendor-neutral invariants versus profile choices

Concern	Vendor-neutral invariant	Microsoft-native choice	Self-hosted/open choice
Canonical representation	Stable IRIs/IDs, first-class claims, JSON-LD/RDF export, bitemporal fields	OneLake canonical tables and RDF/JSON-LD export artifacts	PostgreSQL/object storage plus RDF canonical log
Semantic contract	Versioned ontology modules, SHACL, competency queries	Customer-owned artifacts in Git/Azure DevOps; validation service on Azure	Git, Apache Jena/RDF4J validation and CI
Operational graph	Replaceable projection with mapping version	Fabric Graph LPG/GQL	Jena/RDF4J SPARQL; optional open LPG projection
Search	Query routing and evidence-return contract	Azure AI Search plus Fabric Graph	OpenSearch plus RDF text/vector extensions
Identity resolution	Reversible candidates, probability, evidence, review state	Fabric/Spark pipelines and Azure SQL history	Splink/PostgreSQL or equivalent open pipeline
Provenance	PROV-aligned activities and immutable evidence references	Purview lineage plus Dataheart claim-level provenance	OpenLineage plus Dataheart claim-level provenance
Identity and policy	Principal, purpose, tenant, policy version, decision trace	Entra ID and Fabric/OneLake controls plus application policy evaluator	Keycloak plus OPA/OpenFGA and query-policy enforcement
Reasoning	Bounded deterministic rules with proof traces	Dataheart reasoning service; do not assume Fabric Graph is an ontology reasoner	Jena/RDF4J rules or dedicated open reasoner
Temporal behavior	Valid time, recorded time, observed time, supersession	Azure SQL temporal storage or equivalent Fabric history structures	PostgreSQL temporal design/event log
Actions	Freshness check, authorization, approval, idempotency, audit	Azure Functions/Logic Apps/Power Platform adapters	Open workflow engine and customer-hosted adapters
Portability	Canonical exports, RDFC hashes, conformance suite, restore test	Export from OneLake and Fabric projections	Export from RDF/table/index stores

Resonansia’s proposed role

Resonansia should own:

• the identifier and namespace registry;
• versioned core and domain ontology modules;
• source-to-semantic mappings;
• claims, contradictions, confidence, temporal intervals, and provenance;
• entity-resolution candidates and decisions;
• policy labels and effective-policy derivation;
• RDF, LPG, search, and analytics projection specifications;
• canonical snapshot generation and hashing;
• conformance tests and competency queries;
• evidence-subgraph and proof-trace APIs.

It should not become:

• the authoritative source for mutable operational facts;
• the primary identity provider;
• the sole policy-decision point;
• an opaque LLM memory;
• an engine-specific database abstraction that prevents lossless export.

This is a hypothesis requiring experiments. Its value is architectural continuity across deployment profiles, not the novelty of another graph product.

Ontology-development operating model

Kugghuset’s forward deployed engineers should maintain a three-layer semantic model:

1. A small Dataheart core: entity, claim, evidence, activity, policy, time, recommendation, and action.
2. Reusable industry modules.
3. Customer-owned local modules and mappings.

Customer-specific terms should not silently enter the shared core. Promotion requires demonstrated reuse, semantic review, migration guidance, and cross-customer conformance tests.

Regulation

Where Dataheart participates in an EU high-risk AI system, the AI Act’s requirements for data governance, automatic logging, transparency, limitations, human oversight, and retention make claim-level provenance and reconstructable retrieval materially useful. The regulation does not mandate a knowledge graph, and graph provenance alone does not establish compliance. EU AI Act.

Connections to other domains

• Event sourcing and CQRS: the canonical claim log resembles an event-sourced write model; RDF, LPG, vector, and analytics stores are read projections.
• Software supply-chain security: mappings, ontologies, prompts, extraction models, and indexes need versioning, reproducible builds, dependency records, and integrity checks analogous to SBOM and provenance attestations.
• Master-data management: canonical entities are governed master records, while source records and probabilistic match candidates remain visible.
• Zero trust: every retrieval hop and derivation should be evaluated under principal, purpose, resource, and current policy rather than trusting a graph because it is internal.
• Scientific argumentation: support, contradiction, retraction, evidence quality, and uncertainty are closer to scholarly claim graphs than to conventional master-data triples.
• Digital twins: bitemporal claims and events distinguish observed state, modeled state, and predicted state.
• Compiler architecture: Resonansia’s semantic contract is an intermediate representation compiled into RDF, LPG, search, and UI projections. Conformance tests detect lossy compilation.
• Data contracts: SHACL shapes and competency queries extend structural data contracts into meaning, relationships, and acceptable inference.
• Safety cases: an action should carry an evidence argument showing which claims, policies, and approvals justified it.

Recommended experiments and conformance tests

1. Cross-profile semantic equivalenceIngest the same governed corpus into both deployment profiles. Export canonical RDF, normalize it with RDFC-1.0, and compare hashes after excluding explicitly volatile fields.

2. RDF–LPG round tripTest language tags, multi-valued properties, temporal qualifiers, contradictions, provenance, nested evidence, and authorization labels. Permit zero loss for identity, policy, time, and evidence.

3. Entity-resolution calibrationBuild labeled match/non-match sets. Measure precision, recall, calibration, abstention, subgroup performance, review load, and the downstream blast radius of false merges.

4. Temporal reconstructionInject late and backdated corrections. Verify queries over both valid time and recorded time, and prove that retracted facts no longer appear in current recommendations.

5. Retrieval workload benchmarkStratify questions into exact lookup, single-hop, multi-hop, global summary, temporal, contradiction, and policy-sensitive categories. Compare BM25, dense, graph, and hybrid routing using retrieval recall, answer faithfulness, citation precision, latency, indexing cost, and update cost.

6. Evidence completenessRequire every returned material claim to resolve to a source record/span, content digest, mapping or extraction activity, model/prompt version where applicable, identity-resolution decision, policy decision, and retrieval path.

7. Authorization non-interferenceRun identical queries as principals differing by one permission. Unauthorized nodes must not influence visible summaries, counts, rankings, embeddings, inferred relations, cache keys, or answer wording.

8. Poisoning and indirect prompt injectionReproduce a PoisonedRAG-style five-document injection and malicious-instruction documents. Measure attack success, quarantine effectiveness, cross-source corroboration, and whether contaminated summaries are invalidated.

9. Ontology evolutionExercise property rename, split, merge, cardinality change, and changed inference rule. Measure migration effort, dual-read duration, reingestion cost, and competency-query stability—especially Fabric Graph’s full-model recreation path.

10. Reasoner conformanceDefine an allowed OWL/rule subset. Test consistency, termination, maximum proof depth, authorization of every premise, and reproducibility between profiles.

11. Projection freshnessMeasure source-to-claim, claim-to-graph, claim-to-vector, and revocation-to-cache-invalidated latency separately.

12. Action safetyVerify that stale, contradicted, low-confidence, or newly unauthorized claims cannot trigger execution. Test approvals, parameter bounds, idempotency, compensation, and provenance.

13. Exit testRebuild the complete open profile from Microsoft-native exports and the Microsoft-native profile from open exports. Compare canonical hashes, entity-resolution decisions, policy labels, and competency-query results.

Sources

1. W3C, RDF 1.2 Concepts and Abstract Data Model, Candidate Recommendation Snapshot, 7 April 2026.
2. W3C, SPARQL 1.2 Query Language, Working Draft, 20 August 2026.
3. ISO, ISO/IEC 39075:2024 GQL, April 2024; Technical Corrigendum 1, July 2026.
4. W3C, Shapes Constraint Language—SHACL, Recommendation, 20 July 2017.
5. W3C, OWL 2 Profiles, Second Edition, Recommendation, 11 December 2012.
6. W3C, PROV-O: The PROV Ontology, Recommendation, 30 April 2013.
7. W3C, RDF Dataset Canonicalization—RDFC-1.0, Recommendation, 21 May 2024.
8. W3C/OGC, Time Ontology in OWL, Candidate Recommendation Draft, 15 November 2022.
9. Microsoft Research, From Local to Global: A Graph RAG Approach, April 2024; current project repository, accessed 23 August 2026.
10. Han et al., RAG vs. GraphRAG: A Systematic Evaluation and Key Insights, 17 February 2025.
11. Gutiérrez et al., From RAG to Memory: HippoRAG 2, 20 February 2025; ICML 2025.
12. Zou et al., PoisonedRAG, USENIX Security 2025, 13–15 August 2025.
13. Microsoft, Graph in Microsoft Fabric overview, 20 May 2026; architecture and schema-evolution limitations, 2 June 2026.
14. Apache Jena, SHACL implementation and Fuseki data access control, current documentation accessed 23 August 2026.
15. European Union, Regulation (EU) 2024/1689—the AI Act, Official Journal, 12 July 2024.