This document aims to introduce you to RDF and SPARQL from the ground up, up to a point where SPARQL queries will become familiar and approachable to reason about.

Different RDF triple stores may have different data layouts. All examples in this tutorial come from the Nepomuk ontology, and even though the tutorial aims to be generic enough, it mentions things specific to Tracker. Those are clearly spelled out.

If you are reading this tutorial, you might also have Tracker installed in your system, if that is the case you can for example start a fresh empty SPARQL service for local testing:

$ tracker3 endpoint --dbus-service org.example.Endpoint --ontology nepomuk

The queries can be run in this specific service with:

$ tracker3 sparql --dbus-service org.example.Endpoint --query $SPARQL_QUERY

RDF Triples

RDF data defines a graph, composed by vertices and edges. This graph is directed, because edges point from one vertex to another, and it is labeled, as those edges have a name. The unit of data in RDF is a triple of the form:

subject  predicate  object

Or expressed visually:

Subject and object are 2 graph vertices and the predicate is the edge, the accumulation of those triples form the full graph. For example, the following triples:

<http://example.com/Song> a nfo:FileDataObject .
<http://example.com/Song> a nmm:MusicPiece .
<http://example.com/Song> nie:title "Images" .
<http://example.com/Song> nmm:musicAlbum <http://example.com/Album> .
<http://example.com/Song> nmm:albumArtist <http://example.com/Jason> .
<http://example.com/Song> nmm:albumArtist <http://example.com/Marty> .
<http://example.com/Song> nmm:performer <http://example.com/Band> .

<http://example.com/Album> a nmm:MusicAlbum .
<http://example.com/Album> nie:title "Go Off!" .

<http://example.com/Jason> a nmm:Artist .
<http://example.com/Jason> nmm:artistName "Jason Becker" .

<http://example.com/Marty> a nmm:Artist .
<http://example.com/Marty> nmm:artistName "Marty Friedman" .

<http://example.com/Band> a nmm:Artist .
<http://example.com/Band> nmm:artistName "Cacophony" .

Would visually generate the following graph:

The dot after each triple is not (just) there for legibility, but is part of the syntax. The RDF triples in full length are quite repetitive and cumbersome to write, luckily they can be shortened by providing multiple objects (with , separator) or multiple predicate/object pairs (with ; separator), the previous RDF could be shortened into:

<http://example.com/Song> a nfo:FileDataObject, nmm:MusicPiece .
<http://example.com/Song> nie:title "Images" .
<http://example.com/Song> nmm:musicAlbum <http://example.com/Album> .
<http://example.com/Song> nmm:albumArtist <http://example.com/Jason> , <http://example.com/Marty> .
<http://example.com/Song> nmm:performer <http://example.com/Band> .

<http://example.com/Album> a nmm:MusicAlbum .
<http://example.com/Album> nie:title "Go Off!" .

<http://example.com/Jason> a nmm:Artist .
<http://example.com/Jason> nmm:artistName "Jason Becker" .

<http://example.com/Marty> a nmm:Artist .
<http://example.com/Marty> nmm:artistName "Marty Friedman" .

<http://example.com/Band> a nmm:Artist .
<http://example.com/Band> nmm:artistName "Cacophony" .

And further into:

<http://example.com/Song> a nfo:FileDataObject, nmm:MusicPiece ;
    nie:title "Images" ;
    nmm:musicAlbum <http://example.com/Album> ;
    nmm:albumArtist <http://example.com/Jason> , <http://example.com/Marty> ;
    nmm:performer <http://example.com/Band> .

<http://example.com/Album> a nmm:MusicAlbum ;
    nie:title "Go Off!" .

<http://example.com/Jason> a nmm:Artist ;
    nmm:artistName "Jason Becker" .

<http://example.com/Marty> a nmm:Artist ;
    nmm:artistName "Marty Friedman" .

<http://example.com/Band> a nmm:Artist ;
    nmm:artistName "Cacophony" .

SPARQL

SPARQL is the definition of a query language for RDF data. How does a query language for graphs work? Naturally by providing a graph to be matched, it is conveniently called the “graph pattern”.

