JSON-LD Working Group Charter

JSON-LD Working Group Charter
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.
Charter Status
See the
group status page
and
detailed change history
Start date
06 January 2026
End date
31 January 2028
Chairs
Victor Lu (Invited Expert)
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 columns 4 ("Errata") and 5 ("Future Work")
of the group's
Project Management Page
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, namely YAML and CBOR.
These formats will provide reversible serializations/compressions to JSON-LD 1.2.
Other formats may be incubated in conjunction with the Community Group, but will not be part of
Recommendation track deliverables.
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.
The Working Group will also produce some informational text clarifying further when application
developers are advised to use JSON-LD's data modeling and term mapping, as opposed to "plain" JSON documents. It has not yet
been decided whether this will become part of one the current Recommendations, or will be the subject of a
separate Working Group Note.
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,
, 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,
, 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,
, 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
Draft state:
Proposal in
JSON-LD Star
, JSON for Linked Data Community Group Draft Report.
JSON-LD 1.3 Processing Algorithms and API
This specification will define a new version of JSON-LD API, fully compatible with JSON-LD 1.2 API and
RDF 1.2
Draft state:
Proposal in
JSON-LD Star
, JSON for Linked Data Community Group Draft Report.
JSON-LD 1.3 Framing
This specification will define a new version of JSON-LD Framing, fully compatible with JSON-LD 1.2 Framing and
RDF 1.2
Draft state:
Proposal in
JSON-LD Star
, JSON for Linked Data Community Group Draft Report.
YAML-LD 1.1
This specification will define a new version of YAML-LD, fully compatible with YAML-LD 1.0 and
RDF 1.2
Draft state:
Proposal in
JSON-LD Star
, JSON for Linked Data Community Group Draft Report.
CBOR-LD 1.1
This specification will define a new version of CBOR-LD, fully compatible with CBOR-LD 1.0 and
RDF 1.2
Draft state:
Proposal in
JSON-LD Star
, JSON for Linked Data Community Group Draft Report.
Other Deliverables
Other non-normative documents may be created and/or maintained such as:
Application profile of JSON-LD to enable efficient streaming parsers.
Test suites and implementation reports for the specifications.
Best practices for use and implementation of JSON-LD 1.1, 1.2 and, possibly, 1.3.
Timeline
January 2026: First teleconference
Q2 2026
FPWD of CBOR-LD
FPWD of YAML-LD
FPWD of JSON-LD 1.2
FPWD of JSON-LD 1.2 API
FPWD of JSON-LD 1.2 Framing
Q4 2026
Candidate Recommendation of CBOR-LD
Candidate Recommendation of YAML-LD
Q1 2027
Recommendation of CBOR-LD
Recommendation of YAML-LD
Q3 2027
Candidate Recommendation of JSON-LD 1.2
Candidate Recommendation of JSON-LD 1.2 API
Candidate Recommendation of JSON-LD 1.2 Framing
Q4 2027
Recommendation of JSON-LD 1.2
Recommendation of JSON-LD 1.2 API
Recommendation of JSON-LD 1.2 Framing
Success Criteria
In order to advance beyond
Candidate Recommendation
, each normative specification is expected to have
at least two independent interoperable implementations
of every feature defined in the specification, where interoperability can be verified by passing open test suites. In order to advance beyond Candidate Recommendation, each normative specification must have an open test suite of every feature defined in the specification.
There should be testing plans for each specification, starting from the earliest drafts.
To promote interoperability, all changes made to specifications
in Candidate Recommendation
or to features that have deployed implementations
should have
tests
Each specification should contain separate sections detailing all known security and privacy implications for implementers, Web authors, and end users.
This group is expected to be guided by the following documents:
Ethical Web Principles
Privacy Principles
Web Platform Design Principles
Coordination
For all specifications, this Working Group will seek
horizontal review
for
accessibility, internationalization, privacy, and security with the relevant Working and
Interest Groups, and with the
TAG
Invitation for review must be issued during each major standards-track document transition, including
FPWD
. The
Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of
each specification. The Working Group is advised to seek a review at least 3 months before first entering
CR
and is encouraged
to proactively notify the horizontal review groups when major changes occur in a specification following a review.
Additional technical coordination with the following Groups will be made, per the
W3C Process Document
W3C Groups
JSON for Linking Data Community Group
As mentioned in the scope section, the Working Group is expected to coordinate with this Community Group on consensus-based proposals related to content changes for the JSON-LD Working Group Deliverables. The Chairs of the Working Group may choose to reject proposals that are incompatible with this Charter.
RDF & SPARQL Working Group
The work of this Group will provide the ability to concisely represent in JSON-LD all features defined in
RDF 1.2
, and this will be done in cooperation with the
RDF & SPARQL Working Group.
Verifiable Credentials Working Group
Coordination on named graph indexing and other concerns regarding support for normalization and digital signatures.
Decentralized Identifiers Working Group
Coordination on various concerns regarding the JSON-LD encoding of DID Documents.
Web of Things Working Group
Coordination of various topics concerning the use of JSON-LD by the WoT Thing Description.
Credentials Community Group
Coordination on various concerns regarding the usage of JSON-LD in Verifiable Credentials
and related Community Group specifications.
External Organizations
IETF CBOR Working Group
Coordinating on the CBOR-LD specification.
YAML Language Development Team
Coordinating on the YAML-LD specification.
Participation
To be successful, this Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the Working Group. There is no minimum requirement for other Participants.
The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in
Communication
The group also welcomes non-Members to make technical contributions for ongoing work, provided they agree to the terms of the
W3C Patent Policy
The Chairs should periodically look through the non-Members who have contributed to the Working Group or the JSON for Linking Data Community Group and consider whether each one should be invited to participate as an
Invited Expert
. If a non-Member contributor would like to participate in meetings, they are encouraged to
apply to be an Invited Expert
Participants in the group are required (by the
W3C Process
) to follow the W3C
Code of Conduct
Communication
Technical discussions for this Working Group are conducted in
public
: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed in public repositories and may permit direct public contribution requests.
The meetings themselves are not open to public participation, however.
Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the
JSON-LD Working Group home page.
Most JSON-LD Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.
This group primarily conducts its technical work on
GitHub issues
The public is invited to review, discuss and contribute to this work.
The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.
Decision Policy
This group will seek to make decisions through consensus and due process, per the
W3C Process Document (section 5.2.1, Consensus)
. Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.
However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.
To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional.

