Property Graphs and the RDF Bridge: Neo4j, Cypher and ISO GQL

“RDF or property graph?” is the most frequently asked and worst framed question in this field. It is asked as though you were choosing a religion, when in production it is closer to choosing between a design language and a runtime. Most serious knowledge graph programmes end up using both: RDF, OWL and SHACL to define, govern and validate what the data means, and a labelled property graph engine to serve traversals, run graph algorithms and feed retrieval pipelines at low latency. This lesson gives you the property graph model properly, Cypher and the new ISO GQL standard, an honest decision table you can take into an architecture review, and the interop patterns that make the two worlds one pipeline instead of two silos.

The labelled property graph model

A labelled property graph (LPG) has four moving parts. Nodes carry zero or more labels (Person, Company, Aircraft) which act as loose types. Nodes carry properties, key-value pairs held directly on the node. Relationships are first class objects: directed, exactly one type each, and never dangling. And relationships carry properties of their own, which is the single feature that seduces developers away from triples. Saying that Alice worked for Acme from 2019 at a salary band of 3 is one edge with two properties in an LPG. In plain RDF the same statement needs reification or an intermediate Employment node, because a triple has exactly three slots and no room for the metadata.

The costs are equally structural. Identifiers in an LPG are engine-local integers or strings, not IRIs, so two graphs built by two teams do not merge by construction the way two RDF graphs do. There is no built-in global vocabulary, so a label named Customer in one database and Customer in another carry no shared definition. Schema is optional and historically was enforced only by convention or application code, which is exactly why the ecosystem has spent the last few years adding constraints, type systems and, in GQL, an actual graph type facility. And there is no standard inference: an LPG engine will not tell you that every Aircraft is a MannedVehicle unless you wrote a query or a rule that says so. RDF trades developer ergonomics for merge semantics, global naming and a logic; LPG trades those for speed of build, edge attributes and traversal performance. That is the whole argument, stripped of tribal signalling.

Cypher, and now GQL

Cypher is the pattern language that made property graphs approachable. Its central idea is ASCII art: you draw the pattern you want and the engine finds it. A query reading MATCH (p:Person)-[r:WORKS_FOR]->(c:Company) WHERE r.since < 2020 RETURN c.name, count(p) is legible to an analyst who has never seen a graph database, and that legibility is most of why Neo4j won the developer mindshare battle. Cypher was opened up as openCypher and reimplemented by other engines, which is how a vendor language became a de facto standard before it became a real one.

It became a real one in April 2024, when ISO/IEC published GQL, ISO/IEC 39075:2024: the first entirely new ISO database language standard in over 35 years, the previous one being SQL. That fact deserves more weight than it usually gets. It means property graphs are no longer a vendor category; they are a standardised data model with a standardised declarative query language, a conformance target, and a committee process that outlives any single company. GQL takes Cypher’s pattern syntax as its foundation and adds what a standard needs: a formal graph data model, graph types and schema, catalogue and session concepts, composable graph-to-graph queries, and a properly specified type system. Neo4j has driven conformance work, Google’s Spanner Graph implements graph queries in this lineage, and Microsoft added GQL support to the graph semantics in its Fabric and KQL stack after shipping Graph in Microsoft Fabric from October 2025. Learn the sibling standard too: SQL/PGQ, added to SQL:2023, lets you define a property graph view over existing relational tables and run GQL-style pattern matching against it without moving data, which is the least disruptive on-ramp most enterprises will ever get.

For the semantic web practitioner, the honest comparison is this. SPARQL 1.1 has property paths, federation, CONSTRUCT for graph-to-graph transformation and entailment regimes, and it has had them for over a decade. GQL has better ergonomics for variable-length traversal with per-hop conditions, native edge attributes, and a mutation story that developers do not have to be taught twice. Neither is a superset of the other, and knowing both is now a hiring differentiator rather than a curiosity.

CREATE (p:Pump {iri:'https://data.example.com/id/pump/8f3e2c91',
                tag:'P-101', ratedPowerKW:18.5})
