JSON-LD Framing allows developers to query by example and force a specific tree layout to a JSON-LD document.
This document is an experimental work in progress.
A JSON-LD document is a representation of a directed graph. A single
directed graph can have many different serializations, each expressing
exactly the same information. Developers typically work with trees, represented as
This document is a detailed specification for a serialization of Linked Data in JSON. 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, and the JSON-LD API [[!JSON-LD-API]]. 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]].
The intent of the Working Group and the Editors of this specification is to eventually align terminology used in this document with the terminology used in the RDF Concepts document to the extent to which it makes sense to do so. In general, if there is an analogue to terminology used in this document in the RDF Concepts document, the preference is to use the terminology in the RDF Concepts document.
The following is an explanation of the general terminology used in this document:
@value
,
@list
or @set
and it has one or more keys
other than @id
.@id
key._:
.There are a number of ways that one may participate in the development of this specification:
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 definition below is an experimental extension of the interface defined in the [[JSON-LD-API]].
input
using the
frame
according to the steps in the
Framing Algorithm. The input
is used to build the framed output and is returned if there are no errors.
If there are no matches for the frame, input
; either
in the form of an input
.The JsonLdCallback is used to return a processed JSON-LD representation as the result of processing an API method.
See
This section describes datatype definitions used within the JSON-LD API.
The JsonLdOptions type is used to convert a set of options to an interface method.
See
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.
This specification adds a number of
@default
@explicit
@omitDefault
@embed
@null
All JSON-LD tokens and keywords are case-sensitive.
@context
Framing is the process of taking a JSON-LD document, which expresses a
graph of information, and applying a specific graph layout
(called a
Framing makes use of the Node Map Generation algorithm to place each object defined in the JSON-LD document into a flat list of objects, allowing them to be operated upon by the framing algorithm.
@id
to a parent This algorithm is a work in progress. Presently, it only works for documents without named graphs.
Currently, framing allows just to select node definitions based
on @type
matching or duck typing for included properties. It allows value properties to
be explicitly matched based on defining the property and excluding things that are undefined, but it
does not allow to be more specific about the types of values selected. Allowing this is currently
being discussed.
The framing algorithm takes an
Create @merged
property of the result of performing the
Node Map Generation algorithm on
expanded input. Also create results as an empty
Invoke the recursive algorithm using
The following series of steps is the recursive portion of the framing algorithm:
@type
property containing
one or more @type
property including any of those @type
property only
a empty @type
property, regardless of the actual values.@embed
and @explicit
using the current values
for @id
and id.@id
equal to id, element has
already been embedded and can be overwritten, so set embedOn to @list
, then
create a @list
and
the value of an empty array. Append list to property in
output. Process each listitem in the @list
array as follows:
@id
of listitem as the key
and the @list
as @list
in list.@id
of item as the key and
the @omitDefault
which is @omitDefault
but the value of @preserve
and a value that is a copy of the value
of @default
in frame if it exists, or the string
@null
otherwise.At the completion of the recursive algorithm, results will contain the top-level
The final two steps of the framing algorithm require
results to be compacted according to the
Compaction Algorithm by using the
context provided in the @graph
keyword at the top-level, even if the context is empty or if there
is only one element to put in the @graph
array. Subsequently, replace all key-value
pairs where the key is @preserve
with the value from the key-pair. If the value
from the key-pair is @null
, replace the value with
This algorithm replaces an already embedded
About as clear as mud
The current behaviour avoids embedding the same data multiple times in the result makes it difficult to work with the output. A proposal to change this to "agressive re-embedding" is currently being discussed.
The algorithm is invoked with a
@id
of id,
removing that definition from the map, and then removing the dependents for the parent id
recursively by repeating this step. This step will terminate when there are no more embed
entries containing the removed @id
in their
parent chain.This algorithm recursively embeds property values in
@list
,
then create a new @list
and
a value of an empty array and add it to output, appending if output
is an array, and appending to @list
as @id
of item:
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.
application/json
MIME media type.eval()
function. It is RECOMMENDED that a conforming parser does not attempt to
directly evaluate the JSON-LD frame and instead purely parse the
input into a language-native data structure.Fragment identifiers have no meaning with application/frame-ld+json resources.
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, 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 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 their input on the specification.