RDF 1.2 Concepts and Abstract Data Model

The core structure of the abstract data model is a set of triples, each consisting of a subject, a predicate and an object. A set of such triples is called an RDF graph. An RDF graph can be visualized as a node and directed-arc diagram, in which each triple is represented as a node-arc-node link.

There are four kinds of nodes that can be in an RDF graph: IRIs, literals, blank nodes, and triple terms.

From this definition, it follows that when one term appears in multiple triples, these are simply multiple occurrences of that same term. For example, in a graph containing two triples (here expressed in common set and tuple notation, and using abstract names as distinct terms):

{ (R1, P1, R3),
  (R2, P2, R3) }

the term R3 is the same single term used twice, and there are five terms in total. This is more readily shown in two-dimensional graph diagrams, where one single node can simply be connected from or to multiple other nodes using labelled arcs.

This abstract data model can be encoded in different ways while preserving the same stucture, as described in 1.9 RDF Documents and Syntaxes.

Any IRI or literal denotes something in the world (the "universe of discourse"). These things are called resources. Anything can be a resource, including physical things, documents, abstract concepts, numbers and strings; the term is synonymous with "entity" as it is used in RDF 1.2 Semantics [RDF12-SEMANTICS]. The resource denoted by an IRI is called its referent, and the resource denoted by a literal is called its literal value. Literals have datatypes that define the range of possible values, such as strings, numbers, and dates. Special kinds of literals — language-tagged strings and directional language-tagged strings — respectively denote plain-text strings in a natural language and plain-text strings in a natural language including an initial text direction.

Asserting an RDF triple says that some relationship, indicated by the predicate, holds between the resources denoted by the subject and object (as explained below, not all triples are asserted). This statement corresponding to an RDF triple is known as an RDF statement. The predicate itself is an IRI and denotes a property, that is, a resource that can be thought of as a binary relation. (Relations that involve more than two entities can only be indirectly expressed in RDF [SWBP-N-ARYRELATIONS].)

Unlike IRIs and literals, blank nodes do not identify specific resources. Statements involving blank nodes say that something with the given relationships exists, without explicitly naming it.

The resource denoted by an IRI is also called its referent. For some IRIs with particular meanings, such as those identifying XSD datatypes, the referent is fixed by this specification. For all other IRIs, what exactly is denoted by any given IRI is not defined by this specification. Other specifications may fix IRI referents, or apply other constraints on what may be the referent of any IRI.

Guidelines for determining the referent of an IRI are provided in other documents, like Architecture of the World Wide Web, Volume One [WEBARCH] and Cool URIs for the Semantic Web [COOLURIS]. A very brief, informal, and partial account follows:

• By design, IRIs have global scope. Thus, two different appearances of an IRI denote the same resource. Violating this principle constitutes an IRI collision [WEBARCH].
• By social convention, the IRI owner [WEBARCH] gets to say what the intended (or usual) referent of an IRI is. Applications and users need not abide by this intended denotation, but there may be a loss of interoperability with other applications and users if they do not do so.
• The IRI owner can establish the intended referent by means of a specification or other document that explains what is denoted. For example, the The Organization Ontology [VOCAB-ORG] specifies the intended referents of various IRIs that start with http://www.w3.org/ns/org#.
• A good way of communicating the intended referent is to set up the IRI so that it dereferences [WEBARCH] to such a document.
• Such a document can, in fact, be an RDF document that describes the denoted resource by means of RDF statements.

Perhaps the most important characteristic of IRIs in web architecture is that they can be dereferenced, and hence serve as starting points for interactions with a remote server. This specification is not concerned with such interactions. It does not define an interaction model. It only treats IRIs as globally unique identifiers in a graph data model that describes resources. However, those interactions are critical to the concept of Linked Data Design Issues, [LINKED-DATA], which uses the RDF abstract syntax and concrete RDF syntaxes, the latter also referred to as serialization formats.

