Re: Saying yes to making @context optional

> "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."

^ The assumption that a rollup of some subset of values in a payload ===
what those terms in isolation mean/intend *when combined or adjacent* is
not a safe one, imo. There's no certain way I've seen for a system to
prove/disprove that two terms that mean X in isolation do or don't imply Y
when present together. In practical reality you end up looking for the
top-level URI that stands for the baked bundle, not hunting for terms
inside whatever amorphous property bag you're handed. The presence of other
terms/data in bundles may cause 'side-effects' that confound the assumption
that just because a value is present it means what you think it means in
the specific bundled context (not @context, the actual context of
assessment) it's present in. I think this is why devs naturally turn on the
top-level URIs as their first and most definitive filter for knowing they
really have what they want.

On Mon, Nov 28, 2022, 1:41 AM steve capell <steve.capell@gmail.com> wrote:

> 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
>
>