Re: "world needs less vocabularies"

James, and all
the point of a vocabulary in ontology sometimes overlaps glossary
and glossary, overlap index
an index of terms is NECESSARY for information management purposes
let me give you an example
some clever folks have uploaded al of their knowledge resources that cover
a particular domain
we are all working on to github, there is no way of telling what is in the
resources without
indexing them
there is not çreate automated index in github, I d have to figure out how
to index the files myself
an intelligent project managers maintain and publish the core terms for
their knowledge resources (if they want to share them) and do not publish
them if they decide they want to keep what they are working on a trade
secret, except for those who have the time and skill to download and index
the resources
Unfortunately, many people on the open web misappropriate other peoples
vocabularies to
build their own resources without attribution
this is not a problem that I can solve, other than not publishing the
vocabulary
there is nothing to do with single globla ontology, its about knowledge
indexing
for the purpose of sharing  - its a clear design choice that reflects a
policy choice


On Mon, Nov 28, 2022 at 10:08 PM <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
>
>
>
>