Re: Saying yes to making @context optional

Hi Steve,

+1 on LD, enabling knowledge graphs and self-describing data. CoO FTA
variants are a great example.

Also a huge +1 that the world needs less vocabularies, not more. I'm
obliged to underscore that is exactly about a)
combining the powers of JSON Schema and JSON-LD, and b) referencing
existing terms, not (re-)inventing new ones.

*"... These URIs will generally point at existing, established
vocabularies. Only when no applicable vocabularies can be found are terms
defined as part of the traceability-vocab spec; these are considered
exceptional cases."*

While it isn't always possible to find existing term definitions, the vast
majority reference, GS1 and indeed UN/CEFACT.

On the UN/CEFACT vocab-side, IMO the most productive next step is to start
deprecating terms which already have established definitions. For example, shouldn't be
"competing" with While might not be pretty for
better and worse it's a genuine UN/CEFACT term.
In both cases we have to balance stability vs. perfection - looking forward
to this next phase of the UN vocab work!


On Mon, Nov 28, 2022 at 8:42 AM steve capell <> 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 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
>  But I'm pleased to say
> that the UN is catching up and there is now a draft vocabulary here
>  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 <
>> wrote:
>> On Sun, Nov 27, 2022 at 10:16 PM Anders Rundgren <
>>> 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

Received on Monday, 28 November 2022 09:07:12 UTC