A five-layer Fixed Entity Architecture on Neo4j -- and what the same architecture looks like RDF-native on Virtuoso.
An architecture piece proposing a five-layer 'Fixed Entity Architecture' on a Linked Property Graph (Neo4j) for real-estate management, demonstrated via a proof of concept that consolidates seven RDF/OWL ontologies and uses GraphRAG vector pre-filtering for ontology-schema selection.
I'm also building an Agentic Graph RAG using Neo4j ... building a KG from LLMs over large volumes of data can become very expensive, so we may need to approach that differently.
This is great. If you'd like to learn about what we're doing at Brickgraph to bring knowledge graphs to real estate asset managers, I'd be happy to show you anytime!
I really enjoyed reading this article because it looks at GraphRAG from a different perspective ... keeping the ontology consistent, handling schema changes, avoiding duplicate entities, and maintaining the graph as business rules evolve seem like equally difficult problems.
The named framework the article proposes: a strictly layered graph architecture whose layers separate the context and business logic of the final solution, so one graph can solve many problems instead of one.
Consolidates open RDF/OWL domain ontologies (plus one custom, project-specific ontology) into a shared semantic backbone that every other layer attaches to.
Represents parsed legal and regulatory documents (civil code, tax regulations, construction-service award/contract regulations) as chunked, entity-linked graph structures anchored to the OntologyLayer.
Represents lease, service, and warranty contracts as structured graph entities cross-referenced with legal and invoice data.
Represents contractor invoices and operating-cost data, enabling automated validation against contracts and legal limits.
Encodes automated checks -- for example invoice-validity rules -- that operate across the Legal, Contracts, and Invoice layers.
The proof of concept as the article's author actually built it: a Linked Property Graph on Neo4j that mimics RDF-world ontology semantics via a 'Fixed Entity Layer', with GraphRAG vector search used to pre-filter which ontology schema entities to pass into document parsing.
The POC's starting use case: automated validation of heat pump invoices against installation data, warranty, service contract, and local legal/regulatory requirements.
A connected digital representation of an entire real-estate portfolio -- properties, units, tenants, leases, rental payments, operating costs, loans, insurance, contractors, invoices, maintenance, building components, energy consumption, modernization projects, tax information, legal requirements, deadlines, documents, and market data -- built on Neo4j Community Edition.
An agent-authored proof-of-concept counterpart demonstrating the identical five-layer real-estate architecture implemented RDF-natively on Virtuoso -- OpenLink's RDF-based DBMS and a direct competitor to Neo4j -- using genuine owl:imports of the same seven ontologies, SHACL for the RulesLayer, and a single hybrid full-text+vector SPARQL query (Virtuoso's kg-hybrid mode) in place of the source's separate Cypher vector-index call plus external embedding pipeline.
The source bolts together a Cypher vector-index call, a separate Ollama embedding service, and Python glue code. The RDF-native counterpart expresses the same pre-filter as a single SPARQL query using Virtuoso's built-in hybrid full-text+vector search (kg-hybrid mode).
The source reconciles the shared 'Building' node between brick and rec manually, by ingestion convention. RDF handles this natively via owl:equivalentClass/owl:sameAs reasoning across imported ontologies.
The source encodes invoice-checking rules as bespoke Cypher logic in the RulesLayer. The RDF-native counterpart expresses the same checks as SHACL shapes, a W3C standard validation vocabulary that is portable across any conformant RDF store.
The source runs on Neo4j Community Edition (WSL/Docker, local). The RDF-native counterpart targets Virtuoso, a head-to-head RDF-based competitor to Neo4j in the graph-database space, offering SPARQL, full-text, and vector search in one engine.
The same real-estate portfolio knowledgebase as the Neo4j POC, reimplemented as RDF named graphs on Virtuoso: one named graph per layer, real OWL ontology imports instead of LPG node-tagging, SHACL shapes instead of ad hoc Cypher rule logic, and a single hybrid SPARQL query for schema pre-filtering instead of a bolted-on vector-index pipeline.
The source explicitly avoids the word 'ontology' in the LPG world and mimics it via a hand-rolled 'Fixed Entity Layer'. The RDF-native counterpart needs no mimicry: BRICK, RealEstateCore, FIBO, LKIF-Core, and P2P-O are already OWL ontologies and load via owl:imports.
Five concrete points of contrast between the source's Neo4j/LPG proof of concept and its RDF-native (Virtuoso) counterpart -- ontology semantics, cross-ontology entity alignment, the schema pre-filtering query mechanism, the rule/validation mechanism, and platform.
A graph architecture, proposed by Irina Adamchic, that mimics RDF-world ontology semantics inside a Linked Property Graph (Neo4j) via a 'Fixed Entity Layer', avoiding the word 'ontology' for the LPG layer itself while still importing real open-source RDF ontologies.
Automated heat-pump invoice validation against installation data, warranty, service contract, and local legal/regulatory requirements.
An agent-authored counterpart implementing the identical five-layer architecture on Virtuoso -- an RDF-based DBMS and direct competitor to Neo4j -- using real owl:imports of the same seven ontologies (which are already native OWL vocabularies) instead of LPG mimicry, and SHACL instead of bespoke Cypher rules.
The source pipeline needs a separate Cypher vector-index call plus an external Ollama embedding service. Virtuoso's kg-hybrid mode fuses full-text and vector search directly into a single SPARQL query against the OntologyLayer named graph, removing the need for that separate pipeline.
A standards-native mechanism for declaring which ontologies a graph depends on, with reasoning support (e.g. owl:equivalentClass/owl:sameAs across BRICK and RealEstateCore's shared 'Building' concept) -- versus the source's manual convention of sharing nodes by name.
The author states Part 2 will show more insights into how the interconnected Legal, Invoice, and Ontology layers let agents check invoice validity end-to-end.
Partially. It targets the correct DAV named graph and searches over six real classes fetched from the live Brick and RealEstateCore ontology files at generation time (verified, not fabricated), so it should return real rows for a full-text match. It omits the bif:score() vector-ranking clause, since that requires validation against a live Virtuoso instance to get right. P2P-O's invoice classes are referenced via owl:imports only -- its canonical module endpoint (purl.org/p2p-o/invoice) was unreachable (404) at generation time, so no invoice class labels are inlined.
Because a property-graph node/edge structure that mimics ontology semantics is not a true RDF/OWL ontology with formal reasoning; the author calls it a Fixed Entity Layer instead, reserving 'ontology' for the genuine RDF-based vocabularies it ingests.
OntologyLayer, LegalLayer, ContractsLayer, InvoiceLayer, and RulesLayer, each separating one context/business-logic concern of the real-estate knowledgebase.
Real estate is a very large market, generates significant revenue, and -- unlike finance or pharma -- is not yet a domain where AI is well established, making it a good illustration of a graph solving multi-dimensional problems at once.
The author repurposes GraphRAG away from classical chatbot-style retrieval and uses it instead as a pre-filtering mechanism that selects the most relevant OntologyLayer entities before a document is parsed into the graph.
Embeddings from ontology URI plus description are indexed with a Neo4j vector index; a top-k vector query returns the most relevant OntologyLayer nodes for a given text chunk, and only those allowed nodes/edges are passed to Neo4j Graph Builder.
RealEstateCore, Brick Schema, FIBO (EDM Council), LKIF-Core, Akoma Ntoso (OASIS), and P2P-O (DFKI), plus one custom, project-specific ontology -- seven ontologies in total, per Table 1 of the source article.
After ingesting and consolidating all seven ontologies, the OntologyLayer contains 2,737 entities and even more edges.
Neo4j Community Edition with the APOC plugin, hosted in WSL-based Ubuntu under Docker; Neo4j MCP for graph querying; Neo4j Graph Builder for PDF parsing; Cursor IDE for ETL pipeline authoring; a locally hosted Ollama service with the nomic-embed-text embedding model; and NVIDIA NIM models (nemotron-parse for OCR, llama-3.3-nemotron-super-49b-v1.5 as the LLM).
The layer holding lease, service, and warranty contract data.
A layered Linked Property Graph architecture that mimics RDF-world ontology semantics via a Fixed Entity Layer, proposed by Irina Adamchic as a reusable knowledgebase foundation for multiple AI workflows at once.
Retrieval-augmented generation that uses a knowledge graph rather than (or alongside) a vector database; re-purposed in this article as an ontology-schema pre-filtering mechanism rather than chatbot-style retrieval.
The layer holding contractor invoices and operating-cost data.
A query mode (as used by the data-twingler skill against Virtuoso) that fuses full-text and vector search directly into a single SPARQL query, contrasted in this article's RDF-native counterpart with the source's separate Cypher-plus-embedding-service pipeline.
A property-graph data model (as implemented by Neo4j) where nodes and edges carry key/value properties, contrasted in this article with RDF's triple-based model.
The layer holding parsed legal and regulatory documents, entity-linked against the OntologyLayer.
NVIDIA Inference Microservices -- GPU-optimized Docker containers that serve open-source foundation models with low latency via build.nvidia.com.
The layer consolidating open-source and custom domain ontologies into a shared semantic backbone.
The layer encoding automated cross-layer checks such as invoice-validity rules.
A numeric representation of text or graph content enabling similarity search; used here on OntologyLayer node/edge URIs plus descriptions for pre-filtering.
The Shapes Constraint Language -- a W3C standard for validating RDF graphs against a set of conditions; used in the RDF-native counterpart's RulesLayer.
Ingest the six open-source ontologies (RealEstateCore, Brick Schema, FIBO, LKIF-Core, Akoma Ntoso, P2P-O) plus one custom ontology into a shared semantic backbone, connecting shared entities such as Building across ontologies.
Parse legal/regulatory documents (civil code, tax regulations, construction-service regulations) into Document/Chunk/entity structures anchored to the OntologyLayer schema.
Parse lease, service, and warranty contracts into the ContractsLayer and contractor invoices into the InvoiceLayer, cross-linked to the LegalLayer.
Encode automated checks -- for example invoice-validity rules -- that read across the Legal, Contracts, and Invoice layers.
Before passing allowed nodes/edges to the document parser, pre-filter the OntologyLayer to its top-k most relevant entities for the current document chunk, using vector (or hybrid full-text+vector) search.
Run the automated heat-pump invoice validation use case against installation data, warranty, service contract, and legal/regulatory requirements, using the interconnected layers.
This knowledge graph overview was generated by querying the URIBurner SPARQL endpoint for the named graph https://linkeddata.uriburner.com/DAV/demos/daas/layered-kg-real-estate-adamchic-claude_sonnet_5-1.ttl. The original document was transformed into RDF using kg-generator, rdf-infographic-skill, then uploaded to the Virtuoso-based URIBurner server. The HTML infographic was then rendered using kg-generator, rdf-infographic-skill, powered by Claude Sonnet 5, and running on Virtuoso.
Technology Stack:
Interactive graph visualization derived from the companion RDF. Click nodes to resolve, drag to explore. Graph data embedded from companion RDF at generation time.
Sample queries for this proof of concept, plus a free-form editor. Use the default endpoint or copy queries to your own SPARQL client.
Reproduced verbatim from the companion RDF. Execute loads the query into the workbench below and runs it live.
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX bif: <bif:>
SELECT ?class ?label ?ontology
WHERE {
GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/layered-kg-real-estate-adamchic-claude_sonnet_5-1.ttl> {
?class a owl:Class ;
rdfs:label ?label ;
rdfs:isDefinedBy ?ontology .
?label bif:contains "'pump' OR 'heating' OR 'building'" .
}
}
ORDER BY ?label
LIMIT 10Agent-authored illustration of the ontology-schema pre-filtering step as one hybrid full-text SPARQL query using Virtuoso's kg-hybrid query mode, in place of the source's separate Cypher vector-index call plus external Ollama embedding pipeline. The GRAPH IRI and search terms are real and match the six verified schema:hasPart classes actually loaded into this OntologyLayer instance below (fetched from the live Brick and RealEstateCore ontology files at generation time, not fabricated) -- so this SELECT should return real rows once uploaded to that DAV path. It omits bif:score()-based vector ranking, which requires a live Virtuoso instance to validate; add ORDER BY bif:score(?label) once confirmed against a running deployment. It is not a literal vector/embedding-similarity query -- Virtuoso's kg-hybrid mode additionally supports vector distance functions over an embedding column, which would need real embeddings computed and loaded, a step this document does not perform.
PREFIX schema: <http://schema.org/>
PREFIX : <https://www.linkedin.com/pulse/power-layered-knowledge-graphs-applied-real-estate-adamchic-phd-vv4df/#>
SELECT ?invoice ?equipment ?building ?contract ?legislation
WHERE {
GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/layered-kg-real-estate-adamchic-claude_sonnet_5-1.ttl> {
?invoice a schema:Invoice ;
schema:about ?equipment ;
:checkedAgainst ?contract, ?legislation .
?equipment schema:location ?building .
FILTER(?contract != ?legislation)
}
}Fully executable once uploaded -- unlike the hybrid pre-filter query above, this one uses no bif: functions, only plain SPARQL joins across the illustrative sample instances (sampleInvoice, sampleHeatPump, sampleBuilding, sampleServiceContract, sampleLegislation) declared in this same document. Demonstrates the source article's own use case -- checking an invoice's equipment, building, contract, and applicable legislation in one query -- expressed RDF-natively.