OEWG 20110517

OBO-Edit Working Group Meeting: Tuesday, May 17, 2011, 8:30am PDT

Conference call numbers:
US: 1 866 953 9688
UK: 0808 238 6001
PIN: 801561

Agenda/Chair: Nomi Harris
Minutes: Nomi
Attendees: Nomi, Chris Mungall, Heiko Dietze, Karen Christie, Midori Harris, Ramona Walls, Rebecca Foulger

Bug and Feature Trackers

• OE Bug tracker
• OE Feature tracker

Discussion items

• OBO-Edit 2.1-beta13 released on May 16--release notes are here

Fixed since last meeting

• Search aspect is missing the "can be reached via" selector

Can't restrict ancestor search by relation type in 2.1b12 (same bug)

• • If you have the reasoner on and select "ancestor" or "descendant" as the search aspect, it's supposed to add a list of relations and the label "can be reached via", but that stopped happening in 2.1-b11 or 12
  • Fixed in 2.1-b13
• Search for children is missing some (unless reasoner on)
  • This was an old bug. Turned out that when links to children were being collected, the code erroneously took the PARENT of each link instead of the child. (But when the reasoner was on, there was a different loop, which is why the child search worked ok with the reasoner on.)
  • Fixed in 2.1-b13
• Filtered save with "child" aspect throws exception
  • Fixed in 2.1-b13

• As suggested by OEWG, all search aspects are once again available in search aspect menu. If user selects an aspect (Ancestor or Descendant) that requires reasoning and the reasoner isn't on, they get a pop-up error message:

• • (The previous solution--leaving Ancestor and Descendant out of the aspect menu when reasoner was off--confused users.)
• Also, you can (once again) do filtered saves with Ancestor and Descendant even when the reasoner is off, because the filtered save method can start a reasoner.
  • Some users complained that these filtered saves that silently invoked the reasoner took so long they thought OE had crashed. Now the Progress window says "This filtered save requires the reasoner--please be patient." (Note that the progress string is limited in length--if you make it longer than that it gets cut off.)
• Add verification check for single intersection_of tag
• Changed wording of messages in OE and in installer about the fact that memory allocation is limited to 1860M unless you have a 64-bit JVM.
  • No way to change installer to conditionally allow >1860M if JVM is 64-bit, but at least wording now explains why there's a limit and how you can get around it.

Next bugs to work on

• Is_a closure broken
  • Filtered save with "is_a closure" checked doesn't save all the terms it should.
  • Still working on this
• Bad handling of unrecognized relation (text editor et al.)
  • I looked into this some--will not be simple to fix. Has to do with how dangling objects (e.g., unrecognized relations) are handled in different components.
• Bugs with priority 6, Features with priority 6-7
  • Let's talk about which of these I should look at next.

Discussion

• Action Item: OEWG members will look at the bug and feature trackers (sorted in descending order by priority) and reprioritize where appropriate (or ask Nomi to reprioritize if they don't have permission to change priorities) and suggest to Nomi which bugs to look at next.
• Karen reported that she can remove discriminating relationships from cross-products, but there's no trashcan icon for removing the intersection genus. Sometimes she wants to get rid of the whole cross product. She has tried clearing out all the fields and committing, but that doesn't (always?) work.
  • Midori suggested a workaround--do it in the parent editor
  • Ramona said that sometimes she can't get rid of these relationships when she's been running the reasoner; if she turns off the reasoner and restarts, it works. Karen said she didn't have the reasoner on.
  • The problem where you can't delete some relationships appears to be intermittent.
  • Chris M said you can have more than one discriminating relationship and you might want to delete those individually, but you'd never want to delete the genus and leave the differentia behind. So we should keep the trashcan for the discriminating relationship, but also add a new overall trashcan for getting rid of the whole thing.
    • Karen will add a tracker item for this.
• Karen: if you obsolete a term, you can no longer edit its definition, but documentation says you can. For GO, editors need to add OBSOLETE to beginning of definition. If you don't remember to do that before you obsolete the term, you can't edit the definition and you can't unobsolete the term. (Can still edit comment field but not definition.)
  • OBO-Edit could automatically add OBSOLETE: to beginning of def--but what if other projects don't want that?
    • Could that be a config option? Nomi: yes, but it's kind of a pain to add that.
  • Nomi: how about you can still edit definition after obsoleting a term, but it pops up a warning ("Term is obsolete--are you sure you want to edit definition?")
    • People liked that idea
  • Ramona suggested: the warning you get when you're about to obsolete a term could mention that you can't edit the definition after obsoleting
    • Nomi liked that idea a lot because it would be very easy (just add text to a message).
  • At any rate, documentation should match behavior (either definition is editable in obsolete terms or it's not).
• Action item: GO meeting attendees, please take note of any OBO-Edit problem reports or requests and send them to Nomi.

Links

Back to OEWG meeting agenda and minutes list