OEWG 20110503: Difference between revisions

From GO Wiki
Jump to navigation Jump to search
No edit summary
 
(35 intermediate revisions by 2 users not shown)
Line 1: Line 1:
OBO-Edit Working Group Meeting: Tuesday, May 5, 2011, 8:30am PDT
[[Category:OBO-Edit working group]]
OBO-Edit Working Group Meeting: Tuesday, May 3, 2011, 8:30am PDT


Conference call numbers:<br />
Conference call numbers:<br />
Line 7: Line 8:


Agenda/Chair: Nomi Harris<br />
Agenda/Chair: Nomi Harris<br />
Minutes:  <br />
Minutes:  Nomi<br />
Attendees: <br />
Attendees: Nomi, Heiko, Chris M., Karen, Ramona, Becky, Paola, Midori, Harold, Marcus<br />


== Bug and Feature Trackers ==
== Bug and Feature Trackers ==
Line 18: Line 19:
* OBO-Edit 2.1-beta12 released on April 25--[http://wiki.geneontology.org/index.php/OBO-Editv2.1beta12 release notes are here]
* OBO-Edit 2.1-beta12 released on April 25--[http://wiki.geneontology.org/index.php/OBO-Editv2.1beta12 release notes are here]
* SourceForge trackers closed to anonymous posting due to spam.
* SourceForge trackers closed to anonymous posting due to spam.
* Chris Mungall will present the plan for the GO ontology editing environment.
* A user was puzzled that her Typedefs were disappearing from her filtered save results.  David O-S said that she needed to check off the 'always save properties' option in the filtered save interface.  This fixed the user's problems.  Nomi added more info about this to the userguide.


===Fixed since last meeting===
===Fixed since last meeting===
* [http://sourceforge.net/tracker/?func=detail&aid=3287434&group_id=36855&atid=418257 Cycle over mixed relationship types -> infinite loop]
* [http://sourceforge.net/tracker/?func=detail&aid=3287434&group_id=36855&atid=418257 Infinite loop while loading fly_anatomy_XP -> can't save]
** Can't save fly_anatomy_XP.obo because OE goes into an infinite loop while running verification checks.
** Can't save fly_anatomy_XP.obo because OE goes into an infinite loop while running verification checks.
** Chris thought this was because fly_anatomy_XP has cycles over mixed relationship types, which is valid but was not considered valid when OBO-Edit was originally developed. This may be true, but in fact it turned out that the infinite loop was caused by a term that listed itself as an alternate ID.  The validation process involves recursively checking the term's alternate ID, and since it's the same term, it just recurses over and over.
** It turned out that the infinite loop was caused by a term that listed itself as an alternate ID.  The validation process involves recursively checking the term's alternate ID, and since it's the same term, it just recursed over and over.
** Two ways to fix the infinite loop (it now does both):
** alt_id == primary_id now triggers a fatal error when you try to read in the file (just as obsolete term's id == replacement id already did)
*** Before recursing on alt_id in the validation check, check whether it's the same as the primary ID.
*** When reading in ontology, check for alt_id == primary_id and refuse to add it.
* [http://sourceforge.net/tracker/?func=detail&aid=3289552&group_id=36855&atid=418257 adding words to dictionary removes uncommitted text edits]
* [http://sourceforge.net/tracker/?func=detail&aid=3289552&group_id=36855&atid=418257 adding words to dictionary removes uncommitted text edits]
** Unfortunately, fixing this involved undoing a change I had made that fixed another, more minor bug:<br> [http://sourceforge.net/tracker/?func=detail&aid=3203198&group_id=36855&atid=418257 Words added to dictionary in unedited term don't turn black immediately.]<br>For now, we'll just have to live with the newly-added-to-dictionary word staying red until user does something that causes a commit (or moves to another term and then back).
** Unfortunately, fixing this involved undoing a change I had made that fixed another, more minor bug:<br> [http://sourceforge.net/tracker/?func=detail&aid=3203198&group_id=36855&atid=418257 Words added to dictionary in unedited term don't turn black immediately.]<br>For now, we'll just have to live with the newly-added-to-dictionary word staying red until user does something that causes a commit (or moves to another term and then back).
Line 32: Line 31:
** Loading multiple ontologies--PATO, GO, cell etc, Marcus gets message "ID profile mismatch--use profile loaded from the file"?  Which ontology file is it referring to?  It should say which.
** Loading multiple ontologies--PATO, GO, cell etc, Marcus gets message "ID profile mismatch--use profile loaded from the file"?  Which ontology file is it referring to?  It should say which.
** Thanks to Midori for providing two tiny ontologies with ID profiles so I could test this.
** Thanks to Midori for providing two tiny ontologies with ID profiles so I could test this.
** This message now lists the two ID profiles, so at least it's somewhat clearer.  However, it still seems a bit random which one it chooses as the new one if you have multiple ontologies loaded, and I have not yet added the new feature to let you select which of multiple ID profiles you want to use.  (If there are only two, it does let you choose between the two.)
** This message now lists the two ID profiles, so at least it's somewhat clearer.  However, it still seems a bit random which ID profile OBO-Edit chooses as the new one if you have multiple ontologies loaded, and I have not yet added the new feature to let you select which of multiple ID profiles you want to use.  (If there are only two, it does let you choose between the two.)
* Bogus warning messages during validation:  if you have a URL in a comment or definition, you get complaints about there not being spaces between "sentences" and lack of capital letters.
* Bogus warning messages during validation:  if you have a URL in a comment or definition, you get complaints about there not being spaces between "sentences" and lack of capital letters.
** I have decreased the number of these (though not totally solved the problem)
** I have decreased the number of these (though not totally solved the problem)


===Currently working on===
===Currently working on===
* [http://sourceforge.net/tracker/?func=detail&aid=3296528&group_id=36855&atid=418257 Search aspect is missing the "can be reached via" selector]
** 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.
** Fixed in 2.1-b13 (but not yet committed)
* Weird nondeterministic behavior in Ontology Tree Editor:  for some ontologies (such as [https://phenoscape.svn.sourceforge.net/svnroot/phenoscape/trunk/vocab/teleost_anatomy_VAO_edit.obo teleost_anatomy_VAO_edit.obo]), Tree Editor sometimes displays some non-root terms as roots.  Which terms are shown as roots varies each time you restart!
[[File:teleost1.png]]
[[File:teleost2.png|And now I relaunch it on the same teleost_anatomy_VAO_edit file again...]]
** David O-S figured out how to prevent this weird nondeterministic behavior: "Strip out the OBO_REL: prefix from the relations that have it and, as far as I can tell, the odd behavior goes away...My guess is that OBO-Edit has trouble parsing relationships and/or intersections with these relations."
** That fixes the weird behavior, but I still don't know what causes it!
* 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.
** 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 uses.  I 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:
[[File:aspect-hover.png]]
** The need to turn on the reasoner to see Ancestor and Descendent search aspects is explained in the user guide page about "Advanced Searching" (see below)--if anyone has ideas about where else in the documentation I can explain it let me know.
[[File:aspect-doc.png|frame|User guide page about search aspects]]
* 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)]
* [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 one of the reasoners, you find more children. But what do we really mean by "children"?
** 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?)
** Chris added [http://sourceforge.net/tracker/?func=detail&aid=3265376&group_id=36855&atid=418257 some comments to the bug report], but I need clarification.
** 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]
* [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.
** 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===
Line 51: Line 73:


===Discussion===
===Discussion===
* A user was puzzled that her Typedefs were disappearing from her filtered save results. David O-S said that she needed to check off the 'always save properties' option in the filtered save interface.  This fixed the user's problems. Nomi added more info about this to the userguide.
* SourceForge trackers are now closed to anonymous posting due to spam.
* The same user was puzzled that older versions of OBO-Edit included Ancestor and Dependent in the Aspect menu but the latest OE didn't. We explained that OE can't get the right answers to Ancestor and Dependent searches unless the reasoner is on, so these searches are not included in the Aspect menu when the reasoner is off.
** Yay.
** 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 uses. I 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:
** Most of the useful bug reports and comments that we get are from non-anonymous users.
[[File:aspect-hover.png]]
* Fixed: adding words to dictionary removes uncommitted text edits
 
** Unfortunately, fixing this involved undoing a change I had made that fixed another, more minor bug: Words added to dictionary in unedited term don't turn black immediately.
** The need to turn on the reasoner to see Ancestor and Dependent search aspects is explained in the user guide page about "Advanced Searching" (see below)--if anyone has ideas about where else in the documentation I can explain it let me know.
** Attendees agreed with Nomi that this is, indeed, a very minor issue.  Anyone who didn't agree with that wisely chose to stay silent.
 
* ID Profile Mismatch dialogue box and multiple ontologies
[[File:aspect-doc.png|frame]]
** My quick improvement of listing two ID profiles and letting you choose between the two was deemed a major improvement over the current opacity.
 
* 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.
** While Nomi was testing 2.1-b12, one time it included Ancestor and Dependent in the Aspect menu even though the reasoner was off. After quitting and restarting, I couldn't get the problem to happen again. Let me know if anyone sees this happen.
** 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.
* 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 firstI 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 reliableIn 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."
** 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.
** How did OE 2 do these filtered saves?  Did it invoke a reasoner, and how/when/why was this changed?  (Nomi didn't make that change.)
*** 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.
* Discussion of maximum memory allocation in OE
** Marcus has a computer with 6G of RAM, yet the OE installer (and config manager) only let you set the memory allocation to a max of 1860M.  However, when he hand-edited oboedit.vmoptions and set it to a higher number, OE worked great (and didn't run out of memory like it did before).
** This is because 32-bit JVMs can only handle 1860M.  However, newer 64-bit JVMs (which some users have--such as Marcus) can use as much memory as you care to give them.
*** Is there some way to ask from within a running Java app whether the JVM is 32- or 64-bit?  If so, we could set the max memory accordingly(But might not be able to do that in the installer.)
**** Heiko investigated and didn't find any easy way to figure it out from inside a Java app.
* 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==
==Links==
[[OBO-Edit_Working_Group_Meeting_Agenda_and_Minutes|Back to OEWG meeting agenda and minutes list]]
[[OBO-Edit_Working_Group_Meeting_Agenda_and_Minutes|Back to OEWG meeting agenda and minutes list]]

Latest revision as of 17:56, 30 June 2014

OBO-Edit Working Group Meeting: Tuesday, May 3, 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, Heiko, Chris M., Karen, Ramona, Becky, Paola, Midori, Harold, Marcus

Bug and Feature Trackers

Discussion items

  • OBO-Edit 2.1-beta12 released on April 25--release notes are here
  • SourceForge trackers closed to anonymous posting due to spam.
  • A user was puzzled that her Typedefs were disappearing from her filtered save results. David O-S said that she needed to check off the 'always save properties' option in the filtered save interface. This fixed the user's problems. Nomi added more info about this to the userguide.

Fixed since last meeting

  • Infinite loop while loading fly_anatomy_XP -> can't save
    • Can't save fly_anatomy_XP.obo because OE goes into an infinite loop while running verification checks.
    • It turned out that the infinite loop was caused by a term that listed itself as an alternate ID. The validation process involves recursively checking the term's alternate ID, and since it's the same term, it just recursed over and over.
    • alt_id == primary_id now triggers a fatal error when you try to read in the file (just as obsolete term's id == replacement id already did)
  • adding words to dictionary removes uncommitted text edits
  • ID Profile Mismatch dialogue box and multiple ontologies
    • Loading multiple ontologies--PATO, GO, cell etc, Marcus gets message "ID profile mismatch--use profile loaded from the file"? Which ontology file is it referring to? It should say which.
    • Thanks to Midori for providing two tiny ontologies with ID profiles so I could test this.
    • This message now lists the two ID profiles, so at least it's somewhat clearer. However, it still seems a bit random which ID profile OBO-Edit chooses as the new one if you have multiple ontologies loaded, and I have not yet added the new feature to let you select which of multiple ID profiles you want to use. (If there are only two, it does let you choose between the two.)
  • Bogus warning messages during validation: if you have a URL in a comment or definition, you get complaints about there not being spaces between "sentences" and lack of capital letters.
    • I have decreased the number of these (though not totally solved the problem)

Currently working on

  • Search aspect is missing the "can be reached via" selector
    • 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.
    • Fixed in 2.1-b13 (but not yet committed)
  • Weird nondeterministic behavior in Ontology Tree Editor: for some ontologies (such as teleost_anatomy_VAO_edit.obo), Tree Editor sometimes displays some non-root terms as roots. Which terms are shown as roots varies each time you restart!

And now I relaunch it on the same teleost_anatomy_VAO_edit file again...

    • David O-S figured out how to prevent this weird nondeterministic behavior: "Strip out the OBO_REL: prefix from the relations that have it and, as far as I can tell, the odd behavior goes away...My guess is that OBO-Edit has trouble parsing relationships and/or intersections with these relations."
    • That fixes the weird behavior, but I still don't know what causes it!
  • 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.
    • 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 uses. I 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 need to turn on the reasoner to see Ancestor and Descendent search aspects is explained in the user guide page about "Advanced Searching" (see below)--if anyone has ideas about where else in the documentation I can explain it let me know.
User guide page about search aspects
  • 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?
  • 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.
  • 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

Discussion

  • SourceForge trackers are now closed to anonymous posting due to spam.
    • Yay.
    • Most of the useful bug reports and comments that we get are from non-anonymous users.
  • Fixed: adding words to dictionary removes uncommitted text edits
    • Unfortunately, fixing this involved undoing a change I had made that fixed another, more minor bug: Words added to dictionary in unedited term don't turn black immediately.
    • Attendees agreed with Nomi that this is, indeed, a very minor issue. Anyone who didn't agree with that wisely chose to stay silent.
  • ID Profile Mismatch dialogue box and multiple ontologies
    • My quick improvement of listing two ID profiles and letting you choose between the two was deemed a major improvement over the current opacity.
  • 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.
  • Discussion of maximum memory allocation in OE
    • Marcus has a computer with 6G of RAM, yet the OE installer (and config manager) only let you set the memory allocation to a max of 1860M. However, when he hand-edited oboedit.vmoptions and set it to a higher number, OE worked great (and didn't run out of memory like it did before).
    • This is because 32-bit JVMs can only handle 1860M. However, newer 64-bit JVMs (which some users have--such as Marcus) can use as much memory as you care to give them.
      • Is there some way to ask from within a running Java app whether the JVM is 32- or 64-bit? If so, we could set the max memory accordingly. (But might not be able to do that in the installer.)
        • Heiko investigated and didn't find any easy way to figure it out from inside a Java app.
  • 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