OEWG 20110705: Difference between revisions

From GO Wiki
Jump to navigation Jump to search
No edit summary
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
[[Category:OBO-Edit working group]]
OBO-Edit Working Group Meeting: Tuesday, July 5, 2011, 8:30am PDT
OBO-Edit Working Group Meeting: Tuesday, July 5, 2011, 8:30am PDT


Line 8: Line 9:
Agenda/Chair: Nomi Harris<br />
Agenda/Chair: Nomi Harris<br />
Minutes: <br />
Minutes: <br />
Attendees: <br />
Attendees: Nomi Harris, Midori Harris, Harold Drabkin, Heiko Dietze, Karen Christie, Ramona Walls, Paola Roncaglia<br />


== Bug and Feature Trackers ==
== Bug and Feature Trackers ==

Latest revision as of 17:57, 30 June 2014

OBO-Edit Working Group Meeting: Tuesday, July 5, 2011, 8:30am PDT

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

Agenda/Chair: Nomi Harris
Minutes:
Attendees: Nomi Harris, Midori Harris, Harold Drabkin, Heiko Dietze, Karen Christie, Ramona Walls, Paola Roncaglia

Bug and Feature Trackers

Fixed since last meeting

  • Ancestor/descendant relationships missing
    • In the search panel, when looking for descendants/ancestors of a term, the pulldown menu for relationships only includes default obo-edit relationships and not ontology-specific relationships.
    • I accidentally broke this a few months ago when fixing some other aspects of aspect search (descendant, parent, etc.). Last week restored it to approximately the same slightly broken behavior as it had before: the ontology-specific relationships are added to the pulldown menu but only when you do something to change the search panel--e.g., open the aspect selector, change the aspect, etc. I now have this completely fixed (BY WORKING ON IT DURING A HOLIDAY WEEKEND I HOPE YOU'RE HAPPY).
  • link search problems in beta 14
    • In beta 14, Type and Self both prompt the options that earlier versions only display for type. So, searching by name or definition is impossible Also, string search options are not suppressed for queries of a binary value, e.g.,
      • Beta3: "Select links where [Self] that [don't have] a [is redundant]" (The Englishish of the queries breaks down a bit in these cases....)
      • Beta14: "Select links where [Self] [don't have] a [is redundant] that [equals] the value <box for entering strings>"
    • Beta 3 has the correct (link search) behavior, even if the naming is a little odd:
      • Type allows searching of any string field (not sure all of the options make sense, but the ones that do work)
      • Self allows queries of binary values (+ oddly, string searching on namespace.)
        • When query on a binary (e.g.- is_redundant) is chosen, the string search options are (sensibly) suppressed.
    • The problems described above are now fixed.

Currently working on

  • Is_a closure broken
    • Terry wrote, "I just used beta14 to do is_a closure on cell.edit.obo with GO and PR. Overall it worked but there were two issues. 1) Non is_a relationships for previously MIREOTED terms were added, leading to a dangling parents error. For example, "regulates" relationships were added to many GO terms that were already in CL. 2nd, all typedefs disappeared."
    • Midori commented, "I can confirm that I get the same thing (or at least something similar) happening with 'regulates' relationships: is_a closure saves some terms that would only be there if it followed at least one 'regulates' link. Curiously, it didn't include all 'regulates' links; the term I used for testing had a regulates link itself that apparently wasn't followed. Specifically, I tested using a nonsense xp in SO, with the GO term 'regulation of polysaccharide metabolic process' in an intersection_of tag. The saved file contained all the is_a ancestors I expected, plus the is_a ancestors of 'polysaccharide metabolic process' -- but it didn't have 'polysaccharide metabolic process' itself. I'm getting typedefs saved if they match the filter, and not if they don't (all are saved if I tick 'always save properties' - that seems to be working fine).
  • filtered save doesn't save dangling parents
    • David wrote: "A filter specifies a bunch of term stanzas to save, some of which may have relationships whose objects are not in saved stanzas. 'Allow dangling references' should save those relationships. In 2.1beta3, it does. In 2.1beta13 and 2.1beta14 it does not. Not sure what beta was the first to have this bug."
    • Dangling parent save was broken (not by me) in r2703 on 5/14/2010. The change that broke it was these two lines that were added to OBOFileAdapter.doOperation:
                           /**FilteredPath sets the allowdangling modifier to false on initialization by default.                                                                                                           
                               * this works for all other cases wrt the gui where allowdangling is false by default.                                                                                                           
                               * it is true by default for obo2obo though, hence                                                                                                                                               
                               * explicitly setting allowdangling as per ioprofile settings since the ioprofile.getSaveRecords does not import that modifier.  **/                                                           
                            for(FilteredPath filteredPath : filteredPaths)
                                  filteredPath.setAllowDangling(ioprofile.allowDangling);
      • If I comment out those two lines, then the dangling parent save works again. I'm leery of doing that, though, since apparently those lines were added as a fix for obo2obo and I am not at all keen to have to debug obo2obo. So I did some more investigation, and it turned out that the ioprofile (which is passed to doOperation as an AdapterConfiguration) isn't necessarily the right ioprofile--for example, it might be a read profile when what you're doing is writing. This made debugging complicated, because depending on your history, different ioprofiles might be floating around and it's unclear to me how one is chosen to be passed to doOperation. doOperation is not called explicitly within the OBO-Edit code; it's one of those sort of built-in methods. So I don't know how the mysterious caller decides which AdapterConfiguration to pass in, but clearly it's not always the right one, and it's one of those "how could this ever have worked reliably?" situations--it seems like there could be other bad behaviors resulting from using the wrong ioprofile.
      • Waiting for comments from Chris M. and/or David O-S

Next bugs to work on

Discussion

  • Release 2.1-b14 was a private release to a few specific people to test whether something they reported was fixed. Nomi will do a public release of 2.1-b15 before July 12.
  • Next OEWG meetings:
    • Nomi will be away July 19; however, she will be in Cambridge/Hinxton visiting some OEWG members on July 21 and 22. Should we have an OEWG meeting on July 21 or 22 (8:30am PDT or thereabouts)?
      • Doodle poll for meeting time on July 21 or 22
        • UPDATE: it looks like July 21 at 8:30am PDT works for the most people.
    • Nomi will also be away August 2--we'll just skip that one.
    • The next regularly scheduled OEWG meeting after that will be August 16
  • Graphviz will break in OE using Mac OS 10.7
    • I do not have the time to support GraphViz. Jennifer Deegan used to deal with this. Any volunteers to take this on?
    • Harold thinks the issue has to do with the GraphViz configuration file specifying a file that it can't get to (or something like that). He can't look into this because his lab won't let them get Mac OS 10.7.
  • A user in Belgium reported that OBO-Edit couldn't read her OBO files.
    • I checked them and they are some weird format that is not OBO, so no wonder. It says in the header they were generated by OE 1.01
    • David O-S thought her files might be GO flatfile format, and suggested that she read them back into OE 1.01, save them out as OBO (probably OBO 1.0--I don't think 1.01 could do OBO 1.2), and then get a new OBO-Edit and read them into that.
      • Thank you, David and Midori, for helping answer this question (and others on the OEWG mailing list).
  • Ramona wondered if anyone knew the difference between the greedy and strict root detection algorithms (which show different terms as roots).
    • No one on the call knew. Chris Mungall probably knows.
    • Ramona said she'd just stick with the one that worked.

Links

Back to OEWG meeting agenda and minutes list