This document is also available in this non-normative format: diff to previous version .
This document is licensed under a Creative Commons Attribution 3.0 License .
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.
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.
This document is an experimental work in progress.
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
lightweight
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
simply
adding
context
in
a
way
that
is
either
in-band
or
out-of-band.
referencing
a
context.
The
syntax
is
designed
to
not
disturb
already
deployed
systems
running
on
JSON,
but
provide
a
smooth
upgrade
path
from
JSON
to
JSON
JSON-LD
with
added
semantics.
Finally,
the
format
is
intended
to
be
easy
to
parse,
efficient
to
generate,
convertible
to
RDF
in
one
pass,
and
to
require
a
very
small
memory
footprint
in
order
to
operate.
This document is a detailed specification for a serialization of Linked Data in JSON. The document is primarily intended for the following audiences:
This specification does not describe the processing algorithms and programming interfaces, for those see [ JSON-LD-API ].
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:
The
Dublin
Core
vocabulary
(abbreviation:
dc
,
e.g.,
dc:title
)
The
Friend
of
a
Friend
vocabulary
(abbreviation:
foaf
,
e.g.,
foaf:knows
)
The
RDF
vocabulary
(abbreviation:
rdf
,
e.g.,
rdf:type
)
The
XSD
vocabulary
(abbreviation:
xsd
,
e.g.,
xsd:integer
)
JSON
[
RFC4627
]
defines
several
terms
which
are
used
throughout
this
document:
JSON-LD specifies a number of syntax tokens and keywords that are using in all algorithms described in this section:
@context
@base
@id
@vocab
@language
@language
@type
@datatype
@value
:
There are a number of ways that one may participate in the development of this specification:
The following section outlines the design goals and rationale behind the JSON-LD markup language.
A number of design considerations were explored during the creation of this markup language:
An Internationalized Resource Identifier ( IRI ), as described in [ RFC3987 ], is a mechanism for representing unique identifiers on the web. In Linked Data , an IRI is commonly used for expressing a subject , a property or an object .
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,
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:
{
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"avatar": "http://twitter.com/account/profile_image/manusporny"
}
In
JSON-LD,
a
context
is
used
to
map
term
s,
i.e.,
keys
and
with
associated
values
in
an
JSON
document,
to
IRI
s.
A
term
is
a
short
word
that
may
be
expanded
to
an
IRI
.
A
term
must
have
the
lexical
form
of
NCName
(see
[
XML-NAMES
]),
or
be
an
empty
string.
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.
The
value
of
a
term
mapping
must
be
a
simple
string
with
the
lexical
form
of
an
absolute
IRI
.
These Linked Data term s are typically collected in a context document that would look something like this:
{
"@context": {
"name": "http://xmlns.com/foaf/0.1/name",
"homepage": "http://xmlns.com/foaf/0.1/homepage",
"avatar": "http://xmlns.com/foaf/0.1/avatar"
}
}
This context document can then be used in an JSON-LD document by adding a single line. The JSON markup as shown in the previous section could be changed as follows to link to the context document:
{
"@context": "http://example.org/json-ld-contexts/person",
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"avatar": "http://twitter.com/account/profile_image/manusporny"
}
The
additions
above
transform
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.
{
"@context": {
"name": "http://xmlns.com/foaf/0.1/name",
"homepage": "http://xmlns.com/foaf/0.1/homepage",
"avatar": "http://xmlns.com/foaf/0.1/avatar"
},
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"avatar": "http://twitter.com/account/profile_image/manusporny"
}
Contexts
may
be
used
at
any
time
a
JSON
object
is
defined,
and
a
JSON
object
may
specify
multiple
contexts,
to
be
processed
in
order,
for
example
to
include
standard
prefix
definitions
along
with
a
local
language
definition
used
to
set
the
language
of
plain
literal
s:
an
author-specific
prefix
definition.
The set of contexts defined within a specific JSON Object is termed a local context . The active context refers to the accumulation of local context s that are in scope at a specific point within the document. The following example specifies an external context and then layers a local context on top of the external context:
{
"@context": [
"http://example.org/json-ld-contexts/person",
{
"pic": "http://xmlns.com/foaf/0.1/avatar"
}
],
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"pic": "http://twitter.com/account/profile_image/manusporny"
}
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.
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,
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.
If
a
set
of
terms
term
s
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:
{
"http://xmlns.com/foaf/0.1/name": "Manu Sporny",
"http://xmlns.com/foaf/0.1/homepage": "http://manu.sporny.org"
"http://rdfs.org/sioc/ns#avatar": "http://twitter.com/account/profile_image/manusporny"
}
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.
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.
Expressing IRI s are fundamental to Linked Data as that is how most subject s and many object are named. IRI s can be expressed in a variety of different ways in JSON-LD.
@id
or
@type
.
@iri
@id
.
IRIs may be represented as an absolute IRI , a term , or a prefix :suffix construct.
IRIs can be expressed directly in the key position like so:
{
...
"http://xmlns.com/foaf/0.1/name": "Manu Sporny",
...
}
In
the
example
above,
the
key
http://xmlns.com/foaf/0.1/name
is
interpreted
as
an
IRI
,
as
opposed
to
being
interpreted
as
a
string.
Term
expansion
occurs
for
IRIs
if
the
value
matches
a
term
is
defined
within
the
active
context
:
{
"@context": { "name": "http://xmlns.com/foaf/0.1/name" },
...
"name": "Manu Sporny",
...
}
Prefix
es
are
expanded
when
used
in
keys:
the
form
of
the
value
is
prefix:suffix
,
and
the
prefix
matches
a
term
defined
within
the
active
context
:
{
"@context": { "foaf": "http://xmlns.com/foaf/0.1/" },
...
"foaf:name": "Manu Sporny",
...
}
Term s are case sensitive, and must be matched using a case-sensitive comparison.
foaf:name
above
will
automatically
expand
out
to
the
IRI
http://xmlns.com/foaf/0.1/name
.
See
Prefixes
for
more
details.
An
IRI
is
generated
when
a
value
is
associated
with
a
key
using
the
keyword:
@iri
@id
{
...
"homepage": { "@id": "http://manu.sporny.org" }
...
}
Specifying
a
JSON
Object
with
an
@id
key
is
used
to
represent
an
IRI
,
but
it
also
is
the
mechanism
by
which
a
subject
is
defined.
This
is
an
example
of
chaining
in
JSON-LD,
an
issue
covered
further
in
Chaining
.
If
type
coercion
rules
are
specified
in
the
@context
for
a
particular
vocabulary
term,
term
or
property
IRI
,
an
IRI
is
generated:
{
"@context": {
...
"homepage": {
"@id": "http://xmlns.com/foaf/0.1/homepage", "@type": "@id"
}
...
}
...
"homepage": "http://manu.sporny.org/",
...
}
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
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
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
@id
{
...
"@id": "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
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
@id
is
processed
before
they
can
create
valid
triples.
This
creates
a
memory
and
complexity
burden
for
one-pass
processors.
@subject
@id
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).
To be Linked Data , types must be uniquely identified by an IRI .
{
...
"@id": "http://example.org/people#joebob",
"@type": "http://xmlns.com/foaf/0.1/Person",
...
}
Regular text strings, also referred to as plain literal s, are easily expressed using regular JSON string s.
{
...
"name": "Mark Birbeck",
...
}
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.
{
...
"name":
{
"@value": "花澄",
"@language": "ja"
}
...
}
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.
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:
@coerce
@type
@context
section.
The
first
example
uses
the
keyword
to
express
a
typed
literal:
@coerce
@type
{
"@context": {
"xsd": "http://www.w3.org/2001/XMLSchema#",
"modified": {
"@id": "http://purl.org/dc/terms/modified",
"@type": "xsd:dateTime"
}
}
...
"modified": "2010-05-29T14:17:39+02:00",
...
}
The second example uses the expanded form for specifying objects:
{
...
"modified": {
"@value": "2010-05-29T14:17:39+02:00",
"@type": "xsd:dateTime"
}
...
}
Both
examples
above
would
generate
an
object
with
the
literal
value
of
2010-05-29T14:17:39+02:00
and
the
datatype
of
http://www.w3.org/2001/XMLSchema#dateTime
.
The third example uses a built-in native JSON type, a number , to express a datatype:
{
...
"@id": "http://example.org/people#joebob",
"age": 31
...
}
The
example
above
would
generate
is
really
just
a
shorthand
for
the
following
triple:
following:
{
...
"@id": "http://example.org/people#joebob",
"age": {
"@value": "31",
"@type": "http://www.w3.org/2001/XMLSchema#integer"
}
...
}
The
@type
keyword
is
also
used
to
associate
a
type
with
an
object.
Although
the
same
keyword
is
used
in
both
places,
the
concept
of
object
type
and
literal
datatype
are,
in
fact,
different.
This
is
similar
to
object-oriented
programming
languages
where
both
scalar
and
structured
types
use
the
same
class
inheritance
mechanism,
even
though
scalar
types
and
structured
types
are
inherently
different.
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 .
{
...
"@id": "http://example.org/people#joebob",
"nick": [ "joe", "bob", "jaybee" ],
...
}
The markup shown above would generate the following triples:
<http://example.org/people#joebob>
<http://xmlns.com/foaf/0.1/nick>
"joe" .
<http://example.org/people#joebob>
<http://xmlns.com/foaf/0.1/nick>
"bob" .
<http://example.org/people#joebob>
<http://xmlns.com/foaf/0.1/nick>
"jaybee"
.
Multiple
typed
literal
s
may
also
be
expressed
using
the
expanded
form
for
objects:
{
"@id": "http://example.org/articles/8",
"dc:title":
[
{"@value": "Das Kapital", "@language": "de"},
{"@value": "Capital", "@language": "en"}
]
}
The markup shown above would generate the following triples:
<http://example.org/articles/8>
<http://purl.org/dc/terms/title>
"Das Kapital"@de .
<http://example.org/articles/8>
<http://purl.org/dc/terms/title>
"Capital"@en
.
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:
{
...
"@id": "http://example.org/people#joebob",
"nick": [ "joe", "bob", "jaybee" ],
...
}
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:
{
...
"@subject": "http://example.org/people#joebob",
"nick": ,
,
,
,
,
...
}
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:
{
...
"@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
through
normalization
and
RDF
conversion
alternate
representations
as
described
in
[
JSON-LD-API
].
If
every
use
of
a
given
multi-valued
property
is
a
list,
this
may
be
abbreviated
by
adding
an
@coerce
@type
term:
coercion
:
{
"@context": {
...
"nick": {
"@id": "http://xmlns.com/foaf/0.1/nick",
"@list": true
}
},
...
"@id": "http://example.org/people#joebob",
"nick": [ "joe", "bob", "jaybee" ],
...
}
The
@list
keyword
can
be
used
List
coercion
is
specified
within
an
expanded
term
definition
using
the
@coerce
@list
section
key.
The
value
of
a
this
key,
if
present,
must
be
.
This
indicates
that
array
values
of
keys
coerced
as
@context
true
@list
to
cause
value
arrays
are
to
be
coerced
into
an
ordered
list.
serialized
as
a
List
.
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.
Authors
may
choose
to
declare
JSON-LD
allows
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
s
to
be
specified
in
a
relative
form.
For
subject
and
valid
JSON-LD
document.
The
referenced
document
must
have
a
top-level
JSON
Object
.
The
value
of
any
@context
key
within
that
object
IRIs,
relative
IRIs
are
resolved
against
is
substituted
for
the
IRI
within
the
referencing
document
base
using
section
5.1
Establishing
to
have
the
same
effect
as
if
the
value
were
specified
inline
within
the
referencing
document.
The following example demonstrates the use of an external context:
{
"@context": "http://example.org/json-ld-contexts/person",
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"avatar": "http://twitter.com/account/profile_image/manusporny"
}
Authors
may
also
import
multiple
contexts
or
a
Base
URI
combination
of
[
RFC3986
external
and
local
contexts
by
specifying
a
list
of
contexts:
{
"@context":
[
"http://example.org/json-ld-contexts/person",
{ "foaf": "http://xmlns.com/foaf/0.1/" },
"http://example.org/json-ld-contexts/event"
]
"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
mappings
within
the
context
].
This
value
may
s
must
be
explicitly
set
with
overwritten
on
a
last-defined-overrides
basis.
The
context
list
must
contain
either
de-referenceable
IRI
using
s
or
JSON
Object
s
that
conform
to
the
@base
keyword.
context
syntax
as
described
in
this
document.
For
example,
if
a
JSON-LD
document
was
retrieved
from
http://manu.sporny.org/
,
relative
IRIs
would
resolve
against
that
URI:
An
author
may
nest
contexts
within
JSON
object
s,
with
the
more
deeply
nested
contexts
overriding
the
values
in
previously
defined
contexts:
{
"@context":
{
"name": "http://example.com/person#name",
"details": "http://example.com/person#details"
},
"name": "Markus",
...
"details":
{
"@context": { "name": "http://example.com/organization#name" },
"name": "Acme, Ltd."
}
}
This
document
uses
an
empty
@subject
,
which
resolves
to
In
the
document
base.
However,
if
example
above,
the
document
name
prefix
is
moved
to
a
different
location,
overridden
in
the
subject
IRI
would
change.
To
prevent
this,
more
deeply
nested
details
structure.
Note
that
this
is
rarely
a
good
authoring
practice
and
is
typically
used
when
the
JSON
object
has
legacy
applications
using
the
structure
of
the
object.
External
JSON-LD
context
documents
may
have
a
contain
extra
information
located
outside
of
the
@base
@context
mapping,
to
set
an
absolute
base
for
key,
such
as
documentation
about
the
document
prefix
es
declared
in
spite
the
document.
When
importing
a
@context
value
from
an
external
JSON-LD
context
document,
any
extra
information
contained
outside
of
where
it
actually
is
retrieved
from.
It
the
@context
value
must
have
a
value
of
be
discarded.
It
is
also
recommended
that
a
simple
string
human-readable
document
encoded
in
HTML+RDFa
[
HTML-RDFA
with
]
or
other
Linked
Data
compatible
format
is
served
as
well
to
explain
the
lexical
form
correct
usage
of
an
absolute
IRI
.
the
JSON-LD
context
document.
It
is
often
common
that
all
types
and
properties
come
from
the
same
vocabulary.
JSON-LD
provides
Within
a
way
context
definition,
term
s
may
be
defined
using
an
expanded
notation
to
set
a
base
URI
allow
for
additional
information
associated
with
the
term
to
be
used
for
all
properties
specified
(see
Type
Coercion
and
types
that
aren't
based
on
terms,
prefixes
or
absolute
IRIs.
Much
like
the
@base
keyword,
Lists
).
Instead
of
using
a
string
representation
of
an
IRI
,
the
IRI
is
specified
using
an
object
having
an
@vocab
@id
keyword
can
key.
The
value
of
this
key
must
be
used
to
set
a
base
IRI
to
use
for
all
types
and
properties
that
don't
otherwise
resolve
to
an
absolute
IRI
.
{
,
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"avatar": "http://twitter.com/account/profile_image/manusporny"
.
{
"@context": {
"name": {"@id": "http://xmlns.com/foaf/0.1/name"},
"homepage": {"@id": "http://xmlns.com/foaf/0.1/homepage"},
"avatar": {"@id": "http://xmlns.com/foaf/0.1/avatar"}
},
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"avatar": "http://twitter.com/account/profile_image/manusporny"
}
There is an open issue ( #43 ) on allowing non-terms in the key position to allow coercion to be specified for CURIEs or absolute IRIs.
JSON-LD allows a default value to use as the language for plain literal s. It is commonly the case that documents are written using a single language. As described in String Internationalization , a language-tagged literal may be specified as follows:
{
...
"name":
{
"@value": "花澄",
"@language": "ja"
}
...
}
By
specifying
It
is
also
possible
to
apply
a
particular
language
code
to
all
plain
literals
by
setting
the
@language
within
key
in
the
@context
:
{
"@context:"
{
"@language": "ja"
},
...
"name": "花澄"
"occupation": "科学者"
...
}
The
example
above
would
generate
a
context
,
multiple
language-tagged
literals
may
be
marked
up
plain
literal
for
花澄
and
科学者
and
associate
the
ja
language
code
with
each
literal.
It
is
possible
to
override
the
default
language
by
using
the
expanded
form
of
a
simple
string
form:
literal:
{
"@context:"
{
"@language": "ja"
},
...
"name": "花澄"
"occupation":
{
"@value": "Scientist",
"@language": "en"
}
...
}
It
is
also
possible
to
override
the
default
language
and
specify
a
plain
literal
by
omitting
the
@language
tag
when
expressing
the
expanded
literal
value:
{
"@context:"
{
"@language": "ja"
},
...
"name": "花澄"
"occupation":
{
"@value": "Ninja"
}
...
}
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
suffix
separated
by
a
colon
(
:
).
The
prefix
is
a
term
taken
from
the
active
context
,
and
is
a
short
string
that
identifies
identifying
a
particular
Web
vocabulary.
IRI
in
a
JSON-LD
document.
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
absolute
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,
IRI
,
the
developer
can
instead
use
the
prefix
in
their
JSON-LD
markup.
To
generate
an
IRI
out
of
a
prefix:suffix
construct,
the
value
is
first
split
into
a
prefix
and
suffix
at
the
first
occurrence
of
a
colon
(
:
).
If
the
active
context
contains
a
term
mapping
for
prefix
,
an
IRI
is
generated
by
prepending
the
mapped
prefix
to
the
(possibly
empty)
suffix
using
textual
concatenation.
If
no
prefix
mapping
is
defined,
the
value
is
used
directly
as
an
IRI
.
If
the
prefix
is
an
underscore
(
_
),
the
IRI
remains
unchanged.
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
.
Consider the following example:
{
"@context": {
"dc": "http://purl.org/dc/elements/1.1/",
"ex": "http://example.org/vocab#"
},
"@id": "http://example.org/library",
"@type": "ex:Library",
"ex:contains": {
"@id": "http://example.org/library/the-republic",
"@type": "ex:Book",
"dc:creator": "Plato",
"dc:title": "The Republic",
"ex:contains": {
"@id": "http://example.org/library/the-republic#introduction",
"@type": "ex:Chapter",
"dc:description": "An introductory chapter on The Republic.",
"dc:title": "The Introduction"
}
}
}
In
this
example,
two
different
vocabularies
are
referred
to
using
prefixes.
Those
prefixes
are
then
used
as
type
and
property
values
using
the
prefix:suffix
notation.
Prefixes,
also
known
as
CURIEs,
are
defined
more
formally
in
RDFa
Core
1.1,
Section
6
"CURIE
"CURIE
Syntax
Definition"
Definition"
[
RDFA-CORE
].
JSON-LD
does
not
support
the
square-bracketed
CURIE
syntax
as
the
mechanism
is
not
required
to
disambiguate
IRI
s
in
a
JSON-LD
document
like
it
is
in
HTML
documents.
To
be
consistent
with
JSON-LD
in
general,
anywhere
an
IRI
is
expected,
normal
IRI
expansion
rules
apply
(see
IRIs
).
Within
a
context
definition,
this
can
mean
that
terms
defined
within
a
given
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
literal
s:
{
"@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.
Term s may also be used when defining the IRI of another term :
{
"@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"}
},
...
}
The only exception is that terms must not be used in a circular manner, meaning that the definition of term-1 may not depend on the definition of term-2 if term-2 also depends on term-1 . For example, the following context definition is illegal:
{
"@context":
{
"term1": {"@id": "term2:foo"},
"term2": {"@id": "term1:bar"}
},
...
}
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": 5.3,
"measure:cups": 5.3e0,
// The following value is automatically converted to a type of xsd:double as well
"space:astronomicUnits": 6.5e73,
// The following value should never be converted to a language-native type
"measure:stones": { "@value": "4.8", "@type": "xsd:decimal" },
// This value is automatically converted to having a type of xsd:integer
"chem:protons": 12,
// This value is automatically converted to having a type of xsd:boolean
"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.
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
IRI
s
to
property
types.
Using
type
coercion,
one
may
convert
simple
JSON
value
representation
is
preserved
without
requiring
the
data
type
to
properly
typed
RDF
data.
be
specified
with
each
usage.
Type
coercion
is
specified
within
an
expanded
term
definition
using
the
@type
key.
The
values
of
this
key
represent
datatype
IRIs
and
must
take
the
form
of
term
,
prefix
:suffix,
absolute
IRI
or
the
keyword
@id
.
Specifying
@id
indicates
that
within
the
body
of
a
JSON-LD
document,
string
values
of
keys
coerced
as
@id
are
to
be
interpreted
as
IRI
s,
or
labeled
nodes
and
are
subject
to
IRI
expansion.
Terms
or
prefixes
used
as
the
value
of
a
@type
key
may
be
defined
within
the
same
context.
The
example
below
demonstrates
how
a
JSON-LD
author
can
coerce
values
to
plain
literal
s,
typed
literal
s
s,
IRIs
and
IRIs.
lists.
{
"@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"}
},
"name": "John Smith",
"age": "41",
"homepage": "http://example.org/home/"
}
The
example
above
would
generate
the
following
triples:
turtle:
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> . [ foaf:name "John Smith"; foaf:age "41"^^xsd:integer; foaf:homepage <http://example.org/home> ] .
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:
{
...
"name": "Manu Sporny",
"knows": {
"@type": "Person",
"name": "Gregg Kellogg",
}
...
}
An object definition, like the one used above, may be used as a JSON value at any point in JSON-LD.
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
keyword.
However,
authors
may
provide
identifiers
for
unlabeled
nodes
by
using
the
special
@subject
@id
_
(underscore)
prefix
.
This
allows
to
reference
the
node
locally
within
the
document
but
not
in
an
external
document.
{
...
"@id": "_: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
.
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
.
{
"@context":
{
"url": "@id",
"a": "@type",
"name": "http://schema.org/name"
},
"url": "http://example.com/about#gregg",
"a": "http://schema.org/Person",
"name": "Gregg Kellogg"
}
In
the
example
above,
the
and
@subject
@id
@type
keywords
have
been
given
the
aliases
url
and
a
,
respectively.
JSON-LD
is
a
specification
for
representing
Linked
Data
in
JSON.
A
common
way
of
working
with
Linked
Data
is
through
RDF
,
the
Resource
Description
Framework.
RDF
can
be
expressed
using
JSON-LD
by
associating
JSON-LD
concepts
such
as
and
@subject
@id
@type
with
the
equivalent
IRI
s
in
RDF.
Further
information
about
RDF
may
be
found
in
[
RDF-PRIMER
].
Some
examples
of
encoding
RDF
into
JSON-LD
may
be
found
in
Appendix
A
.
Details
of
transforming
JSON-LD
into
RDF
are
defined
in
[
JSON-LD-API
].
A.
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
RDF/XML,
Turtle,
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.
Details
of
transforming
JSON-LD
into
RDF
are
defined
in
[
JSON-LD-API
].
The following are examples of representing RDF as expressed in [ TURTLE ] into JSON-LD.
The
JSON-LD
context
has
direct
equivalents
for
the
Turtle
@base
and
@prefix
expressions:
declaration:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . <http://manu.sporny.org/#me> a foaf:Person; foaf:name "Manu Sporny"; foaf:homepage<><http://manu.sporny.org/> .
{
"@context": {
"foaf": "http://xmlns.com/foaf/0.1/"
},
"@id": "http://manu.sporny.org/#me",
"@type": "foaf:Person",
"foaf:name": "Manu Sporny",
"foaf:homepage": { "@id": "http://manu.sporny.org/" }
}
JSON-LD
has
no
equivalent
for
the
Turtle
@base
declaration.
Authors
could,
of
course,
use
a
prefix
definition
to
resolve
relative
IRIs.
For
example,
an
empty
prefix
could
be
used
to
get
a
similar
effect
to
@base
:
{
"@context": {
"": "http://manu.sporny.org/",
"foaf": "http://xmlns.com/foaf/0.1/"
},
"@id": ":#me",
"@type": "foaf:Person",
"foaf:name": "Manu Sporny",
"foaf:homepage": { "@id": ":" }
}
Both Turtle and JSON-LD allow chaining of objects, although Turtle only allows chaining of objects which use nlank node identifiers.
@base <http://manu.sporny.org/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . <#me> a foaf:Person; foaf:name "Manu Sporny"; foaf:knows [ a foaf:Person; foaf:name"Gregg Kellogg""Gregg Kellogg" ] .
{
"@context": {
"": "http://manu.sporny.org/",
"foaf": "http://xmlns.com/foaf/0.1/"
},
"@id": ":#me",
"@type": "foaf:Person",
"foaf:name": "Manu Sporny",
"foaf:knows": {
"@type": "foaf:Person",
"foaf:name": "Gregg Kellogg"
}
}
Both JSON-LD and Turtle can represent sequential lists of values.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . <http://example.org/people#joebob> a foaf:Person; foaf:name "Joe Bob"; foaf:nick ("joe" "bob" "jaybee")"joe" "bob" "jaybee") .
{
"@context": {
"foaf": "http://xmlns.com/foaf/0.1/"
},
"@id": "http://example.org/people#joebob",
"@type": "foaf:Person",
"foaf:name": "Joe Bob",
"foaf:nick": { "@list": [ "joe", "bob", "jaybe" ] }
}
The following example describes three people with their respective names and homepages.
<div prefix="foaf: http://xmlns.com/foaf/0.1/"> <ul> <li typeof="foaf:Person"> <a rel="foaf:homepage" href="http://example.com/bob/" property="foaf:name" >Bob</a> </li> <li typeof="foaf:Person"> <a rel="foaf:homepage" href="http://example.com/eve/" property="foaf:name" >Eve</a> </li> <li typeof="foaf:Person"> <a rel="foaf:homepage" href="http://example.com/manu/" property="foaf:name" >Manu</a> </li> </ul> </div>
An example JSON-LD implementation is described below, however, there are other ways to mark-up this information such that the context is not repeated.
{
"@context": { "foaf": "http://xmlns.com/foaf/0.1/" },
"@id": [
{
"@id": "_:bnode1",
"@type": "foaf:Person",
"foaf:homepage": "http://example.com/bob/",
"foaf:name": "Bob"
},
{
"@id": "_:bnode2",
"@type": "foaf:Person",
"foaf:homepage": "http://example.com/eve/",
"foaf:name": "Eve"
},
{
"@id": "_:bnode3",
"@type": "foaf:Person",
"foaf:homepage": "http://example.com/manu/",
"foaf:name": "Manu"
}
]
}
The following example uses a simple Microformats hCard example to express how the Microformat is represented in JSON-LD.
<div class="vcard"> <a class="url fn" href="http://tantek.com/">Tantek �elik</a> </div>
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
.
{
"@context":
{
"vcard": "http://microformats.org/profile/hcard#vcard",
"url": {"@id": "http://microformats.org/profile/hcard#url", "@type": "@id"},
"fn": "http://microformats.org/profile/hcard#fn"
},
"@id": "_:bnode1",
"@type": "vcard",
"url": "http://tantek.com/",
"fn": "Tantek �elik"
}
The
Microdata
microdata
example
below
expresses
book
information
as
a
Microdata
microdata
Work
item.
<dl itemscope
itemtype="http://purl.org/vocab/frbr/core#Work"
itemid="http://purl.oreilly.com/works/45U8QJGZSQKDH8N">
<dt>Title</dt>
<dd><cite itemprop="http://purl.org/dc/terms/title">Just a Geek</cite></dd>
<dt>By</dt>
<dd><span itemprop="http://purl.org/dc/terms/creator">Wil Wheaton</span></dd>
<dt>Format</dt>
<dd itemprop="http://purl.org/vocab/frbr/core#realization"
itemscope
itemtype="http://purl.org/vocab/frbr/core#Expression"
itemid="http://purl.oreilly.com/products/9780596007683.BOOK">
<link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/BOOK">
Print
</dd>
<dd itemprop="http://purl.org/vocab/frbr/core#realization"
itemscope
itemtype="http://purl.org/vocab/frbr/core#Expression"
itemid="http://purl.oreilly.com/products/9780596802189.EBOOK">
<link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/EBOOK">
Ebook
</dd>
</dl>
[
{
"@id": "http://purl.oreilly.com/works/45U8QJGZSQKDH8N",
"@type": "http://purl.org/vocab/frbr/core#Work",
"http://purl.org/dc/terms/title": "Just a Geek",
"http://purl.org/dc/terms/creator": "Whil Wheaton",
"http://purl.org/vocab/frbr/core#realization":
[ "http://purl.oreilly.com/products/9780596007683.BOOK", "http://purl.oreilly.com/products/9780596802189.EBOOK" ]
},
{
"@id": "http://purl.oreilly.com/products/9780596007683.BOOK",
"@type": "http://purl.org/vocab/frbr/core#Expression",
"http://purl.org/dc/terms/type": "http://purl.oreilly.com/product-types/BOOK"
},
{
"@id": "http://purl.oreilly.com/products/9780596802189.EBOOK",
"@type": "http://purl.org/vocab/frbr/core#Expression",
"http://purl.org/dc/terms/type": "http://purl.oreilly.com/product-types/EBOOK"
}
]
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.
This
document
is
an
experimental
work
in
progress.
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
JSON-LD
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.
2.2
Linked
Data
The
following
definition
for
Linked
Data
is
the
one
that
will
be
used
for
this
specification.
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.
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:
You can use these vocabularies in combination, like so:
{
"@type": "foaf:Person",
"foaf:name": "Manu Sporny",
"foaf:homepage": "http://manu.sporny.org/",
"sioc:avatar": "http://twitter.com/account/profile_image/manusporny"
}
Developers
can
also
specify
their
own
Vocabulary
documents
by
modifying
the
active
context
in-line
using
the
@context
keyword,
like
so:
{
"@context": { "myvocab": "http://example.org/myvocab#" },
"@type": "foaf:Person",
"foaf:name": "Manu Sporny",
"foaf:homepage": "http://manu.sporny.org/",
"sioc:avatar": "http://twitter.com/account/profile_image/manusporny",
"myvocab:personality": "friendly"
}
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.
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.
form
compacted
,
expanded
,
normalized
.
application/json
MIME
media
type.
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.
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,
Lindstr�m,
Markus
Lanthaler,
and
Richard
Cyganiak
for
their
input
on
the
specification.