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@nullAll 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.