Abstract

JSON
[
RFC4627
]
has
proven
to
be
a
highly
useful
object
serialization
and
messaging
format.
In
an
attempt
to
harmonize
the
representation
of
Linked
Data
in
JSON,
this
specification
outlines
a
common
JSON
representation
format
for
expressing
directed
graphs;
mixing
both
Linked
Data
and
non-Linked
Data
in
a
single
document.

Status
of
This
Document

This
document
is
merely
a
public
working
draft
of
a
potential
specification.
It
has
no
official
standing
of
any
kind
and
does
not
represent
the
support
or
consensus
of
any
standards
organisation.

1.
Introduction

JSON,
as
specified
in
[
RFC4627
],
is
a
simple
language
for
representing
data
on
the
Web.
Linked
Data
is
a
technique
for
creating
a
graph
of
interlinked
data
across
different
documents
or
Web
sites.
Data
entities
are
described
using
IRI
s,
which
are
typically
dereferencable
and
thus
may
be
used
to
find
more
information
about
an
entity,
creating
a
"Web
"Web
of
Knowledge".
Knowledge".
JSON-LD
is
intended
to
be
a
simple
publishing
method
for
expressing
not
only
Linked
Data
in
JSON,
but
also
for
adding
semantics
to
existing
JSON.

JSON-LD
is
designed
as
a
light-weight
syntax
that
can
be
used
to
express
Linked
Data.
It
is
primarily
intended
to
be
a
way
to
use
Linked
Data
in
Javascript
and
other
Web-based
programming
environments.
It
is
also
useful
when
building
interoperable
Web
services
and
when
storing
Linked
Data
in
JSON-based
document
storage
engines.
It
is
practical
and
designed
to
be
as
simple
as
possible,
utilizing
the
large
number
of
JSON
parsers
and
libraries
available
today.
It
is
designed
to
be
able
to
express
key-value
pairs,
RDF
data,
RDFa
[
RDFA-CORE
]
data,
Microformats
[
MICROFORMATS
]
data,
and
Microdata
[
MICRODATA
].
That
is,
it
supports
every
major
Web-based
structured
data
model
in
use
today.

The
syntax
does
not
necessarily
require
applications
to
change
their
JSON,
but
allows
to
easily
add
meaning
by
adding
context
in
a
way
that
is
either
in-band
or
out-of-band.
The
syntax
is
designed
to
not
disturb
already
deployed
systems
running
on
JSON,
but
provide
a
smooth
upgrade
path
from
JSON
to
JSON
with
added
semantics.
Finally,
the
format
is
intended
to
be
easy
to
parse,
efficient
to
generate,
convertible
to
RDF
in
one
pass,
stream-based
and
document-based
processing
compatible,
and
require
a
very
small
memory
footprint
in
order
to
operate.

1.1
How
to
Read
this
Document

This
document
is
a
detailed
specification
for
a
serialization
of
Linked
Data
in
JSON.
The
document
is
primarily
intended
for
the
following
audiences:

Web
developers
that
want
to
understand
the
design
decisions
and
language
syntax
for
JSON-LD.

Software
developers
that
want
to
encode
Microformats,
RDFa,
or
Microdata
in
a
way
that
is
cross-language
compatible
via
JSON.

Software
developers
that
want
to
implement
processors
and
APIs
for
JSON-LD.

To
understand
the
basics
in
this
specification
you
must
first
be
familiar
with
JSON,
which
is
detailed
in
[
RFC4627
].
To
understand
the
API
and
how
it
is
intended
to
operate
in
a
programming
environment,
it
is
useful
to
have
working
knowledge
of
the
JavaScript
programming
language
[
ECMA-262
]
and
WebIDL
[
WEBIDL
].
To
understand
how
JSON-LD
maps
to
RDF,
it
is
helpful
to
be
familiar
with
the
basic
RDF
concepts
[
RDF-CONCEPTS
].

Examples
may
contain
references
to
existing
vocabularies
and
use
prefix
es
to
refer
to
Web
Vocabularies.
The
following
is
a
list
of
all
vocabularies
and
their
prefix
abbreviations,
as
used
in
this
document:

JSON
[
RFC4627
]
defines
several
terms
which
are
used
throughout
this
document:

JSON
Object

An
object
structure
is
represented
as
a
pair
of
curly
brackets
surrounding
zero
or
more
name/value
pairs
(or
members).
A
name
is
a
string
.
A
single
colon
comes
after
each
name,
separating
the
name
from
the
value.
A
single
comma
separates
a
value
from
a
following
name.
The
names
within
an
object
should
be
unique.

array

An
array
is
an
ordered
collection
of
values.
An
array
structure
is
represented
as
square
brackets
surrounding
zero
or
more
values
(or
elements).
Elements
are
separated
by
commas.
Within
JSON-LD,
array
order
is
not
preserved
by
default,
unless
specific
markup
is
provided
(see
Lists
).
This
is
because
the
basic
data
model
of
JSON-LD
is
a
directed
graph
,
which
is
inherently
unordered.

string

A
string
is
a
sequence
of
zero
or
more
Unicode
characters,
wrapped
in
double
quotes,
using
backslash
escapes.
A
character
is
represented
as
a
single
character
string.

number

A
number
is
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.

true
and
false

Boolean
values.

null

The
use
of
the
null
value
is
undefined
within
JSON-LD.

Supporting
null
in
JSON-LD
might
have
a
number
of
advantages
and
should
be
evaluated.
This
is
currently
an
open
issue
.

1.2
Contributing

There
are
a
number
of
ways
that
one
may
participate
in
the
development
of
this
specification:

The
#json-ld
IRC
channel
is
available
for
real-time
discussion
on
irc.freenode.net.

2.
Design

The
following
section
outlines
the
design
goals
and
rationale
behind
the
JSON-LD
markup
language.

2.1
Goals
and
Rationale

A
number
of
design
considerations
were
explored
during
the
creation
of
this
markup
language:

Simplicity

Developers
need
only
know
JSON
and
three
keywords
to
use
the
basic
functionality
in
JSON-LD.
No
extra
processors
or
software
libraries
are
necessary
to
use
JSON-LD
in
its
most
basic
form.
The
language
attempts
to
ensure
that
developers
have
an
easy
learning
curve.

Compatibility

The
JSON-LD
markup
must
be
100%
compatible
with
JSON.
This
ensures
that
all
of
the
standard
JSON
libraries
work
seamlessly
with
JSON-LD
documents.

Expressiveness

The
syntax
must
be
able
to
express
directed
graphs,
which
have
been
proven
to
be
able
to
simply
express
almost
every
real
world
data
model.

Terseness

The
JSON-LD
syntax
must
be
very
terse
and
human
readable,
requiring
as
little
as
possible
effort
from
the
developer.

Zero
Edits,
most
of
the
time

JSON-LD
provides
a
mechanism
that
allows
developers
to
specify
context
in
a
way
that
is
out-of-band.
This
allows
organizations
that
have
already
deployed
large
JSON-based
infrastructure
to
add
meaning
to
their
JSON
documents
in
a
way
that
is
not
disruptive
to
their
day-to-day
operations
and
is
transparent
to
their
current
customers.
At
times,
mapping
JSON
to
a
graph
representation
can
become
difficult.
In
these
instances,
rather
than
having
JSON-LD
support
esoteric
markup,
we
chose
not
to
support
the
use
case
and
support
a
simplified
syntax
instead.
So,
while
Zero
Edits
is
a
goal,
it
is
not
always
possible
without
adding
great
complexity
to
the
language.

One-pass
Processing
Streaming

JSON-LD
The
format
supports
one-pass
processing,
which
results
in
a
very
small
memory
footprint
when
processing
documents.
For
example,
to
convert
a
JSON-LD
document
into
an
RDF
document
of
any
kind,
only
one
pass
is
required
over
the
data.
both
document-based
and
stream-based
processing.

2.2
Linked
Data

The
following
definition
for
Linked
Data
is
the
one
that
will
be
used
for
this
specification.

Linked
Data
is
a
set
of
documents,
each
containing
a
representation
of
a
linked
data
graph.

A
linked
data
graph
is
an
unordered
labeled
directed
graph,
where
nodes
are
subject
s
or
object
s,
and
edges
are
properties.

