RDF, Turtle, and SPARQL

Which one should I be using?

Anyone arriving at RDF from Neo4j, or at Neo4j from RDF, asks the same question. Most public answers are not neutral. Vendor pieces make property graphs feel practical and RDF feel ceremonial. Semantic-web defenders make RDF feel principled and property graphs feel parochial. Both framings contain truth and both hide where real system design happens.

The honest answer is that RDF and labeled property graphs model many of the same facts but start from different primitives. Once you choose the primitives, consequences cascade: syntax, query shape, metadata, reasoning, reuse, integration, tooling, and team skill. This page tries to make that choice hard in the right way.

The Resume Graph Explorer runs on Neo4j. Its ESCO skill links are RDF. Understanding where those two stacks meet — and where they diverge — is the concrete version of Module 1's 30-second test.

Same fact, different primitives.

RDF starts with the triple: subject, predicate, object. Subjects and predicates are IRIs. Objects can be IRIs, literals, or blank nodes. Classes, vocabularies, entailment, and ontology design sit on top of that single move — there is nothing else.

A labeled property graph starts with nodes and relationships. Nodes carry labels and properties; relationships carry types and properties. The model feels closer to how many developers already think: this person worked at this company, and the relationship itself has a title and start date.

@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:Alice a foaf:Person .
:Bob   a foaf:Person .
:Alice foaf:knows :Bob .

# "since 2020" needs: event node,
# RDF-star, or classical reification.

CREATE
  (alice:Person {name: 'Alice'}),
  (bob:Person   {name: 'Bob'}),
  (alice)-[:KNOWS {since: 2020}]->(bob)

That "since 2020" is not a footnote — it is the first hint of the whole trade-off. LPG puts it on the edge and moves on. RDF asks whether this relationship is itself a thing worth naming. Annoying sometimes; clarifying also sometimes.

A small career graph, twice.

One person, two jobs, one degree, three skills linked to ESCO-style skill concepts. Small enough to fit on screen; structured enough to surface every modeling choice. The ESCO IRIs are illustrative placeholders.

CREATE
  (p:Person {
    name: "Alex Rivera",
    email: "alex@example.com" }),
  (a:Company {name: "Riverbend Analytics"}),
  (b:Company {name: "Northwind Health"}),
  (s:School  {name: "Midstate University"}),
  (p)-[:EMPLOYED_BY {
    role: "Junior Data Analyst",
    startDate: date("2020-01-15"),
    endDate:   date("2022-06-30")
  }]->(a),
  (p)-[:EMPLOYED_BY {
    role: "Data Scientist",
    startDate: date("2022-07-01")
  }]->(b),
  (p)-[:EDUCATED_AT {
    degree: "BS Statistics",
    endDate: date("2019-05-15")
  }]->(s),
  (py:Skill {name:"Python", escoId:"ccd0..."}),
  (sq:Skill {name:"SQL",    escoId:"29cd..."}),
  (ml:Skill {name:"Machine learning",
             escoId:"4d4d..."}),
  (p)-[:HAS_SKILL {level:"advanced"}]->(py),
  (p)-[:HAS_SKILL {level:"advanced"}]->(sq),
  (p)-[:HAS_SKILL {level:"intermediate"}]->(ml)

@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix schema: <https://schema.org/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix sensemaking: <https://sensemaking-ai.com/ns/> .

:alex a foaf:Person ;
  foaf:name "Alex Rivera" ;
  sensemaking:hasEmployment :emp1, :emp2 ;
  sensemaking:hasEducation :edu1 ;
  sensemaking:hasSkill :s_py, :s_sql, :s_ml .

:emp1 a sensemaking:Employment ;
  sensemaking:employer :riverbend ;
  sensemaking:role "Junior Data Analyst" ;
  sensemaking:startDate "2020-01-15"^^xsd:date ;
  sensemaking:endDate   "2022-06-30"^^xsd:date .

:s_py  a skos:Concept ; skos:prefLabel "Python" ;
  skos:exactMatch <http://data.europa.eu/esco/skill/ccd0> .
:s_sql a skos:Concept ; skos:prefLabel "SQL" ;
  skos:exactMatch <http://data.europa.eu/esco/skill/29cd> .
:s_ml  a skos:Concept ; skos:prefLabel "Machine learning" ;
  skos:exactMatch <http://data.europa.eu/esco/skill/4d4d> .

Three things to notice. Dates in Cypher go on the edge; Turtle turns employment into an event node. Skills in Cypher store ESCO IDs as strings; Turtle types them as skos:Concept with a live skos:exactMatch link. And Turtle is longer — the URI tax arriving on the page. The section after next shows where that tax starts buying something.

Three queries, three answers

MATCH (p:Person {name: "Alex Rivera"})
      -[r:EMPLOYED_BY]->(c:Company)
RETURN c.name, r.role, r.startDate
ORDER BY r.startDate

SELECT ?orgName ?role ?start WHERE {
  :alex sensemaking:hasEmployment ?emp .
  ?emp  sensemaking:employer  ?org ;
        sensemaking:role      ?role ;
        sensemaking:startDate ?start .
  ?org  schema:name ?orgName .
} ORDER BY ?start

The ESCO interop unlock

The skills query is where the stacks separate. In Cypher, the ESCO ID is a string — the database has no idea what it points to. Following the ESCO hierarchy requires importing ESCO as a separate node set. In SPARQL, ESCO is published as RDF. Each skill's skos:exactMatch link is a live IRI; skos:broader traversal is a normal triple-pattern, no import required.

The verbosity is real.

RDF is more verbose because every important term carries a globally identifiable IRI. For an isolated application — one team, one database, no integration partners — the URI tax is pure overhead. LPG is the humane choice, and the team ships faster.

