What is a named graph?

A named graph is an extension of the RDF model that turns the subject-predicate-object triple into a quad, adding a fourth element: a URI identifying the set of triples that statement belongs to. Instead of one large undifferentiated graph, a triplestore can keep multiple subsets of triples apart, each labeled with its own URI that typically represents provenance: which system, which supplier, or which import batch asserted those facts. The practical benefit is being able to query, update, or exclude an entire batch of data without touching the rest, something impossible if all triples live in a single unlabeled graph. The concept was introduced informally in the mid-2000s and standardized through SPARQL 1.0, the first specification to make it formally queryable; today it is natively supported by enterprise triplestores such as Virtuoso, GraphDB, and Stardog, and it is mature, established technology, not an experimental draft.

The mechanism: the fourth element and SPARQL syntax

In the quad model, every triple carries a fourth value, the URI of the graph it belongs to: the same subject-predicate-object statement can therefore appear in two different named graphs if two sources assert it independently, without creating ambiguity or indistinguishable duplicates. To serialize multiple named graphs in a single file, dedicated formats are used, such as TriG (a Turtle variant) or TriX (an XML variant), both built specifically to carry quads instead of plain triples. Querying a specific named graph in SPARQL is done with the GRAPH clause: GRAPH <supplier-a-uri> { ?s ?p ?o } restricts the search pattern to that subset alone, while a query without GRAPH queries the default graph or the union of all graphs, depending on the triplestore's configuration.

Why it is not the same thing as RDF-star

Named graphs and RDF-star solve a similar problem, adding context to a statement, but at a different and non-interchangeable granularity. A named graph operates at the level of a set of triples: it labels an entire batch of facts with a shared provenance, for example "everything that comes from supplier A's feed." RDF-star instead annotates the individual triple, letting you say that a specific statement has a given validity period or a given confidence score, independently of how it is grouped. Whoever needs to trace the source of a batch of data needs named graphs; whoever needs to annotate every single fact point by point with its own metadata needs RDF-star. Confusing the two leads to poor modeling: a named graph that is too granular (one per triple) makes no practical sense, while using RDF-star to separate different sources forces you to duplicate the annotation on every triple instead of labeling the batch once.

An enterprise example: integrating data from multiple suppliers

A company building a knowledge graph by integrating master data from two different suppliers, each with its own quality and update frequency, keeps each source in its own named graph: one for supplier A, one for supplier B, possibly one for internally enriched data. If supplier B is later replaced or a systematic error is found in its data, it is enough to exclude that single named graph from queries or delete it, without having to distinguish triple by triple which facts came from there. The same pattern applies to an RDF dataset that keeps current transactional data and historical data loaded in separate batches apart.

Why it matters for decision makers

A named graph is the tool that turns data provenance into a queryable property instead of information lost during integration. For anyone who has to answer an audit on data aggregated from third parties, or assess how much to trust one external source versus another, being able to isolate and trace every batch of triples back to its origin is often a compliance requirement, not just a technical convenience. Adopting it carries a modest discipline cost compared to plain RDF, since it only requires assigning a URI to each source at load time; the return is the ability to trust data selectively instead of treating it as an undifferentiated block.