OEWG 20090407

From GO Wiki
Revision as of 05:47, 7 April 2009 by Jdeegan (talk | contribs)

Jump to: navigation, search
GOC Meeting OE Cake

OBO-Edit Working Group, Tuesday April 7th, 2009 9.30 a.m. PST

Conference call details:
US: 1-888-727-6732
Outside US: 1-719-867-3417
pin: 601425

Agenda/Chair: Midori
Minutes: Jen

Action items carried over

  • Amina and Chris
    • Document ID Fixer, Cross Product pages, Semantic Parser manager.
  • Amina
    • Release notes need to acknowledge known issues
    • RC announcement on sourceforge, oboedit.org and the wiki.
  • Loading_a_History_File.htm - check for accuracy, especially in light of SF 2526247 bug report
  • Amina plans to make the graph viewer work the same as the graph editor (I think this has to do with imlpied links, reasoner, etc. but A will put all in documentation)
  • user dictionary fix in progress
  • Documentation - pending user guide pages
  • Misc user issues - Colin, other non-wg users

Discussion items

  • GOC Meeting
  • OBO-Edit 2.0 Release and next steps
  • config directory changes for version progressions


  • Update test ontologies distributed with release under test_resources for new users to poke around with.
  • Close/ update out of date tracker items

Questions from Jen on how OBO-Edit should behave:

1a) In OBOMerge if a term in the parent file has two relationships, and one gets deleted in the branch file and the other gets deleted in the output file, then the term is currently left with no relationships at all in the output file.

This is because leaving a relationship in is not considered by OBO-Edit to be a concrete decision that would be in conflict with the other decision to delete the relationship. The rules of precedence are not invoked and the deletion is automatically accepted, regardless of which file has precedence.

Is this what we want? It means that very occasionally OBOMerge might produce unexpected orphan children, though these would be very obvious to the user in the output file. Perhaps a warning message would be appreciated?

1b)We have the same behavior with substitution tags. If a term had two replaced_by tags and one was deleted in the live file and the other was deleted in the branch file, then there would be none in the output file.

What behavior do we want to see? Would it be best just to have a verification check for obsolete terms with no substitution tags?

2) If a term mentioned in a substitution tag is subsumed in a merge my tests show that the substitution tag is not currently updated to show the new primary id and term name. Would we like this to happen automatically or should there just be a dialog box to say that substitution tags need updating?

Action Items


Back to OEWG Meeting agenda and minutes List