A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period of
10 working days
, depending on the chair's evaluation of the group consensus on the issue.

If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.
All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs.
This charter is written in accordance with the
W3C Process Document (Section 5.2.3, Deciding by Vote)
and includes no voting procedures beyond what the Process Document requires.
Patent Policy
This Working Group operates under the
W3C Patent Policy
(Version of 15 May 2025). To promote the widest adoption of Web standards, W3C seeks to issue Web specifications that can be implemented, according to this policy, on a Royalty-Free basis.

For more information about disclosure obligations for this group, please see the
licensing information
Licensing
This Working Group will use the
W3C Software and Document license
for all its deliverables.
About this Charter
This charter has been created according to
section 3.4
of the
Process Document
. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
Charter History
The following table lists details of all changes from the initial charter, per the
W3C Process Document (section 4.3, Advisory Committee Review of a Charter)
Charter Period
Start Date
End Date
Changes
Initial Charter
15 June 2018
15 June 2020
none
Maintenance WG Charter
12 August 2020
31 August 2022
New Charter approved on 12 August 2020
Change of staff contact
Philippe le Hégaret appointed as new staff contact
Extension
1 September 2022
30 November 2022
Rechartered
19 January 2023
31 January 2025
Switch to Patent Policy 2020. Added RCH and RDF-Star to coordination section
Change of staff contact
Pierre-Antoine Champin appointed as new staff contact
Chair re-appointed
Benjamin Young re-appointed as the group chair
Extension
01 February 2025
31 July 2025
Extension, new co-chair
07 August 2025
30 November 2025
Gregg Kellogg appointed as co-chair
Extension
4 November 2025
30 May 2026
Rechartered
06 January 2026
31 January 2028
New charter with new deliverables. Change of co-chairs: Victor Lu and Benjamin Young
Change log
Changes to this document are documented in this section.