SPARQL extends over the RDF concepts and syntax, once familiar with RDF the basic data insertion syntax should be fairly self-explanatory:

INSERT DATA {
    <http://example.com/Song> a nfo:FileDataObject, nmm:MusicPiece ;
        nie:title "Images" ;
        nmm:musicAlbum <http://example.com/Album> ;
        nmm:albumArtist <http://example.com/Jason> , <http://example.com/Marty> ;
        nmm:performer <http://example.com/Band> .

    <http://example.com/Album> a nmm:MusicAlbum ;
        nie:title "Go Off!" .

    <http://example.com/Jason> a nmm:Artist ;
        nmm:artistName "Jason Becker" .

    <http://example.com/Marty> a nmm:Artist ;
        nmm:artistName "Marty Friedman" .

    <http://example.com/Band> a nmm:Artist ;
        nmm:artistName "Cacophony" .
}

Same with simple data deletion:

DELETE DATA {
    <http://example.com/Resource> a rdfs:Resource ;
}

And simple graph testing:

# Tell me whether this RDF data exists in the store
ASK {
    <http://example.com/Song> nie:title "Images" ;
        nmm:albumArtist <http://example.com/Jason> ;
        nmm:musicAlbum <http://example.com/Album> .
    <http://example.com/Album> nie:title "Go Off!" .
    <http://example.com/Jason> nmm:artistName "Jason Becker"
}

Which would result in true, as the triple does exist. The ASK query syntax results in a single boolean row/column containing whether the provided graph exists in the store or not.

Queries and variables

Of course, the deal of a query language is being able to obtain the stored data, not just testing whether data exists.

The SELECT query syntax is used for that, and variables are denoted with a ? prefix (or $, although that is less widely used), variables act as “placeholders” where any data will match and be available to the resultset or within the query as that variable name.

These variables can be set anywhere as the subject, predicate or object of a triple. For example, the following query could be considered the opposite to the simple boolean testing the that ASK provides:

# Give me every known triple
SELECT * {
    ?subject ?predicate ?object
}

What does this query do? it provides a triple with 3 variables, that every known triple in the database will match. The * is a shortcut for all queried variables, the query could also be expressed as:

SELECT ?subject ?predicate ?object {
    ?subject ?predicate ?object
}

However, querying for all known data is most often hardly useful, this got unwieldly soon! Luckily, that is not necessarily the case, the variables may be used anywhere in the triple definition, with other triple elements consisting of literals you want to match for, e.g.:

# Give me the title of the song (Result: "Images")
SELECT ?songName {
    <http://example.com/Song> nie:title ?songName
}

# What is this text to the album? (Result: the nie:title)
SELECT ?predicate {
    <http://example.com/Album> ?predicate "Go Off!"
}

# What is the resource URI of this fine musician? (Result: <http://example.com/Marty>)
SELECT ?subject {
    ?subject nmm:artistName "Marty Friedman"
}

# Give me all resources that are a music piece (Result: <http://example.com/Song>)
SELECT ?song {
    ?song a nmm:MusicPiece
}

And also combinations of them, for example:

# Give me all predicate/object pairs for the given resource
SELECT ?pred ?obj {
    <http://example.com/Song> ?pred ?obj
}

# The Answer to the Ultimate Question of Life, the Universe, and Everything
SELECT ?subj ?pred {
    ?subj ?pred 42
}

# Give me all resources that have a title, and their title.
SELECT ?subj ?obj {
    ?subj nie:title ?obj
}

And of course, the graph pattern can hold more complex triple definitions, that will be matched as a whole across the stored data. for example:

# Give me all songs from this fine album
SELECT ?song {
    ?album nie:title "Go Off!" .
    ?song nmm:musicAlbum ?album
}

# Give me all song resources, their title, and their album title
SELECT ?song ?songTitle ?albumTitle {
    ?song a nmm:MusicPiece ;
        nmm:musicAlbum ?album ;
        nie:title ?songTitle .
    ?album nie:title ?albumTitle
}

Stop a bit to think on the graph pattern expressed in the last query:

