This wiki has been archived and is now read-only.

Graph Terminology

From RDF Working Group Wiki
(Redirected from GraphConceptTerminology)
Jump to: navigation, search

See also RDF+SPARQL Graph Terminology and more recently (May 2012) Containers of Triples.

NB: We resolved on 2011-10-12: In our documents, we'll use the terms "RDF Graph" for g-snap, "Graph Container" for g-box, and "Graph Serialization" for g-text.

NB: But as of 2012-08, that resolution has not been adopted by the drafts under consideration; a new one may be needed. See Graph Terminology/Options.

This page explains three terms (g-box, g-snap, g-text) which allow us to speak more clearly about RDF graphs, documents, datasets, stores, etc. See also Sandro's original email and the ensuing email discussion. That email include discussion about related terms that have not yet made it to this page.

Graph Concept Terminology

The term "RDF Graph" has become used to refer to multiple different concepts over the years. This page introduces three temporary terms relating to different graph concepts, which can be used within RDF WG discussions and use cases.


A "g-box" is a container, like a "set" data structure in programming. It holds some RDF arcs, with their nodes. (Alternatively, it holds some RDF triples.). G-boxes can overlap, sharing some of the same nodes and arcs. Two g-boxes can happen to have the same contents (right now) while being distinct g-boxes. G-boxes contents can change: today a particular g-box might contain the triples { my:a my:b _:x. my:a my:c _:x }, and tomorrow it might instead contain { my:a my:b _:x. my:a my:c2 _:x }.


A "g-snap" as an idealized snapshot of a g-box; it's a mathematical set of RDF arcs, with their nodes. (Alternatively, a mathematical set of RDF triples.) Like g-boxes, g-snaps can overlap, sharing nodes and arcs. Unlike g-boxes, it makes no sense to talk about g-snaps changing: they are defined to be exactly the collection of their elements. If a g-snap were to "change" it would simply be a different g-snap. If two g-snaps have the same nodes/arcs, they are really the same g-snap. The contents of a g-box at any point in time are a g-snap.


A "g-text" is a particular sequence of characters or bytes which conveys a particular g-snap in some language (eg turtle or rdf/xml). If you can parse a g-text, you know what is in the g-snap it conveys (except blank nodes, as discussed below). You can tell someone exactly what is in a particular g-box at some instant by sending them a g-text. (You send them the g-text which conveys the g-snap which is the current state/contents of that g-box.)

Possible Requirements

  • There may exist a need to make statements about a g-box, thus a way to refer to them may be required
  • There may exist a need to make statements about a g-snap, or a distinct set of triples, thus a way to refer to one may be required
  • There may exist a need to make statements about a "state" of a g-box, either previous or future, thus a way to refer to a g-snap as being the state of g-box-X at Y time may be needed.

General Story

A "named g-box" equates roughly to an "Information Resource" or a "Named Graph in a Quad Store", ( name , G ) where G is a set of values over time { Gs1, Gs2, ... }, each value in the set is a g-snap, a distinct set of triples, and each g-snap can be "serialized" or "represented" in many different ways (RDF/XML, turtle, rdf-json, ...). Each distinct serialization/representation is a "g-text".

Visual Diagram

Error creating thumbnail: Unable to save thumbnail to destination