Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
maxLevel1

Meeting Minutes

Participants

Farhad Ameri Evan Wallace Chris Will Gianmaria Bullegas Serm Kulvatunyou Jim Wilson Dusan Sormaz

Agenda

  1. Review and finalize Release Criteria

  2. Establish initial list of “requirements” to be achieved with managing Tasks and Issues and how they should be tracked.

  3. Review the suggested validation SPARQLs and checklist Elisa provided

  4. Review open action items

Minutes

  1. 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:

    1. Evan to Review the ISO 21838 drafts provided to us by Barry and excerpt applicable criteria for use in releasing IOF Core, and a subset applicable to the release of IOF domain reference ontologies. ISO 21838 is about Top‐Level Ontologies (TLO) and includes two parts: Part 1, Requirements, & Part 2, Basic Formal Ontology.

  2. asdf

  3. 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.

  4. 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

  1. Review the minutes and action items from prior meetings, enter relevant ones in Jira, and dispatch them.

  2. Work through details of the “post-term candidate definition” workflow of the ontological development process.

  3. Other topics

Minutes

  1. In our review of action items from the prior meetings, the relevant discussion points are as follows:

    1. 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 tohttps://oagiscore.atlassian.net/browse/DRMP-6?atlOrigin=eyJpIjoiZDNkMmYxY2RjYWM5NDg1YThlOTBmOGIwYWRjMmJjYzYiLCJwIjoiaiJ9

    2. 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 Jira LegacyshowSummaryfalseserverSystem JIRAserverIde40ab0a4-b576-382d-85fc-495e1da7d966keyhttps://oagiscore.atlassian.net/browse/DRMP-8. Will also mentioned that with the first option, we have the undesirable effect of intermingling repository information across both IOF and OAGi.

    3. 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 https://oagiscore.atlassian.net/browse/DRMP-4 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.

  2. We reviewed the provisional Candidate Term Definition Review Procedure that was recently introduced at one of the IOF Core meetings. Feedback included:

    1. 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 LegacyshowSummaryfalseserverSystem JIRAserverIde40ab0a4-b576-382d-85fc-495e1da7d966keyhttps://oagiscore.atlassian.net/browse/DRMP-9.

    2. 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 .

    3. 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.

  3. On agenda topic #3, Chris took on the action item to https://oagiscore.atlassian.net/browse/DRMP-7

Meeting Minutes

Participants

Elisa Kendall Farhad Ameri William Sobel Jim Wilson Evan Wallace Dusan Sormaz Serm Kulvatunyou Chris Will

...

  1. 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):

    1. 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?

    2. 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.

    3. 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:

      1. 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.

      2. 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.

      3. 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.

    4. We’ll have to detail the above points further in our next meeting.

  2. 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

...

  1. 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?

  2. 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.

  3. Workflows and Tooling for Ontology Development and Release. Highlights of our discussions are as follows:

    1. 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.

    2. 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..

    3. 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.

    4. 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.

  4. 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

...