Named Graphs

An RDF dataset can contain multiple graphs. The default graph is the main graph that scripts run against. Named graphs are additional graphs identified by a URI, isolated from the default graph and from each other.

The Concept

A named graph is just a set of triples with a name (a URI). Triples in a named graph are invisible to scripts that target the default graph. You access them explicitly with the GRAPH keyword:

PREFIX tasks: <https://example.org/spec/tasks#>

# Select from the default graph (normal)
SELECT ?task ?title WHERE {
    ?task a tasks:Task ;
          tasks:title ?title .
}

# Select from a specific named graph
SELECT ?task ?title WHERE {
    GRAPH <urn:graph:my-results> {
        ?task a tasks:Task ;
              tasks:title ?title .
    }
}

That's all a named graph is: an isolated subgraph you access by name.

How Poliglot Uses Named Graphs

In Poliglot, the default graph is the context graph: the unified view of your operational state, composed from observations across all agents and data sources. It has RDFS inference, continuous SHACL validation, and full provenance tracking.

Named graphs sit alongside this as scratchpads. They don't participate in default graph operations, inference, or provenance. They're used for:

Action Result Storage

When a CONSTRUCT or DESCRIBE script handler executes, its output goes into a named graph (auto-generated as urn:graph:{uuid}). The graph URI is returned to the caller:

PREFIX tasks: <https://example.org/spec/tasks#>

?graph tasks:SummarizeStatus (?workspace) .

GRAPH ?graph {
    ?summary tasks:totalOpen ?open .
}

Dynamic Graphs

Create temporary graphs at runtime with rars-os:newGraph():

PREFIX tasks: <https://example.org/spec/tasks#>
PREFIX rars-os:    <https://poliglot.io/rars/spec/os#>

BIND(rars-os:newGraph() AS ?g)

INSERT {
    GRAPH ?g {
        ?task tasks:score ?computed .
    }
} WHERE {
    ?task a tasks:Task .
    BIND(/* some computation */ AS ?computed)
}

rars-os:newGraph() creates the graph and grants read/write access to the calling agent's roles automatically.

Batch Results

Service integrations can store mapped responses in a named graph via rars-act:resultGraph instead of binding individual resources:

tasks:SyncIntegration
    a rars-act:ServiceIntegration ;
    rars-act:resultGraph [
        rars-os:datatype xsd:anyURI ;
        rars-os:fromValue """
        SELECT ?value WHERE {
            BIND(URI(CONCAT("urn:graph:sync:", STRUUID())) AS ?value)
        }
        """
    ] .

Permissions

Named graph access is controlled separately from the default graph.

The default graph uses rars-os:ReadStatement and rars-os:WriteStatement on specific classes. Named graphs use rars-os:ReadGraph and rars-os:WriteGraph on the specific graph resource.

Dynamically created graphs (via rars-os:newGraph()) automatically grant access to the creator's roles. Statically declared graphs need explicit IAM policies:

tasks:AnalyticsGraph
    a rars-os:NamedGraph ;
    rdfs:label "Task Analytics" .

tasks:AnalyticsReadPolicy
    a rars-iam:ResourcePolicy ;
    rars-iam:effect rars-iam:Allow ;
    rars-iam:action rars-os:ReadGraph ;
    rars-iam:resource tasks:AnalyticsGraph ;
    rars-iam:role tasks:AnalystRole .

What Named Graphs Don't Have

Provenance: statements in named graphs aren't tracked as observations
Inference: RDFS reasoning doesn't apply within named graphs
Continuous validation: SHACL constraints aren't evaluated against named graph contents

If data needs provenance, inference, or validation, it belongs in the default graph.