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