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
syntax
that
can
be
used
to
express
Linked
Data.
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, and 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:
dc
,
e.g.,
dc:title
)
foaf
,
e.g.,
foaf:knows
)
rdf
,
e.g.,
rdf:type
)
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
@vocab
@coerce
@literal
@iri
@language
@datatype
:
@subject
@type
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:
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.
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,
but
rather
ensures
that
keys
and
values
can
be
mapped
to
IRIs
if
the
developer
desires
to
transform
their
data
into
Linked
Data.
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
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:
{
"@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:
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.
{
"@context": [
"http://example.org/json-ld-contexts/person",
{
"@language": "en"
}
],
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"avatar": "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.
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,
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.
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.
The
referenced
document
must
have
a
top-level
JSON
Object
.
The
value
of
any
@context
key
within
that
object
is
substituted
for
the
IRI
within
the
referencing
document
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 combination of external and local contexts by specifying a list of contexts:
{
"@context": ["http://example.org/json-ld-contexts/person", "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 s must be overwritten on a last-defined-overrides basis. The context list must contain either de-referenceable IRI s 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.
If
a
set
of
terms
such
as,
name
,
homepage
,
and
avatar
,
are
defined
in
a
context,
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.
context
.
As
more
JSON-LD
features
are
used,
more
semantics
are
added
to
the
JSON
markup.
Expressing
IRIs
IRI
s
are
fundamental
to
Linked
Data
as
that
is
how
most
subject
s
and
many
object
are
named.
IRIs
IRI
s
can
be
expressed
in
a
variety
of
different
ways
in
JSON-LD.
@context
and
when
dealing
with
keys
that
start
with
the
@subject
character.
@subject
,
if
it
is
a
string
.
@type
.
@iri
keyword.
@coerce
rules
in
effect
for
a
key
named
@iri
.
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,
IRI
,
as
opposed
to
being
interpreted
as
a
string.
Term expansion occurs for IRIs if 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:
{
"@context": {"foaf": "http://xmlns.com/foaf/0.1/"},
...
"foaf:name": "Manu Sporny",
...
}
foaf:name
above
will
automatically
expand
out
to
the
IRI
http://xmlns.com/foaf/0.1/name
.
An
IRI
is
generated
when
a
value
is
associated
with
a
key
using
the
@iri
keyword:
{
...
"homepage": { "@iri": "http://manu.sporny.org" }
...
}
If
type
coercion
rules
are
specified
in
the
@context
for
a
particular
vocabulary
term,
an
IRI
is
generated:
{
"@context":
{
...
"@coerce":
{
"@iri": "homepage"
}
}
...
"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
IRIs
may
be
represented
as
an
absolute
IRI,
a
term
,
a
prefix
:
term
construct,
or
as
a
value
relative
to
@base
or
@vocab
.
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,
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.
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,
Data
,
types
must
be
uniquely
identified
by
an
IRI
.
{
...
"@subject": "http://example.org/people#joebob",
"@type": "http://xmlns.com/foaf/0.1/Person",
...
}
The example above would generate the following triple if the JSON-LD document is mapped to RDF (in N-Triples notation):
<http://example.org/people#joebob> <http://www.w3.org/1999/02/22-rdf-syntax-ns#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":
{
"@literal": "花澄",
"@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.
It
is
also
possible
to
set
a
language
to
use
within
a
@context
,
to
allow
specify
a
language
to
apply
to
all
plain
literal
s
within
the
scope
of
the
context
{
"@context:" {
"@language": "ja"
},
...
"name": "花澄"
...
}
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
keyword.
The
first
example
uses
the
@coerce
keyword
to
express
a
typed
literal:
{
"@context":
{
"modified": "http://purl.org/dc/terms/modified",
"dateTime": "http://www.w3.org/2001/XMLSchema#dateTime"
"@coerce":
{
"dateTime": "modified"
}
}
...
"modified": "2010-05-29T14:17:39+02:00",
...
}
The second example uses the expanded form for specifying objects:
{
...
"modified":
{
"@literal": "2010-05-29T14:17:39+02:00",
"@datatype": "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:
{
...
"@subject": "http://example.org/people#joebob",
"age": 31
...
}
The example above would generate the following triple:
<http://example.org/people#joebob> <http://xmlns.com/foaf/0.1/age> "31"^^<http://www.w3.org/2001/XMLSchema#integer> .
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 .
{
...
"@subject": "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:
{
...
"@subject": "http://example.org/articles/8",
"modified":
[
{
"@literal": "2010-05-29T14:17:39+02:00",
"@datatype": "dateTime"
},
{
"@literal": "2010-05-30T09:21:28-04:00",
"@datatype": "dateTime"
}
]
...
}
The markup shown above would generate the following triples:
<http://example.org/articles/8>
<http://purl.org/dc/terms/modified>
"2010-05-29T14:17:39+02:00"^^http://www.w3.org/2001/XMLSchema#dateTime .
<http://example.org/articles/8>
<http://purl.org/dc/terms/modified>
"2010-05-30T09:21:28-04:00"^^http://www.w3.org/2001/XMLSchema#dateTime
.
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
.
For
example,
assume
the
following
JSON-LD
input
document:
{
"@context":
{
"name": "http://xmlns.com/foaf/0.1/name",
"homepage": "http://xmlns.com/foaf/0.1/homepage",
"@coerce":
{
"@iri": "homepage"
}
},
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/"
}
Running
the
JSON-LD
Expansion
algorithm
against
the
JSON-LD
input
document
provided
above
would
result
Because
graphs
do
not
describe
ordering
for
links
between
nodes,
in
the
following
output:
{
"http://xmlns.com/foaf/0.1/name": "Manu Sporny",
"http://xmlns.com/foaf/0.1/homepage":
{
"@iri": "http://manu.sporny.org/"
}
}
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
contrast
to
plain
JSON,
multi-valued
properties
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
do
not
in
its
most
compact
form.
JSON-LD,
via
provide
an
ordering
of
the
API,
provides
a
way
to
compact
a
JSON-LD
document.
listed
objects.
For
example,
assume
consider
the
following
JSON-LD
input
simple
document:
{
...
"@subject": "http://example.org/people#joebob",
"nick": ["joe", "bob", "jaybee"],
...
}
Running
the
JSON-LD
Compaction
algorithm
given
the
context
supplied
above
against
the
JSON-LD
input
document
provided
above
would
result
This
results
in
three
triples
being
generated,
each
relating
the
following
output:
{
"@context":
{
"name": "http://xmlns.com/foaf/0.1/name",
"homepage": "http://xmlns.com/foaf/0.1/homepage",
"@coerce":
{
"@iri": "homepage"
}
},
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/"
}
The
compaction
algorithm
also
enables
the
developer
subject
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.
individual
object,
with
no
inherent
order.
A
JSON-LD
document
is
a
representation
To
preserve
the
order
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
objects,
RDF-based
languages,
such
as
JSON
object
[
TURTLE
s.
While
mapping
a
graph
to
a
tree
can
be
done,
]
use
the
layout
concept
of
the
end
result
must
be
specified
an
rdf:List
(as
described
in
advance.
A
Frame
can
be
used
by
a
developer
on
a
JSON-LD
document
to
specify
a
deterministic
layout
for
[
RDF-SCHEMA
]).
This
uses
a
graph.
Framing
is
the
process
sequence
of
taking
a
JSON-LD
document,
which
expresses
unlabeled
nodes
with
properties
describing
a
graph
of
information,
and
applying
value,
a
null-terminated
next
property.
Without
specific
graph
layout
(called
a
Frame
).
The
syntactical
support,
this
could
be
represented
in
JSON-LD
document
below
expresses
a
library,
a
book
and
a
chapter:
as
follows:
{
...
"@subject": "http://example.org/people#joebob",
"nick": {,
"@first": "joe",
"@rest": {
"@first": "bob",
"@rest": {
"@first": "jaybee",
"@rest": "@nil"
}
}
}
},
...
}
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,
As
this
notation
is
rather
unwieldy
and
then
the
chapters
contained
notion
of
ordered
collections
is
rather
important
in
each
book.
To
achieve
that
layout,
the
developer
can
define
data
modeling,
it
is
useful
to
have
specific
language
support.
In
JSON-LD,
a
list
may
be
represented
using
the
following
frame
:
@list
keyword
as
follows:
{
...
"@subject": "http://example.org/people#joebob",
"foaf:nick": {"@list": ["joe", "bob", "jaybee"]},
...
}
When
This
describes
the
framing
algorithm
use
of
this
array
as
being
ordered,
and
order
is
run
against
the
previously
defined
JSON-LD
document,
paired
with
the
frame
maintained
through
normalization
and
RDF
conversion
as
described
in
[
JSON-LD-API
above,
the
following
JSON-LD
document
].
If
every
use
of
a
given
multi-valued
property
is
the
end
result:
a
list,
this
may
be
abbreviated
by
adding
an
@coerce
term:
{
"@context": {
...
"@coerce": {
"@list": ["foaf:nick"]
}
},
...
"@subject": "http://example.org/people#joebob",
"foaf:nick": ["joe", "bob", "jaybee"],
...
}
The
JSON-LD
framing
algorithm
allows
developers
to
query
by
example
and
force
@list
keyword
can
be
used
within
the
@coerce
section
of
a
specific
tree
layout
@context
to
a
JSON-LD
document.
cause
value
arrays
to
be
coerced
into
an
ordered
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
context
allows
IRI
s
in
external
documents
to
promote
re-use
of
contexts
as
well
as
reduce
be
specified
in
a
relative
form.
For
subject
and
object
IRIs,
relative
IRIs
are
resolved
against
the
size
document
base
using
section
5.1
Establishing
a
Base
URI
of
JSON-LD
documents.
In
order
to
use
an
external
context,
an
author
[
RFC3986
].
This
value
may
specify
an
IRI
to
be
explicitly
set
with
a
context
using
the
@base
keyword.
For
example,
if
a
valid
JSON-LD
document.
If
document
was
retrieved
from
http://manu.sporny.org/
,
relative
IRIs
would
resolve
against
that
URI:
{
"@subject": "about/",
"http://xmlns.com/foaf/0.1/name": "Manu Sporny",
"http://xmlns.com/foaf/0.1/homepage: ""
}
This
document
uses
an
IRI
is
specified,
empty
@subject
,
which
resolves
to
the
external
document
must
be
dereferenced
and
base.
However,
if
the
top-level
document
is
moved
to
a
different
location,
the
subject
IRI
would
change.
To
prevent
this,
a
context
may
have
a
@context
@base
key
in
mapping,
to
set
an
absolute
base
for
the
JSON
Object
document
in
spite
of
where
it
actually
is
retrieved
from.
It
must
be
overlayed
on
top
have
a
value
of
a
simple
string
with
the
current
active
context.
The
following
example
demonstrates
the
use
lexical
form
of
an
external
context:
absolute
IRI
.
{
"@context": { "@base": "http://manu.sporny.org/"},
"@subject": "about/",
"http://xmlns.com/foaf/0.1/name": "Manu Sporny",
"http://xmlns.com/foaf/0.1/homepage: ""
}
Authors
may
also
import
multiple
contexts
by
specifying
It
is
often
common
that
all
types
and
properties
come
from
the
same
vocabulary.
JSON-LD
provides
a
list
of
contexts
way
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
set
a
list
will
be
evaluated
in-order.
Duplicate
values
must
base
URI
to
be
overwritten
used
for
all
properties
and
types
that
aren't
based
on
a
last-defined-overrides
basis.
The
context
list
must
contain
either
de-referenceable
IRIs
terms,
prefixes
or
JSON
Object
absolute
IRIs.
Much
like
the
@base
keyword,
the
@vocab
keyword
can
be
used
to
set
a
base
IRI
s
to
use
for
all
types
and
properties
that
conform
don't
otherwise
resolve
to
the
context
syntax
as
described
in
this
document.
an
absolute
IRI
.
{
"@context": { "@vocab": "http://xmlns.com/foaf/1.0/" },
"@type": "Person",
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/",
"avatar": "http://twitter.com/account/profile_image/manusporny"
}
External
JSON-LD
context
documents
may
contain
extra
information
located
outside
of
the
@context
key,
such
allows
a
default
value
to
use
as
documentation
about
the
prefix
language
for
plain
literal
es
declared
in
the
document.
s.
It
is
also
recommended
commonly
the
case
that
documents
are
written
using
a
human-readable
document
encoded
single
language.
As
described
in
HTML+RDFa
[
HTML-RDFA
]
or
other
Linked
Data
compatible
format
is
served
String
Internationalization
,
a
language-tagged
literal
may
be
specified
as
well
to
explain
the
correct
usage
of
the
JSON-LD
follows:
{
...
"name":
{
"@literal": "花澄",
"@language": "ja"
}
...
}
By
specifying
@language
within
a
context
document.
,
multiple
language-tagged
literals
may
be
marked
up
using
a
simple
string
form:
{
"@context": { "@language": "ja"},
...
"name": "花澄"
...
}
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,
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
suffix
separated
by
a
colon
(
:
).
The
prefix
is
a
term
taken
from
the
active
context
,
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
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,
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.
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.
context
.
Consider the following example:
{
"@context": {
"dc": "http://purl.org/dc/elements/1.1/",
"ex": "http://example.org/vocab#"
},
"@subject": "http://example.org/library",
"@type": "ex:Library",
"ex:contains": {
"@subject": "http://example.org/library/the-republic",
"@type": "ex:Book",
"dc:creator": "Plato",
"dc:title": "The Republic",
"ex:contains": {
"@subject": "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
notation.
prefix:term
prefix:suffix
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
IRIs
IRI
s
in
a
JSON-LD
document
like
it
is
in
HTML
documents.
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": { "@literal": "4.8", "@datatype": "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
IRIs
IRI
s
to
property
types.
Using
type
coercion,
one
may
convert
simple
JSON
data
to
properly
typed
RDF
data.
The example below demonstrates how a JSON-LD author can coerce values to plain literal s, typed literal s and IRIs.
{
"@context":
{
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"name": "http://xmlns.com/foaf/0.1/name",
"age": "http://xmlns.com/foaf/0.1/age",
"homepage": "http://xmlns.com/foaf/0.1/homepage",
"@coerce":
{
"xsd:integer": "age",
"@iri": "homepage"
}
},
"name": "John Smith",
"age": "41",
"homepage": "http://example.org/home/"
}
The example above would generate the following triples:
_:bnode1
<http://xmlns.com/foaf/0.1/name>
"John Smith" .
_:bnode1
<http://xmlns.com/foaf/0.1/age>
"41"^^http://www.w3.org/2001/XMLSchema#integer .
_:bnode1
<http://xmlns.com/foaf/0.1/homepage>
<http://example.org/home/>
.
The
mechanism
for
type
coercion
is
still
being
debated.
It
may
be
that
the
key/value
positions
are
swapped,
yielding
a
@context
such
as
the
following:
{
"@context": {
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"name": "http://xmlns.com/foaf/0.1/name",
"age": "http://xmlns.com/foaf/0.1/age",
"homepage": "http://xmlns.com/foaf/0.1/homepage",
"currentProject": "http://xmlns.com/foaf/0.1/currentProject",
"@coerce": {
"age": "xsd:integer",
"homepage": "@iri",
"currentProject": ["@iri", "@list"]
}
},
...
}
An alternative is to merge the coercion into term definitions:
{
"@context":
{
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"name": "http://xmlns.com/foaf/0.1/name",
"age": {"@iri": "http://xmlns.com/foaf/0.1/age", "@coerce": "xsd:integer"},
"homepage": {"@iri": "http://xmlns.com/foaf/0.1/age", "@coerce": "@iri"},
"currentProject": {"@iri": "http://xmlns.com/foaf/0.1/currentProject", "@coerce": ["@iri", "@list"]},
},
...
}
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
@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": "_: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.
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.
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
.
{
"@context":
{
"url": "@subject",
"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
@subject
and
@type
keywords
have
been
given
the
aliases
url
and
a
,
respectively.
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
specification
for
representing
Linked
Data
in
a
deterministic
way.
This
is
easy
to
do
when
all
of
the
nodes
have
unique
names,
but
very
difficult
to
do
when
some
JSON.
A
common
way
of
the
nodes
are
not
labeled.
Normalization
working
with
Linked
Data
is
useful
when
comparing
two
graphs
against
one
another,
when
generating
a
detailed
list
of
differences
between
two
graphs,
through
RDF
,
the
Resource
Description
Framework.
RDF
can
be
expressed
using
JSON-LD
by
associating
JSON-LD
concepts
such
as
@subject
and
when
generating
a
cryptographic
digital
signature
for
information
contained
in
a
graph
or
when
generating
a
hash
of
@type
with
the
equivalent
IRI
s
in
RDF.
Further
information
contained
about
RDF
may
be
found
in
a
graph.
The
example
below
is
an
un-normalized
JSON-LD
document:
[
RDF-PRIMER
].
The
example
below
is
the
normalized
form
Some
examples
of
the
JSON-LD
document
above:
Whitespace
is
used
below
to
aid
readability.
The
normalization
algorithm
for
encoding
RDF
into
JSON-LD
removes
all
unnecessary
whitespace
may
be
found
in
the
fully
normalized
form.
[{
"@subject":
{
"@iri": "_:c14n0"
},
"http://xmlns.com/foaf/0.1/homepage":
{
"@iri": "http://manu.sporny.org/"
},
"http://xmlns.com/foaf/0.1/name": "Manu Sporny"
}]
Notice
how
all
Appendix
A
.
Details
of
the
term
s
have
been
expanded
and
sorted
transforming
JSON-LD
into
RDF
are
defined
in
alphabetical
order.
Also,
notice
how
the
subject
[
JSON-LD-API
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.
].
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.
The following are examples of representing RDF as expressed in [ TURTLE ] into JSON-LD.
The
JSON-LD
context
has
direct
equivalents
for
Turtle
@base
and
@prefix
expressions:
@base <http://manu.sporny.org/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . <#me> a foaf:Person; foaf:name "Manu Sporny"; foaf:homepage <> .
{
"@context": {
"@base": "http://manu.sporny.org/",
"foaf": "http://xmlns.com/foaf/0.1/"
},
"@subject": "#me",
"@type": "foaf:Person",
"foaf:name": "Manu Sporny",
"foaf:homepage": {"@iri": ""}
}
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" ] .
{
"@context": {
"@base": "http://manu.sporny.org/",
"foaf": "http://xmlns.com/foaf/0.1/"
},
"@subject": "#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") .
{
"@context": {
"@base": "http://manu.sporny.org/",
"foaf": "http://xmlns.com/foaf/0.1/"
},
"@subject": "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/"},
"@subject": [
{
"@subject": "_:bnode1",
"@type": "foaf:Person",
"foaf:homepage": "http://example.com/bob/",
"foaf:name": "Bob"
},
{
"@subject": "_:bnode2",
"@type": "foaf:Person",
"foaf:homepage": "http://example.com/eve/",
"foaf:name": "Eve"
},
{
"@subject": "_: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": "http://microformats.org/profile/hcard#url",
"fn": "http://microformats.org/profile/hcard#fn",
"@coerce": { "@iri": "url" }
},
"@subject": "_:bnode1",
"@type": "vcard",
"url": "http://tantek.com/",
"fn": "Tantek �elik"
}
The Microdata example below expresses book information as a 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>
Note
that
the
JSON-LD
representation
of
the
Microdata
information
stays
true
to
the
desires
of
the
Microdata
community
to
avoid
contexts
and
instead
refer
to
items
by
their
full
IRI.
IRI
.
[
{
"@subject": "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"]
},
{
"@subject": "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"
},
{
"@subject": "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"
}
]
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
,
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.
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.
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.