Abstract

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
Last
Call
Working
Draft.
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
).
The
Last
Call
period
ends
06
September
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
Last
Call
Working
Draft
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.

This
is
a
Last
Call
Working
Draft
and
thus
the
Working
Group
has
determined
that
this
document
has
satisfied
the
relevant
technical
requirements
The
following
features
are
at
risk
and
is
sufficiently
stable
may
be
changed
from
normative
to
advance
through
the
Technical
Recommendation
process.
non-normative:

1.1
Graph-based
Data
Model

This
section
is
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.
1
An
RDF
graph
with
two
nodes
(Subject
and
Object)
and
a
triple
connecting
them
(Predicate)

1.2
Resources
and
Statements

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”.
"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.

1.3
The
Referent
of
an
IRI

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
.

By
social
convention,
the
IRI
owner
[
WEBARCH
]
gets
to
say
what
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
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.

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:

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.

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
graph
s:

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
[
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.

2.
Conformance

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.

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
URI
s
[
RFC3986
]
that
permits
a
much
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.

3.3
Literals

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.

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
IRI
http://www.w3.org/2001/XMLSchema#string
.

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
:

http://example.com/.well-known/genid/d26a2d0e98334696f4ad70a677abc1f6

Note

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
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:

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:
if
there
is
a
bijection
DG1
M
between
the
nodes,
triples
and
DG2
are
graph-isomorphic;
For
each
(n1,g1)
graphs
in
NG1
,
there
exists
(n2,g2)
D1
and
those
in
NG2
D2
such
that
that:

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.

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.

5.2
The
rdf:HTML
Datatype

Feature
at
Risk
1

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:

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
.

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
MAY
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.

6.
Fragment
Identifiers

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
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
triple
s.
For
example,
the
completeness
of
the
RDFS
entailment
rules
is
easier
to
show
with
a
generalization
of
RDF
triples.
Note
that
any
users
of
these
generalized
notions
need
to
be
aware
that
their
use
may
cause
interoperability
problems,
and
that
there
is
no
requirement
on
the
part
of
any
RDF
tool
to
accept,
process,
or
produce
anything
beyond
regular
RDF
triples,
graphs,
and
datasets.

A
generalized
RDF
triple
is
an
RDF
a
triple
generalized
so
that
subjects,
predicates,
having
a
subject,
a
predicate,
and
objects
are
all
allowed
to
object,
where
each
can
be
IRIs,
an
IRI
,
a
blank
nodes,
node
or
literals.
a
literal
.
A
generalized
RDF
graph
is
an
RDF
graph
of
generalized
RDF
triples,
i.e.,
a
set
of
generalized
RDF
triples.
A
generalized
RDF
dataset
is
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
dataset
graph.

Any
users
of
generalized
RDF
triples,
graphs
where
graph
labels
can
or
datasets
need
to
be
IRIs,
blank
nodes,
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
literals.
produce
anything
beyond
standard
RDF
triples,
graphs,
and
datasets.

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.

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-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.