The JSON-LD API 1.0

1.1 How to Read this Document

This document is a detailed specification for a serialization of Linked Data in JSON. The document is primarily intended for the following audiences:

• Authors that want a very detailed view of how JSON-LD processors operate.
• Software developers that want to implement processors and APIs for JSON-LD.

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].

Examples may contain references to existing vocabularies and use prefixes to refer to vocabularies. The following is a list of all vocabularies and their prefix abbreviations, as used in this document:

• The Dublin Core vocabulary (abbreviation: dc, e.g., dc:title)
• The Friend of a Friend vocabulary (abbreviation: foaf, e.g., foaf:knows)
• The RDF vocabulary (abbreviation: rdf, e.g., rdf:type)
• The XSD vocabulary (abbreviation: xsd, e.g., xsd:integer)

JSON [RFC4627] defines several terms which are used throughout this document:

JSON object

An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object should be unique.

array

An array is an ordered collection of values. An array structure is represented as square brackets surrounding zero or more values (or elements). Elements are separated by commas. Within JSON-LD, array order is not preserved by default, unless specific markup is provided. This is because the basic data model of JSON-LD is a linked data graph, which is inherently unordered.

string

A string is a sequence of zero or more Unicode characters, wrapped in double quotes, using backslash escapes. A character is represented as a single character string.

number

A number is is similar to that used in most programming languages, except that the octal and hexadecimal formats are not used and that leading zeros are not allowed.

true and false

Boolean values.

null

The use of the null value within JSON-LD is used to ignore or reset values.

subject definition

A JSON object used to represent a subject and one or more properties of that subject. A JSON object is a subject definition if it does not contain they keys @value, @list or @set and it has one or more keys other than @id.

subject reference

A JSON object used to reference a subject having only the @id key.

1.2 Linked Data

The following definition for Linked Data is the one that will be used for this specification.

1. Linked Data is a set of documents, each containing a representation of a linked data graph.
2. A linked data graph is an unordered labeled directed graph, where nodes are subjects or objects, and edges are properties.
3. A subject is any node in a linked data graph with at least one outgoing edge.
4. A subject should be labeled with an IRI (an Internationalized Resource Identifier as described in [RFC3987]).
5. An object is a node in a linked data graph with at least one incoming edge.
6. An object may be labeled with an IRI.
7. An object may be a subject and object at the same time.
8. A property is an edge of the linked data graph.
9. A property should be labeled with an IRI.
10. An IRI that is a label in a linked data graph should be dereferencable to a Linked Data document describing the labeled subject, object or property.
11. A literal is an object with a label that is not an IRI

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.

1.3 Contributing

There are a number of ways that one may participate in the development of this specification:

• Technical discussion typically occurs on the public mailing list: public-linked-json@w3.org
• Public teleconferences are held on Tuesdays at 1500UTC on the second and fourth week of each month.
• Specification bugs and issues should be reported in the issue tracker.
• Source code for the specification can be found on Github.
• The #json-ld IRC channel is available for real-time discussion on irc.freenode.net.

2.1 JsonLdProcessor

[NoInterfaceObject]
interface JsonLdProcessor {
    void expand (object or object[] or URL input, JsonLdCallback callback, optional JsonLdOptions options);
    void compact (object or object[] or URL input, object or URL context, JsonLdCallback callback, optional JsonLdOptions options);
    void frame (object or object[] or URL input, object or URL frame, JsonLdCallback callback, optional JsonLdOptions options);
    void fromRDF (Statement[] input, JsonLdCallback callback, optional JsonLdOptions options);
    void toRDF (object or object[] or URL input, ObjectOrURL? context, StatementCallback callback, optional JsonLdOptions options);
};

2.2 Callbacks

[NoInterfaceObject Callback]
interface JsonLdCallback {
    void jsonLd (ObjectOrObjectArray jsonld);
};

[NoInterfaceObject Callback]
interface StatementCallback {
    void statement (Statement statement);
};

2.3 Data Structures

This section describes datatype definitions used within the JSON-LD API.

typedef DOMString URL;

typedef object JsonLdOptions;

The following data structures are used for representing data about RDF statements (triples or quads). They are used for normalization, fromRDF, and from toRDF interfaces.

[NoInterfaceObject]
interface Statement {
    readonly attribute Node  subject;
    readonly attribute Node  property;
    readonly attribute Node  object;
    readonly attribute Node? name;
};

[NoInterfaceObject]
interface Node {
    readonly attribute DOMString nominalValue;
    readonly attribute DOMString interfaceName;
};

