| Table of Contents | ||
|---|---|---|
|
Meeting Minutes
Participants
Evan Wallace Elisa Kendall William Sobel Serm Kulvatunyou Milos Drobnjakovic Chris Will
Minutes
William Sobel and Milos Drobnjakovic will set up the public git repo.
William Sobel will work with Alexandrau to set a resolvable IRI resource. However, this is not necessary done b/f the release.
We will have to discuss in the GB to whether letting the public, non-member to file issue. Then, we will see whether we need two ways to log and manage issue. (side note: if we don’t want accept issue from public what is the point of having a public git repo, can’t we just put the zip on the web in that case?)
William Sobel suggested to have sample instantiation from the supply chain WG informally released along with the Core release. Serm Kulvatunyou and Milos Drobnjakovic will try to work with Farhad Ameri on that to pull this off in the next few weeks.
…..
Meeting Minutes
Participants
Evan Wallace Chris Will Elisa Kendall William Sobel
Minutes
We had a shortened meeting today as both Will and Elisa had to drop off at the bottom of the hour. Here are the key points discussed:
Concerning the Draft of Release Criteria, we feel they are ready for a final review by the task group and then for TOB approval. An open action item before we do this however is to reformat the spreadsheet content back into a “document format,” one that will be published on a Confluence page after approval. No one on the call indicated they had time to do the reformatting work in the month of September, so herewith, I we are serving a help-wanted request to the other members of the task group. Perhaps Serm Kulvatunyou or Farhad Ameri or Dusan Sormaz or tschneider have time??? If so, please email Chris Will if you are able to volunteer for this job.
We then moved the discussion to several of the items in the release criteria and affecting our release procedures, that are dependent on the ontological approach we ultimately decide on for releasing the first version of the core. Those options are (a) to release a single IOF Core ontology that is tied to and directly based BFO, or (b) to release a decoupled IOF Core ontology along with a Core-to-BFO mapping ontology. Option (b) is what we have been referring to more recently as the “IOF Core Restructured” ontology. After some discussion, we agreed it isn’t the purpose of this task group to make a decision on which approach should be taken, but rather it is up to the TOB. Chris took on the action item to ping the tschneider or the TOB and let him know that this group is in a holding pattern until the TOB decides which approach we will take for releasing a first version of core.
Lastly, Chris mentioned that as he is attempting to formalize definitions and axioms for core terms in the decoupled version, he is encountering challenges that depending on the approach taken, he expects major debates in the foreseeable future. Will and Elisa had to jump off the call but indicated a strong willingness to discuss the overall status of restructured terms/term definitions, next steps, and review some of the challenges Chris is encountering. Chris will try to setup an off-line meeting between the three of them, and failing that, will make these the agenda topics for next week’s IOF Core group meeting.
Meeting Minutes
Participants
Evan Wallace Chris Will Jim Wilson Elisa Kendall
Minutes
Chris first reported on his experiences of posting the IOF Core refresh on the new GitHub site William Sobel has created for IOF use. The process ran smoothly although he did run into an issue with automating the RDF Serializer in his GitHub desktop client, and ended up having to run the tool in manual mode. Chris will reach out to Elisa in case he cannot resolve his issues. Chris also indicated that he only serialized the IOF Core in RDF/XML format, and that until the review cycle gets further underway and the demand for other formats surfaces, we will only serialize in RDF/XML format.
We then discussed briefly whether we should be validating that an ontology is utilizing only the OWL DL 2 syntax and version of OWL. Evan and I thought this was decided in the affirmative a long time ago, and will check with Todd. Either way, we did not discuss how such a check would be done or whether it is even necessary, as Elisa had not joined the call yet and attendance in the meeting was otherwise too sparse. We may revisit this topic in a future meeting.
The discussion moved on to one of the validation queries from FIBO, namely the one that checks that appropriate copyright and licensing statements appear in the ontology file. The IOF has agreed to CC BY 4.0 and MIT Open Source licensing, but we need to agree on the specific language and which statements (copyright and/or MIT and/or both) that need to appear in an IOF ontology file. Action items are as follows:
Chris to check with a couple of the IOF corporate members to see what sort of verbiage and text they might expect to see in IOF content.
As we are not part of OAGi, the IOF is operating under their intellectual property policy. Jim took on the action item to check with OAGi’s governance person to better understand what statements need to appear in IOF artifacts and ontology files. Jim will then present this to the TOB for review and decide on the next steps (as in what textual statements are to appear in the ontology files).
In the last part of the meeting, we reviewed other release criteria, namely as follows:
On the requirement of “composability,” and the procedure we would follow for verifying this, Elisa mentioned this will likely be done manually for the first release of an IOF ontology. The action item here is for all of us to review and get a better understanding on the requirement, and then we can discuss what sort of hygiene test(s) we might need to author to satisfy our needs.
As far as a tool for generating a glossary of an ontology, we will likely want to shy away from using fee-based tools (like CCM). Open action item is to research the FIBO viewer tool and content generation tool, and perhaps other open source tools that others have used.
As far as whether we require a tutorial or reference manual upon release of an ontology, currently this is not a requirement. FIBO has and offers training courses for which they charge. We might discuss this further in an upcoming meeting.
Meeting Minutes
Participants
Chris Will Dusan Sormaz Elisa Kendall
Minutes
We decided to just have an open-ended discussion on workflow for raising issues and tracking the evolution of term definitions between and across releases. Here are the highlights: Although we have implemented a tentative procedure for conducting the final review cycle for the IOF Core (a procedure that is documented here: https://oagiscore.atlassian.net/l/c/Q61EfMk5), we discussed the need to document how the evolution of a term should be tracked both within the Jira issue tracking system, and GitHub. These details are missing from the tentative procedure, which only currently instructs the reviewer to log such issues in Jira. As far as tracking the evolution of a term within a release, we feel the current workflow in Jira needs to be expanded to track the approval cycle. As far as tracking evolution across releases, this is currently a lower priority topic to decide on but certainly to be addressed by the time we release the core to the public. Elisa mentioned the possibility of tracking term evolution by using an ontology overlay file but we did not get into details.
Meeting Minutes
Participants
Evan Wallace Chris Will Dusan Sormaz Serm Kulvatunyou William Sobel
Agenda
Review open action items
Minutes
Chris first provided a brief update on various “clean-up” items he is making to IOF Core before he publishes it to GitHub and starts the review cycle.
We then resumed discussions on the proposed workflow configuration in Jira for managing projects, and some of the issues we are having. We reviewed a “template” for entering tasks, issues and the various “task types” that Will had created and is prototyping in the MT Connect working group. Serm voiced concerns of not introducing too many tasks types, at least initially as we implement task and issue tracking in Jira. William Sobel offered to take on the action item to setup the same workflow for IOF Core as exists for MT Connect. Chris Will will prototype the recommended workflow (and template usage) for creating and managing issues as soon as he starts the IOF Core review cycle. We all agreed that the workflow for TOB review and approval of recommendations from the working groups, remains a to-do.
Meeting Minutes
Participants
Farhad Ameri Evan Wallace Chris Will Michael Brundage Dusan Sormaz Serm Kulvatunyou Elisa Kendall William Sobel
Agenda
Review open action items
Minutes
We started the meeting being introduced to William Bernstein from NIST’s Systems Integration Division, who is quite active on the evolution of the STEP standard, QIF and the GEO specification. We will be sitting in on occasion on various of the IOF working group activities, as a backup or in addition to Evan and Serm. We welcomed Bill and look forward to more collaboration between IOF and his activities on STEP related matters.
We then began reviewing some of the open items from prior meetings and entered an expanded discussion on what the recommended workflow should be for tracking tasks and issues, the use of Jira for this and some of its shortcomings, and how we would like to proceed. William Sobel took on the task of documenting a provisional workflow in this regard, which we will review in our next meeting, with the hopes of having something we can recommend to the TOB and implement tactically.
We spent most of the rest of the meeting reviewing how we would structure EPICS, Tasks, Issues and Subtasks and how we might structure projects in Jira to work around some of its shortcomings.
Meeting Minutes
Participants
Farhad Ameri Evan Wallace Chris Will Gianmaria Bullegas Serm Kulvatunyou Jim Wilson Dusan Sormaz
Agenda
Review and finalize Release Criteria
Establish initial list of “requirements” to be achieved with managing Tasks and Issues and how they should be tracked.
Review the suggested validation SPARQLs and checklist Elisa provided
Review open action items
Minutes
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 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 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.Jira Legacy server System JIRA serverId e40ab0a4-b576-382d-85fc-495e1da7d966 key DRMP-12 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.Jira Legacy server System JIRA serverId e40ab0a4-b576-382d-85fc-495e1da7d966 key DRMP-13
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.
Meeting Minutes
Participants
Elisa Kendall Farhad Ameri William Sobel Evan Wallace Dusan Sormaz Chris Will Gianmaria Bullegas William Sobel Serm Kulvatunyou
Agenda
Review the minutes and action items from prior meetings, enter relevant ones in Jira, and dispatch them.
Work through details of the “post-term candidate definition” workflow of the ontological development process.
Other topics
Minutes
In our review of action items from the prior meetings, the relevant discussion points are as follows:
Concerning Ontology Source & Artifact Management on GitHub, eventually the plan is to automate much of the validation that is needed when ontology files are committed back to GitHub (automation we plan to achieve with Jenkins). For now, we’ll do this manually. Elisa will compile provide us a subset of SPARQL validation queries from the set FIBO uses, that she feels would be the high priority ones the IOF should consider using in IOF’s initial releases. Chris to
Jira Legacy server System JIRA serverId e40ab0a4-b576-382d-85fc-495e1da7d966 key DRMP-6 As far as establishing an IOF account on GitHub: one choice is for the IOF to utilize OAGi’s existing account on GitHub, and another, our preferred choice, would be to establish our own account. Will noted that the latter option involves a monthly fee starting around $25, and is likely not a tactical option until we charge IOF membership fees or get grant funding. Serm will reach out to Jim to explore the first option
. Will also mentioned that with the first option, we have the undesirable effect of intermingling repository information across both IOF and OAGi.Jira Legacy server System JIRA serverId e40ab0a4-b576-382d-85fc-495e1da7d966 key DRMP-8 As far as GitHub usage requirements, we discussed the need for both private and public repositories, with the private facing one used for pre-release work, and the public for released versions ontologies. William Sobelto
for the use of GitHub in the next 3 weeks – both the private repositories by the working groups and the public-facing one for released versions . It would appear that many of the working groups have managed GitHub accounts and would be or have already established private repositories (e.g., Maintenance WG). Chris will send out an email to the other chairs to see who has this capability. We would obviously utilize this in lieu of sharing an account with OAGi.Jira Legacy server System JIRA serverId e40ab0a4-b576-382d-85fc-495e1da7d966 key DRMP-4
We reviewed the provisional Final Review Cycle of the IOF Core that was recently introduced at one of the IOF Core meetings. Feedback included:
Farhad asked whether who will create the structure in Jira to enable the raising and tracking of issues raised against a term. I indicated this would be done in a just-in-time manner as issues are raised for a term. Chris to take on the action item of detailing this and placing it on the page describing the procedure
.Jira Legacy server System JIRA serverId e40ab0a4-b576-382d-85fc-495e1da7d966 key DRMP-9 We discussed how notifications would be handled – as in do we notify all IOF Members or only the selected “Core Reviewers.” I suggested that an invitation to participate in the review process would be sent to all IOF members, but that the details of managing the formalization of and issues raised against a term, would involve the “Core Reviewers” and any other IOF members that subscribe to updates from the Jira project where we manage the IOF Core term issues. Chris to .
On the topic of notification, Dusan took a way an action item to ask Jim and the TOB how we should deal with group notifications by email under the new OAGi arrangement. For now, we will continue to use Google Groups.
On agenda topic #3, Chris took on the action item to
Jira Legacy server System JIRA serverId e40ab0a4-b576-382d-85fc-495e1da7d966 key DRMP-7
Meeting Minutes
Participants
Elisa Kendall Farhad Ameri William Sobel Jim Wilson Evan Wallace Dusan Sormaz Serm Kulvatunyou Chris Will
Agenda/Minutes
Here are the highlights of our last meeting:
We spent most of the meeting discussing the workflow for managing ontology terms and issues raised against them, especially in the context of which workflows and activities should be tracked and potentially automated in Jira or GitHub. There may be some outliers among us but I believe the general consensus is as follows (and I’m dividing the discussion into the “pre-” and “post-candidate” phases of a term’s evolution):
Let’s first define the phrase “candidate term definition” as the state a term reaches when its analysis phase completes – meaning the term (a class or object property) has been formalized in the applicable IOF ontology or module, is conformant to the IOF Technical Principles and Annotation Property Rules, and that the underlying ontology file has been “Serialized” and committed to GitHub in the applicable “development branch” for the ontology. Question: Does someone have a good narrative for managing an ontology in GitHub from other efforts?
Concerning pre-candidate term definition activities – including all the activities shown in the Term Analysis Procedure – the consensus is to allow the working groups to continue using whatever methods and tools they currently use (Slack, GitHub, etc.), provided the minutes from working group and the collaboration history show evidence the term analysis procedure is being followed. While most of us felt it was either premature or “over-the-top” for the IOF to manage such pre-candidate term definition activities in Jira, it might make sense to configure a basic workflow and prototype this in Jira for one of the working groups. MTConnect is currently doing so to manage its terms. Will indicated he might expand the Jira workflow to align more closely with the analysis procedure, but that this was lower priority. Net-net, we will track MTConnect’s progress on this before we commit to automation.
Concerning post-candidate term activities – including voting on a candidate term definition, and raising and resolving issues raised for a term – the consensus was to use Jira. Will has setup a basic workflow for managing tasks and issues alike, which is being prototyped by several of the working groups. Some assumptions and questions that come to mind as I document our minutes on this are:
It wasn’t clear from our discussions whether voting would happen during the pre- or post-candidate definitional phase. I made the assumption that the voting process happens as one of the post-candidate definition activities, since we want to keep records of who participated in the vote and manage any issues raised, resolved, or outstanding, as one of the metric to drive a release schedule.
Do we keep the minutes, issues, and collaborations of post-candidate definition activities “private” or make these visible to the public? There’s obviously implications either way we go.
How many people and what types of experts must be involved in the voting process, what constitutes a “quorum,” and what constitute a successful outcome of the process? We talked a bit about this in the TOB.
We’ll have to detail the above points further in our next meeting.
Relative to holding meetings in general, and in this instance in reference to the up-coming Architecture meeting that was to be held the next day, Evan mentioned the importance of knowing what the Agenda topics are in advance of a meeting. I believe we are addressing Evan’s concerns for this meeting, and if not, please do let me know. Certainly, we should open up our next release management meeting by reviewing open action items from our prior meetings and dispatching them in the Jira portal. And then we can detail the above workflows (the post-candidate definition workflow) as one of the next agenda topics.
Meeting Minutes
Participants
Elisa Kendall Farhad Ameri William Sobel tschneider
Agenda/Minutes
As I had not prepared an agenda in advance, we began the discussion somewhat informally by reviewing minutes from the last meeting that I had published to Confluence the day before. We then agreed to discuss the following topics: (1) Review the structuring of projects in Jira and proposed workflows for managing issues and action items or tasks that Will had prepared using MTConnect WG by example. (2) Discuss further the workflows and tooling for ontology development. And (3) review the action items from last meeting.
Being on the call for the first time, Todd grabbed the stage to talk about our Term Analysis Procedure and the importance of the linguistic analysis step – referencing the recent analysis discussion of term Agent from the prior IOF Core meeting. Todd reiterated the importance of arriving at a suitable natural language before starting or mixing in terms and relations from BFO and IOF. We agreed the analysis workflow might need to be revisited to ensure Todd’s concerns are reflected in the procedure. Chris took on the action item to move the content for this procedure from Google Docs to Confluence. Check it out here: Term Analysis Procedure. One concerns after moving this content is that Confluence is more of a content management system and not a file management system from what I can tell. So where to put the PowerPoint presentation of this procedure since PowerPoint, at least for now, will remain the tool for managing updates to it? And the general question would be for any other content authored and managed in tools outside of Confluence?
Managing Projects, Issues and Tasks in Jira. Will gave the group an overview of the project and workflows he had setup in Jira for the MTConnect WG. The only requirement coming out of this discussion is that we want to be able to easily search and find things on Confluence & Jira (GitHub for that matter too). It is not clear yet whether the search features in the Atlassian tools are sufficient. E.g., how do you do a focused search for the term “stasis” and target just the MTConnect project and Confluence content? Will is playing around a bit with this and will provide some guidance.
Workflows and Tooling for Ontology Development and Release. Highlights of our discussions are as follows:
We discussed first the “term review and approval” steps of the workflow Will had configured in Jira in relationship to making changes to terms in an ontology (master or branch in GitHub of an ontology). E.g., what validation tools need to be run before submitting a term for review, and which later on in the process? We decided that before committing any changes to GitHub, the Serializer should be run. The Hygiene and other tests can be run much later before ontology revisions reach the release status.
We then discussed whether the IOF GitHubs would be public or private. Didn’t get a group consensus or conclusion on this so to be revisited next time..
Elisa mentioned FIBO and other efforts she’s done have a formal “checklist” to be filled out by a term author/editor and will provide a sample checklist from FIBO to share with us.
We discussed the need to draft a more detailed description of the workflows related to the above – an action item to be assigned in our next meeting as we discuss this topic further.
Review action items from last meeting. We ran over on the above items and since we had only a limited number of attendees, we pushed the discussion for this to the next meeting.
Meeting Minutes
Participants
Jim Wilson Serm Kulvatunyou Elisa Kendall Farhad Ameri William Sobel Evan Wallace Mike Bennet Dusan Sormaz
Agenda/Minutes
Elisa spent the first 30 minutes giving the group an overview and demonstration of the key release artifacts, process and tooling used by FIBO.
We spent a bit of time talking about the Elisa’s IRI recommendations, and agreed to discuss this further in the Architecture Task Group.
We then proceeded to discuss some of the tools we will likely use in managing the development and release process – as in Jira, Confluence and GitHub, which are provided at no charge to IOF by OAGi, or are open source. Key discussion points were:
I believe general consensus was reached on utilizing Jira as the tool to manage the development and release efforts of the various IOF working groups, and utilize GitHub to manage WG outputs – reference ontologies and supporting artifacts, including the versioning thereof. William Sobel agreed to setup a basic workflow and project structure in Jira and apply that to the MT Connect WG as a prototype.
For raising, tracking and resolving issues, our choices from the FIBO discussion were that this can be done either in GitHub or Jira, or both. FIBO has some automation in place that synchronizes issues content between Jira and GitHub in both directions. Elisa mentioned making this available for the IOF and possibly improving some of its capabilities if the IOF gets some funding to streamline its processes. Elisa also mentioned that some members of FIBO don’t allow access to the public/cloud GitHub instance and that we might need to eventually stand up a private GitHub instance for IOF. We had no further discussion regarding next steps on this point but I think the requirements are: (1) we will utilize both GitHub and Jira. (2) Issues raised against terms and artifacts managed in GitHub should be visible in GitHub. (3) duplication and synchronization of issue content between GitHub and Jira, including the assignment of tracking identifiers and cross-referencing, must be automated. And (4) Jira should serve as the master “system of record” for all issues since some project issues lie beyond GitHub. Additional action item: We should poll our corporate members to see what sort of GitHub policies they have in place and understand if we have an immediate need to stand up a private GitHub instance, or not. Serm is volunteering for this?!?!?
The discussion then moved on to some of the release tools FIBO can make available to IOF.
The first tool discussed was the “RDF Serializer,” which standardizes the formatting of content in ontology files (eliminates white space, orders content in a consistent and repeatable manner).
Ontology term glossary generation tool. We talked a bit about “SourceTree” from Atlassian and certainly other tools currently in use by the WGs to generate such glossaries.
“Jenkins” job/automation supports various dimensions of the ontology publishing process: “hygiene test,” ontology viewer content generator, versioned IRI generation. Follow-on questions: does it automate versioned folder generation, redirect the virtual paths to the new versioned files and take care of deploy documents to the correct target folders?
The likely action items on the above is for some of the working groups to test out these tools and report back on their findings – from which we might glean some requirements on what we might need/require. Elisa has already run the Serializer against the annotation properties file (see here separate email and findings on this). Action item for Evan to update the annotation file and publish a new version.
Many of the above to be revisited and discussed in our next meeting.
We then discussed more general requirements for releases/release process:
What artifacts constitute a release (i.e., release products as FIBO calls them)?
Ontology files (including the additional IOF-authored & imported meta files)
Data files/data dictionary
Vocabulary (glossary as mentioned above)
Release notes
Other supporting documentation (version independent and both tool- and ontology-centric)
Use cases (likely not something we are ready to publish externally, but to be considered downstream)
For source (ontology files and related artifacts) workflows:
The review and approval step before a change is committed back into GitHub must include at least 2 approvers. Question: Who should these approvers be (as in perhaps 1 ontologist + 1 subject matter expert)?
Ontology publishing tools (in current use by FIBO and available to the IOF):
Hygene testing tool
Ontology Viewer/content generation tool
Jenkins job for automating Ontology content deployment
Authoring of release notes is currently a manual process.
Key questions:
Do we version ontologies at the domain level or at a more granular level (module/file level)?
What frequency of releases are we looking at (yearly vs quarterly)?
Do we synchronize releases across the domains, modules and core, or allow each to release on their own, potentially separate, schedule?
...