Re: Saying yes to making @context optional

I could be wrong but it seems that this thread is talking about two quite
different things

   1. What's an ideal serialisation format for VCs? (the CBOR vs Base64
   JSON story).  Good discussion.  I like CBOR too but also dont have any
   objection to JSON, especially for my use cases in cross border trade where
   we want a syntax that is easy to consume and easy to use as the source for
   human rendered versions.
   2. Should VCs contain semantic anchors such as JSON-LD @contect
   references?  Different question.  I note too that the proponents of the
   CBOR version were keen to emphasize the ability to include semantic triples
   - which did confuse me a bit because it sounded like "we don't like JSON-LD
   (which links VC content ot semantic definitions) but we do like CBOR with
   embedded RDF triples (which also links VC content to semantic definitions).
   Sounds like you are saying you like semantic anchors but just don't like
   the way JSON-LD does it?

On the second question, I've often been asked "why do we need that JSON-LD
stuff, why not just use a JSON Schema?".  My answer to that is based on a
nirvana that I've yet to see really working but still hold out hope that
it's true.  That is the ability for a verifier to do some run-time
reasoning over a VC content without necessarily having some design-time
mapping to a specific Schema.  THis is especially interesting for
decentralised architectures like VCs where there are likely to be a
proliferation of slightly different schema.  For example a
cross-border preferential certificate of origin.  100's of different free
trade agreements (FTA) and it won't surprise me if there is a variant of a
core schema for each FTA (in some FTA this or that field is mandatory,
optional, not required).  As a border authority verifier I really don't
care too much about all the content variations, I just want to get the
consignment reference and the origin criteria for machine processing.  The
rest can go in a blob box for possible human audit.  So the idea of just
looking for a couple of vocabulary terms instead of building specific
mappings and validations to 100 slightly different schema is very
appealing.

Of course this whole argument only works if all these different schema are
built from a small number of reference vocabularies.  If you roll your own
vocabulary at the same time as you roll your own schema then you may as
well not have bothered.  That does entail a different mindset from schema
designers - which may not be easy to establish.  It also requires that
useful reference vocabularies exist.  There is schema.org of course for
most generic things you find on the web.  For the specifics of cross border
trade the standards authority is UN/CEFACT - but they have been a bit
behind the wave with vocabulary publishing so it's quite understandable
that working groups in W3C come up with their own - such as this
https://w3c-ccg.github.io/traceability-vocab/.  But I'm pleased to say that
the UN is catching up and there is now a draft vocabulary here
https://vocabulary.uncefact.org/.  Unfortunately it's not the highest
quality vocabulary because it wasn't designed for semantic anchoring from
the start (so has some definitions that are too abstract like
"transportMeans" that is used to mean "Truck", "Flight", "Vessel", Barge",
etc - but you need a separate type code to understand that.  Anyhow, the
next step is to fix up that UN vocabulary to address those EDIFACT - era
weaknesses.  Then it'll be a usable vocabulary from an actual authority.
And then maybe, just maybe, people will use it to anchor the properties in
their cross border trade document schema.

Anyhow - all this is longhand for my hope that we do *NOT* throw
out @context before we've even given it a chance to work.

Kind regards
Steve



On Mon, 28 Nov 2022 at 17:34, Christopher Allen <
ChristopherA@lifewithalacrity.com> wrote:

> On Sun, Nov 27, 2022 at 10:16 PM Anders Rundgren <
> anders.rundgren.net@gmail.com> wrote:
>
>> CBOR + Deterministic serialization!
>> This is the s**t, finally get rid of Base64 (JOSE) or putting everything
>> crypto-ish in "bstr" (COSE).
>>
>> Trivial to do, works like charm, and makes ASN.1 DER look like rocket
>> science.
>
>
> Thanks. I’m pleased with it.  Part of the reason I didn’t take a strong
> position on the JWT vs JSON-LD choice in recent years was a lack of
> elegance in either, but didn’t have an alternative. Now I do.
>
>>
> We also have a reference cli app (in Swift) with a bunch of video
> tutorials that really help you understand it. We are working with the
> community on a ports to Kotlin & Typescript so we can cover mobile, and
> hope to soon have start on Rust & Python.
>
> — Christopher Allen [via iPhone]
>
>>

-- 
Steve Capell