[NoInterfaceObject]
interface NamedNode : Node {
    readonly attribute DOMString nominalValue;
};

[NoInterfaceObject]
interface BlankNode : Node {
    readonly attribute DOMString nominalValue;
};

[NoInterfaceObject]
interface LiteralNode : Node {
    readonly attribute DOMString  nominalValue;
    readonly attribute DOMString? language;
    readonly attribute NamedNode? datatype;
};

3.1 Syntax Tokens and Keywords

JSON-LD specifies a number of syntax tokens and keywords that are using in all algorithms described in this section:

@context

Used to set the local context.

@id

Sets the active subject.

@language

Used to specify the language for a literal.

@type

Used to set the type of the active subject or the datatype of a literal.

@value

Used to specify the value of a literal.

@container

Used to set the container of a particular value.

@list

Used to express an ordered set of data.

@set

Used to express an unordered set of data.

@graph

Used to explicitly express a linked data graph.

:

The separator for JSON keys and values that use compact IRIs.

@default

Used in Framing to set the defeault value for an output property when the framed subject definition does not include such a property.

@explicit

Used in Framing to override the value of explicit inclusion flag within a specific frame.

@omitDefault

Used in Framing to override the value of omit default flag within a specific frame.

@embed

Used in Framing to override the value of object embed flag within a specific frame.

@null

>Used in Framing when a value of null should be returned, which would otherwise be removed when Compacting.

All JSON-LD tokens and keywords are case-sensitive.

3.2 Algorithm Terms

initial context

a context that is specified to the algorithm before processing begins. The contents of the initial context is defined in Appendix B.

active subject

the currently active subject that the processor should use when processing.

active property

the currently active property that the processor should use when processing. The active property is represented in the original lexical form, which is used for finding coercion mappings in the active context.

active object

the currently active object that the processor should use when processing.

active context

a context that is used to resolve terms while the processing algorithm is running. The active context is the context contained within the processor state.

blank node

a blank node is a resource which is neither an IRI nor a literal. Blank nodes may be named or unnamed and often take on the role of a variable that may represent either an IRI or a literal.

compact IRI

a compact IRI is has the form of prefix and suffix and is used as a way of expressing an IRI without needing to define separate term definitions for each IRI contained within a common vocabulary identified by prefix.

local context

a context that is specified within a JSON object, specified via the @context keyword.

processor state

the processor state, which includes the active context, active subject, and active property. The processor state is managed as a stack with elements from the previous processor state copied into a new processor state when entering a new JSON object.

JSON-LD input

The JSON-LD data structure that is provided as input to the algorithm.

JSON-LD output

The JSON-LD data structure that is produced as output by the algorithm.

term

A term is a short word defined in a context that may be expanded to an IRI

prefix

A prefix is a term that expands to a vocabulary base IRI. It is typically used along with a suffix to form a compact IRI to create an IRI within a vocabulary.

plain literal

A plain literal is a literal without a datatype, possibly including a language.

typed literal

A typed literal is a literal with an associated IRI which indicates the literal's datatype.

3.3 Context Processing

Processing of JSON-LD data structure is managed recursively. During processing, each rule is applied using information provided by the active context. Processing begins by pushing a new processor state onto the processor state stack and initializing the active context with the initial context. If a local context is encountered, information from the local context is merged into the active context.

The active context is used for expanding properties and values of a JSON object (or elements of a list (see List Processing)) using a term mapping. It is also used to maintain coercion mappings from terms to datatypes, language mappings from terms to language codes, and list mappings and set mappings for terms. Processors must use the lexical form of the property when creating a mapping, as lookup is performed on lexical representations, not expanded IRI representations.

A local context is identified within a JSON object having a @context property with a string, array or a JSON object value. When processing a local context, special processing rules apply:

1. Create a new, empty local context.
2. Let context be the value of @context
   1. If context equals null, reset the active context to the initial context.
   2. If context is an array, process each element as context in order by starting at Step 2.1.
   3. If context is a string, it must have a lexical form of absolute IRI.
      1. Dereference context.
      2. If the resulting document is a JSON document, extract the top-level @context element using the JSON Pointer "/@context" as described in [JSON-POINTER]. Set context to the extracted content and process it by starting at Step 2.1.
   4. If context is a JSON object, perform the following steps:
      1. If context has a @language property, it must have a value of a simple string or null. Add the language to the local context.
      2. Otherwise, for each property in context perform the following steps:
         1. If the property's value is a simple string, determine the IRI mapping value by performing IRI Expansion on the associated value. If the result of the IRI mapping is an absolute IRI, merge the property into the local context term mapping, unless the property is a JSON-LD keyword, in which case throw an exception.
         2. Otherwise, if the property's value is null remove mapping, coercion, container and language information associated with property from the local context.
         3. Otherwise, the property's value must be a JSON object.
            1. If the property is a JSON-LD keyword and the value has @id, @language or @type properties, throw an exception.
               Undecided if @type or @graph can take a @container with @set.
            2. If the property has the form of term, it's value must have an @id property with a string value which must have the form of a term, compact IRI, or absolute IRI. Determine the IRI mapping by performing IRI Expansion on the associated value. If the result of the IRI mapping is an absolute IRI, merge the property into the local context term mapping.
            3. If the property has the form of of a compact IRI or absolute IRI, the value may have a @id property with a string value which must have the form of a term, compact IRI, or absolute IRI. Determine the IRI mapping by performing IRI Expansion on the associated value. If the result of the IRI mapping is an absolute IRI, merge the property into the local context term mapping.
            4. If the value has a @type property, it's value must have the form of a term, compact IRI, absolute IRI, or the keyword @id. Determine the IRI by performing IRI Expansion on the associated value. If the result of the IRI mapping is an absolute IRI or @id, merge into the local context coercion mapping using the lexical value of the property.
            5. If the value has a @container property, it's value must be @list or @set. Merge the list mapping or set mapping into the local context using the lexical value of the property.
            6. If the value has a @language property but no @type property, the value of the @language property must be a string or null. Merge the language mapping into the local context using the lexical value of the property.
         4. Merge the local context into the active context.
         5. Repeat Step 2.4.2 until no entries are added to the local context.

It can be difficult to distinguish between a compact IRI and an absolute IRI, as a compact IRI may seem to be a valid IRI scheme. When performing repeated IRI expansion, a term used as a prefix may not have a valid mapping due to dependencies in resolving term definitions. By continuing Step 2.3.2 until no changes are made, mappings to IRIs created using an undefined term prefix will eventually resolve to absolute IRIs.

Issue 43 concerns performing IRI expansion in the key position of a context definition.

3.4 IRI Expansion

Keys and some values are evaluated to produce an IRI. This section defines an algorithm for transforming a value representing an IRI into an actual IRI.

IRIs may be represented as an absolute IRI, a term or a compact IRI.

An absolute IRI is defined in [RFC3987] containing a scheme along with path and optional query and fragment segments. A relative IRI is an IRI that is relative some other absolute IRI; in the case of JSON-LD this is the base location of the document.

The algorithm for generating an IRI is:

1. If the active context contains a term mapping for the value using a case-sensitive comparison, use the mapped value as an IRI.
2. Otherwise, split the value into a prefix and suffix from the first occurrence of ':'.
3. If the prefix is a '_' (underscore), the value represents a named blank node.
4. If the active context contains a term mapping for prefix using a case-sensitive comparison, and suffix does not does not begin with '//' (i.e., it does not match a hier-part including authority (as defined in [RFC3986]), generate an IRI by prepending the mapped prefix to the (possibly empty) suffix using textual concatenation. Note that an empty suffix and no suffix (meaning the value contains no ':' string at all) are treated equivalently.
5. Otherwise, use the value directly as an IRI.

Previous versions of this specification used @base and @vocab to define IRI prefixes used to resolve relative IRIs. It was determined that this added too much complexity, but the issue can be re-examined in the future based on community input.

3.5 IRI Compaction

Some keys and values are expressed using IRIs. This section defines an algorithm for transforming an IRI (iri) to a term or compact IRI using the terms specified in the active context using an optional value.

3.6 Value Expansion

Some values in JSON-LD can be expressed in a compact form. These values are required to be expanded at times when processing JSON-LD documents.

The algorithm for expanding a value takes an active property and active context. It is implemented as follows:

1. If value is a number and the active property is the target of typed literal coercion to xsd:integer or xsd:double, expand the value into an object with two key-value pairs. The first key-value pair will be @value and the string representation of value as defined in the section Data Round Tripping. The second key-value pair will be @type and the associated coercion datatype expanded according to the IRI Expansion rules.
2. Otherwise, if active property is @graph, or the target of an @id coercion, expand the value into an object with a key-value pair where the key is @id and the value is the expanded IRI according to the IRI Expansion rules.
3. Otherwise, if active property is the target of typed literal coercion, expand value into an object with key-value pairs. The first key-value pair will be @value and the unexpanded value. The second key-value pair will be @type and the associated coercion datatype expanded according to the IRI Expansion rules.
4. Otherwise, if value is a string and the active property is not the target of typed literal coercion but target of language tagging, expand value into an object with two key-value pairs. The first key-value pair will be @value and the unexpanded value. The second key-value pair will be @language and value of the language tagging from the active context.
5. Otherwise, value is already expanded.

3.7 Value Compaction

Some values, such as IRIs and typed literals, may be expressed in an expanded form in JSON-LD. These values are required to be compacted at times when processing JSON-LD documents.

The algorithm for compacting an expanded value value takes an active property and active context. It is implemented as follows:

1. If the value may be expressed as true, false or number, the value is the native representation of the @value value.
2. If active property is @graph, the compacted value is the value associated with the @id key, processed according to the IRI Compaction steps.
3. Otherwise, if the active context contains a coercion target for the key that matches the expression of the value, compact the value using the following steps:
   1. If the coercion target is an @id, the compacted value is the value associated with the @id key, processed according to the IRI Compaction steps.
   2. If the coercion target is a typed literal, the compacted value is the value associated with the @value key.
4. Otherwise, if value contains an @id key, the compacted value is value with the value of @id processed according to the IRI Compaction steps.
5. Otherwise, if the active context contains a @language, which matches the @language of the value, or the value has only a @value key, the compacted value is the value associated with the @value key.
6. Otherwise, if the value contains a @type key, the compacted value is value with the @type value processed according to the IRI Compaction steps.
7. Otherwise, the value is not modified.

3.8 Generate Blank Node Identifier

This algorithm is used by the Framing Algorithm and Convert From RDF Algorithm to deterministicly name blank node identifiers. It uses a identifier map and prefix and takes a possibly null identifier and returns a new identifier based on prefix.

The variable next identifier is initialized to prefix appended with 0.

1. If the old identifier is not null and is in identifier map return the mapped identifier.
2. Otherwise, if old identifier is not null, create a new entry in identifier map initialized to the current value of next identifier. Increment next identifier by adding one to the integer suffix. Return the mapped identifier.
3. Otherwise, increment next identifier by adding one to the integer suffix and return its original value.

3.9 Expansion

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.

For example, assume the following JSON-LD input document:

{
   "@context":
   {
      "name": "http://xmlns.com/foaf/0.1/name",
      "homepage": {
        "@id": "http://xmlns.com/foaf/0.1/homepage",
        "@type", "@id"
      }
   },
   "name": "Manu Sporny",
   "homepage": "http://manu.sporny.org/"
}

Running the JSON-LD Expansion algorithm against the JSON-LD input document provided above would result in the following output:

{
   "http://xmlns.com/foaf/0.1/name": "Manu Sporny",
   "http://xmlns.com/foaf/0.1/homepage": {
      "@id": "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 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 not in its most compact form. JSON-LD, via the API, provides a way to compact a JSON-LD document.

For example, assume the following JSON-LD input document:

{
  "http://xmlns.com/foaf/0.1/name": "Manu Sporny",
  "http://xmlns.com/foaf/0.1/homepage": {
    "@id": "http://manu.sporny.org/"
  }
}

Additionally, assume the following developer-supplied JSON-LD context:

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/homepage",
      "@type": "@id"
    }
  }
}

Running the JSON-LD Compaction algorithm given the context supplied above against the JSON-LD input document provided above would result in the following output:

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/homepage",
      "@type": "@id"
    }
  },
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/"
}

The compaction algorithm also enables the developer 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.

3.11 Framing

JSON-LD Framing allows developers to query by example and force a specific tree layout to a JSON-LD document.

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 JSON objects. While mapping a graph to a tree can be done, the layout of the end result must be specified in advance. A Frame can be used by a developer on a JSON-LD document to specify a deterministic layout for a graph.

Framing is the process of taking a JSON-LD document, which expresses a graph of information, and applying a specific graph layout (called a Frame).

Framing makes use of the Subject Flattening 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.

5.2 RDF Conversion Algorithm Terms

graph name

A IRI or Blank Node used to identify statements belonging to a named graph.

5.3 Convert to RDF Algorithm

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 Statements that the following algorithm generates:

The algorithm takes five 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. This removes any existing context to allow the given context to be cleanly applied.