An RDF vocabulary is a collection of IRIs intended for use in RDF graphs. For example, the IRIs documented in [RDF12-SCHEMA] are the RDF Schema vocabulary. RDF Schema can itself be used to define and document additional RDF vocabularies. Some such vocabularies are mentioned in the RDF 1.2 Primer [RDF12-PRIMER].

The IRIs in an RDF vocabulary often begin with a common substring known as a namespace IRI. Some namespace IRIs are associated by convention with a short name known as a namespace prefix.

In some serialization formats, it is common to associate some namespace IRIs with arbitrary namespace prefixes, and to improve readability by abbreviating IRIs that start with one of those namespace IRIs by using the corresponding namespace prefix. For example, based on the prefix mapping in the table above, the IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral would be abbreviated as rdf:XMLLiteral. Note however that such abbreviations are not meant to be processed directly as IRIs, and are not to be used in syntactic contexts where IRIs are expected. Note also that namespace IRIs and namespace prefixes are not a formal part of the RDF abstract data model. They are merely a syntactic convenience for abbreviating IRIs; for processing, the actual IRIs are reconstructed by replacing each namespace prefix with the corresponding namespace IRI.

The term “namespace” on its own does not have a well-defined meaning in the context of RDF, but is sometimes informally used to mean “namespace IRI” or “RDF vocabulary”.

A triple term is an RDF triple used as an RDF term within another triple. Being an RDF triple, it denotes a proposition.

A reifying triple is a triple where the predicate is rdf:reifies and the object is a triple term. The subject of that triple is called a reifier, and it can be the subject or object of other triples.

A reifier may denote a variety of things that are related to the triple term's proposition, such as a statement or belief that the proposition holds. It is expected that the reifiers (rather than the triple terms) will be used in further statements. This section briefly describes this common usage. For more examples, refer to the RDF 1.2 Primer [RDF12-PRIMER].

For example, the following diagram represents a reifying triple of a triple term, together with a triple that includes the reifier as the subject. The latter describes the reifier as a claim, made by :Bob, that the proposition denoted by the reified triple term holds. In other words, :Bob claims that :Alice's family name is "Liddell".

