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

• Some terminological resource (e.g. a SKOS repository)
• Means of generating the outputs described above from that resource
• Means of generating or populating that terminology resource from available ontologies and (potentially) other conceptual resources

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:

• The Word or Term is accessed by an end user, who is looking for a Definition
• The Definition belongs to the Concept not the Word or Term
• The Context links that term usage to the concept with its definition

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:

• What community of practice do you look to for definition of a given set of terms or kind of term?
  • For example, GovDTF may determine a given statistics CoP for statistics related terms and concepts
• What did you intend for a given term to mean?
  • A definition that happens to match the words might be entirely different to what this TF intends to mean
  • Need to be able to present business-readable 'straw man' representations of possible meanings, ideally derived from an ontology

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:

• Metamodel: what constructs are needed and their relations to other such constructs
• Annotations: elements that take simple text as their range rather than other constructs

The deliverables for anyone applying the desired methodology are:

• Tables of Term, Definition, Synonym(s) and other relevant materials
• Acronyms with their referents or terms
• References

These may take one or more physical forms:

• Tabular text resources for use on TF and SIG wikis
• Wiki pages with individual Term, Acronym or Reference one per page
• Document inserts in the style of the OMG Specification template, for Terms, Abbreviations, References

There are two kinds of ontology that may be in play overall. These are referred to in VCoI under the following distinctions:

• Ontology (1): the VCoIs own ontology
  • For defining the 'Context' element of the Term/Context/Concept triad
  • For use in representation of References (see output formats)
• Ontology (2): The conceptual resource maintained by the individual TF or SIG

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:

• A 'Business Area' overall (broad or narrow e.g. Healthcare, Treasury operations)
• A specific business application use case
• Service or Service Area
• The viewpoint of a specific party (Party-in-Role) as well as individual people or entities ('Who)
• A given time ('When') or some temporal cadence (past, present, anticipated future worlds)
• Some specific point in a business process workflow
• others yet to be thought about

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

• The parts (Term / Context / Concept with its definition, metadata etc.)
• The activities (Process workflow)

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:

• 1. Concepts Re-use Calculus
  • Context Treatment - Given all the above, how should the 'context' be treated for
  • Word usage (This word W means concept C in the context of this TF or SIG)
  • Concept - origin context in the case of externally sourced concepts
• 2. Content requirements
  • SMEFeedback - Considerations and pointers in gathering domain knowledge by TF or SIG
  • Definitions - form of definitions and how to derive these from the concept resource (ontology)
  • LocalOntologies - Formal reference ontologies for concept defined by the TF or SIG
• 3. Metamodel
  • Architecture - Tools and formats to maintain the terminology and vocabulary of a Task Force or SIG
• 4. Annotation requirements
• 5. Output Formats
  • OutputFormats - desired form of outputs for the terminology and concepts
• 6. Context Ontology
• 7. Process

• 1. Concepts Re-use Calculus
  • Mostly figured out and documented
• 2. Content requirements
  • Considerations and pointers in gathering domain knowledge by TF or SIG - to be done
  • Definitions - form of definitions and how to derive these from the concept resource (ontology) - TBD
  • Guidelines for Formal reference ontologies for concept defined by the TF or SIG - TBD / in progress
• 3. Metamodel
  • Tools and formats to maintain the terminology and vocabulary of a Task Force or SIG - In progress, see Architecture page as above
• 4. Annotation requirements
  • In progress AnnotationsWishlist
• 5. Output Formats
  • Mostly determined (specification for what the underlying 'machinery' needs to emit)
  • New formats may be identified from time to time
  • Expect to liaise with others on e.g. wiki glossary pages
• 6. Context Ontology
  • In progress July 2021
• 7. Process
  • Some initial work May / June 2021, to be completed

See MeetingNotes page