The RDF data model represents information as triples: subject, predicate, object. A named graph adds a fourth component — a graph name — turning each triple into a quad: (subject, predicate, object, graph-IRI). This lets you group triples into labelled subsets within a single store.
(subject, predicate, object, graph-IRI)
A SPARQL query executes against an RDF dataset, which has two parts:
{ ?s ?p ?o }
GRAPH
GRAPH <uri> { ?s ?p ?o }
GRAPH ?g { ?s ?p ?o }
The GRAPH keyword changes the active graph for pattern matching within that part of the query. Outside a GRAPH clause, patterns match against the default graph.
One way to think about it: a named-graph RDF store is a set of quads where the fourth element is the graph IRI, which may be empty (the default graph).
RDF Studio uses named graphs to enforce semantic separation — each type of knowledge lives in its own graph. This separation is what allows the reasoner, the editors, and the query engine to work on the right subset of data without confusion.
Every graph is named in your namespace — the one the database declares — so the graph names travel with your data if you export it to another triplestore:
data
http://example.org/northwind/graph/data
ontology
http://example.org/northwind/graph/ontology
taxonomy
http://example.org/northwind/graph/taxonomy
shape
http://example.org/northwind/graph/shape
query
http://example.org/northwind/graph/query
config
http://example.org/northwind/graph/config
namespace
http://example.org/northwind/graph/namespace
The convention is {base}graph/{type}, where {base} is the database's base IRI — for Northwind, http://example.org/northwind/. A base that ends in an instance segment such as id/ has that segment dropped first, so the graphs sit beside the instances. On a database connected to a triplestore you already own, the query, config and namespace graphs also carry the database's name: {base}{database}/graph/{type}.
{base}graph/{type}
{base}
http://example.org/northwind/
id/
{base}{database}/graph/{type}
The Northwind namespaces file declares the prefix nwg: for its graph base, which is why the shipped queries can write GRAPH nwg:data instead of a full IRI.
nwg:
GRAPH nwg:data
The actual IRIs for your database are shown in Connect ▸ Databases ▸ card ⋮ ▸ Config ▸ Named Graphs.
This is where triplestores differ most — and where users coming from other tools are most likely to be surprised.
Per the spec, if you don't put any data in the default graph, a bare SELECT * WHERE { ?s ?p ?o } returns nothing — because there's nothing to match against. This is technically correct but practically useless. In RDF Studio, all data lives in named graphs.
SELECT * WHERE { ?s ?p ?o }
query.all.graphs=true
RDF Studio uses Oxigraph's union default graph mode (use_default_graph_as_union=True). The default graph is a read-only virtual view over all named graphs computed at query time. Nothing is stored there. No data is copied.
use_default_graph_as_union=True
This means:
GRAPH <data> { ?s ?p ?o }
This is the same behaviour as RDFox in its default union graph mode, and the same as Neptune's architectural choice. It's the cleanest semantics available.
The GraphDB/Stardog-union approach stores (or presents) data in both the default graph and the named graph. So a query like this:
SELECT ?g ?s ?p ?o WHERE { { GRAPH ?g { ?s ?p ?o } } UNION { ?s ?p ?o BIND("default" AS ?g) } }
…returns every triple twice on GraphDB: once from the named graph, once from the "default" which is a copy of it.
On RDF Studio nothing is stored twice: the default graph IS the named graph content — a view, not a copy. A query that asks both ways, like the one above, still lists each triple once per branch, so use one pattern or the other.
SELECT ?s ?p ?o WHERE { ?s ?p ?o }
Returns triples from all named graphs. No GRAPH clause needed.
SELECT ?s ?p ?o WHERE { GRAPH <http://example.org/northwind/graph/data> { ?s ?p ?o } }
Returns only instance data — ontology, taxonomy and shape triples are excluded.
SELECT ?g (COUNT(*) AS ?count) WHERE { GRAPH ?g { ?s ?p ?o } } GROUP BY ?g ORDER BY DESC(?count)
SELECT ?s ?p ?o WHERE { { GRAPH <http://example.org/northwind/graph/data> { ?s ?p ?o } } UNION { GRAPH <http://example.org/northwind/graph/ontology> { ?s ?p ?o } } }
PREFIX nwo: <http://example.org/ontology/northwind#> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?instance ?label WHERE { GRAPH <http://example.org/northwind/graph/data> { ?instance a nwo:Customer . } GRAPH <http://example.org/northwind/graph/ontology> { nwo:Customer rdfs:label ?label . } }
You can use the standard SPARQL FROM NAMED syntax to limit which named graphs a GRAPH ?g { … } pattern can match (a pattern outside GRAPH still reads every graph while "Default Graph as Union" is ON):
FROM NAMED
GRAPH ?g { … }
SELECT ?s ?p ?o FROM NAMED <http://example.org/northwind/graph/data> WHERE { GRAPH ?g { ?s ?p ?o } }
This returns only data-graph triples. The ?g variable binds to the data graph IRI.
?g
The SPARQL editor's autocomplete knows your database's named graph IRIs. After the keyword GRAPH, the editor shows a dropdown of the database's named graphs in prefixed form — those whose namespace has a PREFIX declared in the query (for Northwind, declare nwg: first). This prevents typos and eliminates the need to memorise long URIs.
PREFIX
The graph filter (the filter button in the toolbar, showing All Graphs or how many graphs are selected) controls which named graphs are queried by the Explore and Visualize tabs. It does NOT affect the Query Editor — there a query runs exactly as written, and you control scoping with SPARQL syntax.
Available filter presets:
On a local database, Data Only, Schema and a custom selection send explicit named graph URIs in their SPARQL queries (e.g. GRAPH <data> { ... }). All Graphs sends no graph list: the query is a bare one while "Default Graph as Union" is ON, and GRAPH ?g { … } over every named graph when it is OFF; Default Graph sends a bare query.
GRAPH <data> { ... }
When you run DESCRIBE <uri> in the Query Editor, the result includes triples from all named graphs where that subject appears. For most instances, this means:
DESCRIBE <uri>
rdf:type
This is expected and complete — the Query Editor is designed to give the full unfiltered view of a resource. If you want only what the data graph says about a resource, name the graph in a CONSTRUCT:
CONSTRUCT { <http://example.org/northwind/id/order-10485> ?p ?o } WHERE { GRAPH <http://example.org/northwind/graph/data> { <http://example.org/northwind/id/order-10485> ?p ?o } }
Located in Connect ▸ Databases ▸ card ⋮ ▸ Config ▸ Named Graphs, this toggle controls Oxigraph's union default graph mode per database. It defaults to ON.
FROM
This setting applies wherever a query is sent with no GRAPH clause: the Query Editor, the Default Graph filter in Explore and Visualize — which therefore shows the same classes as All Graphs while the setting is ON — and All Graphs itself on a local database. Data Only, Schema and a custom selection name their graphs with explicit GRAPH clauses and are unaffected.
stardog:context:named
stardog:context:all
stardog:context:default