1.
Introduction
§
This
section
is
non-normative.
Linked
Data
[
LINKED-DATA
]
is
a
way
to
create
a
network
of
standards-based
machine
interpretable
data
across
different
documents
and
Web
sites.
It
allows
an
application
to
start
at
one
piece
of
Linked
Data,
and
follow
embedded
links
to
other
pieces
of
Linked
Data
that
are
hosted
on
different
sites
across
the
Web.
JSON-LD
is
a
lightweight
syntax
to
serialize
Linked
Data
in
JSON
[
RFC7159
].
Its
design
allows
existing
JSON
to
be
interpreted
as
Linked
Data
with
minimal
changes.
JSON-LD
is
primarily
intended
to
be
a
way
to
use
Linked
Data
in
Web-based
programming
environments,
to
build
interoperable
Web
services,
and
to
store
Linked
Data
in
JSON-based
storage
engines.
Since
JSON-LD
is
100%
compatible
with
JSON,
the
large
number
of
JSON
parsers
and
libraries
available
today
can
be
reused.
In
addition
to
all
the
features
JSON
provides,
JSON-LD
introduces:
-
a
universal
identifier
mechanism
for
JSON
objects
via
the
use
of
IRIs
,
-
a
way
to
disambiguate
keys
shared
among
different
JSON
documents
by
mapping
them
to
IRIs
via
a
context
,
-
a
mechanism
in
which
a
value
in
a
JSON
object
may
refer
to
a
JSON
object
on
a
different
site
on
the
Web,
-
the
ability
to
annotate
strings
with
their
language,
-
a
way
to
associate
datatypes
with
values
such
as
dates
and
times,
-
and
a
facility
to
express
one
or
more
directed
graphs,
such
as
a
social
network,
in
a
single
document.
JSON-LD
is
designed
to
be
usable
directly
as
JSON,
with
no
knowledge
of
RDF
[
RDF11-CONCEPTS
].
It
is
also
designed
to
be
usable
as
RDF,
if
desired,
for
use
with
other
Linked
Data
technologies
like
SPARQL.
Developers
who
require
any
of
the
facilities
listed
above
or
need
to
serialize
an
RDF
Graph
or
RDF
Dataset
in
a
JSON-based
syntax
will
find
JSON-LD
of
interest.
People
intending
to
use
JSON-LD
with
RDF
tools
will
find
it
can
be
used
as
another
RDF
syntax,
like
Turtle
[
TURTLE
].
Complete
details
of
how
JSON-LD
relates
to
RDF
are
in
section
7.
10.
Relationship
to
RDF
.
The
syntax
is
designed
to
not
disturb
already
deployed
systems
running
on
JSON,
but
provide
a
smooth
upgrade
path
from
JSON
to
JSON-LD.
Since
the
shape
of
such
data
varies
wildly,
JSON-LD
features
mechanisms
to
reshape
documents
into
a
deterministic
structure
which
simplifies
their
processing.
1.2
Contributing
§
There
are
a
number
of
ways
that
one
may
participate
in
the
development
of
this
specification:
-
Technical
discussion
typically
occurs
on
the
public
working
group
mailing
list:
public-linked-json@w3.org
public-json-ld-wg@w3.org
-
The
working
group
uses
#json-ld
IRC
channel
is
available
for
real-time
discussion
on
irc.w3.org
.
-
The
#json-ld
IRC
channel
is
also
available
for
real-time
discussion
on
irc.freenode.net.
1.3
Terminology
§
This
document
uses
the
following
terms
as
defined
in
JSON
[
RFC7159
].
Refer
to
the
JSON
Grammar
section
in
[
RFC7159
]
for
formal
definitions.
-
array
-
In
the
JSON
serialization,
an
array
structure
is
represented
as
square
brackets
surrounding
zero
or
more
values.
Values
are
separated
by
commas.
In
the
internal
representation
,
an
array
is
an
ordered
collection
of
zero
or
more
values.
While
JSON-LD
uses
the
same
array
representation
as
JSON,
the
collection
is
unordered
by
default.
While
order
is
preserved
in
regular
JSON
arrays,
it
is
not
in
regular
JSON-LD
arrays
unless
specifically
defined
(see
Sets
and
Lists
in
the
JSON-LD
Syntax
specification
[
JSON-LD11
]).
-
JSON
object
-
In
the
JSON
serialization,
an
object
structure
is
represented
as
a
pair
of
curly
brackets
surrounding
zero
or
more
key-value
pairs.
A
key
is
a
string
.
A
single
colon
comes
after
each
key,
separating
the
key
from
the
value.
A
single
comma
separates
a
value
from
a
following
key.
In
JSON-LD
the
keys
in
an
object
MUST
be
unique.
In
the
internal
representation
a
JSON
object
is
equivalent
to
a
dictionary
(see
[
WEBIDL
]).
-
JSON-LD
internal
representation
-
The
JSON-LD
internal
representation
is
the
result
of
transforming
a
JSON
syntactic
structure
into
the
core
data
structures
suitable
for
direct
processing:
arrays
,
dictionaries
,
strings
,
numbers
,
booleans
,
and
null
.
-
null
-
The
use
of
the
null
value
within
JSON-LD
is
used
to
ignore
or
reset
values.
A
key-value
pair
in
the
@context
where
the
value,
or
the
@id
of
the
value,
is
null
explicitly
decouples
a
term's
association
with
an
IRI
.
A
key-value
pair
in
the
body
of
a
JSON-LD
document
whose
value
is
null
has
the
same
meaning
as
if
the
key-value
pair
was
not
defined.
If
@value
,
@list
,
or
@set
is
set
to
null
in
expanded
form,
then
the
entire
JSON
object
is
ignored.
-
number
-
In
the
JSON
serialization,
a
number
is
similar
to
that
used
in
most
programming
languages,
except
that
the
octal
and
hexadecimal
formats
are
not
used
and
that
leading
zeros
are
not
allowed.
In
the
internal
representation
,
a
number
is
equivalent
to
either
a
long
or
double
,
depending
on
if
the
number
has
a
non-zero
fractional
part
(see
[
WEBIDL
]).
-
-
string
-
A
string
is
a
sequence
of
zero
or
more
Unicode
(UTF-8)
characters,
wrapped
in
double
quotes,
using
backslash
escapes
(if
necessary).
A
character
is
represented
as
a
single
character
string.
-
true
and
false
-
Values
that
are
used
to
express
one
of
two
possible
boolean
states.
Furthermore,
the
following
terminology
is
used
throughout
this
document:
-
absolute
IRI
-
An
absolute
IRI
is
defined
in
[
RFC3987
]
containing
a
scheme
along
with
a
path
and
optional
query
and
fragment
segments.
-
active
context
-
A
context
that
is
used
to
resolve
terms
while
the
processing
algorithm
is
running.
-
base
IRI
-
The
base
IRI
is
an
absolute
IRI
established
in
the
context
,
or
is
based
on
the
JSON-LD
document
location.
The
base
IRI
is
used
to
turn
relative
IRIs
into
absolute
IRIs
.
-
blank
node
-
A
node
in
a
graph
that
is
neither
an
IRI
,
nor
a
JSON-LD
value
,
nor
a
list
.
A
blank
node
does
not
contain
a
de-referenceable
identifier
because
it
is
either
ephemeral
in
nature
or
does
not
contain
information
that
needs
to
be
linked
to
from
outside
of
the
linked
data
graph
.
A
blank
node
is
assigned
an
identifier
starting
with
the
prefix
_:
.
-
blank
node
identifier
-
A
blank
node
identifier
is
a
string
that
can
be
used
as
an
identifier
for
a
blank
node
within
the
scope
of
a
JSON-LD
document.
Blank
node
identifiers
begin
with
_:
.
-
compact
IRI
-
A
compact
IRI
is
has
the
form
of
prefix
:
suffix
and
is
used
as
a
way
of
expressing
an
IRI
without
needing
to
define
separate
term
definitions
for
each
IRI
contained
within
a
common
vocabulary
identified
by
prefix
.
-
context
-
A
set
of
rules
for
interpreting
a
JSON-LD
document
as
specified
in
The
Context
of
the
JSON-LD
Syntax
specification
[
JSON-LD11
].
-
-
default
graph
-
The
default
graph
is
the
only
graph
in
a
JSON-LD
document
which
has
no
graph
name
.
When
executing
an
algorithm,
the
graph
where
data
should
be
placed
if
a
named
graph
is
not
specified.
-
default
language
-
The
default
language
is
set
in
the
context
using
the
@language
key
whose
value
MUST
be
a
string
representing
a
[
BCP47
]
language
code
or
null
.
-
-
edge
-
Every
edge
has
a
direction
associated
with
it
and
is
labeled
with
an
IRI
or
a
blank
node
identifier
.
Within
the
JSON-LD
syntax
these
edge
labels
are
called
properties
.
Whenever
possible,
an
edge
should
be
labeled
with
an
IRI
.
-
expanded
term
definition
-
An
expanded
term
definition,
is
a
term
definition
where
the
value
is
a
JSON
object
containing
one
or
more
keyword
properties
to
define
the
associated
absolute
IRI
,
if
this
is
a
reverse
property,
the
type
associated
with
string
values,
and
a
container
mapping.
-
Frame
-
A
JSON-LD
document
,
which
describes
the
form
for
transforming
another
JSON-LD
document
using
matching
and
embedding
rules.
A
frame
document
allows
additional
keywords
and
certain
property
values
to
describe
the
matching
and
transforming
process.
-
-
graph
name
-
The
IRI
identifying
a
named
graph
.
-
graph
object
-
A
graph
object
represents
a
named
graph
represented
as
the
value
of
a
property
within
a
node
object
.
When
expanded,
a
graph
object
MUST
have
an
@graph
member,
and
may
also
have
@id
,
and
@index
members.
A
simple
graph
object
is
a
graph
object
which
does
not
have
an
@id
member.
Note
that
node
objects
may
have
a
@graph
member,
but
are
not
considered
graph
objects
if
they
include
any
other
properties.
A
top-level
object
consisting
of
@graph
is
also
not
a
graph
object
.
-
id
map
-
An
id
map
is
a
JSON
object
value
of
a
term
defined
with
@container
set
to
@id
,
whose
keys
are
interpreted
as
IRIs
representing
the
@id
of
the
associated
node
object
;
value
MUST
be
a
node
object
.
If
the
value
contains
a
property
expanding
to
@id
,
it's
value
MUST
be
equivalent
to
the
referencing
key.
-
implicitly
named
graph
-
A
named
graph
created
from
the
value
of
a
property
having
an
expanded
term
definition
where
@container
is
set
to
@graph
.
-
index
map
-
An
index
map
is
a
JSON
object
value
of
a
term
defined
with
@container
set
to
@index
,
whose
values
MUST
be
any
of
the
following
types:
string
,
number
,
true
,
false
,
null
,
node
object
,
value
object
,
list
object
,
set
object
,
or
an
array
of
zero
or
more
of
the
above
possibilities.
-
IRI
-
An
Internationalized
Resource
Identifier
as
described
in
[
RFC3987
].
-
JSON-LD
document
-
A
JSON-LD
document
is
a
serialization
of
a
collection
of
graphs
and
comprises
exactly
one
default
graph
and
zero
or
more
named
graphs
.
-
JSON-LD
Processor
-
A
JSON-LD
Processor
is
a
system
which
can
perform
the
algorithms
defined
in
[
JSON-LD11-API
].
-
JSON-LD
value
-
A
JSON-LD
value
is
a
string
,
a
number
,
true
or
false
,
a
typed
value
,
or
a
language-tagged
string
.
-
keyword
-
A
JSON
key
that
is
specific
to
JSON-LD,
specified
in
the
JSON-LD
Syntax
specification
[
JSON-LD11
]
in
the
section
titled
Syntax
Tokens
and
Keywords
.
-
language
map
-
An
language
map
is
a
JSON
object
value
of
a
term
defined
with
@container
set
to
@language
,
whose
keys
MUST
be
strings
representing
[
BCP47
]
language
codes
and
the
values
MUST
be
any
of
the
following
types:
null
,
string
,
or
an
array
of
zero
or
more
of
the
above
possibilities.
-
language-tagged
string
-
A
language-tagged
string
consists
of
a
string
and
a
non-empty
language
tag
as
defined
by
[
BCP47
].
The
language
tag
MUST
be
well-formed
according
to
section
2.2.9
Classes
of
Conformance
of
[
BCP47
],
and
is
normalized
to
lowercase.
-
-
linked
data
graph
-
A
labeled
directed
graph
,
i.e.,
a
set
of
nodes
connected
by
edges
,
as
specified
in
the
Data
Model
section
of
the
JSON-LD
specification
[
JSON-LD11
].
A
linked
data
graph
is
a
generalized
representation
of
an
RDF
graph
as
defined
in
[
RDF-CONCEPTS
].
-
list
-
A
list
is
an
ordered
sequence
of
IRIs
,
blank
nodes
,
and
JSON-LD
values
.
See
RDF
collection
in
[
RDF-SCHEMA
].
-
list
object
-
A
list
object
is
a
JSON
object
that
has
an
@list
member.
-
-
local
context
-
A
context
that
is
specified
within
a
JSON
object
,
specified
via
the
@context
keyword
.
-
named
graph
-
A
named
graph
is
a
linked
data
graph
that
is
identified
by
an
IRI
or
blank
node
.
-
nested
property
-
A
nested
property
is
a
property
which
is
contained
within
an
object
referenced
by
a
semantically
meaningless
nesting
property
.
-
node
-
Every
node
is
an
IRI
,
a
blank
node
,
a
JSON-LD
value
,
or
a
list
.
A
piece
of
information
that
is
represented
in
a
linked
data
graph
.
-
node
object
-
A
node
object
represents
zero
or
more
properties
of
a
node
in
the
graph
serialized
by
the
JSON-LD
document
.
A
JSON
object
is
a
node
object
if
it
exists
outside
of
the
JSON-LD
context
and:
-
it
does
not
contain
the
@value
,
@list
,
or
@set
keywords,
or
-
it
is
not
the
top-most
JSON
object
in
the
JSON-LD
document
consisting
of
no
other
members
than
@graph
and
@context
.
-
-
-
prefix
-
A
prefix
is
the
first
component
of
a
compact
IRI
which
comes
from
a
term
that
maps
to
a
string
that,
when
prepended
to
the
suffix
of
the
compact
IRI
results
in
an
absolute
IRI
.
-
processing
mode
-
The
processing
mode
defines
how
a
JSON-LD
document
is
processed.
By
default,
all
documents
are
assumed
to
be
conformant
with
JSON-LD
1.0
[
JSON-LD
].
By
defining
a
different
version
using
the
@version
member
in
a
context
,
or
via
explicit
API
option,
other
processing
modes
can
be
accessed.
This
specification
defines
extensions
for
the
json-ld-1.1
processing
mode
.
-
property
-
The
IRI
label
of
an
edge
in
a
linked
data
graph
.
See
RDF
predicate
in
[
RDF11-CONCEPTS
].
-
-
RDF
dataset
-
A
dataset
as
specified
by
[
RDF11-CONCEPTS
]
representing
a
collection
of
RDF
graphs
.
-
-
RDF
triple
-
A
triple
as
specified
by
[
RDF11-CONCEPTS
].
-
relative
IRI
-
A
relative
IRI
is
an
IRI
that
is
relative
to
some
other
absolute
IRI
,
typically
the
base
IRI
of
the
document.
Note
that
properties
,
values
of
@type
,
and
values
of
terms
defined
to
be
vocabulary
relative
are
resolved
relative
to
the
vocabulary
mapping
,
not
the
base
IRI
.
-
set
object
-
A
set
object
is
a
JSON
object
that
has
an
@set
member.
-
-
term
-
A
term
is
a
short
word
defined
in
a
context
that
MAY
be
expanded
to
an
IRI
-
term
definition
-
A
term
definition
is
an
entry
in
a
context
,
where
the
key
defines
a
term
which
may
be
used
within
a
JSON
object
as
a
property
,
type,
or
elsewhere
that
a
string
is
interpreted
as
a
vocabulary
item.
Its
value
is
either
a
string
(
simple
term
definition
),
expanding
to
an
absolute
IRI
,
or
an
expanded
term
definition
.
-
type
map
-
An
type
map
is
a
JSON
object
value
of
a
term
defined
with
@container
set
to
@type
,
whose
keys
are
interpreted
as
IRIs
representing
the
@type
of
the
associated
node
object
;
value
MUST
be
a
node
object
,
or
array
of
node
objects.
If
the
value
contains
a
property
expanding
to
@type
,
it's
values
are
merged
with
the
map
value
when
expanding.
-
-
typed
value
-
A
typed
value
consists
of
a
value,
which
is
a
string
,
and
a
type,
which
is
an
IRI
.
-
value
object
-
A
value
object
is
a
JSON
object
that
has
an
@value
member.
-
vocabulary
mapping
-
The
vocabulary
mapping
is
set
in
the
context
using
the
@vocab
key
whose
value
MUST
be
an
absolute
IRI
null
.
1.4
Typographical
conventions
§
The
following
typographic
conventions
are
used
in
this
specification:
-
markup
-
Markup
(elements,
attributes,
properties),
machine
processable
values
(string,
characters,
media
types),
property
name,
or
a
file
name
is
in
red-orange
monospace
font.
-
variable
-
A
variable
in
pseudo-code
or
in
an
algorithm
description
is
in
italics.
-
definition
-
A
definition
of
a
term,
to
be
used
elsewhere
in
this
or
other
specifications,
is
in
bold
and
italics.
-
definition
reference
-
A
reference
to
a
definition
in
this
document
is
underlined
and
is
also
an
active
link
to
the
definition
itself.
-
markup
definition
reference
-
A
references
to
a
definition
in
this
document
,
when
the
reference
itself
is
also
a
markup,
is
underlined,
red-orange
monospace
font,
and
is
also
an
active
link
to
the
definition
itself.
-
external
definition
reference
-
A
reference
to
a
definition
in
another
document
is
underlined,
in
italics,
and
is
also
an
active
link
to
the
definition
itself.
-
markup
external
definition
reference
-
A
reference
to
a
definition
in
another
document
,
when
the
reference
itself
is
also
a
markup,
is
underlined,
in
italics
red-orange
monospace
font,
and
is
also
an
active
link
to
the
definition
itself.
-
hyperlink
-
A
hyperlink
is
underlined
and
in
blue.
-
[
reference
]
-
A
document
reference
(normative
or
informative)
is
enclosed
in
square
brackets
and
links
to
the
references
section.
-
Changes
from
Recommendation
-
Sections
or
phrases
changed
from
the
previous
Recommendation
are
highlighted
.
Note
Notes
are
in
light
green
boxes
with
a
green
left
border
and
with
a
"Note"
header
in
green.
Notes
are
normative
or
informative
depending
on
the
whether
they
are
in
a
normative
or
informative
section,
respectively.
Example
1
Examples are in light khaki boxes, with khaki left border, and with a
numbered "Example" header in khaki. Examples are always informative.
The
content
of
the
example
is
in
monospace
font
and
may
be
syntax
colored.
3.
Basic
Concepts
§
This
section
is
non-normative.
JSON
[
RFC7159
]
is
a
lightweight,
language-independent
data
interchange
format.
It
is
easy
to
parse
and
easy
to
generate.
However,
it
is
difficult
to
integrate
JSON
from
different
sources
as
the
data
may
contain
keys
that
conflict
with
other
data
sources.
Furthermore,
JSON
has
no
built-in
support
for
hyperlinks,
which
are
a
fundamental
building
block
on
the
Web.
Let's
start
by
looking
at
an
example
that
we
will
be
using
for
the
rest
of
this
section:
Example
2
:
Sample
JSON
document
{
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"image": "http://manu.sporny.org/images/manu.png"
}
It's
obvious
to
humans
that
the
data
is
about
a
person
whose
name
is
"Manu
Sporny"
and
that
the
homepage
property
contains
the
URL
of
that
person's
homepage.
A
machine
doesn't
have
such
an
intuitive
understanding
and
sometimes,
even
for
humans,
it
is
difficult
to
resolve
ambiguities
in
such
representations.
This
problem
can
be
solved
by
using
unambiguous
identifiers
to
denote
the
different
concepts
instead
of
tokens
such
as
"name",
"homepage",
etc.
Linked
Data,
and
the
Web
in
general,
uses
IRIs
(
Internationalized
Resource
Identifiers
as
described
in
[
RFC3987
])
for
unambiguous
identification.
The
idea
is
to
use
IRIs
to
assign
unambiguous
identifiers
to
data
that
may
be
of
use
to
other
developers.
It
is
useful
for
terms
,
like
name
and
homepage
,
to
expand
to
IRIs
so
that
developers
don't
accidentally
step
on
each
other's
terms.
Furthermore,
developers
and
machines
are
able
to
use
this
IRI
(by
using
a
web
browser,
for
instance)
to
go
to
the
term
and
get
a
definition
of
what
the
term
means.
This
process
is
known
as
IRI
dereferencing.
Leveraging
the
popular
schema.org
vocabulary
,
the
example
above
could
be
unambiguously
expressed
as
follows:
Example
3
:
Sample
JSON-LD
document
using
full
IRIs
instead
of
terms
{
"http://schema.org/name": "Manu Sporny",
"http://schema.org/url": { "@id": "http://manu.sporny.org/" },
"http://schema.org/image": { "@id": "http://manu.sporny.org/images/manu.png" }
}
In
the
example
above,
every
property
is
unambiguously
identified
by
an
IRI
and
all
values
representing
IRIs
are
explicitly
marked
as
such
by
the
@id
keyword
.
While
this
is
a
valid
JSON-LD
document
that
is
very
specific
about
its
data,
the
document
is
also
overly
verbose
and
difficult
to
work
with
for
human
developers.
To
address
this
issue,
JSON-LD
introduces
the
notion
of
a
context
as
described
in
the
next
section.
3.1
The
Context
§
This
section
is
non-normative.
When
two
people
communicate
with
one
another,
the
conversation
takes
place
in
a
shared
environment,
typically
called
"the
context
of
the
conversation".
This
shared
context
allows
the
individuals
to
use
shortcut
terms,
like
the
first
name
of
a
mutual
friend,
to
communicate
more
quickly
but
without
losing
accuracy.
A
context
in
JSON-LD
works
in
the
same
way.
It
allows
two
applications
to
use
shortcut
terms
to
communicate
with
one
another
more
efficiently,
but
without
losing
accuracy.
Simply
speaking,
a
context
is
used
to
map
terms
to
IRIs
.
Terms
are
case
sensitive
and
any
valid
string
that
is
not
a
reserved
JSON-LD
keyword
can
be
used
as
a
term
.
For
the
sample
document
in
the
previous
section,
a
context
would
look
something
like
this:
Example
4
:
Context
for
the
sample
document
in
the
previous
section
{
"@context": {
"name": "http://schema.org/name",
"image": {
"@id": "http://schema.org/image",
"@type": "@id"
},
"homepage": {
"@id": "http://schema.org/url",
"@type": "@id"
}
}
}
As
the
context
above
shows,
the
value
of
a
term
definition
can
either
be
a
simple
string,
mapping
the
term
to
an
IRI
,
or
a
JSON
object
.
When
a
JSON
object
is
associated
with
a
term,
it
is
called
an
expanded
term
definition
.
The
example
above
specifies
that
the
values
of
image
and
homepage
,
if
they
are
strings,
are
to
be
interpreted
as
IRIs
.
Expanded
term
definitions
also
allow
terms
to
be
used
for
index
maps
and
to
specify
whether
array
values
are
to
be
interpreted
as
sets
or
lists
.
Expanded
term
definitions
may
be
defined
using
absolute
or
compact
IRIs
as
keys,
which
is
mainly
used
to
associate
type
or
language
information
with
an
absolute
or
compact
IRI
.
Contexts
can
either
be
directly
embedded
into
the
document
or
be
referenced.
Assuming
the
context
document
in
the
previous
example
can
be
retrieved
at
https://json-ld.org/contexts/person.jsonld
,
it
can
be
referenced
by
adding
a
single
line
and
allows
a
JSON-LD
document
to
be
expressed
much
more
concisely
as
shown
in
the
example
below:
Example
5
:
Referencing
a
JSON-LD
context
{
"@context": "https://json-ld.org/contexts/person.jsonld",
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"image": "http://manu.sporny.org/images/manu.png"
}
The
referenced
context
not
only
specifies
how
the
terms
map
to
IRIs
in
the
Schema.org
vocabulary
but
also
specifies
that
string
values
associated
with
the
homepage
and
image
property
can
be
interpreted
as
an
IRI
(
"@type":
"@id"
,
see
section
3.2
IRIs
for
more
details).
This
information
allows
developers
to
re-use
each
other's
data
without
having
to
agree
to
how
their
data
will
interoperate
on
a
site-by-site
basis.
External
JSON-LD
context
documents
may
contain
extra
information
located
outside
of
the
@context
key,
such
as
documentation
about
the
terms
declared
in
the
document.
Information
contained
outside
of
the
@context
value
is
ignored
when
the
document
is
used
as
an
external
JSON-LD
context
document.
JSON
documents
can
be
interpreted
as
JSON-LD
without
having
to
be
modified
by
referencing
a
context
via
an
HTTP
Link
Header
as
described
in
section
4.9
6.
Interpreting
JSON
as
JSON-LD
.
It
is
also
possible
to
apply
a
custom
context
using
the
JSON-LD
1.1
API
[
JSON-LD11-API
].
In
JSON-LD
documents
,
contexts
may
also
be
specified
inline.
This
has
the
advantage
that
documents
can
be
processed
even
in
the
absence
of
a
connection
to
the
Web.
Ultimately,
this
is
a
modeling
decision
and
different
use
cases
may
require
different
handling.
Example
6
:
In-line
context
definition
{
"@context": {
"name": "http://schema.org/name",
"image": {
"@id": "http://schema.org/image",
"@type": "@id"
},
"homepage": {
"@id": "http://schema.org/url",
"@type": "@id"
}
},
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"image": "http://manu.sporny.org/images/manu.png"
}
This
section
only
covers
the
most
basic
features
of
the
JSON-LD
Context.
The
Context
can
also
be
used
to
help
interpret
other
more
complex
JSON
data
structures,
such
as
indexed
values
,
ordered
values
,
and
nested
properties
.
More
advanced
features
related
to
the
JSON-LD
Context
are
covered
in
section
section
4.
Advanced
Concepts
.
3.2
IRIs
§
This
section
is
non-normative.
IRIs
(
Internationalized
Resource
Identifiers
[
RFC3987
])
are
fundamental
to
Linked
Data
as
that
is
how
most
nodes
and
properties
are
identified.
In
JSON-LD,
IRIs
may
be
represented
as
an
absolute
IRI
or
a
relative
IRI
.
An
absolute
IRI
is
defined
in
[
RFC3987
]
as
containing
a
scheme
along
with
path
and
optional
query
and
fragment
segments.
A
relative
IRI
is
an
IRI
that
is
relative
to
some
other
absolute
IRI
.
In
JSON-LD,
with
exceptions
are
as
described
below,
all
relative
IRIs
are
resolved
relative
to
the
base
IRI
.
A
string
is
interpreted
as
an
IRI
when
it
is
the
value
of
an
@id
member:
Example
7
:
Values
of
@id
are
interpreted
as
IRI
{
"homepage": { "@id": "http://example.com/" }
}
Values
that
are
interpreted
as
IRIs
,
can
also
be
expressed
as
relative
IRIs
.
For
example,
assuming
that
the
following
document
is
located
at
http://example.com/about/
,
the
relative
IRI
../
would
expand
to
http://example.com/
(for
more
information
on
where
relative
IRIs
can
be
used,
please
refer
to
section
6.
9.
JSON-LD
Grammar
).
Example
8
:
IRIs
can
be
relative
{
"homepage": { "@id": "../" }
}
Absolute
IRIs
can
be
expressed
directly
in
the
key
position
like
so:
Example
9
:
IRI
as
a
key
{
"http://schema.org/name": "Manu Sporny"
}
In
the
example
above,
the
key
http://schema.org/name
is
interpreted
as
an
absolute
IRI
.
Term-to-
IRI
expansion
occurs
if
the
key
matches
a
term
defined
within
the
active
context
:
Example
10
:
Term
expansion
from
context
definition
{
"@context": {
"name": "http://schema.org/name"
},
"name": "Manu Sporny",
"status": "trollin'"
}
JSON
keys
that
do
not
expand
to
an
IRI
,
such
as
status
in
the
example
above,
are
not
Linked
Data
and
thus
ignored
when
processed.
If
type
coercion
rules
are
specified
in
the
@context
for
a
particular
term
or
property
IRI
,
an
IRI
is
generated:
Example
11
:
Type
coercion
{
"@context": {
"homepage": {
"@id": "http://schema.org/url",
"@type": "@id"
}
},
"homepage": "http://manu.sporny.org/"
}
In
the
example
above,
since
the
value
http://manu.sporny.org/
is
expressed
as
a
JSON
string
,
the
type
coercion
rules
will
transform
the
value
into
an
IRI
when
processing
the
data.
See
section
4.6
4.2.2
Type
Coercion
for
more
details
about
this
feature.
In
summary,
IRIs
can
be
expressed
in
a
variety
of
different
ways
in
JSON-LD:
-
JSON
object
keys
that
have
a
term
mapping
in
the
active
context
expand
to
an
IRI
(only
applies
outside
of
the
context
definition
).
-
An
IRI
is
generated
for
the
string
value
specified
using
@id
or
@type
.
-
An
IRI
is
generated
for
the
string
value
of
any
key
for
which
there
are
coercion
rules
that
contain
an
@type
key
that
is
set
to
a
value
of
@id
or
@vocab
.
This
section
only
covers
the
most
basic
features
associated
with
IRIs
in
JSON-LD.
More
advanced
features
related
to
IRIs
are
covered
in
section
4.
Advanced
Concepts
.
4.
Advanced
Concepts
§
JSON-LD
has
a
number
of
features
that
provide
functionality
above
and
beyond
the
core
functionality
described
above.
The
following
JSON
can
be
used
to
express
data
using
such
structures,
and
the
features
described
in
this
section
describes
can
be
used
to
interpret
a
variety
of
different
JSON
structures
as
Linked
Data.
A
JSON-LD
processor
will
make
use
of
provided
and
embedded
contexts
to
interpret
property
values
in
a
number
of
different
idiomatic
ways.
-
Describing
values
One
pattern
in
JSON
is
for
the
value
of
a
property
to
be
a
string.
Often
times,
this
string
actually
represents
some
other
typed
value,
for
example
an
IRI
,
a
date,
or
a
string
in
some
specific
language.
See
section
4.2
Describing
Values
for
details
on
how
to
describe
such
value
typing.
-
Value
ordering
In
JSON,
a
property
with
an
array
value
implies
an
implicit
order;
arrays
in
JSON-LD
do
not
provide
an
ordering
of
the
contained
elements
by
default,
unless
defined
using
embedded
structures
or
through
a
context
definition.
See
section
4.3
Value
Ordering
for
a
further
discussion.
-
Property
nesting
Another
JSON
idiom
often
found
in
APIs
is
to
use
an
intermediate
object
to
represent
the
properties
of
an
object;
in
JSON-LD
these
are
refered
to
as
nested
properties
and
are
described
in
section
4.4
Nested
Properties
.
-
Referencing
objects
Linked
Data
is
all
about
describing
the
relationships
between
different
resources.
Sometimes
these
relationships
are
between
resources
defined
in
different
documents
described
on
the
web,
sometimes
the
resources
are
described
within
the
same
document.
Example
16
:
Referencing
Objects
on
the
Web
{
"@context": {
"@vocab": "http://schema.org/",
"knows": {"@type": "@id"}
},
"@id": "http://manu.sporny.org/about#manu",
"@type": "Person",
"name": "Manu Sporny",
"knows": "http://greggkellogg.net/foaf#me"
}
In
this
case,
a
document
residing
at
http://manu.sporny.org/about
may
contain
the
example
above,
and
reference
another
document
at
http://greggkellogg.net/foaf
which
could
include
a
similar
representation.
A
common
idiom
found
in
JSON
usage
is
objects
being
specified
as
the
value
of
other
objects,
called
object
embedding
in
JSON-LD;
for
example,
a
friend
specified
as
an
object
value
of
a
Person
:
Example
17
:
Embedding
Objects
{
"@context": {
"@vocab": "http://schema.org/"
},
"@id": "http://manu.sporny.org/about#manu",
"@type": "Person",
"name": "Manu Sporny",
"knows": {
"@id": "http://greggkellogg.net/foaf#me",
"@type": "Person",
"name": "Gregg Kellogg"
}
}
See
section
4.5
Embedding
details
these
relationships.
-
Indexed
values
Another
common
idiom
in
JSON
is
to
use
an
intermediate
object
to
represent
property
values
via
indexing.
JSON-LD
allows
data
to
be
indexed
in
a
number
of
different
ways,
as
detailed
in
section
4.6
Indexed
Values
.
-
Reverse
Properties
JSON-LD
serializes
directed
graphs
.
That
means
that
every
property
points
from
a
node
to
another
node
or
value
.
However,
in
some
cases,
it
is
desirable
to
serialize
in
the
reverse
direction,
as
detailed
in
section
4.7
Reverse
Properties
.
The
following
sections
describe
such
advanced
functionality
in
more
detail.
4.1
Advanced
Context
Usage
§
This
section
is
non-normative.
Section
3.1
The
Context
introduced
the
basics
of
what
makes
JSON-LD
work.
This
section
expands
on
the
basic
principles
of
the
context
and
demonstrates
how
more
advanced
use
cases
can
be
achieved
using
JSON-LD.
In
general,
contexts
may
be
used
any
time
a
JSON
object
is
defined.
The
only
time
that
one
cannot
express
a
context
is
as
a
direct
child
of
another
context
definition
(other
than
as
part
of
an
expanded
term
definition
).
For
example,
a
JSON-LD
document
may
use
more
than
one
context
at
different
points
in
a
document:
Example
18
:
Using
multiple
contexts
[
{
"@context": "http://example.org/contexts/person.jsonld",
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"depiction": "http://twitter.com/account/profile_image/manusporny"
},
{
"@context": "http://example.org/contexts/place.jsonld",
"name": "The Empire State Building",
"description": "The Empire State Building is a 102-story landmark in New York City.",
"geo": {
"latitude": "40.75",
"longitude": "73.98"
}
}
]
Duplicate
context
terms
are
overridden
using
a
most-recently-defined-wins
mechanism.
Example
19
:
Scoped
contexts
within
node
objects
{ "@context": {
"name": "http://example.com/person#name",
"details": "http://example.com/person#details"
},
"name": "Markus Lanthaler",
"details": {
"@context": {
"name": "http://example.com/organization#name"
},
"name": "Graz University of Technology"
}
}
In
the
example
above,
the
name
term
is
overridden
in
the
more
deeply
nested
details
structure.
Note
that
this
is
rarely
a
good
authoring
practice
and
is
typically
used
when
working
with
legacy
applications
that
depend
on
a
specific
structure
of
the
JSON
object
.
If
a
term
is
redefined
within
a
context,
all
previous
rules
associated
with
the
previous
definition
are
removed.
If
a
term
is
redefined
to
null
,
the
term
is
effectively
removed
from
the
list
of
terms
defined
in
the
active
context
.
Multiple
contexts
may
be
combined
using
an
array
,
which
is
processed
in
order.
The
set
of
contexts
defined
within
a
specific
JSON
object
are
referred
to
as
local
contexts
.
The
active
context
refers
to
the
accumulation
of
local
contexts
that
are
in
scope
at
a
specific
point
within
the
document.
Setting
a
local
context
to
null
effectively
resets
the
active
context
to
an
empty
context,
without
term
definitions
,
default
language
,
or
other
things
defined
within
previous
contexts.
The
following
example
specifies
an
external
context
and
then
layers
an
embedded
context
on
top
of
the
external
context:
Example
20
:
Combining
external
and
local
contexts
{ "@context": [
"https://json-ld.org/contexts/person.jsonld",
{
"pic": "http://xmlns.com/foaf/0.1/depiction"
}
],
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"pic": "http://twitter.com/account/profile_image/manusporny"
}
Note
When
possible,
the
context
definition
should
be
put
at
the
top
of
a
JSON-LD
document.
This
makes
the
document
easier
to
read
and
might
make
streaming
parsers
more
efficient.
Documents
that
do
not
have
the
context
at
the
top
are
still
conformant
JSON-LD.
Note
To
avoid
forward-compatibility
issues,
terms
starting
with
an
@
character
are
to
be
avoided
as
they
might
be
used
as
keyword
in
future
versions
of
JSON-LD.
Terms
starting
with
an
@
character
that
are
not
JSON-LD
1.1
keywords
are
treated
as
any
other
term,
i.e.,
they
are
ignored
unless
mapped
to
an
IRI
.
Furthermore,
the
use
of
empty
terms
(
""
)
is
not
allowed
as
not
all
programming
languages
are
able
to
handle
empty
JSON
keys.
4.2
Base
IRI
§
This
section
is
non-normative.
JSON-LD
allows
IRIs
to
be
specified
in
a
relative
form
which
is
resolved
against
the
document
base
according
section
5.1
Establishing
a
Base
URI
of
[
RFC3986
].
The
base
IRI
may
be
explicitly
set
with
a
context
using
the
@base
keyword.
For
example,
if
a
JSON-LD
document
was
retrieved
from
http://example.com/document.jsonld
,
relative
IRIs
would
resolve
against
that
IRI
:
Example
17
:
Use
a
relative
IRI
as
node
identifier
{
"@context": {
"label": "http://www.w3.org/2000/01/rdf-schema#label"
},
,
"label": "Just a simple document"
}
This
document
uses
an
empty
@id
,
which
resolves
to
the
document
base.
However,
if
the
document
is
moved
to
a
different
location,
the
IRI
would
change.
To
prevent
this
without
having
to
use
an
absolute
IRI
,
a
context
may
define
an
@base
mapping,
to
overwrite
the
base
IRI
for
the
document.
Example
18
:
Setting
the
document
base
in
a
document
{
"@context": {
"label": "http://www.w3.org/2000/01/rdf-schema#label"
},
"@id": "",
"label": "Just a simple document"
}
Setting
@base
to
null
will
prevent
relative
IRIs
to
be
expanded
to
absolute
IRIs
.
Please
note
that
the
@base
will
be
ignored
if
used
in
external
contexts.
4.4
4.1.4
Compact
IRIs
§
This
section
is
non-normative.
A
compact
IRI
is
a
way
of
expressing
an
IRI
using
a
prefix
and
suffix
separated
by
a
colon
(
:
).
The
prefix
is
a
term
taken
from
the
active
context
and
is
a
short
string
identifying
a
particular
IRI
in
a
JSON-LD
document.
For
example,
the
prefix
foaf
may
be
used
as
a
short
hand
for
the
Friend-of-a-Friend
vocabulary,
which
is
identified
using
the
IRI
http://xmlns.com/foaf/0.1/
.
A
developer
may
append
any
of
the
FOAF
vocabulary
terms
to
the
end
of
the
prefix
to
specify
a
short-hand
version
of
the
absolute
IRI
for
the
vocabulary
term.
For
example,
foaf:name
would
be
expanded
to
the
IRI
http://xmlns.com/foaf/0.1/name
.
Example
23
28
:
Prefix
expansion
{
"@context": {
"foaf": "http://xmlns.com/foaf/0.1/"
},
"@type": "foaf:Person",
"foaf:name": "Dave Longley"
}
In
the
example
above,
foaf:name
expands
to
the
IRI
http://xmlns.com/foaf/0.1/name
and
foaf:Person
expands
to
http://xmlns.com/foaf/0.1/Person
.
Prefixes
are
expanded
when
the
form
of
the
value
is
a
compact
IRI
represented
as
a
prefix:suffix
combination,
the
prefix
matches
a
term
defined
within
the
active
context
,
and
the
suffix
does
not
begin
with
two
slashes (
//
).
The
compact
IRI
is
expanded
by
concatenating
the
IRI
mapped
to
the
prefix
to
the
(possibly
empty)
suffix
.
If
the
prefix
is
not
defined
in
the
active
context
,
or
the
suffix
begins
with
two
slashes
(such
as
in
http://example.com
),
the
value
is
interpreted
as
absolute
IRI
instead.
If
the
prefix
is
an
underscore
(
_
),
the
value
is
interpreted
as
blank
node
identifier
instead.
It's
also
possible
to
use
compact
IRIs
within
the
context
as
shown
in
the
following
example:
Example
24
29
:
Using
vocabularies
{
"@context": {
"@version": 1.1,
"xsd": "http://www.w3.org/2001/XMLSchema#",
"foaf": "http://xmlns.com/foaf/0.1/",
"foaf:homepage": { "@type": "@id" },
"picture": { "@id": "foaf:depiction", "@type": "@id" }
},
"@id": "http://me.markus-lanthaler.com/",
"@type": "foaf:Person",
"foaf:name": "Markus Lanthaler",
"foaf:homepage": "http://www.markus-lanthaler.com/",
"picture": "http://twitter.com/account/profile_image/markuslanthaler"
}
In
JSON-LD
1.0,
terms
may
be
chosen
as
compact
IRI
prefixes
when
compacting
only
if
a
simple
term
definition
is
used
where
the
value
ends
with
a
URI
gen-delim
character
(e.g,
/
,
#
and
others,
see
[
RFC3986
]).
The
previous
specification
allows
any
term
to
be
chosen
as
a
compact
IRI
prefix,
which
led
to
a
poor
experience.
In
JSON-LD
1.1,
terms
may
be
chosen
as
compact
IRI
prefixes
when
compacting
only
if
a
simple
term
definition
is
used
where
the
value
ends
with
a
URI
gen-delim
character,
or
if
their
expanded
term
definition
contains
a
@prefix
member
with
the
value
true
.
Note
This
represents
a
small
change
to
the
1.0
algorithm
to
prevent
IRIs
that
are
not
really
intended
to
be
used
as
prefixes
from
being
used
for
creating
compact
IRIs
.
When
processing
mode
is
set
to
json-ld-1.1
,
terms
will
be
used
as
compact
IRI
prefixes
when
compacting
only
if
their
expanded
term
definition
contains
a
@prefix
member
with
the
value
true
,
or
if
it
has
a
a
simple
term
definition
where
the
value
ends
with
a
URI
gen-delim
character
(e.g,
/
,
#
and
others,
see
[
RFC3986
]).
Example
25
30
:
Using
explicit
@prefix
declaration
to
create
compact
IRIs
{
"@context": {
"compact-iris": {"@id": "http://example.com/compact-iris-", "@prefix": true},
"property": "http://example.com/property"
},
"property": {
"@id": "compact-iris:are-considered",
"property": "@prefix does not require a gen-delim"
}
}
In
this
case,
the
compact-iris
term
would
not
normally
be
usable
as
a
prefix,
both
because
it
is
defined
with
an
expanded
term
definition
,
and
because
it's
@id
does
not
end
in
a
gen-delim
character.
Adding
"@prefix":
true
allows
it
to
be
used
as
the
prefix
portion
of
the
compact
IRI
compact-iris:are-considered
.
4.1.6
IRI
Expansion
within
a
Context
§
This
section
is
non-normative.
In
general,
normal
IRI
expansion
rules
apply
anywhere
an
IRI
is
expected
(see
section
3.2
IRIs
).
Within
a
context
definition,
this
can
mean
that
terms
defined
within
the
context
may
also
be
used
within
that
context
as
long
as
there
are
no
circular
dependencies.
For
example,
it
is
common
to
use
the
xsd
namespace
when
defining
typed
values
:
Example
32
:
IRI
expansion
within
a
context
{
"@context": {
"xsd": "http://www.w3.org/2001/XMLSchema#",
"name": "http://xmlns.com/foaf/0.1/name",
"age": {
"@id": "http://xmlns.com/foaf/0.1/age",
"@type": "xsd:integer"
},
"homepage": {
"@id": "http://xmlns.com/foaf/0.1/homepage",
"@type": "@id"
}
}
}
In
this
example,
the
xsd
term
is
defined
and
used
as
a
prefix
for
the
@type
coercion
of
the
age
property.
Terms
may
also
be
used
when
defining
the
IRI
of
another
term
:
Example
33
:
Using
a
term
to
define
the
IRI
of
another
term
within
a
context
{
"@context": {
"foaf": "http://xmlns.com/foaf/0.1/",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"name": "foaf:name",
"age": {
"@id": "foaf:age",
"@type": "xsd:integer"
},
"homepage": {
"@id": "foaf:homepage",
"@type": "@id"
}
}
}
Compact
IRIs
and
IRIs
may
be
used
on
the
left-hand
side
of
a
term
definition.
Example
34
:
Using
a
compact
IRI
as
a
term
{
"@context": {
"foaf": "http://xmlns.com/foaf/0.1/",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"name": "foaf:name",
"foaf:age": {
"@type": "xsd:integer"
},
"foaf:homepage": {
"@type": "@id"
}
}
}
In
this
example,
the
compact
IRI
form
is
used
in
two
different
ways.
In
the
first
approach,
foaf:age
declares
both
the
IRI
for
the
term
(using
short-form)
as
well
as
the
@type
associated
with
the
term
.
In
the
second
approach,
only
the
@type
associated
with
the
term
is
specified.
The
full
IRI
for
foaf:homepage
is
determined
by
looking
up
the
foaf
prefix
in
the
context
.
Absolute
IRIs
may
also
be
used
in
the
key
position
in
a
context
:
Example
35
:
Associating
context
definitions
with
absolute
IRIs
{
"@context": {
"foaf": "http://xmlns.com/foaf/0.1/",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"name": "foaf:name",
"foaf:age": {
"@id": "foaf:age",
"@type": "xsd:integer"
},
"http://xmlns.com/foaf/0.1/homepage": {
"@type": "@id"
}
}
}
In
order
for
the
absolute
IRI
to
match
above,
the
absolute
IRI
needs
to
be
used
in
the
JSON-LD
document
.
Also
note
that
foaf:homepage
will
not
use
the
{
"@type":
"@id"
}
declaration
because
foaf:homepage
is
not
the
same
as
http://xmlns.com/foaf/0.1/homepage
.
That
is,
terms
are
looked
up
in
a
context
using
direct
string
comparison
before
the
prefix
lookup
mechanism
is
applied.
Note
While
it
is
possible
to
define
a
compact
IRI
,
or
an
absolute
IRI
to
expand
to
some
other
unrelated
IRI
(for
example,
foaf:name
expanding
to
http://example.org/unrelated#species
),
such
usage
is
strongly
discouraged.
The
only
exception
for
using
terms
in
the
context
is
that
circular
definitions
are
not
allowed.
That
is,
a
definition
of
term1
cannot
depend
on
the
definition
of
term2
if
term2
also
depends
on
term1
.
For
example,
the
following
context
definition
is
illegal:
Example
36
:
Illegal
circular
definition
of
terms
within
a
context
{
"@context": {
"term1": "term2:foo",
"term2": "term1:bar"
}
}
4.1.7
Scoped
Contexts
§
This
section
is
non-normative.
An
expanded
term
definition
can
include
a
@context
property,
which
defines
a
context
(an
embedded
context
)
for
values
of
properties
defined
using
that
term
.
This
allows
values
to
use
term
definitions
,
base
IRI
,
vocabulary
mapping
or
default
language
which
is
different
from
the
node
object
they
are
contained
in,
as
if
the
context
was
specified
within
the
value
itself.
Example
37
:
Defining
an
@context
within
a
term
definition
{
"@context": {
"@version": 1.1,
"name": "http://schema.org/name",
"interest": {
"@id": "http://xmlns.com/foaf/0.1/interest",
"@context": {"@vocab": "http://xmlns.com/foaf/0.1/"}
}
},
"name": "Manu Sporny",
"interest": {
"@id": "https://www.w3.org/TR/json-ld/",
"name": "JSON-LD",
"topic": "Linking Data"
}
}
In
this
case,
the
social
profile
is
defined
using
the
schema.org
vocabulary,
but
interest
is
imported
from
FOAF,
and
is
used
to
define
a
node
describing
one
of
Manu's
interests
where
those
properties
now
come
from
the
FOAF
vocabulary.
Expanding
this
document,
uses
a
combination
of
terms
defined
in
the
outer
context,
and
those
defined
specifically
for
that
term
in
an
embedded
context
.
Example
38
:
Expanded
document
using
a
scoped
context
[{
"http://schema.org/name": [{"@value": "Manu Sporny"}],
"http://xmlns.com/foaf/0.1/interest": [{
"@id": "https://www.w3.org/TR/json-ld/",
"http://schema.org/name": [{"@value": "JSON-LD"}],
"http://xmlns.com/foaf/0.1/topic": [{"@value": "Linking Data"}]
}]
}]
Scoping
can
also
be
performed
using
a
term
used
as
a
value
of
@type
:
Example
39
:
Defining
an
@context
within
a
term
definition
used
on
@type
{
"@context": {
"@version": 1.1,
"name": "http://schema.org/name",
"interest": "http://xmlns.com/foaf/0.1/interest",
"Document": {
"@id": "http://xmlns.com/foaf/0.1/Document",
"@context": {"@vocab": "http://xmlns.com/foaf/0.1/"}
}
},
"@type": "Person",
"name": "Manu Sporny",
"interest": {
"@id": "https://www.w3.org/TR/json-ld/",
"@type": "Document",
"name": "JSON-LD",
"topic": "Linking Data"
}
}
Scoping
on
@type
is
useful
when
common
properties
are
used
to
relate
things
of
different
types,
where
the
vocabularies
in
use
within
different
entities
calls
for
different
context
scoping.
For
example,
hasPart
/
partOf
may
be
common
terms
used
in
a
document,
but
mean
different
things
depending
on
the
context.
When
expanding,
each
value
of
@type
is
considered
(ordering
them
lexographically)
where
that
value
is
also
a
term
in
the
active
context
having
its
own
embedded
context
.
If
so,
that
embedded
context
is
applied
to
the
active
context
.
When
compacting,
if
a
term
is
chosen
to
represent
an
IRI
used
as
a
value
of
@type
where
that
term
definition
also
has
an
embedded
context
,
it
is
then
applied
to
the
active
context
to
affect
further
compaction.
Note
The
values
of
@type
are
unordered,
so
if
multiple
types
are
listed,
the
order
that
scoped
contexts
are
applied
is
based
on
lexicographical
ordering.
Note
If
a
term
defines
a
scoped
context,
and
then
that
term
is
later
re-defined,
the
association
of
the
context
defined
in
the
earlier
expanded
term
definition
is
lost
within
the
scope
of
that
re-definition.
This
is
consistent
with
term
definitions
of
a
term
overriding
previous
term
definitions
from
earlier
less
deeply
nested
definitions,
as
discussed
in
section
4.1
Advanced
Context
Usage
.
Note
Scoped
Contexts
are
a
new
feature
in
JSON-LD
1.1,
requiring
processing
mode
set
to
json-ld-1.1
.
4.2
Describing
Values
§
This
section
is
non-normative.
Values
are
leaf
nodes
in
a
graph
associated
with
scalar
values
such
as
strings
,
dates,
times,
and
other
such
atomic
values.
4.5
4.2.1
Typed
Values
§
This
section
is
non-normative.
A
value
with
an
associated
type,
also
known
as
a
typed
value
,
is
indicated
by
associating
a
value
with
an
IRI
which
indicates
the
value's
type.
Typed
values
may
be
expressed
in
JSON-LD
in
three
ways:
-
By
utilizing
the
@type
keyword
when
defining
a
term
within
an
@context
section.
-
By
utilizing
a
value
object
.
-
By
using
a
native
JSON
type
such
as
number
,
true
,
or
false
.
The
first
example
uses
the
@type
keyword
to
associate
a
type
with
a
particular
term
in
the
@context
:
Example
26
40
:
Expanded
term
definition
with
type
coercion
{
"@context": {
"modified": {
"@id": "http://purl.org/dc/terms/modified",
"@type": "http://www.w3.org/2001/XMLSchema#dateTime"
}
},
"@id": "http://example.com/docs/1",
"modified": "2010-05-29T14:17:39+02:00"
}
The
modified
key's
value
above
is
automatically
type
coerced
to
a
dateTime
value
because
of
the
information
specified
in
the
@context
.
A
JSON-LD
processor
will
interpret
the
example
above
as
follows:
|
Subject
|
Property
|
Value
|
Value
Type
|
|
http://example.com/docs/1
|
http://purl.org/dc/terms/modified
|
2010-05-29T14:17:39+02:00
|
xsd:dateTime
|
The
second
example
uses
the
expanded
form
of
setting
the
type
information
in
the
body
of
a
JSON-LD
document:
Example
27
41
:
Expanded
value
with
type
{
"@context": {
"modified": {
"@id": "http://purl.org/dc/terms/modified"
}
},
"modified": {
"@value": "2010-05-29T14:17:39+02:00",
"@type": "http://www.w3.org/2001/XMLSchema#dateTime"
}
}
Both
examples
above
would
generate
the
value
2010-05-29T14:17:39+02:00
with
the
type
http://www.w3.org/2001/XMLSchema#dateTime
.
Note
that
it
is
also
possible
to
use
a
term
or
a
compact
IRI
to
express
the
value
of
a
type.
A
node
type
specifies
the
type
of
thing
that
is
being
described,
like
a
person,
place,
event,
or
web
page.
A
value
type
specifies
the
data
type
of
a
particular
value,
such
as
an
integer,
a
floating
point
number,
or
a
date.
Example
28
42
:
Example
demonstrating
the
context-sensitivity
for
@type
{
"@id": "http://example.org/posts#TripToWestVirginia",
"@type": "http://schema.org/BlogPosting",
"modified": {
"@value": "2010-05-29T14:17:39+02:00",
"@type": "http://www.w3.org/2001/XMLSchema#dateTime"
}
}
The
first
use
of
@type
associates
a
node
type
(
http://schema.org/BlogPosting
)
with
the
node
,
which
is
expressed
using
the
@id
keyword
.
The
second
use
of
@type
associates
a
value
type
(
http://www.w3.org/2001/XMLSchema#dateTime
)
with
the
value
expressed
using
the
@value
keyword
.
As
a
general
rule,
when
@value
and
@type
are
used
in
the
same
JSON
object
,
the
@type
keyword
is
expressing
a
value
type
.
Otherwise,
the
@type
keyword
is
expressing
a
node
type
.
The
example
above
expresses
the
following
data:
|
Subject
|
Property
|
Value
|
Value
Type
|
|
http://example.org/posts#TripToWestVirginia
|
rdf:type
|
schema:BlogPosting
|
-
|
|
http://example.org/posts#TripToWestVirginia
|
dc:modified
|
2010-05-29T14:17:39+02:00
|
xsd:dateTime
|
4.6
4.2.2
Type
Coercion
§
This
section
is
non-normative.
JSON-LD
supports
the
coercion
of
values
to
particular
data
types.
Type
coercion
allows
someone
deploying
JSON-LD
to
coerce
the
incoming
or
outgoing
values
to
the
proper
data
type
based
on
a
mapping
of
data
type
IRIs
to
terms
.
Using
type
coercion,
value
representation
is
preserved
without
requiring
the
data
type
to
be
specified
with
each
piece
of
data.
Type
coercion
is
specified
within
an
expanded
term
definition
using
the
@type
key.
The
value
of
this
key
expands
to
an
IRI
.
Alternatively,
the
keyword
@id
or
@vocab
may
be
used
as
value
to
indicate
that
within
the
body
of
a
JSON-LD
document,
a
string
value
of
a
term
coerced
to
@id
or
@vocab
is
to
be
interpreted
as
an
IRI
.
The
difference
between
@id
and
@vocab
is
how
values
are
expanded
to
absolute
IRIs
.
@vocab
first
tries
to
expand
the
value
by
interpreting
it
as
term
.
If
no
matching
term
is
found
in
the
active
context
,
it
tries
to
expand
it
as
compact
IRI
or
absolute
IRI
if
there's
a
colon
in
the
value;
otherwise,
it
will
expand
the
value
using
the
active
context's
vocabulary
mapping
,
if
present.
Values
coerced
to
@id
in
contrast
are
expanded
as
compact
IRI
or
absolute
IRI
if
a
colon
is
present;
otherwise,
they
are
interpreted
as
relative
IRI
.
Terms
or
compact
IRIs
used
as
the
value
of
a
@type
key
may
be
defined
within
the
same
context.
This
means
that
one
may
specify
a
term
like
xsd
and
then
use
xsd:integer
within
the
same
context
definition.
The
example
below
demonstrates
how
a
JSON-LD
author
can
coerce
values
to
typed
values
and
IRIs
.
Example
29
43
:
Expanded
term
definition
with
types
{
"@context": {
"xsd": "http://www.w3.org/2001/XMLSchema#",
"name": "http://xmlns.com/foaf/0.1/name",
"age": {
"@id": "http://xmlns.com/foaf/0.1/age",
"@type": "xsd:integer"
},
"homepage": {
"@id": "http://xmlns.com/foaf/0.1/homepage",
"@type": "@id"
}
},
"@id": "http://example.com/people#john",
"name": "John Smith",
"age": "41",
"homepage": [
"http://personal.example.org/",
"http://work.example.com/jsmith/"
]
}
The
example
shown
above
would
generate
the
following
data.
data:
|
Subject
|
Property
|
Value
|
Value
Type
|
|
http://example.com/people#john
|
foaf:name
|
John
Smith
|
|
|
http://example.com/people#john
|
foaf:age
|
41
|
xsd:integer
|
|
http://example.com/people#john
|
foaf:homepage
|
http://personal.example.org/
|
IRI
|
|
http://work.example.com/jsmith/
|
IRI
|
Terms
may
also
be
defined
using
absolute
IRIs
or
compact
IRIs
.
This
allows
coercion
rules
to
be
applied
to
keys
which
are
not
represented
as
a
simple
term
.
For
example:
Example
30
44
:
Term
definitions
using
compact
and
absolute
IRIs
{
"@context": {
"foaf": "http://xmlns.com/foaf/0.1/",
"foaf:age": {
"@id": "http://xmlns.com/foaf/0.1/age",
"@type": "xsd:integer"
},
"http://xmlns.com/foaf/0.1/homepage": {
"@type": "@id"
}
},
"foaf:name": "John Smith",
"foaf:age": "41",
"http://xmlns.com/foaf/0.1/homepage": [
"http://personal.example.org/",
"http://work.example.com/jsmith/"
]
}
In
this
case
the
@id
definition
in
the
term
definition
is
optional.
If
it
does
exist,
the
compact
IRI
or
IRI
representing
the
term
will
always
be
expanded
to
IRI
defined
by
the
@id
key—regardless
of
whether
a
prefix
is
defined
or
not.
Type
coercion
is
always
performed
using
the
unexpanded
value
of
the
key.
In
the
example
above,
that
means
that
type
coercion
is
done
looking
for
foaf:age
in
the
active
context
and
not
for
the
corresponding,
expanded
IRI
http://xmlns.com/foaf/0.1/age
.
Note
Keys
in
the
context
are
treated
as
terms
for
the
purpose
of
expansion
and
value
coercion.
At
times,
this
may
result
in
multiple
representations
for
the
same
expanded
IRI
.
For
example,
one
could
specify
that
dog
and
cat
both
expanded
to
http://example.com/vocab#animal
.
Doing
this
could
be
useful
for
establishing
different
type
coercion
or
language
specification
rules.
It
also
allows
a
compact
IRI
(or
even
an
absolute
IRI
)
to
be
defined
as
something
else
entirely.
For
example,
one
could
specify
that
the
term
http://example.org/zoo
should
expand
to
http://example.org/river
,
but
this
usage
is
discouraged
because
it
would
lead
to
a
great
deal
of
confusion
among
developers
attempting
to
understand
the
JSON-LD
document.
4.7
Embedding
§
This
section
is
non-normative.
Embedding
is
a
JSON-LD
feature
that
allows
an
author
to
use
node
objects
as
property
values.
This
is
a
commonly
used
mechanism
for
creating
a
parent-child
relationship
between
two
nodes
.
Without
embedding,
node
objects
can
be
linked
by
referencing
the
identifier
of
another
node
object
.
For
example:
Example
31
:
Referencing
node
objects
[{
"@context": {
"@vocab": "http://schema.org/",
},
"name": "Manu Sporny",
"@type": "Person",
}, {
"@id": "http://foaf.me/gkellogg#me",
"@type": "Person",
"name": "Gregg Kellogg"
}]
The
previous
example
describes
two
node
objects
,
for
Manu
and
Gregg,
with
the
knows
property
defined
to
treat
string
values
as
identifiers.
Embedding
allows
the
node
object
for
Gregg
to
be
embedded
as
a
value
of
the
knows
property:
Example
32
:
Embedding
a
node
object
as
property
value
of
another
node
object
{
"@context": {
"@vocab": "http://schema.org/"
},
"name": "Manu Sporny",
"@id": "http://foaf.me/gkellogg#me",
"@type": "Person",
"name": "Gregg Kellogg"
}
A
node
object
,
like
the
one
used
above,
may
be
used
in
any
value
position
in
the
body
of
a
JSON-LD
document.
Note
that
type
coercion
of
the
knows
property
is
not
required,
as
the
value
is
not
a
string.
While
it
is
considered
a
best
practice
to
identify
nodes
in
a
graph,
at
times
this
is
impractical.
In
the
data
model,
nodes
without
an
explicit
identifier
are
called
blank
nodes
,
which
can
be
represented
in
a
serialization
such
as
JSON-LD
using
a
blank
node
identifier
.
In
the
previous
example,
the
top-level
node
for
Manu
does
not
have
an
identifier,
and
does
not
need
one
to
describe
it
within
the
data
model.
However,
if
we
were
to
want
to
describe
a
knows
relationship
from
Gregg
to
Manu,
we
would
need
to
introduce
a
blank
node
identifier
(here
_:b0
).
Example
33
:
Referencing
an
unidentified
node
{
"@context": {
"@vocab": "http://schema.org/"
},
"name": "Manu Sporny",
"knows": {
"@id": "http://foaf.me/gkellogg#me",
"@type": "Person",
"name": "Gregg Kellogg",
}
}
Blank
node
identifiers
may
be
automatically
introduced
by
algorithms
such
as
flattening
,
but
they
are
also
useful
for
authors
to
describe
such
relationships
directly.
4.8
Advanced
Context
Usage
§
This
section
is
non-normative.
Section
3.1
The
Context
introduced
the
basics
of
what
makes
JSON-LD
work.
This
section
expands
on
the
basic
principles
of
the
context
and
demonstrates
how
more
advanced
use
cases
can
be
achieved
using
JSON-LD.
In
general,
contexts
may
be
used
at
any
time
a
JSON
object
is
defined.
The
only
time
that
one
cannot
express
a
context
is
as
a
direct
child
of
another
context
definition.
For
example,
a
JSON-LD
document
may
use
more
than
one
context
at
different
points
in
a
document:
Example
34
:
Using
multiple
contexts
[
{
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"depiction": "http://twitter.com/account/profile_image/manusporny"
},
{
"name": "The Empire State Building",
"description": "The Empire State Building is a 102-story landmark in New York City.",
"geo": {
"latitude": "40.75",
"longitude": "73.98"
}
}
]
Duplicate
context
terms
are
overridden
using
a
most-recently-defined-wins
mechanism.
Example
35
:
Scoped
contexts
within
node
objects
{
"@context": {
"name": "http://example.com/person#name",
"details": "http://example.com/person#details"
},
"": "Markus Lanthaler",
"details": {
"@context": {
"name": "http://example.com/organization#name"
},
"": "Graz University of Technology"
}
}
In
the
example
above,
the
name
term
is
overridden
in
the
more
deeply
nested
details
structure.
Note
that
this
is
rarely
a
good
authoring
practice
and
is
typically
used
when
working
with
legacy
applications
that
depend
on
a
specific
structure
of
the
JSON
object
.
If
a
term
is
redefined
within
a
context,
all
previous
rules
associated
with
the
previous
definition
are
removed.
If
a
term
is
redefined
to
null
,
the
term
is
effectively
removed
from
the
list
of
terms
defined
in
the
active
context
.
Multiple
contexts
may
be
combined
using
an
array
,
which
is
processed
in
order.
The
set
of
contexts
defined
within
a
specific
JSON
object
are
referred
to
as
local
contexts
.
The
active
context
refers
to
the
accumulation
of
local
contexts
that
are
in
scope
at
a
specific
point
within
the
document.
Setting
a
local
context
to
null
effectively
resets
the
active
context
to
an
empty
context.
The
following
example
specifies
an
external
context
and
then
layers
an
embedded
context
on
top
of
the
external
context:
Example
36
:
Combining
external
and
local
contexts
{
"@context": [
"https://json-ld.org/contexts/person.jsonld",
{
"pic": "http://xmlns.com/foaf/0.1/depiction"
}
],
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
}
Note
When
possible,
the
context
definition
should
be
put
at
the
top
of
a
JSON-LD
document.
This
makes
the
document
easier
to
read
and
might
make
streaming
parsers
more
efficient.
Documents
that
do
not
have
the
context
at
the
top
are
still
conformant
JSON-LD.
Note
To
avoid
forward-compatibility
issues,
terms
starting
with
an
@
character
are
to
be
avoided
as
they
might
be
used
as
keyword
in
future
versions
of
JSON-LD.
Terms
starting
with
an
@
character
that
are
not
JSON-LD
1.1
keywords
are
treated
as
any
other
term,
i.e.,
they
are
ignored
unless
mapped
to
an
IRI
.
Furthermore,
the
use
of
empty
terms
(
""
)
is
not
allowed
as
not
all
programming
languages
are
able
to
handle
empty
JSON
keys.
4.9
Interpreting
JSON
as
JSON-LD
§
Ordinary
JSON
documents
can
be
interpreted
as
JSON-LD
by
providing
an
explicit
JSON-LD
context
document.
One
way
to
provide
this
is
by
using
referencing
a
JSON-LD
context
document
in
an
HTTP
Link
Header
.
Doing
so
allows
JSON
to
be
unambiguously
machine-readable
without
requiring
developers
to
drastically
change
their
documents
and
provides
an
upgrade
path
for
existing
infrastructure
without
breaking
existing
clients
that
rely
on
the
application/json
media
type
or
a
media
type
with
a
+json
suffix
as
defined
in
[
RFC6839
].
In
order
to
use
an
external
context
with
an
ordinary
JSON
document,
when
retrieving
an
ordinary
JSON
document
via
HTTP,
processors
MUST
retrieve
any
JSON-LD
document
referenced
by
a
Link
Header
with:
rel="http://www.w3.org/ns/json-ld#context"
,
and
type="application/ld+json"
.
The
referenced
document
MUST
have
a
top-level
JSON
object
.
The
@context
subtree
within
that
object
is
added
to
the
top-level
JSON
object
of
the
referencing
document.
If
an
array
is
at
the
top-level
of
the
referencing
document
and
its
items
are
JSON
objects
,
the
@context
subtree
is
added
to
all
array
items.
All
extra
information
located
outside
of
the
@context
subtree
in
the
referenced
document
MUST
be
discarded.
Effectively
this
means
that
the
active
context
is
initialized
with
the
referenced
external
context
.
A
response
MUST
NOT
contain
more
than
one
HTTP
Link
Header
[
RFC5988
]
using
the
http://www.w3.org/ns/json-ld#context
link
relation.
Other
mechanisms
for
providing
a
JSON-LD
Context
MAY
be
described
for
other
URI
schemes.
The
JSON-LD
1.1
Processing
Algorithms
and
API
specification
[
JSON-LD11-API
]
provides
for
an
expandContext
option
for
specifying
a
context
to
use
when
expanding
JSON
documents
programatically.
The
following
example
demonstrates
the
use
of
an
external
context
with
an
ordinary
JSON
document
over
HTTP:
Example
37
:
Referencing
a
JSON-LD
context
from
a
JSON
document
via
an
HTTP
Link
Header
GET /ordinary-json-document.json HTTP/1.1
Host: example.com
Accept: application/ld+json,application/json,*/*;q=0.1
====================================
HTTP/1.1 200 OK
Content-Type:
{
"name": "Markus Lanthaler",
"homepage": "http://www.markus-lanthaler.com/",
"image": "http://twitter.com/account/profile_image/markuslanthaler"
}
Please
note
that
JSON-LD
documents
served
with
the
application/ld+json
media
type
MUST
have
all
context
information,
including
references
to
external
contexts,
within
the
body
of
the
document.
Contexts
linked
via
a
http://www.w3.org/ns/json-ld#context
HTTP
Link
Header
MUST
be
ignored
for
such
documents.
4.10
4.2.3
String
Internationalization
§
This
section
is
non-normative.
At
times,
it
is
important
to
annotate
a
string
with
its
language.
In
JSON-LD
this
is
possible
in
a
variety
of
ways.
First,
it
is
possible
to
define
a
default
language
for
a
JSON-LD
document
by
setting
the
@language
key
in
the
context
:
Example
38
45
:
Setting
the
default
language
of
a
JSON-LD
document
{
"@context": {
"@language": "ja"
},
"name": "花澄",
"occupation": "科学者"
}
The
example
above
would
associate
the
ja
language
code
with
the
two
strings
花澄
and
科学者
.
Languages
codes
are
defined
in
[
BCP47
].
The
default
language
applies
to
all
string
values
that
are
not
type
coerced
.
To
clear
the
default
language
for
a
subtree,
@language
can
be
set
to
null
in
a
local
context
as
follows:
Example
39
46
:
Clearing
default
language
{
"@context": {
"@language": "ja"
},
"name": "花澄",
"details": {
"@context": {
"@language": null
},
"occupation": "Ninja"
}
}
Second,
it
is
possible
to
associate
a
language
with
a
specific
term
using
an
expanded
term
definition
:
Example
40
47
:
Expanded
term
definition
with
language
{
"@context": {
"ex": "http://example.com/vocab/",
"@language": "ja",
"name": { "@id": "ex:name", "@language": null },
"occupation": { "@id": "ex:occupation" },
"occupation_en": { "@id": "ex:occupation", "@language": "en" },
"occupation_cs": { "@id": "ex:occupation", "@language": "cs" }
},
"name": "Yagyū Muneyoshi",
"occupation": "忍者",
"occupation_en": "Ninja",
"occupation_cs": "Nindža"
}
The
example
above
would
associate
忍者
with
the
specified
default
language
code
ja
,
Ninja
with
the
language
code
en
,
and
Nindža
with
the
language
code
cs
.
The
value
of
name
,
Yagyū
Muneyoshi
wouldn't
be
associated
with
any
language
code
since
@language
was
reset
to
null
in
the
expanded
term
definition
.
Just
as
in
the
example
above,
systems
often
need
to
express
the
value
of
a
property
in
multiple
languages.
Typically,
such
systems
also
try
to
ensure
that
developers
have
a
programmatically
easy
way
to
navigate
the
data
structures
for
the
language-specific
data.
In
this
case,
language
maps
may
be
utilized.
Example
41
48
:
Language
map
expressing
a
property
in
three
languages
{
"@context": {
"occupation": { "@id": "ex:occupation", "@container": "@language" }
},
"name": "Yagyū Muneyoshi",
"occupation": {
"ja": "忍者",
"en": "Ninja",
"cs": "Nindža"
}
}
The
example
above
expresses
exactly
the
same
information
as
the
previous
example
but
consolidates
all
values
in
a
single
property.
To
access
the
value
in
a
specific
language
in
a
programming
language
supporting
dot-notation
accessors
for
object
properties,
a
developer
may
use
the
property.language
pattern.
For
example,
to
access
the
occupation
in
English,
a
developer
would
use
the
following
code
snippet:
obj.occupation.en
.
Third,
it
is
possible
to
override
the
default
language
by
using
a
value
object
:
Example
42
49
:
Overriding
default
language
using
an
expanded
value
{
"@context": {
"@language": "ja"
},
"name": "花澄",
"occupation": {
"@value": "Scientist",
"@language": "en"
}
}
This
makes
it
possible
to
specify
a
plain
string
by
omitting
the
@language
tag
or
setting
it
to
null
when
expressing
it
using
a
value
object
:
Example
43
50
:
Removing
language
information
using
an
expanded
value
{
"@context": {
"@language": "ja"
},
"name": {
"@value": "Frank"
},
"occupation": {
"@value": "Ninja",
"@language": "en"
},
"speciality": "手裏剣"
}
4.11
IRI
Expansion
within
a
Context
§
This
section
is
non-normative.
In
general,
normal
IRI
expansion
rules
apply
anywhere
an
IRI
is
expected
(see
See
section
3.2
9.6
IRIs
).
Within
a
context
definition,
this
can
mean
that
terms
defined
within
the
context
may
also
be
used
within
that
context
as
long
as
there
are
no
circular
dependencies.
For
example,
it
is
common
to
use
the
xsd
namespace
when
defining
typed
values
:
Example
44
:
IRI
expansion
within
a
context
Language
Maps
{
"@context": {
,
"name": "http://xmlns.com/foaf/0.1/name",
"age": {
"@id": "http://xmlns.com/foaf/0.1/age",
"@type":
},
"homepage": {
"@id": "http://xmlns.com/foaf/0.1/homepage",
"@type": "@id"
}
},
...
}
In
this
example,
the
xsd
term
is
defined
and
used
as
a
prefix
for
the
@type
coercion
of
the
age
property.
Terms
may
also
be
used
when
defining
the
IRI
of
another
term
:
Example
45
:
Using
a
term
to
define
the
IRI
of
another
term
within
a
context
{
"@context": {
,
"xsd": "http://www.w3.org/2001/XMLSchema#",
"name": ,
"age": {
"@id": ,
"@type": "xsd:integer"
},
"homepage": {
"@id": ,
"@type": "@id"
}
},
...
}
Compact
IRIs
and
IRIs
may
be
used
on
the
left-hand
side
description
of
a
term
definition.
Example
46
:
Using
a
compact
IRI
as
a
term
{
"@context": {
,
"xsd": "http://www.w3.org/2001/XMLSchema#",
"name": "foaf:name",
"": {
"@type": "xsd:integer"
},
"{
"@type": "@id"
}
},
...
}
In
this
example,
the
compact
IRI
form
is
used
in
two
different
ways.
In
the
first
approach,
foaf:age
declares
both
the
IRI
for
the
term
(using
short-form)
as
well
as
the
@type
associated
with
the
term
.
In
the
second
approach,
only
the
@type
associated
with
the
term
is
specified.
The
full
IRI
for
foaf:homepage
is
determined
by
looking
up
the
foaf
prefix
in
the
context
.
Absolute
IRIs
may
also
be
used
in
the
key
position
in
a
context
:
Example
47
:
Associating
context
definitions
with
absolute
IRIs
{
"@context": {
"foaf": "http://xmlns.com/foaf/0.1/",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"name": "foaf:name",
"foaf:age": {
"@id": "foaf:age",
"@type": "xsd:integer"
},
"": {
"@type": "@id"
}
},
...
}
In
order
for
the
absolute
IRI
to
match
above,
the
absolute
IRI
needs
to
be
used
in
the
JSON-LD
document
.
Also
note
that
foaf:homepage
will
not
use
the
{
"@type":
"@id"
}
declaration
because
foaf:homepage
is
not
the
same
as
http://xmlns.com/foaf/0.1/homepage
.
That
is,
terms
are
looked
up
in
a
context
using
direct
string
comparison
before
the
prefix
lookup
mechanism
is
applied.
Note
While
it
is
possible
to
define
a
compact
IRI
,
or
an
absolute
IRI
to
expand
to
some
other
unrelated
IRI
language
maps
(for
example,
foaf:name
expanding
to
http://example.org/unrelated#species
),
such
usage
is
strongly
discouraged.
The
only
exception
for
using
terms
in
the
context
is
that
circular
definitions
are
not
allowed.
That
is,
a
definition
of
term1
cannot
depend
on
set
the
definition
language
of
term2
if
term2
also
depends
on
term1
.
For
example,
the
following
context
definition
is
illegal:
mapped
values.
Example
48
:
Illegal
circular
definition
of
terms
within
a
context
{
"@context": {
"term1": "term2:foo",
"term2": "term1:bar"
},
...
}
4.12
4.3
Sets
and
Lists
Value
Ordering
§
This
section
is
non-normative.
A
JSON-LD
author
can
express
multiple
values
in
a
compact
way
by
using
arrays
.
Since
graphs
do
not
describe
ordering
for
links
between
nodes,
arrays
in
JSON-LD
do
not
provide
an
ordering
of
the
contained
elements
by
default.
This
is
exactly
the
opposite
from
regular
JSON
arrays,
which
are
ordered
by
default.
For
example,
consider
the
following
simple
document:
Example
49
51
:
Multiple
values
with
no
inherent
order
{
"@id": "http://example.org/people#joebob",
"foaf:nick": [ "joe", "bob", "JB" ]
}
The
example
shown
above
would
result
in
the
following
data
being
generated,
each
relating
the
node
to
an
individual
value,
with
no
inherent
order:
|
Subject
|
Property
|
Value
|
|
http://example.org/people#joebob
|
foaf:nick
|
joe
|
|
http://example.org/people#joebob
|
foaf:nick
|
bob
|
|
http://example.org/people#joebob
|
foaf:nick
|
JB
|
Multiple
values
may
also
be
expressed
using
the
expanded
form:
Example
50
52
:
Using
an
expanded
form
to
set
multiple
values
{
"@id": "http://example.org/articles/8",
"dc:title": [
{
"@value": "Das Kapital",
"@language": "de"
},
{
"@value": "Capital",
"@language": "en"
}
]
}
The
example
shown
above
would
generate
the
following
data,
again
with
no
inherent
order:
|
Subject
|
Property
|
Value
|
Language
|
|
http://example.org/articles/8
|
dc:title
|
Das
Kapital
|
de
|
|
http://example.org/articles/8
|
dc:title
|
Capital
|
en
|
Although
multiple
values
of
a
property
are
typically
of
the
same
type,
JSON-LD
places
no
restriction
on
this,
and
a
property
may
have
values
of
different
types:
Example
51
53
:
Multiple
array
values
of
different
types
{
"@id": "http://example.org/people#michael",
"dc:name": [
"Michael",
{"@value": "Mike"},
{"@value": "Miguel", "@language": "es"},
{ "@id": "https://www.wikidata.org/wiki/Q4927524" },
42
]
}
The
example
shown
above
would
generate
the
following
data,
also
with
no
inherent
order:
|
Subject
|
Property
|
Value
|
Language
|
Value
Type
|
|
http://example.org/people#michael
|
dc:name
|
Michael
|
|
|
|
http://example.org/people#michael
|
dc:name
|
Mike
|
|
|
|
http://example.org/people#michael
|
dc:name
|
Miguel
|
es
|
|
|
http://example.org/people#michael
|
dc:name
|
https://www.wikidata.org/wiki/Q4927524
|
|
|
|
http://example.org/people#michael
|
dc:name
|
42
|
|
xsd:integer
|
4.3.1
Lists
§
This
section
is
non-normative.
As
the
notion
of
ordered
collections
is
rather
important
in
data
modeling,
it
is
useful
to
have
specific
language
support.
In
JSON-LD,
a
list
may
be
represented
using
the
@list
keyword
as
follows:
Example
52
54
:
An
ordered
collection
of
values
in
JSON-LD
{
"@id": "http://example.org/people#joebob",
"foaf:nick": {
"@list": [ "joe", "bob", "jaybee" ]
}
}
This
describes
the
use
of
this
array
as
being
ordered,
and
order
is
maintained
when
processing
a
document.
If
every
use
of
a
given
multi-valued
property
is
a
list,
this
may
be
abbreviated
by
setting
@container
to
@list
in
the
context
:
Example
53
55
:
Specifying
that
a
collection
is
ordered
in
the
context
{
"@context": {
"nick": {
"@id": "http://xmlns.com/foaf/0.1/nick",
"@container": "@list"
}
},
"@id": "http://example.org/people#joebob",
"nick": [ "joe", "bob", "jaybee" ]
}
The
implementation
of
lists
in
RDF
depends
on
linking
anonymous
nodes
together
using
the
properties
rdf:first
and
rdf:rest
,
with
the
end
of
the
list
defined
as
the
resource
rdf:nil
.
This
can
be
represented
as
triples,
as
the
following
example
shows:
|
Subject
|
Property
|
Value
|
|
http://example.org/people#joebob
|
foaf:nick
|
_:b0
|
|
_:b0
|
rdf:first
|
joe
|
|
_:b0
|
rdf:rest
|
_:b1
|
|
_:b1
|
rdf:first
|
bob
|
|
_:b1
|
rdf:rest
|
_:b2
|
|
_:b2
|
rdf:first
|
jaybee
|
|
_:b2
|
rdf:rest
|
rdf:nil
|
JSON-LD
provides
a
syntactic
shortcut
for
these
lists.
In
Turtle,
the
graph
would
be
expressed
as
follows:
Example
54
56
:
An
ordered
collection
of
values
in
Turtle
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
<http://example.org/people#joebob>
foaf:nick
(
"joe"
"bob"
"jaybe"
)
.
In
JSON-LD
1.1,
lists
of
lists,
where
the
value
of
a
list
object
,
may
itself
be
a
list
object
,
are
fully
supported.
For
example,
in
GeoJSON
(see
[
RFC7946
]),
coordinates
are
an
ordered
list
of
positions
,
which
are
represented
as
an
array
of
two
or
more
numbers:
Example
55
57
:
Coordinates
expressed
in
GeoJSON
{
"type": "Feature",
"bbox": [-10.0, -10.0, 10.0, 10.0],
"geometry": {
"type": "Polygon",
"coordinates": [
[
[-10.0, -10.0],
[10.0, -10.0],
[10.0, 10.0],
[-10.0, -10.0]
]
]
}
//...
}
For
these
examples,
it's
important
that
values
expressed
within
bbox
and
coordinates
maintain
their
order,
which
requires
the
use
of
embedded
list
structures.
In
JSON-LD
1.1,
we
can
express
this
using
recursive
lists,
by
simply
adding
the
appropriate
context
definion:
Example
56
58
:
Coordinates
expressed
in
JSON-LD
{
"@context": {
"@vocab": "https://purl.org/geojson/vocab#",
"type": "@type",
"bbox": {"@container": "@list"},
"coordinates": {"@container": "@list"}
},
"type": "Feature",
"bbox": [-10.0, -10.0, 10.0, 10.0],
"geometry": {
"type": "Polygon",
"coordinates": [
[
[-10.0, -10.0],
[10.0, -10.0],
[10.0, 10.0],
[-10.0, -10.0]
]
]
}
//...
}
This
is
equivalent
to
the
expanded
form,
which
uses
list
objects
:
Example
57
59
:
Coordinates
expressed
in
JSON-LD
(expanded)
[{
"@type": ["https://purl.org/geojson/vocab#Feature"],
"https://purl.org/geojson/vocab#bbox": [{
"@list": [
{"@value": -10.0},
{"@value": -10.0},
{"@value": 10.0},
{"@value": 10.0}
]
}],
"https://purl.org/geojson/vocab#geometry": [{
"@type": ["https://purl.org/geojson/vocab#Polygon"],
"https://purl.org/geojson/vocab#coordinates": [{
"@list": [{
"@list": [
{"@list": [{"@value": -10.0}, {"@value": -10.0}]},
{"@list": [{"@value": 10.0}, {"@value": -10.0}]},
{"@list": [{"@value": 10.0}, {"@value": 10.0}]},
{"@list": [{"@value": -10.0}, {"@value": -10.0}]}
]
}]
}]
}]
}]
Note
that
coordinates
includes
three
levels
of
lists.
When
expressed
in
Turtle,
this
would
be
the
following:
Example
58
60
:
Coordinates
expressed
in
Turtle
Values
of
terms
associated
with
an
@list
container
are
always
represented
in
the
form
of
an
array
,
even
if
there
is
just
a
single
value
or
no
value
at
all.
4.13
4.4
Reverse
Nested
Properties
§
This
section
is
non-normative.
Many
JSON
APIs
separate
properties
from
their
entities
using
an
intermediate
object;
in
JSON-LD
serializes
directed
graphs
these
are
called
nested
properties
.
That
means
that
every
property
points
from
For
example,
a
node
set
of
possible
labels
may
be
grouped
under
a
common
property:
Example
63
:
Nested
properties
{
"@context": {
"@version": 1.1,
"skos": "http://www.w3.org/2004/02/skos/core#",
"labels": "@nest",
"main_label": {"@id": "skos:prefLabel"},
"other_label": {"@id": "skos:altLabel"},
"homepage": {"@id": "http://schema.org/description", "@type": "@id"}
},
"@id": "http://example.org/myresource",
"homepage": "http://example.org",
"labels": {
"main_label": "This is the main label for my resource",
"other_label": "This is the other label"
}
}
By
defining
labels
using
the
keyword
to
another
node
@nest
,
a
JSON-LD
processor
or
value
.
However,
in
some
cases,
it
is
desirable
to
serialize
in
will
ignore
the
reverse
direction.
Consider
for
example
nesting
created
by
using
the
case
where
a
person
labels
property
and
its
children
should
be
described
in
a
document.
If
process
the
contents
as
if
it
were
declared
directly
within
containing
object.
In
this
case,
the
used
vocabulary
does
not
provide
a
children
labels
property
is
semantically
meaningless.
Defining
it
as
equivalent
to
@nest
causes
it
to
be
ignored
when
expanding,
making
it
equivalent
to
the
following:
Example
64
:
Nested
properties
folded
into
containing
object
{
"@context": {
"skos": "http://www.w3.org/2004/02/skos/core#",
"main_label": {"@id": "skos:prefLabel"},
"other_label": {"@id": "skos:altLabel"},
"homepage": {"@id": "http://schema.org/description", "@type": "@id"}
},
"@id": "http://example.org/myresource",
"homepage": "http://example.org",
"main_label": "This is the main label for my resource",
"other_label": "This is the other label"
}
Similarly,
node
objects
may
contain
a
@nest
property
to
reference
a
term
aliased
to
@nest
which
causes
such
values
to
be
nested
under
that
aliased
term.
Example
65
:
Defining
property
nesting
{
"@context": {
"@version": 1.1,
"skos": "http://www.w3.org/2004/02/skos/core#",
"labels": "@nest",
"main_label": {"@id": "skos:prefLabel", "@nest": "labels"},
"other_label": {"@id": "skos:altLabel", "@nest": "labels"},
"homepage": {"@id": "http://schema.org/description", "@type": "@id"}
},
"@id": "http://example.org/myresource",
"homepage": "http://example.org",
"labels": {
"main_label": "This is the main label for my resource",
"other_label": "This is the other label"
}
}
4.5
Embedding
§
parent
This
section
is
non-normative.
Embedding
is
a
JSON-LD
feature
that
allows
an
author
to
use
node
objects
as
property
,
every
node
representing
values.
This
is
a
child
would
have
to
be
expressed
with
commonly
used
mechanism
for
creating
a
property
parent-child
relationship
between
two
nodes
.
Without
embedding,
node
objects
pointing
to
the
parent
as
in
can
be
linked
by
referencing
the
following
example.
identifier
of
another
node
object
.
For
example:
Example
59
66
:
A
document
with
children
linking
to
their
parent
Referencing
node
objects
[
{
,
"http://example.com/vocab#name": "Homer"
}, {
"@id": "#bart",
"http://example.com/vocab#name": "Bart",
{
"@context": {
"@vocab": "http://schema.org/",
"knows": {"@type": "@id"}
},
"@graph": [{
"name": "Manu Sporny",
"@type": "Person",
"knows": "http://greggkellogg.net/foaf#me"
}, {
"@id": "#lisa",
"http://example.com/vocab#name": "Lisa",
}
]
"@id": "http://greggkellogg.net/foaf#me",
"@type": "Person",
"name": "Gregg Kellogg"
}]
}
Expressing
such
data
is
much
simpler
by
using
JSON-LD's
The
previous
example
describes
two
node
objects
,
for
Manu
and
Gregg,
with
the
@reverse
knows
keyword
:
property
defined
to
treat
string
values
as
identifiers.
Embedding
allows
the
node
object
for
Gregg
to
be
embedded
as
a
value
of
the
knows
property:
Example
60
67
:
A
person
and
its
children
using
Embedding
a
reverse
node
object
as
property
value
of
another
node
object
{
"@id": "#homer",
"http://example.com/vocab#name": "Homer",
: {
: [
{
"@id": "#bart",
"http://example.com/vocab#name": "Bart"
}, {
"@id": "#lisa",
"http://example.com/vocab#name": "Lisa"
}
]
}
"@context": {
"@vocab": "http://schema.org/"
},
"name": "Manu Sporny",
"knows": {
"@id": "http://greggkellogg.net/foaf#me",
"@type": "Person",
"name": "Gregg Kellogg"
}
}
The
@reverse
keyword
can
also
A
node
object
,
like
the
one
used
above,
may
be
used
in
expanded
term
definitions
any
value
position
in
the
body
of
a
JSON-LD
document.
Note
that
type
coercion
to
create
reverse
properties
of
the
knows
property
is
not
required,
as
shown
the
value
is
not
a
string.
While
it
is
considered
a
best
practice
to
identify
nodes
in
a
graph,
at
times
this
is
impractical.
In
the
following
example:
data
model,
nodes
without
an
explicit
identifier
are
called
blank
nodes
,
which
can
be
represented
in
a
serialization
such
as
JSON-LD
using
a
blank
node
identifier
.
In
the
previous
example,
the
top-level
node
for
Manu
does
not
have
an
identifier,
and
does
not
need
one
to
describe
it
within
the
data
model.
However,
if
we
were
to
want
to
describe
a
knows
relationship
from
Gregg
to
Manu,
we
would
need
to
introduce
a
blank
node
identifier
(here
_:b0
).
Example
61
68
:
Using
@reverse
to
define
reverse
properties
Referencing
an
unidentified
node
{
"@context": { "name": "http://example.com/vocab#name",
"@context": {
"@vocab": "http://schema.org/"
},
"@id": "#homer",
"name": "Homer",
: [
{
"@id": "#bart",
"name": "Bart"
}, {
"@id": "#lisa",
"name": "Lisa"
}
]
"@id": "_:b0",
"name": "Manu Sporny",
"knows": {
"@id": "http://greggkellogg.net/foaf#me",
"@type": "Person",
"name": "Gregg Kellogg",
"knows": {"@id": "_:b0"}
}
}
Blank
node
identifiers
may
be
automatically
introduced
by
algorithms
such
as
flattening
,
but
they
are
also
useful
for
authors
to
describe
such
relationships
directly.
4.6
Indexed
Values
§
This
allows
section
is
non-normative.
Sometimes
multiple
property
values
need
to
be
accessed
in
a
more
direct
fashion
than
iterating
though
multiple
array
values.
JSON-LD
provides
an
indexing
mechanism
to
allow
the
use
term
definitions
of
an
intermediate
dictionary
to
associate
specific
indexes
with
associated
values.
-
Data
Indexing
-
As
described
in
section
4.6.1
Data
Indexing
,
base
data
indexing
allows
an
arbitrary
to
reference
a
node
or
value.
-
Language
Indexing
-
As
described
in
section
4.6.2
Language
Indexing
,
language
indexing
allows
a
language
to
reference
a
string
and
be
interpreted
as
the
language
associated
with
that
string.
-
Node
Identifier
Indexing
-
As
described
in
section
4.6.3
Node
Identifier
Indexing
,
node
indentifier
indexing
allows
an
IRI
,
vocabulary
mapping
or
default
language
to
reference
a
node
which
is
different
from
and
be
interpreted
as
the
identifier
of
that
node
object
.
-
Node
Type
Indexing
-
As
described
in
section
4.6.4
Node
Type
Indexing
,
node
type
indexing
allows
an
IRI
they
are
contained
in,
to
reference
a
node
and
be
interpreted
as
if
a
type
of
that
node
.
See
section
4.8
Named
Graphs
for
other
uses
of
indexing
in
JSON-LD.
4.6.1
Data
Indexing
§
This
section
is
non-normative.
Databases
are
typically
used
to
make
access
to
data
more
efficient.
Developers
often
extend
this
sort
of
functionality
into
their
application
data
to
deliver
similar
performance
gains.
Often
this
data
does
not
have
any
meaning
from
a
Linked
Data
standpoint,
but
is
still
useful
for
an
application.
JSON-LD
introduces
the
context
notion
of
index
maps
was
that
can
be
used
to
structure
data
into
a
form
that
is
more
efficient
to
access.
The
data
indexing
feature
allows
an
author
to
structure
data
using
a
simple
key-value
map
where
the
keys
do
not
map
to
IRIs
.
This
enables
direct
access
to
data
instead
of
having
to
scan
an
array
in
search
of
a
specific
item.
In
JSON-LD
such
data
can
be
specified
within
by
associating
the
value
itself.
@index
keyword
with
a
@container
declaration
in
the
context:
Example
62
70
:
Defining
an
@context
within
a
term
definition
Indexing
data
in
JSON-LD
{
"@context": {
,
"name": "http://schema.org/name",
"interest": {
"@id": "http://xmlns.com/foaf/0.1/interest",
"schema": "http://schema.org/",
"name": "schema:name",
"body": "schema:articleBody",
"words": "schema:wordCount",
"post": {
"@id": "schema:blogPost",
"@container": "@index"
}
},
"name": "Manu Sporny",
"interest": {
"@id": "https://www.w3.org/TR/json-ld/",
"name": "JSON-LD",
"topic": "Linking Data"
}
"@id": "http://example.com/",
"@type": "schema:Blog",
"name": "World Financial News",
"post": {
"en": {
"@id": "http://example.com/posts/1/en",
"body": "World commodities were up today with heavy trading of crude oil...",
"words": 1539
},
"de": {
"@id": "http://example.com/posts/1/de",
"body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
"words": 1204
}
}
}
In
this
case,
the
social
profile
is
defined
using
example
above,
the
schema.org
vocabulary,
but
interest
is
imported
from
FOAF,
post
term
has
been
marked
as
an
index
map
.
The
en
and
is
used
to
define
de
keys
will
be
ignored
semantically,
but
preserved
syntactically,
by
the
JSON-LD
Processor
.
This
allows
a
node
describing
one
developer
to
access
the
German
version
of
Manu's
interests
where
those
properties
now
come
from
the
FOAF
vocabulary.
post
using
the
following
code
snippet:
obj.post.de
.
Expanding
this
document,
uses
a
combination
The
interpretation
of
terms
defined
the
data
above
is
expressed
in
the
outer
context,
table
below.
Note
how
the
index
keys
do
not
appear
in
the
Linked
Data
below,
but
would
continue
to
exist
if
the
document
were
compacted
or
expanded
(see
section
5.2
Compacted
Document
Form
and
those
defined
specifically
for
section
5.1
Expanded
Document
Form
)
using
a
JSON-LD
processor
:
|
Subject
|
Property
|
Value
|
|---|
|
http://example.com/
|
rdf:type
|
schema:Blog
|
|
http://example.com/
|
schema:name
|
World
Financial
News
|
|
http://example.com/
|
schema:blogPost
|
http://example.com/posts/1/en
|
|
http://example.com/
|
schema:blogPost
|
http://example.com/posts/1/de
|
|
http://example.com/posts/1/en
|
schema:articleBody
|
World
commodities
were
up
today
with
heavy
trading
of
crude
oil...
|
|
http://example.com/posts/1/en
|
schema:wordCount
|
1539
|
|
http://example.com/posts/1/de
|
schema:articleBody
|
Die
Werte
an
Warenbörsen
stiegen
im
Sog
eines
starken
Handels
von
Rohöl...
|
|
http://example.com/posts/1/de
|
schema:wordCount
|
1204
|
The
value
of
@container
can
also
be
an
array
containing
both
@index
and
@set
.
When
compacting
,
this
ensures
that
term
a
JSON-LD
Processor
will
use
the
array
form
for
all
values
of
indexes.
Example
71
:
Indexing
data
in
JSON-LD
with
@set
representation
{
"@context": {
"@version": 1.1,
"schema": "http://schema.org/",
"name": "schema:name",
"body": "schema:articleBody",
"words": "schema:wordCount",
"post": {
"@id": "schema:blogPost",
"@container": ["@index", "@set"]
}
},
"@id": "http://example.com/",
"@type": "schema:Blog",
"name": "World Financial News",
"post": {
"en": [{
"@id": "http://example.com/posts/1/en",
"body": "World commodities were up today with heavy trading of crude oil...",
"words": 1539
}],
"de": [{
"@id": "http://example.com/posts/1/de",
"body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
"words": 1204
}]
}
}
If
the
processing
mode
is
set
to
json-ld-1.1
,
the
special
index
@none
is
used
for
indexing
data
which
does
not
have
an
embedded
context
.
associated
index,
which
is
useful
to
maintain
a
normalized
representation.
Example
63
72
:
Expanded
document
Indexing
data
using
a
scoped
context
@none
[{
"http://schema.org/name": [{"@value": "Manu Sporny"}],
"http://xmlns.com/foaf/0.1/interest": [{
"@id": "https://www.w3.org/TR/json-ld/",
"http://schema.org/name": [{"@value": "JSON-LD"}],
}]
}]
{
"@context": {
"schema": "http://schema.org/",
"name": "schema:name",
"body": "schema:articleBody",
"words": "schema:wordCount",
"post": {
"@id": "schema:blogPost",
"@container": "@index"
}
},
"@id": "http://example.com/",
"@type": "schema:Blog",
"name": "World Financial News",
"post": {
"en": {
"@id": "http://example.com/posts/1/en",
"body": "World commodities were up today with heavy trading of crude oil...",
"words": 1539
},
"de": {
"@id": "http://example.com/posts/1/de",
"body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
"words": 1204
},
"@none": {
"@id": "http://example.com/posts/1/no-language",
"body": "Unindexed description",
"words": 20
}
}
}
4.6.3
Node
Identifier
Indexing
§
This
section
is
non-normative.
In
addition
to
index
maps
,
JSON-LD
introduces
the
notion
of
different
types,
id
maps
for
structuring
data.
The
id
indexing
feature
allows
an
author
to
structure
data
using
a
simple
key-value
map
where
the
vocabularies
keys
map
to
IRIs
.
This
enables
direct
access
to
associated
node
objects
instead
of
having
to
scan
an
array
in
use
within
different
entities
calls
for
different
context
scoping.
For
example,
search
of
a
specific
item.
In
JSON-LD
such
data
can
be
specified
by
associating
the
hasPart
@id
/
keyword
with
a
partOf
@container
may
be
common
terms
used
declaration
in
a
document,
but
mean
different
things
depending
on
the
context.
context:
Example
76
:
Indexing
data
in
JSON-LD
by
node
identifiers
{
"@context": {
"@version": 1.1,
"schema": "http://schema.org/",
"name": "schema:name",
"body": "schema:articleBody",
"words": "schema:wordCount",
"post": {
"@id": "schema:blogPost",
"@container": "@id"
}
},
"@id": "http://example.com/",
"@type": "schema:Blog",
"name": "World Financial News",
"post": {
"http://example.com/posts/1/en": {
"body": "World commodities were up today with heavy trading of crude oil...",
"words": 1539
},
"http://example.com/posts/1/de": {
"body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
"words": 1204
}
}
}
When
expanding,
each
value
of
In
the
example
above,
the
@type
post
is
considered
(ordering
them
lexographically)
where
that
value
is
also
a
term
in
the
active
context
having
its
own
embedded
context
has
been
marked
as
an
id
map
.
If
so,
that
embedded
context
is
applied
to
The
http://example.com/posts/1/en
and
http://example.com/posts/1/de
keys
will
be
interpreted
as
the
active
context
.
When
compacting,
if
a
term
@id
property
of
the
node
object
value.
The
interpretation
of
the
data
above
is
chosen
to
represent
an
IRI
used
exactly
the
same
as
that
in
section
4.6.1
Data
Indexing
using
a
JSON-LD
processor
.
The
value
of
@type
@container
where
that
term
definition
can
also
has
be
an
embedded
context
,
it
is
then
applied
to
array
containing
both
@id
and
@set
.
When
compacting
,
this
ensures
that
a
JSON-LD
processor
will
use
the
active
context
array
to
affect
further
compaction.
form
for
all
values
of
node
identifiers.
Note
Example
77
:
Indexing
data
in
JSON-LD
by
node
identifiers
with
@set
representation
{
"@context": {
"@version": 1.1,
"schema": "http://schema.org/",
"name": "schema:name",
"body": "schema:articleBody",
"words": "schema:wordCount",
"post": {
"@id": "schema:blogPost",
"@container": ["@id", "@set"]
}
},
"@id": "http://example.com/",
"@type": "schema:Blog",
"name": "World Financial News",
"post": {
"http://example.com/posts/1/en": [{
"body": "World commodities were up today with heavy trading of crude oil...",
"words": 1539
}],
"http://example.com/posts/1/de": [{
"body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
"words": 1204
}]
}
}
The
values
of
special
index
@type
@none
are
unordered,
so
if
multiple
types
are
listed,
the
order
that
scoped
contexts
are
applied
is
based
on
lexicographical
ordering.
used
for
indexing
node
objects
which
do
not
have
an
@id
,
which
is
useful
to
maintain
a
normalized
representation.
The
@none
index
may
also
be
a
term
which
expands
to
@none
,
such
as
the
term
none
used
in
the
example
below.
Example
78
:
Indexing
data
in
JSON-LD
by
node
identifiers
using
@none
{
"@context": {
"@version": 1.1,
"schema": "http://schema.org/",
"name": "schema:name",
"body": "schema:articleBody",
"words": "schema:wordCount",
"post": {
"@id": "schema:blogPost",
"@container": "@id"
},
"none": "@none"
},
"@id": "http://example.com/",
"@type": "schema:Blog",
"name": "World Financial News",
"post": {
"http://example.com/posts/1/en": {
"body": "World commodities were up today with heavy trading of crude oil...",
"words": 1539
},
"http://example.com/posts/1/de": {
"body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
"words": 1204
},
"none": {
"body": "Description for object within an @id",
"words": 20
}
}
}
Note
If
a
term
Id
maps
defines
are
a
scoped
context,
and
then
that
term
new
feature
in
JSON-LD
1.1,
requiring
processing
mode
set
to
json-ld-1.1
.
4.6.4
Node
Type
Indexing
§
This
section
is
later
re-defined,
non-normative.
In
addition
to
id
and
index
maps
,
JSON-LD
introduces
the
association
notion
of
type
maps
for
structuring
data.
The
type
indexing
feature
allows
an
author
to
structure
data
using
a
simple
key-value
map
where
the
context
defined
keys
map
to
IRIs
.
This
enables
data
to
be
structured
based
on
the
@type
of
specific
node
objects
.
In
JSON-LD
such
data
can
be
specified
by
associating
the
@type
keyword
with
a
@container
declaration
in
the
earlier
expanded
context:
Example
79
:
Indexing
data
in
JSON-LD
by
type
{
"@context": {
"@version": 1.1,
"schema": "http://schema.org/",
"name": "schema:name",
"affiliation": {
"@id": "schema:affiliation",
"@container": "@type"
}
},
"name": "Manu Sporny",
"affiliation": {
"schema:Corporation": {
"@id": "https://digitalbazaar.com/",
"name": "Digital Bazaar"
},
"schema:ProfessionalService": {
"@id": "https://spec-ops.io",
"name": "Spec-Ops"
}
}
}
In
the
example
above,
the
affiliation
term
definition
is
lost
within
has
been
marked
as
an
type
map
.
The
schema:Corporation
and
schema:ProfessionalService
keys
will
be
interpreted
as
the
scope
@type
property
of
the
node
object
value.
The
value
of
@container
can
also
be
an
array
containing
both
@type
and
@set
.
When
compacting
,
this
ensures
that
re-definition.
This
is
consistent
with
term
definitions
a
JSON-LD
processor
will
use
the
array
form
for
all
values
of
types.
Example
80
:
Indexing
data
in
JSON-LD
by
type
with
@set
representation
{
"@context": {
"@version": 1.1,
"schema": "http://schema.org/",
"name": "schema:name",
"affiliation": {
"@id": "schema:affiliation",
"@container": ["@type", "@set"]
}
},
"name": "Manu Sporny",
"affiliation": {
"schema:Corporation": [{
"@id": "https://digitalbazaar.com/",
"name": "Digital Bazaar"
}],
"schema:ProfessionalService": [{
"@id": "https://spec-ops.io",
"name": "Spec-Ops"
}]
}
}
The
special
index
@none
is
used
for
indexing
node
objects
which
do
not
have
an
@type
,
which
is
useful
to
maintain
a
normalized
representation.
The
@none
index
may
also
be
a
term
overriding
previous
term
definitions
from
earlier
less
deeply
nested
definitions,
which
expands
to
@none
,
such
as
discussed
the
term
none
used
in
section
4.8
the
example
below.
Example
81
Advanced
Context
Usage
:
Indexing
data
in
JSON-LD
by
type
using
@none
.
{
"@context": {
"@version": 1.1,
"schema": "http://schema.org/",
"name": "schema:name",
"affiliation": {
"@id": "schema:affiliation",
"@container": "@type"
},
"none": "@none"
},
"name": "Manu Sporny",
"affiliation": {
"schema:Corporation": {
"@id": "https://digitalbazaar.com/",
"name": "Digital Bazaar"
},
"schema:ProfessionalService": {
"@id": "https://spec-ops.io",
"name": "Spec-Ops"
},
"none": {
"@id": "http://greggkellogg.net/",
"name": "Gregg Kellogg"
}
}
}
As
with
id
maps
,
when
used
with
@type
,
a
container
may
also
include
@set
to
ensure
that
key
values
are
always
contained
in
an
array.
4.15
4.8
Named
Graphs
§
This
section
is
non-normative.
At
times,
it
is
necessary
to
make
statements
about
a
graph
itself,
rather
than
just
a
single
node
.
This
can
be
done
by
grouping
a
set
of
nodes
using
the
@graph
keyword
.
A
developer
may
also
name
data
expressed
using
the
@graph
keyword
by
pairing
it
with
an
@id
keyword
as
shown
in
the
following
example:
Example
65
85
:
Identifying
and
making
statements
about
a
graph
{
"@context": {
"generatedAt": {
"@id": "http://www.w3.org/ns/prov#generatedAtTime",
"@type": "http://www.w3.org/2001/XMLSchema#date"
},
"Person": "http://xmlns.com/foaf/0.1/Person",
"name": "http://xmlns.com/foaf/0.1/name",
"knows": "http://xmlns.com/foaf/0.1/knows"
},
"@id": "http://example.org/foaf-graph",
"generatedAt": "2012-04-09",
"@graph": [
{
"@id": "http://manu.sporny.org/about#manu",
"@type": "Person",
"name": "Manu Sporny",
"knows": "http://greggkellogg.net/foaf#me"
}, {
"@id": "http://greggkellogg.net/foaf#me",
"@type": "Person",
"name": "Gregg Kellogg",
"knows": "http://manu.sporny.org/about#manu"
}
]
}
The
example
above
expresses
a
named
graph
that
is
identified
by
the
IRI
http://example.org/foaf-graph
.
That
graph
is
composed
of
the
statements
about
Manu
and
Gregg.
Metadata
about
the
graph
itself
is
expressed
via
the
generatedAt
property,
which
specifies
when
the
graph
was
generated.
An
alternative
view
of
the
information
above
is
represented
in
table
form
below:
|
Graph
|
Subject
|
Property
|
Value
|
Value
Type
|
|
|
http://example.org/foaf-graph
|
prov:generatedAtTime
|
2012-04-09
|
xsd:date
|
|
http://example.org/foaf-graph
|
http://manu.sporny.org/about#manu
|
xsd:type
|
foaf:Person
|
|
|
http://example.org/foaf-graph
|
http://manu.sporny.org/about#manu
|
foaf:name
|
Manu
Sporny
|
|
|
http://example.org/foaf-graph
|
http://manu.sporny.org/about#manu
|
foaf:knows
|
http://greggkellogg.net/foaf#me
|
|
|
http://example.org/foaf-graph
|
http://greggkellogg.net/foaf#me
|
xsd:type
|
foaf:Person
|
|
|
http://example.org/foaf-graph
|
http://greggkellogg.net/foaf#me
|
foaf:name
|
Gregg
Kellogg
|
|
|
http://example.org/foaf-graph
|
http://greggkellogg.net/foaf#me
|
foaf:knows
|
http://manu.sporny.org/about#manu
|
|
When
a
JSON-LD
document's
top-level
structure
is
an
object
that
contains
no
other
properties
than
@graph
and
optionally
@context
(properties
that
are
not
mapped
to
an
IRI
or
a
keyword
are
ignored),
@graph
is
considered
to
express
the
otherwise
implicit
default
graph
.
This
mechanism
can
be
useful
when
a
number
of
nodes
exist
at
the
document's
top
level
that
share
the
same
context
,
which
is,
e.g.,
the
case
when
a
document
is
flattened
.
The
@graph
keyword
collects
such
nodes
in
an
array
and
allows
the
use
of
a
shared
context.
Example
66
86
:
Using
@graph
to
explicitly
express
the
default
graph
{
"@context": {},
"@graph": [
{
"@id": "http://manu.sporny.org/about#manu",
"@type": "foaf:Person",
"name": "Manu Sporny",
"knows": "http://greggkellogg.net/foaf#me"
}, {
"@id": "http://greggkellogg.net/foaf#me",
"@type": "foaf:Person",
"name": "Gregg Kellogg",
"knows": "http://manu.sporny.org/about#manu"
}
]
}
In
this
case,
embedding
doesn't
work
as
each
node
object
references
the
other.
This
is
equivalent
to
using
multiple
node
objects
in
array
and
defining
the
@context
within
each
node
object
:
Example
67
87
:
Context
needs
to
be
duplicated
if
@graph
is
not
used
[
{
"@context": {},
"@id": "http://manu.sporny.org/about#manu",
"@type": "foaf:Person",
"name": "Manu Sporny",
"knows": "http://greggkellogg.net/foaf#me"
},
{
"@context": {},
"@id": "http://greggkellogg.net/foaf#me",
"@type": "foaf:Person",
"name": "Gregg Kellogg",
"knows": "http://manu.sporny.org/about#manu"
}
]
4.15.1
4.8.1
Graph
Containers
§
In
some
cases,
it
is
useful
to
logically
partition
data
into
separate
graphs,
without
making
this
explicit
within
the
JSON
expression.
For
example,
a
JSON
document
may
contain
data
against
which
other
metadata
is
asserted
and
it
is
useful
to
separate
this
data
in
the
data
model
using
the
notion
of
named
graphs
,
without
the
syntactic
overhead
associated
with
the
@graph
keyword.
An
expanded
term
definition
can
use
@graph
as
the
value
of
@container
.
This
indicates
that
values
of
this
term
should
be
considered
to
be
named
graphs
,
where
the
graph
name
is
an
automatically
assigned
blank
node
identifier
creating
an
implicitly
named
graph
.
When
expanded,
these
become
simple
graph
objects
.
An
alternative
to
our
example
above
could
use
an
anonymously
named
graph
as
follows:
Example
68
88
:
Implicitly
named
graph
{
"@context": {
"@version": 1.1,
"generatedAt": {
"@id": "http://www.w3.org/ns/prov#generatedAtTime",
"@type": "http://www.w3.org/2001/XMLSchema#date"
},
"Person": "http://xmlns.com/foaf/0.1/Person",
"name": "http://xmlns.com/foaf/0.1/name",
"knows": "http://xmlns.com/foaf/0.1/knows",
"claim": {
"@id": "https://w3id.org/credentials#claim",
"@container": "@graph"
}
},
"@id": "http://example.org/foaf-graph",
"generatedAt": "2012-04-09",
"claim": [
{
"@id": "http://manu.sporny.org/about#manu",
"@type": "Person",
"name": "Manu Sporny",
"knows": "http://greggkellogg.net/foaf#me"
}, {
"@id": "http://greggkellogg.net/foaf#me",
"@type": "Person",
"name": "Gregg Kellogg",
"knows": "http://manu.sporny.org/about#manu"
}
]
}
The
example
above
expresses
a
named
graph
that
is
identified
by
the
blank
node
identifier
_:b0
.
That
graph
is
composed
of
the
statements
about
Manu
and
Gregg.
Metadata
about
the
graph
itself
is
expressed
via
the
generatedAt
property,
which
specifies
when
the
graph
was
generated.
An
alternative
view
of
the
information
above
is
represented
in
table
form
below:
|
Graph
|
Subject
|
Property
|
Value
|
Value
Type
|
|
|
http://example.org/foaf-graph
|
prov:generatedAtTime
|
2012-04-09
|
xsd:date
|
|
|
http://example.org/foaf-graph
|
cred:claim
|
_:b0
|
|
|
_:b0
|
http://manu.sporny.org/about#manu
|
xsd:type
|
foaf:Person
|
|
|
_:b0
|
http://manu.sporny.org/about#manu
|
foaf:name
|
Manu
Sporny
|
|
|
_:b0
|
http://manu.sporny.org/about#manu
|
foaf:knows
|
http://greggkellogg.net/foaf#me
|
|
|
_:b0
|
http://greggkellogg.net/foaf#me
|
xsd:type
|
foaf:Person
|
|
|
_:b0
|
http://greggkellogg.net/foaf#me
|
foaf:name
|
Gregg
Kellogg
|
|
|
_:b0
|
http://greggkellogg.net/foaf#me
|
foaf:knows
|
http://manu.sporny.org/about#manu
|
|
Note
The
blank
node
identifier
_:b0
is
automatically
created
to
allow
the
default
graph
to
reference
the
named
graph
as
the
definition
of
the
claim
.
These
are
necessary
for
serialization,
where
nodes
without
explicit
identifiers,
such
as
the
named
graph
in
this
case,
can
be
represented.
Expanding
this
graph
results
in
the
following:
Example
69
89
:
Implicitly
named
graph
after
expansion
[{
"http://www.w3.org/ns/prov#generatedAtTime": [{
"@value": "2012-04-09",
"@type": "http://www.w3.org/2001/XMLSchema#date"
}],
"@id": "http://example.org/foaf-graph",
"https://w3id.org/credentials#claim": [{
"@graph": [{
"@id": "http://manu.sporny.org/about#manu",
"@type": ["http://xmlns.com/foaf/0.1/Person"],
"http://xmlns.com/foaf/0.1/knows": [{
"@value": "http://greggkellogg.net/foaf#me"
}],
"http://xmlns.com/foaf/0.1/name": [{
"@value": "Manu Sporny"
}]
}, {
"@id": "http://greggkellogg.net/foaf#me",
"@type": ["http://xmlns.com/foaf/0.1/Person"],
"http://xmlns.com/foaf/0.1/knows": [{
"@value": "http://manu.sporny.org/about#manu"
}],
"http://xmlns.com/foaf/0.1/name": [{
"@value": "Gregg Kellogg"
}]
}]
}]
}]
Note
Graph
Containers
are
a
new
feature
in
JSON-LD
1.1,
requiring
processing
mode
set
to
json-ld-1.1
.
4.16
Identifying
Blank
Nodes
§
This
section
is
non-normative.
At
times,
it
becomes
necessary
to
be
able
to
express
information
without
being
able
to
uniquely
identify
the
node
with
an
IRI
.
This
type
of
node
is
called
a
blank
node
.
JSON-LD
does
not
require
all
nodes
to
be
identified
using
@id
.
However,
some
graph
topologies
may
require
identifiers
to
be
serializable.
Graphs
containing
loops,
e.g.,
cannot
be
serialized
using
embedding
alone,
@id
must
be
used
to
connect
the
nodes.
In
these
situations,
one
can
use
blank
node
identifiers
,
which
look
like
IRIs
using
an
underscore
(
_
)
as
scheme.
This
allows
one
to
reference
the
node
locally
within
the
document,
but
makes
it
impossible
to
reference
the
node
from
an
external
document.
The
blank
node
identifier
is
scoped
to
the
document
in
which
it
is
used.
Example
70
:
Specifying
a
local
blank
node
identifier
{
"@id": "",
"name": "Secret Agent 1",
"knows": {
"name": "Secret Agent 2",
"knows": { "@id": "" }
}
}
The
example
above
contains
information
about
two
secret
agents
that
cannot
be
identified
with
an
IRI
.
While
expressing
that
agent 1
knows
agent 2
is
possible
without
using
blank
node
identifiers
,
it
is
necessary
to
assign
agent 1
an
identifier
so
that
it
can
be
referenced
from
agent 2
.
It
is
worth
noting
that
blank
node
identifiers
may
be
relabeled
during
processing.
If
a
developer
finds
that
they
refer
to
the
blank
node
more
than
once,
they
should
consider
naming
the
node
using
a
dereferenceable
IRI
so
that
it
can
also
be
referenced
from
other
documents.
4.17
Aliasing
Keywords
§
This
section
is
non-normative.
Each
of
the
JSON-LD
keywords
,
except
for
@context
,
may
be
aliased
to
application-specific
keywords.
This
feature
allows
legacy
JSON
content
to
be
utilized
by
JSON-LD
by
re-using
JSON
keys
that
already
exist
in
legacy
documents.
This
feature
also
allows
developers
to
design
domain-specific
implementations
using
only
the
JSON-LD
context
.
Example
71
:
Aliasing
keywords
{
"@context": {
,
,
"name": "http://xmlns.com/foaf/0.1/name"
},
"": "http://example.com/about#gregg",
"": "http://xmlns.com/foaf/0.1/Person",
"name": "Gregg Kellogg"
}
In
the
example
above,
the
@id
and
@type
keywords
have
been
given
the
aliases
url
and
a
,
respectively.
Since
keywords
cannot
be
redefined,
they
can
also
not
be
aliased
to
other
keywords.
4.18
Data
Indexing
§
This
section
is
non-normative.
Databases
are
typically
used
to
make
access
to
data
more
efficient.
Developers
often
extend
this
sort
of
functionality
into
their
application
data
to
deliver
similar
performance
gains.
Often
this
data
does
not
have
any
meaning
from
a
Linked
Data
standpoint,
but
is
still
useful
for
an
application.
JSON-LD
introduces
the
notion
of
index
maps
that
can
be
used
to
structure
data
into
a
form
that
is
more
efficient
to
access.
The
data
indexing
feature
allows
an
author
to
structure
data
using
a
simple
key-value
map
where
the
keys
do
not
map
to
IRIs
.
This
enables
direct
access
to
data
instead
of
having
to
scan
an
array
in
search
of
a
specific
item.
In
JSON-LD
such
data
can
be
specified
by
associating
the
@index
keyword
with
a
@container
declaration
in
the
context:
Example
72
:
Indexing
data
in
JSON-LD
{
"@context": {
"schema": "http://schema.org/",
"name": "schema:name",
"body": "schema:articleBody",
"words": "schema:wordCount",
"post": {
"@id": "schema:blogPost",
}
},
"@id": "http://example.com/",
"@type": "schema:Blog",
"name": "World Financial News",
"post": {
"en": {
"@id": "http://example.com/posts/1/en",
"body": "World commodities were up today with heavy trading of crude oil...",
"words": 1539
},
"de": {
"@id": "http://example.com/posts/1/de",
"body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
"words": 1204
}
}
}
In
the
example
above,
the
post
term
has
been
marked
as
an
index
map
.
The
en
and
de
keys
will
be
ignored
semantically,
but
preserved
syntactically,
by
the
JSON-LD
Processor
.
This
allows
a
developer
to
access
the
German
version
of
the
post
using
the
following
code
snippet:
obj.post.de
.
The
interpretation
of
the
data
above
is
expressed
in
the
table
below.
Note
how
the
index
keys
do
not
appear
in
the
Linked
Data
below,
but
would
continue
to
exist
if
the
document
were
compacted
or
expanded
(see
section
4.26
Compacted
Document
Form
and
section
4.25
Expanded
Document
Form
)
using
a
JSON-LD
processor
:
Subject
Property
Value
http://example.com/
rdf:type
schema:Blog
http://example.com/
schema:name
World
Financial
News
http://example.com/
schema:blogPost
http://example.com/posts/1/en
http://example.com/
schema:blogPost
http://example.com/posts/1/de
http://example.com/posts/1/en
schema:articleBody
World
commodities
were
up
today
with
heavy
trading
of
crude
oil...
http://example.com/posts/1/en
schema:wordCount
1539
http://example.com/posts/1/de
schema:articleBody
Die
Werte
an
Warenbörsen
stiegen
im
Sog
eines
starken
Handels
von
Rohöl...
http://example.com/posts/1/de
schema:wordCount
1204
The
value
of
@container
can
also
be
an
array
containing
both
@index
and
@set
.
When
compacting
,
this
ensures
that
a
JSON-LD
Processor
will
use
the
array
form
for
all
values
of
indexes.
Example
73
:
Indexing
data
in
JSON-LD
with
@set
representation
{
"@context": {
,
"schema": "http://schema.org/",
"name": "schema:name",
"body": "schema:articleBody",
"words": "schema:wordCount",
"post": {
"@id": "schema:blogPost",
"@container":
}
},
"@id": "http://example.com/",
"@type": "schema:Blog",
"name": "World Financial News",
"post": {
"en": {
"@id": "http://example.com/posts/1/en",
"body": "World commodities were up today with heavy trading of crude oil...",
"words": 1539
},
"de": {
"@id": "http://example.com/posts/1/de",
"body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
"words": 1204
}
}
}
If
the
processing
mode
is
set
to
json-ld-1.1
,
the
special
index
@none
is
used
for
indexing
data
which
does
not
have
an
associated
index,
which
is
useful
to
maintain
a
normalized
representation.
Example
74
:
Indexing
data
using
@none
{
"@context": {
"schema": "http://schema.org/",
"name": "schema:name",
"body": "schema:articleBody",
"words": "schema:wordCount",
"post": {
"@id": "schema:blogPost",
}
},
"@id": "http://example.com/",
"@type": "schema:Blog",
"name": "World Financial News",
"post": {
"en": {
"@id": "http://example.com/posts/1/en",
"body": "World commodities were up today with heavy trading of crude oil...",
"words": 1539
},
"de": {
"@id": "http://example.com/posts/1/de",
"body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
"words": 1204
},
"@none": {
"@id": "http://example.com/posts/1/no-language",
"body": "Unindexed description",
"words": 20
}
}
}
4.19
4.8.2
Named
Graph
Data
Indexing
§
In
addition
to
indexing
node
objects
by
index,
graph
objects
may
also
be
indexed
by
an
index.
By
using
the
@graph
container
type,
introduced
in
section
4.15.1
4.8.1
Graph
Containers
in
addition
to
@index
,
an
object
value
of
such
a
property
is
treated
as
a
key-value
map
where
the
keys
do
not
map
to
IRIs
,
but
are
taken
from
an
@index
property
associated
with
named
graphs
which
are
their
values.
When
expanded,
these
must
be
simple
graph
objects
The
following
example
describes
a
default
graph
referencing
multiple
named
graphs
using
an
index
map
.
Example
75
90
:
Indexing
graph
data
in
JSON-LD
{
"@context": {
"@version": 1.1,
"schema": "http://schema.org/",
"name": "schema:name",
"body": "schema:articleBody",
"words": "schema:wordCount",
"post": {
"@id": "schema:blogPost",
"@container": ["@graph", "@index"]
}
},
"@id": "http://example.com/",
"@type": "schema:Blog",
"name": "World Financial News",
"post": {
"en": {
"@id": "http://example.com/posts/1/en",
"body": "World commodities were up today with heavy trading of crude oil...",
"words": 1539
},
"de": {
"@id": "http://example.com/posts/1/de",
"body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
"words": 1204
}
}
}
This
expands
to
the
following:
Example
76
91
:
Indexed
graph
data
after
expansion
[{
"@id": "http://example.com/",
"@type": ["http://schema.org/Blog"],
"http://schema.org/blogPost": [{
"@graph": [{
"@id": "http://example.com/posts/1/de",
"http://schema.org/articleBody": [{
"@value": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl..."
}],
"http://schema.org/wordCount": [{"@value": 1204}]
}],
"@index": "de"
}, {
"@graph": [{
"@id": "http://example.com/posts/1/en",
"http://schema.org/articleBody": [{
"@value": "World commodities were up today with heavy trading of crude oil..."
}],
"http://schema.org/wordCount": [{"@value": 1539}]
}],
"@index": "en"
}],
"http://schema.org/name": [{"@value": "World Financial News"}]
}]
When
expressed
as
Quads,
this
becomes
the
following:
|
Graph
|
Subject
|
Property
|
Value
|
Value
Type
|
|
|
http://example.com/
|
rdf:type
|
schema:Blog
|
|
|
|
http://example.com/
|
schema:name
|
World
Financial
News
|
|
|
|
http://example.com/
|
schema:blogPost
|
_:b1
|
|
|
|
http://example.com/
|
schema:blogPost
|
_:b2
|
|
|
_:b1
|
http://example.com/posts/1/de
|
schema:wordCount
|
1204
|
xsd:integer
|
|
_:b1
|
http://example.com/posts/1/de
|
schema:articleBody
|
Die
Werte
an
Warenbörsen
stiegen
im
Sog
eines
starken
Handels
von
Rohöl...
|
|
|
_:b2
|
http://example.com/posts/1/en
|
schema:wordCount
|
1539
|
xsd:integer
|
|
_:b2
|
http://example.com/posts/1/en
|
schema:articleBody
|
World
commodities
were
up
today
with
heavy
trading
of
crude
oil...
|
|
As
with
index
maps
,
when
used
with
@graph
,
a
container
may
also
include
@set
to
ensure
that
key
values
are
always
contained
in
an
array.
If
the
processing
mode
is
set
to
json-ld-1.1
,
the
special
index
@none
is
used
for
indexing
graphs
which
does
not
have
an
@index
key,
which
is
useful
to
maintain
a
normalized
representation.
Note,
however,
that
compacting
a
document
where
multiple
unidentified
named
graphs
are
compacted
using
the
@none
index
will
result
in
the
content
of
those
graphs
being
merged.
To
prevent
this,
give
each
graph
a
distinct
@index
key.
Example
77
92
:
Indexing
graphs
using
@none
for
no
index
{
"@context": {
"@version": 1.1,
"schema": "http://schema.org/",
"name": "schema:name",
"body": "schema:articleBody",
"words": "schema:wordCount",
"post": {
"@id": "schema:blogPost",
"@container": ["@graph", "@index"]
}
},
"@id": "http://example.com/",
"@type": "schema:Blog",
"name": "World Financial News",
"post": {
"en": {
"@id": "http://example.com/posts/1/en",
"body": "World commodities were up today with heavy trading of crude oil...",
"words": 1539
},
"@none": {
"@id": "http://example.com/posts/1/no-language",
"body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
"words": 1204
}
}
}
This
expands
to
the
following:
Example
78
93
:
Indexed
languaged-tagged
strings
with
@none
after
expansion
[{
"@id": "http://example.com/",
"@type": ["http://schema.org/Blog"],
"http://schema.org/blogPost": [{
"@graph": [{
"@id": "http://example.com/posts/1/no-language",
"http://schema.org/articleBody": [{
"@value": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl..."
}],
"http://schema.org/wordCount": [{"@value": 1204}]
}]
}, {
"@graph": [{
"@id": "http://example.com/posts/1/en",
"http://schema.org/articleBody": [{
"@value": "World commodities were up today with heavy trading of crude oil..."
}],
"http://schema.org/wordCount": [{"@value": 1539}]
}],
"@index": "en"
}],
"http://schema.org/name": [{"@value": "World Financial News"}]
}]
4.20
Language
Indexing
§
This
section
is
non-normative.
JSON
which
includes
string
values
in
multiple
languages
may
be
represented
using
a
language
map
to
allow
for
easily
indexing
property
values
by
language
tag
.
This
enables
direct
access
to
language
values
instead
of
having
to
scan
an
array
in
search
of
a
specific
item.
In
JSON-LD
such
data
can
be
specified
by
associating
the
@language
keyword
with
a
@container
declaration
in
the
context:
Example
79
:
Indexing
languaged-tagged
strings
in
JSON-LD
{
: {
,
: {
,
}
},
,
: {
,
]
}
}
In
the
example
above,
the
label
term
has
been
marked
as
an
language
map
.
The
en
and
de
keys
are
implicitly
associated
with
their
respective
values
by
the
JSON-LD
Processor
.
This
allows
a
developer
to
access
the
German
version
of
the
label
using
the
following
code
snippet:
obj.label.de
.
The
value
of
@container
can
also
be
an
array
containing
both
@language
and
@set
.
When
compacting
,
this
ensures
that
a
JSON-LD
Processor
will
use
the
array
form
for
all
values
of
language
tags.
Example
80
:
Indexing
languaged-tagged
strings
in
JSON-LD
with
@set
representation
{
"@context": {
"vocab": "http://example.com/vocab/",
"label": {
"@id": "vocab:label",
"@container":
}
},
"@id": "http://example.com/queen",
"label": {
"en": ,
"de": [ "Die Königin", "Ihre Majestät" ]
}
}
If
the
processing
mode
is
set
to
json-ld-1.1
,
the
special
index
@none
is
used
for
indexing
data
which
does
not
have
a
language,
which
is
useful
to
maintain
a
normalized
representation.
Example
81
:
Indexing
languaged-tagged
strings
using
@none
for
no
language
{
"@context": {
"vocab": "http://example.com/vocab/",
"label": {
"@id": "vocab:label",
"@container": "@language"
}
},
"@id": "http://example.com/queen",
"label": {
"en": "The Queen",
"de": [ "Die Königin", "Ihre Majestät" ],
"@none": "The Queen"
}
}
4.21
Node
Identifier
Indexing
§
This
section
is
non-normative.
In
addition
to
index
maps
,
JSON-LD
introduces
the
notion
of
id
maps
for
structuring
data.
The
id
indexing
feature
allows
an
author
to
structure
data
using
a
simple
key-value
map
where
the
keys
map
to
IRIs
.
This
enables
direct
access
to
associated
node
objects
instead
of
having
to
scan
an
array
in
search
of
a
specific
item.
In
JSON-LD
such
data
can
be
specified
by
associating
the
@id
keyword
with
a
@container
declaration
in
the
context:
Example
82
:
Indexing
data
in
JSON-LD
by
node
identifiers
{
"@context": {
,
"schema": "http://schema.org/",
"name": "schema:name",
"body": "schema:articleBody",
"words": "schema:wordCount",
"post": {
"@id": "schema:blogPost",
}
},
"@id": "http://example.com/",
"@type": "schema:Blog",
"name": "World Financial News",
"post": {
"http://example.com/posts/1/en": {
"body": "World commodities were up today with heavy trading of crude oil...",
"words": 1539
},
"http://example.com/posts/1/de": {
"body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
"words": 1204
}
}
}
In
the
example
above,
the
post
term
has
been
marked
as
an
id
map
.
The
http://example.com/posts/1/en
and
http://example.com/posts/1/de
keys
will
be
interpreted
as
the
@id
property
of
the
node
object
value.
The
interpretation
of
the
data
above
is
exactly
the
same
as
that
in
section
4.18
Data
Indexing
using
a
JSON-LD
processor
.
The
value
of
@container
can
also
be
an
array
containing
both
@id
and
@set
.
When
compacting
,
this
ensures
that
a
JSON-LD
processor
will
use
the
array
form
for
all
values
of
node
identifiers.
Example
83
:
Indexing
data
in
JSON-LD
by
node
identifiers
with
@set
representation
{
"@context": {
,
"schema": "http://schema.org/",
"name": "schema:name",
"body": "schema:articleBody",
"words": "schema:wordCount",
"post": {
"@id": "schema:blogPost",
"@container":
}
},
"@id": "http://example.com/",
"@type": "schema:Blog",
"name": "World Financial News",
"post": {
"http://example.com/posts/1/en": {
"body": "World commodities were up today with heavy trading of crude oil...",
"words": 1539
},
"http://example.com/posts/1/de": {
"body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
"words": 1204
}
}
}
The
special
index
@none
is
used
for
indexing
node
objects
which
do
not
have
an
@id
,
which
is
useful
to
maintain
a
normalized
representation.
The
@none
index
may
also
be
a
term
which
expands
to
@none
,
such
as
the
term
none
used
in
the
example
below.
Example
84
:
Indexing
data
in
JSON-LD
by
node
identifiers
using
@none
{
"@context": {
"@version": 1.1,
"schema": "http://schema.org/",
"name": "schema:name",
"body": "schema:articleBody",
"words": "schema:wordCount",
"post": {
"@id": "schema:blogPost",
"@container": "@id"
},
},
"@id": "http://example.com/",
"@type": "schema:Blog",
"name": "World Financial News",
"post": {
"http://example.com/posts/1/en": {
"body": "World commodities were up today with heavy trading of crude oil...",
"words": 1539
},
"http://example.com/posts/1/de": {
"body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
"words": 1204
},
"none": {
"body": "Description for object within an @id",
"words": 20
}
}
}
Note
Id
maps
are
a
new
feature
in
JSON-LD
1.1,
requiring
processing
mode
set
to
json-ld-1.1
.
4.22
4.8.3
Named
Graph
Indexing
by
Identifier
Indexing
§
In
addition
to
indexing
node
objects
by
identifier,
graph
objects
may
also
be
indexed
by
their
graph
name
.
By
using
the
@graph
container
type,
introduced
in
section
4.15.1
4.8.1
Graph
Containers
in
addition
to
@id
,
an
object
value
of
such
a
property
is
treated
as
a
key-value
map
where
the
keys
represent
the
identifiers
of
named
graphs
which
are
their
values.
The
following
example
describes
a
default
graph
referencing
multiple
named
graphs
using
an
id
map
.
Example
85
94
:
Referencing
named
graphs
using
an
id
map
{
"@context": {
"@version": 1.1,
"generatedAt": {
"@id": "http://www.w3.org/ns/prov#generatedAtTime",
"@type": "http://www.w3.org/2001/XMLSchema#date"
},
"Person": "http://xmlns.com/foaf/0.1/Person",
"name": "http://xmlns.com/foaf/0.1/name",
"knows": "http://xmlns.com/foaf/0.1/knows",
"graphMap": {
"@id": "http://example.org/graphMap",
"@container": ["@graph", "@id"]
}
},
"@id": "http://example.org/foaf-graph",
"generatedAt": "2012-04-09",
"graphMap": {
"http://manu.sporny.org/about#manu": {
"@id": "http://manu.sporny.org/about#manu",
"@type": "Person",
"name": "Manu Sporny",
"knows": "http://greggkellogg.net/foaf#me"
},
"http://greggkellogg.net/foaf#me": {
"@id": "http://greggkellogg.net/foaf#me",
"@type": "Person",
"name": "Gregg Kellogg",
"knows": "http://manu.sporny.org/about#manu"
}
}
}
This
expands
to
the
following:
Example
86
95
:
Referencing
named
graphs
after
expansion
[{
"@id": "http://example.org/foaf-graph",
"http://example.org/graphMap": [{
"@id": "http://greggkellogg.net/foaf#me",
"@graph": [{
"@id": "http://greggkellogg.net/foaf#me",
"@type": ["http://xmlns.com/foaf/0.1/Person"],
"http://xmlns.com/foaf/0.1/knows": [{"@value": "http://manu.sporny.org/about#manu"}],
"http://xmlns.com/foaf/0.1/name": [{"@value": "Gregg Kellogg"}]
}]
}, {
"@id": "http://manu.sporny.org/about#manu",
"@graph": [{
"@id": "http://manu.sporny.org/about#manu",
"@type": [
"http://xmlns.com/foaf/0.1/Person"
],
"http://xmlns.com/foaf/0.1/knows": [
{
"@value": "http://greggkellogg.net/foaf#me"
}
],
"http://xmlns.com/foaf/0.1/name": [
{
"@value": "Manu Sporny"
}
]
}]
}],
"http://www.w3.org/ns/prov#generatedAtTime": [{
"@value": "2012-04-09",
"@type": "http://www.w3.org/2001/XMLSchema#date"
}]
}]
When
expressed
as
Quads,
this
becomes
the
following:
|
Graph
|
Subject
|
Property
|
Value
|
Value
Type
|
|
|
http://example.org/foaf-graph
|
prov:generatedAtTime
|
2012-04-09
|
xsd:date
|
|
|
http://example.org/foaf-graph
|
http://example.org/graphMap
|
http://manu.sporny.org/about#manu
|
|
|
|
http://example.org/foaf-graph
|
http://example.org/graphMap
|
http://greggkellogg.net/foaf#me
|
|
|
http://manu.sporny.org/about#manu
|
http://manu.sporny.org/about#manu
|
xsd:type
|
foaf:Person
|
|
|
http://manu.sporny.org/about#manu
|
http://manu.sporny.org/about#manu
|
foaf:name
|
Manu
Sporny
|
|
|
http://manu.sporny.org/about#manu
|
http://manu.sporny.org/about#manu
|
foaf:knows
|
http://greggkellogg.net/foaf#me
|
|
|
http://greggkellogg.net/foaf#me
|
http://greggkellogg.net/foaf#me
|
xsd:type
|
foaf:Person
|
|
|
http://greggkellogg.net/foaf#me
|
http://greggkellogg.net/foaf#me
|
foaf:name
|
Gregg
Kellogg
|
|
|
http://greggkellogg.net/foaf#me
|
http://greggkellogg.net/foaf#me
|
foaf:knows
|
http://manu.sporny.org/about#manu
|
|
As
with
id
maps
,
when
used
with
@graph
,
a
container
may
also
include
@set
to
ensure
that
key
values
are
always
contained
in
an
array.
As
with
id
maps
,
the
special
index
@none
is
used
for
indexing
named
graphs
which
do
not
have
an
@id
,
which
is
useful
to
maintain
a
normalized
representation.
The
@none
index
may
also
be
a
term
which
expands
to
@none
.
Note,
however,
that
if
multiple
graphs
are
represented
without
an
@id
,
they
will
be
merged
on
expansion.
To
prevent
this,
use
@none
judiciously,
and
consider
giving
graphs
their
own
distinct
identifier.
Example
87
96
:
Referencing
named
graphs
using
an
id
map
with
@none
{
"@context": {
"@version": 1.1,
"generatedAt": {
"@id": "http://www.w3.org/ns/prov#generatedAtTime",
"@type": "http://www.w3.org/2001/XMLSchema#date"
},
"Person": "http://xmlns.com/foaf/0.1/Person",
"name": "http://xmlns.com/foaf/0.1/name",
"knows": "http://xmlns.com/foaf/0.1/knows",
"graphMap": {
"@id": "http://example.org/graphMap",
"@container": ["@graph", "@id"]
}
},
"@id": "http://example.org/foaf-graph",
"generatedAt": "2012-04-09",
"graphMap": {
"@none": [{
"@id": "http://manu.sporny.org/about#manu",
"@type": "Person",
"name": "Manu Sporny",
"knows": "http://greggkellogg.net/foaf#me"
}, {
"@id": "http://greggkellogg.net/foaf#me",
"@type": "Person",
"name": "Gregg Kellogg",
"knows": "http://manu.sporny.org/about#manu"
}]
}
}
Note
Graph
Containers
are
a
new
feature
in
JSON-LD
1.1,
requiring
processing
mode
set
to
json-ld-1.1
.
6.
Interpreting
JSON
as
JSON-LD
§
Ordinary
JSON
documents
can
be
interpreted
as
JSON-LD
by
providing
an
explicit
JSON-LD
context
document.
One
way
to
provide
this
is
by
using
referencing
a
JSON-LD
context
document
in
an
HTTP
Link
Header
.
Doing
so
allows
JSON
to
be
unambiguously
machine-readable
without
requiring
developers
to
drastically
change
their
documents
and
provides
an
upgrade
path
for
existing
infrastructure
without
breaking
existing
clients
that
rely
on
the
application/json
media
type
or
a
media
type
with
a
+json
suffix
as
defined
in
[
RFC6839
].
In
order
to
use
an
external
context
with
an
ordinary
JSON
document,
when
retrieving
an
ordinary
JSON
document
via
HTTP,
processors
MUST
retrieve
any
JSON-LD
document
referenced
by
a
Link
Header
with:
rel="http://www.w3.org/ns/json-ld#context"
,
and
type="application/ld+json"
.
The
referenced
document
MUST
have
a
top-level
JSON
object
.
The
@context
subtree
within
that
object
is
added
to
the
top-level
JSON
object
of
the
referencing
document.
If
an
array
is
at
the
top-level
of
the
referencing
document
and
its
items
are
JSON
objects
,
the
@context
subtree
is
added
to
all
array
items.
All
extra
information
located
outside
of
the
@context
subtree
in
the
referenced
document
MUST
be
discarded.
Effectively
this
means
that
the
active
context
is
initialized
with
the
referenced
external
context
.
A
response
MUST
NOT
contain
more
than
one
HTTP
Link
Header
[
RFC5988
]
using
the
http://www.w3.org/ns/json-ld#context
link
relation.
Other
mechanisms
for
providing
a
JSON-LD
Context
MAY
be
described
for
other
URI
schemes.
The
JSON-LD
1.1
Processing
Algorithms
and
API
specification
[
JSON-LD11-API
]
provides
for
an
expandContext
option
for
specifying
a
context
to
use
when
expanding
JSON
documents
programatically.
The
following
example
demonstrates
the
use
of
an
external
context
with
an
ordinary
JSON
document
over
HTTP:
Example
107
:
Referencing
a
JSON-LD
context
from
a
JSON
document
via
an
HTTP
Link
Header
GET /ordinary-json-document.json HTTP/1.1
Host: example.com
Accept: application/ld+json,application/json,*/*;q=0.1
====================================
HTTP/1.1 200 OK
Content-Type: application/json
Link: <https://json-ld.org/contexts/person.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
{
"name": "Markus Lanthaler",
"homepage": "http://www.markus-lanthaler.com/",
"image": "http://twitter.com/account/profile_image/markuslanthaler"
}
Please
note
that
JSON-LD
documents
served
with
the
application/ld+json
media
type
MUST
have
all
context
information,
including
references
to
external
contexts,
within
the
body
of
the
document.
Contexts
linked
via
a
http://www.w3.org/ns/json-ld#context
HTTP
Link
Header
MUST
be
ignored
for
such
documents.
6.
9.
JSON-LD
Grammar
§
This
appendix
restates
the
syntactic
conventions
described
in
the
previous
sections
more
formally.
A
JSON-LD
document
MUST
be
valid
JSON
text
as
described
in
[
RFC7159
],
or
some
format
that
can
be
represented
in
the
JSON-LD
internal
representation
that
is
equivalent
to
valid
JSON
text
.
A
JSON-LD
document
MUST
be
a
single
node
object
,
a
JSON
object
consisting
of
only
the
members
@context
and/or
@graph
,
or
an
array
or
zero
or
more
node
objects
.
In
contrast
to
JSON,
in
JSON-LD
the
keys
in
objects
MUST
be
unique.
Note
JSON-LD
allows
keywords
to
be
aliased
(see
section
4.17
4.1.5
Aliasing
Keywords
for
details).
Whenever
a
keyword
is
discussed
in
this
grammar,
the
statements
also
apply
to
an
alias
for
that
keyword
.
For
example,
if
the
active
context
defines
the
term
id
as
an
alias
for
@id
,
that
alias
may
be
legitimately
used
as
a
substitution
for
@id
.
Note
that
keyword
aliases
are
not
expanded
during
context
processing.
6.2
9.2
Node
Objects
§
A
node
object
represents
zero
or
more
properties
of
a
node
in
the
graph
serialized
by
the
JSON-LD
document
.
A
JSON
object
is
a
node
object
if
it
exists
outside
of
a
JSON-LD
context
and:
-
it
is
not
the
top-most
JSON
object
in
the
JSON-LD
document
consisting
of
no
other
members
than
@graph
and
@context
,
-
it
does
not
contain
the
@value
,
@list
,
or
@set
keywords,
and
-
it
is
not
a
graph
object
.
The
properties
of
a
node
in
a
graph
may
be
spread
among
different
node
objects
within
a
document.
When
that
happens,
the
keys
of
the
different
node
objects
need
to
be
merged
to
create
the
properties
of
the
resulting
node
.
A
node
object
MUST
be
a
JSON
object
.
All
keys
which
are
not
IRIs
,
compact
IRIs
,
terms
valid
in
the
active
context
,
or
one
of
the
following
keywords
(or
alias
of
such
a
keyword)
MUST
be
ignored
when
processed:
-
@context
,
-
@id
,
-
@graph
,
-
@nest
,
-
@type
,
-
@reverse
,
or
-
@index
If
the
node
object
contains
the
@context
key,
its
value
MUST
be
null
,
an
absolute
IRI
,
a
relative
IRI
,
a
context
definition
,
or
an
array
composed
of
any
of
these.
If
the
node
object
contains
the
@id
key,
its
value
MUST
be
an
absolute
IRI
,
a
relative
IRI
,
or
a
compact
IRI
(including
blank
node
identifiers
).
See
section
3.3
Node
Identifiers
,
section
4.4
4.1.4
Compact
IRIs
,
and
section
4.16
4.5.1
Identifying
Blank
Nodes
for
further
discussion
on
@id
values.
If
the
node
object
contains
the
@graph
key,
its
value
MUST
be
a
node
object
or
an
array
of
zero
or
more
node
objects
.
If
the
node
object
contains
an
@id
keyword,
its
value
is
used
as
the
graph
name
of
a
named
graph
.
See
section
4.15
4.8
Named
Graphs
for
further
discussion
on
@graph
values.
As
a
special
case,
if
a
JSON
object
contains
no
keys
other
than
@graph
and
@context
,
and
the
JSON
object
is
the
root
of
the
JSON-LD
document,
the
JSON
object
is
not
treated
as
a
node
object
;
this
is
used
as
a
way
of
defining
node
objects
that
may
not
form
a
connected
graph.
This
allows
a
context
to
be
defined
which
is
shared
by
all
of
the
constituent
node
objects
.
If
the
node
object
contains
the
@type
key,
its
value
MUST
be
either
an
absolute
IRI
,
a
relative
IRI
,
a
compact
IRI
(including
blank
node
identifiers
),
a
term
defined
in
the
active
context
expanding
into
an
absolute
IRI
,
or
an
array
of
any
of
these.
See
section
3.4
Specifying
the
Type
for
further
discussion
on
@type
values.
If
the
node
object
contains
the
@reverse
key,
its
value
MUST
be
a
JSON
object
containing
members
representing
reverse
properties.
Each
value
of
such
a
reverse
property
MUST
be
an
absolute
IRI
,
a
relative
IRI
,
a
compact
IRI
,
a
blank
node
identifier
,
a
node
object
or
an
array
containing
a
combination
of
these.
If
the
node
object
contains
the
@index
key,
its
value
MUST
be
a
string
.
See
section
4.18
4.6.1
Data
Indexing
for
further
discussion
on
@index
values.
If
the
node
object
contains
the
@nest
key,
its
value
MUST
be
an
JSON
object
or
an
array
of
JSON
objects
which
MUST
NOT
include
a
value
object
.
See
section
6.10
9.10
Property
Nesting
for
further
discussion
on
@nest
values.
Keys
in
a
node
object
that
are
not
keywords
MAY
expand
to
an
absolute
IRI
using
the
active
context
.
The
values
associated
with
keys
that
expand
to
an
absolute
IRI
MUST
be
one
of
the
following:
-
string
,
-
number
,
-
true
,
-
false
,
-
null
,
-
node
object
,
-
graph
object
,
-
value
object
,
-
list
object
,
-
set
object
,
-
an
array
of
zero
or
more
of
any
of
the
possibilities
above,
-
a
language
map
,
-
an
index
map
,
-
an
id
map
,
or
-
an
type
map
6.3
9.3
Graph
Objects
§
A
graph
object
represents
a
named
graph
,
which
MAY
include
include
an
explicit
graph
name
.
A
JSON
object
is
a
graph
object
if
it
exists
outside
of
a
JSON-LD
context
,
it
is
not
a
node
object
,
it
is
not
the
top-most
JSON
object
in
the
JSON-LD
document,
and
it
consists
of
no
members
other
than
@graph
,
@index
,
@id
and
@context
,
or
an
alias
of
one
of
these
keywords
.
If
the
graph
object
contains
the
@context
key,
its
value
MUST
be
null
,
an
absolute
IRI
,
a
relative
IRI
,
a
context
definition
,
or
an
array
composed
of
any
of
these.
If
the
graph
object
contains
the
@id
key,
its
value
is
used
as
the
identifier
(
graph
name
)
of
a
named
graph
,
and
MUST
be
an
absolute
IRI
,
a
relative
IRI
,
or
a
compact
IRI
(including
blank
node
identifiers
).
See
section
3.3
Node
Identifiers
,
section
4.4
4.1.4
Compact
IRIs
,
and
section
4.16
4.5.1
Identifying
Blank
Nodes
for
further
discussion
on
@id
values.
A
graph
object
without
an
@id
member
is
also
a
simple
graph
object
and
represents
a
named
graph
without
an
explicit
identifier,
although
in
the
data
model
it
still
has
a
graph
name
,
which
is
an
implicitly
allocated
blank
node
identifier
.
The
value
of
the
@graph
key
MUST
be
a
node
object
or
an
array
of
zero
or
more
node
objects
.
See
section
4.15
4.8
Named
Graphs
for
further
discussion
on
@graph
values..
6.4
9.4
Value
Objects
§
A
value
object
is
used
to
explicitly
associate
a
type
or
a
language
with
a
value
to
create
a
typed
value
or
a
language-tagged
string
.
A
value
object
MUST
be
a
JSON
object
containing
the
@value
key.
It
MAY
also
contain
an
@type
,
an
@language
,
an
@index
,
or
an
@context
key
but
MUST
NOT
contain
both
an
@type
and
an
@language
key
at
the
same
time.
A
value
object
MUST
NOT
contain
any
other
keys
that
expand
to
an
absolute
IRI
or
keyword
.
The
value
associated
with
the
@value
key
MUST
be
either
a
string
,
a
number
,
true
,
false
or
null
.
The
value
associated
with
the
@type
key
MUST
be
a
term
,
a
compact
IRI
,
an
absolute
IRI
,
a
string
which
can
be
turned
into
an
absolute
IRI
using
the
vocabulary
mapping
,
or
null
.
The
value
associated
with
the
@language
key
MUST
have
the
lexical
form
described
in
[
BCP47
],
or
be
null
.
The
value
associated
with
the
@index
key
MUST
be
a
string
.
See
section
4.5
4.2.1
Typed
Values
and
section
4.10
4.2.3
String
Internationalization
for
more
information
on
value
objects
.
6.5
9.5
Lists
and
Sets
§
A
list
represents
an
ordered
set
of
values.
A
set
represents
an
unordered
set
of
values.
Unless
otherwise
specified,
arrays
are
unordered
in
JSON-LD.
As
such,
the
@set
keyword,
when
used
in
the
body
of
a
JSON-LD
document,
represents
just
syntactic
sugar
which
is
optimized
away
when
processing
the
document.
However,
it
is
very
helpful
when
used
within
the
context
of
a
document.
Values
of
terms
associated
with
an
@set
or
@list
container
will
always
be
represented
in
the
form
of
an
array
when
a
document
is
processed—even
if
there
is
just
a
single
value
that
would
otherwise
be
optimized
to
a
non-array
form
in
compact
document
form
.
This
simplifies
post-processing
of
the
data
as
the
data
is
always
in
a
deterministic
form.
A
list
object
MUST
be
a
JSON
object
that
contains
no
keys
that
expand
to
an
absolute
IRI
or
keyword
other
than
@list
,
@context
,
and
@index
.
A
set
object
MUST
be
a
JSON
object
that
contains
no
keys
that
expand
to
an
absolute
IRI
or
keyword
other
than
@set
,
@context
,
and
@index
.
Please
note
that
the
@index
key
will
be
ignored
when
being
processed.
In
both
cases,
the
value
associated
with
the
keys
@list
and
@set
MUST
be
one
of
the
following
types:
See
section
4.12
4.3
Sets
and
Lists
Value
Ordering
for
further
discussion
on
sets
and
lists.
6.7
9.7
Index
Maps
§
An
index
map
allows
keys
that
have
no
semantic
meaning,
but
should
be
preserved
regardless,
to
be
used
in
JSON-LD
documents.
An
index
map
may
be
used
as
a
term
value
within
a
node
object
if
the
term
is
defined
with
@container
set
to
@index
,
or
an
array
containing
both
@index
and
@set
.
The
values
of
the
members
of
an
index
map
MUST
be
one
of
the
following
types:
See
section
4.18
4.6.1
Data
Indexing
for
further
information
on
this
topic.
Index
Maps
may
also
be
used
to
map
indexes
to
associated
named
graphs
,
if
the
term
is
defined
with
@container
set
to
an
array
containing
both
@graph
and
@index
,
and
optionally
including
@set
.
The
value
consists
of
the
node
objects
contained
within
the
named
graph
which
is
named
using
the
referencing
key,
which
can
be
represented
as
a
simple
graph
object
.
6.8
9.8
Id
Maps
§
An
id
map
is
used
to
associate
an
IRI
with
a
value
that
allows
easy
programmatic
access.
An
id
map
may
be
used
as
a
term
value
within
a
node
object
if
the
term
is
defined
with
@container
set
to
@id
,
or
an
array
containing
both
@id
and
@set
.
The
keys
of
an
id
map
MUST
be
IRIs
(
relative
IRI
,
compact
IRI
(including
blank
node
identifiers
),
or
absolute
IRI
),
the
keyword
@none
,
or
a
term
which
expands
to
@none
,
and
the
values
MUST
be
node
objects
.
If
the
value
contains
a
property
expanding
to
@id
,
it's
value
MUST
be
equivalent
to
the
referencing
key.
Otherwise,
the
property
from
the
value
is
used
as
the
@id
of
the
node
object
value
when
expanding.
Id
Maps
may
also
be
used
to
map
graph
names
to
their
named
graphs
,
if
the
term
is
defined
with
@container
set
to
an
array
containing
both
@graph
and
@id
,
and
optionally
including
@set
.
The
value
consists
of
the
node
objects
contained
within
the
named
graph
which
is
named
using
the
referencing
key.
6.9
9.9
Type
Maps
§
A
type
map
is
used
to
associate
an
IRI
with
a
value
that
allows
easy
programmatic
access.
A
type
map
may
be
used
as
a
term
value
within
a
node
object
if
the
term
is
defined
with
@container
set
to
@type
,
or
an
array
containing
both
@type
and
@set
.
The
keys
of
a
type
map
MUST
be
IRIs
(
relative
IRI
,
compact
IRI
(including
blank
node
identifiers
),
or
absolute
IRI
),
the
keyword
@none
,
or
a
term
which
expands
to
@none
,
and
the
values
MUST
be
node
objects
.
If
the
value
contains
a
property
expanding
to
@type
,
and
it's
value
is
contains
the
referencing
key
after
suitable
expansion
of
both
the
referencing
key
and
the
value,
then
the
node
object
already
contains
the
type.
Otherwise,
the
property
from
the
value
is
added
as
a
@type
of
the
node
object
value
when
expanding.
6.11
9.11
Context
Definitions
§
A
context
definition
defines
a
local
context
in
a
node
object
.
A
context
definition
MUST
be
a
JSON
object
whose
keys
MUST
be
either
terms
,
compact
IRIs
,
absolute
IRIs
,
or
one
of
the
keywords
@language
,
@base
,
@vocab
,
or
@version
.
If
the
context
definition
has
an
@language
key,
its
value
MUST
have
the
lexical
form
described
in
[
BCP47
]
or
be
null
.
If
the
context
definition
has
an
@base
key,
its
value
MUST
be
an
absolute
IRI
,
a
relative
IRI
,
or
null
.
If
the
context
definition
has
an
@vocab
key,
its
value
MUST
be
a
absolute
IRI
,
a
compact
IRI
,
a
blank
node
identifier
,
an
empty
string
(
""
)
,
a
term
,
or
null
.
If
the
context
definition
has
an
@version
key,
its
value
MUST
be
a
number
with
the
value
1.1
.
The
value
of
keys
that
are
not
keywords
MUST
be
either
an
absolute
IRI
,
a
compact
IRI
,
a
term
,
a
blank
node
identifier
,
a
keyword
,
null
,
or
an
expanded
term
definition
.
An
expanded
term
definition
is
used
to
describe
the
mapping
between
a
term
and
its
expanded
identifier,
as
well
as
other
properties
of
the
value
associated
with
the
term
when
it
is
used
as
key
in
a
node
object
.
An
expanded
term
definition
MUST
be
a
JSON
object
composed
of
zero
or
more
keys
from
@id
,
@reverse
,
@type
,
@language
,
@context
,
@prefix
,
or
@container
.
An
expanded
term
definition
SHOULD
NOT
contain
any
other
keys.
If
the
term
being
defined
is
not
a
compact
IRI
or
absolute
IRI
and
the
active
context
does
not
have
an
@vocab
mapping,
the
expanded
term
definition
MUST
include
the
@id
key.
If
the
expanded
term
definition
contains
the
@id
keyword
,
its
value
MUST
be
null
,
an
absolute
IRI
,
a
blank
node
identifier
,
a
compact
IRI
,
a
term
,
or
a
keyword
.
If
an
expanded
term
definition
has
an
@reverse
member,
it
MUST
NOT
have
@id
or
@nest
members
at
the
same
time,
its
value
MUST
be
an
absolute
IRI
,
a
blank
node
identifier
,
a
compact
IRI
,
or
a
term
.
If
an
@container
member
exists,
its
value
MUST
be
null
,
@set
,
or
@index
.
If
the
expanded
term
definition
contains
the
@type
keyword
,
its
value
MUST
be
an
absolute
IRI
,
a
compact
IRI
,
a
term
,
null
,
or
one
of
the
keywords
@id
or
@vocab
.
If
the
expanded
term
definition
contains
the
@language
keyword
,
its
value
MUST
have
the
lexical
form
described
in
[
BCP47
]
or
be
null
.
If
the
expanded
term
definition
contains
the
@container
keyword
,
its
value
MUST
be
either
@list
,
@set
,
@language
,
@index
,
@id
,
@graph
,
@type
,
or
be
null
or
an
array
containing
exactly
any
one
of
those
keywords,
or
a
combination
of
@set
and
any
of
@index
,
@id
,
@graph
,
@type
,
@language
in
any
order
.
@container
may
also
be
an
array
containing
@graph
along
with
either
@id
or
@index
and
also
optionally
including
@set
.
If
the
value
is
@language
,
when
the
term
is
used
outside
of
the
@context
,
the
associated
value
MUST
be
a
language
map
.
If
the
value
is
@index
,
when
the
term
is
used
outside
of
the
@context
,
the
associated
value
MUST
be
an
index
map
.
If
an
expanded
term
definition
has
an
@context
member,
it
MUST
be
a
valid
context
definition
.
If
the
expanded
term
definition
contains
the
@nest
keyword
,
its
value
MUST
be
either
@nest
,
or
a
term
which
expands
to
@nest
.
If
the
expanded
term
definition
contains
the
@prefix
keyword
,
its
value
MUST
be
true
or
false
.
Terms
MUST
NOT
be
used
in
a
circular
manner.
That
is,
the
definition
of
a
term
cannot
depend
on
the
definition
of
another
term
if
that
other
term
also
depends
on
the
first
term.
See
section
3.1
The
Context
for
further
discussion
on
contexts.
7.
10.
Relationship
to
RDF
§
JSON-LD
is
a
concrete
RDF
syntax
as
described
in
[
RDF11-CONCEPTS
].
Hence,
a
JSON-LD
document
is
both
an
RDF
document
and
a
JSON
document
and
correspondingly
represents
an
instance
of
an
RDF
data
model.
model
.
However,
JSON-LD
also
extends
the
RDF
data
model
to
optionally
allow
JSON-LD
to
serialize
generalized
RDF
Datasets
.
The
JSON-LD
extensions
to
the
RDF
data
model
are:
-
In
JSON-LD
properties
can
be
IRIs
or
blank
nodes
whereas
in
RDF
properties
(predicates)
have
to
be
IRIs
.
This
means
that
JSON-LD
serializes
generalized
RDF
Datasets
.
-
In
JSON-LD
lists
are
part
of
the
data
model
whereas
use
native
JSON
syntax,
either
contained
in
RDF
they
are
part
of
a
vocabulary,
namely
list
object,
or
described
as
such
within
a
context.
Consequently,
developers
using
the
JSON
representation
can
access
list
elements
directly
rather
than
using
the
vocabulary
for
collections
described
in
[
RDF-SCHEMA
].
]..
-
RDF
values
are
either
typed
literals
(
typed
values
)
or
language-tagged
strings
whereas
JSON-LD
also
supports
JSON's
native
data
types,
i.e.,
number
,
strings
,
and
the
boolean
values
true
and
false
.
The
JSON-LD
1.1
Processing
Algorithms
and
API
specification
[
JSON-LD11-API
]
defines
the
conversion
rules
between
JSON's
native
data
types
and
RDF's
counterparts
to
allow
round-tripping.
Summarized,
these
differences
mean
that
JSON-LD
is
capable
of
serializing
any
RDF
graph
or
dataset
and
most,
but
not
all,
JSON-LD
documents
can
be
directly
interpreted
as
RDF
as
described
in
RDF
1.1
Concepts
[
RDF11-CONCEPTS
].
For
authors
and
developers
working
with
blank
nodes
as
properties
when
deserializing
to
RDF,
three
potential
approaches
are
suggested:
The
normative
algorithms
for
interpreting
JSON-LD
as
RDF
and
serializing
RDF
as
JSON-LD
are
specified
in
the
JSON-LD
1.1
Processing
Algorithms
and
API
specification
[
JSON-LD11-API
].
Even
though
JSON-LD
serializes
generalized
RDF
Datasets
,
it
can
also
be
used
as
a
RDF
graph
source
.
In
that
case,
a
consumer
MUST
only
use
the
default
graph
and
ignore
all
named
graphs
.
This
allows
servers
to
expose
data
in
languages
such
as
Turtle
and
JSON-LD
using
content
negotiation.
Note
Publishers
supporting
both
dataset
and
graph
syntaxes
have
to
ensure
that
the
primary
data
is
stored
in
the
default
graph
to
enable
consumers
that
do
not
support
datasets
to
process
the
information.
