Welcome to Vocabularies for Communities of Interest (VCOI) Working Group Wiki
The aim of this working group is to come up with a common, reusable method for OMG Task Forces and SIGs to use when developing vocabularies.
This Sept 2021 Update sets out the basic proposition for TCs and the current status.
These slides from June 2021 filed at OMG as finance/2021-06-04 constitute the most recent high level outline of each of the various parts that make up the overall VCoI set of parts, and the 'calculus' for context-specific vocabulary linkage to concept models.
See the Activities heading at the foot of this page for links through to work in progress on each activity.
The core proposition is that terms are defined in some context - specifically in this case the context of that Task Force or SIG. Further contextual treatment is merited when a TF or SIG decides to use a definition sourced from elsewhere, since then the context of that external definition needs to be represented.
Simply put a context is itself a concept or a set of concepts (Who, What, When etc.).
Meaning is intended to be derived from some source of formal semantics (e.g. ontology) as a 'concept'.
Then for the TF or SIG:
Term T has meaning of Concept C in context X.
Concepts are considered as being made available as a library of concepts. Meaning (for a term) does NOT rely upon the written definition given for the term, but rather the written definition reflects and is derived from the Concept Library.
This is still being explored but will likely consist of
TFs and SIGs may develop their own ontologies for concepts that they choose to define for themselves. Concepts from other sources may already be in the form of ontologies or may be in less ontologically mature formats such as dictionaries or vocabularies.
Once the Context ontology is developed the next challenge will be how to represent that in Term / Definition representations. Recall that:
This should be something as simple as:
“In the context of Toad of Toad Hall, a 'bank' is the side of a river or stream”
That needs to be able to be generated from the Context ontology and its use as the linkage between Term and Concept needs to be maintained in the underlying machinery that supports all this.
Another output of applying the methodology when it exists, is the ability to frame questions for the owning TF or SIG, including:
This is not just about what the overall metamodel should be (since we intend to use existing metamodels such as SKOS and MVF), but about how the various pieces of any of the available standards metamodels are to be used under the VCoI framework.
A further deliverable made possible if we use the MVF emerging standard is the ability to annotate models with links to concept and vocabulary.
This is the 'Annotations Wishlist'. Work in progress.
The distinction between Metamodel and Annotations is simply:
The deliverables for anyone applying the desired methodology are:
These may take one or more physical forms:
There are two kinds of ontology that may be in play overall. These are referred to in VCoI under the following distinctions:
As defined in the VCoI Calculus, the notion of 'Context' is simply a nexus or combination of concepts. Often summarized as 'Who, What, When, Where, Why, hoW' (the Ws), these are really a simple reminder list for what are basically concepts, and therefore capable of being represented in a suitable concept ontology. The Ws effectively represent a simplistic Top Level Ontology (TLO).
More realistically, and based on more detailed analysis, the kinds of Concept [NOTE] that make up a Context would typically include things like:
[NOTE: capitalized here to show that we mean Concept as defined in the overall calculus]
For this reason, the ontology developed by the VCoI WG to support this will make use of a suitable Top Level Ontology for basic partitioning of the world, rather than simply having one partition for each of the Ws.
Sometimes the Context will be just one time, place, working group, use case etc. but in most cases it will be a combination of these. Likewise specific points within a business process represent a nexus of Who (actor, swimlane) or What (system) and When, among other things.
It is up to each TF or SIG (Collectively, Sub Group) to determine what form their concept model takes. We anticipate that many SGs would start with a general taxonomy, refining this in stages from a broad business taxonomy (having a range of different organizing relationships) to a generalization-based taxonomy, and then enhancing that taxonomy by the addition of properties to derive an ontology at the concept level.
Note that the kind of concept ontology that is suitable for this usage is unlikely to be anything like a conventional OWL-based application ontology, though SGs may elect to serialize their ontology in OWL, and in some cases may even elect to use a use case-driven OWL operational ontology as a stand-in for their domain concept ontology. We don't recommend that but it's the choice of each individual TF or SIG.
In order to develop something that can be used by OMG SGs, there are two aspects to what needs to be delivered or recommended to SGs:
This part of the work focuses on sketching out a basic process workflow that SGs can adopt and extend.
These deliverables and activities are expanded on in the pages below:
See MeetingNotes page