That is exactly what I was getting at Benjamin - thanks for expounding on it!! Leonard From: Benjamin Young <byoung@digitalbazaar.com> Date: Wednesday, March 18, 2026 at 1:13 PM To: Manu Sporny <msporny@digitalbazaar.com>, Leonard Rosenthol <lrosenth@adobe.com> Cc: Ivan Herman <ivan@w3.org>, JSON-LD Working Group <public-json-ld-wg@w3.org>, Wesley Smith <wsmith@digitalbazaar.com> Subject: Re: Re: CBOR-LD w/o JSON-LD? EXTERNAL: Use caution when clicking on links or opening attachments. Hi all, (Also great to chat again, Leonard. :) ) My understanding (so far) is that CBOR-LD's greatest strength comes from the "semantic compression" which doesn't require any conversion to JSON(-LD), but does require the use of a term map provided via one or more context files. Essentially, the baseline CBOR-LD processing takes term URLs defined in the referenced/loaded contexts and assigns them to integers. So, for the greatest value (versus "just CBOR" compression), a context file(s) provides the ability to shrink the string-based key names (and certain values) in a CBOR-LD document down to integers in the CBOR-LD. It's conceivable that once you'd done the mapping in a context (and/or additional registry entry) one could write a CBOR "side" processor for that consistently string-to-integer mapped output/encoding without going to JSON-LD. Is that where you were aiming, Leonard? Or am I missing the trajectory? Basically, once "solidified" for your "type" of CBOR-LD document--which would be defined by context definition and (most likely) a registry entry--you'd have a fixed CBOR "shape" that you could build around without explicitly requiring JSON-LD processing. Happy to hear more, though, in case I've missed the objective here. :) Cheers! Benjamin -- https://linkedin.com/in/benjaminyoung Developer Engagement Engineer Digital Bazaar<https://digitalbazaar.com/>
Received on Wednesday, 18 March 2026 18:20:03 UTC