Re: "world needs less vocabularies"

On Mon, Nov 28, 2022 at 11:35 AM <james.schoening@ieee.org> wrote:

> Alan,
>
>
>
> I agree an uber-ontology could not succeed, because it would grow far too
> large. The hierarchical approach (single top-level, single mid-level, then
> many domains and subdomains) has been emerging for the past decade, and
> hasn't been seriously tried before.
>

I took your earlier point to mean that every ontology in the hierarchy must
be part of a single standard set.  If you are allowed to include one of
your own choosing for your community, then I heartily approve.

>
>
> You correctly describe the 'let a thousand flowers bloom' approach to
> ontologies, but this has given us large numbers of siloed ontologies that
> overlap, are not logically consistent, and don't work across silos.
>

My experience back when I did my ontology study circa 2000 was that those
siloed ontologies could only include a standard ontology by value, which
led to drift even for the standardized terms.  Including them by reference
should avoid that pitfall.

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


On Mon, Nov 28, 2022 at 11:35 AM <james.schoening@ieee.org> wrote:

> Alan,
>
>
>
> I agree an uber-ontology could not succeed, because it would grow far too
> large. The hierarchical approach (single top-level, single mid-level, then
> many domains and subdomains) has been emerging for the past decade, and
> hasn't been seriously tried before.
>
>
>
> You correctly describe the 'let a thousand flowers bloom' approach to
> ontologies, but this has given us large numbers of siloed ontologies that
> overlap, are not logically consistent, and don't work across silos.
>
>
>
> I won't belabor this topic further on this forum, but email me if anyone
> would like discuss offline.
>
>
>
> Jim Schoening
>
> +01-732-996-0018
>
>
>
> *From:* Alan Karp <alanhkarp@gmail.com>
> *Sent:* Monday, November 28, 2022 11:35 AM
> *To:* james.schoening@ieee.org
> *Cc:* Nis Jespersen <nis.jespersen@gmail.com>; steve capell <
> steve.capell@gmail.com>; 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
> >
> *Subject:* Re: "world needs less vocabularies"
>
>
>
> 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.  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.
> That approach lets small communities specify the specialized terms they
> need while using widely understood terms for the rest.  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.  This approach
> was part of E-speak, but HP shut it down before we had enough data to know
> how well the approach worked.
>
>
> --------------
> 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
>
>
>
>