...
We spent most of the meeting reviewing the Ontology Release Criteria candidates submitted to the TOB by Dimitris (and comments by mostly Evan and Chris) and added a few additional comments and criteria. The next steps we discussed are as follows:
Evan will do an initial assessment of the ISO 21838 - Top-level Ontologies draft standard and excerpt applicable criteria for use in releasing the IOF Core, and flag a subset of such criteria that would be applicable to the release of IOF domain reference ontologies
. The ISO 21838 is a standard for authoring Top‐Level Ontologies (TLO) based on Basic Formal Ontology, and includes two parts: Part 1, Requirements, & Part 2, Basic Formal Ontology. Both Parts 1 and 2 include criteria for releasing BFO-compliant ontologies, and also requirements for defining ontology terms in general (which we’ve reflected to some extent in the IOF’s Technical Principles document, and in our annotation rules).Jira Legacy showSummary false server System JIRA serverId e40ab0a4-b576-382d-85fc-495e1da7d966 key DRMP-10 Chris to add details on the two additional release criteria
he added during the discussion: Creation of an “ontology introduction” document, which would include, at the term-level, a list of complement & counter examples along with a discussion on any impact these may have on the ontology’s use, as well as “known issues” and quandaries – of which the latter will likely span multiple terms and ontologies.Jira Legacy showSummary false server System JIRA serverId e40ab0a4-b576-382d-85fc-495e1da7d966 key DRMP-11
On the subject of tracking tasks and issues, we thought it might be relevant to separate the rules (and tooling/automation) we impose on the working groups into those happening during the development phase versus those happening during the release phase. Our thinking is that we might need to be more flexible during the development phase but impose more strict rules during the release phase, where we will likely be introducing some automation for validation and content publication, and would want tighter control and visibility of tasks and issues raised. Another consideration of being more flexible is that it is not yet clear how effective Jira will be for managing tasks and issues at a detailed level. For example, it seems that while Jira supports some degree of task or issue decomposition, you lose visibility of such sub-tasks in most of the top-level views like in the “backlog” and “board” views. Serm mentioned that while we should “log everything” during in all of our activities and phases, we should not “overthink” the automation we require or ultimately desire. For the first IOF ontology release, we may have little or no automation. In reference to tracking tasks and issues, we decided to manage tasks and issues in Jira for now, and hopefully use that tool to successfully meet project milestones. The action items from our discussion are roughly as follows:
Requirements for tracking tasks and issues during the development phase. This is will remain a lower-priority task for now and until somebody steps forward to drive it (Serm?). But certainly feel free to add anything that comes to mind to that task in the meantime.
Requirements for tracking tasks and issues during the release phase. Chris will spend a small amount of time to list out his initial thoughts on the matter and we’ll revisit this again soon.
On the topic of suggested SPARQL validation scripts and the FIBO checklist, Chris indicated he had not yet had time to sift through all of what Elisa had provided him, and that it would be discussed in our next meeting.
Regarding a review of open tasks, we had no time left in the meeting for this and will address next time.
...