BuildingEquipment
Equipment installed in or serving a building.
ComparisonDimension
A criterion used to compare the two graph architectures.
EvidenceDocument
A source document that supports a validation decision.
GraphArchitecture
A graph-platform architecture participating in the comparison.
GraphLayer
A logical layer of the real-estate knowledge system.
HeatPump
A heat-pump asset used for building heating or cooling.
InvoiceLineItem
A named line item on an invoice.
PlatformCapability
A graph-platform capability demonstrated or described in the comparison.
RetrievalCandidate
A candidate ontology term selected by graph patterns and instance evidence.
RetrievalExecution
A provenance-bearing execution or reproducible result of a retrieval mode.
RetrievalMode
A defined method for retrieving or ranking knowledge-graph entities.
ValidationFinding
A named result produced by evaluating a validation rule.
ValidationRule
A deterministic constraint or graph rule evaluated against business evidence.
Shared building concept aligned across the real-estate and building-equipment domains.
Building
Building equipment that transfers heat for heating or cooling.
Heat pump
Commercial document requesting payment for supplied goods or services.
Invoice
Requirement grounded in an identified legal or regulatory source.
Legal requirement
Agreement defining covered maintenance and diagnostic services.
Service contract
Commitment covering qualifying equipment defects or services during a defined period.
Warranty
Invoice total should not exceed the contracted call-out ceiling.
Call-out ceiling shape
Covered diagnostic service must not be billed as a separate charge.
Covered-service billing shape
Supplier invoice identifiers should be unique.
Duplicate invoice identifier shape
evaluatesRule
Links a finding to its evaluated validation rule.
expectedAmount
Expected monetary amount derived from contract or line-item evidence.
findingStatus
Records Pass, Warning, or Fail for a validation finding.
focusNode
Identifies the primary business entity evaluated by a finding.
hasEvidence
Links a finding to the evidence that supports it.
implementsArchitecture
Associates an execution or component with its graph architecture.
inLayer
Associates an entity with one logical graph layer.
Invoice total must reconcile with line items and tax.
Invoice validation shape
matchedTerm
Connects a ranked result to the matched ontology term.
neo4jTreatment
Describes how the article's Neo4j implementation treats a comparison dimension.
observedAmount
Observed monetary amount supplied by the invoice.
Illustrative property portfolio used solely for the proof of concept.
Rhein Main demonstration property portfolio
semanticScore
Score contributed by RDF type and graph-pattern constraints.
supportsCapability
Connects an architecture to a demonstrated or source-described capability.
usesRetrievalMode
Associates an execution with its retrieval mode.
virtuosoTreatment
Describes how the Virtuoso proof of concept treats a comparison dimension.
Reusable OpenLink AI-agent skill used to generate, query, or present the RDF collection.
rdf-infographic-skill
OpenAI coding agent environment used with GPT-5 Chat to generate this collection.
Codex
Article author and knowledge-graph architect who presents the Neo4j-based layered real-estate proof of concept.
AI Manager; Knowledge Graph Architect
Irina Adamchic, PhD
Article-listed ontology source for legal document structure.
akomantoso
Akoma Ntoso (OASIS)
Executable
Executable standards-based SPARQL ASK proof over the companion Turtle graph.
ASK Arithmetic
SPARQL
PREFIX schema: <http://schema.org/> PREFIX : <https://www.linkedin.com/pulse/power-layered-knowledge-graphs-applied-real-estate-adamchic-phd-vv4df/#> ASK WHERE { :invoiceRE20260017 schema:totalPaymentDue 476.00 ; schema:tax 76.00 ; schema:hasPart :lineDiagnostic, :lineFilter, :lineTravel . :lineDiagnostic :observedAmount 120.00 . :lineFilter :observedAmount 180.00 . :lineTravel :observedAmount 100.00 . }
ASK Asset
PREFIX schema: <http://schema.org/> PREFIX : <https://www.linkedin.com/pulse/power-layered-knowledge-graphs-applied-real-estate-adamchic-phd-vv4df/#> ASK WHERE { VALUES ?document { :invoiceRE20260017 :installationRecord :warranty :serviceContract } ?document schema:about :heatPumpHPDE2048 . }
ASK CoveredDiagnostic violation
PREFIX schema: <http://schema.org/> PREFIX : <https://www.linkedin.com/pulse/power-layered-knowledge-graphs-applied-real-estate-adamchic-phd-vv4df/#> ASK WHERE { :invoiceRE20260017 schema:hasPart :lineDiagnostic . :lineDiagnostic :observedAmount ?amount . FILTER(?amount > 0) :serviceContract schema:about :heatPumpHPDE2048 . }
ASK Duplicate
PREFIX schema: <http://schema.org/> PREFIX : <https://www.linkedin.com/pulse/power-layered-knowledge-graphs-applied-real-estate-adamchic-phd-vv4df/#> ASK WHERE { :invoiceRE20260017 schema:identifier ?id ; schema:provider ?supplier . :priorInvoiceRE20260017 schema:identifier ?id ; schema:provider ?supplier . FILTER(:invoiceRE20260017 != :priorInvoiceRE20260017) }
ASK evidence path
PREFIX schema: <http://schema.org/> PREFIX : <https://www.linkedin.com/pulse/power-layered-knowledge-graphs-applied-real-estate-adamchic-phd-vv4df/#> ASK WHERE { :finding5 :focusNode :invoiceRE20260017 ; :hasEvidence :lineDiagnostic, :serviceContract ; :evaluatesRule :ruleCoveredDiagnostic . :lineDiagnostic schema:about :heatPumpHPDE2048 . :serviceContract schema:about :heatPumpHPDE2048 . }
ASK Supplier
PREFIX schema: <http://schema.org/> PREFIX : <https://www.linkedin.com/pulse/power-layered-knowledge-graphs-applied-real-estate-adamchic-phd-vv4df/#> ASK WHERE { :invoiceRE20260017 schema:provider ?supplier . :installationContract schema:provider ?supplier . :serviceContract schema:provider ?supplier . }
Article-listed ontology source for buildings, hvac, and equipment.
brick
Brick Schema
Call-out ceiling shape constraint
The proof of concept holds the real-estate evidence constant and contrasts the article's Neo4j design with an RDF-native Virtuoso implementation. The comparison concerns concrete architectures rather than claiming that every Neo4j deployment lacks semantic integrations.
One problem, two competing graph architectures
Covered-service billing shape constraint
Article-listed ontology source for project-specific types.
custom
Custom ontology
Property-graph query surface used by the article's implementation.
Cypher graph querying
Comparison of graph model across the two concrete implementations.
Graph model
Linked Property Graph with labeled nodes and relationships.
RDF quad model with IRI-identified subjects, predicates, objects, and optional graph names.
Comparison of entity identity across the two concrete implementations.
Entity identity
Internal graph identifiers and URI properties support identity within the property graph.
HTTP IRIs are native identifiers for entities and predicates and can be dereferenced through a Linked Data resolver.
Comparison of inference across the two concrete implementations.
Inference
Additional semantic inference depends on modeling conventions, application logic, or added integrations.
RDFS/OWL axioms can entail additional facts while remaining visible and queryable as graph semantics.
Comparison of layer representation across the two concrete implementations.
Layer representation
Neo4j labels and architectural conventions identify OntologyLayer, LegalLayer, ContractsLayer, InvoiceLayer, and RulesLayer.
Named layer resources and inLayer predicates make layer membership queryable while retaining shared entity identity.
Comparison of portability across the two concrete implementations.
Portability
Graph Builder, APOC, Neo4j vector indexes, and Cypher are Neo4j-specific implementation choices.
RDF, RDFS, OWL, SHACL, SPARQL, and HTTP IRIs are standards-based and portable across conforming systems.
Comparison of provenance across the two concrete implementations.
Provenance
Application-specific properties and traversal history can record lineage.
PROV-O activities and named evidence relationships connect every result to its sources and generating mode.
Comparison of pure sparql proof across the two concrete implementations.
Pure SPARQL proof
The article uses a Neo4j vector index to pre-filter OntologyLayer nodes.
The RDF proof of concept demonstrates the same business scenario with standards-based SPARQL 1.1 patterns and no vector-function dependency.
Comparison of query surface across the two concrete implementations.
Query surface
Cypher plus Neo4j procedures and indexes.
Pure SPARQL graph patterns over ontology instances, layers, rules, evidence, and findings.
Comparison of rules and validation across the two concrete implementations.
Rules and validation
RulesLayer and application/agent traversal evaluate business conditions.
Named RDF rules, SHACL constraints, SPARQL ASK checks, and provenance-bearing findings.
Comparison of domain schema across the two concrete implementations.
Domain schema
Fixed Entity Architecture projects ontology concepts into LPG labels and properties.
RDF/OWL ontology terms remain native graph resources with domains, ranges, hierarchy, and dereferenceable identifiers.
Duplicate invoice identifier shape constraint
Article-listed ontology source for finance and legal-business concepts.
fibo
FIBO (EDM Council)
Line items sum to EUR 400.00; tax is EUR 76.00; total due is EUR 476.00.
PASS: Invoice arithmetic rule
PASS
The invoice provider matches the contractor identified by the installation and service contracts.
PASS: Supplier identity rule
The invoice, installation record, warranty, and service contract all concern heat pump HP-DE-2048.
PASS: Equipment identity rule
The invoice date falls within the illustrative warranty validity period.
PASS: Warranty-period rule
The diagnostic line is billed even though the annual service contract says that diagnostic visit is covered.
FAIL: Covered-service billing rule
FAIL
A prior invoice record uses the same supplier invoice identifier.
WARNING: Duplicate invoice identifier rule
WARNING
The total invoice amount of EUR 476.00 exceeds the illustrative EUR 450.00 call-out ceiling.
WARNING: Service call-out ceiling rule
The invoice includes an explicit tax amount and the legal evidence node is connected to the rule.
PASS: Tax evidence rule
Source pattern that projects selected ontology concepts into a stable Linked Property Graph entity layer.
Fixed Entity Architecture
Invoice validation shape constraint
RDF-grounded retrieval that answers from the generated ontology instances, graph structure, rules, and local evidence without vector or full-text functions.
data-twingler KG-only mode
Article-listed ontology source for legal concepts.
lkif-core
LKIF-Core
Source mechanism used to find the top-k ontology-layer nodes for a document chunk.
Neo4j vector index
Article-listed ontology source for procure-to-pay and invoices.
p2p-o
P2P-O (DFKI)
Named provenance links from retrieval and validation results back to evidence and execution activities.
PROV-O evidence lineage
Shows the failed covered-service path from finding to invoice, billed diagnostic line, service contract, and rule using pure SPARQL.
Pure SPARQL covered-service evidence path
PREFIX schema: <http://schema.org/> PREFIX : <https://www.linkedin.com/pulse/power-layered-knowledge-graphs-applied-real-estate-adamchic-phd-vv4df/#> SELECT ?finding ?invoice ?lineItem ?lineName ?lineAmount ?serviceContract ?contractText ?rule FROM <https://linkeddata.uriburner.com/DAV/demos/daas/power-layered-knowledge-graphs-real-estate-neo4j-virtuoso-gpt5-chat-1.ttl> WHERE { ?finding :evaluatesRule :ruleCoveredDiagnostic ; :focusNode ?invoice ; :hasEvidence ?lineItem, ?serviceContract ; :evaluatesRule ?rule . ?invoice a schema:Invoice ; schema:hasPart ?lineItem . ?lineItem a :InvoiceLineItem ; schema:name ?lineName ; :observedAmount ?lineAmount . ?serviceContract schema:about :heatPumpHPDE2048 ; schema:description ?contractText . FILTER(?lineAmount > 0) } ORDER BY ?finding ?lineItem
Retrieves the proof-of-concept invoice instance, line items, amounts, asset, supplier, tax, and total without vector or full-text functions.
Pure SPARQL invoice instance details
PREFIX schema: <http://schema.org/> PREFIX : <https://www.linkedin.com/pulse/power-layered-knowledge-graphs-applied-real-estate-adamchic-phd-vv4df/#> SELECT ?invoice ?invoiceName ?lineItem ?lineName ?lineAmount ?tax ?total ?asset ?supplier FROM <https://linkeddata.uriburner.com/DAV/demos/daas/power-layered-knowledge-graphs-real-estate-neo4j-virtuoso-gpt5-chat-1.ttl> WHERE { ?invoice a schema:Invoice ; schema:name ?invoiceName ; schema:hasPart ?lineItem ; schema:about ?asset ; schema:provider ?supplier ; schema:tax ?tax ; schema:totalPaymentDue ?total . ?lineItem a :InvoiceLineItem ; schema:name ?lineName ; :observedAmount ?lineAmount . } ORDER BY ?invoice ?lineName
Lists each generated GraphLayer and its ontology, evidence, invoice, and rule members using only SPARQL graph patterns.
Pure SPARQL layer inventory
PREFIX schema: <http://schema.org/> PREFIX : <https://www.linkedin.com/pulse/power-layered-knowledge-graphs-applied-real-estate-adamchic-phd-vv4df/#> SELECT ?layer ?layerName ?member ?memberName ?memberType FROM <https://linkeddata.uriburner.com/DAV/demos/daas/power-layered-knowledge-graphs-real-estate-neo4j-virtuoso-gpt5-chat-1.ttl> WHERE { ?layer a :GraphLayer ; schema:name ?layerName ; schema:hasPart ?member . OPTIONAL { ?member schema:name ?memberName . } OPTIONAL { ?member a ?memberType . } } ORDER BY ?layerName ?memberName ?member
Returns the named validation findings, statuses, evaluated rules, focus node, and evidence resources using ordinary SPARQL.
Pure SPARQL validation findings
PREFIX schema: <http://schema.org/> PREFIX : <https://www.linkedin.com/pulse/power-layered-knowledge-graphs-applied-real-estate-adamchic-phd-vv4df/#> SELECT ?finding ?findingName ?status ?rule ?ruleName ?focusNode ?evidence ?evidenceName FROM <https://linkeddata.uriburner.com/DAV/demos/daas/power-layered-knowledge-graphs-real-estate-neo4j-virtuoso-gpt5-chat-1.ttl> WHERE { ?finding a :ValidationFinding ; schema:name ?findingName ; :findingStatus ?status ; :evaluatesRule ?rule ; :focusNode ?focusNode ; :hasEvidence ?evidence . OPTIONAL { ?rule schema:name ?ruleName . } OPTIONAL { ?evidence schema:name ?evidenceName . } } ORDER BY ?status ?findingName ?evidenceName
Virtuoso design capability in which entities and predicates are identified natively by HTTP IRIs.
RDF HTTP IRI identity
Derivation of additional facts from explicit RDFS/OWL axioms and graph semantics.
RDF inference
Article-listed ontology source for buildings and real estate.
rec
RealEstateCore
Standards-based RDF and SPARQL checks are executed locally. The proof of concept intentionally excludes SPARQL queries that depend on vector functions so the showcase is portable across SPARQL 1.1 processors.
Executed pure SPARQL evidence
The article's Cypher vector query is preserved as source evidence. The Virtuoso/RDF proof of concept uses pure SPARQL graph patterns over generated ontology instances, invoice evidence, layer membership, rules, and validation findings.
Schema selection: vector GraphRAG versus pure SPARQL
Source query
Cypher query reproduced from the LinkedIn article for top-k vector retrieval over OntologyLayer nodes.
Source Neo4j GraphRAG ontology pre-filter
Cypher
CALL db.index.vector.queryNodes($index_name, $k, $embedding) YIELD node AS vectorNode, score AS vectorScore WITH vectorNode, vectorScore WHERE vectorNode:OntologyLayer AND vectorNode.name IS NOT NULL RETURN vectorNode.name AS name, coalesce(vectorNode.uri, '') AS uri, coalesce(vectorNode.kind, 'class') AS kind, coalesce(vectorNode.ontologies, []) AS ontologies, vectorScore AS score ORDER BY vectorScore DESC
The article presents a Neo4j Community Edition proof of concept in which a Fixed Entity Architecture imports selected ontology concepts into a Linked Property Graph, organizes evidence into five layers, and uses vector-based GraphRAG to pre-filter ontology terms before document extraction.
What the source article builds
Standards-based query surface for graph patterns, named graphs, provenance, and federation.
SPARQL graph querying
Connected subgraph that explains how a finding follows from business documents, assets, rules, and provenance.
Evidence path
The source author's pattern for a stable entity layer that projects selected ontology concepts into a property graph.
Retrieval-augmented generation that uses graph structure or graph retrieval as part of context selection.
GraphRAG
Derivation of additional RDF statements from explicit axioms and entailment rules.
Resolution from local RDF graph evidence and semantics without endpoint corroboration.
KG-only retrieval
Property-graph model using labeled nodes, relationships, and properties, with explicit links between entities.
Linked Property Graph
RDF graph identified by an IRI so statements can be grouped, queried, and attributed.
Named graph
Layer containing stable domain terms used to guide extraction and connect other layers.
OntologyLayer
Information identifying the origin, transformation, evidence, and responsible activity behind a graph assertion or result.
A proof path that uses standards-based SPARQL graph patterns over RDF instances without full-text or vector-function extensions.
W3C graph data model using IRI-identified subjects, predicates, and objects.
Resource Description Framework
RDF vocabulary for expressing and reporting graph-shape constraints.
Shapes Constraint Language
Deterministic RDF graph-pattern query selecting the ontology slice required for the heat-pump invoice scenario.
Virtuoso KG-only ontology-slice query
PREFIX schema: <http://schema.org/> PREFIX : <https://www.linkedin.com/pulse/power-layered-knowledge-graphs-applied-real-estate-adamchic-phd-vv4df/#> SELECT ?term ?name ?sourceOntology FROM <https://linkeddata.uriburner.com/DAV/demos/daas/power-layered-knowledge-graphs-real-estate-neo4j-virtuoso-gpt5-chat-1.ttl> WHERE { ?term :inLayer :ontologyLayer ; schema:name ?name . OPTIONAL { ?sourceOntology schema:hasPart ?term } VALUES ?term { :heatPumpConcept :invoiceConcept :serviceContractConcept :warrantyConcept :legalRequirementConcept } } ORDER BY ?name
Graph database used by the source article's proof of concept.
Neo4j
data-twingler skill
kg-generator skill
Answer 1
A smart layered graph can serve as a reusable knowledgebase foundation for multiple real-estate and agentic use cases rather than solving only one retrieval problem.
Answer 10
The matching identifier is suspicious evidence requiring review, but the small illustrative graph does not establish whether the earlier record was canceled, corrected, or legitimately reissued.
Answer 11
No. Legal nodes are illustrative evidence used to demonstrate graph linkage and validation mechanics, not a complete or authoritative statement of German law.
Answer 12
No. It compares the article's concrete LPG projection with the RDF-native Virtuoso proof of concept and acknowledges that Neo4j can be extended or integrated with semantic tooling.
Answer 13
Each named finding records its rule, focus node, status, explanation, and direct links to the invoice, contract, asset, or legal evidence supporting it.
Answer 14
Entities retain one stable IRI while explicit inLayer relations and cross-layer evidence links make their logical placement and reuse queryable.
Answer 2
It projects selected ontology concepts into a stable Neo4j entity layer so later document extraction can attach to a controlled domain schema.
Answer 3
Virtuoso is an RDF quad-store and multi-model database that can provide graph storage, query, inference-oriented semantics, provenance, and federation through SPARQL.
Answer 4
KG-only resolves answers from RDF graph structure, semantics, rules, and local evidence without depending on a live endpoint or vector retrieval.
Answer 5
This edition isolates the RDF proof of concept: every workbench query is pure SPARQL over generated ontology instances, rules, findings, and evidence paths.
Answer 6
No. The proof-of-concept queries use standards-based SPARQL 1.1 graph patterns. Virtuoso remains the RDF-native target, but this workbench avoids vector-specific functions.
Answer 7
Yes. The Turtle parse, standards-based SPARQL ASK validations, inference checks, graph-data extraction, HTML validation, and browser interaction checks are executed locally.
Answer 8
The Turtle parse, six SPARQL ASK validations, inference checks, graph-data extraction, HTML validation, and browser interaction checks are executed locally.
Answer 9
It finds that a diagnostic line was billed even though the illustrative annual service contract identifies that diagnostic visit as covered.
Illustrative contract identifying the installed asset, supplier, and agreed work.
Heat-pump installation contract
Illustrative installation evidence connecting the building, equipment serial number, contractor, and installation date.
Installation record for HP-DE-2048
Illustrative prior record sharing the same supplier invoice identifier and triggering a duplicate warning.
Prior invoice record RE-2026-0017
Illustrative multi-unit property containing the heat-pump asset.
Lindenhof Property
Equipment identity rule
Supplier identity rule
Tax evidence rule
Warranty-period rule
Parse the Turtle document or load it into Virtuoso under the documented graph IRI.
Load the companion Turtle graph
Query the named GraphLayer resources and their members before evaluating the business scenario.
Inspect the five source layers
Execute the deterministic SPARQL graph-pattern query to retrieve the ontology slice required by the invoice scenario.
Run KG-only semantic selection
Execute the arithmetic, supplier, asset, covered-service, duplicate-identifier, and evidence-path ASK queries.
Run the validation ASK queries
Execute the layer inventory, invoice instance, validation findings, covered-service path, and ASK proof queries.
Run the pure SPARQL workbench queries
Compare returned entities, inferred facts, rule results, provenance paths, and portability while labeling measured and unmeasured claims separately.
Compare evidence rather than slogans
Illustrative rule requiring an explicit tax amount and rate in the invoice evidence used by the proof of concept.
Invoice tax evidence requirement
Building served by heat pump HP-DE-2048.
Lindenhof Building A
Proof-of-concept legal evidence record. It demonstrates source linkage and does not claim to be a complete statement of German law or legal advice.
Illustrative German invoice and tax evidence record
Legal documents, chunks, obligations, authorities, and regulatory evidence.
LegalLayer
Billable material outside diagnostic coverage
Replacement filter
Billable call-out component
Technician travel
What is the article's central architectural claim?
Why is the duplicate invoice only a warning?
Does this collection provide legal advice?
Does the comparison claim every Neo4j system lacks semantics?
What makes an RDF finding auditable?
How does the graph remain layered without duplicating entities?
What does Fixed Entity Architecture do in the source implementation?
Why is Virtuoso treated as a head-on competitor?
What is KG-only mode in this collection?
Why remove vector-function SPARQL from this edition?
Does the proof require Virtuoso vector functions?
Was the pure SPARQL proof executed during generation?
Which parts were executed?
What invoice defect does the proof of concept find?
Invoice arithmetic rule
Service call-out ceiling rule
Covered-service billing rule
Duplicate invoice identifier rule
Illustrative warranty active from installation through 2027-09-14 and covering qualifying diagnostic work.
Heat-pump warranty
Covered by the annual service contract
Diagnostic inspection
Power of Layered Knowledge Graphs Applied to Real Estate Management: GraphRAG Re-born
Installation, warranty, and service-contract evidence.
ContractsLayer
Illustrative service agreement covering one diagnostic visit per contract year and imposing a EUR 450 call-out ceiling.
Annual heat-pump service contract
Illustrative contractor named consistently across installation, contract, service, and invoice evidence.
ThermoHaus Service
Invoices, line items, tax, totals, and supplier evidence.
InvoiceLayer
A representative invoice is checked against installation data, equipment identity, warranty coverage, a service contract, contractor identity, arithmetic, tax, supporting evidence, and a call-out price ceiling.
Heat-pump invoice validation proof of concept
Six-step procedure for loading, querying, validating, and inspecting the pure SPARQL proof of concept.
How to reproduce the Neo4j-versus-Virtuoso comparison
One invoice-validation problem is modeled through the article's Neo4j property-graph design and through Virtuoso's RDF-native semantics, inference, provenance, and standards-based SPARQL query surface.
The comparison holds the real-estate evidence constant while changing the graph platform. Neo4j uses Fixed Entity Architecture, labels, vector indexes, Graph Builder, and Cypher. Virtuoso uses RDF IRIs, ontology axioms, graph patterns, inference, provenance, and pure SPARQL over generated ontology instances.
Source-grounded notes about Irina Adamchic's article, paired with an executable RDF proof of concept that compares Neo4j GraphRAG with a pure SPARQL Virtuoso/RDF showcase.
Notes on Layered Real-Estate Knowledge Graphs: Neo4j and Virtuoso
Installed heat-pump asset referenced by the contract, warranty, service record, and invoice.
Heat pump HP-DE-2048
HP-DE-2048
Multi-model database and RDF quad store used by the RDF-based competing design.
OpenLink Virtuoso
Terms used across the Neo4j and Virtuoso implementations.
Layered graph comparison glossary
Named code resources preserve the source Cypher and provide RDF, SPARQL, and Virtuoso query recipes for reproducing the comparison.
Reproducible query and validation recipes
Source-described architecture using Neo4j Community Edition, Fixed Entity Architecture, labeled layers, Graph Builder, vector indexes, Cypher, APOC, and Neo4j MCP.
Neo4j Linked Property Graph architecture
Questions covering the article, the controlled comparison, and the limits of the proof of concept.
Frequently asked questions
RDF-native competitor architecture using HTTP IRIs, RDF/OWL semantics, SPARQL, provenance, and inference-oriented graph patterns.
Virtuoso RDF knowledge-graph architecture
Illustrative heat-pump service invoice evaluated by every proof-of-concept rule.
Invoice RE-2026-0017
Stable domain vocabulary and imported ontology concepts.
Deterministic validation rules and named findings.
RulesLayer
Layered Real-Estate Graph Comparison Ontology
Lightweight ontology for comparing Neo4j and Virtuoso implementations and for executing the heat-pump invoice validation proof of concept.
Defines architecture, layer, retrieval, rule, evidence, and validation concepts used by the proof of concept.