SEMANTIC INTEROPERABILITY FOR NEO4J

Neosemantics: Bringing RDF Semantics Into Neo4j

Import, explore, validate, reason over, and export semantic data with the Neo4j property graph model.
A brief overview based on the Neosemantics 4.0 user guide.
Neosemantics · RDF and Neo4j

RDF and Property Graphs Need an Interoperability Layer

RDF brings shared meaning

  • Global identifiers through URIs
  • Shared vocabularies and ontologies
  • A W3C standard for data interchange

Neo4j brings graph application strengths

  • A direct property graph model
  • Cypher for exploration and analysis
  • A mature graph application platform
The gap: Teams need to use semantic standards and Neo4j graph capabilities without maintaining disconnected copies or translation logic.
Neosemantics · RDF and Neo4j

Neosemantics Connects Standards and Graph Applications

RDF sourcesFiles, linked data, APIs, and SPARQL endpoints.
→
NeosemanticsParses, configures, maps, and validates semantic data.
→
Neo4jStores the data as a property graph for Cypher and applications.
↔
RDF consumersReceive RDF generated from selected graph data.
  • Import RDF into Neo4j.
  • Export imported RDF or native property graph data as RDF.
  • Add model mapping, SHACL validation, and inferencing.
Round trip: Imported RDF can be exported without losing triples when the required namespace information is retained.
Neosemantics · RDF and Neo4j

Configuration Decides What the Neo4j Graph Will Look Like

Decision Options Why it matters
Vocabulary URIs Keep, shorten, ignore, or map Balances RDF fidelity with readable Cypher names
Multiple values Keep one value or use arrays Controls how repeated RDF properties are stored
Language tags Preserve or filter Supports multilingual literals and selective imports
Custom data types Retain or simplify Determines how specialized literal types survive
RDF types Labels or connected nodes Changes how instances relate to ontology concepts
Required first: Create a uniqueness constraint on :Resource(uri) and initialize the graph configuration before importing RDF.
Neosemantics · RDF and Neo4j

RDF Statements Become Familiar Graph Elements

RDF statement Neo4j representation
ex:alice rdf:type ex:Person Person label on the Alice node
ex:alice ex:name "Alice" name property on the Alice node
ex:alice ex:knows ex:bob KNOWS relationship from Alice to Bob
Resource identifier uri property on a Resource node
The result: Semantic data becomes a property graph that can be explored with Cypher while retaining its RDF identity.
Neosemantics · RDF and Neo4j

Preview and Filter RDF Before It Reaches the Graph

  • Stream first: Parse RDF and inspect triples without persisting them.
  • Check structure: Review subjects, predicates, objects, literal values, and data types.
  • Limit scope: Exclude predicates or select a language during import.
  • Customize: Use Cypher to decide how streamed triples become graph structures.
Why preview: A small inspection step exposes naming, density, and modeling issues before they become part of the stored graph.
Neosemantics · RDF and Neo4j

One Procedure Loads Common RDF Sources and Formats

CALL n10s.rdf.import.fetch(
  "https://example.org/data.ttl",
  "Turtle"
);

Sources

  • Local or remote files
  • HTTP services that return RDF
  • RDF generated by SPARQL endpoints

Serializations

  • Turtle and N-Triples
  • JSON-LD and RDF/XML
  • TriG and N-Quads
Neosemantics · RDF and Neo4j

Ontologies Bring Shared Vocabulary Into the Same Graph

  • Import classes and properties from an ontology.
  • Load instance data using the same URI identifiers.
  • Connect instances to ontology concepts when RDF types are modeled as nodes.
  • Explore class hierarchies and instance relationships with Cypher.
URI identity does the linking: Consistent identifiers allow ontology elements and instance data to meet in the same graph.
Neosemantics · RDF and Neo4j

Mappings Keep External Semantics and Internal Names Aligned

