- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Thu, 20 Aug 2020 13:58:05 -0700
- To: Leonard Rosenthol <lrosenth@adobe.com>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, "public-json-ld-wg@w3.org" <public-json-ld-wg@w3.org>
- Message-Id: <337DDC33-1EAE-4FD1-9713-14CE47167CB4@greggkellogg.net>
> On Aug 20, 2020, at 12:10 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote: > >> 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)... Perhaps we can describe mechanism for creating versioned/cached/optimized contexts, with a default managed by the group, along with a way to validate and update context versions. It should allow others to create their own context set, and how to achieve and measure the resulting compaction. Gregg > Leonard > > > On 8/20/20, 1:52 PM, "Manu Sporny" <msporny@digitalbazaar.com <mailto: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 <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 <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 <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 <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 20:58:21 UTC