Re: The new charter is now in place

> 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&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cbee153d9291d424fe86a08d84531d1cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637335427567321328&amp;sdata=SKSaIzeFLlA42zvilvvBCxU2zAf3RJNhUfXCDtUzUu4%3D&amp;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&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cbee153d9291d424fe86a08d84531d1cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637335427567321328&amp;sdata=SKSaIzeFLlA42zvilvvBCxU2zAf3RJNhUfXCDtUzUu4%3D&amp;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&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cbee153d9291d424fe86a08d84531d1cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637335427567321328&amp;sdata=l104fdVovreoNJP%2F%2FycAq2YedIxAM%2BcvysOotahCjRw%3D&amp;reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fjson-ld-cbor%2F%23serialize&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cbee153d9291d424fe86a08d84531d1cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637335427567321328&amp;sdata=l104fdVovreoNJP%2F%2FycAq2YedIxAM%2BcvysOotahCjRw%3D&amp;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&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cbee153d9291d424fe86a08d84531d1cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637335427567321328&amp;sdata=zbPzmZqsYaQhz1Ub6cx%2F0EQlWjz%2Fe6btDrdL8eKSR7I%3D&amp;reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cbee153d9291d424fe86a08d84531d1cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637335427567321328&amp;sdata=zbPzmZqsYaQhz1Ub6cx%2F0EQlWjz%2Fe6btDrdL8eKSR7I%3D&amp;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&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cbee153d9291d424fe86a08d84531d1cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637335427567321328&amp;sdata=PX4AuOzo6I3Wz9j7uUcqQgRP6cwdmy160lrstc%2BFFZs%3D&amp;reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cbee153d9291d424fe86a08d84531d1cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637335427567321328&amp;sdata=PX4AuOzo6I3Wz9j7uUcqQgRP6cwdmy160lrstc%2BFFZs%3D&amp;reserved=0>

Received on Thursday, 20 August 2020 20:58:21 UTC