This pattern on one hand consists of specified data (eg. ?song must be a nmm:MusicPiece, it must have a nmm:musicAlbum and a nie:title, ?album must have a nie:title, which must all apply for a match to happen.

On the other hand, the graph pattern contains a number of variables, some only used internally in the graph pattern, as a temporary variable of sorts (?album, in order to express the relation between ?song and its album title), while other variables are requested in the result set.

URIs, URNs and IRIs

In RDF data, everything that can be identified does so by a URI. URIs uniquely identify an element in the RDF set, have properties that are defined by URIs themselves, and point to data that may either be other resources (identified by URI) or literal values.

Given URIs are central to RDF data and SPARQL queries, there are a number of ways to write, generalize and shorten them. URIs can of course be defined in their full form:

ASK {
    <http://example.com/a> rdf:type rdfs:Resource .
    <http://example.com/sub/b> rdfs:label 'One' .
}

Sadly, not everything in the world can be trivially mapped to a URI, as an aide Tracker offers helpers to generate URIs based on UUIDv4 identifiers like tracker_sparql_get_uuid_urn(), these generated strings are typically called URNs.

The BASE keyword allows setting a common prefix for all URIs in the query:

BASE <http://example.com/>

ASK {
    <a> rdf:type rdfs:Resource .
    <sub/b> rdfs:label 'One' .
}

Or different prefixes can be defined with the PREFIX keyword:

PREFIX ex: <http://example.com/>
PREFIX sub: <http://example.com/sub/>

ASK {
    ex:a rdf:type rdfs:Resource .
    sub:b rdfs:label 'One' .
}

Notice how in the first triple, subject/predicate/object now look the same? That is because they now all are prefixed names, here the rdf and rdfs prefixes are simply builtin.

Taking the opposite path (i.e. expanding every term), this query could be written as:

ASK {
    <https://example/a> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2000/01/rdf-schema#Resource> .
    <https://example/sub/b> <http://www.w3.org/1999/02/22-rdf-syntax-ns#label> 'One' .
}

For the sake of familiarity, these elements have been referred to as “URIs”, but these are actually IRIs, thus the unicode range is available:

INSERT DATA {
    <http://example.com/💣> a rdfs:Resource
}

Filtering data

With some practice and experimentation, it should be quick to get the hang of graph patterns, and how do they match the stored RDF data. But it also quickly comes with the realization that it is completely binary, every piece of RDF data that matches the graph pattern is returned and everything else is ignored.

The FILTER keyword adds the missing further expressiveness, allowing to define arbitrary expressions on the variables defined in the graph pattern. E.g.:

# Get images larger than 800x600, at 4:3 ratio
SELECT ?image {
    ?image a nfo:Image ;
        nfo:width ?width ;
        nfo:height ?height .
    FILTER (?width > 800 &&
            ?height > 600 &&
            (?width / ?height = 4/3)) .
}

Conceptually, every solution given by the graph pattern runs through these filters, providing finer control over the final set of solutions. These filters are ultimately interpreted as boolean values, for example the following query:

# This returns nothing!
SELECT * {
   ?subject ?predicate ?object .
   FILTER (false)
}

Would return no results, as every solution is filtered out.

The SPARQL language also provides a number of builtin functions that are suitable for use in filters (e.g. for string checks and manipulation), these complement the relational expressions = != > >= < <=.

It is also possible to provide a list of possible values for variables to be filtered in or out via the operators IN and NOT IN:

# Give me every folder, except those named "Music" or "Downloads"
SELECT ?song {
    ?folder a nfo:Folder ;
        nfo:fileName ?name .
    FILTER (?name NOT IN ('Music', 'Downloads'))
}

Aggregate functions

Aggregate functions are those that work over groups of solutions, e.g.:

# Tell me how many songs do I have
SELECT (COUNT (?song) AS ?count) {
    ?song a nmm:MusicPiece .
}

By default, there is a single group for all solutions, a different grouping can be provided with the GROUP BY clause.

# Get the run time of each of my albums, the sum of their music pieces.
SELECT ?album (SUM (?duration) AS ?runtime) {
    ?song a nmm:MusicPiece ;
        nfo:duration ?duration ;
        nmm:musicAlbum ?album .
}
GROUP BY ?album

For numeric operations, SPARQL defines the COUNT / MIN / MAX / SUM / AVG functions. For strings, concatenation is available via the GROUP_CONCAT function. The SAMPLE function can be used to pick one of the values at random.

# Give me a list of directors, with one of their movies.
SELECT ?director (SAMPLE (?movie) AS ?sample) {
    ?movie a nmm:Movie ;
        nmm:director ?director .
}
GROUP BY ?director

Sometimes, it is desirable to apply filters on these aggregate values. The HAVING clause behaves like FILTER, except it can be used to apply filters on these aggregate values:

# Get music albums, but filter out singles and bonus discs (an arbitrary
# minimum of 4 songs is used for this)
SELECT ?album {
    ?song a nmm:MusicPiece .
        nmm:musicAlbum ?album
}
GROUP BY ?album
HAVING (COUNT (?song) >= 4)

Optional data

As we have seen, the graph pattern provided in SELECT queries match as a whole, stored RDF data either is a match (and becomes a possible solution), or it does not. Sometimes the available data is not all that regular, so it is desirable to create a graph pattern that can find solutions where some variables are left blank.

The OPTIONAL clause can be used for this:

# Get songs, and their known performer(s). But audio files are often mis/unlabeled!
SELECT ?song ?performer {
    ?song a nmm:MusicPiece .
    OPTIONAL {
        ?song nmm:performer ?performer .
    }
}

This query will always return all music pieces, but as the song’s nmm:performer property is obtained inside the OPTIONAL clause, it does not become mandatory to be part of the set of solutions. Contrast with:

SELECT ?song ?performer {
    ?song a nmm:MusicPiece ;
        nmm:performer ?performer .
}

Which will only return music pieces that have a nmm:performer.

It is worth pointing out that the content of OPTIONAL { } is itself also a graph pattern, so it also either matches as a whole or it does not. When fetching multiple optional properties, it is a common pitfall to do:

# BAD ❌: Only songs that have both performer *and* composer will match the
# optional graph pattern. Otherwise these 2 variables will be null.
SELECT ?song ?performer ?composer {
    ?song a nmm:MusicPiece .
    OPTIONAL {
        ?song nmm:performer ?performer ;
            nmm:composer ?composer .
    }
}

If there are multiple optional pieces of data, these must happen in separate OPTIONAL clauses:

# GOOD ✅: Songs may have none/either/both of performer/composer.
SELECT ?song ?performer ?composer
    ?song a nmm:MusicPiece .
    OPTIONAL {
        ?song nmm:performer ?performer .
    } .
    OPTIONAL {
        ?song nmm:composer ?composer .
    }
}

