RDF, Turtle, SPARQL

The standard prefix block

Paste this at the top of every Turtle file and SPARQL query. The first eight are the curriculum default; PROV-O and OWL-Time get added when reification or temporal modeling shows up.

@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl:     <http://www.w3.org/2002/07/owl#> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix foaf:    <http://xmlns.com/foaf/0.1/> .
@prefix schema:  <https://schema.org/> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .
# Add when needed:
@prefix prov:    <http://www.w3.org/ns/prov#> .
@prefix time:    <http://www.w3.org/2006/time#> .

SPARQL equivalent (no @, no period)

PREFIX rdf:    <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX schema: <https://schema.org/>
PREFIX skos:   <http://www.w3.org/2004/02/skos/core#>

Turtle syntax, the essentials

Every Turtle file is a set of triples (subject, predicate, object) ending in a period. The shorthand is what makes it readable at scale.

:Naruto schema:memberOf :Konoha .

:Naruto a schema:Person ;
        schema:memberOf :Konoha ;
        schema:name "Naruto Uzumaki" .

:Naruto naruto:hasJutsu :ShadowClone ,
                        :Rasengan ,
                        :SageMode .

:Naruto a schema:Person .
# is the same as:
:Naruto rdf:type schema:Person .

Literals

"Naruto Uzumaki"                # plain string
"Naruto Uzumaki"@en             # language-tagged
"うずまきナルト"@ja               # Japanese
"1999-09-21"^^xsd:date          # typed
42                              # integer (sugar for "42"^^xsd:integer)
3.14                            # decimal
true                            # boolean

Long strings, blank nodes, lists

:Itachi schema:description """
Member of the Uchiha clan
who joined Akatsuki after
the Uchiha massacre.
""" .

:Naruto schema:address [
  schema:streetAddress "Konoha Village" ;
  schema:postalCode    "00001"
] .

:ChuninExams naruto:teams
  ( :Team7 :Team8 :Team10 ) .

XSD datatypes you'll actually use

There are dozens. These are the ones that come up in real ontology work.

SPARQL essentials

SPARQL is graph-pattern matching. You describe a shape; the engine finds every binding of variables that fits the shape. The mental shift from SQL is real — but the syntax is small.

The four query forms

SELECT skeleton

PREFIX schema: <https://schema.org/>

SELECT ?person ?name
WHERE {
  ?person a schema:Person ;
          schema:name ?name .
}
ORDER BY ?name
LIMIT 25

Triple patterns

Variables start with ?. Each triple pattern ends in a period (or chains with ; / , like Turtle).

?s rdf:type ?type .              # what types is ?s?
?s ?p ?o .                       # everything about ?s
?ninja schema:memberOf :Konoha . # everyone from Konoha

FILTER — narrow existing bindings

?character schema:birthDate ?date .
FILTER (?date < "1990-01-01"^^xsd:date)

?character schema:name ?name .
FILTER (REGEX(?name, "Uchiha", "i"))   # case-insensitive

FILTER EXISTS { ?character naruto:hasJutsu :Sharingan }
FILTER NOT EXISTS { ?character naruto:rivalOf :Naruto }

OPTIONAL — left-outer join

?person schema:name ?name .
OPTIONAL { ?person schema:email ?email }
OPTIONAL { ?person schema:birthDate ?dob }

If the optional pattern matches, the variable is bound. If not, the row still returns with that variable unbound.

UNION — either pattern

{ ?person schema:name ?name }
UNION
{ ?person foaf:name ?name }

Aggregation

SELECT ?village (COUNT(?ninja) AS ?count)
WHERE {
  ?ninja schema:memberOf ?village .
}
GROUP BY ?village
HAVING (?count > 5)
ORDER BY DESC(?count)

Other aggregates: SUM, AVG, MIN, MAX, GROUP_CONCAT, SAMPLE.

Property paths — SPARQL 1.1

?p foaf:knows+ :Naruto .          # 1 or more hops
?p foaf:knows* :Naruto .          # 0 or more (includes self)
?p foaf:knows? :Naruto .          # 0 or 1 (optional)
?p (foaf:knows|schema:colleague) :Naruto .       # alternation
?p schema:parent/schema:name ?gpName .           # sequence: grandparent's name
?p ^schema:parent ?child .                       # inverse: ?p is ?child's parent

CONSTRUCT — materialize a new graph

CONSTRUCT {
  ?person naruto:hasCompetency ?skill .
}
WHERE {
  ?person naruto:heldRole ?role .
  ?role schema:duration ?d .
  ?role naruto:relatedSkill ?skill .
  FILTER (?d > "P2Y"^^xsd:duration)
}

Returns RDF, not a table. The workhorse of inference materialization in Module 3.

Wikidata query patterns

Wikidata uses Q-numbers for entities and P-numbers for properties. The query service at query.wikidata.org has a forgiving UI — find Q/P numbers via the search box, then modify example queries before writing from scratch.

The minimum useful query

PREFIX wd:  <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>

# Books by Adrian Tchaikovsky (Q14010003)
SELECT ?book ?title
WHERE {
  ?book wdt:P50  wd:Q14010003 ;   # P50 = author
        wdt:P31  wd:Q571 ;        # P31 = instance of, Q571 = book
        rdfs:label ?title .
  FILTER(LANG(?title) = "en")
}

The label service — always add this

SELECT ?person ?personLabel
WHERE {
  ?person wdt:P69 wd:Q49108 .   # educated at MIT
  SERVICE wikibase:label {
    bd:serviceParam wikibase:language "en" .
  }
}

Any variable ending in Label gets auto-resolved to a readable name.

Common Q/P numbers worth memorizing

Reusable vocabularies — when to reach for what

Reuse before defining. Every custom term is future maintenance burden and lost interoperability. The order below is the order to check.

The decision flow

• Check rdfs/owl built-ins first (label, comment, subClassOf are universal)
• Then schema.org — broadest coverage, best tooling, alive and maintained
• Then domain-specific established vocabularies: FOAF (people), SKOS (taxonomies), Dublin Core (bibliographic), PROV-O (provenance), OWL-Time (temporal)
• Then domain-of-practice vocabularies if applicable: ESCO (occupations), FIBO (finance), UMLS (medical)
• Only then mint terms in your custom namespace — and document the reasoning in a REUSE.md

Common errors and where they bite

The errors you'll hit in the first month. Each one looks cryptic the first time.

Endpoints and sandboxes