Phenote cgi wish list
The following functionalities should be integrated into the new phenote cgi:
1. Term info panel (which displays info on the paper object, allele, ontology term etc.)
2. Annotation editor (with multiple tabs)
3. Annotation table
4. Retrieve function
no OR use filter for AND all retrieves are append retrieves. new annotations always blue. each retrieve a different color (alternate with 2 colors like green and yellow) with a retrieve number if a retrieve would get something that is already there, don't get it, but append a retrieve number and change the color to a 4th color (purple) sorting of retrieves in filtering. no read-only annotations, can always open another browser.
4.1. Clear function to start over with a clean slate. (file new)
5. List fields with the option to delete invidual terms with a 'del' radio button
If the sample I sent out is not this, let me know, otherwise it'll be just that (see below about obsolete fields issue) JF: Let's stick to one you used for the online allele submission form. Input box with auto suggest, forced values only, no toggle, del button, no add button.
RK: talks to Sanger - try to get a weekly dump of wbgenes with obsoletes.
6. Edit radio button feature that provides you w/ a pop-box to insert or edit large amounts of text
Why a radio button instead of a normal button (or link). We can do a popup window like phenote does, but would an input field (line) that on focus (when it gets clicked or tabbed into) switches to a large expandable textarea (like the curator_first_pass fields) work just as well ? For allele phenotype only have some fields that toggle between input fields and textareas on focus. (no buttons)
7. Spell checker (Google has come out with a fancy spell check code that checks for both spelling error and context)
8. Autopopulating a field based on the contents of the another field. (eg: autopopulate gene name field based on allele object field).
How would you want this to work ? Switching one field toggles another field that is read-only, or can you edit the second field, but if you switch the first field it re-switches what you manually changed in the second field ? read-only, maybe some fields have a ``fix wrong autopopulate field that overrides the read-only.
9. Ability to configure/customize the panels according to preference
Yes, but it'd help if we were clear on what panels, and how you'd like them to be customizable. Default config, 3 frames in single window, always have only one window. possibly also have 3 frames in a row config.
10. Ability to customize the column arrangement in the annotation table
In this case resize, reorder, and sort by columns.
11. Incorporate Simple Filter and filter based on the individual field
I've forgotten what we decided on how filtering would work, I remember talking about a lot of different methods. Simple filter works on all fields, not just current field ? Individual field filtering just displays characters with literal matches on that field ? Simple filter -> text match on any field Field filter -> text match on specific field (includes query filter) or filtering by | e.g. dpy|egl 3 sets of filters, each with field drop-down, text, and partial/exact radio button
12. After hitting commit, it gives you a summary of the following counts: Total number of alleles/rearrangements/transgenes per paper. Total # of phenotypes/ paper. Total number of object-phenotype connections
Is this for allele-phenotype phenote only ? Yes. pop-up results. characters can only have one paper. phenotypes can only have one value (not list) foreach paper : count of unique alleles, count of unique rearrangements, count of unique transgenes. count of unique object name-phenotype connections, meaning characters (rows) because all characters must have object name and phenotype. total count of unique object name-phenotype connections, meaning characters (rows) total count of unique object names that have NBP (even if there's an append retrieve, everything from annotation table)
13. A system integrated for requesting new terms
A link to email the .obo maintainers ? No. Stuff goes into postgres. Other CGIs from other curators can see that, and do stuff, that also affects phenote postgres tables. (allele-phenotype)
14. Retain existing pipelines to Mary Ann's, Wen Chen's and Gary's cgi
This is just from the postgres tables like 13
15. Auto update date for GO form (must be editable esp. if it's a minor edit)
Date and Curator from login are auto assigned to new characters or duplicate characters. Queried stuff keeps DB curator and date.
16. When actively curating two or more genes it would be nice if a retrieve query did not erase the previous annotations from the annotation table. Maybe the results of the new query could be displayed in a separate window? if there is a fear of deleting or changing something by mistake.
See 4. (retrieve)
17. Curator login
How would this work ? Fill in the curator-drop with that curator by default, but when querying values use the postgres curator for that character and still allow that character's curator to be replaced (but not doing that automatically) on query use DB curator. on duplicate use login curator. on new character assign login curator. if querying characters without curators, leave them blank. allow field to be editable.
18. Mandatory Constraints on certain fields... dependent on the configuration
19. Incorporating results of Textpresso searches into cgi form.
To unify the GO curation process, would it be possible to have a module or panel where the weekly Textpresso search results are deposited and could be curated just as they are now from the ccc_curation cgi? Perhaps also include an option to see the sentences in a PDF.
20. tab files.
Save tab file with headers, import from headers ; if names of headers have changed, then this breaks.
Questions : 1. Obsolete .obo terms / .obo fields should be forced to be in the .obo. Currently .obo fields's values have to be in the .obo, which is good because you can't enter invalid values, but it's bad when obsolete terms are not tracked because invalid values can't be queried. Do we want to properly track obsolete values and have restricted ontology, or do we want a free field with autocomplete that stills allow non-.obo terms in there (and potentially lets wrong data in the database) ? see #5 above