CBOR-LD musings

So far, we have two different CG specs that discuss CBOR-LD, in different ways:

* JSON-LD in CBOR [1] – Mostlly about transforming from the JSON-LD Internal Representation in to CBOR, with provisions for xsd:integer and xsd:base64Binary. It also prposes an rdf:CBOR datatype, which I personally don’t feel is warranted.

* CBOR-LD 1.0 [2] – Mostly about serialize a JSON-LD map to CBOR in either an uncompressed or compressed form by creating short map keys taken from an index into an applicationTermMap constructed by enumerating terms defined in referenced contexts. This does not support JSON-LD in an array form, or JSON-LD maps with inline contexts (which needs expanding). It also does not specify how to turn this from CBOR back into JSON (or the internal representation), although it could be considered to be symetric to the Compressed CBOR-LD Buffer Algorithm. It also depends on something like a Magic number, which doesn’t seem to exist in CBOR otherwise 

CBOR-LD also defines a Term Codec Registry, although I don’t see how it comes into play through the algorithms.

Neither of these are as complete as YAML-LD, which provides a mechanism parallel to the JSON-LD 1.1 API, just using YAML instead of JSON.

I think the compression can be added as a separate set of algorithms to a basic CBOR-LD spec, patterned off of YAML-LD, which can be optionally invoked from the Compaction and Expansion algorithms. I don’t understand why CBOR doesn’t use some form of magic number to identify the altorighm, but we probably need to do something like this, but it should tolerate forms that use an outer array as well as map.

It would be great to have a discussion on DB’s CBOR-LD spec to understand what it is trying to do.

Gregg Kellogg
gregg@greggkellogg.net

[1] https://w3c.github.io/json-ld-cbor
[2] https://digitalbazaar.github.io/cbor-ld-spec/

Received on Monday, 27 November 2023 23:29:11 UTC