CREATE (s:Site {iri:'https://data.example.com/id/Aberdeen2'})
CREATE (p)-[:INSTALLED_AT {since:date('2019-06-02')}]->(s)

ex:P101 ex:installedAt ex:Aberdeen2 .
<< ex:P101 ex:installedAt ex:Aberdeen2 >> ex:since "2019-06-02"^^xsd:date .

The bridge is now real infrastructure

Three developments turned interop from a research topic into plumbing. First, RDF-star has been mainstreamed into RDF 1.2: RDF 1.2 Concepts reached Candidate Recommendation with snapshots dated 7 April 2026, and triple terms in object position let you attach metadata to a statement without inventing an intermediate node. Writing that Alice works for Acme, then annotating that statement with a start date and a source, becomes a first class move rather than a modelling workaround, which erases the most cited practical reason to abandon RDF. Oxigraph exposes this behind its rdf-12 and sparql-12 feature flags, which makes it the easiest way to try RDF-star on a laptop today.

Second, concrete converters. neosemantics, the Neo4j Labs plugin known as n10s, imports RDF into Neo4j, exports Cypher-queried subgraphs back as RDF, handles namespace prefix mapping, and can import an OWL or RDFS vocabulary as a Neo4j graph so that class hierarchies are queryable as nodes. The reverse direction is served by R2RML-style mappings and by SPARQL CONSTRUCT queries that shape a lossless projection. Amazon Neptune goes further by hosting RDF and property graph APIs in one managed service, and Neptune Analytics added GraphRAG capability through Bedrock Knowledge Bases in March 2025.

Third, oneGraph thinking: the position, argued hardest inside the Neo4j ecosystem, that the two models are surface syntaxes over a common graph substrate and that a single store should be able to speak both. Treat it as an engineering aspiration rather than a shipped product, but the direction of travel is clear from RDF 1.2 triple terms, GQL graph types, and LlamaIndex’s replacement of its triple-only index with a Property Graph Index that runs over Neo4j, Memgraph, Kuzu or FalkorDB behind one API.

CREATE (p)-[:HAS_ATTRIBUTE]->(a:Attribute {name:'ratedPowerKW'})
CREATE (a)-[:HAS_VALUE]->(v:Value {value:18.5})

Do not pick a side, pick a pipeline

Here is the architecture that keeps showing up in programmes that survive their second year. Author and govern the model in RDF, OWL and SHACL, because that is where you get global identifiers, formal definitions, versioning and machine-checkable constraints, and where the crosswalks of lesson 29 can be expressed and certified. Validate every ingest against SHACL in CI, so bad data fails a build rather than a board meeting. Then project the validated graph into an LPG for serving, keeping the original IRI on every node as a property, which is the one discipline that makes the round trip lossless and lets you re-derive the RDF at any time. Run community detection, centrality and vector indexes over the LPG for GraphRAG retrieval. Push any correction back through the RDF model, never directly into the projection, or the two will diverge within a quarter.

The payoff is measurable rather than aesthetic. FalkorDB’s published, self-interested but instructive benchmarks report vector-only retrieval scoring near zero against schema-bound aggregation queries that a graph answers above ninety percent, and OG-RAG (arXiv 2412.15235, EMNLP 2025) reports 55 percent better fact recall from grounding retrieval in a curated ontology rather than an auto-extracted graph. Both results point the same way: the semantics earn the accuracy, the property graph engine earns the latency. Our own public work follows this shape, with the open-ontologies validation tooling at github.com/fabio-rovai/open-ontologies treating the RDF layer as the thing that must be falsifiable, and the serving layer as an artefact derived from it. If you want the RDF half of that pipeline in depth, the RDF, OWL and SHACL foundations course is the companion track.

One caution before you build. Engine choice is a commercial decision as well as a technical one, and this market moves: Kuzu, a popular embedded Cypher engine in GraphRAG stacks, lost its sponsoring company in 2025 and continues on community effort, so verify the support position of anything you standardise on. Which brings us to the deeper problem hiding behind every tooling argument: nobody hangs a project on the query language. They hang it on a model nobody agreed to. Module 3 starts there, with competency questions and a repeatable method for getting from a blank Protege window to a first release.