OEWG 20110517: Difference between revisions

From GO Wiki
Jump to navigation Jump to search
No edit summary
Line 20: Line 20:


* [http://sourceforge.net/tracker/?func=detail&aid=3296528&group_id=36855&atid=418257 Search aspect is missing the "can be reached via" selector]
* [http://sourceforge.net/tracker/?func=detail&aid=3296528&group_id=36855&atid=418257 Search aspect is missing the "can be reached via" selector]
[http://sourceforge.net/tracker/?func=detail&aid=3297446 &group_id=36855&atid=418257 Can't restrict ancestor search by relation type in 2.1b12] (same bug)
[http://sourceforge.net/tracker/?func=detail&aid=3297446&group_id=36855&atid=418257 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
** 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
** Fixed in 2.1-b13
Line 29: Line 29:
** Fixed in 2.1-b13
** Fixed in 2.1-b13


* A user was puzzled that older versions of OBO-Edit included Ancestor and Descendent in the Aspect menu but the latest OE didn'tWe explained that OE can't get the right answers to Ancestor and Descendent searches unless the reasoner is on, so these searches are not included in the Aspect menu when the reasoner is off.
* 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: "If you want to search Ancestors or Descendants, you must first turn on the Reasoner (use the Reasoner Manager component to do that).[[File:aspect-message.jpg]]
** I agree that it's a bit unintuitive to have those search aspects simply disappear from the aspect menu without a trace.  What I wanted to do was to leave them in the menu, but disable them (so they'd be grayed out). This turned out not to be possible with the current setup; I would have had to rewrite the whole pulldown menu class that the search aspect usesI also would have liked to add a tooltip so that if you hovered your mouse over the aspect menu, it would explain that the missing aspects could be enabled by turning on the reasoner.  Again, it turned out that the class that handles that menu can't add tooltips. It didn't seem worth spending a huge amount of time on this, so I did the best I could and added a tooltip to the word "in" next to the Aspect menu:
** (The previous solution--leaving Ancestor and Descendant out of the aspect menu
[[File:aspect-hover.png]]
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.)


David O-S said: "Oddly, filtered saves on earlier versions of OE 2 that use restrictions on ancestor/descendant work fine without a reasoner being turned on first.  I believe that this is because a reasoner (most likely the rule-based-reasoner) is being run as part of the save process.  From the few tests I've done, I believe the output of these filtered saves sans reasoner to be reliable.  In fact, this is extremely useful to me - as, for the ontology I work with, trying to get a filtered save to work after running a reasoner is painfully slow and dangerously close to using up OE2s available memory."
** The code that does filtered save invokes the reasoner (if the reasoner hasn't already been activated) if the user checks the "save implied links" checkbox.
** If I allow the Ancestor aspect to be chosen in the filtered save interface, it does the right thing (for the test example--more testing is needed).
** I am investigating whether I can make search also invoke the reasoner for searches that need it (ancestor/descendent).  Then we wouldn't have to remove those search aspects from the menu.
*** Is this a good idea, or would it be too slow?
* [http://sourceforge.net/tracker/?func=detail&aid=3265376&group_id=36855&atid=418257 Search for children misses some (unless reasoner on)]
** If you turn on the reasoner, you find more children. But what do we really mean by "children"?  (Do we include inferred children or just asserted?)
** Maybe this can be fixed by the same fix that will (hopefully) allow ancestor/descendent searches to invoke the reasoner as needed--maybe child search also requires a reasoner?
** The test case in the original bug report (fly_anatomy.obo) needs to be updated.  I can't get it to find anything even with the reasoners on.
* [http://sourceforge.net/tracker/?func=detail&aid=3176685&group_id=36855&atid=418257 Is_a closure broken]
** Filtered save with "is_a closure" checked doesn't save all the terms it should.
** Maybe this can also be fixed by turning on reasoner for is_a closure filtered save.
===Next bugs to work on===
===Next bugs to work on===
* [http://sourceforge.net/tracker/?func=detail&aid=3265349&group_id=36855&atid=418257 Filtered save with "child" aspect fails]
* [http://sourceforge.net/tracker/?func=detail&aid=3265349&group_id=36855&atid=418257 Filtered save with "child" aspect fails]

Revision as of 13:13, 16 May 2011

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:
Attendees:

Bug and Feature Trackers

Discussion items

Fixed since last meeting

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: "If you want to search Ancestors or Descendants, you must first turn on the Reasoner (use the Reasoner Manager component to do that).File:Aspect-message.jpg
    • (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.)

Next bugs to work on

Discussion

  • A user was puzzled that older versions of OBO-Edit included Ancestor and Descendent in the Aspect menu but the latest OE didn't. We explained that OE can't get the right answers to Ancestor and Descendent searches unless the reasoner is on, so these searches are not included in the Aspect menu when the reasoner is off.
    • Nomi described the attempts she had made to make this more obvious (none of which succeeded in making it particularly obvious), and then suggested a new possible approach: leave Ancestor and Descendent in Aspect menu, but if user chooses one when Reasoner is off and tries to do a search, they get a popup error message explaining that they need to turn the reasoner on to do that search.
      • Attendees liked that solution.
    • Chris said that it should be possible to make OBO-Edit run a simple reasoner (such as the OnTheFly reasoner) to do ancestor searches (as long as they are over all ancestors, not limited by a specific relationship type) without turning on the full reasoner.
      • Nomi said that could be added as a feature request but it probably would not be quick to implement.
  • Filtered save silently invokes a reasoner if the user asks to save inferred links
    • This can be slow--it was suggested that OE should pop up some sort of warning so that the user doesn't think OE has frozen up.
    • Nomi thought maybe running the reasoner for is_a closure filtered save would help fix it.
      • Chris didn't think that would help. (?? Did I remember that correctly??)
        • I don't remember whether Chris said anything. I found when I was testing that it didn't make any difference if I ran the reasoner before saving or not; the is_a closure didn't work as expected (except sort of in beta4). I don't know whether the reasoner was running during the save, nor do I have any idea whether it would help if it did. -Midori
  • Search for children misses some (unless reasoner on)
    • Nomi needs a small test case this. Someone (Marcus??) said they'd make one.
Marcus is making cross products with PATO as intersection genus, GO as differentia (?), saving with complete is_a closure  [I didn't get this all down, can someone help fill it in?]
    • In cross-product intersection box, it shows ugly java.lang.Object@303e7b (the gibberish after '@' seems to be unique per OE launch) (minor edit -Midori)
    • Midori sees that too IF she doesn't load the other ontologies (with allow dangling refs). If she loads the other ontologies, they look ok. (minor edit -Midori)
      • Yes - Marcus and I are both making cross-products using terms from PATO, GO, ChEBI, etc. The terms with the cross-product definitions live in our phenotype ontologies (FYPO for me), and we can load just the phenotype ontology, all of the ontologies used in xp defs, or a subset of the total. Terms from ontologies I load look fine in the cross-product panel; anything from an ontology I don't load gets a java.lang.Object@wackiness. If I load GO and FYPO, for example, FYPO terms and GO terms look good, but PATO and ChEBI terms show up as java.lang.Objects. (added -Midori)
    • If you're making a cross-product ontology, you can't reasonably ask users to load all the other ontologies
    • Chris said the java.lang thing should be posted as a bug report
    • Feature request: way to save just the terms from the ontologies that are needed in the cross-product ontologies (save is_a closure is intended to do this but doesn't really work right)

Links

Back to OEWG meeting agenda and minutes list