- From: Leonard Rosenthol <lrosenth@adobe.com>
- Date: Thu, 20 Aug 2020 19:10:47 +0000
- To: Manu Sporny <msporny@digitalbazaar.com>, "public-json-ld-wg@w3.org" <public-json-ld-wg@w3.org>
> 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
>
Provided that it isn't context-specific - I agree!!
But as you note - perhaps it is simply the existence of "conformance levels" or "profiles", where some are targeted to specific contexts (and pre-built dictionaries)...
Leonard
On 8/20/20, 1:52 PM, "Manu Sporny" <msporny@digitalbazaar.com> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fpresentation%2Fd%2F1ksh-gUdjJJwDpdleasvs9aRXEmeRvqhkVWqeitx5ZAE%2Fedit%23slide%3Did.g866980c4a6_0_14&data=02%7C01%7Clrosenth%40adobe.com%7Cbee153d9291d424fe86a08d84531d1cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637335427567321328&sdata=SKSaIzeFLlA42zvilvvBCxU2zAf3RJNhUfXCDtUzUu4%3D&reserved=0
and slide 10 (CBOR-LD (no compression). We could easily use
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fjson-ld-cbor%2F%23serialize&data=02%7C01%7Clrosenth%40adobe.com%7Cbee153d9291d424fe86a08d84531d1cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637335427567321328&sdata=l104fdVovreoNJP%2F%2FycAq2YedIxAM%2BcvysOotahCjRw%3D&reserved=0 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cbee153d9291d424fe86a08d84531d1cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637335427567321328&sdata=zbPzmZqsYaQhz1Ub6cx%2F0EQlWjz%2Fe6btDrdL8eKSR7I%3D&reserved=0
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&data=02%7C01%7Clrosenth%40adobe.com%7Cbee153d9291d424fe86a08d84531d1cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637335427567321328&sdata=PX4AuOzo6I3Wz9j7uUcqQgRP6cwdmy160lrstc%2BFFZs%3D&reserved=0
Received on Thursday, 20 August 2020 19:11:01 UTC