Compacted form for the "Serialize RDF as JSON-LD Algorithm"

[multimeric]

In Section 8.4 we have the RDF to JSON-LD algorithm, which specifies that it outputs "a JSON-LD document in expanded form". The issue with this is that users may prefer a compact serialisation, and it seems sub-optimal to first serialise to expanded form and then compact it. Therefore, I wonder if it would be possible for the spec to either rewrite this algorithm to have a configurable form, or alternatively to include a compact serialisation algorithm that is an explicit alternative. In either case, compact form serialisation would require not only the RDF graph but also the context.

Python's rdflib already broadly implements this by allowing context and/or auto_compact arguments to be passed to the serialiser, but I find it strange that this is not specified in the spec.

[gkellogg]

Generally, in addition to compacting, it is useful to frame the result as well. My implementation allows either a frame option or a context option to be specified, as well as a simple map of prefixes to IRIs from which a context can be created. But, this is outside of the spec, itself.

The JSON-LD API Editors' Draft has updated the WebIDL interface to accept and return just the native/internal representation, and separate out the serialization and deserialization steps, as this is important for supporting YAML-LD and CBOR-LD formats. This makes separating the toJson and Compact/Frame as separate algorithms which work on the internal representation easier and eliminates the need for multiple serialization/deserialization steps.

[w3cbot]

This was discussed during the #json-ld meeting on 04 June 2025.

View the transcript

w3c/json-ld-api#659

Issue 659 Compacted form for the "Serialize RDF as JSON-LD Algorithm" (by multimeric)

gkellogg: this was a request related to flattening and framing
… that implies that maybe we could add some options to flattening
… my response was that recent changes should make it easier to get the original representation
… so stringing these algorithms together is still possible, but can now be shortened
… so I'd suggest we close this with no change

PROPOSAL: Close w3c/json-ld-api#659 with no change, as the ability to get the native form out of the API gets around the duplication.

+1

gkellogg: since this is really on the RDF side, my code handles it there
… it makes use of the JSON-LD algorithm

+1

gkellogg: for instance, I can pass in prefix mapping and use it later with contexts and frames
… I think trying to be a swiss army knife in the spec is not helpul

+1

+1

gkellogg: and this should be left to implementations

+1

+1

RESOLUTION: Close w3c/json-ld-api#659 with no change, as the ability to get the native form out of the API gets around the duplication.

Issue 659 Compacted form for the "Serialize RDF as JSON-LD Algorithm" (by multimeric)

gkellogg: shall we look at a few more?
… anything specific someone wants to discuss?

pchampin:

---

[gkellogg]

You can see the discussion in #659 (comment). The group is trying to keep algorithms specific and not try to do too much. The ability to get back the native data from the API endpoints, and provide them as inputs, reduces the amount of work needed to invoke different algorithms, but implementations may do their own things to combine steps.