Re: "world needs less vocabularies"

Inline:

On Mon, Nov 28, 2022 at 10:48 AM Alan Karp <alanhkarp@gmail.com> wrote:

> On Mon, Nov 28, 2022 at 6:08 AM <james.schoening@ieee.org> wrote:
>
>> Nis,
>>
>>                 If as you say, ‘less vocabularies’ is better, why not a
>> single standard one?  I mean a ‘hierarchy’ of standard ontologies (so no
>> modules get too big).
>>
>>
>>
>> Every attempt at creating a single, global ontology, even a hierarchical
> one, has failed in one way or another.
>

IANA registries seem to be a great counter example of this... powering you
being able to read this message:

- https://www.iana.org/domains/root/servers
- https://www.iana.org/assignments/jose/jose.xhtml
- https://www.iana.org/assignments/cose/cose.xhtml
- https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml


> An approach that we tried was to allow you to define your own ontology
> that consists of only terms that aren't provided by others while including
> other ontologies by reference.
>

This is equivalent to providing:

{ @vocab: https://your.example/vocab# } in a second context,

assuming the { @vocab : https://w3c.example/vocab# } is in the first...

which is a thing I keep arguing for in VCDM v2.


> That approach lets small communities specify the specialized terms they
> need while using widely understood terms for the rest.
>

Strongly agreed.


>   The goal is to let ontologies that don't add value wither from lack of
> use while others grow the number of users and become more widely used
> standards.
>

Yes, this aligns with the original intention of the did spec registries.


> This approach was part of E-speak, but HP shut it down before we had
> enough data to know how well the approach worked.
>
>
I think it's important to protect the uniqueness and culture of the W3C,
and to build on the work related at W3C, including:

- https://www.w3.org/TR/json-ld11/
- https://www.w3.org/TR/wot-thing-description11/
- https://www.w3.org/TR/activitystreams-core/
- https://www.w3.org/TR/sparql11-query/

If we were at IETF, we would be trying to use CBOR and COSE for everything,
we would be actively avoiding reimplementing things or similar things, such
as protocol buffers or other esoteric (or custom or proprietary) binary
formats.

Since the W3C Verifiable Credentials WG is focused on aligning to the
contributors and use cases that are specific to W3C Members,
it makes sense to align to their concerns and experiences using the related
standards, and see where we can improve,
and where we can't because we want to maintain interoperability.


> --------------
> Alan Karp
>
>
> On Mon, Nov 28, 2022 at 6:08 AM <james.schoening@ieee.org> wrote:
>
>> Nis,
>>
>>                 If as you say, ‘less vocabularies’ is better, why not a
>> single standard one?  I mean a ‘hierarchy’ of standard ontologies (so no
>> modules get too big).
>>
>>
>>
>> We already have ISO/IEC-JTC1-21838-2 Basic Formal Ontology (a small top
>> level ontology providing structural terms to keep extensions logically
>> consistent).  I chair the newly approved IEEE Ontology Standard Working
>> Group (new participants welcome at no cost) at
>> https://sagroups.ieee.org/oswg/,  where we are standardizing the mature
>> Common Core Ontology (a mid-level ontology with terms common across
>> multiple domains) and starting to work on domain extensions for Cyber and
>> MyOntology (this one in collaboration with MyData Global). Our PURL server
>> is in testing and should be out in about a month.
>>
>>
>>
>> If you could suspend your disbelief for a moment, wouldn’t this help?
>>
>>
>>
>> Questions and arrows welcome.
>>
>>
>>
>> Jim Schoening
>>
>> +01-732-996-0018
>>
>> *From:* Nis Jespersen <nis.jespersen@gmail.com>
>> *Sent:* Monday, November 28, 2022 4:03 AM
>> *To:* steve capell <steve.capell@gmail.com>
>> *Cc:* Christopher Allen <ChristopherA@lifewithalacrity.com>; Anders
>> Rundgren <anders.rundgren.net@gmail.com>; Michael Herman (Trusted
>> Digital Web) <mwherman@parallelspace.net>; public-credentials (
>> public-credentials@w3.org) <public-credentials@w3.org>
>> *Subject:* 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
>> <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
>>
>>
>>
>>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>