External vocabularyStable RDF URIs and published semantic terms.
↔
n10s mappingOne-to-one mappings applied during import or export.
↔
Neo4j vocabularyReadable labels, relationship types, and property names.
  • Keep standards-based identifiers at the boundary.
  • Use application-friendly names inside the graph.
  • Apply the same mapping definitions in both directions.
Practical result: Interoperability does not require awkward names in everyday Cypher queries.
Neosemantics · RDF and Neo4j

SHACL Turns Semantic Expectations Into Validation Checks

Does the graph conform to the structures and values the domain expects?
  • Load SHACL shapes that describe expected graph constraints.
  • Validate Neo4j data against those shapes.
  • Identify resources and properties that violate the rules.
  • Review or correct issues before downstream use.
Quality gate: Shared vocabulary becomes more reliable when the graph can also be checked against shared rules.
Neosemantics · RDF and Neo4j

Inference Exposes Knowledge That Was Only Implicit

Asserted factA resource belongs to a specific class.
+
OntologyThe class belongs to a broader class hierarchy.
→
Inferred contextThe broader classification becomes available to queries.
  • Reason over class and property relationships.
  • Use ontology structure without manually storing every implied statement.
  • Combine explicit graph facts with semantic context in application queries.
Neosemantics · RDF and Neo4j

Export Keeps Neo4j Connected to the RDF Ecosystem

  • Generate RDF on demand from selected Neo4j data.
  • Recreate RDF triples from imported data when semantic identifiers were preserved.
  • Publish native property graph data through RDF serializations.
  • Apply mappings and control how much graph context is included.
Open boundary: Neo4j can serve graph applications and still exchange data with standards-based semantic systems.
Neosemantics · RDF and Neo4j

Prove the Round Trip With One Small Use Case

  1. Choose: Select one RDF dataset or ontology with a clear purpose.
  2. Configure: Decide which identifiers and semantic details must survive.
  3. Preview: Inspect the triples and confirm the intended graph shape.
  4. Import: Load the data and test representative Cypher queries.
  5. Check: Validate the graph and apply reasoning where it adds value.
  6. Export: Generate RDF and confirm that the required semantics remain intact.
Success: The same semantic data works naturally in Neo4j and remains usable across the RDF ecosystem.
Sources: Neo4j Labs Neosemantics 4.0 User Guide, Introduction, and Importing RDF Data.
Neosemantics · RDF and Neo4j

Appendix: What the Semantic Choices Look Like in the Graph

Concrete examples of configuration, URI linking, vocabulary mapping, and SHACL validation

Neosemantics · Technical appendix

URI Handling Changes the Names Stored in the Graph

ex:alice a ex:Person ; ex:given-name "Alice" .
handleVocabUris Label and property in Neo4j What it preserves
KEEP :`http://example.org/vocab#Person`
n.`http://example.org/vocab#given-name` 		Complete vocabulary URIs
SHORTEN :ex__Person
n.ex__given-name		 Namespace meaning through a prefix
IGNORE :Person
n.given-name		 Only each URI's local name
MAP :Person
n.givenName		 Explicit application-friendly names
Same RDF, different graph vocabulary: The configuration sets the balance between semantic fidelity and readable Cypher.
Neosemantics · Technical appendix

Value and Type Settings Change Properties and Relationships

RDF pattern Setting Resulting graph representation
ex:alice ex:altName "Al", "Ace" Default single value (:Resource {altName: "Ace"})
Same repeated property handleMultival: "ARRAY" (:Resource {altName: ["Al", "Ace"]})
ex:alice rdf:type ex:Person typesToLabels: true (:Resource:Person {uri: "...alice"})
Same type statement typesToLabels: false (:Resource {uri: "...alice"})-[:rdf__type]->(:Resource {uri: "...Person"})
Structural choice: Labels make type checks concise. Type nodes make the RDF statement explicit and allow direct links to an ontology.
Neosemantics · Technical appendix

The Same URI Connects Instance Data to Its Ontology Class