1. If element is a JSON object, perform the following steps:
   1. Set active object to null.
   2. If element has a @value property, set the active object to a literal value as follows:
      1. As a typed literal if element contains a @type property after performing IRI Expansion on the specified @type.
      2. Otherwise, as a plain literal. If element contains a @language property, use it's value to set the language of the plain literal.
   3. If element has a @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
   4. If active object is not null:
      1. If nether active subject nor active property are null, generate a Statement representing active subject, active property, active object, and graph name.
      2. Return active object.
   5. If element has a @id property, the value must be a string, set the active subject to the previously expanded value (either a blank node or an IRI).
   6. Otherwise, if element does not have a @id property, set the active subject to newly generated blank node.
   7. Process each property and value in element as follows:
      1. If property is @type, set the active property to rdf:type.
      2. Otherwise, if property is @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.
      3. Otherwise, if property is a keyword, skip this step.
      4. Otherwise, set active property to the IRI value of property.
      5. Process value recursively using this algorithm, passing copies of active subject, active property and graph name.
   8. Set active object to active subject.
2. Otherwise, if element is an array, process each value in the array as follows, process element recursively using this algorithm, using copies of active subject, active property, and graph name.
3. Otherwise, if element is a string, set the active object to a plain literal value created from the string.
4. Otherwise, if element is a number, set the active object to a typed literal using a string representation of the value with datatype set to either xsd:integer or xsd:double, depending on if the value contains a fractional and/or an exponential component.
5. Otherwise, if element is true or false, set the active object to a typed literal created from the string representation of the value with datatype set to xsd:boolean.
6. If any of these steps created an active object and neither active subject nor active property are null, generate a Statement using active subject,active property, active object and graph name.
7. Return active object.

5.4 List Conversion

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.

1. If array is empty return rdf:nil.
2. Otherwise, generate a Statement using using the active subject, active property and a newly generated blank node identified as first blank node.
3. For each element in array other than the last element:
   1. Create a processor state using first blank node as the active subject, and rdf:first as the active property.
      1. Process the value starting at Step 1.
      2. Proceed using the previous processor state.
   2. Unless this is the last element in array, generate a new blank node identified as rest blank node, otherwise use rdf:nil.
   3. Generate a new Statement using first blank node, rdf:rest and rest blank node.
   4. Set first blank node to rest blank node.
   5. Return first blank node.

5.5 Convert from RDF Algorithm

In some cases, data exists natively in Triples or Quads form; 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 Statements into a JSON-LD document.

The conversion algorithm takes a single parameter input in the form of an array of Statement representations.

1. Construct a JSON array array to serve as the output object.
2. Construct a JSON object listMap to map graph names and subjects to objects derived from statements having a property of rdf:first.
3. Construct a JSON object restMap to map graph names and subjects to objects derived from statements having a property of rdf:rest.
4. Construct a JSON object subjectMap to map graph names and subjects to JSON object instances contained in array.
5. For each statement in input:
   1. If property is rdf:first, create a new entry in listMap with for name and subject and an array value containing object representation and skip to the next statement.
   2. If property is rdf:rest, and object is a BlankNode, create a new entry in restMap to map name and subject to a value being the result of IRI expansion on object and skip to the next statement.
   3. If name is not null:
      1. If subjectMap does not have an entry for null as name and name as subject:
         1. Create a new JSON object with key/value pair of @id and a string representation of name and use as value.
         2. Save value in subjectMap and append to array.
      2. Otherwise, use that entry as value.
      3. If value does not have an entry for @graph, initialize it as a new array ary.
      4. Otherwise, let ary be that array.
      5. If subjectMap does not have an entry for name and subject:
         1. Create a new JSON object with key/value pair of @id and a string representation of subject and use as value.
         2. Save value in subjectMap and append to ary.
      6. Otherwise, use that entry as value.
   4. Otherwise, if subjectMap does not have an entry for null as name and subject:
      1. Create a new JSON object with key/value pair of @id and a string representation of subject and use as value.
      2. Save value in subjectMap and append to array.
   5. Otherwise, use that entry as value.
   6. If property is rdf:type:
      1. Append the string representation of object to the array value for the key @type, creating an entry in value if necessary.
   7. Otherwise, if object is rdf:nil:
      1. Let key be the string representation of property.
      2. Set the value for key in value to an empty @list representation: {"@list": []}.
   8. Otherwise,
      1. Let key be the string representation of property and let object representation be object represented in expanded form as described in Value Expansion.
      2. Append object representation to the array value for key, creating an entry in value if necessary.
6. For each name, map in restMap:
   1. For each key/value prev, rest entry in map, append to the listMap value identified by name and prev the listMap value identified by name and rest.
7. For each name, map in listMap:
   1. For each key/value node, list, in map where list exists as a value of an object in array, replace the object value with list.
8. Return array as the graph representation in expanded form.