This document is also available in this non-normative format: diff to previous version
Copyright © 2010-2012 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark and document use rules apply.
JSON [ RFC4627 ] has proven to be a highly useful object serialization and messaging format. JSON-LD [ JSON-LD ] harmonizes the representation of Linked Data in JSON by outlining a common JSON representation format for expressing directed graphs; mixing both Linked Data and non-Linked Data in a single document. This document outlines an Application Programming Interface and a set of algorithms for programmatically transforming JSON-LD documents in order to make them easier to work with in programming environments like JavaScript, Python, and Ruby.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document has been under development for over 18 months in the JSON for Linking Data Community Group. The document has recently been transferred to the RDF Working Group for review, improvement, and publication along the Recommendation track. The specification has undergone significant development, review, and changes during the course of the last 18 months.
There
are
currently
several
independent
five
interoperable
implementations
of
this
specification.
There
is
a
fairly
complete
test
suite
and
a
live
JSON-LD
editor
that
is
capable
of
demonstrating
the
features
described
in
this
document.
While
development
on
implementations,
the
test
suite
and
the
live
editor
will
continue,
they
are
believed
to
be
mature
enough
to
be
integrated
into
a
non-production
system
at
this
point
in
time
with
the
expectation
that
they
could
be
used
in
a
production
system
within
the
next
year.
It is important for readers to understand that the scope of this document is currently under debate and new features may be added to the specification. Existing features may be modified heavily or removed entirely from the specification upon further review and feedback from the broader community. This is a work in progress and publication as a Working Draft does not require that all Working Group members agree on the content of the document.
There are a number of ways that one may participate in the development of this specification:
This document was published by the RDF Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-rdf-comments@w3.org ( subscribe , archives ). All feedback is welcome.
Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This section is non-normative.
This document is a detailed specification for an Application Programming Interface for the JSON-LD Syntax. The document is primarily intended for the following audiences:
To understand the basics in this specification you must first be familiar with JSON, which is detailed in [ RFC4627 ]. You must also understand the JSON-LD Syntax [ JSON-LD ], which is the base syntax used by all of the algorithms in this document. 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 ].
This section is non-normative.
The
JSON-LD
Syntax
specification
[
JSON-LD
]
outlines
a
language
that
may
be
used
to
express
Linked
Data
in
JSON.
Often,
it
is
useful
to
be
able
to
transform
JSON-LD
documents
so
that
they
may
be
easily
processed
in
a
various
programming
environment
like
JavaScript,
Python
or
Ruby.
environments.
There
are
four
major
types
of
transformation
that
are
discussed
in
this
document;
compaction,
document:
expansion,
compaction,
flattening,
and
RDF
conversion.
This section is non-normative.
Software algorithms are easiest to write when the data that they are processing have a regular form. Since information can be represented by JSON-LD in a variety of different ways, transforming all of these methods into a uniform structure allows the developer to simplify their processing code. For example, note that the following input uses only term s and is fairly compact:
{ "@context": { "name": "http://xmlns.com/foaf/0.1/name", "homepage": { "@id": "http://xmlns.com/foaf/0.1/homepage", "@type": "@id" } }, "@id": "http://me.markus-lanthaler.com/", "name": "Markus Lanthaler", "homepage": "http://www.markus-lanthaler.com/" }
The next input example uses one IRI to express a property, but leaves the rest of the information untouched.
{
"@context": {
"homepage": {
"@id": "http://xmlns.com/foaf/0.1/homepage",
"@type": "@id"
}
},
"@id": "http://me.markus-lanthaler.com/",
"http://xmlns.com/foaf/0.1/name": "Markus Lanthaler",
"homepage": "http://www.markus-lanthaler.com/"
}
While
both
inputs
are
valid
JSON-LD,
writing
a
program
to
handle
every
permutation
of
possible
inputs
can
be
difficult,
especially
when
the
incoming
context
could
change
as
well.
To
ensure
that
the
data
can
be
given
a
more
uniform
structure,
JSON-LD
introduces
the
notion
of
expansion.
Expansion
performs
two
important
operations.
The
first
is
to
expand
all
values
that
are
represent
IRI
IRIs
s
to
their
fully
expanded
form.
absolute
IRIs
.
The
second
is
to
express
all
values
in
expanded
form
.
To
transform
both
inputs
above
to
the
same
representation,
.
Running
the
developer
could
do
Expansion
algorithm
against
the
following:
function expansionCallback(output) {
console.log(output);
}
// the second parameter is 'null' because the developer does not wish to
// inject another context value
jsonld.expand(input1, null, expansionCallback);
jsonld.expand(input2,
null,
expansionCallback);
The
output
for
both
calls
examples
provided
above
will
be:
results
in
the
following
output:
[ { "@id": "http://me.markus-lanthaler.com/", "http://xmlns.com/foaf/0.1/name": [ { "@value": "Markus Lanthaler" } ], "http://xmlns.com/foaf/0.1/homepage": [ { "@id": "http://www.markus-lanthaler.com/" } ] } ]
Note
that
in
the
example
above;
output
above
all
context
definitions
have
been
removed,
all
term
terms
and
prefixes
have
been
expanded
to
full
IRIs,
absolute
IRIs
,
and
all
literal
JSON-LD
values
s
are
expressed
in
expanded
form
.
While
the
output
is
more
difficult
for
a
human
to
read,
it
is
easier
for
a
software
program
to
process
because
of
its
very
regular
structure.
This section is non-normative.
While
expansion
expands
a
given
input
as
much
as
possible,
compaction
performs
the
opposite
operation
-
expressing
operation:
it
expresses
a
given
input
as
succinctly
as
possible.
While
In
contrast
to
expansion
which
is
meant
to
produce
something
that
is
easy
to
process
by
software
programs,
compaction
is
meant
to
produce
something
that
is
easy
to
read
by
software
developers.
Compaction
uses
a
developer-supplied
context
to
compresses
all
compress
IRI
IRIs
s
to
term
terms
s
or
prefix
compact
IRIs
es,
and
compacts
all
literal
JSON-LD
values
s
expressed
in
expanded
form
to
simple
values
such
as
much
as
possible.
strings
and
numbers
.
The
For
example,
assume
the
following
example
expresses
expanded
JSON-LD
input
that
has
already
been
fully
expanded:
document:
[ { "@id": "http://me.markus-lanthaler.com/", "http://xmlns.com/foaf/0.1/name": [ { "@value": "Markus Lanthaler" } ], "http://xmlns.com/foaf/0.1/homepage": [ { "@id": "http://www.markus-lanthaler.com/" } ] } ]
A
developer
that
wants
to
transform
the
data
above
into
a
more
human-readable
form,
could
do
Additionally,
assume
the
following
using
the
developer-supplied
JSON-LD
API:
context
:
{ "@context": { "name": "http://xmlns.com/foaf/0.1/name", "homepage": { "@id": "http://xmlns.com/foaf/0.1/homepage", "@type": "@id" } } }jsonld.compact(expandedInput, "http://json-ld.org/contexts/person.jsonld", compactionCallback);
The
following
would
be
Running
the
Compaction
Algorithm
given
the
context
supplied
above
against
the
JSON-LD
input
document
provided
above
would
result
of
in
the
call
above:
following
output:
{ "@context": { "name": "http://xmlns.com/foaf/0.1/name", "homepage": { "@id": "http://xmlns.com/foaf/0.1/homepage", "@type": "@id" } }, "@id": "http://me.markus-lanthaler.com/", "name": "Markus Lanthaler", "homepage": "http://www.markus-lanthaler.com/" }
Note
that
all
of
the
term
IRIs
s
have
been
compressed
and
compacted
to
terms
as
specified
in
the
context
which
consequently
has
been
injected
into
the
output.
While
compacted
output
is
most
useful
to
humans,
it
can
often
also
be
carefully
used
to
generate
structures
that
are
easy
to
use
for
program
against.
Compaction
enables
developers
to
program
against
as
well.
map
any
expanded
document
into
an
application-specific
compacted
document.
While
the
context
provided
above
mapped
http://xmlns.com/foaf/0.1/name
to
name
,
it
could
have
also
have
been
mapped
to
any
other
term
provided
by
the
developer.
This section is non-normative.
While expansion ensures that a document is in a uniform structure, flattening goes a step further and ensures that also the shape of the data is deterministic. In expanded documents properties of a single node may still be spread across a number of different JSON objects . By flattening a document, all properties of a node are collected in a single JSON object and all blank nodes are labeled with a blank node identifier . Often this drastically simplifies the code to process JSON-LD data.
For example, assume the following JSON-LD input document:
{ "@context": { "name": "http://xmlns.com/foaf/0.1/name", "knows": "http://xmlns.com/foaf/0.1/knows" }, "@id": "http://me.markus-lanthaler.com/", "name": "Markus Lanthaler", "knows": [ { "name": "Manu Sporny", "knows": { "@id": "http://greggkellogg.net/foaf#me" } }, { "@id": "http://greggkellogg.net/foaf#me", "name": "Gregg Kellogg" } ] }
Running the Flattening Algorithm with a context set to null to prevent compaction returns the following document:
[ { "@id": "http://me.markus-lanthaler.com/", "http://xmlns.com/foaf/0.1/name": [ { "@value": "Markus Lanthaler" } ], "http://xmlns.com/foaf/0.1/knows": [ { "@id": "_:t0" }, { "@id": "http://greggkellogg.net/foaf#me" } ] }, { "@id": "_:t0", "http://xmlns.com/foaf/0.1/name": [ { "@value": "Manu Sporny" } ], "http://xmlns.com/foaf/0.1/knows": [ { "@id": "http://greggkellogg.net/foaf#me" } ] }, { "@id": "http://greggkellogg.net/foaf#me", "http://xmlns.com/foaf/0.1/name": [ { "@value": "Gregg Kellogg" } ] } ]
Note
how
in
the
output
above
all
properties
of
a
node
are
collected
in
a
single
JSON
object
and
how
the
blank
node
representing
"Manu
Sporny"
has
been
assigned
the
blank
node
identifier
_:t0
.
To make it easier for humans to read such a flattened document can be compacted by passing a context. Using the same context as the input document, the flattened and compacted document looks as follows:
{ "@context": { "name": "http://xmlns.com/foaf/0.1/name", "knows": "http://xmlns.com/foaf/0.1/knows" }, "@graph": [ { "@id": "http://me.markus-lanthaler.com/", "name": "Markus Lanthaler", "knows": [ { "@id": "_:t0" }, { "@id": "http://greggkellogg.net/foaf#me" } ] }, { "@id": "_:t0", "name": "Manu Sporny", "knows": { "@id": "http://greggkellogg.net/foaf#me" } }, { "@id": "http://greggkellogg.net/foaf#me", "name": "Gregg Kellogg" } ] }
Please
note
that
the
flattened
and
compacted
result
will
always
explicitly
designate
the
default
by
the
@graph
member
in
the
top-level
JSON
object
.
Compaction
optimizes
that
member
away
if
its
value
contains
just
one
item.
This section is non-normative.
JSON-LD
can
be
used
to
losslessly
express
the
RDF
serialize
data
model
expressed
in
RDF
as
described
in
the
RDF
Concepts
document
[
RDF-CONCEPTS
].
This
ensures
that
data
can
be
round-tripped
from
and
to
any
RDF
syntax,
like
N-Triples
or
TURTLE,
syntax
without
any
loss
in
the
fidelity
of
the
data.
Assume
For
example,
assume
the
following
RDF
input
serialized
in
N-Triples
format:
Turtle
[
TURTLE-TR
]:
<http://me.markus-lanthaler.com/> <http://xmlns.com/foaf/0.1/name> "Markus Lanthaler" . <http://me.markus-lanthaler.com/> <http://xmlns.com/foaf/0.1/homepage><http://manu.sporny.org/> .";<http://www.markus-lanthaler.com/> .
A
developer
can
use
Using
the
JSON-LD
API
to
Convert
from
RDF
Algorithm
a
developer
could
transform
the
markup
above
this
document
into
a
JSON-LD
document:
function conversionCallback(result)
{
console.log("JSON-LD Document: ", result);
};
jsonld.fromRDF(data,
conversionCallback,
{"format":
"ntriples"});
The
following
expanded
output
would
be
the
result
of
the
call
above:
JSON-LD:
[ { "@id": "http://me.markus-lanthaler.com/", "http://xmlns.com/foaf/0.1/name": [ { "@value": "Markus Lanthaler" } ], "http://xmlns.com/foaf/0.1/homepage": [ { "@id": "http://www.markus-lanthaler.com/" } ] } ]
Note
that
the
output
above,
above
could
easily
be
compacted
to
produce
the
following
using
the
technique
outlined
in
the
previous
section:
{
"@context": "http://json-ld.org/contexts/person.jsonld",
"@id": "http://manu.sporny.org/about/#manu",
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/"
}
Transforming
section.
It
is
also
possible
to
transform
the
node
above
JSON-LD
document
back
to
RDF
is
as
simple
as
calling
using
the
toRDF()
method:
Convert
to
RDF
Algorithm
.
This
API
provides
a
clean
mechanism
All
examples
and
notes
as
well
as
sections
marked
as
non-normative
in
this
specification
are
non-normative.
Everything
else
in
this
specification
is
normative.
The keywords must , must not , required , should , should not , recommended , may , and optional in this specification are to be interpreted as described in [ RFC2119 ].
There
are
two
classes
of
products
that
enables
developers
can
claim
conformance
to
convert
this
specification:
JSON-LD
data
into
a
Implementations
and
JSON-LD
Processors
.
A
conforming
JSON-LD
Implementation
is
a
variety
system
capable
of
output
formats
that
are
easier
to
work
with
transforming
JSON-LD
documents
according
the
algorithms
defined
in
various
programming
languages.
If
a
this
specification.
A
conforming
JSON-LD
API
Processor
is
provided
in
a
conforming
JSON-LD
Implementation
that
exposes
the
application
programming
environment,
interface
(API)
defined
in
this
specification.
The
algorithms
in
this
specification
are
generally
written
with
more
concern
for
clarity
than
over
efficiency.
Thus,
JSON-LD
Implementations
and
Processors
may
implement
the
entirety
of
algorithms
given
in
this
specification
in
any
way
desired,
so
long
as
the
following
API
end
result
is
indistinguishable
from
the
result
that
would
be
obtained
by
the
specification's
algorithms.
This
specification
does
not
define
how
JSON-LD
Implementations
or
Processors
handle
non-conforming
input
documents.
This
implies
that
JSON-LD
Implementations
or
Processors
must
not
be
implemented.
attempt
to
correct
malformed
IRIs
or
language
tags;
however,
they
may
issue
validation
warnings.
The
intent
of
the
Working
Group
and
the
Editors
Implementers
can
partially
check
their
level
of
this
specification
is
conformance
to
eventually
align
terminology
used
in
this
document
with
specification
by
successfully
passing
the
terminology
used
in
test
cases
of
the
RDF
Concepts
document
to
JSON-LD
test
suite
[
JSON-LD-TESTS
].
Note,
however,
that
passing
all
the
extent
to
which
it
makes
sense
to
do
so.
In
general,
if
there
is
an
analogue
to
terminology
used
in
this
document
tests
in
the
RDF
Concepts
document,
the
preference
is
test
suite
does
not
imply
complete
conformance
to
use
this
specification.
It
only
implies
that
the
terminology
in
implementation
conforms
to
aspects
tested
by
the
RDF
Concepts
document.
test
suite.
The
This
document
uses
the
following
is
an
explanation
of
terms
as
defined
in
JSON
[
RFC4627
].
Refer
to
the
general
terminology
used
JSON
Grammar
section
in
this
document:
[
RFC4627
]
for
formal
definitions.
@context
where
the
value,
or
the
@id
of
the
value,
is
null
@value
,
@list
,
or
@set
is
set
to
null
in
expanded
form,
then
the
entire
JSON
object
is
ignored.
Furthermore, the following terminology is used throughout this document:
BlankNode
values
will
often
be
generated
differently
by
different
processors.
Note
Implementers
must
ensure
that
_:
.All algorithms described in this section are intended to operate on language-native data structures. That is, the serialization to a text-based JSON document isn't required as input or output to any of these algorithms and language-native data structures must be used where applicable.
@context
keyword
.
@value
,
@list
,
or
@set
keywords,
or
@graph
keyword.
@list
member.
Processing
of
JSON-LD
data
structure
is
managed
recursively.
During
processing,
each
rule
is
applied
using
information
provided
by
the
The
algorithm
takes
three
input
variables:
an
active
context
.
Processing
begins
by
pushing
a
new
processor
state
onto
,
an
active
property
,
and
an
element
to
be
expanded.
To
begin,
the
processor
state
stack.
If
a
local
active
context
is
encountered,
information
from
set
to
the
local
context
result
of
performing,
Context
Processing
is
merged
into
on
the
active
context
.
The
active
context
passed
expandContext
,
or
empty
if
expandContext
is
used
for
expanding
properties
and
values
of
a
JSON
object
null
,
active
property
(or
elements
of
an
array)
using
a
term
mapping
.
It
is
also
used
to
maintain
coercion
mapping
s
from
terms
to
datatypes,
language
mapping
s
from
terms
set
to
language
codes,
and
list
mapping
s
null
,
and
set
mapping
s
for
terms.
Processors
must
element
use
is
set
to
the
lexical
form
of
JSON-LD
input
.
This
algorithm
expects
the
property
when
creating
JSON-LD
input
to
be
a
mapping,
well-formed
JSON-LD
document
as
lookup
is
performed
on
lexical
forms,
not
expanded
IRI
representations.
A
local
context
defined
in
[
JSON-LD
].
@list
and
the
expanded
LIST_OF_LISTS_DETECTED
error.
@language
@context
@context
member.
true
for
the
@id
,
set
the
@language
or
@type
@id
@graph
true
INVALID_ID_VALUE
@type
,
set
the
@id
@type
true
for
both
the
INVALID_TYPE_VALUE
error.
Empty
arrays
are
ignored.
@value
,
set
the
@value
member
of
result
to
value
.
If
value
is
neither
a
scalar
INVALID_VALUE_OBJECT_VALUE
error.
@language
,
set
the
@language
member
of
INVALID_LANGUAGE_VALUE
error.
@annotation
,
set
the
@annotation
member
of
result
to
value
.
If
value
is
not
a
INVALID_ANNOTATION_VALUE
error.
@set
or
@list
,
set
the
@type
@graph
,
set
the
@graph
@id
.
Determine
the
IRI
by
performing
IRI
Expansion
on
@graph
as
active
property
.
@language
@language
property
but
no
@type
@value
@language
LANGUAGE_MAP_INVALID_VALUE
error.
Otherwise
append
the
object
to
language
@annotation
@annotation
set
to
key
if
no
such
member
exists
yet
and
append
the
@list
and
@list
member,
replace
@list
member
whose
value
is
set
to
@annotation
member,
decrease
numProperties
by
1.
@value
member,
@language
member,
decrease
@value
member
is
a
string.
If
not,
trigger
an
INVALID_LANGUAGE_TAGGED_STRING
error.
@type
member,
decrease
numProperties
by
1
and
@type
INVALID_TYPED_VALUE
INVALID_VALUE_OBJECT
error.
@value
member
equals
null
,
set
element
to
null
.
@type
member
whose
value
is
not
@list
or
@set
member
and
INVALID_SET_OR_LIST_OBJECT
error.
@set
member,
set
element
to
the
@language
member,
set
element
to
null.
If,
after
the
algorithm
outlined
above
is
run,
the
resulting
element
is
an
JSON
object
with
just
a
@graph
member,
element
is
set
to
the
value
of
@graph
's
value.
Finally,
if
element
is
a
JSON
object
,
it
is
wrapped
into
an
array
.
Some
keys
Processing
of
JSON-LD
data
structure
is
managed
recursively.
During
processing,
each
rule
is
applied
using
information
provided
by
the
active
context
.
The
active
context
contains
the
active
term
definitions
which
specify
how
properties
and
values
are
expressed
using
IRI
have
to
be
interpreted
as
well
as
the
current
vocabulary
mapping
and
the
default
language
.
Each
term
definition
s.
This
section
defines
an
algorithm
for
transforming
consists
of
an
IRI
(
iri
)
to
mapping
and
optionally
a
term
type
mapping
from
terms
to
datatypes
or
compact
language
mapping
from
terms
to
language
codes,
and
a
container
mapping
.
If
an
IRI
mapping
maps
a
term
to
multiple
If
a
local
context
using
is
encountered,
information
from
the
term
local
context
s
specified
in
is
merged
into
the
active
context
.
A
local
context
using
is
identified
within
a
JSON
object
having
a
@context
member
with
a
string
,
array
or
a
JSON
object
value.
This
algorithm
specifies
how
the
active
context
is
updated
with
a
local
context
.
The
algorithm
takes
three
input
variables:
an
optional
active
context
,
a
local
context
,
and
an
array
of
already
included
remote
contexts
value
remoteContexts
.
To
begin,
remoteContexts
is
initialized
to
an
empty
array.
All
calls
of
the
IRI
Compaction
Algorithm
The
Expansion
algorithm
for
generating
a
compact
IRI
is:
pass
the
value
specified
in
the
algorithm
along
with
the
active
context
,
the
currently
being
processed
local
context
,
and
true
for
the
vocabRelative
flag.
RECURSIVE_CONTEXT_INCLUSION
error.
Otherwise,
add
context
@context
member
recursively
invoke
this
algorithm
passing
a
copy
of
active
context
,
the
value
of
the
@context
member
as
local
context
,
and
a
copy
of
the
INVALID_REMOTE_CONTEXT
error.
INVALID_LOCAL_CONTEXT
error.
@container
@vocab
member:
if
its
value
is
neither
an
absolute
IRI
,
i.e.,
it
does
not
contain
a
colon
(
:
),
nor
null
,
trigger
an
INVALID_VOCAB_MAPPING
error;
otherwise
set
the
active
context's
vocabulary
mapping
to
@vocab
member
from
true
@language
INVALID_DEFAULT_LANGUAGE
error;
otherwise
set
the
active
context's
default
language
to
its
value
and
remove
the
@list
@language
INVALID_TERM_DEFINITION
container
@id
INVALID_PROPERTY_GENERATOR
error.
@type
member
with
a
INVALID_TYPE_MAPPING
error.
Otherwise
set
the
@vocab
@language
member
with
a
value
val
that
is
INVALID_LANGUAGE_MAPPING
error.
@container
member
with
a
value
@list
,
@set
,
or
@annotation
,
set
the
container
mapping
of
definition
to
val
.
If
val
is
not
one
of
those
values,
raise
an
INVALID_CONTAINER_MAPPING
error.
When
selecting
among
multiple
possible
terms
for
a
given
property,
it
may
be
that
multiple
terms
In
JSON-LD
documents
keys
and
some
values
are
defined
with
the
same
evaluated
to
produce
an
IRI
,
but
differ
in
@type
,
@container
or
@language
.
The
purpose
.
This
section
defines
an
algorithm
for
transforming
strings
representing
an
IRI
into
an
absolute
IRI
.
If
IRI
expansion
occurs
during
context
processing,
the
local
context
that
is
being
processed
is
passed
to
this
algorithm.
After
application
of
this
algorithm,
values
processed
by
this
algorithm
is
are
said
to
take
a
term
be
in
expanded
IRI
form
,
although
this
may
also
include
blank
node
identifiers
and
a
value
and
give
it
a
term
rank
.
The
selection
can
then
be
based,
partly,
on
the
term
having
the
highest
term
rank
JSON-LD
keywords
.
Given
The
algorithm
takes
two
mandatory
and
four
optional
input
variables:
a
term
term
,
value
,
and
to
be
expanded,
an
active
context
,
two
flags
documentRelative
and
vocabRelative
specifying
whether
value
should
be
interpreted
as
relative
IRI
determine
against
the
term
rank
document's
base
IRI
or
the
active
context's
using
vocabulary
mapping
,
along
with
an
local
context
passed
when
this
algorithm
is
used
in
Context
Processing
,
and
finally
an
array
path
which
is
used
to
detect
cyclic
IRI
mappings
.
If
not
passed,
the
following
steps:
two
flags
are
set
to
false
and
path
is
initialized
to
an
empty
array
by
default.
The algorithm for generating an IRI is:
CYCLIC_IRI_MAPPING
true
for
PROPERTY_GENERATOR_IN_TERM_DEFINITION
error.
:
:
@type
//
or
prefix
equals
@language
it
is
2
_
,
@language
,
term
rank
true
for
the
vocabRelative
flag.
If
the
expanded
prefix
contains
a
colon
(
:
)
generate
and
return
an
IRI
@language
true
@id
true
,
If
the
result
of
the
algorithm
above
is
a
blank
node
identifier
,
i.e.,
a
string
that
begins
with
_:
,
and
no
local
context
has
been
passed,
generated
a
new
blank
node
identifier
before
returning
the
final
result.
Some
values
in
JSON-LD
can
be
expressed
in
a
compact
form.
compacted
form
.
These
values
are
required
to
be
expanded
at
times
when
processing
JSON-LD
documents.
A
value
is
said
to
be
in
expanded
form
after
the
application
of
this
algorithm.
The algorithm for expanding a value takes an active property and active context . It is implemented as follows:
@graph
or
the
@id
coercion,
expand
the
value
into
an
object
with
,
add
a
key-value
pair
to
result
where
the
key
is
@id
and
the
value
is
the
true
for
the
@value
and
the
@type
and
the
@language
and
the
value
Some
values,
such
as
IRIs
and
typed
literals
,
may
be
expressed
in
an
expanded
form
(
expanded
value
)
in
JSON-LD.
These
values
are
required
to
be
compacted
at
times
when
processing
JSON-LD
documents.
The
algorithm
for
compacting
takes
a
single
input
variable:
an
expanded
value
value
element
takes
an
active
property
and
active
context
to
be
labeled
with
blank
node
identifiers
.
It
is
implemented
as
follows:
@id
@list
@list
member's
value.
@id
,
the
compacted
value
is
the
value
associated
with
the
member,
create
a
new
@id
This
algorithm
is
used
to
generate
new
blank
node
identifiers
or
to
relabel
existing
blank
node
identifiers
with
a
typed
literal
,
new
one
to
avoid
collision
by
the
compacted
value
introduction
of
new
ones.
It
needs
to
keep
an
identifier
map
,
a
counter
,
and
a
prefix
between
its
executions
to
be
able
to
generate
new
blank
node
identifiers
.
The
counter
is
the
value
associated
with
the
initialized
to
@value
0
key.
Otherwise,
if
and
value
prefix
contains
an
is
set
to
@id
_:t
key,
the
compacted
value
is
by
default.
The
algorithm
takes
a
single
input
variable
value
identifier
with
the
value
of
@id
processed
according
to
the
IRI
Compaction
steps.
which
might
be
null
.
@type
value
processed
according
to
the
IRI
Compaction
steps.
1
.
The
algorithm
takes
three
four
input
variables:
an
active
context
,
an
inverse
context
,
an
active
property
,
and
an
element
to
be
expanded.
compacted.
To
begin,
the
active
context
is
set
to
the
result
of
performing,
performing
Context
Processing
on
the
passed
context
,
or
empty
if
inverse
context
is
null
set
to
the
result
of
creating
an
inverse
context
from
the
active
context
,
active
property
is
set
to
null
,
and
element
is
set
to
the
result
of
performing
the
Expansion
Algorithm
on
the
JSON-LD
input
.
compactArrays
option
is
set
to
@list
and
any
entry
in
true
,
return
that
item;
otherwise
return
result
.
@value
or
@id
member,
replace
element
@id
,
compact
value
according
@type
,
compact
true
.
If
value
is
@id
the
@graph
,
compact
value
true
.
true
.
@value
@language
or
@language
@annotation
@list
@language
or
@set
@annotation
@list
@list
,
set
the
active
property
member
of
result
to
the
value
of
item's
@list
member.
If
such
an
member
already
exists
in
result,
raise
an
COMPACTION_TO_LIST_OF_LISTS
error;
otherwise
continue
with
the
next
property
-
value
pair
from
element
.
compactArrays
option
is
set
to
@container
false
or
the
active
property's
container
mapping
is
set
to
@list
@set
,
convert
the
If,
after
the
algorithm
outlined
above
is
run,
the
resulting
value
element
to
is
an
array
replace
it
with
a
new
JSON
object
with
an
a
single
member
whose
name
is
the
result
of
compacting
the
value
@list
@graph
property
with
the
IRI
Compaction
algorithm
and
whose
value
is
set
element
.
Finally,
add
a
@context
property
to
value
element
(unless
and
set
it
to
the
initially
passed
context
.
This
section
defines
an
algorithm
for
transforming
an
IRI
to
a
term
or
compact
IRI
.
If
a
value
is
already
in
that
form).
Convert
passed
it
is
used
to
choose
the
best
matching
term
.
This
algorithm
takes
three
mandatory
and
two
optional
parameters.
The
mandatory
parameters
are
the
value
iri
to
array
form
unless
be
compacted,
an
active
context
,
and
an
inverse
context
.
Optionally
it
is
possible
to
pass
a
value
is
null
and
a
vocabRelative
flag
which
specifies
whether
the
passed
iri
should
be
compacted
using
the
active
context's
or
vocabulary
mapping
.
If
the
property
vocabRelative
flag
is
not
set
it
defaults
to
.
@id
,
@type
,
@value
,
or
@language
false
The algorithm for generating a compact IRI is:
@set
,
@annotation
member,
set
@annotation
.
@id
member,
set
typeOrLanguage
to
@type
and
typeLanguageValue
to
@id
.
@value
@type
member,
set
@language
@type
@type
@language
member,
set
typeOrLanguage
to
@language
and
typeLanguageValue
to
the
value
of
the
@value
@language
@annotation
member,
set
container
to
@language
@value
member
is
is
a
string
,
set
typeOrLanguage
to
@language
and
typeLanguageValue
to
@null
.
@type
@list
@list
member
has
at
least
one
item,
update
container
,
typeOrLanguage
,
and
@list
member
as
new
value
.
@set
@annotation
@list
property,
it
must
.
@list
member,
recursively
run
the
steps
2.1.2
to
2.1.3.4
(which
will
never
be
true
since
list
of
lists
are
not
allowed)
of
this
algorithm
passing
the
@list
@language
property,
@list
,
set
the
first
item
of
@list
and
null
.
;
otherwise
set
it
to
an
array
consisting
of
three
elements
where
the
first
element
is
the
value
of
container
and
the
other
two
elements
are
@set
and
@null
.
@null
.
@null
.
Set
the
third
item
of
queryPath
to
an
array
whose
first
element
typeLanguageValue
and
@null
.
@graph
term
@graph
term
term
member,
i.e.,
it
is
term
member
of
termDefinition
with
a
:
)
character
and
http://xmlns.com/foaf/0.1/name
term
member
of
result
to
true
,
the
active
context
term
member
of
result
to
vocabIri
and
return
result
.
term
member
of
An
active
context
as
produced
by
the
Expansion
Algorithm
Context
Processing
on
algorithm
is
very
efficient
for
expanding
terms
and
compact
IRIs
to
IRIs
but
is
of
limited
use
for
the
JSON-LD
input
opposite
operation:
IRI
compaction
.
This
removes
any
existing
Hence,
this
algorithm
introduces
the
notion
of
an
inverse
context
which
brings
the
same
efficiency
to
IRI
compaction
.
An
inverse
context
a
tree
of
JSON
objects
which
allow
the
given
to
efficiently
select
a
term
for
a
IRI
-value
pair.
The
value
takes
an
active
context
to
be
cleanly
applied.
and
returns
the
corresponding
inverse
context
.
@null
.
@null
if
no
such
mapping
exists.
propertyGenerators
.
@value
term
term
member
of
inverseContext[iri]['term']
).
inverseContext[iri][container]['@type'][type][termType]
,
e.g.,
inverseContext['http://...']['@list']['@type']['http://...']['term']
.
@null
.
Then
append
the
term
to
@list
inverseContext[iri][container]['@language'][language][termType]
,
e.g.,
inverseContext['http://...']['@list']['@language']['de']['term']
.
inverseContext[iri][container]['@null']['@null'][termType]
as
well
as
inverseContext[iri][container]['@language'][defaultLanguage][termType]
to
take
the
default
language
into
consideration
for
terms
without
explicit
language
mapping
.
term
member
in
inverse
context
.
The
result
is
thus
a
@list
propertyGenerators
It
is
possible
that
property's
value
passing
a
copy
multiple
terms
that
differ
in
their
container
,
type
,
or
language
mapping
are
mapped
to
the
same
IRI
.
The
purpose
of
this
algorithm
is
to
query
the
active
inverse
context
and
to
return
either
the
active
best
matching
term
,
or
a
list
of
potential
property
generators
ensuring
that
the
result
is
an
array
along
with
all
null
values
removed.
If
there
already
exists
a
value
for
active
term
to
fall
back
to
if
none
of
the
property
generators
in
can
be
applied.
This
algorithm
takes
an
element
inverseContextSubtree
,
a
queryPath
and
as
generated
by
the
full
IRI
of
Compaction
algorithm
and
a
property
level
parameter
which
is
also
coerced
initialized
to
if
nothing
else
is
passed.
The
algorithm
returns
either
a
string
representing
the
@list
,
return
an
error.
Otherwise
store
0
resulting
best
matching
term
or
a
JSON
object
consisting
of
a
propertyGenerators
member,
containing
a
sorted
array
as
value
of
active
potential
property
generators
,
and
an
optional
term
member
containing
a
term
to
fall
back
to
if
empty
or
none
of
the
property
generators
can
be
applied.
3
,
i.e.,
the
deepest
nested
JSON
object
in
the
inverse
context
has
been
reached,
perform
the
following
steps:
propertyGenerators
member,
copy
that
member
into
a
new
JSON
object
term
member
and
result
is
null
,
return
the
value
of
that
member;
otherwise
result
term
member
into
@type
queryPath[level]
),
perform
the
following
steps:
1
as
new
level
.
propertyGenerators
member
is
set
to
an
empty
array
term
member
is
set
to
propertyGenerator
true
,
propertyGenerator
member
of
term
member
but
tmpResult
does,
copy
tmpResult's
term
member
into
result
.
Expansion
transforms
all
values
into
expanded
form
in
JSON-LD.
This
algorithm
does
the
opposite,
it
compacts
an
algorithm
according
the
term
definition
of
the
passed
active
property
and
.
After
the
application
of
this
algorithm
a
value
is
said
to
be
in
compacted
form
.
This
algorithm
takes
a
value
to
,
an
active
context
,
an
inverse
context
,
an
active
property
,
and
an
optional
output
containerValue
.
@annotation
and
value
@annotation
member
which
equals
containerValue
,
remove
that
member.
@id
,
return
the
result
of
performing
IRI
Compaction
on
@value
member,
perform
the
following
steps:
@type
member,
remove
the
@type
member
from
value
@language
member,
remove
the
@language
member
from
value
.
@language
,
and
@language
member
which
equals
containerValue
,
remove
the
@language
member
from
value
.
@container
mapping
to
@set
@language
false
,
convert
@language
member
from
value
@value
member
is
a
string
,
return
value
.
@value
member,
return
the
value
of
that
member.
If,
after
the
This
algorithm
outlined
above
is
run,
the
resulting
checks
if
a
specific
value
exists
for
all
IRIs
associated
with
a
property
generator
and
if
so,
it
removes
them.
The
algorithm
takes
five
parameters:
element
is
an
array
,
property
,
value
,
active
context
,
put
active
property
.
@graph
propertyGenerators
@id
member
exists
(i.e.,
it
is
an
unlabeled
@merged
term
The
algorithm
takes
two
input
variables,
an
element
to
flatten
and
the
graph
for
which
the
node
definitions
should
be
returned.
If
a
graph
context
is
not
set,
it
will
default
used
to
@merged
which
represents
the
result
of
merging
all
graphs
including
compact
the
default
graph
(
@default
).
flattened
document.
@default
member
of
nodeMap
;
a
JSON
object
representing
the
default
graph
.
@id
member
whose
value
is
set
to
graphName
.
@graph
member
set
to
an
empty
array
(referred
to
as
@graph
keyword
(or
its
alias)
at
the
top-level,
even
if
the
context
is
empty
or
if
there
is
only
one
element
to
put
in
the
@graph
array
.
This
ensures
that
the
returned
document
has
a
deterministic
structure.
The
Node
Map
Generation
This
algorithm
takes
as
input
an
expanded
JSON-LD
document
and
results
in
creates
a
JSON
object
nodeMap
holding
a
flat
an
indexed
representation
of
the
graphs
and
nodes
represented
in
the
passed,
expanded
document.
All
nodes
that
are
not
uniquely
identified
by
an
IRI
get
assigned
a
(new)
blank
node
identifier.
identifier
.
The
resulting
nodeMap
document
will
have
a
property
member
for
every
graph
in
the
document
whose
value
is
another
object
with
a
property
member
for
every
node
represented
in
the
document.
While
the
The
default
graph
is
stored
under
the
@default
property
and
the
merged
graph
under
the
@merged
property,
member,
all
other
graphs
are
stored
under
their
respective
IRIs
.
graph
name.
The
algorithm
takes
as
input
the
an
expanded
JSON-LD
document
as
element
,
the
initially
empty
and
a
reference
to
a
JSON
object
nodeMap
,
.
Furthermore
it
has
the
optional
parameters
active
graph
(which
defaults
to
@default
as
graph
,
null
as
list
,
),
an
active
subject
,
active
property
,
and
null
a
reference
to
a
JSON
object
as
id
list
.
The
nodeMap
must
be
initialized
to
a
JSON
object
consisting
of
a
single
member
whose
name
corresponds
with
active
graph
and
whose
value
is
an
empty
JSON
object
.
@id
@type
@id
with
the
@value
member,
perform
the
following
steps:
Handling of free-floating values is still being discussed.
@graph
,
recursively
call
this
algorithm
passing
value
for
element
,
nodeMap
,
null
for
@list
member
of
list
@merged
@list
property
@list
@list
member
as
new
Handling of free-floating values is still being discussed.
@list
@id
@list
@id
whose
value
is
set
to
@id
whose
value
is
@list
member
of
list
.
@type
member,
merge
each
value
into
the
@type
of
active
subject
in
@merged
@type
@annotation
member,
set
the
@annotation
of
active
subject
in
activeGraph
to
CONFLICTING_ANNOTATION
error.
Otherwise
continue
and
remove
the
@annotation
from
@graph
member,
recursively
invoke
this
algorithm
passing
the
value
of
the
@graph
member
as
new
@graph
member
from
A
JSON-LD
document
may
be
converted
between
other
RDF-compatible
document
formats
using
the
algorithms
specified
in
this
section.
The
JSON-LD
Processing
Model
This
specification
describes
processing
rules
for
extracting
RDF
from
a
algorithms
to
transform
JSON-LD
document,
and
for
transforming
documents
to
an
array
of
Quad
RDF
quads
retrieved
by
processing
another
serialization
format
into
JSON-LD.
and
vice-versa.
Note
that
many
uses
of
JSON-LD
may
not
require
generation
of
RDF.
The
processing
algorithms
described
in
this
section
are
provided
in
order
to
demonstrate
how
one
might
implement
a
JSON-LD
to
RDF
processor.
Conformant
implementations
are
only
required
to
produce
the
same
type
and
number
of
quads
during
the
output
process
and
but
are
not
required
to
implement
the
algorithm
exactly
as
described.
This algorithm hasn't been updated yet.
The algorithm below is designed for in-memory implementations with random access to JSON object elements.
A
conforming
JSON-LD
processor
implementing
RDF
conversion
must
implement
a
processing
algorithm
that
results
in
the
same
set
of
RDF
Quads
quads
that
the
following
algorithm
generates:
The
algorithm
takes
four
input
variables:
a
element
to
be
converted,
an
active
subject
,
active
property
and
graph
name
.
To
begin,
the
active
subject
,
active
property
and
graph
name
are
set
to
null
,
and
element
is
set
to
the
result
of
performing
the
Expansion
Algorithm
on
the
JSON-LD
input
.
which
is
expected
to
be
a
a
well-formed
JSON-LD
document
as
defined
in
[
JSON-LD
].
This
removes
any
existing
context
to
allow
the
given
context
to
be
cleanly
applied.
@value
property:
@value
is
a
number
,
set
the
active
object
to
a
typed
@type
property
if
it
exists,
otherwise
either
xsd:integer
or
xsd:double
,
depending
on
if
the
value
contains
a
fractional
and/or
an
exponential
component.
@value
is
true
or
false
,
set
the
active
object
to
a
typed
@type
property
if
it
exists,
otherwise
xsd:boolean
.
@type
property,
set
the
active
object
to
a
typed
@language
property,
set
the
active
object
to
a
language-tagged
string
.
xsd:string
as
the
datatype.
@list
property
the
value
must
be
an
array
.
Process
its
value
as
a
list
as
described
in
List
Conversion
using
the
return
value
as
the
active
object
@id
property,
the
value
must
be
a
string
,
set
the
active
subject
to
the
previously
expanded
value
(either
a
blank
node
or
an
IRI
).
@id
property,
set
the
active
subject
to
newly
generated
blank
node
.
@type
,
set
the
active
property
to
rdf:type
.
@graph
,
process
value
algorithm
recursively,
using
active
subject
as
graph
name
and
null
values
for
active
subject
and
active
property
and
then
proceed
to
next
property.
rdf:type
so
set
the
active
object
to
an
IRI
.
List
Conversion
is
the
process
of
taking
an
array
of
values
and
adding
them
to
a
newly
created
RDF
Collection
(see
[
RDF-SCHEMA
])
by
linking
each
element
of
the
list
using
rdf:first
and
rdf:next
,
terminating
the
list
with
rdf:nil
using
the
following
sequence:
The algorithm is invoked with an array array , the active property and returns a value to be used as an active object in the calling location.
This algorithm hasn't been updated yet.
rdf:nil
.
rdf:first
as
the
active
property
.
rdf:nil
.
rdf:rest
and
rest
blank
node
.
In
some
cases,
data
exists
natively
in
Triples
the
form
of
triples
or
Quads
form;
or
quads
;
for
example,
if
the
data
was
originally
represented
in
an
RDF
graph
or
triple/quad
store.
This
algorithm
is
designed
to
simply
translate
an
array
of
Quads
quads
into
a
JSON-LD
document.
When
expanding
typed
literal
values
having
a
datatype
of
xsd:string
,
the
@type
must
not
be
set
to
xsd:string
and
the
resulting
value
must
have
only
a
@value
property.
The conversion algorithm takes a single parameter input in the form of an array of Quad representations.
This algorithm hasn't been updated yet.
rdf:first
,
use
the
entry
in
graph.listMap
indexed
by
subject
,
initializing
it
to
a
new
JSON
object
if
nesessary.
Represent
object
in
expanded
rdf:rest
:
@id
and
@id
and
rdf:type
,
object
is
not
a
JSON-LD
value
,
and
the
useRdfType
option
is
not
present
or
false
:
@type
,
creating
an
entry
in
value
if
necessary.
useNativeTypes
option
is
set
to
true
:
xsd:boolean
,
the
converted
value
is
true
if
the
literal
matches
the
value
true
or
false
if
the
literal
matches
the
value
false
.
xsd:integer
or
xsd:double
,
try
to
convert
the
literal
to
a
JSON
number
.
If
the
conversion
is
successful,
store
the
result
in
converted
value
,
otherwise
set
converted
value
to
value
.
rdf:nil
:
@list
representation
to
the
array
value
for
key
,
creating
an
entry
in
value
if
necessary.
@id
in
value
.
@list
initialized
to
a
new
array
containing
the
value
of
first
from
entry
.
@graph
in
entry
containing
the
ordered
entries
from
graphs[subject].nodes
.
When
converting
JSON-LD
to
RDF
JSON-native
types
such
as
numbers
and
booleans
are
automatically
coerced
to
xsd:integer
,
xsd:double
,
or
xsd:boolean
.
Implementers
must
ensure
that
the
result
is
a
in
canonical
lexical
form
in
the
form
of
a
string
.
A
canonical
lexical
form
is
a
set
of
literals
from
among
the
valid
set
of
literals
for
a
datatype
such
that
there
is
a
one-to-one
mapping
between
the
canonical
lexical
form
and
a
value
in
the
value
space
as
defined
in
[
XMLSCHEMA11-2
].
In
other
words,
every
value
must
be
converted
to
a
deterministic
string
representation.
The
canonical
lexical
form
of
an
integer
,
i.e.,
a
number
without
fractions
or
a
number
coerced
to
xsd:integer
,
is
a
finite-length
sequence
of
decimal
digits
(
0-9
)
with
an
optional
leading
minus
sign;
leading
zeroes
are
prohibited.
To
convert
the
number
in
JavaScript,
implementers
can
use
the
following
snippet
of
code:
(value).toFixed(0).toString()
The
canonical
lexical
form
of
a
double
,
i.e.,
a
number
with
fractions
or
a
number
coerced
to
xsd:double
,
consists
of
a
mantissa
followed
by
the
character
"E",
followed
by
an
exponent.
The
mantissa
must
be
a
decimal
number.
The
exponent
must
be
an
integer.
Leading
zeroes
and
a
preceding
plus
sign
(
+
)
are
prohibited
in
the
exponent.
If
the
exponent
is
zero,
it
must
be
indicated
by
E0
.
For
the
mantissa,
the
preceding
optional
plus
sign
is
prohibited
and
the
decimal
point
is
required.
Leading
and
trailing
zeroes
are
prohibited
subject
to
the
following:
number
representations
must
be
normalized
such
that
there
is
a
single
digit
which
is
non-zero
to
the
left
of
the
decimal
point
and
at
least
a
single
digit
to
the
right
of
the
decimal
point
unless
the
value
being
represented
is
zero.
The
canonical
representation
for
zero
is
0.0E0
.
xsd:double
's
value
space
is
defined
by
the
IEEE
double-precision
64-bit
floating
point
type
[
IEEE-754-1985
];
in
JSON-LD
the
mantissa
is
rounded
to
15
digits
after
the
decimal
point.
To convert the number in JavaScript, implementers can use the following snippet of code:
(value).toExponential(15).replace(/(\d)0*e\+?/,'$1E')
When data such as decimals need to be normalized, JSON-LD authors should not use values that are going to undergo automatic conversion. This is due to the lossy nature of xsd:double values. Authors should instead use the expanded object form to set the canonical lexical form directly.
The
canonical
lexical
form
of
the
boolean
values
true
and
false
are
the
strings
true
and
false
.
When JSON-native number s, are type coerced, lossless data round-tripping can not be guaranted as rounding errors might occur. Additionally, only literals typed as xsd:integer , xsd:double , and xsd:boolean are automatically converted back to their JSON-native counterparts in when converting from RDF .
Some
JSON
serializers,
such
as
PHP's
native
implementation
in
some
versions,
backslash-escape
the
forward
slash
character.
For
example,
the
value
http://example.com/
would
be
serialized
as
http:\/\/example.com\/
.
This
is
problematic
as
other
JSON
parsers
might
not
understand
those
escaping
characters.
There
is
no
need
to
backslash-escape
forward
slashes
in
JSON-LD.
To
aid
interoperability
between
JSON-LD
processors,
a
JSON-LD
serializer
must
not
backslash-escape
forward
slashes.
This API provides a clean mechanism that enables developers to convert JSON-LD data into a a variety of output formats that are easier to work with in various programming languages. If a JSON-LD API is provided in a programming environment, the entirety of the following API must be implemented.
The JSON-LD processor interface is the high-level programming structure that developers use to access the JSON-LD transformation methods.
The
JSON-LD
API
signatures
are
the
same
across
all
programming
languages.
Due
to
the
fact
that
asynchronous
programming
is
uncommon
in
certain
languages,
developers
may
implement
a
processor
with
a
synchronous
interface
instead.
In
that
case,
the
callback
parameter
must
not
be
included
and
the
result
must
be
returned
as
a
return
value
instead.
It is important to highlight that conformant JSON-LD processors must not modify the input parameters.
[Constructor]
interface JsonLdProcessor {
void expand ((object or object[] or DOMString) input, JsonLdCallback
callback, optional JsonLdOptions
? options); void compact ((object or object[] or DOMString) input, (object or DOMString) context, JsonLdCallback
callback, optional JsonLdOptions
? options); void flatten ((object or object[] or DOMString) input, (object or DOMString)? context, JsonLdCallback
callback, optional JsonLdOptions
? options);
};
compact
input
using
the
context
according
to
the
steps
in
the
Compaction
Algorithm
.Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
input |
(
object
or
object[]
or
DOMString
)
| ✘ | ✘ | The JSON-LD object or array of JSON-LD objects to perform the compaction upon or an IRI referencing the JSON-LD document to compact. |
context |
(
object
or
DOMString
)
| ✘ | ✘ |
The
context
to
use
when
compacting
the
input
;
either
in
the
form
of
an
JSON
object
or
as
IRI
. |
callback |
| ✘ | ✘ |
A
callback
that
is
called
when
processing
is
complete
on
the
given
input
. |
options |
| ✔ | ✔ |
A
set
of
options
to
configure
the
used
algorithms
such.
This
allows,
e.g.,
to
set
the
input
document's
base
IRI
.
This
also
includes
the
optimize
flag,
which,
if
set,
will
allow
processor-specific
optimization.
|
void
expand
input
according
to
the
steps
in
the
Expansion
Algorithm
.Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
input |
(
object
or
object[]
or
DOMString
)
| ✘ | ✘ | The JSON-LD object or array of JSON-LD objects to perform the expansion upon or an IRI referencing the JSON-LD document to expand. |
callback |
| ✘ | ✘ |
A
callback
that
is
called
when
processing
is
complete
on
the
given
input
. |
options |
| ✔ | ✔ | A set of options to configure the used algorithms such. This allows, e.g., to set the input document's base IRI . |
void
flatten
input
and
compacts
it
using
the
passed
context
according
to
the
steps
in
the
Flattening
Algorithm
.Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
input |
(
object
or
object[]
or
DOMString
)
| ✘ | ✘ | The JSON-LD object or array of JSON-LD objects or an IRI referencing the JSON-LD document to flatten. |
context |
(
object
or
DOMString
)
| ✔ | ✘ |
The
context
to
use
when
compacting
the
flattened
input
;
either
in
the
form
of
an
JSON
object
or
as
IRI
.
If
null
is
passed,
the
result
will
not
be
compacted
but
keept
in
expanded
form.
|
callback |
| ✘ | ✘ |
A
callback
that
is
called
when
processing
is
complete
on
the
given
input
. |
options |
| ✔ | ✔ | A set of options to configure the used algorithms such. This allows, e.g., to set the input document's base IRI . |
void
JSON-LD processors utilize callbacks in order to return information in an asynchronous manner to calling applications. This section details the parameters sent to those callbacks.
The
JsonLdCallback
is
called
when
processing
of
an
API
method
of
JsonLdProcessor
has
been
completed
successfully
or
been
terminated
by
an
error.
callback
JsonLdCallback
=
void
(
JsonLdProcessingError
error
,
object
or
object
[]
document
);
JsonLdCallback
Parameters
error
of
type
JsonLdProcessingError
null
,
then
no
error
occurred.
If
the
value
is
non-
null
,
a
processing
error
occurred
and
the
details
will
be
contained
within
the
error
object.
document
of
type
array
of
object
or
object
This section describes datatype definitions used within the JSON-LD API.
The
JsonLdOptions
type
is
used
to
pass
various
options
to
the
JsonLdProcessor
methods.
dictionary JsonLdOptions { DOMString base; object or DOMString expandContext = null; boolean compactArrays = true; boolean optimize = false; boolean useRdfType = false; boolean useNativeTypes = true;
};
JsonLdOptions
Members
base
of
type
DOMString
compactArrays
of
type
boolean
,
defaulting
to
true
true
,
the
JSON-LD
processor
replaces
arrays
with
just
one
element
with
that
element
during
compaction.
If
set
to
false
,
all
arrays
will
remain
arrays
even
if
they
have
just
one
element.
expandContext
of
type
object
or
DOMString
,
defaulting
to
null
optimize
of
type
boolean
,
defaulting
to
false
true
,
the
JSON-LD
processor
is
allowed
to
optimize
the
output
of
the
Compaction
Algorithm
to
produce
even
compacter
representations.
The
algorithm
for
compaction
optimization
is
beyond
the
scope
of
this
specification
and
thus
not
defined.
Consequently,
different
implementations
may
implement
different
optimization
algorithms.
useNativeTypes
of
type
boolean
,
defaulting
to
true
true
,
the
JSON-LD
processor
will
try
to
convert
typed
values
to
JSON
native
types
instead
of
using
the
expanded
object
form
when
converting
from
RDF
.
xsd:boolean
values
will
be
converted
to
true
or
false
.
xsd:integer
and
xsd:double
values
will
be
converted
to
JSON
numbers
.
useRdfType
of
type
boolean
,
defaulting
to
false
true
,
the
JSON-LD
processor
will
use
the
expanded
rdf:type
IRI
as
the
property
instead
of
@type
when
converting
from
RDF
.Developers should note that the details of error handling are being actively debated.
The
JsonLdProcessingError
type
is
used
to
report
errors
to
a
JsonLdCallback
.
dictionary JsonLdProcessingError { JsonLdErrorCode
code; DOMString? message;
};
JsonLdProcessingError
Members
code
of
type
JsonLdErrorCode
message
of
type
DOMString
,
nullable
The JsonLdErrorCode represent the collection of valid JSON-LD error codes.
enum JsonLdErrorCode {
"INVALID_SYNTAX",
"LOAD_ERROR",
"LIST_OF_LISTS_DETECTED"
};
Enumeration description | |
---|---|
INVALID_SYNTAX
| A violation of the grammar as defined by the JSON-LD syntax specification [ JSON-LD ] was detected. |
LOAD_ERROR
| There was a problem encountered loading a remote context. |
LIST_OF_LISTS_DETECTED
| A list of lists was detected. List of lists are not supported in this version of JSON-LD due to the algorithmic complexity associated with conversion to RDF. |
A
large
amount
of
thanks
goes
out
to
the
JSON-LD
Community
Group
participants
who
worked
through
many
of
the
technical
issues
on
the
mailing
list
and
the
weekly
telecons
-
of
special
mention
are
Niklas
Lindström,
François
Daoust,
Lin
Clark,
and
Zdenko
'Denny'
Vrandečić.
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.
The
work
of
Dave
Lehn
and
Mike
Johnson
are
appreciated
for
reviewing,
and
performing
several
implementations
of
the
specification.
Ian
Davis
is
thanked
for
this
his
work
on
RDF/JSON.
Thanks
also
to
Nathan
Rixham,
Bradley
P.
Allen,
Kingsley
Idehen,
Glenn
McDonald,
Alexandre
Passant,
Danny
Ayers,
Ted
Thibodeau
Jr.,
Olivier
Grisel,
Josh
Mandel,
Eric
Prud'hommeaux,
David
Wood,
Guus
Schreiber,
Pat
Hayes,
Sandro
Hawke,
and
Richard
Cyganiak
for
or
their
input
on
the
specification.