For a graph that participates in a broader ecosystem — ESCO, FIBO, schema.org, PROV-O, Wikidata — the tax becomes infrastructure. The cost arrives early. The value compounds: every external vocabulary you can read is a query you do not have to engineer separately.

Eight deities, three realms, five patterns.

The starter kit's data/mythology.ttl follows the same structural conventions as example.ttl — same prefix block, same class/property pattern — with the domain swapped to Greek and Roman mythology. Three things to notice before the queries begin.

# Class declaration — reuse before defining
sensemaking:Deity a owl:Class ;
    rdfs:subClassOf schema:Person ;
    rdfs:label "Deity" ;
    rdfs:comment "A divine being affiliated
                  with a realm." .

# Greek and Latin names — the LANG gotcha
sensemaking:Apollo rdfs:label
    "Ἀπόλλων"@el ,
    "Apollo"@la .

sensemaking:Ares rdfs:label
    "Ἄρης"@el ,
    "Mars"@la .

# championed: directed sponsorship
sensemaking:Zeus
    sensemaking:championed
        sensemaking:Athena ,
        sensemaking:Apollo ,
        sensemaking:Ares .

sensemaking:Poseidon
    sensemaking:championed
        sensemaking:Triton .

# Ares: intentionally no hasPower
sensemaking:Ares a sensemaking:Deity ;
    schema:name "Ares" ;
    rdfs:label "Ἄρης"@el , "Mars"@la ;
    sensemaking:memberOfRealm
        sensemaking:Olympians .

Five queries, five patterns.

The same five SPARQL patterns as the Naruto workbook — SELECT, GROUP BY, ASK, FILTER + OPTIONAL, CONSTRUCT — applied to mythology data. Copy each query, paste it into the Fuseki SPARQL editor, and run it. Work through the "Think about this" prompts before moving on.

PREFIX rdf:         <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX schema:      <https://schema.org/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/mythology#>

SELECT ?deity ?name
WHERE {
  ?deity a sensemaking:Deity ;
         schema:name ?name .
}
ORDER BY ?name

PREFIX schema:      <https://schema.org/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/mythology#>

SELECT ?realmName (COUNT(?deity) AS ?memberCount)
WHERE {
  ?realm a sensemaking:Realm ;
         schema:name ?realmName .
  FILTER (LANG(?realmName) = "en")

  ?deity sensemaking:memberOfRealm ?realm .
}
GROUP BY ?realmName
ORDER BY DESC(?memberCount) ?realmName

PREFIX sensemaking: <https://sensemaking-ai.com/ns/mythology#>

ASK
WHERE {
  ?deity sensemaking:hasPower sensemaking:Prophecy .
}

PREFIX rdfs:        <http://www.w3.org/2000/01/rdf-schema#>
PREFIX schema:      <https://schema.org/>
PREFIX skos:        <http://www.w3.org/2004/02/skos/core#>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/mythology#>

SELECT ?name ?powerLabel
WHERE {
  ?deity a sensemaking:Deity ;
         schema:name ?name ;
         sensemaking:memberOfRealm ?realm .

  ?realm rdfs:label ?realmLabel .
  FILTER (CONTAINS(LCASE(?realmLabel), "olymp"))

  OPTIONAL {
    ?deity sensemaking:hasPower ?power .
    ?power skos:prefLabel ?powerLabel .
    FILTER (LANG(?powerLabel) = "en")
  }
}
ORDER BY ?name

PREFIX sensemaking: <https://sensemaking-ai.com/ns/mythology#>

CONSTRUCT {
  ?a sensemaking:pantheonmateOf ?b .
}
WHERE {
  ?a sensemaking:memberOfRealm ?realm .
  ?b sensemaking:memberOfRealm ?realm .

  FILTER (STR(?a) < STR(?b))
}

Four things to build.

Each challenge asks you to write a query not in the starter kit. Start from the closest existing query and modify from there. Write the query before opening the answer panel.

PREFIX schema:      <https://schema.org/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/mythology#>

SELECT ?name WHERE {
  ?deity a sensemaking:Deity ;
         schema:name ?name .
  FILTER NOT EXISTS {
    ?deity sensemaking:hasPower ?power .
  }
} ORDER BY ?name

PREFIX schema:      <https://schema.org/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/mythology#>

SELECT ?name (COUNT(?power) AS ?powerCount)
WHERE {
  ?deity a sensemaking:Deity ;
         schema:name ?name ;
         sensemaking:hasPower ?power .
}
GROUP BY ?name
ORDER BY DESC(?powerCount) ?name

# All championed pairs
PREFIX schema:      <https://schema.org/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/mythology#>

SELECT ?championName ?championedName WHERE {
  ?champion sensemaking:championed ?championed ;
            schema:name ?championName .
  ?championed schema:name ?championedName .
} ORDER BY ?championName

# Champions of 2+ others only
SELECT ?championName (COUNT(?championed) AS ?n)
WHERE {
  ?champion sensemaking:championed ?championed ;
            schema:name ?championName .
}
GROUP BY ?championName
HAVING (COUNT(?championed) > 1)

PREFIX schema:      <https://schema.org/>
PREFIX sensemaking: <https://sensemaking-ai.com/ns/mythology#>

SELECT ?aName ?bName WHERE {
  ?a sensemaking:rivalOf ?b ;
     schema:name ?aName .
  ?b schema:name ?bName .
} ORDER BY ?aName

Heuristics, not slogans.

This section is the answer to Module 1's 30-second test: explain to a working engineer, without slogans, why someone would choose RDF over a labeled property graph or vice versa.

Six good next reads.

Not equal-purpose links — read them for different kinds of evidence.

Other materials for Submodule 1.1: synthesis document (static reading companion with annotated diagrams and side-by-side queries) · Naruto domain variant · Module 1 cheatsheet (coming soon)