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

Re: The new charter is now in place

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Fri, 2 Oct 2020 10:40:44 -0400
To: "public-json-ld-wg@w3.org" <public-json-ld-wg@w3.org>
Message-ID: <129eadd2-bb1d-f426-1047-4f98de127a75@digitalbazaar.com>
On 10/2/20 7:09 AM, Pierre-Antoine Champin wrote:
>> 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.

Great! What I'd really like to do is merge the specs and work with you
to expand on the implementation and work we've done.

>>  (like, translating some types to CBOR native while not
>> touching other types).
> What other types do you have in mind?

It's detailed at a high level in the compressor section of the spec:


We have discovered that we can do compression based on declared `@type`
values in JSON-LD Contexts... that is, if you know the datatype for a
value, you can often compress it into a more compact binary form. We
left the compressor functionality fairly open ended... because there are
many different datatypes in Linked Data and some could benefit greatly
from binary compression (think of large numbers of lat/long coordinates,
large arrays of small numbers, vector fields, base-encoded data, etc.)

>> 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.

Yes, and the trade-off is very much worth it for our use cases. You can
always choose to embed the compression map in the CBOR-LD by rewriting
the @context, but then you lose the compression benefits for smaller
payloads... and we have many "small payload" use cases.

Pierre, do you think it would be possible to merge the specs and go
forward with one spec (without eliminating the ideas in each for now)?

-- manu

Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
Received on Friday, 2 October 2020 14:40:59 UTC

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