OEWG 20110705: Difference between revisions

From GO Wiki
Jump to navigation Jump to search
Line 25: Line 25:
* [http://sourceforge.net/tracker/?func=detail&aid=3176685&group_id=36855&atid=418257 Is_a closure broken]
* [http://sourceforge.net/tracker/?func=detail&aid=3176685&group_id=36855&atid=418257 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."
** 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.
** 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).
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. A
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).


* [http://sourceforge.net/tracker/?func=detail&atid=418257&aid=3316815&group_id=36855 filtered save doesn't save dangling parents]
* [http://sourceforge.net/tracker/?func=detail&atid=418257&aid=3316815&group_id=36855 filtered save doesn't save dangling parents]
Line 38: Line 36:
                             for(FilteredPath filteredPath : filteredPaths)
                             for(FilteredPath filteredPath : filteredPaths)
                                   filteredPath.setAllowDangling(ioprofile.allowDangling);
                                   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.
*** 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
*** Waiting for comments from Chris M. and/or David O-S


* [http://sourceforge.net/tracker/?func=detail&atid=418257&aid=3346958&group_id=36855 link search broken in beta 14]
* [http://sourceforge.net/tracker/?func=detail&atid=418257&aid=3346958&group_id=36855 link search broken 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.
** 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....)
*** 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>"
*** Beta14: "Select links where [Self]  [don't have] a [is redundant] that [equals] the value <box for entering strings>"
** Beta 3 has the correct behavior, even if the naming is a little odd:
** 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)
*** 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.)
*** 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.
**** When query on a binary (e.g.- is_redundant) is chosen, the string search options are (sensibly) suppressed.
** The problems described above are fixed in b15, with one remaining issue:  if you select "Type", the "have/have not" option pulldown doesn't show all the types until after you select something from the limited options in that menu.  So, if you select (say) "Namespace", it then shows "Any text field" and if you pull down that list again you see all the types.
** The problems described above are fixed in b15, with one remaining issue:  if you select "Type", the "have/have not" option pulldown doesn't show all the types until after you select something from the limited options in that menu.  So, if you select (say) "Namespace", it then shows "Any text field" and if you pull down that list again you see all the types.
*** Changed bug title to match current behavior
*** Changed bug title to match current behavior

Revision as of 14:43, 1 July 2011

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:

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.). I have now 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. If you are restarting OE and the search panel already showed the aspect search that you still want to do, it won't include the ontology-specific relationships. I tried to fix this, but because of the control flow in OE, I couldn't find a way to make it work.

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
  • link search broken 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 fixed in b15, with one remaining issue: if you select "Type", the "have/have not" option pulldown doesn't show all the types until after you select something from the limited options in that menu. So, if you select (say) "Namespace", it then shows "Any text field" and if you pull down that list again you see all the types.
      • Changed bug title to match current behavior

Next bugs to work on

Discussion

  • 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)?
    • 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

Links

Back to OEWG meeting agenda and minutes list