Note
that
the
definition
for
Linked
Data
above
is
silent
on
the
topic
of
unlabeled
nodes.
Unlabeled
nodes
are
not
considered
Linked
Data
.
However,
this
specification
allows
for
the
expression
of
unlabled
nodes,
as
most
graph-based
data
sets
on
the
Web
contain
a
number
of
associated
nodes
that
are
not
named
and
thus
are
not
directly
de-referenceable.

JSON-LD
defines
a
mechanism
to
map
JSON
terms,
i.e.,
keys
and
values,
to
IRIs.
This
does
not
mean
that
JSON-LD
requires
every
key
or
value
to
be
an
IRI,
but
rather
ensures
that
keys
and
values
can
be
mapped
to
IRIs
if
the
developer
desires
to
transform
their
data
into
Linked
Data.
There
are
a
few
techniques
that
can
ensure
that
developers
will
generate
good
Linked
Data
for
the
Web.
JSON-LD
formalizes
those
techniques.

We
will
be
using
the
following
JSON
markup
as
the
example
for
the
rest
of
this
section:

2.4
The
Context

In
JSON-LD,
a
context
is
used
to
map
term
s,
i.e.,
keys
and
values
in
an
JSON
document,
to
IRI
s.
A
term
is
a
short
word
that
may
be
expanded
to
an
IRI
.
The
Web
uses
IRIs
for
unambiguous
identification.
The
idea
is
that
these
term
s
mean
something
that
may
be
of
use
to
other
developers
and
that
it
is
useful
to
give
them
an
unambiguous
identifier.
That
is,
it
is
useful
for
term
s
to
expand
to
IRIs
so
that
developers
don't
accidentally
step
on
each
other's
Web
Vocabulary
terms.
For
example,
the
term
name
may
map
directly
to
the
IRI
http://xmlns.com/foaf/0.1/name
.
This
allows
JSON-LD
documents
to
be
constructed
using
the
common
JSON
practice
of
simple
name/value
pairs
while
ensuring
that
the
data
is
useful
outside
of
the
page,
API
or
database
in
which
it
resides.

These
Linked
Data
term
s
are
typically
collected
in
a
context
document
that
would
look
something
like
this:

The
additions
addition
above
transform
transforms
the
previous
JSON
document
into
a
JSON
document
with
added
semantics
because
the
@context
specifies
how
the
name
,
homepage
,
and
avatar
terms
map
to
IRIs.
Mapping
those
keys
to
IRIs
gives
the
data
global
context.
If
two
developers
use
the
same
IRI
to
describe
a
property,
they
are
more
than
likely
expressing
the
same
concept.
This
allows
both
developers
to
re-use
each
others
data
without
having
to
agree
to
how
their
data
will
inter-operate
on
a
site-by-site
basis.
Contexts
may
also
contain
datatype
information
for
certain
term
s
as
well
as
other
processing
instructions
for
the
JSON-LD
processor.

Contexts
may
be
specified
in-line.
This
ensures
that
JSON-LD
documents
can
be
processed
when
a
JSON-LD
processor
does
not
have
access
to
the
Web.

JSON-LD
strives
to
ensure
that
developers
don't
have
to
change
the
JSON
that
is
going
into
and
being
returned
from
their
Web
APIs.
This
means
that
developers
can
also
specify
a
context
for
JSON
data
in
an
out-of-band
fashion.
This
is
described
later
in
this
document.

JSON-LD
uses
a
special
type
of
machine-readable
document
called
a
Web
Vocabulary
to
define
term
s
that
are
then
used
to
describe
concepts
and
"things"
"things"
in
the
world.
Typically,
these
Web
Vocabulary
documents
have
prefix
es
associated
with
them
and
contain
a
number
of
term
declarations.
A
prefix
,
like
a
term
,
is
a
short
word
that
expands
to
a
Web
Vocabulary
base
IRI.
Prefix
es
are
helpful
when
a
developer
wants
to
mix
multiple
vocabularies
together
in
a
context,
but
does
not
want
to
go
to
the
trouble
of
defining
every
single
term
in
every
single
vocabulary.
Some
Web
Vocabularies
may
have
dozens
of
terms
defined.
If
a
developer
wants
to
use
3-4
different
vocabularies,
the
number
of
terms
that
would
have
to
be
declared
in
a
single
context
could
become
quite
large.
To
reduce
the
number
of
different
terms
that
must
be
defined,
JSON-LD
also
allows
prefixes
to
be
used
to
compact
IRIs.

For
example,
the
IRI
http://xmlns.com/foaf/0.1/
specifies
a
Web
Vocabulary
which
may
be
represented
using
the
foaf
prefix
.
The
foaf
Web
Vocabulary
contains
a
term
called
name
.
If
you
join
the
foaf
prefix
with
the
name
suffix,
you
can
build
a
compact
IRI
that
will
expand
out
into
an
absolute
IRI
for
the
http://xmlns.com/foaf/0.1/name
vocabulary
term.
That
is,
the
compact
IRI,
or
short-form,
is
foaf:name
and
the
expanded-form
is
http://xmlns.com/foaf/0.1/name
.
This
vocabulary
term
is
used
to
specify
a
person's
name.

Developers,
and
machines,
are
able
to
use
this
IRI
(plugging
it
directly
into
a
web
browser,
for
instance)
to
go
to
the
term
and
get
a
definition
of
what
the
term
means.
Much
like
we
can
use
WordNet
today
to
see
the
definition
of
words
in
the
English
language.
Developers
and
machines
need
the
same
sort
of
definition
of
terms.
IRIs
provide
a
way
to
ensure
that
these
terms
are
unambiguous.

The
context
provides
a
collection
of
vocabulary
term
s
and
prefix
es
that
can
be
used
to
expand
JSON
keys
and
values
into
IRI
s.

To
ensure
the
best
possible
performance,
it
is
a
best
practice
to
put
the
context
definition
at
the
top
of
the
JSON-LD
document.
If
it
isn't
listed
first,
processors
have
to
save
each
key-value
pair
until
the
context
is
processed.
This
creates
a
memory
and
complexity
burden
for
one-pass
processors.

2.5
From
JSON
to
JSON-LD

If
a
set
of
terms
such
as,
name
,
homepage
,
and
avatar
,
are
defined
in
a
context,
and
that
context
is
used
to
resolve
the
names
in
JSON
objects,
machines
are
able
to
automatically
expand
the
terms
to
something
meaningful
and
unambiguous,
like
this:

Doing
this
allows
JSON
to
be
unambiguously
machine-readable
without
requiring
developers
to
drastically
change
their
workflow.

Please
note
that
this
JSON-LD
document
doesn't
define
the
subject
and
will
thus
result
in
an
unlabeled
or
blank
node.

3.
Basic
Concepts

JSON-LD
is
designed
to
ensure
that
Linked
Data
concepts
can
be
marked
up
in
a
way
that
is
simple
to
understand
and
author
by
Web
developers.
In
many
cases,
regular
JSON
markup
can
become
Linked
Data
with
the
simple
addition
of
a
context.
As
more
JSON-LD
features
are
used,
more
semantics
are
added
to
the
JSON
markup.

3.1
IRIs

Expressing
IRIs
are
fundamental
to
Linked
Data
as
that
is
how
most
subject
s
and
many
object
are
named.
IRIs
can
be
expressed
in
a
variety
of
different
ways
in
JSON-LD.

In
general,
term
s
in
the
key
position
in
a
JSON
object
that
have
a
mapping
to
an
IRI
or
another
key
in
the
context
are
expanded
to
an
IRI
by
JSON-LD
processors.
There
are
special
rules
for
processing
keys
in
@context
and
when
dealing
with
keys
that
start
with
the
@subject
character.

An
IRI
is
generated
for
the
value
specified
using
@subject
,
if
it
is
a
string
.

An
IRI
is
generated
for
the
value
specified
using
@type
.

An
IRI
is
generated
for
the
value
specified
using
the
@iri
keyword.

An
IRI
is
generated
when
there
are
@coerce
rules
in
effect
for
a
key
named
@iri
.

Even
though
the
value
http://manu.sporny.org/
is
a
string
,
the
type
coercion
rules
will
transform
the
value
into
an
IRI
when
processed
by
a
JSON-LD
Processor

3.2
Identifying
the
Subject

