Re: "world needs less vocabularies"

On Mon, Nov 28, 2022 at 9:26 AM Orie Steele <orie@transmute.industries>
wrote:

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

I would say that these are excellent ontologies suitable for widespread,
but maybe not universal, use.  I can conceive of some small niches that
would need to extend them slightly.

--------------
Alan Karp


On Mon, Nov 28, 2022 at 9:26 AM Orie Steele <orie@transmute.industries>
wrote:

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