1. Ontology import creates class nodes and hierarchy links
(:Class {name: "Employee", uri: "...#Employee"})
    -[:SCO]->
(:Class {name: "Person", uri: "...#Person"})
2. Instance import keeps rdf:type as a relationship
(:Resource {name: "Alice", uri: ".../alice"})
    -[:rdf__type]->
(:Class {name: "Employee", uri: "...#Employee"})
URI identity does the linking: The instance points to the existing class node because both imports use the same ...#Employee identifier.
Neosemantics · Technical appendix
CALL n10s.nsprefixes.add(
  "skos", "http://www.w3.org/2004/02/skos/core#"
);
CALL n10s.mapping.add(
  "http://www.w3.org/2004/02/skos/core#narrower",
  "CHILD_CATEGORY"
);
External RDFcategoryA skos:narrower categoryB
↔
Mappingskos:narrower
is equivalent to
CHILD_CATEGORY
↔
Neo4j graph(categoryA)-[:CHILD_CATEGORY]->(categoryB)
Neosemantics · Technical appendix

A SHACL Shape Makes the Expected Person Model Explicit

Shape

neo4j:PersonShape
  a sh:NodeShape ;
  sh:targetClass neo4j:Person ;
  sh:property [
    sh:path neo4j:name ;
    sh:datatype xsd:string ;
    sh:maxCount 1
  ] .

Graph data

(:Person {
  name: 42
})
  • The node targets the Person shape.
  • name exists, but its value is not a string.
  • Validation reports the node and offending value.
The shape is executable documentation: It states the rule in a standard form and gives validation a precise test.
Neosemantics · Technical appendix

Validation Returns a Specific Violation and Can Enforce It Three Ways

focus node node type failed constraint offending value path severity
17 Person DatatypeConstraintComponent 42 name Violation
Whole graphFind every violation in the current database.
·
Selected nodesCheck only the resources involved in a workflow.
·
TransactionReject a write when it introduces a violation.
CALL n10s.validation.shacl.validate()
Neosemantics · Technical appendix

Neosemantics, also called n10s, is a Neo4j plugin for working with RDF. It connects standards-based semantic data with the Neo4j property graph and Cypher query model. This overview follows the lifecycle of semantic data through Neo4j: configuration, import, graph use, validation, reasoning, and export.

RDF and the property graph model emphasize different strengths. RDF provides stable identifiers, shared vocabularies, and a standard exchange model. Neo4j provides a direct graph model and Cypher. The practical challenge is moving between them while retaining the semantic details that make the data understandable and reusable.

Neosemantics sits at the boundary between the RDF ecosystem and Neo4j. It handles RDF parsing and graph representation on the way in, then can generate RDF again on the way out. The round-trip guarantee depends on preserving the semantic identifiers needed to reconstruct the original triples. Configuration therefore comes before import, not after it.

The graph configuration defines the translation between the RDF model and the property graph model. It affects names, values, types, and the ability to export the graph as RDF later. Neosemantics also requires a uniqueness constraint on Resource URI values. The configuration should be treated as an architectural decision because changing it after data has been loaded requires clearing the imported graph.

This slide shows the core transformation. Literal values become node properties. Links between resources become graph relationships. RDF types become labels by default, and the source URI remains on the resource node. The exact labels, relationship types, and property names depend on how vocabulary URIs are configured.

Neosemantics can stream parsed RDF as records before anything is written. This gives teams a chance to inspect the source and apply their own Cypher logic when the standard import transformation is not the desired model. Import parameters can also narrow the data by predicate or language tag. That is useful when only part of a large semantic dataset is relevant.

The main import procedure accepts a source URL, the RDF serialization, and optional parameters. A source can be a static file or a service that produces RDF dynamically. Advanced request settings support headers and POST payloads, which makes it possible to submit a query to an RDF-producing endpoint and import the result directly.

