RE: "world needs less vocabularies"

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 <mailto: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 <mailto: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 <mailto:nis.jespersen@gmail.com> > 
Sent: Monday, November 28, 2022 4:03 AM
To: steve capell <steve.capell@gmail.com <mailto:steve.capell@gmail.com> >
Cc: Christopher Allen <ChristopherA@lifewithalacrity.com <mailto:ChristopherA@lifewithalacrity.com> >; Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> >; Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net <mailto:mwherman@parallelspace.net> >; public-credentials (public-credentials@w3.org <mailto:public-credentials@w3.org> ) <public-credentials@w3.org <mailto: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 <http://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 <http://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 <mailto: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 <http://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 <mailto:ChristopherA@lifewithalacrity.com> > wrote:

On Sun, Nov 27, 2022 at 10:16 PM Anders Rundgren <anders.rundgren.net@gmail.com <mailto: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