This document is also available in this non-normative format: diff to previous version
Copyright
©
2004-2013
2004-2014
W3C
®
(
MIT
,
ERCIM
,
Keio
,
Beihang
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
use
rules
apply.
The
Resource
Description
Framework
(RDF)
is
a
framework
for
representing
information
in
the
Web.
RDF
1.1
Concepts
and
Abstract
Syntax
This
document
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
RDF 1.1
Concepts
and
Abstract
Syntax
also
introduces
key
concepts
and
terminology,
and
discusses
datatyping
and
the
handling
of
fragment
identifiers
in
IRIs
within
RDF
graphs.
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/.
The
following
features
are
at
risk
and
may
be
changed
from
normative
to
non-normative:
The
rdf:HTML
datatype
may
be
made
non-normative
The
rdf:XMLLiteral
datatype
may
be
made
non-normative
This document is a part of the RDF 1.1 document suite. The RDF Working Group welcomes comments and reports of implementations in general, but given the nature of this document (as a conceptual overview), the group is not expecting to track implementations of this document on its own.
This
document
was
published
by
the
RDF
Working
Group
as
a
Candidate
Proposed
Recommendation.
This
document
is
intended
to
become
a
W3C
Recommendation.
If
you
wish
The
W3C
Membership
and
other
interested
parties
are
invited
to
make
comments
regarding
this
document,
please
review
the
document
and
send
them
comments
to
public-rdf-comments@w3.org
(
subscribe
,
archives
).
W3C
publishes
a
Candidate
Recommendation
to
indicate
)
through
09
February
2014.
Advisory
Committee
Representatives
should
consult
their
WBS
questionnaires
.
Note
that
the
document
is
believed
to
be
stable
and
to
encourage
implementation
by
the
developer
community.
This
Candidate
Recommendation
is
substantive
technical
comments
were
expected
to
advance
to
Proposed
Recommendation
no
earlier
than
26
November
during
the
Last
Call
review
period
that
ended
06
September
2013.
All
comments
are
welcome.
Please see the Working Group's implementation report .
Publication
as
a
Candidate
Proposed
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.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This section is non-normative.
The Resource Description Framework (RDF) is a framework for representing information in the Web.
This document defines an abstract syntax (a data model) which serves to link all RDF-based languages and specifications, including:
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.
There can be three kinds of nodes in an RDF graph : IRIs , literals , and blank nodes .
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
[
RDF11-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
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 resources denoted 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
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
informal,
and
partial
account
follows:
http://www.w3.org/ns/org#
.
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.
An
RDF
vocabulary
is
a
collection
of
IRIs
intended
for
use
in
RDF
graphs
.
For
example,
the
IRIs
documented
in
[
RDF-SCHEMA
RDF11-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
RDF11-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:
Namespace prefix | Namespace IRI | RDF vocabulary |
---|---|---|
rdf |
http://www.w3.org/1999/02/22-rdf-syntax-ns#
|
The
RDF
built-in
vocabulary
[
|
rdfs |
http://www.w3.org/2000/01/rdf-schema#
|
The
RDF
Schema
vocabulary
[
|
xsd |
http://www.w3.org/2001/XMLSchema#
|
The RDF-compatible XSD types |
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 ”.
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:
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 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 [ RDF11-MT ], which yields the following relationships between RDF graph s:
An
entailment
regime
[
RDF11-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
RDF11-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
Turtle
[
TURTLE
],
RDFa
[
RDFA-PRIMER
],
JSON-LD
[
JSON-LD
],
RDF/XML
[
RDF-SYNTAX-GRAMMAR
],
or
N-Triples
TriG
[
N-TRIPLES
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 , relative IRIs, blank node identifiers , and different ordering of statements. While these aspects can have great effect on the convenience of working with the RDF document , they are not significant for its meaning.
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 graph is a set of RDF triples .
An RDF triple consists of three components:
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 collectively known as RDF terms .
IRIs
,
literals
and
blank
nodes
are
distinct
and
distinguishable.
For
example,
http://example.org/
as
a
string
literal
is
not
neither
equal
to
http://example.org/
as
an
IRI
,
nor
to
a
blank
node
with
the
blank
node
identifier
http://example.org/
.
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.
URIs and IRIs: IRIs are a generalization of URI s [ 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:
http://example.com:80/
);
http://example.com/
is
http://example.com
);
http://example.com/
is
/./
”
or
“
/../
”
in
the
path
component
of
an
IRI
%3F
”
is
preferable
over
“
%3f
”)
Literals
are
used
for
values
such
as
strings,
numbers
numbers,
and
dates.
A literal in an RDF graph consists of two or three elements:
http://www.w3.org/1999/02/22-rdf-syntax-ns#langString
,
A
literal
is
a
language-tagged
string
if
the
third
element
is
present.
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
Please
note
that
concrete
syntaxes
MAY
support
simple
literals
,
consisting
of
only
a
lexical
form
without
any
datatype
IRI
or
language
tag.
tag
.
Simple
literals
only
exist
in
concrete
syntaxes,
and
are
treated
as
syntactic
sugar
for
abstract
syntax
literals
with
the
datatype
IRI
http://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
Similarly,
most
concrete
syntaxes
represent
language-tagged
strings
(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
datatype
IRI
and
are
not
term-equals.
because
it
always
equals
http://www.w3.org/1999/02/22-rdf-syntax-ns#langString
.
The literal value associated with a literal is:
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. Thus, 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-equal because their lexical form differs.
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.
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
occurrences
of
the
same
blank
node
identifier
except
in
situations
where
this
is
supported
by
the
syntax.
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
:
http://example.com/.well-known/genid/d26a2d0e98334696f4ad70a677abc1f6
Two RDF graphs G 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:
See also: IRI equality , literal term equality .
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
RDF11-TESTCASES
]
specification.
An RDF dataset is a collection of RDF graphs , and comprises:
Blank
nodes
MAY
can
be
shared
between
graphs
in
an
RDF
dataset
.
Despite
the
use
of
the
word
“name”
in
“
named
graph
”,
the
graph
name
does
is
not
formally
required
to
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.
A
discussion
of
different
RDF
dataset
semantics
can
be
found
in
[
RDF11-DATASETS
].
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.
SPARQL
1.1
[
SPARQL11-OVERVIEW
]
also
defines
the
concept
of
an
RDF
Dataset.
The
definition
of
an
RDF
Dataset
in
SPARQL
1.1
and
this
specification
differ
slightly
in
that
this
specification
allows
RDF
Graphs
to
be
identified
using
either
an
IRI
or
a
blank
node.
SPARQL
1.1
Query
Language
only
allows
RDF
Graphs
to
be
identified
using
an
IRI
.
Existing
SPARQL
implementations
might
not
accept
this
new
feature
allow
blank
nodes
to
be
used
to
identify
RDF
Graphs
for
some
time,
so
the
their
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.
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:
This section is non-normative.
Primary
Web
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.
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
defines
two
additional
built-in
non-normative
datatypes,
rdf:HTML
and
rdf:XMLLiteral
.
The
list
of
datatypes
supported
by
an
implementation
is
determined
by
its
recognized
datatype
IRIs
.
A datatype consists of a lexical space , a value space and a lexical-to-value mapping , and is denoted by one or more 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.
Language-tagged
strings
have
the
datatype
IRI
http://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:
true
”,
“
false
”,
“
1
”,
“
0
”}
true
”,
true
>,
<“
false
”,
false
>,
<“
1
”,
true
>,
<“
0
”,
false
>,
}
The literals that can be defined using this datatype are:
Literal | Value |
---|---|
<“
true
”,
xsd:boolean
>
|
true |
<“
false
”,
xsd:boolean
>
|
false |
<“
1
”,
xsd:boolean
>
|
true |
<“
0
”,
xsd:boolean
>
|
false |
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.
Datatype | Value space (informative) | |
---|---|---|
Core types |
xsd:string
|
Character strings (but not all Unicode character strings) |
xsd:boolean
|
true, false | |
xsd:decimal
|
Arbitrary-precision decimal numbers | |
xsd:integer
|
Arbitrary-size integer numbers | |
IEEE
floating-point
numbers |
xsd:double
|
64-bit floating point numbers incl. ±Inf, ±0, NaN |
xsd:float
|
32-bit floating point numbers incl. ±Inf, ±0, NaN | |
Time and date |
xsd:date
|
Dates (yyyy-mm-dd) with or without timezone |
xsd:time
|
Times (hh:mm:ss.sss…) with or without timezone | |
xsd:dateTime
|
Date and time with or without timezone | |
xsd:dateTimeStamp
|
Date and time with required timezone | |
Recurring
and
partial dates |
xsd:gYear
|
Gregorian calendar year |
xsd:gMonth
|
Gregorian calendar month | |
xsd:gDay
|
Gregorian calendar day of the month | |
xsd:gYearMonth
|
Gregorian calendar year and month | |
xsd:gMonthDay
|
Gregorian calendar month and day | |
xsd:duration
|
Duration of time | |
xsd:yearMonthDuration
|
Duration of time (months and years only) | |
xsd:dayTimeDuration
|
Duration of time (days, hours, minutes, seconds only) | |
Limited-range
integer numbers |
xsd:byte
|
-128…+127 (8 bit) |
xsd:short
|
-32768…+32767 (16 bit) | |
xsd:int
|
-2147483648…+2147483647 (32 bit) | |
xsd:long
|
-9223372036854775808…+9223372036854775807 (64 bit) | |
xsd:unsignedByte
|
0…255 (8 bit) | |
xsd:unsignedShort
|
0…65535 (16 bit) | |
xsd:unsignedInt
|
0…4294967295 (32 bit) | |
xsd:unsignedLong
|
0…18446744073709551615 (64 bit) | |
xsd:positiveInteger
|
Integer numbers >0 | |
xsd:nonNegativeInteger
|
Integer numbers ≥0 | |
xsd:negativeInteger
|
Integer numbers <0 | |
xsd:nonPositiveInteger
|
Integer numbers ≤0 | |
Encoded binary data |
xsd:hexBinary
|
Hex-encoded binary data |
xsd:base64Binary
|
Base64-encoded binary data | |
Miscellaneous
XSD types |
xsd:anyURI
|
Absolute or relative URIs and IRIs |
xsd:language
|
Language tags per [ BCP47 ] | |
xsd:normalizedString
|
Whitespace-normalized strings | |
xsd:token
|
Tokenized strings | |
xsd:NMTOKEN
|
XML NMTOKENs | |
xsd:Name
|
XML Names | |
xsd:NCName
|
XML NCNames |
The
other
built-in
XML
Schema
datatypes
are
unsuitable
for
various
reasons,
reasons
and
SHOULD
NOT
be
used.
used:
xsd:QName
and
xsd:ENTITY
require
an
enclosing
XML
document
context.
xsd:ID
and
xsd:IDREF
are
for
cross
references
within
an
XML
document.
xsd:NOTATION
is
not
intended
for
direct
use.
xsd:IDREFS
,
xsd:ENTITIES
and
xsd:NMTOKENS
are
sequence-valued
datatypes
which
do
not
fit
the
RDF
datatype
model.
rdf:HTML
Datatype
The
rdf:HTML
datatype
is
at
risk
of
being
changed
from
normative
to
non-normative
because
the
definitions
in
[
DOM4
This
section
is
non-normative.
]
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
set
to
rdf:HTML
.
This
datatype
is
defined
as
non-normative
because
it
depends
on
[
DOM4
],
a
specification
that
has
not
yet
reached
W3C
Recommendation
status.
The
rdf:HTML
datatype
is
defined
as
follows:
http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML
.
DocumentFragment
nodes
[
DOM4
].
Two
DocumentFragment
nodes
A
and
B
are
considered
equal
if
and
only
if
the
DOM
method
A
.
isEqualNode
(
B
)
[
DOM4
]
returns
true
.
Each member of the lexical space is associated with the result of applying the following algorithm:
domnodes
be
the
list
of
DOM
nodes
[
DOM4
]
that
result
from
applying
the
HTML
fragment
parsing
algorithm
[
HTML5
]
to
the
input
string,
without
a
context
element.
domfrag
be
a
DOM
DocumentFragment
[
DOM4
]
whose
childNodes
attribute
is
equal
to
domnodes
domfrag.
normalize
()
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.
rdf:XMLLiteral
Datatype
The
rdf:XMLLiteral
datatype
is
at
risk
of
being
changed
from
normative
to
non-normative
because
the
definitions
in
[
DOM4
This
section
is
non-normative.
]
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
set
to
rdf:XMLLiteral
.
This
datatype
is
defined
as
non-normative
because
it
depends
on
[
DOM4
],
a
specification
that
has
not
yet
reached
W3C
Recommendation
status.
,
which
The
rdf:XMLLiteral
datatype
is
defined
as
follows:
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
.
DocumentFragment
nodes
[
DOM4
].
Two
DocumentFragment
nodes
A
and
B
are
considered
equal
if
and
only
if
the
DOM
method
A
.
isEqualNode
(
B
)
returns
true
.
Each member of the lexical space is associated with the result of applying the following algorithm:
domfrag
be
a
DOM
DocumentFragment
node
[
DOM4
]
corresponding
to
the
input
string
domfrag.
normalize
()
rdf:XMLLiteral
canonical
mapping
is
the
exclusive
XML
canonicalization
method
(
with
comments,
with
empty
InclusiveNamespaces
PrefixList
)
[
XML-EXC-C14N
].
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
RDF11-XML
]).
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
any
IRI
of
the
form
is
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
http://www.w3.org/2001/XMLSchema#xxx
recognized
then
recognized,
it
refers
MUST
refer
to
the
datatype
RDF-compatible
XSD
type
named
rdf:XMLLiteral
xsd:xxx
;
If
for
every
XSD
type
listed
in
section
5.1
.
Furthermore,
the
following
IRIs
are
allocated
for
non-normative
datatypes:
http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
rdf:HTML
rdf:XMLLiteral
http://www.w3.org/2001/XMLSchema#xxx
http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML
xsd:xxx
,
for
every
XSD
type
listed
in
section
5.1
.
rdf:HTML
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 [ RDF11-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.
The Web Ontology Language [ OWL2-OVERVIEW ] offers facilities for formally defining custom datatypes that can be used with RDF. Furthermore, a practice for identifying user-defined simple XML Schema datatypes is suggested in [ SWBP-XSCH-DATATYPES ]. RDF implementations are not required to support either of these facilities.
This section is non-normative.
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
resource
denoted
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
fragment
identifiers
should
be
taken
to
denote
an
XML
element.
Primary
used
consistently
in
resources
may
have
with
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.
This section is non-normative.
It is sometimes convenient to loosen the requirements on RDF triple s. 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.
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.
This section is non-normative.
The
RDF
1.1
editors
acknowledge
valuable
contributions
from
Thomas
Baker,
Tim
Berners-Lee,
David
Booth,
Dan
Brickley,
Gavin
Carothers,
Jeremy
Carroll,
Pierre-Antoine
Champin,
Dan
Connolly,
Tim
Berners-Lee,
John
Cowan,
Martin
J.
Dürst,
Alex
Hall,
Steve
Harris,
Sandro
Hawke,
Pat
Hayes,
Ivan
Herman,
Peter
F.
Patel-Schneider,
Addison
Phillips,
Eric
Prud'hommeaux,
Nathan
Rixham,
Andy
Seaborne,
Leif
Halvard
Silli,
Nathan
Rixham,
Guus
Schreiber,
Dominik
Tomaszuk
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.
This
specification
is
a
product
of
extended
deliberations
by
the
members
membership
of
the
RDF
Working
Group
.
It
draws
upon
two
earlier
specifications,
RDF
Model
and
Syntax
,
edited
by
Ora
Lassilla
and
Ralph
Swick,
and
RDF
Schema
,
edited
by
included
Thomas
Baker,
Scott
Bauer,
Dan
Brickley
and
R.
V.
Guha,
which
were
produced
by
members
of
the
RDFcore
Brickley,
Gavin
Carothers,
Pierre-Antoine
Champin,
Olivier
Corby,
Richard
Cyganiak,
Souripriya
Das,
Ian
Davis,
Lee
Feigenbaum,
Fabien
Gandon,
Charles
Greer,
Alex
Hall,
Steve
Harris,
Sandro
Hawke,
Pat
Hayes,
Ivan
Herman,
Nicholas
Humfrey,
Kingsley
Idehen,
Gregg
Kellogg,
Markus
Lanthaler,
Arnaud
Le
Hors,
Peter
F.
Patel-Schneider,
Eric
Prud'hommeaux,
Yves
Raimond,
Nathan
Rixham,
Guus
Schreiber,
Andy
Seaborne,
Manu
Sporny,
Thomas
Steiner,
Ted
Thibodeau,
Mischa
Tuffield,
William
Waites,
Jan
Wielemaker,
David
Wood,
Zhe
Wu,
and
Schema
Working
Groups
.
Antoine
Zimmermann.
This section is non-normative.
This
section
discusses
changes
between
the
2004
Recommendation
of
RDF
Concepts
and
Abstract
Syntax
and
the
RDF
1.1
versions
of
this
specification.
Previous
versions
A
detailed
overview
of
RDF
used
the
term
“
differences
between
RDF
URI
Reference
”
instead
of
“
IRI
”
and
allowed
additional
characters:
“
<
”,
“
>
”,
“
{
”,
“
}
”,
“
|
”,
“
\
”,
“
^
”,
“
`
”,
‘
“
’
(double
quote),
and
“
”
(space).
In
IRIs,
these
characters
must
versions 1.0
and 1.1
can
be
percent-encoded
as
described
found
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
What’s
New
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
RDF 1.1
that
adhered
to
the
generic
tag/subtag
syntax
of
language
tags,
but
were
not
well-formed
according
to
[
BCP47
RDF11-NEW
].
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.
This section is non-normative.
This
section
lists
changes
from
since
the
23
July
5
November
2013
Last
Call
Working
Draft
(LC)
to
this
Candidate
Recommendation
of
RDF
1.1
Concepts
and
Abstract
Syntax
.
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
(CR)
.
2013-10-16:
Update
to
Section
7
in
accordance
with
ISSUE-147
(
ACTION-309
,
assignment
of
action
)
2013-09-10:
Update
to
Section
7
in
accordance
with
ISSUE-139
(
resolution
)
2013-08-26:
Update
to
Section
4.1
to
satisfy
ACTION-283
and
ISSUE-140
(
resolution
)
B.2
Changes
from
15
January
2013
WD
to
this
version
This
section
lists
changes
from
the
15
January
2013
Working
Draft
(LC)
to
the
Last
Call
Working
Draft
of
RDF
1.1
Concepts
and
Abstract
Syntax
.
rdf:HTML
and
rdf:XMLLiteral
non-normative