Property paths

Up till now, we have been defining triples in the graph pattern as sets of subject predicate object. A single predicate like that is the simplest property path there is, it relates subject and object directly via a labeled arrow.

Property paths make it possible to define more complex connections between subject and object (literally, paths of properties). The / operator may be used for concatenation:

# Get songs and their performer artist name, jumping across
# the intermediate nmm:Artist resource.
SELECT ?song ?artistName {
    ?song nmm:performer/nmm:artistName ?artistName
}

The | operator may be used for providing optional paths:

# Get songs and their performer/composer artist names, jumping across
# the intermediate nmm:Artist resources.
SELECT ?song ?artistName {
    ?song (nmm:performer|nmm:composer)/nmm:artistName ?artistName
}

The unary * and + operators may be used to define recursive paths, * allows a 0-length property path (essentially, subject equals object), while + requires that the property path should happen at least once.

# Get the XDG music folder, plus all its recursive contents.
SELECT ?file {
    ?file a nfo:FileDataObject ;
        (nfo:belongsToContainer/nie:isStoredAs)* ?root .
    FILTER (?root = 'file:///home/.../Music')
}

The unary ? operator makes portions of the property path optional, matching paths with either length 0 or 1:

# Get the XDG music folder, plus all its direct contents.
SELECT ?file {
    ?file a nfo:FileDataObject ;
        (nfo:belongsToContainer/nie:isStoredAs)? ?root .
    FILTER (?root = 'file:///home/.../Music')
}

