Re: The new charter is now in place

This email has been lingering in my inbox way too long, apologies for that.

On 20/08/2020 19:51, Manu Sporny 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://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
That document was intended as the starting point for discussion. Any
feedback is of course very welcome.
>  (like, translating some types to CBOR native while not
> touching other types).
What other types do you have in mind?
> 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.

Of course. This was the goal of section 4
<https://w3c.github.io/json-ld-cbor/#optimize>. IIUC, you pushed the
idea even further by moving the "compression map" outside the document,
and rely on out-of-band knowledge to retrieve it? I am a bit concerned
about the "out-of-band" part, but I guess this is a matter of trade-off
between efficiency and self-sufficiency.

  pa

>
> -- manu
>