...
| Table of Contents | ||||
|---|---|---|---|---|
|
Background & Current State of the IOF Core
For a cursory glance into the evolution of the IOF Core (formerly referred to as the “top-20 terms,” and later often the “top-26 terms”), we reflect back to a list of industrial domain terms that were submitted by IOF members years ago and from which we selected the top 20 to do a “prototype effort” – that of agreeing on natural language definitions and of mapping the terms to various three foundational ontologies: the Process Specification Language, the Basic Formal Ontology and DOLCE. Ultimately, we voted on and chose the Basic Formal Ontology or BFO. The prototype effort also resulted in the introduction of dozens of additional “mid-level” terms that mapped the top-20 terms to BFO. The effort resulted in an initial set of both natural language definitions and first order logic formalizations (FOL) for the terms and a paper that was published in 2019. Please note that where we use the word “term” herein or in other IOF discussions, we refer to both classes and object properties from an OWL perspective, or to entities and binary or higher-place relations from a logician’s perspective. For additional background information, please follow any of the following links to files that still reside on a Google Drive share folder (please note that these and other archival content will soon be migrated to the Atlassian portal):
...
On the surface or on a net-change basis, the number of terms in the IOF Core today is roughly on par with the number it had in 2019 – making it seem as though little progress has been made. In fact only a few new terms have been introduced while a number have been deprecated or have been moved to one of the domain ontology working groups, if we concluded a term was not likely to appear across multiple domains. The major changes since 2019 are in the definitional content of terms remaining in the core, not only to resolve outstanding issues raised in previously, but to expand or further constrain them to include complement examples, or exclude counter examples. And since few would disagree with the statement that 99% of our discussions are spent debating the natural language or semi-formal definitions of a term, and only about 1% on the FOL or the OWL axiomatization, we have deferred the effort of writing out of FOL or the OWL axiomatization until after agreement is reached on the former definitional content (and the elucidations for terms that are primitives). Reaching agreement on these term definitions so that we can formalize them, is a key objective of this final review cycle.
Where We Are From an Overall Development Lifecycle Perspective?
As far as the final review cycle and where it fits in the overall scheme of a traditional software development life cycle – of which ontological development efforts are surely close cousins – we realistically are still somewhere in the development phase. We can argue the case that we “froze scope” years ago by limiting the number of terms to the top-26 we selected, and the additional ones we’ve introduced along the way, but does our current scope constitute what one might call a “minimally-viable” set of terms from which practitioners in industry can be productive in building application ontologies, or domain-specific ontologies? As recently as a month ago, several of the working groups voiced concern that we should not release anything without at least provisional definitions for notions like event and state (stasis). In any case, we are in a final review cycle and although we will surely be adding some additional terms, we will make every attempt to reach a compromise between expanding scope further and driving towards a release. To that end, and to optimize our time, we will attempt to conduct the final review cycle in an “off-line mode” and utilize our weekly meetings to review issues that are raised, and ways towards resolving them, and minimize lengthy debates on the definitions themselves.
...
Now to manage and track our progress throughout this review cycle, we have assigned a “level of maturity” to each term, which reflects the evolution of a term’s analysis and definitional content, the level of acceptance or review performed, and the number of pending open issues raised. For this measure, we have assigned one of four possible maturity levels as discussed in more detail below. We have not run an overall report to see what the overall status is as of today, but it is fair to say that most terms are in need of peer review and approval.
Where to Get Latest IOF Core?
The IOF Core is now managed through a private GitHub repository that we’ve established here. The IOF Core “ontology file” has been serialized into a standardized format that will facilitate the tracking of changes going forward. We have utilized a tool courtesy of the FIBO organization called “the serializer.” Presently, the IOF Core file has only been serialized in the rdf/xml syntax but once the review process gets further underway, we’ll be uploading serialized versions in other popular formats such as Turtle.
Important Points About IOF Core Content
The IOF Core imports several ontologies and one meta file. These are located in the “imports” subfolder of the project files and include the following:
BFO-2020.owl – this is the first ISO released version of the BFO, released in 2020 (henceforth, BFO-2020). The import version the IOF has voted to use, is the the “temporalized version” of BFO-2020. The arguments for why we made this decision is beyond the scope of this discussion.
cco-imports.owl –mid-level or domain independent terms the IOF has imported and used from the Common Core Ontology, or CCO. We have extensively utilized the CCO in order to either map an industry domain term to BFO, or to introduce “hook” classes/relations that are generic or domain independent mid-level terms, under which we anticipate asserting additional industry-level terms using the “is-a” relation in the near future. An example would our use of the mid-level term “Artifact” from CCO, to assert any number of “man-made” objects such as machines, tools, piece of equipment, and so forth. We have of course sometimes renamed a CCO term label, as in the case of Artifact, which was relabeled Material Artifact.
ro-imports.owl – mid-level or domain independent terms the IOF has imported and used from the Relations Ontology, in order to either map an industry term to BFO, or to introduce “hook” classes/relations that are somewhat generic or abstract, with the understanding that many additional industry terms will be introduced as sibling classes in the future.
IOF_AnnotationsVocabulary.rdf – the definitional content for each term in the Core ontology is embodied in a set of annotation properties the IOF has adopted. We have established various rules on how these annotation properties are to be used. These are documented within the annotations file, under the description property for each.
Throughout the development and review phase of the IOF Core terms, we have introduced and utilized several “temporary” annotation properties to (a) manage the evolution of a term’s definitional content from its initial introduction, through the analysis phase, and to where it is fully formalized in accordance with the IOF’s Technical Principles guide, (b) facilitate the generation of supplementary release documentation at the term-level, and (c) document open action items, issues, arguments for changes made in a definition, and potential considerations for improving a definition in future releases – issues and action items we will soon migrate to the Atlassian Jira project. Please note that all temporary annotation properties will be removed in the released version of the IOF Core. To separate temporary annotations from the list of required or pro-forma annotation properties, we have prefixed the former with the letter ‘x’. The temporary annotation properties are as follows:
xDefinitionOtherCommon
xExampleComplement
xExampleCounter
xIssuesAndActionItems
xMaturity
...
One of the temporary annotation properties is worthy of further note here, namely xMaturity. We will use this property to track the evolution of a term’s definitional content from the (continuing) analysis stage, to the fully-formalized stage. Each term appearing in the IOF Core file has been tagged as to its current status, and will be updated as it is further formalized and accepted according to our annotation rules and technical principles. Four maturity designations are used for this purpose:
Formalized → term has been analyzed, defined and formalized according to the IOF Technical Principles Guide and the Annotation Property Rules; term has been “peer-reviewed” by WG members with no major issues are outstanding
Stable Definition → term has been analyzed and a natural language definition has been identified and adopted by WG members; term however may be lacking in further formalization and may contain terms or notions to be analyzed, defined and added to the ontology
In Analysis → term or notion is under analysis by the WG, or has a candidate definition that has not yet been peer-reviewed
Pre-analysis → a new term or notion motivated by WG discussions, or one that needs to be introduced because it is contained in the definition of another term that has been adopted; although the analysis for such a term remains to be conducted, it will usually have a candidate natural language definition originating from the context where it is used, or from some external source
Raising Issues & Issue Resolution
For issues, questions or concerns related to a term – please create an issue in Jira under the IOF Core project. We’ve created a Jira “Epic” to group all term-level issues that are raised, and it is titled “Term Issues.” The URI is https://oagiscore.atlassian.net/browse/CW-3?atlOrigin=eyJpIjoiNzJjOWUxM2U1MTNlNDRiZmJiYjRlYjI5MTEyZGQ5MzgiLCJwIjoiaiJ9. Depending on the participation level – meaning how many issues get raised – we may create additional Jira Epics around “term clusters,” or in the worst-case, an epic for each term. In the meantime, go ahead and start your review and raise any issues you find. We will move the issues around as necessary and add structure along the way.
...
Please note that at this time, GitHub will not and must not be used to raise issues. This is something we will defer until after we release a version of the IOF Core to a public. At that time, we most certainly will have to entertain the use of GitHub to raise and resolve issues raised by external users.
Getting Started & Call to Action
If you are reading this page, you’ve already been assigned a user account in the Atlassian toolset, so you have already completed the first step!
Next, download the Core ontology project code from GitHub to your local desktop. You will need an “invite” from GitHub to get access to this and any of the other IOF repositories that have been uploaded there. If you don’t have an invite, please email Chris.will@outlook.com or Will and provide your GitHub user ID. We’ll get you setup within about 24 hours.
If you haven’t already done so, please familiarize yourself on these annotation properties and rules by reading here.
Load up the Core ontology in your favorite ontology editor. Protégé is likely still the IOF standard for this at the present time.
Once you’ve loaded the ontology into your editor, the call to action is for you to start reviewing term definitions and formalizations. Raise issues and questions as mentioned above.
Of Special Mention
Although all IOF members are invited to participate in the final review cycle, to ensure we a sufficient level of review of each term, the working group chairs will be asked to explicitly confirm that they have reviewed and approve each term’s definitional content. This approval is needed initially regarding the natural language and semi-formal definitions or elucidations, and subsequently for the FOL and OWL axiomatization. The IOF Core working group meetings will be the venue during which such “explicit confirmation” will be requested, and recorded.
...