OE IRC 20April06
Harold: Cindy is here from MGI; she uses the editor for the mammalian phenotype ontology
midori: Welcome, Cindy!
Harold: There may need to be more documentation around saving in flat-file format from OBO-Edit.
jrichter: Try diagramming that sentence.
jrichter: You're right, Harold. Luckily, the data adapters are next up on my documentation agenda.
jrichter: (After I integrate all the very helpful items that people have sent in)
midori: OK, my timestamp says it's time to start!
jrichter: Okay, Midori. Let's get this early morning party started (in here)
Alex_MGI: Can we have a quick update on beta version status, what works, what should we be using, what is coming next?
jrichter: I can't speak to all the parts of that question...
jrichter: but...
jrichter: the major save bugs have been fixed, and I've been slowly cranking through the bug reports on sourceforge. I was hoping to have a new beta+docs release on Monday (which could be moved up to Friday, if you don't mind the docs being released separately)
midori: Monday's fine for me.
Harold: But officially, we should be using 16 for commited stuff?
Alex_MGI: It's partly a question to the group about whether b16 is preferred over b17 at this time.
Harold: But I thought 17 had some major problems with saving?
midori: Yes, use beta16 until you hear otherwise on the wg or GO list.
jrichter: Certainly. beta17 has a small but deadly bug in the way it saves dbxrefs
jrichter: BTW: Once the save bug was pointed out, I added a test to detect that kind of bug in the future.
jrichter: (As well as any other save bug)
karen: are all parts of the documentation covered? I was late to the last meeting, and then there was never a mail about who had what parts, so I haven't been assigned a section.
midori: OK, looks like we can move on to the agenda items ...
midori: ... one of which is indeed on documentation progress.
midori: First, though, a 2-min review of the StX meeting ...
jrichter: (oh man, the editorial group is totally gonna get it again...)
midori: did the PIs give you orders?
Harold: pies, tar and eathers ready
Harold: feathers
jclark: two of us are missing
jrichter: So, the review then.
MelissaH: Hi all, sorry I am late
Alex_MGI: You missed the best parts.
midori: Anyway, I'm just skimming my meeting notes, and it looks as though we're going to touch on one thing later today anyway, namely displays relevant in an is_a complete world.
csmith: Okay, I'm back, too. had to take an urgent phone call.. Hi everyone.
midori: Another point has to do with versioning, both for the whole GO file and for individual terms. I vote we call it 'noted and logged', and come back to it in a future (maybe not too distant future) chat.
midori: Then there are 3 things from the OBO-Edit demo:
jrichter: Midori: What was the group consensus on that meeting note on versioning?
midori: "John to visit GO Eds to work out how to implement this stuff in OBO-Edit"
jrichter: I remember arguing strenuously against it, because I think it will be a useless pain in the butt that will give us a false sense of security, but I don't remember the final word.
midori: on closer inspection, I don't have a very strong conclusion,
midori: ... but it looks like something about 'release notes' for the monthly snapshots got the nod, and the rest got tabled
karen: I remember some discussion that people would find it useful to know when an individual term had last been added/updated...
midori: (tho Barry still wants per-term versioning, and is convinced we need it)
midori: back to demo items:
midori: 1. John to look into webinar hosting company
midori: can't say much about that now! next!
karen: and that there was some agreement that the monthly release was sufficient for "versioning" the whole file
karen: what is "pre-term versioning"?
midori: (Karen - it's a typo for 'per-term versioning'; sorry 'bout dat!)
Harold: Is it difficult to add a date stamp to each stanza?
jrichter: My argument is: We HAVE per-term versioning. It's implicit in CVS. If we want to do something, let's write a tool that can extract the info from CVS.
gwg agrees with John-boy
midori: 2. wg to decide on timeline/frequency for official releases
midori: let's come back to that one if there's time. I'd rather get a user guide progress check
midori: 3. script to generate web version of user guide; John talk to Mike about putting it on GO web site
midori: ... segues beautifully into our next topic for today!
midori: How's the user guide coming along?
jrichter: Chris has suggested that we amend point 3 to "User's guide and OBO-Edit API documentation"
jrichter: John's user guide progress since last release: none!
jclark: what's the difference?
pankaj: hi everyone
jrichter: Explanation: I only got back to Denver this week, and I've spent the week working on bug fixes and a new feature for detangling the graph.
Harold: It's J-lo!
midori: Greeting to those who have just joined us. We've just started on user guide progress (or lack thereof).
jrichter: I know that I'm supposed to get the go ahead for new feature development from the WG, but in this case I sent out an email and got no replies. I took that to mean that I needed to work it up so people would know what I'm talking about.
midori: What it really meant was that we needed more time to digest your email!
gwg: I assumed we would discuss it today so didn't reply
jrichter: Sweet! We'll discuss it, and we'll have an example to look at in the next version. It's a win-win.
jclark: we need to release before we get new features
karen: Can we get back on track to discuss if there has been any progress on the user guide documentation
Alex_MGI: I confess I haven't yet considered my user guide assignment yet, but will look at my sections in the next week.
jrichter: Anyway, I finished the new feature last night, so I planned to spend today and tomorrow integrating the docs I've gotten from Midori, Harold and Jen, and writing the data adapter stuff.
midori: OK, John hasn't done anything, but I sent him suggestions for my part, and I've seen email from Jen and Harold.
jclark: what's the data adapter stuff?
midori: John, we also need the complete list of assignments.
jrichter: There's a whole section of the documentation on data adapters. I'm going to write that section.
jclark: is it a new feature though?
midori: no
jrichter: No, Jen. It's a documentation section.
jclark: splendid
Harold: Things like how to save to flat-files using the editor, etc.
jrichter: I do not have the documentation assignments at my fingertips. However, I promise to email them out immediately after this chat.
midori: John - excellent
Alex_MGI: I'm assigned the review of the data adaptors section, so it's good I waited.
MelissaH: that will light a few fires, I think.
Harold: Yes, there's sections I need to review ; started before stcrx, but didn't pick it up again
karen: I'm not yet assigned a section, so I will have to wait for John's email to find an as yet unclaimed one
gwg: moi aussi
jrichter: Karen: I think everything was claimed. You may be off the hook.
midori: harold/alex: there's a nice set of step-by-step instructions for the old-flat-file adapter in SF 1472521 (tho it's not complete)
csmith: I wasn't initially part of the assignments, but I am willing to do some review as well. Having the documentation will be really helpful to me as I am not generally part of the GO group discussions.
jclark: if we are helping to write sections does it matter if screen shots are from different platforms?
Alex_MGI: I will look at the SF item - thanks.
jrichter: Jen - no. In fact, I intentionally do screen shots on different/weird platforms, so that everyone feels included.
midori: Cindy - maybe you could give the whole thing a read-through to ensure that it makes some sense to someone who hasn't been knee-deep in it for a long time!
csmith: midori/John- that makes sense to me.
gwg: I would be happy to do the same thing, as I managed to turn up too late to the chat about assigning documentation sections to claim one...
midori: thanks!
jrichter: A tip for small documentation changes:
jrichter: The documentation is now in CVS, in the form of HTML files.
Suparna: I could volunteer to read through as well, if you need another...
jrichter: It's simple enough to edit and commit little changes that way, if you want.
midori: John - can you give us the URL/location?
jrichter: It's in the sourceforge CVS. Go to sourceforge.net/projects/geneontology and click the "CVS" link for connection info.
midori: ta
jrichter: The part of the repository you want is go-dev/java/oboedit/docs
midori: OK, Jane's back, and we have some idea how things stand with the user guide, so let's move on ...
midori: Top priorities are still finishing the user guide and fixing bugs so we can get a release out.
jrichter: Yes.
karen: One more thing on the user guide... Do we have a time frame for completing it?
jrichter: No, but that's a really good idea.
j-lo: before we move on, can we clarify who's doing which sections again?
jrichter: Let's say in two weeks, or I'm fired.
jclark: aw..
jrichter: J-Lo - I need to hunt up an IRC transcript to figure that out.
jrichter: Jen - I'm not kidding. It's the only way to motivate me.
jrichter: I hate working on the damned thing.
jclark: noted
midori: A transcript went out to the wg mailing list, but if you've lost it, I'll re-send it off-list.
jclark: If we all adapt bits of the old user guide and send them then that should help
jrichter: I don't know if it will. Almost everything works differently than it used to.
jrichter: Anyway, we'll be done by the first Thursday in May.
midori: Priorities reaffirmed, and on record, there is a feature proposal to discuss.
jrichter: Put it in the newsletter.
jrichter: Is that my feature proposal?
midori: yup
jrichter: Nice. Let me do a brief bit of background.
jrichter: When you run the OBO-Edit reasoner, it figures out every single implied link in the ontology. So when the reasoner's done, it's figured out a link between every single term in the ontology and one of the roots (along with thousands of other implications).
jrichter: You obviously don't want to see all of those, so a filter is applied in the background that hides all of the trivially true links.
jrichter: When you create a user-specified filter (like "show me all links that have type "part-of") you are normally filtering a version of the ontology that has all those trivial links already removed.
jrichter: This means that if you try to see all the part-of links, you'll end up with a graph that is cut up into big chunks, because there's no pure part-of path to most terms.
jrichter: Any questions so far?
jclark: no
midori: nope, so far so good
jrichter: Cool.
jrichter: I propose we add a feature where your user-defined filter is applied BEFORE the trivial link trimming happens.
j-lo raises her hand
jclark: just for relationship filters?
jrichter: Either.
jrichter: But realize, there's a number of ways to build the interface. Let me tell you about the one I've mocked up first.
jrichter: Jane?
j-lo: does this require the reasoner to be turned on the whole time?
jrichter: This kind of filtering does.
j-lo: okay
jrichter: If you do the filtering in this new way, your "show only part_of links" filter will now show the complete logical part_of tree, with no disconnections.
jclark: funky
jrichter: (We also run the trivial link trimmer at the last step, so that you aren't swamped by worthless links)
MelissaH: What about ontologies that don't have complete is_a links(yet/or ever)?
jrichter: It depends on what your filter is.
jrichter: If you do a "show only is_a links" filter, the terms that aren't is_a complete will be orphaned.
MelissaH: Can we add a similar reasoner filter to add them back so there are no orphans?
jrichter: You can properly link them into the ontology so there are no orphans...
jrichter: But if your filter means "show me all the is_a assignments in this graph", you want those terms to be orphaned.
MelissaH: ok, this might need more discussion off of IRC...
midori: It's a means of identifying incomplete is_a paths, no?
midori: (but we should move on)
MelissaH: If they are orphaned, wouldn't you not see them?
jrichter: That's one thing it does, but more importantly, it allows you to "detangle" the graph by showing you only one relationship type at a time.
jrichter: Like the new detangled AmiGO interface Chris showed in St. Croix.
jrichter: Melissa - Yeah, but you could turn off the filter and see them again.
MelissaH: Seems like it would be terrific to actually see where the links were missing as opposed to looking at the difference.
jrichter: I think Melissa wants a means to see where is_a orphans are. That's a great idea (maybe as a plugin or search criterion), but it's not the focus of this feature.
MelissaH: ok
midori: OK, put it on our list of things ...
jclark: to do that you can do a filter to highlight the terms that are is_a orphas with their names in black
karen: What is the focus of THIS feature?
jclark: so you can see just one relationship type right through the whole graph
jrichter: Right.
jrichter: There is a prototype of this feature in the next beta. Have a look at it there.
jrichter: It's kinda slow, but it does the job.
jclark: like us
jrichter:
karen: the prototype is in b17? or the next one to be released?
jrichter: b18, available Monday.
midori: OK, is there more background?
jrichter: No, that's it.
Alex_MGI: Okay, but let's not stray from the no new features before the 1.0 release.
karen: I completely agree
midori: Alex - I second that!
Alex_MGI: (Sorry to be a jerk!0
Alex_MGI: )
MelissaH: Can we bring back the select everywhere option? Its not really new...
jclark: what's that?
midori: But as long as we remember that, we can talk about the features we'll add once the release is out.
jrichter: Melissa wants the option for a different behavior when a search result is selected.
MelissaH: Right now when you hit select terms, it only selects the first place the term occurs.
MelissaH: It used to select it everywhere.
karen: I miss that it doesn't select/highlight all locations too
jrichter: Do I add it now, or wait?
MelissaH: Beg, plead, now please.
jclark: it wont be long 'til the user guide is done
jrichter: (Note: It's easy to do, probably about 2 hours of work at most)
jane: sorry, I got disconnected - will this work for non-link filters?
midori: I want it too, so it seems like a feature to add (back) immediately after the 1st release.
MelissaH: Does anyone else besides Karen and Midori and myself want this feature back?
jane: i.e. term filters
jrichter: Jane - Yup, although it's hard to see why you'd want to, except maybe for slims.
Suparna: me too
jane: yep - for slims
gwg would like it back too
jrichter: A point about why this feature was removed: It can be really, REALLY slow.
tberardi: If you're gathering votes, I'd like it back too.
jane: sorry - what feature?
MelissaH: Not as slow as my editing without it.
midori: having a selection highlighted everywhere, rather than just once
karen: So how 'bout making it optional, but at least available, it really slows me down to have to manually find and expand the section I'm actually interested
Alex_MGI: Make it an optional feature -- default is off.
jrichter: Okay: I suggest that we break the no new features rule this once and add this in. It seems like everyone needs it now.
Harold: Yes, it should be switchable on/off
jrichter: (Realize that you can always select any given path by selecting it and right-clicking it in the DAG Viewer)
karen: NO, we do not break the no new features rule. As much as I want this, I want to get a release out first.
pankaj: john, when we get the search results for a given term, we do not get the column with the ontology aspect (M/F/C), i think user needs to find it at that level which term he/she in interested to select.
tberardi: It's not really a new feature, right? It's more like a Lazarus feature.
MelissaH: But the DAGviewer doesn't expand fully anymore either.
Harold: I agree with Karen; we should concentrate on getting the release out first
karen: with respect to what is currently there, it is a new feature, which will require more testing to make sure it hasn't introduced new bugs. I still vote to put it first on the list of stuff for the next release
midori also votes against breaking the rule
jclark: me too
Suparna: no problem here
Suparna: release first
jrichter: Karen - There is an argument to be made for making sure the official release has all the essential features.
MelissaH: ok, certainly don't want more bugs.
jrichter: Let's put it to a vote.
jrichter: All in favor of an immediate change, say yeah.
MelissaH: yeah.
karen: no
jrichter: (And all those not in favor, say nay)
Harold: no
Alex_MGI: no
pankaj: yeah
jclark: no
jane: nay
Suparna: nay
tberardi: nay
csmith: no
midori: negative
jrichter: Nays win. We'll do it in two weeks.
MelissaH: ok, no problem.
jrichter: 5 mins left. Any other items?
midori: Yay, result! 'Optional select everywhere' is top of the list of new features to be added after the release. (Much as we're going to love it, it's not essential.)
jane: what about the new filter thing?
jane: is there a mock-up did you say John?
jrichter: There's a working protoype in the next beta release, BUT the button will be removed for the official release.
midori: John, you had some interface options at the end of the email. Did you want any comments on them?
jrichter: Thus, no new (maybe buggy) features.
jrichter: I went with the very simplest choice for the prototype - a single button under the term editor panel.
jrichter: I think it's the least confusing way to start.
jane: okay. When's the next release?
jclark: it's all in the transcript
midori: OK. Which option was that (got the numbers in my head ...)?
jrichter: I think 4?
midori: OK. I liked 4.
jrichter: Midori, will you take care of sending out the transcript and removing references to *****?
midori: yup.
jrichter: Okay! Action items:
Alex_MGI: Maybe we should select a non-John ombudsman to keep on top of the documentation situation and assignments? And someone else to keep track of bugs in the current beta versions?
jane: good idea
midori: Once John sends out the doc assignments, I can keep track of progress.
Alex_MGI: Just so we can really get this thing "out the door."
jrichter: I like the first idea. But the second thing is handled by sourceforge bug tracking, right?
midori: yes
jrichter: Hey!
jrichter: Let's create a sourceforge tracker for the doc assignments!
MelissaH: And there is light.
jrichter: I'll send out an email saying who's in charge of what piece of documentation...
jclark: one more question: Is there progress on the new paid for version of irc and vnc and whotnot
jrichter: that person adds their section to the new tracker, and we'll tick things off as they're done.
jrichter: Jen - nope. I consider that a back-burner priority right now.
jclark: we could use the web tracker
jclark: cool
jrichter: I'll send out info about the new tracker in the assignments email.
jane: so...action items?
jrichter: Yes-
jrichter: 1) Send out documentation assignments email
jrichter: 2) Create new tracker for docs
tberardi: Sorry, got to go to another meeting.
Suparna: me too...bye everyone...
jrichter: 3) Note that "select-everywhere" should be added as soon as an official release happens
jrichter: 4) Test and comment on new reasoner-related filtering feature
jrichter: done
jrichter: Did I miss anything?
jane: no - think that's it
karen: two week deadline to get docs finished
MelissaH: nope,thats enough.
jrichter: 5) Fire John if docs aren't done by first Thursday in May
jclark: or just delete the empty sections
jrichter: :0
jrichter: Bye all.
Alex_MGI: and their matching program modules.
jclark: bye
midori: that was a joke, right?
jclark: yes of course
Harold: we never joke at mgi!
jclark: no indeed. Nor here