The ^ operator inverts the direction of the relation expressed by the property path:

# The arrow goes in the other direction!
SELECT ?song ?artistName {
    ?artistName ^nmm:artistName ?song
}

The ! operator inverts the meaning of the match:

# Give me everything except the title
SELECT ?song ?value {
    ?song !nie:title ?value .
}

These operators may be all nested with ( ), allowing full expressiveness when defining the ways subject and object are interrelated.

Ontologies

In the RDF world, an “ontology” defines the characteristics of the data that a RDF database can hold. RDF triples that fit in its view of the world are accepted, while data that does not is rejected.

# This is good
INSERT DATA {
    <a> rdf:type rdfs:Resource
};

# This is bad, this property is unknown
INSERT DATA {
    <a> ex:nonExistentProperty 1000
}

Tracker defines all its ontologies on top of the RDF Schema, which provides the basic blocks to define classes (i.e. the types of the resources being stored) and the properties that each of these can have.

Basic types and literals have their own builtin classes (e.g. xsd:string for string literals), properties can point to either one of these builtin classes (e.g. the rdfs:label property points to string literals), or any other class defined in the ontology. This ability to “define the type” of properties allows to define the structure of the data:

# This is consistent, the nmm:musicAlbum property
# must point to a nmm:MusicAlbum resource
INSERT DATA {
    <album> a nmm:MusicAlbum .
    <song1> a nmm:MusicPiece ;
        nmm:musicAlbum <album>
}

# This is inconsistent, agenda contacts are not albums
INSERT DATA {
    <contact> a nco:Contact .
    <song2> a nmm:MusicPiece ;
        nmm:musicAlbum <contact>
}

The ontology is defined via RDF itself, and Tracker makes it part of the data set, there are thus full introspection capabilities builtin:

# Query all available classes
SELECT ?class {
    ?class a rdfs:Class
}

# Query all available properties, get
# the class they belong to, and the class
# type they point to.
SELECT ?definedOn ?property ?pointsTo {
    ?property a rdf:Property ;
        rdfs:domain ?definedOn ;
        rdfs:range ?pointsTo .
}

It is even possible to use these introspection capabilities while querying the stored data:

# Get all string properties of any song.
SELECT ?song ?value {
    ?song a nmm:MusicPiece ;
        ?p ?value .
    ?p rdfs:range xsd:string .
}

To learn more about how ontologies are done, read the documentation about defining ontologies. Tracker also provides a stock Nepomuk ontology, ready for use.

Inserting data

Once you know how RDF data is written, and are moderately acquainted with the ontology used by the database you are targeting, the syntax to insert data should be quite evident:

# Add a new music piece
INSERT DATA {
    <song> a nmm:MusicPiece
}

Just like with SELECT queries, the RDF data in a INSERT DATA clause may represent complex graphs:

# Add a new music piece, with more information
INSERT DATA {
    <song> a nmm:MusicPiece ;
        nfo:duration 360 ;
        nfo:codec 'MP3' ;
        nmm:dlnaProfile 'MP3' ;
        nie:title "It's a long way to the top" ;
        nmm:musicAlbum <album> ;
        nmm:artist <artist> .
    <album> a nmm:MusicAlbum ;
        nmm:albumDuration 5000 ;
        nie:title "T.N.T." .
    <artist> nmm:artistName "AC DC" .
}

Updating and deleting data

We have already seen the INSERT DATA and DELETE DATA syntax that allows specifying pure RDF data to manipulate the stored data.

It is additionally possible to perform bulk insertions and deletions over the already stored data. It is worth introducing first to the full syntax for updates and deletions:

DELETE {
   # Triple data
} INSERT {
   # Triple data
} WHERE {
   # Graph pattern
}

This query looks for all RDF data that matches the WHERE clause, and proceeds to deleting and inserting the given triple data for each of the matches.

The DELETE and INSERT clauses of this query form are optional, allowing to simply insert data:

# My favorite song is... all of them!
INSERT {
    ?song nao:hasTag nao:predefined-tag-favorite .
} WHERE {
    ?song a nmm:MusicPiece .
}