In this example, the proposition denoted by the triple term (i.e., the proposition that :Alice's family name is "Liddell") is not claimed to be true. That would only be the case if the triple used as a triple term was also an asserted triple in the RDF graph. By using non-asserted triple terms, as in the figure, one can make statements about unasserted statements; for example, if one is unsure whether :Alice's family name is actually "Liddell".

Here is a variation on the graph shown in Figure 3. This represents a graph where an asserted triple corresponds to the triple term object of a reifying triple. In this case, the subset of triples including the reifier as subject—as illustrated in these examples— is called a triple annotation.

Concrete syntaxes, such as Turtle [RDF12-TURTLE], may have shortcuts for specifying reifying triples and triple annotations more succinctly.

Finally, RDF terms that appear in a triple term have the same denotation as when they appear in an asserted triple in the graph. For example, the term :Alice from a triple term and :Alice in an asserted triple both denote the same resource. For this reason, we say that triple terms are transparent.

The RDF abstract data model is atemporal: RDF graphs are static snapshots of information.

However, RDF graphs can express information about events and about temporal aspects of other entities, given appropriate vocabulary terms.

Since RDF graphs are defined as mathematical sets, adding or removing triples from an RDF graph yields a different RDF graph.

We informally use the term RDF source to refer to a persistent yet mutable source or container of RDF graphs. An RDF source is a resource that may be said to have a state that can change over time. A snapshot of the state can be expressed as an RDF graph. For example, any web document that has an RDF-bearing representation may be considered an RDF source. Like all resources, RDF sources may be named with IRIs and therefore described in other RDF graphs.

Intuitively speaking, changes in the universe of discourse can be reflected in the following ways:

• An IRI, once minted, should never change its intended referent. (See URI persistence [WEBARCH].)
• Literals, by design, are constants and never change their value.
• A relationship that holds between two resources at one time may not hold at another time.
• RDF sources may change their state over time. That is, they may provide different RDF graphs at different times.
• Some RDF sources may, however, be immutable snapshots of another RDF source, archiving its state at some point in time.

As RDF graphs are sets of triples, they can be combined easily, supporting the use of data from multiple sources. Nevertheless, it is sometimes desirable to work with multiple RDF graphs while keeping their contents separate. RDF datasets support this requirement.

An RDF dataset is a collection of RDF graphs. All but one of these graphs have an associated IRI or blank node. They are called named graphs, and the IRI or blank node is called the graph name. The remaining graph does not have an associated IRI, and is called the default graph of the RDF dataset.

There are many possible uses for RDF datasets. One such use is to hold snapshots of multiple RDF sources.

An RDF triple denotes a proposition — a simple logical expression, describing a relationship between two entities. An asserted triple is a claim that the corresponding proposition is true. An RDF graph is the conjunction (logical AND) of all the claims made by its asserted triples. The precise details of this meaning of RDF triples and RDF graphs are the subject of RDF 1.2 Semantics [RDF12-SEMANTICS], which yields the following relationships between RDF graphs:

Entailment

An RDF graph A entails another RDF graph B if every possible arrangement of the world that makes A true also makes B true. When A entails B, if the truth of A is presumed or demonstrated then the truth of B is established.

Equivalence

Two RDF graphs A and B are equivalent if they make the same claim about the world. A is equivalent to B if and only if A entails B and B entails A.

Inconsistency

An RDF graph is inconsistent if it contains an internal contradiction. There is no possible arrangement of the world that would make the expression true.

An entailment regime [RDF12-SEMANTICS] is a specification that defines precise conditions that make these relationships hold. RDF itself recognizes only some basic cases of entailment, equivalence and inconsistency. Other specifications, such as RDF 1.2 Schema [RDF12-SCHEMA] and OWL 2 [OWL2-OVERVIEW], add more powerful entailment regimes, as do some domain-specific vocabularies.

This specification does not constrain how implementations use the logical relationships defined by entailment regimes. Implementations may or may not detect inconsistencies, and may make all, some or no entailed information available to users.

An RDF document is a document that encodes an RDF graph or RDF dataset in a concrete RDF syntax, such as N-Triples [RDF12-N-TRIPLES], Turtle [RDF12-TURTLE], RDFa [RDFA-CORE], JSON-LD [JSON-LD11], or TriG [RDF12-TRIG]. RDF documents enable the exchange of RDF graphs and RDF datasets between systems.

A concrete RDF syntax may offer many different ways to encode the same RDF graph or RDF dataset, for example through the use of namespace prefixes, IRI references, blank node identifiers, and different ordering of triples. While these aspects can have great effect on the convenience of working with the RDF document, they are not significant for its meaning.

The basis for concrete RDF syntaxes is the structure of the abstract data model, called the abstract syntax; summarized in the following two tables.

To allow RDF parsers to error or warn about unsupported RDF versions as early as possible, RDF serialization formats are expected to allow a version to be specified, via either a media-type parameter, a version announcement in a format-specific syntax, or both.

When the version is indicated both in a media-type parameter and in syntax, they are expected to be the same. If they differ, parsers use the version from the media-type parameter and might emit a warning about the mismatch.

To retain compability that is as broad as possible with older parsers, only RDF documents that make use of RDF 1.2-specific functionality are encouraged to announce their version (i.e., for RDF documents that do not make use of RDF 1.2-specific functionality it is discouraged to announce a version).

To announce the version in the HTTP responses using the Content-Type header, the server is expected to use the version parameter, as illustrated in the following example response.

HTTP/1.1 200 OK
Content-Type: text/turtle; version=1.2
Location: http://example.com/document.ttl

Servers are also expected to announce the version in-line, when the format supports in-line version announcement (such as RDF 1.2 Turtle [RDF12-TURTLE]).

When requesting an RDF document from an HTTP server, a client can use the version parameter during content negotiation [WEBARCH], by including it in the Accept request header, as illustrated in the following example request.

GET /document.ttl HTTP/1.1
Host: example.com
Accept: text/turtle; version=1.2

Section 2.1 Version Labels defines version labels to be used with the version parameter and in concrete RDF syntax.