To
be
able
to
externally
reference
nodes,
it
is
important
that
each
node
has
an
unambiguous
identifier.
IRI
s
are
a
fundamental
concept
of
Linked
Data,
and
nodes
should
have
a
de-referencable
identifier
used
to
name
and
locate
them.
For
nodes
to
be
truely
linked,
de-referencing
the
identifier
should
result
in
a
representation
of
that
node.
Associating
an
IRI
with
a
node
tells
an
application
that
the
returned
document
contains
a
description
of
the
node
requested.

JSON-LD
documents
may
also
contain
descriptions
of
other
nodes,
so
it
is
necessary
to
be
able
to
uniquely
identify
each
node
which
may
be
externally
referenced.

A
subject
of
an
object
in
JSON
is
declared
using
the
@subject
key.
The
subject
is
the
first
piece
of
information
needed
by
the
JSON-LD
processor
in
order
to
create
the
(subject,
property,
object)
tuple,
also
known
as
a
triple.

{

{
...
"",
"@subject": "http://example.org/people#joebob",
...
}

The
example
above
would
set
the
subject
to
the
IRI
http://example.org/people#joebob
.

To
ensure
the
best
possible
performance,
it
is
a
best
practice
to
put
the
@subject
key
before
other
key-value
pairs
in
an
object.
If
it
isn't
listed
first,
processors
have
to
save
each
key-value
pair
until
@subject
is
processed
before
they
can
create
valid
triples.
This
creates
a
memory
and
complexity
burden
for
one-pass
processors.

3.3
Specifying
the
Type

The
type
of
a
particular
subject
can
be
specified
using
the
@type
key.
Specifying
the
type
in
this
way
will
generate
a
triple
of
the
form
(subject,
type,
type-iri).

3.4
Strings

3.5
String
Internationalization

JSON-LD
makes
an
assumption
that
strings
with
associated
language
encoding
information
are
not
very
common
when
used
in
JavaScript
and
Web
Services.
Thus,
it
takes
a
little
more
effort
to
express
strings
with
associated
language
information.

The
example
above
would
generate
a
plain
literal
for
花澄
and
associate
the
ja
language
code
with
the
triple
that
is
generated.
Languages
must
be
expressed
in
[
BCP47
]
format.

3.6
Datatypes

A
value
with
an
associated
datatype,
also
known
as
a
typed
literal
,
is
indicated
by
associating
a
literal
with
an
IRI
which
indicates
the
literal's
datatype.
Typed
literals
may
be
expressed
in
JSON-LD
in
three
ways:

By
utilizing
the
@coerce
keyword.

By
utilizing
the
expanded
form
for
specifying
objects.

By
using
a
native
JSON
datatype.

The
first
example
uses
the
@coerce
keyword
to
express
a
typed
literal:

3.7
Multiple
Objects
for
a
Single
Property

A
JSON-LD
author
can
express
multiple
triples
in
a
compact
way
by
using
array
s.
If
a
subject
has
multiple
values
for
the
same
property,
the
author
may
express
each
property
as
an
array
.

In
JSON-LD,
multiple
objects
on
a
property
are
not
ordered.
This
is
because
typically
graphs
are
not
inherently
ordered
data
structures.
To
see
more
on
creating
ordered
collections
in
JSON-LD,
see
Lists
.

3.9
Expansion

Expansion
is
the
process
of
taking
a
JSON-LD
document
and
applying
a
context
such
that
all
IRI,
datatypes,
and
literal
values
are
expanded
so
that
the
context
is
no
longer
necessary.
JSON-LD
document
expansion
is
typically
used
as
a
part
of
Framing
or
Normalization
.

3.10
Compaction

Compaction
is
the
process
of
taking
a
JSON-LD
document
and
applying
a
context
such
that
the
most
compact
form
of
the
document
is
generated.
JSON
is
typically
expressed
in
a
very
compact,
key-value
format.
That
is,
full
IRIs
are
rarely
used
as
keys.
At
times,
a
JSON-LD
document
may
be
received
that
is
not
in
its
most
compact
form.
JSON-LD,
via
the
API,
provides
a
way
to
compact
a
JSON-LD
document.

The
compaction
algorithm
also
enables
the
developer
to
map
any
expanded
format
into
an
application-specific
compacted
format.
While
the
context
provided
above
mapped
http://xmlns.com/foaf/0.1/name
to
name
,
it
could
have
also
mapped
it
to
any
arbitrary
string
provided
by
the
developer.

3.11
Framing

A
JSON-LD
document
is
a
representation
of
a
directed
graph.
A
single
directed
graph
can
have
many
different
serializations,
each
expressing
exactly
the
same
information.
Developers
typically
work
with
trees,
represented
as
JSON
object
s.
While
mapping
a
graph
to
a
tree
can
be
done,
the
layout
of
the
end
result
must
be
specified
in
advance.
A
Frame
can
be
used
by
a
developer
on
a
JSON-LD
document
to
specify
a
deterministic
layout
for
a
graph.

Framing
is
the
process
of
taking
a
JSON-LD
document,
which
expresses
a
graph
of
information,
and
applying
a
specific
graph
layout
(called
a
Frame
).

Developers
typically
like
to
operate
on
items
in
a
hierarchical,
tree-based
fashion.
Ideally,
a
developer
would
want
the
data
above
sorted
into
top-level
libraries,
then
the
books
that
are
contained
in
each
library,
and
then
the
chapters
contained
in
each
book.
To
achieve
that
layout,
the
developer
can
define
the
following
frame
:

The
JSON-LD
framing
algorithm
allows
developers
to
query
by
example
and
force
a
specific
tree
layout
to
a
JSON-LD
document.

4.
Advanced
Concepts

JSON-LD
has
a
number
of
features
that
provide
functionality
above
and
beyond
the
core
functionality
described
above.
The
following
sections
outline
the
features
that
are
specific
to
JSON-LD.

4.1
External
Contexts
Authors
may
choose
to
declare
JSON-LD
context
s
in
external
documents
to
promote
re-use
of
contexts
as
well
as
reduce
the
size
of
JSON-LD
documents.
In
order
to
use
an
external
context,
an
author
may
specify
an
IRI
to
a
valid
JSON-LD
document.
If
an
IRI
is
specified,
the
external
document
must
be
dereferenced
and
the
top-level
@context
key
in
the
JSON
Object
must
be
overlayed
on
top
of
the
current
active
context.
The
following
example
demonstrates
the
use
of
an
external
context:
{
,
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"avatar": "http://twitter.com/account/profile_image/manusporny"
}
Authors
may
also
import
multiple
contexts
by
specifying
a
list
of
contexts
to
import:
{
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"avatar": "http://twitter.com/account/profile_image/manusporny"
"celebrates":
{
"@type": "Event",
"description": "International Talk Like a Pirate Day",
"date": "R/2011-09-19"
}
}
Each
context
in
a
list
will
be
evaluated
in-order.
Duplicate
values
must
be
overwritten
on
a
last-defined-overrides
basis.
The
context
list
must
contain
either
de-referenceable
IRIs
or
JSON
Object
s
that
conform
to
the
context
syntax
as
described
in
this
document.
External
JSON-LD
context
documents
may
contain
extra
information
located
outside
of
the
@context
key,
such
as
documentation
about
the
prefix
es
declared
in
the
document.
It
is
also
recommended
that
a
human-readable
document
encoded
in
HTML+RDFa
[
HTML-RDFA
]
or
other
Linked
Data
compatible
format
is
served
as
well
to
explain
the
correct
usage
of
the
JSON-LD
context
document.

4.2
4.1
Vocabulary
Prefixes

Vocabulary
terms
in
Linked
Data
documents
may
draw
from
a
number
of
different
Web
vocabularies.
At
times,
declaring
every
single
term
that
a
document
uses
can
require
the
developer
to
declare
tens,
if
not
hundreds
of
potential
vocabulary
terms
that
may
be
used
across
an
application.
This
is
a
concern
for
at
least
three
reasons;
the
first
is
the
cognitive
load
on
the
developer,
the
second
is
the
serialized
size
of
the
context,
the
third
is
future-proofing
application
contexts.
In
order
to
address
these
issues,
the
concept
of
a
prefix
mechanism
is
introduced.

A
prefix
is
a
compact
way
of
expressing
a
base
IRI
to
a
Web
Vocabulary
.
Generally,
these
prefixes
are
used
by
concatenating
the
prefix
and
a
term
separated
by
a
colon
(
:
).
The
prefix
is
a
short
string
that
identifies
a
particular
Web
vocabulary.
For
example,
the
prefix
foaf
may
be
used
as
a
short
hand
for
the
Friend-of-a-Friend
Web
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
full
IRI
for
the
vocabulary
term.
For
example,
foaf:name
would
be
expanded
out
to
the
IRI
http://xmlns.com/foaf/0.1/name
.
Instead
of
having
to
remember
and
type
out
the
entire
IRI,
the
developer
can
instead
use
the
prefix
in
their
JSON-LD
markup.

The
ability
to
use
prefix
es
reduces
the
need
for
developers
to
declare
every
vocabulary
term
that
they
intend
to
use
in
the
JSON-LD
context.
This
reduces
document
serialization
size
because
every
vocabulary
term
need
not
be
declared
in
the
context.
Prefix
also
reduce
the
cognitive
load
on
the
developer.
It
is
far
easier
to
remember
foaf:name
than
it
is
to
remember
http://xmlns.com/foaf/0.1/name
.
The
use
of
prefixes
also
ensures
that
a
context
document
does
not
have
to
be
updated
in
lock-step
with
an
externally
defined
Web
Vocabulary
.
Without
prefixes,
a
developer
would
need
to
keep
their
application
context
terms
in
lock-step
with
an
externally
defined
Web
Vocabulary.
Rather,
by
just
declaring
the
Web
Vocabulary
prefix,
one
can
use
new
terms
as
they're
declared
without
having
to
update
the
application's
JSON-LD
context.

4.3
4.2
Automatic
Typing

Since
JSON
is
capable
of
expressing
typed
information
such
as
doubles,
integers,
and
boolean
values.
As
demonstrated
below,
JSON-LD
utilizes
that
information
to
create
typed
literal
s:

{

{
...
// The following two values are automatically converted to a type of xsd:double
// and both values are equivalent to each other.
"measure:cups": ,
"measure:cups": ,
"measure:cups": 5.3,
"measure:cups": 5.3e0,
// The following value is automatically converted to a type of xsd:double as well
"space:astronomicUnits": ,
"space:astronomicUnits": 6.5e73,
// The following value should never be converted to a language-native type
"measure:stones": ,
"measure:stones": { "@literal": "4.8", "@datatype": "xsd:decimal" },
// This value is automatically converted to having a type of xsd:integer
"chem:protons": ,
"chem:protons": 12,
// This value is automatically converted to having a type of xsd:boolean
"sensor:active": ,
"sensor:active": true,
...
}

When
dealing
with
a
number
of
modern
programming
languages,
including
JavaScript
ECMA-262,
there
is
no
distinction
between
xsd:decimal
and
xsd:double
values.
That
is,
the
number
5.3
and
the
number
5.3e0
are
treated
as
if
they
were
the
same.
When
converting
from
JSON-LD
to
a
language-native
format
and
back,
datatype
information
is
lost
in
a
number
of
these
languages.
Thus,
one
could
say
that
5.3
is
a
xsd:decimal
and
5.3e0
is
an
xsd:double
in
JSON-LD,
but
when
both
values
are
converted
to
a
language-native
format
the
datatype
difference
between
the
two
is
lost
because
the
machine-level
representation
will
almost
always
be
a
double
.
Implementers
should
be
aware
of
this
potential
round-tripping
issue
between
xsd:decimal
and
xsd:double
.
Specifically
objects
with
a
datatype
of
xsd:decimal
must
not
be
converted
to
a
language
native
type.

4.4
4.3
Type
Coercion

JSON-LD
supports
the
coercion
of
values
to
particular
data
types.
Type
coercion
allows
someone
deploying
JSON-LD
to
coerce
the
incoming
or
outgoing
types
to
the
proper
data
type
based
on
a
mapping
of
data
type
IRIs
to
property
types.
Using
type
coercion,
one
may
convert
simple
JSON
data
to
properly
typed
RDF
data.

4.5
4.4
Chaining

Object
chaining
is
a
JSON-LD
feature
that
allows
an
author
to
use
the
definition
of
JSON-LD
objects
as
property
values.
This
is
a
commonly
used
mechanism
for
creating
a
parent-child
relationship
between
two
subject
s.

The
example
shows
an
two
subjects
related
by
a
property
from
the
first
subject:

An
object
definition,
like
the
one
used
above,
may
be
used
as
a
JSON
value
at
any
point
in
JSON-LD.

4.6
4.5
Identifying
Unlabeled
Nodes

At
times,
it
becomes
necessary
to
be
able
to
express
information
without
being
able
to
specify
the
subject.
Typically,
this
type
of
node
is
called
an
unlabeled
node
or
a
blank
node.
In
JSON-LD,
unlabeled
node
identifiers
are
automatically
created
if
a
subject
is
not
specified
using
the
@subject
keyword.
However,
authors
may
provide
identifiers
for
unlabeled
nodes
by
using
the
special
_
(underscore)
prefix
.
This
allows
to
reference
the
node
locally
within
the
document
but
not
in
an
external
document.

{

{
...
"@subject": "",
"@subject": "_:foo",
...
}

The
example
above
would
set
the
subject
to
_:foo
,
which
can
then
be
used
later
on
in
the
JSON-LD
markup
to
refer
back
to
the
unlabeled
node.
This
practice,
however,
is
usually
frowned
upon
when
generating
Linked
Data.
If
a
developer
finds
that
they
refer
to
the
unlabeled
node
more
than
once,
they
should
consider
naming
the
node
using
a
resolve-able
IRI.

4.7
4.6
Aliasing
Keywords

JSON-LD
allows
all
of
the
syntax
keywords,
except
for
@context
,
to
be
aliased.
This
feature
allows
more
legacy
JSON
content
to
be
supported
by
JSON-LD.
It
also
allows
developers
to
design
domain-specific
implementations
using
only
the
JSON-LD
context.

In
the
example
above,
the
@subject
and
@type
keywords
have
been
given
the
aliases
url
and
a
,
respectively.

4.8
4.7
Normalization

Normalization
is
the
process
of
taking
JSON-LD
input
and
performing
a
deterministic
transformation
on
that
input
that
results
in
a
JSON-LD
output
that
any
conforming
JSON-LD
processor
would
have
generated
given
the
same
input.
The
problem
is
a
fairly
difficult
technical
problem
to
solve
because
it
requires
a
directed
graph
to
be
ordered
into
a
set
of
nodes
and
edges
in
a
deterministic
way.
This
is
easy
to
do
when
all
of
the
nodes
have
unique
names,
but
very
difficult
to
do
when
some
of
the
nodes
are
not
labeled.

Normalization
is
useful
when
comparing
two
graphs
against
one
another,
when
generating
a
detailed
list
of
differences
between
two
graphs,
and
when
generating
a
cryptographic
digital
signature
for
information
contained
in
a
graph
or
when
generating
a
hash
of
the
information
contained
in
a
graph.

Notice
how
all
of
the
term
s
have
been
expanded
and
sorted
in
alphabetical
order.
Also,
notice
how
the
subject
has
been
labeled
with
a
blank
node
identifier
.
Normalization
ensures
that
any
arbitrary
graph
containing
exactly
the
same
information
would
be
normalized
to
exactly
the
same
form
shown
above.

5.
The
Application
Programming
Interface

This
API
provides
a
clean
mechanism
that
enables
developers
to
convert
JSON-LD
data
into
a
a
variety
of
output
formats
that
are
easier
to
work
with
in
various
programming
languages.
If
a
JSON-LD
API
is
provided
in
a
programming
environment,
the
entirety
of
the
following
API
must
be
implemented.

5.1.1
Methods

compact

Compacts
the
given
input
according
to
the
steps
in
the
Compaction
Algorithm
.
The
input
must
be
copied,
compacted
and
returned
if
there
are
no
errors.
If
the
compaction
fails,
an
appropirate
exception
must
be
thrown.

A
general
syntax
error
was
detected
in
the
@context
.
For
example,
if
a
@coerce
key
maps
to
anything
other
than
a
string
or
an
array
of
strings,
this
exception
would
be
raised.

MULTIPLE_DATATYPES

There
is
more
than
one
target
datatype
specified
for
a
single
property
in
the
list
of
coercion
rules.
This
means
that
the
processor
does
not
know
what
the
developer
intended
for
the
target
datatype
for
a
property.

Expands
the
given
input
according
to
the
steps
in
the
Expansion
Algorithm
.
The
input
must
be
copied,
expanded
and
returned
if
there
are
no
errors.
If
the
expansion
fails,
an
appropriate
exception
must
be
thrown.

A
general
syntax
error
was
detected
in
the
@context
.
For
example,
if
a
@coerce
key
maps
to
anything
other
than
a
string
or
an
array
of
strings,
this
exception
would
be
raised.

MULTIPLE_DATATYPES

There
is
more
than
one
target
datatype
specified
for
a
single
property
in
the
list
of
coercion
rules.
This
means
that
the
processor
does
not
know
what
the
developer
intended
for
the
target
datatype
for
a
property.

Frames
the
given
input
using
the
frame
according
to
the
steps
in
the
Framing
Algorithm
.
The
input
is
used
to
build
the
framed
output
and
is
returned
if
there
are
no
errors.
If
there
are
no
matches
for
the
frame,
null
must
be
returned.
Exceptions
must
be
thrown
if
there
are
errors.

Normalizes
the
given
input
according
to
the
steps
in
the
Normalization
Algorithm
.
The
input
must
be
copied,
normalized
and
returned
if
there
are
no
errors.
If
the
compaction
fails,
null
must
be
returned.

A
general
syntax
error
was
detected
in
the
@context
.
For
example,
if
a
@coerce
key
maps
to
anything
other
than
a
string
or
an
array
of
strings,
this
exception
would
be
raised.

MULTIPLE_DATATYPES

There
is
more
than
one
target
datatype
specified
for
a
single
property
in
the
list
of
coercion
rules.
This
means
that
the
processor
does
not
know
what
the
developer
intended
for
the
target
datatype
for
a
property.

A
general
syntax
error
was
detected
in
the
@context
.
For
example,
if
a
@coerce
key
maps
to
anything
other
than
a
string
or
an
array
of
strings,
this
exception
would
be
raised.

MULTIPLE_DATATYPES

There
is
more
than
one
target
datatype
specified
for
a
single
property
in
the
list
of
coercion
rules.
This
means
that
the
processor
does
not
know
what
the
developer
intended
for
the
target
datatype
for
a
property.

6.
Algorithms

All
algorithms
described
in
this
section
are
intended
to
operate
on
language-native
data
structures.
That
is,
the
serialization
to
a
text-based
JSON
document
isn't
required
as
input
or
output
to
any
of
these
algorithms
and
language-native
data
structures
must
be
used
where
applicable.

6.1
Syntax
Tokens
and
Keywords

JSON-LD
specifies
a
number
of
syntax
tokens
and
keywords
that
are
using
in
all
algorithms
described
in
this
section:

6.3.2
Initial
Context

@base
is
set
using
section
5.1
Establishing
a
Base
URI
of
[
RFC3986
].
Processors
may
provide
a
means
of
setting
the
base
IRI
programatically.

@coerce
is
set
with
a
single
mapping
from
@iri
to
@type
.

{
"@base": document-location,
"@context": {
"@iri": "@type"
}
}

6.4
IRI
Expansion

Keys
and
some
values
are
evaluated
to
produce
an
IRI.
This
section
defines
an
algorithm
for
transforming
a
value
representing
an
IRI
into
an
actual
IRI.

IRIs
may
be
represented
as
an
absolute
IRI,
a
term
,
a
prefix
:
term
construct,
or
as
a
value
relative
to
@base
or
@vocab
.

The
algorithm
for
generating
an
IRI
is:

Split
the
value
into
a
prefix
and
suffix
from
the
first
occurrence
of
':'.

If
the
prefix
is
a
'_'
(underscore),
the
IRI
is
unchanged.

If
the
active
context
contains
a
mapping
for
prefix
,
generate
an
IRI
by
prepending
the
mapped
prefix
to
the
(possibly
empty)
suffix
using
textual
concatenation.
Note
that
an
empty
suffix
and
no
suffix
(meaning
the
value
contains
no
':'
string
at
all)
are
treated
equivalently.

If
the
IRI
being
processed
is
for
a
property
(i.e.,
a
key's
value
in
a
JSON
object
,
or
a
value
in
a
@coerce
mapping)
and
the
active
context
has
a
@vocab
mapping,
join
the
mapped
value
to
the
suffix
using
textual
concatenation.

If
the
IRI
being
processed
is
for
a
subject
or
object
(i.e.,
not
a
property)
and
the
active
context
has
a
@base
mapping,
join
the
mapped
value
to
the
suffix
using
the
method
described
in
[
RFC3986
].

Otherwise,
use
the
value
directly
as
an
IRI.

6.5
IRI
Compaction

Some
keys
and
values
are
expressed
using
IRIs.
This
section
defines
an
algorithm
for
transforming
an
IRI
to
a
compact
IRI
using
the
term
s
and
prefix
es
specified
in
the
local
context
.

The
algorithm
for
generating
a
compacted
IRI
is:

Search
every
key-value
pair
in
the
active
context
for
a
term
that
is
a
complete
match
against
the
IRI.
If
a
complete
match
is
found,
the
resulting
compacted
IRI
is
the
term
associated
with
the
IRI
in
the
active
context
.

If
a
complete
match
is
not
found,
search
for
a
partial
match
from
the
beginning
of
the
IRI.
For
all
matches
that
are
found,
the
resulting
compacted
IRI
is
the
prefix
associated
with
the
partially
matched
IRI
in
the
active
context
concatenated
with
a
colon
(:)
character
and
the
unmatched
part
of
the
string.
If
there
is
more
than
one
compacted
IRI
produced,
the
final
value
is
the
shortest
and
lexicographically
least
value
of
the
entire
set
of
compacted
IRIs.

6.6
Value
Expansion

Some
values
in
JSON-LD
can
be
expressed
in
a
compact
form.
These
values
are
required
to
be
expanded
at
times
when
processing
JSON-LD
documents.

The
algorithm
for
expanding
a
value
is:

If
the
key
that
is
associated
with
the
value
has
an
associated
coercion
entry
in
the
local
context
,
the
resulting
expansion
is
an
object
populated
according
to
the
following
steps:

If
the
coercion
target
is
@iri
,
expand
the
value
by
adding
a
new
key-value
pair
where
the
key
is
@iri
and
the
value
is
the
expanded
IRI
according
to
the
IRI
Expansion
rules.

If
the
coercion
target
is
a
typed
literal,
expand
the
value
by
adding
two
new
key-value
pairs.
The
first
key-value
pair
will
be
@literal
and
the
unexpanded
value.
The
second
key-value
pair
will
be
@datatype
and
the
associated
coercion
datatype
expanded
according
to
the
IRI
Expansion
rules.

6.7
Value
Compaction

Some
values,
such
as
IRIs
and
typed
literals,
may
be
expressed
in
an
expanded
form
in
JSON-LD.
These
values
are
required
to
be
compacted
at
times
when
processing
JSON-LD
documents.

The
algorithm
for
compacting
a
value
is:

If
the
local
context
contains
a
coercion
target
for
the
key
that
is
associated
with
the
value,
compact
the
value
using
the
following
steps:

If
the
coercion
target
is
an
@iri
,
the
compacted
value
is
the
value
associated
with
the
@iri
key,
processed
according
to
the
IRI
Compaction
steps.

If
the
coercion
target
is
a
typed
literal,
the
compacted
value
is
the
value
associated
with
the
@literal
key.

Otherwise,
the
value
is
not
modified.

6.8
Expansion

This
algorithm
is
a
work
in
progress,
do
not
implement
it.

As
stated
previously,
expansion
is
the
process
of
taking
a
JSON-LD
input
and
expanding
all
IRIs
and
typed
literals
to
their
fully-expanded
form.
The
output
will
not
contain
a
single
context
declaration
and
will
have
all
IRIs
and
typed
literals
fully
expanded.

If
the
value
is
an
array
,
process
each
item
in
the
array
recursively
using
this
algorithm.

If
the
value
is
an
object,
process
the
object
recursively
using
this
algorithm.

Otherwise,
check
to
see
the
associated
key
has
an
associated
coercion
rule.
If
the
value
should
be
coerced,
expand
the
value
according
to
the
Value
Expansion
rules.
If
the
value
does
not
need
to
be
coerced,
leave
the
value
as-is.

Remove
the
context
from
the
object.

6.9
Compaction

This
algorithm
is
a
work
in
progress,
do
not
implement
it.

As
stated
previously,
compaction
is
the
process
of
taking
a
JSON-LD
input
and
compacting
all
IRIs
using
a
given
context.
The
output
will
contain
a
single
top-level
context
declaration
and
will
only
use
term
s
and
prefix
es
and
will
ensure
that
all
typed
literals
are
fully
compacted.

6.10
Framing

This
algorithm
is
a
work
in
progress,
do
not
implement
it.

A
JSON-LD
document
is
a
representation
of
a
directed
graph.
A
single
directed
graph
can
have
many
different
serializations,
each
expressing
exactly
the
same
information.
Developers
typically
don't
work
directly
with
graphs,
but
rather,
prefer
trees
when
dealing
with
JSON.
While
mapping
a
graph
to
a
tree
can
be
done,
the
layout
of
the
end
result
must
be
specified
in
advance.
This
section
defines
an
algorithm
for
mapping
a
graph
to
a
tree
given
a
frame
.

The
expanded
frame
has
an
rdf:type
that
exists
in
the
item's
list
of
rdf:type
s.
Note:
the
rdf:type
can
be
an
array
,
but
only
one
value
needs
to
be
in
common
between
the
item
and
the
expanded
frame
for
a
match.

The
expanded
frame
does
not
have
an
rdf:type
property,
but
every
property
in
the
expanded
frame
exists
in
the
item.

Process
each
item
in
the
match
array
with
its
associated
match
frame
:

If
the
key
is
in
the
item,
then
build
a
new
recursion
input
list
using
the
object
or
objects
associated
with
the
key.
If
any
object
contains
an
@iri
value
that
exists
in
the
normalized
input
,
replace
the
object
in
the
recusion
input
list
with
a
new
object
containing
the
@subject
key
where
the
value
is
the
value
of
the
@iri
,
and
all
of
the
other
key-value
pairs
for
that
subject.
Set
the
recursion
match
frame
to
the
value
associated
with
the
match
frame
's
key.
Replace
the
value
associated
with
the
key
by
recursively
calling
this
algorithm
using
recursion
input
list
,
recursion
match
frame
as
input.

If
the
key
is
not
in
the
item,
add
the
key
to
the
item
and
set
the
associated
value
to
an
empty
array
if
the
match
frame
key's
value
is
an
array
or
null
otherwise.

The
final,
non-recursive
step
of
the
framing
algorithm
requires
the
JSON-LD
output
to
be
compacted
according
to
the
Compaction
Algorithm
by
using
the
context
provided
in
the
input
frame
.
The
resulting
value
is
the
final
output
of
the
compaction
algorithm
and
is
what
should
be
returned
to
the
application.

6.11
Normalization

This
algorithm
is
a
work
in
progress,
do
not
implement
it.

Normalization
is
the
process
of
taking
JSON-LD
input
and
performing
a
deterministic
transformation
on
that
input
that
results
in
all
aspects
of
the
graph
being
fully
expanded
and
named
in
the
JSON-LD
output
.
The
normalized
output
is
generated
in
such
a
way
that
any
conforming
JSON-LD
processor
will
generate
identical
output
given
the
same
input.
The
problem
is
a
fairly
difficult
technical
problem
to
solve
because
it
requires
a
directed
graph
to
be
ordered
into
a
set
of
nodes
and
edges
in
a
deterministic
way.
This
is
easy
to
do
when
all
of
the
nodes
have
unique
names,
but
very
difficult
to
do
when
some
of
the
nodes
are
not
labeled.

In
time,
there
may
be
more
than
one
normalization
algorithm
that
will
need
to
be
identified.
For
identification
purposes,
this
algorithm
is
named
UGNA2011
.

6.11.1
Normalization
Algorithm
Terms

label

The
subject
IRI
associated
with
a
graph
node.
The
subject
IRI
is
expressed
using
a
key-value
pair
in
a
JSON
object
where
the
key
is
@subject
and
the
value
is
a
string
that
is
an
IRI
or
a
JSON
object
containing
the
key
@iri
and
a
value
that
is
a
string
that
is
an
IRI.

An
identifier
that
is
created
to
aid
in
the
normalization
process
in
the
Deep
Comparison
Algorithm
.
The
value
typically
takes
the
form
of
s
or
c
.

6.11.2
Normalization
State

When
performing
the
steps
required
by
the
normalization
algorithm,
it
is
helpful
to
track
the
many
pieces
of
information
in
a
data
structure
called
the
normalization
state
.
Many
of
these
pieces
simply
provide
indexes
into
the
graph.
The
information
contained
in
the
normalization
state
is
described
below.

node
state

Each
node
in
the
graph
will
be
assigned
a
node
state
.
This
state
contains
the
information
necessary
to
deterministically
label
all
nodes
in
the
graph.
A
node
state
includes:

Lists
the
label
s
for
all
nodes
that
are
properties
of
the
node
reference
.
This
list
should
be
initialized
by
iterating
over
every
object
associated
with
a
property
in
the
node
reference
adding
its
label
if
it
is
another
node.

incoming
list

Lists
the
label
s
for
all
nodes
in
the
graph
for
which
the
node
reference
is
a
property.
This
list
is
initialized
to
an
empty
list.

outgoing
serialization
map

Maps
node
label
s
to
serialization
label
s.
This
map
is
initialized
to
an
empty
map.
When
this
map
is
populated,
it
will
be
filled
with
keys
that
are
the
label
s
of
every
node
in
the
graph
with
a
label
that
begins
with
_:
and
that
has
a
path,
via
properties,
that
starts
with
the
node
reference
.

Maps
node
label
s
to
serialization
label
s.
This
map
is
initialized
to
an
empty
map.
When
this
map
is
populated,
it
will
be
filled
with
keys
that
are
the
label
s
of
every
node
in
the
graph
with
a
label
that
begins
with
_:
and
that
has
a
path,
via
properties,
that
ends
with
the
node
reference
.

The
labeling
prefix
is
a
string
that
is
used
as
the
beginning
of
a
node
label
.
It
should
be
initialized
to
a
random
base
string
that
starts
with
the
characters
_:
,
is
not
used
by
any
other
node's
label
in
the
JSON-LD
input
,
and
does
not
start
with
the
characters
_:c14n
.
The
prefix
has
two
uses.
First
it
is
used
to
temporarily
name
nodes
during
the
normalization
algorithm
in
a
way
that
doesn't
collide
with
the
names
that
already
exist
as
well
as
the
names
that
will
be
generated
by
the
normalization
algorithm.
Second,
it
will
eventually
be
set
to
_:c14n
to
generate
the
final,
deterministic
labels
for
nodes
in
the
graph.
This
prefix
will
be
concatenated
with
the
labeling
counter
to
produce
a
node
label
.
For
example,
_:j8r3k
is
a
proper
initial
value
for
the
labeling
prefix
.

labeling
counter

A
counter
that
is
used
to
label
nodes.
It
is
appended
to
the
labeling
prefix
to
create
a
node
label
.
It
is
initialized
to
1
.

map
of
flattened
nodes

A
map
containing
a
representation
of
all
nodes
in
the
graph
where
the
key
is
a
node
label
and
the
value
is
a
single
JSON
object
that
has
no
nested
sub-objects
and
has
had
all
properties
for
the
same
node
merged
into
a
single
JSON
object
.

6.11.3
Normalization
Algorithm

The
normalization
algorithm
expands
the
JSON-LD
input
,
flattens
the
data
structure,
and
creates
an
initial
set
of
names
for
all
nodes
in
the
graph.
The
flattened
data
structure
is
then
processed
by
a
node
labeling
algorithm
in
order
to
get
a
fully
expanded
and
named
list
of
nodes
which
is
then
sorted.
The
result
is
a
deterministically
named
and
ordered
list
of
graph
nodes.

Go
through
every
property
associated
with
an
array
in
the
expanded
node
and
remove
any
duplicate
IRI
entries
from
the
array.
If
the
resulting
array
only
has
one
IRI
entry,
change
it
from
an
array
to
an
object.

After
exiting
the
recursive
step,
replace
the
reference
to
the
expanded
node
with
an
object
containing
a
single
key-value
pair
where
the
key
is
@iri
and
the
value
is
the
value
of
the
@subject
key
in
the
node.

6.11.6
Shallow
Comparison
Algorithm

The
shallow
comparison
algorithm
takes
two
unlabeled
nodes,
alpha
and
beta
,
as
input
and
determines
which
one
should
come
first
in
a
sorted
list.
The
following
algorithm
determines
the
steps
that
are
executed
in
order
to
determine
the
node
that
should
come
first
in
a
list:

Compare
the
total
number
of
node
properties.
The
node
with
fewer
properties
is
first.

Lexicographically
sort
the
property
IRIs
for
each
node
and
compare
the
sorted
lists.
If
an
IRI
is
found
to
be
lexicographically
smaller,
the
node
containing
that
IRI
is
first.

Compare
the
values
of
each
property
against
one
another:

The
node
associated
with
fewer
property
values
is
first.

Create
an
alpha
list
by
adding
all
values
associated
with
the
alpha
property
that
are
not
unlabeled
nodes.

Create
a
beta
list
by
adding
all
values
associated
with
the
beta
property
that
is
not
an
unlabeled
node.

Compare
the
length
of
alpha
list
and
beta
list
.
The
node
associated
with
the
list
containing
the
fewer
number
of
items
is
first.

6.11.7
Object
Comparison
Algorithm

The
object
comparison
algorithm
is
designed
to
compare
two
graph
node
property
values,
alpha
and
beta
,
against
the
other.
The
algorithm
is
useful
when
sorting
two
lists
of
graph
node
properties.

If
one
of
the
values
is
a
string
and
the
other
is
not,
the
value
that
is
a
string
is
first.

If
both
values
are
string
s,
the
lexicographically
lesser
string
is
first.

If
one
of
the
values
is
a
literal
and
the
other
is
not,
the
value
that
is
a
literal
is
first.

If
both
values
are
literals:

The
lexicographically
lesser
string
associated
with
@literal
is
first.

The
lexicographically
lesser
string
associated
with
@datatype
is
first.

The
lexicographically
lesser
string
associated
with
@language
is
first.

If
both
values
are
expanded
IRIs,
the
lexicographically
lesser
string
associated
with
@iri
is
first.

Otherwise,
the
two
values
are
equivalent.

6.11.8
Deep
Comparison
Algorithm

The
deep
comparison
algorithm
is
used
to
compare
the
difference
between
two
nodes,
alpha
and
beta
.
A
deep
comparison
takes
the
incoming
and
outgoing
node
edges
in
a
graph
into
account
if
the
number
of
properties
and
value
of
those
properties
are
identical.
The
algorithm
is
helpful
when
sorting
a
list
of
nodes
and
will
return
whichever
node
should
be
placed
first
in
a
list
if
the
two
nodes
are
not
truly
equivalent.

When
performing
the
steps
required
by
the
deep
comparison
algorithm,
it
is
helpful
to
track
state
information
about
mappings.
The
information
contained
in
a
mapping
state
is
described
below.

A
stack
where
each
element
contains
an
array
of
adjacent
serialization
label
s
and
an
index
into
that
array.
It
is
initialized
to
a
stack
containing
a
single
element
where
its
array
contains
a
single
string
element
s1
and
its
index
is
set
to
0
.

6.11.9
Node
Serialization
Algorithm

The
node
serialization
algorithm
takes
a
node
state
,
a
mapping
state
,
and
a
direction
(either
outgoing
direction
or
incoming
direction
)
as
inputs
and
generates
a
deterministic
serialization
for
the
node
reference
.

Build
a
string
using
the
pattern
<
KEY
>
where
KEY
is
the
current
key.
Append
string
to
the
label
serialization
.

The
value
may
be
a
single
object
or
an
array
of
objects.
Process
all
of
the
objects
that
are
associated
with
the
key,
building
an
object
string
for
each
item:

If
the
object
contains
an
@iri
key
with
a
value
that
starts
with
_:
,
set
the
object
string
to
the
value
_:
.
If
the
value
does
not
start
with
_:
,
build
the
object
string
using
the
pattern
<
IRI
>
where
IRI
is
the
value
associated
with
the
@iri
key.

If
the
object
contains
a
@literal
key
and
a
@datatype
key,
build
the
object
string
using
the
pattern
"
LITERAL
"^^
<
DATATYPE
>
where
LITERAL
is
the
value
associated
with
the
@literal
key
and
DATATYPE
is
the
value
associated
with
the
@datatype
key.

If
the
object
contains
a
@literal
key
and
a
@language
key,
build
the
object
string
using
the
pattern
"
LITERAL
"@
LANGUAGE
where
LITERAL
is
the
value
associated
with
the
@literal
key
and
LANGUAGE
is
the
value
associated
with
the
@language
key.

Otherwise,
the
value
is
a
string.
Build
the
object
string
using
the
pattern
"
LITERAL
"
where
LITERAL
is
the
value
associated
with
the
current
key.

Build
a
reference
string
using
the
pattern
<
PROPERTY
>
<
REFERER
>
where
PROPERTY
is
the
property
associated
with
the
incoming
reference
and
REFERER
is
either
the
subject
of
the
node
referring
to
the
label
in
the
incoming
reference
or
_:
if
REFERER
begins
with
_:
.

6.12
Data
Round
Tripping

When
normalizing
xsd:double
values,
implementers
must
ensure
that
the
normalized
value
is
a
string.
In
order
to
generate
the
string
from
a
double
value,
output
equivalent
to
the
printf("%1.6e",
value)
function
in
C
must
be
used
where
"%1.6e"
is
the
string
formatter
and
value
is
the
value
to
be
converted.

To
convert
the
a
double
value
in
JavaScript,
implementers
can
use
the
following
snippet
of
code:

// the variable 'value' below is the JavaScript native double value that is to be converted
(value).toExponential(6).replace(/(e(?:\+|-))([0-9])$/,
'$10$2')

When
data
needs
to
be
normalized,
JSON-LD
authors
should
not
use
values
that
are
going
to
undergo
automatic
conversion.
This
is
due
to
the
lossy
nature
of
xsd:double
values.

Some
JSON
serializers,
such
as
PHP's
native
implementation,
backslash-escapes
the
forward
slash
character.
For
example,
the
value
http://example.com/
would
be
serialized
as
http:\/\/example.com\/
in
some
versions
of
PHP.
This
is
problematic
when
generating
a
byte
stream
for
processes
such
as
normalization.
There
is
no
need
to
backslash-escape
forward-slashes
in
JSON-LD.
To
aid
interoperability
between
JSON-LD
processors,
a
JSON-LD
serializer
must
not
backslash-escape
forward
slashes.

Round-tripping
data
can
be
problematic
if
we
mix
and
match
@coerce
rules
with
JSON-native
datatypes,
like
integers.
Consider
the
following
code
example:

At
this
point,
myObj2
and
myObj
will
have
different
values
for
the
"number"
value.
myObj
will
be
the
number
42,
while
myObj2
will
be
the
string
"42".
This
type
of
data
round-tripping
error
can
bite
developers.
We
are
currently
wondering
if
having
a
"coerce
validation"
phase
in
the
parsing/normalization
phases
would
be
a
good
idea.
It
would
prevent
data
round-tripping
issues
like
the
one
mentioned
above.

6.13
RDF
Conversion

A
JSON-LD
document
may
be
converted
to
any
other
RDF-compatible
document
format
using
the
algorithm
specified
in
this
section.

The
JSON-LD
Processing
Model
describes
processing
rules
for
extracting
RDF
from
a
JSON-LD
document.
Note
that
many
uses
of
JSON-LD
may
not
require
generation
of
RDF.

The
processing
algorithm
described
in
this
section
is
provided
in
order
to
demonstrate
how
one
might
implement
a
JSON-LD
to
RDF
processor.
Conformant
implementations
are
only
required
to
produce
the
same
type
and
number
of
triples
during
the
output
process
and
are
not
required
to
implement
the
algorithm
exactly
as
described.

The
RDF
Conversion
Algorithm
is
a
work
in
progress.

6.13.1
Overview

This
section
is
non-normative.

JSON-LD
is
intended
to
have
an
easy
to
parse
grammar
that
closely
models
existing
practice
in
using
JSON
for
describing
object
representations.
This
allows
the
use
of
existing
libraries
for
parsing
JSON
in
a
document-oriented
fashion,
or
can
allow
for
stream-based
parsing
similar
to
SAX.

As
with
other
grammars
used
for
describing
Linked
Data
,
a
key
concept
is
that
of
a
resource
.
Resources
may
be
of
three
basic
types:
IRI
s,
for
describing
externally
named
entities,
BNodes
,
resources
for
which
an
external
name
does
not
exist,
or
is
not
known,
and
Literals,
which
describe
terminal
entities
such
as
strings,
dates
and
other
representations
having
a
lexical
representation
possibly
including
an
explicit
language
or
datatype.

Data
described
with
JSON-LD
may
be
considered
to
be
the
representation
of
a
graph
made
up
of
subject
and
object
resources
related
via
a
property
resource.
However,
specific
implementations
may
choose
to
operate
on
the
document
as
a
normal
JSON
description
of
objects
having
attributes.

6.13.2
RDF
Conversion
Algorithm
Terms

default
graph

the
destination
graph
for
all
triples
generated
by
JSON-LD
markup.

6.13.3
RDF
Conversion
Algorithm

The
algorithm
below
is
designed
for
in-memory
implementations
with
random
access
to
JSON
object
elements.

A
conforming
JSON-LD
processor
implementing
RDF
conversion
must
implement
a
processing
algorithm
that
results
in
the
same
default
graph
that
the
following
algorithm
generates:

If
a
number
is
detected,
generate
a
typed
literal
using
a
string
representation
of
the
value
with
datatype
set
to
either
xsd:integer
or
xsd:double
,
depending
on
if
the
value
contains
a
fractional
and/or
an
exponential
component.
Generate
a
triple
using
the
active
subject
,
active
property
and
the
generated
typed
literal.

A.
Experimental
Concepts

There
are
a
few
advanced
concepts
where
it
is
not
clear
whether
or
not
the
JSON-LD
specification
is
going
to
support
the
complexity
necessary
to
support
each
concept.
The
entire
section
on
Advanced
Concepts
should
be
considered
as
discussion
points;
it
is
merely
a
list
of
possibilities
where
all
of
the
benefits
and
drawbacks
have
not
been
explored.

A.1
Disjoint
Graphs

When
serializing
an
RDF
graph
that
contains
two
or
more
sections
of
the
graph
which
are
entirely
disjoint,
one
must
use
an
array
to
express
the
graph
as
two
graphs.
This
may
not
be
acceptable
to
some
authors,
who
would
rather
express
the
information
as
one
graph.
Since,
by
definition,
disjoint
graphs
require
there
to
be
two
top-level
objects,
JSON-LD
utilizes
a
mechanism
that
allows
disjoint
graphs
to
be
expressed
using
a
single
graph.

Warning:
Using
this
serialisation
format
it
is
impossible
to
include
@context
given
that
the
document's
data
structure
is
an
array
and
not
an
object.

A.2
Lists

Because
graphs
do
not
describe
ordering
for
links
between
nodes,
in
contrast
to
plain
JSON,
multi-valued
properties
in
JSON-LD
do
not
provide
an
ordering
of
the
listed
objects.
For
example,
consider
the
following
simple
document:

This
results
in
three
triples
being
generated,
each
relating
the
subject
to
an
individual
object,
with
no
inherent
order.

To
preserve
the
order
of
the
objects,
RDF-based
languages,
such
as
[
TURTLE
]
use
the
concept
of
an
rdf:List
(as
described
in
[
RDF-SCHEMA
]).
This
uses
a
sequence
of
unlabeled
nodes
with
properties
describing
a
value,
a
null-terminated
next
property.
Without
specific
syntactical
support,
this
could
be
represented
in
JSON-LD
as
follows:

As
this
notation
is
rather
unwieldy
and
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:

This
describes
the
use
of
this
array
as
being
ordered,
and
order
is
maintained
through
normalization
and
RDF
conversion.
If
every
use
of
a
given
multi-valued
property
is
a
list,
this
may
be
abbreviated
by
adding
an
@coerce
term:

B.
Markup
Examples

The
JSON-LD
markup
examples
below
demonstrate
how
JSON-LD
can
be
used
to
express
semantic
data
marked
up
in
other
languages
such
as
RDFa,
Microformats,
and
Microdata.
These
sections
are
merely
provided
as
proof
that
JSON-LD
is
very
flexible
in
what
it
can
express
across
different
Linked
Data
approaches.

A.1
B.1
RDFa

The
following
example
describes
three
people
with
their
respective
names
and
homepages.

The
representation
of
the
hCard
expresses
the
Microformat
terms
in
the
context
and
uses
them
directly
for
the
url
and
fn
properties.
Also
note
that
the
Microformat
to
JSON-LD
processor
has
generated
the
proper
URL
type
for
http://tantek.com
.

B.
C.
Mashing
Up
Vocabularies

Developers
would
also
benefit
by
allowing
other
vocabularies
to
be
used
automatically
with
their
JSON
API.
There
are
over
200
Web
Vocabulary
Documents
that
are
available
for
use
on
the
Web
today.
Some
of
these
vocabularies
are:

RDF
-
for
describing
information
about
objects
and
concepts
on
the
Web.

The
@context
keyword
is
used
to
change
how
the
JSON-LD
processor
evaluates
key-value
pairs.
In
this
case,
it
was
used
to
map
one
string
('myvocab')
to
another
string,
which
is
interpreted
as
a
IRI
.
In
the
example
above,
the
myvocab
string
is
replaced
with
"
"
http://example.org/myvocab#
"
"
when
it
is
detected.
In
the
example
above,
"
"
myvocab:personality
"
"
would
expand
to
"
"
http://example.org/myvocab#personality
".
".

This
mechanism
is
a
short-hand,
called
a
Web
Vocabulary
prefix
,
and
provides
developers
an
unambiguous
way
to
map
any
JSON
value
to
RDF.

C.
D.
IANA
Considerations

This
section
is
included
merely
for
standards
community
review
and
will
be
submitted
to
the
Internet
Engineering
Steering
Group
if
this
specification
becomes
a
W3C
Recommendation.

Type
name:

application

Subtype
name:

ld+json

Required
parameters:

None

Optional
parameters:

form

Determines
the
serialization
form
for
the
JSON-LD
document.
Valid
values
include;
compacted
,
expanded
,
framed
,
and
normalized
.
Other
values
are
allowed,
but
must
be
pre-pended
with
a
x-
string
until
they
are
clearly
defined
by
a
stable
specification.
If
no
form
is
specified
in
an
HTTP
request
header
to
a
responding
application,
such
as
a
Web
server,
the
application
may
choose
any
form.
If
no
form
is
specified
for
a
receiving
application,
the
form
must
not
be
assumed
to
take
any
particular
form.

Since
JSON-LD
is
intended
to
be
a
pure
data
exchange
format
for
directed
graphs,
the
serialization
should
not
be
passed
through
a
code
execution
mechanism
such
as
JavaScript's
eval()
function.
It
is
recommended
that
a
conforming
parser
does
not
attempt
to
directly
evaluate
the
JSON-LD
serialization
and
instead
purely
parse
the
input
into
a
language-native
data
structure.

Any
programming
environment
that
requires
the
exchange
of
directed
graphs.
Implementations
of
JSON-LD
have
been
created
for
JavaScript,
Python,
Ruby,
PHP
and
C++.

Additional
information:

Magic
number(s):

Not
Applicable

File
extension(s):

.jsonld

Macintosh
file
type
code(s):

TEXT

Person
&
&
email
address
to
contact
for
further
information:

Manu
Sporny
<msporny@digitalbazaar.com>

Intended
usage:

Common

Restrictions
on
usage:

None

Author(s):

Manu
Sporny,
Gregg
Kellogg,
Dave
Longley

Change
controller:

W3C

D.
E.
Acknowledgements

The
editors
would
like
to
thank
Mark
Birbeck,
who
provided
a
great
deal
of
the
initial
push
behind
the
JSON-LD
work
via
his
work
on
RDFj,
Dave
Longley,
Dave
Lehn
and
Mike
Johnson
who
reviewed,
provided
feedback,
and
performed
several
implementations
of
the
specification,
and
Ian
Davis,
who
created
RDF/JSON.
Thanks
also
to
Nathan
Rixham,
Bradley
P.
Allen,
Kingsley
Idehen,
Glenn
McDonald,
Alexandre
Passant,
Danny
Ayers,
Ted
Thibodeau
Jr.,
Olivier
Grisel,
Niklas
Lindström,
Markus
Lanthaler,
and
Richard
Cyganiak
for
their
input
on
the
specification.
Another
huge
thank
you
goes
out
to
Dave
Longley
who
designed
many
of
the
algorithms
used
in
this
specification,
including
the
normalization
algorithm
which
was
a
monumentally
difficult
design
challenge.