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 w3id.org/traceability is exactly about a)
combining the powers of JSON Schema and JSON-LD, and b) referencing
existing terms, not (re-)inventing new ones.

From https://w3id.org/traceability/#vocabulary-linkage:
*"... 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 schema.org, 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,
https://vocabulary.uncefact.org/GeographicalCoordinate shouldn't be
"competing" with https://schema.org/GeoCoordinates. While
https://vocabulary.uncefact.org/TransportMeans 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!

Cheers,
Nis

On Mon, Nov 28, 2022 at 8:42 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
>
>