Ontology import gives the graph an explicit semantic model. Because RDF resources use URIs, ontology elements and instance data can connect when they refer to the same identifiers. The choice between representing RDF types as labels or nodes matters here. Type nodes make the link between instances and ontology classes explicit, while labels provide a simpler property graph representation.

Mapping separates the external semantic contract from the internal graph vocabulary. For example, an RDF property with a long or inconvenient name can map to a concise property name in Neo4j. Mappings are one-to-one and can be used during both import and export. That keeps the transformation explicit and reversible.

RDF vocabularies describe meaning. SHACL adds machine-readable expectations about graph structure and values. Neosemantics can validate Neo4j graph data against SHACL shapes and return the violations. This creates a clear quality checkpoint between ingestion and application use.

Semantic models often contain knowledge that is implied rather than written as a direct statement. A class hierarchy is a simple example: membership in a specific class can imply membership in a broader class. Neosemantics exposes reasoning functions that let queries use this ontology structure without copying every possible implied relationship into the graph.

Export completes the interoperability story. Neosemantics can generate RDF from a graph created through RDF import and from a native property graph. The export can target selected nodes or Cypher results and can use model mappings. If an imported graph discarded namespace information, an exact round trip is no longer possible, which reinforces the importance of the initial configuration.

Close with a small, testable adoption path. One dataset is enough to prove the decisions that matter: graph configuration, Cypher usability, semantic validation, reasoning value, and RDF export fidelity. Sources used for this deck: https://neo4j.com/labs/neosemantics/4.0/ https://neo4j.com/labs/neosemantics/4.0/introduction/ https://neo4j.com/labs/neosemantics/4.0/import/

The main deck explains the lifecycle. This appendix makes four parts of that lifecycle concrete by showing simplified RDF inputs, Neo4j graph representations, and validation output. The examples follow Neosemantics 4.0 behavior. Names can vary when a graph uses different namespace prefixes or mapping definitions.

KEEP retains the full vocabulary URI in labels, relationship types, and property names. SHORTEN replaces namespaces with registered prefixes. IGNORE keeps only local names. MAP applies explicit one-to-one mappings. The example names are simplified and use an ex prefix registered for http://example.org/vocab#. Source: https://neo4j.com/labs/neosemantics/4.0/config/

Neosemantics keeps one literal value by default when an RDF property occurs multiple times. ARRAY preserves every value in a Neo4j list. RDF types become labels by default. Setting typesToLabels to false keeps the type as a relationship between URI-identified resources. The displayed rdf__type relationship assumes shortened namespace handling. Source: https://neo4j.com/labs/neosemantics/4.0/import/

The ontology loader stores named classes as Class nodes with URI and name properties. It stores rdfs:subClassOf as SCO relationships by default. When instance data is imported with typesToLabels false, the rdf:type object is resolved by URI. If the ontology class already has that URI, the instance connects to the existing class node rather than creating a disconnected copy. Sources: https://neo4j.com/labs/neosemantics/4.0/importing-ontologies/ https://neo4j.com/labs/neosemantics/4.0/import/

This is the mapping example from the Neosemantics guide. A relationship named CHILD_CATEGORY in Neo4j is equivalent to skos:narrower in RDF. Mappings are one-to-one pairs of equivalent vocabulary elements. The same definition is used on import and export, so internal Cypher conventions do not have to become the external semantic contract. Source: https://neo4j.com/labs/neosemantics/4.0/mapping/

This simplified shape is based on the Person example in the guide. It says that a Person name must be a string and may appear no more than once. The example graph violates the datatype constraint because its name value is numeric. Neosemantics loads SHACL from a URL or inline Turtle. Source: https://neo4j.com/labs/neosemantics/4.0/validation/

The validation report identifies the failing node, its type, the constraint component, the offending value, the property path, and severity. Neosemantics 4.0 supports validation of the whole graph, a selected node set, or changes inside a transaction. The guide notes that version 4 implements a significant portion of SHACL, but not the entire language. Source: https://neo4j.com/labs/neosemantics/4.0/validation/