Containers of Triples
In RDF, people use the term "graph" in many different kinds of ways, referring to many different kinds of collections of triples. Sometimes the distinctions do not matter; sometimes they do. This page explain some of the cases where they do.
Applicable Metadata Properties
|"Last Modified" (What was the most recent time that there was a change in which triples it contained?)||No||No||Yes||Yes|
So you have some sort of container or group or collection of RDF triples. What type is it?
1. At any given point in time, is it clearly defined which triples are contained in it? For example, considering a Web service which returns different RDF data based on the client's IP address, we would have to say "No". If YES, go to question 1. If NO, it's not a container of triples, this is not the right quiz for you.
2. While it conceptually contains triples, does it actually consist entirely of a sequence of characters (or bytes)? If YES, it's g-text. If NO, proceed to number 3.
3. Could you have two of these, with distinct identities, but containing exactly the same triples? "Distinct identities" means you might want to say something about one and not also be saying the same thing about the other. If YES, it's some kind of g-box; proceed to number 4; if NO, it's g-snap.
Types of Containers
Some might not call the g-text a container of triples, but it sure looks like one:
"<a> <b> <c>"
That looks like it has a triple in it. Maybe it does. But it's also a string of 11 characters. When computers transmit triples, they put them in a g-text, then transmit the g-text.
This is for the purists: it's a mathematical set of triples. The g-snap has no identity of its own. Anything you can say about the g-snap containing just the triple <a> <b> <c> is true of every g-snap containing just that triple, because there's really only one g-snap like that.
It also makes no sense to talk about a g-snap changing.
G-snaps tend to be somewhat confusing outside of math. It may help to think of them like integers. There is only one number 7, for example. We can write it down many places, and change what's written in those places, but we can't change the number itself. We can assign meaning to some of those places -- on the score board in a stadium, for instance, it means a lot -- but it's complete nonsense to say that one person's number seven is somehow different from another person's number seven. There is only one number seven. Similarly, there is only one empty g-snap, only one g-snap containing just <a> <b> <c>, etc.
This is what the RDF Recommendation (2004) calls a "graph".
Suggested names for this include "RDF Graph", "graph snapshot", ...
The mutable g-box is perhaps the most versitile of containers for triples. G-boxes retain their separate identities regardless of which triples they contain, and their triples can change over time.
Examples of mutable g-boxes includes:
- An HTML page with embedded RDFa or microdata
- A SQL database exported as RDF using R2RML
- The "default graph" of a normal SPARQL server
- A file containing RDF/XML, Turtle, or N-Triples
Names sometimes used for this include "graph" and "named graph".
Suggested names for this include "graph container", "data space", "data page", "layer", and "sheet".
The static g-box is like the mutable g-box, except it's defined to never change. It's not yet clear how practical this is.
If it were identified with a URL that included some kind of cryptographic hash, that might help keep it from changing.
The static g-box is different from the g-snap in that it retains it's own identity, separate from its contents. There can be many different empty static g-boxes, each meaningfully having its own metadata.
Suggested names for this include "graph snapshot" (confusingly), and 'static' followed by any of the names for a mutable g-box.