W3C home > Mailing lists > Public > public-json-ld-wg@w3.org > October 2020

Re: The new charter is now in place

From: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>
Date: Fri, 2 Oct 2020 13:09:49 +0200
To: Manu Sporny <msporny@digitalbazaar.com>, "public-json-ld-wg@w3.org" <public-json-ld-wg@w3.org>
Message-ID: <90ea9825-d092-446c-ea97-d0a6a72bfd13@ercim.eu>
This email has been lingering in my inbox way too long, apologies for that.

On 20/08/2020 19:51, Manu Sporny wrote:
> On 8/20/20 1:30 PM, Leonard Rosenthol wrote:
>> While I would like to see the group come up with an official CBOR-LD
>> spec, I think itís focus should be closer to what we already have [1].
>> It should mostly concern itself with transforming between CBOR and our
>> Internal representation [2]. It should also likely deal with intermixing
>> CBOR-LD and JSON-LD resources, so that a JSON-LD context might be used
>> in a CBOR-LD document and visa-versa.
> Note that the CBOR-LD proposal already incorporates this desire
> (although, not very well documented). That is called "uncompressed
> CBOR-LD", which is basically just a direct mapping of the JSON-LD
> document to CBOR and back.
> We covered this during the presentation on slide 6 -- CBOR-LD (raw):
> https://docs.google.com/presentation/d/1ksh-gUdjJJwDpdleasvs9aRXEmeRvqhkVWqeitx5ZAE/edit#slide=id.g866980c4a6_0_14
> and slide 10 (CBOR-LD (no compression). We could easily use
> https://w3c.github.io/json-ld-cbor/#serialize for that purpose. That
> said, there are a number of things that the given algorithm does that
> are concerning
That document was intended as the starting point for discussion. Any
feedback is of course very welcome.
>  (like, translating some types to CBOR native while not
> touching other types).
What other types do you have in mind?
> So, feels like we can merge the specs for the most part, no problem.
> We'd be opposed to a solution that doesn't greatly reduce the size of
> the initial JSON-LD document, however, as if we don't do that, many of
> the compelling reasons to use CBOR disappear.

Of course. This was the goal of section 4
<https://w3c.github.io/json-ld-cbor/#optimize>. IIUC, you pushed the
idea even further by moving the "compression map" outside the document,
and rely on out-of-band knowledge to retrieve it? I am a bit concerned
about the "out-of-band" part, but I guess this is a matter of trade-off
between efficiency and self-sufficiency.

† pa

> -- manu

Received on Friday, 2 October 2020 11:09:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:57:51 UTC