Migrating from libtracker-sparql 2.x to 3.0

Graph semantics
No libtracker-control
No libtracker-miner
No tracker_sparql_connection_load()/load_async()/load_finish()
No tracker_sparql_connection_statistics()/statistics_async()/statistics_finish()
No TRACKER_NOTIFIER_FLAG_NOTIFY_UNEXTRACTED
No TRACKER_NOTIFIER_FLAG_QUERY_LOCATION
No tracker_notifier_new()
Different signature of TrackerNotifier::events signal
Return value change in tracker_sparql_connection_update_array()
No tracker_sparql_connection_get()/get_async()
No tracker_sparql_connection_set_domain
No priority argument on SPARQL updates

Tracker 3.0 is a new major version, containing some large syntax and conceptual changes.

Graph semantics

One of the big features in 3.0 is full SPARQL 1.1 syntax support. Besides the missing syntax additions, one conceptually big change is the handling of graphs in the database.

In 2.x, there was a minimum concept of graphs, but it didn't represent what is defined in the standard. You could attribute a graph to a data triple, but a given triple could only reside in one graph at a time. In other words, this yields the wrong result:

INSERT { GRAPH <A> { <foo> nie:title 'Hello' } }
INSERT { GRAPH <B> { <foo> nie:title 'Hola' } }

# We expect 2 rows, 2.x returns 1.
SELECT ?g ?t { GRAPH ?g { <foo> nie:title ?t } }
    

3.0 implements the graph semantics as defined in the SPARQL 1.1 documents. So the SELECT query would return both graphs.

3.0 also honors properly the concept of «Unnamed graph». This graph is always used whenever no graph is specified, and always skipped if a GRAPH is requested or defined, e.g.:

# Inserts element into the unnamed graph
INSERT { <foo> a nfo:FileDataObject }

# Inserts element into named graph A
INSERT { GRAPH <A> { <bar> a nfo:FileDataObject } }

# Queries from all named graphs, A in this case
SELECT ?g ?s { GRAPH ?g { ?s a nfo:FileDataObject } }

# Queries the default graph, which includes the unnamed graph
SELECT ?s { ?s a nfo:FileDataObject }
    

3.0 defines the default graph to be the union of the unnamed graph plus all known named graphs. So the last query in the example above would return results from both the unnamed graph and graph A. This behavior can be influenced with FROM/FROM NAMED syntax (also newly handled in 3.0)

In contrast, 2.x does not distinguish between named and unnamed graphs. The first SELECT query would return a row for the unnamed graph, with ?g being NULL.