// See https://github.com/w3c/respec/wiki/ for how to configure ReSpec

TODO in the end

This is an unofficial proposal.


The [[[RFC7049]]] [[RFC7049]] is a data format for constrained environments. It is designed to be processable with small code, and to produce small messages. Its underlying data model is an extension of the JSON data model [[RFC8259]]. That makes it an possible format to transport JSON-LD documents, in constrained contexts such as, e.g., the Web of Things. It also allows JSON-LD contexts to be used to provide a layer of semantics on existing CBOR data.

More specifically, this note specifies how to convert between the CBOR data format and the JSON-LD internal representation (a is straightforward abstraction of the JSON format using the following terms, which are only included here to please ReSpec, but should not be displayed: array, boolean, map, entries, null, number, long, double, scalar, string ). Since CBOR emphasizes small messages, we also propose a number of techniques for reducing the size of messages.

To understand this note you must be familiar both the JSON format [[RFC8259]] and the CBOR format [[RFC7049]]. You must also understand the basics of JSON-LD 1.1 [[JSON-LD11]].

Serializing JSON-LD to CBOR

While being generally based on the JSON data model, the CBOR specification does not specify a standard conversion between both models. This is due in part to the fact that the CBOR model is an extension of the former. In this section, we provide a complete specification of such a conversion, following the guidelines from §4.2 of RFC7049, and taking into account the particularities of JSON-LD.

Parsing CBOR to JSON-LD

This section describes how to parse CBOR data into the JSON-LD internal representation, following the guidelines from §4.1 of RFC7049. It is the inverse process of the one described in .

  • A data item with major type 6 (semantic tag) is generally ignored; its following value is simply parsed by recursively applying these rules.
  • A data item with major type 7 (primitive) is parsed as Any other additional type value must raise an error.
  • CBOR-specific optimization of JSON-LD data


    JSON-LD semantic tag

    TODO propose numeric aliases for keywords, and possibly often used IRIs?

    Designing contexts for CBOR

    TODO do no alias keywords, do not use type coercion, define small prefixes, more...

    The `rdf:CBOR` datatype

    The intent of this datatype is to make it possible to convey CBOR data as RDF literals. It is defined as a subset of the `xsd:base64Binary` datatype.

    The rdf:CBOR datatype is defined as follows:

    The IRI denoting this datatype
    is `http://www.w3.org/1999/02/22-rdf-syntax-ns#CBOR`.
    The lexical space
    is the subset of the lexical space of `xsd:base64Binary`, for which the lexical mapping produces well-formed CBOR data [[RFC7049]].
    The value space
    is the set of finite-length sequences of zero or more binary octets, which are well-formed CBOR data [[RFC7049]].
    The lexical-to-value mapping and canonical mapping
    are the ones defined for the `xsd:base64Binary` datatype [[XSD]].