- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 20 Aug 2020 13:51:57 -0400
- To: public-json-ld-wg@w3.org
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