Run a read-only SPARQL query (SELECT, CONSTRUCT, ASK or DESCRIBE).

Forms: SELECT returns rows, CONSTRUCT and DESCRIBE return triples, ASK returns a boolean. WHERE is optional -- "SELECT ?s { ?s ?p ?o }" is valid SPARQL.

Property paths are the reason to reach for SPARQL over a REST API: a/b sequence ?s foaf:knows/foaf:name ?name a|b alternative ?s (rdfs:label|skos:prefLabel) ?label a* zero or more ?s skos:broader* ?ancestor a+ one or more ?s rdfs:subClassOf+ ?super a? zero or one ^a inverse ?child ^ex:hasParent ?parent !a negated ?s !rdf:type ?o

Named graphs: GRAPH { ?s ?p ?o }, or GRAPH ?g { ... } to range over all of them. Note that a query without a GRAPH clause reads the default graph, which on many datasets is empty unless the store is configured with a union default graph.

Results are capped. A SELECT without its own LIMIT gets one appended (see default_limit), because an unbounded exploration query over even a small dataset can return hundreds of thousands of characters. Pass limit: 0 to lift the cap deliberately, and out_file to send a large result to disk instead of through the conversation.

Run a SPARQL Update: INSERT, DELETE, LOAD, CLEAR, CREATE, DROP, COPY, MOVE or ADD.

To create a named graph, insert into it: INSERT DATA { GRAPH { "o" } }

CREATE GRAPH on its own is not enough on TDB2. It answers 200, but a graph with no triples does not exist as far as anything else is concerned -- list_graphs will not show it and the Graph Store Protocol answers 404 for it.

For replacing a whole graph from a file, write_graph and load_rdf_file are better: they do not put the RDF through this conversation.

Everything the store knows about one IRI, in both directions.

Returns the triples where the IRI is the subject and, unless you turn it off, those where it is the object -- which is usually where the interesting part is, because it shows what points at the thing.

Faster to reach for than writing the query by hand, and it names the graph each triple came from.

List the named graphs in a dataset, with a triple count for each.

Only graphs holding at least one triple appear, and on TDB2 that is the whole story: an empty graph is indistinguishable from one that was never created. If a graph you just made is missing, it has no triples yet.

The default graph is reported separately, because a query without a GRAPH clause reads that one -- and on a store without a union default graph it is often empty while the named graphs are full.

Fetch one named graph whole, as Turtle.

One HTTP request, and it never touches the query parser -- the right way to read a graph you intend to inspect or copy. A CONSTRUCT returns the same triples but has to be parsed as a query first.

A 404 here means the graph holds no triples. That is not an error about the endpoint.

Graphs get large quickly; pass out_file for anything beyond a few hundred triples.

Replace or extend one named graph with RDF you supply.

mode "replace" (the default) makes the graph exactly what you send: whatever was in it is gone. mode "merge" adds to what is there.

Replacing per graph is how a versioned schema is kept in sync -- one graph per module, so that updating one cannot wipe another.

Give the RDF either inline (content) or from a file (file). Prefer the file for anything beyond a handful of triples: it goes straight to the server instead of through the conversation.

Delete a named graph and everything in it. There is no undo.

Run backup_dataset first if the contents matter.

A 404 means the graph was already empty, which on TDB2 means it did not exist.

Load an RDF file from the sandbox into a dataset.

Accepts Turtle, N-Triples, TriG, N-Quads, JSON-LD and RDF/XML; the media type comes from the extension. TriG and N-Quads carry their own graph names, so do not pass a target graph with those -- the file decides.

This exists so that bulk RDF never has to pass through the conversation. A 44 kB ontology rewritten as INSERT DATA costs roughly 11 000 tokens; here it costs none.

List the datasets on this Fuseki server and the endpoints each offers.

Reach for this first when a call fails with 405. Fuseki answers 405 -- not 404 -- for a dataset name it does not know, which reads like "wrong method" when it actually means "no such dataset".

The endpoint names matter too. A dataset configured through an assembler file often exposes only "sparql", while Fuseki's stock configuration also accepts "query". This shows which one you have.

Size and shape of a dataset: triple counts, graphs, classes and properties.

A quick orientation for a store you have not seen before -- how much is in it, how it is divided over graphs, and which types and predicates dominate.

Create a dataset on the server.

kind "tdb2" (the default) is persistent and survives a restart; "mem" is in-memory and is gone when the server stops -- useful for a scratch space, and a trap if you meant to keep the data.

Fuseki writes a configuration file for the new dataset, so it comes back after a restart. A dataset created this way has the stock endpoints: sparql, query, update, data and get.

Remove a dataset from the server and delete its files. Irreversible.

This is not "unmount": the data on disk goes too. Take a backup first if there is anything in it you would miss.

Version, uptime and per-dataset request statistics.

Worth a call at the start of a session to confirm you are talking to the server you think you are -- a wrong endpoint that happens to answer is otherwise hard to spot.

Start a server-side backup of a dataset.

The backup is written on the server, into Fuseki's backups directory, and runs in the background: this returns a task id to poll with task_status.

Do this before anything destructive. There is no undo for drop_graph or delete_dataset.

Listed as a read tool deliberately -- it copies data out, it does not change it, so it stays available when the server runs read-only.

Compact a TDB2 dataset, reclaiming space held by superseded data.

Runs in the background; poll with task_status. delete_old removes the pre-compaction copy once it succeeds, which frees the most space and cannot be undone.

Only meaningful for TDB2 datasets.

The state of a background task started by backup_dataset or compact_dataset.

A task that has finished reports a "finished" timestamp; one still running does not.