Or delete it:

# Delete all songs
DELETE {
    ?song a rdfs:Resource .
} WHERE {
    ?song a nmm:MusicPiece .
}

This last form can be further reduced if the RDF data to look for is also the data that should be deleted:

# Delete all songs, again
DELETE WHERE {
    ?song a nmm:MusicPiece, rdfs:Resource .
}

Going back to the full query form, there is no relation required between the data being deleted and the data being inserted. Its use can range from minor updates:

# Replace title of a song
DELETE {
    ?song nie:title ?title
} INSERT {
    ?song nie:title 'Two'
} WHERE {
    ?song a nmm:MusicPiece ;
        nie:title ?title .
    FILTER (?title = 'One')
}

To outright data substitutions:

# These are not songs, but personal recordings!
DELETE {
    # Delete anything that makes it look like a music piece
    ?notasong a nmm:MusicPiece .
    ?performer a rdfs:Resource .
    ?composer a rdfs:Resource .
} INSERT {
    # And insert my own data
    ?notasong a nfo:Note ;
        nie:title 'My Notes' .
} WHERE {
    ?notasong a nmm:MusicPiece ;
        nmm:performer ?performer ;
        nmm:composer ?composer .
}

Blank nodes

Blank nodes (or anonymous nodes) are nodes without an specified URI, these are given a query-local name via the special _: prefix:

# Insert a blank node
INSERT DATA {
    _:anon a nmm:MusicPiece
}

Note that running this query multiple times will insert a different blank node each time. Unlike e.g.:

INSERT DATA {
    <http://example.com/song1> a nmm:MusicPiece
}

Where any second insert would be redundantly attempting to add the same triple to the store.

By default, Tracker deviates from the SPARQL standard in the handling of blank nodes, these are considered a generator of URIs. The #TRACKER_SPARQL_CONNECTION_FLAGS_ANONYMOUS_BNODES flag may be used to make Tracker honor the SPARQL 1.1 standard with those. The standard defines blank nodes as truly anonymous, you can only use them to determine that there is something that matches the graph pattern you defined. The practical difference could be seen with this query:

SELECT ?u {
    ?u a rdfs:Resource .
    FILTER (isBlank (?u))
}

Tracker by default will provide you with URNs that can be fed into other SPARQL queries as URIs. With #TRACKER_SPARQL_CONNECTION_FLAGS_ANONYMOUS_BNODES enabled, the returned elements will be temporary names that can only be used to determine the existence of a distinct match. There, blank nodes can match named nodes, but named nodes do not match with blank nodes.

This nature of blank nodes is however useful to query for elements whose resource URI is irrelevant, e.g.:

# Query songs, and their disc's artist name
SELECT ?song ?artistName {
    ?song a nmm:MusicPiece ;
        nmm:musicAlbum _:album .
    _:album a nmm:MusicAlbum ;
        nmm:albumArtist _:artist ;
    _:artist a nmm:Artist ;
        nmm:artistName ?artistName .
}

In this query there is no interest in getting the intermediate album and artist resources, so blank nodes can be used for them.

Blank nodes have an in-place [ ] syntax, which declares a distinct empty blank node, it can also contain predicate/object pairs to further define the structure of the blank node. E.g. the previous query could be rewritten like:

SELECT ?song ?artistName {
    ?song a nmm:MusicPiece ;
        nmm:musicAlbum [
            a nmm:MusicAlbum ;
            nmm:albumArtist [
                a nmm:Artist ;
                nmm:artistName ?artistName
            ]
        ]
}

Named graphs

If SPARQL had a motto, it would be “Everything is a graph”. Until this point of the tutorial we have been talking about a singular “graph”, the triple store holds “a graph”, graph patterns match against “the graph”, et cetera.

This is not entirely accurate, or rather, it is an useful simplification. SPARQL is actually able to work over sets of graphs, or their union/intersection.

As with everything that has a name in RDF, URIs are also used to reference named graphs. The GRAPH clause is used to specify the named graph, in either inserts/deletes:

INSERT DATA {
    GRAPH <http://example.com/MyGraph> {
        <http://example.com/MySong> a nmm:MusicPiece ;
            nie:title "My song" .
    }
}

Or in queries:

SELECT ?song {
    GRAPH <http://example.com/MyGraph> {
        ?song a nmm:MusicPiece .
    }
}

So what have been doing all these queries up to this point in the tutorial? Without any specified graph, all insertions and deletes happen on an anonymous graph, while all queries happen on a “default” graph that Tracker defines as the union of all graphs.

These named graphs can exist independently of each other, and they can also overlap (e.g. specific RDF triples may exist in more than one graph). This makes it possible to match for specific pieces of data in specific graphs:

# Get info from different graphs, ?file is known in both of them, but none
# has the full information.
SELECT ?fileName ?title {
    GRAPH tracker:FileSystem {
        ?file a nfo:FileDataObject ;
            nfo:fileName ?fileName .
    }
    GRAPH tracker:Pictures {
        ?photo a nmm:Photo ;
            nie:isStoredAs ?file ;
            nie:title ?title .
    }
}

Tracker heavily relies on these named graph characteristics for its sandboxing support, where the availability of graphs may be restricted.

It is also possible to use the GRAPH clause with a variable, making it possible to query for the graph(s) where the graph pattern solutions are found:

# Query all known graphs, everything matches an empty graph pattern!
SELECT ?graph { GRAPH ?graph { } }

Services

RDF triple stores are sometimes available as “endpoints”, distinct services available externally via HTTP or other remote protocols, able to run SPARQL queries.

The SPARQL language itself defines the interoperation with other such endpoints within SPARQL queries. Since everything is RDF data, and everything is identified with a URI, this “foreign” RDF data might be conceptually dealt with as just another graph:

# Get data from the wikidata SPARQL service for my local albums, using
# an intermediate external reference.
SELECT ?album ?wikiPredicate ?wikiObject {
    ?album a nfo:MusicAlbum ;
        tracker:externalReference ?externalReference .
    ?externalReference tracker:referenceSource 'wikidata' .

    SERVICE <http://query.wikidata.org/sparql> {
        ?externalReference ?wikiPredicate ?wikiObject
    }
}

Tracker provides means to make RDF triple stores publicly available as SPARQL endpoints both via HTTP(S) and D-Bus protocols. By default, triple stores are not exported as endpoints, and are considered private to a process.

Importing and exporting data

Bulk insertions of RDF data are available with the LOAD clause:

# Load a file containing RDF data into a named graph
LOAD <file:///path/to/data.rdf> INTO GRAPH <http://example.com/MyGraph>

Bulk extraction of data can be obtained with the DESCRIBE query clause, the following query would return all subject/predicate/object triples inserted by the previous LOAD clause:

# Describe all objects in the named graph
DESCRIBE ?resource {
    GRAPH <http://example.com/MyGraph> {
        ?resource a rdfs:Resource .
    }
}

The DESCRIBE syntax can also be used to get all triple information describing specific resources:

# Get all information around the XDG music folder's URI
DESCRIBE <file:///.../Music>

The data returned by DESCRIBE is RDF triple data, so it can be serialized as such.

There may also be situations where it is convenient to transform data to other RDF formats (e.g. a different ontology) from the get go, the CONSTRUCT syntax exists for this purpose:

# Convert portions of the Nepomuk ontology into another fictional one.
PREFIX ex: <http://example.com>
CONSTRUCT {
    ?file ex:newTitleProperty ?title ;
        ex:newFileNameProperty ?fileName .
} WHERE {
    ?song a nmm:MusicPiece ;
        nie:isStoredAs ?file ;
        nie:title ?title .
}

The data returned by this syntax is also triple data, but ready for consumption in the other end.

Conclusion

SPARQL is a rather deep language that takes its purpose (making it possible to query information in RDF data graphs) very thoroughly, it also has some unusual features that make it able to scale from small private databases to large distributed ones.

Perhaps the “everything is a graph” mindset takes a while to think intuitively about to anyone with a background in relational databases. As with any complex language, mastery requires dedication. This is probably just the beginning of a journey.