Re: The new charter is now in place

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 (like, translating some types to CBOR native while not
touching other types).

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.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

Received on Thursday, 20 August 2020 17:52:11 UTC