DRAFT JSON-LD Working Group Charter

The mission of the JSON-LD Working Group is to maintain and extend the family of JSON-LD Recommendations and related Working Group Notes.

Join the JSON-LD Working Group.

This draft charter is available on GitHub. Feel free to raise issues.

Charter Status	See the group status page and detailed change history.
Start date	[dd monthname yyyy] (date of the "Call for Participation", when the charter is approved)
End date	[dd monthname yyyy] (Start date + 2 years)
Chairs	Benjamin Young (Digital Bazaar)
Team Contacts	Pierre-Antoine Champin (0.1 FTE)
Meeting Schedule	Teleconferences: 1-hour calls will be held weekly. Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year.

Motivation and Background

JSON-LD (JavaScript Object Notation for Linked Data) is a widely used method of encoding Linked Data using JSON. Use of JSON-LD has grown and expanded over the last decade (since it's first publication as a W3C Recommendation in 2014). JSON-LD remains a popular choice for encoding SEO-focused structured data in Web pages using schema.org. JSON-LD has also become a foundational format for social media (ActivityStreams), Internet of Things data (Web of Things Description), Verifiable Credentials, or Software Bill of Materials (SPDX).

This growth in the applied use of JSON-LD has led to a community interest in additional expressions of JSON-LD's underlying Linked Data structure in other formats. YAML-LD has been created by the JSON for Linking Data Community Group to ease human authoring and to provide a clearer path for using Linked Data applied to popular YAML-based documents such as infrastructure as code, static site front matter, and API documentation formats.

For a number of application areas, the size of JSON-LD content is an obstacle. Size constraints may be encountered when storing data as a QR or in a barcode, transmitting data over low bandwidth channels, or when relying on high volume data storage. These constraints are not only significant for existing applications, but are also obstacles to enable new application areas (e.g., in embedded systems). CBOR-LD, based on CBOR (which already has a large user and tool base), can exploit the linked data features of JSON-LD, and provide a high level and easily reversible compression of JSON-LD data. Work on CBOR-LD has begun in the JSON for Linking Data Community Group, and will be finalized by the JSON-LD Working Group.

The goal of this new, more inclusively focused JSON-LD WG is to meet the demand of the broader JSON-LD community by strengthening the foundational JSON-LD specifications, growing the family of JSON-LD related formats which orbit around the JSON-LD processing model, and specifying improved context retrieval methods for greater clarity and stability.

Scope

The Working Group will evolve the recommendations defining JSON-LD (i.e., JSON-LD 1.1, JSON-LD 1.1 API, and JSON-LD 1.1 Framing) by handling Errata and by adding requested features, as recorded on the group's Project Management Page. In order to handle these, the Working Group will issue new versions of these recommendations, possibly with new features, in order to make future usage and evolutions easier. In particular, the Working Group will handle two important security related problems:

JSON-LD has become a common structural foundation for a wide range of data models. Some of those environments have more restrictive requirements than others on how unmapped terms should be treated (i.e., when JSON keys present in the document have no term definition in the context). The current JSON-LD API stipulates that the unknown term is silently ignored. The Working Group will specify a "safe mode", that will detect these situations and cause the processing to fail instead. This mode is already available in some JSON-LD API implementations, such as jsonld.js and dotNetRDF, and is especially useful if the resulting RDF Graph is to be canonicalized.
External (i.e., non-inline) JSON-LD context files are identified using URIs. This is a common pattern across many technologies that has, at times, confused implementers who expect that they should always use these identifiers as locators, and dereference them. This assumption can create risks and vulnerabilities that have been documented, but also often overlooked, in previous versions of JSON-LD. The Working Group intends to address this problem through more explanatory specification text, but also through the exploration of options such as the addition of a hash fragment to be used with the application/ld+json media type responses. This fragment conveys a content hash which may be used by implementations to further confirm and handle the intentions of the original document author. (This has already been discussed by the Working Group, see, for example, the open issues 108, 436 or 422.)

Development of the 1.2 versions of the JSON-LD specifications will follow the principle of backward compatibility. This means that any valid JSON-LD 1.1 document will remain valid for JSON-LD 1.2, and that the algorithms defined by the JSON-LD 1.2 API specification will yield isomorphic results to those of the JSON-LD 1.1 API — barring any bug or inconsistency of the JSON-LD 1.1 specifications identified in the errata.

The Working Group will also develop new Recommendation Track deliverables, based on work incubated by the JSON for Linking Data Community Group, specifying the use of JSON-LD algorithms with similar formats (YAML and CBOR).

The Working Group is expected to coordinate with the JSON for Linking Data Community Group on consensus-based proposals related to content changes for the JSON-LD Working Group Deliverables. The Chairs of this group may choose to reject proposals that are incompatible with this Charter.

Finally, the Working Group will start working on the introduction of the new RDF 1.2 concepts (primarily triple terms and directional language-tagged string), into the JSON-LD syntax, API, and Framing. The final goal is to have, eventually, a version of JSON-LD that is fully compatible with the upcoming RDF 1.2 version, and provides shortcuts similar to those in RDF 1.2 Turtle (e.g., reifying triple or triple annotations). This will be done in strong cooperation with the RDF & SPARQL Working Group.

Out of Scope

The following features are out of scope, and will not be addressed by this Working Group.

Linked Data Signatures.

Deliverables

Updated document status is available on the group publication status page.

Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.

Normative Specifications

The Working Group will deliver the following W3C normative specifications:

JSON-LD 1.2

This specification will define a new version of JSON-LD, including improvements as listed in the Scope Section above.

Draft state: Adopted from JSON-LD 1.1 Recommendation.

Expected completion: Q4 2027.

Initial Text: JSON-LD 1.1, https://www.w3.org/TR/2020/REC-json-ld11-20200716/, 16 July 2020.

JSON-LD 1.2 Processing Algorithms and API

This specification will define a new version of JSON-LD Processing Algorithms and API, including improvements as listed in the Scope Section above.

Draft state: Adopted from JSON-LD 1.1 Processing Algorithms and API Recommendation.

Expected completion: Q4 2027.

Initial Text: JSON-LD 1.1 Processing Algorithms and API, https://www.w3.org/TR/2020/REC-json-ld11-api-20200716/, 16 July 2020.

JSON-LD 1.2 Framing

This specification will define a new version of JSON-LD Framing, including improvements as listed in the Scope Section above.

Draft state: Adopted from JSON-LD 1.1 Framing Recommendation.

Expected completion: Q4 2027.

Initial Text: JSON-LD 1.1 Framing, https://www.w3.org/TR/2020/REC-json-ld11-framing-20200716/, 16 July 2020.

YAML-LD 1.0

This document defines YAML-LD, a set of conventions built on top of YAML, which outlines how to serialize Linked Data as YAML based on JSON-LD syntax, semantics, and APIs.

Draft state: adopted from the JSON for Linking Data Community Group.

Expected completion: Q1 2027.

Adopted Draft: YAML-LD, Final Community Group Report (2023-12-06)

CBOR-LD 1.0

This specification defines CBOR-LD, a CBOR-based format to serialize Linked Data. The encoding is designed to leverage the existing JSON-LD ecosystem, to provide a compact serialization format for those seeking efficient encoding schemes for Linked Data.

Draft state: adopted from the JSON for Linking Data Community Group.

Expected completion: Q1 2027.

Adopted Draft: CBOR-LD, Community Group Draft Report (2025-05-09)

Tentative Deliverables

Depending on the incubation progress, interest from multiple implementers, and the consensus of the Group participants, the Working Group may adopt the following documents as Rec-track specifications, all related to the compatibility of JSON-LD with RDF 1.2:

JSON-LD 1.3

This specification will define a new version of JSON-LD, fully compatible with JSON-LD 1.2 and RDF 1.2.