The Resource Description Framework (RDF) is a framework for
representing information in the Web.
RDF 1.1 Concepts and Abstract Syntax defines an abstract syntax
(a data model) which serves to link all RDF-based languages and
specifications. The abstract syntax has two key data structures:
RDF graphs are sets of subject-predicate-object triples,
where the elements may be IRIs, blank nodes, or datatyped literals. They
are used to express descriptions of resources. RDF datasets are used
to organize collections of RDF graphs, and comprise a default graph
and zero or more named graphs.
This document also introduces key concepts and terminology, and discusses
datatyping and the handling of fragment identifiers in IRIs within
RDF graphs.
Status of This Document
This section describes the status of this document at the time of its publication. Other
documents may supersede this document. A list of current W3C publications and the latest revision
of this technical report can be found in the W3C technical reports
index at http://www.w3.org/TR/.
This document was published by the RDF Working Group as a Candidate Recommendation.
This document is intended to become a W3C Recommendation.
If you wish to make comments regarding this document, please send them to
public-rdf-comments@w3.org
(subscribe,
archives).
W3C publishes a Candidate Recommendation to indicate that the document is believed
to be stable and to encourage implementation by the developer community. This
Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than
26 November 2013.
All comments are welcome.
Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership.
This is a draft document and may be updated, replaced or obsoleted by other documents at
any time. It is inappropriate to cite this document as other than work in progress.
The following features are at risk and may be changed from normative to non-normative:
The core structure of the abstract syntax 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.
Fig. 1An RDF graph with two nodes (Subject and Object) and a triple connecting them (Predicate)
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
the RDF Semantics specification [RDF-MT].
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. A special kind of literals,
language-tagged strings, denote plain-text strings in a
natural language.
Asserting an RDF triple says that some relationship,
indicated by the predicate, holds between the
resourcesdenoted by
the subject and object. 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 denote specific
resources.
Statements involving
blank nodes say that something with the given
relationships exists, without explicitly naming it.
1.3 The Referent of an IRI
The resourcedenoted 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.
IRIs have global scope: Two different appearances of an IRI
denote the same resource.
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
Organization Ontology
document [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 [LINKED-DATA],
which makes use of the RDF data model and serialization formats.
1.4 RDF Vocabularies and Namespace IRIs
An RDF vocabulary is a collection of IRIs
intended for use in RDF graphs. For example,
the IRIs documented in [RDF-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
Primer [RDF-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. Some examples:
In some serialization formats it is common to abbreviate IRIs
that start with namespace IRIs by using a
namespace prefix in order to assist readability. For example, the IRI
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
would be abbreviated as rdf:XMLLiteral.
Note however that these abbreviations are not valid IRIs,
and must not be used in contexts where IRIs are expected.
Namespace IRIs and namespace prefixes are not a formal part of the
RDF data model. They are merely a syntactic convenience for
abbreviating IRIs.
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”.
1.5 RDF and Change Over Time
The RDF data model is atemporal: It does not deal with time,
and does not have a built-in notion of temporal validity of information.
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:
Literals, by design, are constants and
never change their value.
Some properties may change over time.
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.
1.6 Working with Multiple RDF Graphs
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.
1.7 Equivalence, Entailment and Inconsistency
An RDF triple encodes a statement—a
simple logical expression, or claim about the world.
An RDF graph is the conjunction (logical AND) of
its triples. The precise details of this meaning of RDF triples and graphs are
the subject of the RDF Semantics specification [RDF-MT], which yields the
following relationships between RDF graphs:
Entailment
An RDF graphA 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 graphsA and B
are equivalent if they make the same claim about the world.
A is equivalent to B if and only if
AentailsB 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 [RDF-MT] 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 Schema [RDF-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.
1.8 RDF Documents and Syntaxes
An RDF document is a document that encodes an
RDF graph or RDF dataset in a concrete RDF syntax,
such as Turtle [TURTLE], RDFa [RDFA-PRIMER], JSON-LD [JSON-LD],
RDF/XML [RDF-SYNTAX-GRAMMAR], or N-Triples [N-TRIPLES].
RDF documents enable the exchange of RDF graphs and RDF datasets
between systems.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples,
and notes in this specification are non-normative. Everything else in this specification is
normative.
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY,
and OPTIONAL in this specification are to be interpreted as described in [RFC2119].
This specification, RDF 1.1 Concepts and Abstract Syntax,
defines a data model and related terminology for use in
other specifications, such as
concrete RDF syntaxes,
API specifications, and query languages.
Implementations cannot directly conform to
RDF 1.1 Concepts and Abstract Syntax,
but can conform to such other specifications that normatively
reference terms defined here.
An RDF triple is conventionally written in the order subject,
predicate, object.
The set of nodes of an RDF graph
is the set of subjects and objects of triples in the graph.
It is possible for a predicate IRI to also occur as a node in
the same graph.
IRIs, literals
and blank nodes are distinct and distinguishable.
For example, http://example.org/ as a string literal
is not equal to http://example.org/ as an IRI,
nor to a blank node with the blank node identifierhttp://example.org/.
3.2 IRIs
An IRI
(Internationalized Resource Identifier) within an RDF graph
is a Unicode string [UNICODE] that conforms to the syntax
defined in RFC 3987 [RFC3987].
IRIs in the RDF abstract syntax MUST be absolute, and MAY
contain a fragment identifier.
IRI equality:
Two IRIs are equal if and only if they are equivalent
under Simple String Comparison according to
section 5.1
of [RFC3987]. Further normalization MUST NOT be performed when
comparing IRIs for equality.
Note
URIs and IRIs:
IRIs are a generalization of
URIs
[RFC3986] that permits a wider range of Unicode characters.
Every absolute URI and URL is an IRI, but not every IRI is an URI.
When IRIs are used in operations that are only
defined for URIs, they must first be converted according to
the mapping defined in
section 3.1
of [RFC3987]. A notable example is retrieval over the HTTP
protocol. The mapping involves UTF-8 encoding of non-ASCII
characters, %-encoding of octets not allowed in URIs, and
Punycode-encoding of domain names.
Relative IRIs:
Some concrete RDF syntaxes permit
relative IRIs as a convenient shorthand
that allows authoring of documents independently from their final
publishing location. Relative IRIs must be
resolved
against a base IRI to make them absolute.
Therefore, the RDF graph serialized in such syntaxes is well-defined only
if a base IRI
can be established [RFC3986].
IRI normalization:
Interoperability problems can be avoided by minting
only IRIs that are normalized according to
Section 5
of [RFC3987]. Non-normalized forms that are best avoided
include:
Uppercase characters in scheme names and domain names
Percent-encoding of characters where it is not
required by IRI syntax
Explicitly stated HTTP default port
(http://example.com:80/);
http://example.com/ is preferrable
Completely empty path in HTTP IRIs
(http://example.com);
http://example.com/ is preferrable
“/./” or “/../” in the path
component of an IRI
Lowercase hexadecimal letters within percent-encoding
triplets (“%3F” is preferable over
“%3f”)
Punycode-encoding of Internationalized Domain Names
in IRIs
IRIs that are not in Unicode Normalization
Form C [NFC]
3.3 Literals
Literals are used for values such as strings, numbers and dates.
A literal in an RDF graph consists of two or three
elements:
a lexical form, being a Unicode [UNICODE] string,
which SHOULD be in Normal Form C [NFC],
a datatype IRI, being an IRI identifying a
datatype that determines how the lexical form maps to a
literal value.
A literal is a language-tagged string if and only if its
datatype IRI is
http://www.w3.org/1999/02/22-rdf-syntax-ns#langString,
and only in this case the third element is present:
a non-empty language tag as defined by [BCP47].
The language tag MUST be well-formed according to
section 2.2.9
of [BCP47]. Lexical representations of language tags MAY be converted to
lower case. The value space of language tags is always in lower case.
A badly formed language tag MUST be treated as a syntax error.
Note
Implementors might wish to note that language tags conform to the
regular expression ’@’ [a-zA-Z]{1,8} (’-’
[a-zA-Z0-9]{1,8})*
before normalizing to lowercase.
Multiple literals may have the same lexical form.
Concrete syntaxes MAY support simple
literals, consisting of only a lexical form
without any datatype IRI or language tag. Simple literals only
exist in concrete syntaxes, and are treated as
syntactic sugar for abstract syntax
literals with the datatype IRIhttp://www.w3.org/2001/XMLSchema#string.
Literal term equality: Two literals are term-equal
(the same RDF literal) if and only if the two lexical forms, the
two datatype IRIs, and the two language tags (if any) compare equal,
character by character.
Two literals can have the same value without being the same
RDF term. For example:
"1"^^xs:integer
"01"^^xs:integer
denote the same value, but are not the same literal
RDF terms and are not term-equals.
Otherwise, the literal is ill-typed,
and no literal value can be associated with the literal. Such a case
produces a semantic inconsistency but is not syntactically
ill-formed and implementations MUST accept ill-typed literals and produce
RDF graphs from them. Implementations MAY produce warnings when
encountering ill-typed literals.
3.4 Blank Nodes
Blank nodes are disjoint from
IRIs and literals. Otherwise,
the set of possible blank nodes is arbitrary. RDF makes no reference to
any internal structure of blank nodes.
Note
Blank node identifiers
are local identifiers that are used in some
concrete RDF syntaxes
or RDF store implementations.
They are always locally scoped to the file or RDF store,
and are not persistent or portable identifiers
for blank nodes. Blank node identifiers are not
part of the RDF abstract syntax, but are entirely dependent
on the concrete syntax or implementation. The syntactic restrictions
on blank node identifiers, if any, therefore also depend on
the concrete RDF syntax or implementation. Implementations that handle blank node
identifiers in concrete syntaxes need to be careful not to create the
same blank node from multiple occurences of the same blank node identifier
except in situations where this is supported by the syntax.
3.5 Replacing Blank Nodes with IRIs
Blank nodes do not have identifiers in the RDF abstract syntax. The
blank node identifiers introduced
by some concrete syntaxes have only
local scope and are purely an artifact of the serialization.
In situations where stronger identification is needed, systems MAY
systematically replace some or all of the blank nodes in an RDF graph
with IRIs. Systems wishing to do this SHOULD
mint a new, globally
unique IRI (a Skolem IRI) for each blank node so replaced.
This transformation does not appreciably change the meaning of an
RDF graph, provided that the Skolem IRIs do not occur anywhere else.
It does however permit the possibility of other graphs
subsequently using the Skolem IRIs, which is not possible
for blank nodes.
Systems may wish to mint Skolem IRIs in such a way that they can
recognize the IRIs as having been introduced solely to replace blank
nodes. This allows a system to map IRIs back to blank nodes
if needed.
Systems that want Skolem IRIs to be recognizable outside of the system
boundaries SHOULD use a well-known IRI [RFC5785] with the registered
name genid. This is an IRI that uses the HTTP or HTTPS scheme,
or another scheme that has been specified to use well-known IRIs; and whose
path component starts with /.well-known/genid/.
For example, the authority responsible for the domain
example.com could mint the following recognizable Skolem IRI:
RFC 5785 [RFC5785] only specifies well-known URIs,
not IRIs. For the purpose of this document, a well-known IRI is any
IRI that results in a well-known URI after IRI-to-URI mapping [RFC3987].
3.6 Graph Comparison
Two
RDF graphsG and G' are
isomorphic (that is, they have an identical
form) if there is a bijection M between the sets of nodes of the two
graphs, such that:
M maps blank nodes to blank nodes.
M(lit)=lit for all RDF literalslit which
are nodes of G.
With this definition, M shows how each blank node
in G can be replaced with
a new blank node to give G'. Graph isomorphism
is needed to support the RDF Test Cases [RDF-TESTCASES] specification.
4. RDF Datasets
An RDF dataset is a collection of
RDF graphs, and comprises:
Exactly one default graph, being an RDF graph.
The default graph does not have a name and MAY be empty.
Zero or more named graphs.
Each named graph is a pair consisting of an IRI or a blank node
(the graph name), and an RDF graph.
Graph names are unique within an RDF dataset.
Despite the use of the word “name”
in “named graph”, the graph name does not formally
denote the graph. It is merely syntactically paired with
the graph. RDF does not place any formal restrictions on what
resource the graph name may denote, nor on the relationship between
that resource and the graph.
Some RDF dataset
implementations do not track empty named graphs.
Applications can avoid interoperability issues by not
ascribing importance to the presence or absence of empty named graphs.
Blank nodes as graph names are new. Existing SPARQL implementations
might not accept this new feature for some time, so the use of blank
nodes as graph names can cause interoperability problems.
Skolemizing blank nodes used as
graph names can be used to overcome these interoperability problems.
4.1 RDF Dataset Comparison
Two RDF datasets
(the RDF dataset D1 with default graph DG1 and any named
graph NG1 and the RDF dataset D2 with default graph
DG2 and any named graph NG2)
are dataset-isomorphic if and only if
there is a bijection M between the nodes, triples and graphs in
D1 and those in D2 such that:
M maps blank nodes to blank nodes;
M is the identity map on literals and URIs;
For every triple <s p o>, M(<s, p, o>)=
<M(s), M(p), M(o)>;
For every graph G={t1, ..., tn},
M(G)={M(t1), ..., M(tn)};
DG2 = M(DG1); and
<n, G> is in NG1 if and only if
<M(n), M(G)> is in NG2.
4.2 Content Negotiation of RDF Datasets
This section is non-normative.
Primary resources may have multiple representations that are
made available via
content negotiation
[WEBARCH]. A representation may be returned in an RDF serialization
format that supports the expression of both RDF datasets and
RDF graphs. If an RDF dataset
is returned and the consumer is expecting an RDF graph,
the consumer is expected to use the RDF dataset's default graph.
5. Datatypes
Datatypes are used with RDF literals
to represent values such as strings, numbers and dates.
The datatype abstraction used in RDF is compatible with XML Schema
[XMLSCHEMA11-2]. Any datatype definition that conforms
to this abstraction MAY be used in RDF, even if not defined
in terms of XML Schema. RDF re-uses many of the XML Schema
built-in datatypes,
and provides two additional built-in datatypes,
rdf:HTML and rdf:XMLLiteral.
The list of datatypes supported by an implementation is determined
by its recognized datatype IRIs.
The lexical space of a datatype is a set of Unicode [UNICODE] strings.
The lexical-to-value mapping of a datatype is a set of
pairs whose first element belongs to the lexical space,
and the second element belongs to the value space
of the datatype. Each member of the lexical space is paired with exactly
one value, and is a lexical representation
of that value. The mapping can be seen as a function
from the lexical space to the value space.
Note
Language-tagged
strings have the datatype IRIhttp://www.w3.org/1999/02/22-rdf-syntax-ns#langString.
No datatype is formally defined for this IRI because the definition
of datatypes does not accommodate
language tags in the lexical space.
The value space associated with this datatype IRI is the set
of all pairs of strings and language tags.
For example, the XML Schema datatype xsd:boolean,
where each member of the value space has two lexical
representations, is defined as follows:
The literals that can be defined using this
datatype are:
This table lists the literals of type xsd:boolean.
Literal
Value
<“true”, xsd:boolean>
true
<“false”, xsd:boolean>
false
<“1”, xsd:boolean>
true
<“0”, xsd:boolean>
false
5.1 The XML Schema Built-in Datatypes
IRIs of the form
http://www.w3.org/2001/XMLSchema#xxx,
where xxx
is the name of a datatype, denote the built-in datatypes defined in
XML Schema 1.1 Part 2:
Datatypes [XMLSCHEMA11-2]. The XML Schema built-in types
listed in the following table are the
RDF-compatible XSD types. Their use is RECOMMENDED.
Readers might note that the xsd:hexBinary and xsd:base64Binary
datatypes are the only safe datatypes for transferring binary
information.
A list of the RDF-compatible XSD types, with short descriptions"
The rdf:HTML datatype is at risk of being changed from normative to non-normative
because the definitions in [DOM4] and thus the lexical-to-value mapping are not yet stable.
Consequently interoperability can not be guaranteed at this point in time. Please send feedback
to public-rdf-comments@w3.org.
RDF provides for HTML content as a possible literal value.
This allows markup in literal values. Such content is indicated
in an RDF graph using a literal whose datatype
is a special built-in datatype rdf:HTML.
This datatype is defined as follows:
An IRI denoting this datatype
is http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML.
Any language annotation (lang="…") or
XML namespaces (xmlns) desired in the HTML content
must be included explicitly in the HTML literal. Relative URLs
in attributes such as href do not have a well-defined
base URL and are best avoided.
RDF applications may use additional equivalence relations,
such as that which relates an xsd:string with an
rdf:HTML literal corresponding to a single text node
of the same string.
5.3 The rdf:XMLLiteral Datatype
Feature at Risk 2
The rdf:XMLLiteral datatype is at risk of being changed from normative to non-normative
because the definitions in [DOM4] and thus the lexical-to-value mapping are not yet stable.
Consequently interoperability can not be guaranteed at this point in time. Please send feedback
to public-rdf-comments@w3.org.
RDF provides for XML content as a possible literal value.
Such content is indicated in an RDF graph using a literal
whose datatype is a special built-in datatype
rdf:XMLLiteral, which is defined as follows:
is the set of all strings which are well-balanced, self-contained
XML content
[XML10]; and for which embedding between an arbitrary
XML start tag and an end tag yields a document conforming to
XML Namespaces
[XML-NAMES].
Any XML namespace declarations (xmlns),
language annotation (xml:lang) or base URI
declarations (xml:base) desired in the
XML content must be included explicitly in the XML literal.
Note that some concrete RDF syntaxes may define mechanisms
for inheriting them from the context
(e.g., @parseType="literal"
in RDF/XML [RDF-SYNTAX-GRAMMAR]).
5.4 Datatype IRIs
Datatypes are identified by IRIs. If
D is a set of IRIs which are used to refer to
datatypes, then the elements of D are called recognized
datatype IRIs. Recognized IRIs have fixed
referents, which MUST satisfy these
conditions:
If the IRI
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
is recognized then it refers to the datatype
rdf:XMLLiteral;
If the IRI
http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML
is recognized then it refers to the datatype rdf:HTML;
If any IRI of the form
http://www.w3.org/2001/XMLSchema#xxx
is recognized then it refers to the RDF-compatible XSD type
named xsd:xxx, for every XSD type listed in
section 5.1.
Note
Semantic extensions of RDF might choose to
recognize other datatype IRIs
and require them to refer to a fixed datatype. See the RDF
Semantics specification [RDF-MT] for more information on
semantic extensions.
RDF processors are not required to recognize datatype IRIs.
Any literal typed with an unrecognized IRI is treated just like
an unknown IRI, i.e. as referring to an unknown thing. Applications
MAY give a warning message if they are unable to determine the
referent of an IRI used in a typed literal, but they SHOULD NOT
reject such RDF as either a syntactic or semantic error.
Other specifications
MAY impose additional constraints on datatype IRIs,
for example, require support for certain datatypes.
RDF uses IRIs, which may include
fragment identifiers, as resource identifiers.
The semantics of fragment identifiers is
defined in
RFC 3986 [RFC3986]: They identify a secondary resource
that is usually a part of, view of, defined in, or described in
the primary resource, and the precise semantics depend on the set
of representations that might result from a retrieval action
on the primary resource.
This section discusses the handling of fragment identifiers
in representations that encode RDF graphs.
In RDF-bearing representations of a primary resource
<foo>,
the secondary resource identified by a fragment bar
is the resourcedenoted by the
full IRI<foo#bar> in the RDF graph.
Since IRIs in RDF graphs can denote anything, this can be
something external to the representation, or even external
to the web.
In this way, the RDF-bearing representation acts as an intermediary
between the web-accessible primary resource, and some set of possibly
non-web or abstract entities that the RDF graph may describe.
In cases where other specifications constrain the semantics of
fragment identifiers in RDF-bearing representations, the encoded
RDF graph should use fragment identifiers in a way that is consistent
with these constraints. For example, in an HTML+RDFa document [HTML-RDFA],
the fragment chapter1 may identify a document section
via the semantics of HTML's @name or @id
attributes. The IRI<#chapter1> should
then be taken to denote that same section in any RDFa-encoded
triples within the same document.
Similarly, if the @xml:id attribute [XML-ID] is used
in an RDF/XML document, then the corresponding IRI
should be taken to denote an XML element.
Primary resources may have multiple representations that are
made available via
content negotiation
[WEBARCH]. Fragments in RDF-bearing representations
should be used in a way that is consistent with the semantics imposed by any
non-RDF representations. For example, if the fragment
chapter1 identifies a document section in an
HTML representation of the primary resource, then the IRI<#chapter1>
should be taken to denote that same section in all RDF-bearing
representations of the same primary resource.
7. Generalized RDF Triples, Graphs, and Datasets
This section is non-normative.
It is sometimes convenient to loosen the requirements
on RDF triples. For example, the completeness
of the RDFS entailment rules is easier to show with a
generalization of RDF triples.
A generalized RDF
triple is a triple having a subject, a predicate,
and object, where each can be an IRI, a
blank node or a
literal. A
generalized RDF graph
is a set of generalized RDF triples. A
generalized RDF dataset
comprises a distinguished generalized RDF graph, and zero
or more pairs each associating an IRI, a blank node or a literal
to a generalized RDF graph.
Generalized RDF triples, graphs, and datasets differ
from normative RDF triples,
graphs, and
datasets only
by allowing IRIs,
blank nodes and
literals to appear
in any position, i.e., as subject, predicate, object or graph names.
Note
Any users of
generalized RDF triples, graphs or datasets need to be
aware that these notions are non-standard extensions of
RDF and their use may cause interoperability problems.
There is no requirement on the part of any RDF tool to
accept, process, or produce anything beyond standard RDF
triples, graphs, and datasets.
8. Acknowledgments
This section is non-normative.
The RDF 1.1 editors acknowledge valuable contributions from
Thomas Baker, Dan Brickley, Gavin Carothers, Jeremy Carroll,
Pierre-Antoine Champin, Dan Connolly, Tim Berners-Lee,
John Cowan, Martin J. Dürst, Alex Hall, Steve Harris, Pat Hayes,
Ivan Herman, Peter F. Patel-Schneider, Addison Phillips,
Eric Prud'hommeaux, Andy Seaborne, Leif Halvard Silli,
Nathan Rixham, Dominik Tomaszuk and Antoine Zimmermann.
The RDF 2004 editors acknowledge valuable contributions from
Frank Manola, Pat Hayes, Dan Brickley, Jos de Roo, Sergey Melnik,
Dave Beckett, Patrick Stickler, Peter F. Patel-Schneider, Jerome Euzenat,
Massimo Marchiori, Tim Berners-Lee, Dave Reynolds and Dan Connolly.
Editors of the 2004 version of this specification were Graham Klyne
and Jeremy J. Carroll. Brian McBride served as series editor for
the 2004 RDF specifications.
Previous versions of RDF used the term
“RDF URI Reference” instead of “IRI” and allowed
additional characters:
“<”, “>”,
“{”, “}”,
“|”, “\”,
“^”, “`”,
‘“’ (double quote), and “” (space).
In IRIs, these characters must be percent-encoded as
described in section 2.1
of [RFC3986].
In earlier versions of RDF, literals
with a language tag did not have a datatype IRI, and
simple literals could appear
directly in the abstract syntax. Simple literals and literals with a
language tag were collectively known as
plain literals.
Earlier versions of RDF permitted
language tags that
adhered to the generic tag/subtag syntax of language tags,
but were not well-formed according to [BCP47]. Such
language tags do not conform to RDF 1.1.
The xsd:string datatype does not
permit the #x0 character, and implementations might not permit
control codes in the #x1-#x1F range. Earlier versions of
RDF allowed these characters in
simple literals, although they
could never be serialized in a W3C-recommended concrete syntax.
Currently a literal with type xsd:string containing the #x0 character
is an ill-typed literal.
2013-10-30: Mark rdf:rdf:HTML and rdf:XMLLiteral as at risk.
2013010-21: Added Markus Lanthaler as editor. Minor editorial updates (e.g. repair of broken links). Updates to sections 1.2, 1.3, 3.1, 3.2, 3.3, 4.1 and 5.4 to address comments from Michael Schneider (ISSUE-161)
2013-10-16: Fixed ReSpec issue regarding previous editor attributions
and added previous editors to acknowledgements to address ISSUE-150.
2012-11-17: Reverted section on Blank Nodes to earlier state
2012-11-17: Changes, mostly but not exclusively editorial, to section on Fragment Identifiers
2012-11-13: Remove the notion of other specs conforming to this spec from the Conformance section. This spec simply provides definitions that other specs can use.
2012-11-09: Re-wrote the section on Blank Nodes, including a definition of “fresh blank nodes” and an extended Note on standardizing apart blank node IDs
2012-11-09: Moved all informative material about changes between RDF 2004 and RDF 1.1 to a new appendix
2012-05-14: Replaced the example graph diagram in Section 1.1 with a re-drawn SVG version, with support from Dominik Tomaszuk
2012-05-10: New Conformance section to explain that this specification is not implemented directly, but through other specifications that use our definitions
2012-05-10: Simplified rdf:XMLLiteral's new value space slightly after feedback from Ivan Herman and Arnaud Le Hors.
2012-05-09: Removed an example from the conformance section that didn't make sense any more with the modified rdf:XMLLiteral. Added some new issue boxes.
2012-05-09: rdf:XMLLiteral no longer requires lexical forms to be canonicalized, and the value space is now defined in terms of [DOM-LEVEL-3-CORE] (ISSUE-13)
2012-05-09: Removed Section 3 RDF Vocabulary IRI and Namespace; its contents will be folded into the RDF Schema document
2012-04-26: Remove normative definition of “property” as it disagreed with RDF Semantics; small editorial changes.
2011-11-21: Updated XHTML 1.0 reference to XHTML 1.1
2011-11-20: Added table of RDF-compatible XSD types, and definition of datatype map, both adapted from previous content in [RDF-MT]
2011-11-18: Replaced informative Introduction and RDF Concepts sections with a new extended introduction. Folded some content from RDF Concepts into the later normative sections, mostly as examples and notes.
2011-11-09: Updated the two sections on literals to reflect the ISSUE-71 resolution that literals with language tag now have the datatype IRI rdf:langString. Formally introduced the term “language-tagged string”.
2011-11-09: Add a note that explains that #x0-#x1F are no longer allowed in simple literals
2011-08-13: Updated Turtle reference to Turtle FPWD
2011-07-21: Condensed the 2004 acknowledgements
2011-07-21: Updated the two sections on literals to reflect the ISSUE-12 resolution that simple literals are no longer part of the abstract syntax. Formally introduced the terms “language-tagged literal”, “simple literal”.
2011-07-21: Updated the introduction, and removed many mentions of RDF/XML. Changed the normative reference for the terms in the RDF namespace from the RDF/XML spec to the RDF Schema spec. Removed any mention of the 1999 version of RDF.
2011-07-21: Replaced RFC 2279 reference (UTF-8) with RFC 3629
2011-07-20: Removed informative sections “Motivations and Goals” (see RDF 2004 version) and “RDF Expression of Simple Facts” (see RDF 2004 version)
2011-06-01: Replaced the URI References section with new section on IRIs, and changed “RDF URI Reference” to “IRI” throughout the document.
2011-06-01: Changed language tag definition to require well-formedness according to BCP47; added a note that this invalidates some RDF
2011-05-25: Added boxes for known WG issues throught the document
2011-05-25: Deleted “Structure of this Document” section, it added no value beyond the TOC
