Concise Descriptions

From WormBaseWiki
Jump to navigationJump to search

Concise Description Curation

Genes with Recent Publications and No Concise Description

The list below contains genes for which a paper has recently been published but for which we do not yet have a concise description. The paper in parentheses after the gene name is the recent paper that prompted adding the gene to the list, but may not be the only relevant publication, so we may need to check other papers for writing a complete description.

If you'd like to work on one of these genes, feel free to check it out on the concise description check-out form and remove it from the list here.

http://tazendra.caltech.edu/~postgres/cgi-bin/concise_description_checkout.cgi

Please also feel free to add genes to the list if you come across them in the context of other curation, but can't write a concise description right away. Someone else may be able to pick up that gene and write the description in the mean time.

  • pix-1 (see WBPaper00038193)
  • git-1 (see WBPaper00038193)
  • sepa-1 (see WBPaper00033110)
  • maco-1 (see WBPaper00038258)
  • tfg-1 (see WBPaper00038310)
  • sec-13 and other sec- secretion pathway genes (see WBPaper00038310)
  • gcy-28 (see WBPaper00038243)
  • pptr-1 (see WBPaper00032946)
  • alr-1 (see WBPaper00038207)
  • crtc-1 (see WBPaper00038172)
  • snf-12 (see WBPaper00038424)
  • lin-54 (see WBPaper00028753)
  • lin-53 (see WBPaper00028573)
  • cnt-2 (see WBPaper00038432)
  • orai-1 (see WBPaper00028994)

Keeping Gene Names Up-to-Date

Concise descriptions typically begin with the name of the gene, either its CGC name, e.g. unc-7, or its sequence name, e.g. Y24F12A.2. Sometimes the CGC name changes, but more frequently, the gene with a sequence name acquires a CGC name due to more intensive study or characterization.

  • To keep the names up-to-date in the concise descriptions, there are two emails to check:
    • Check each email from the webserver@sanger.ac.uk and pay particular attention to the emails with subject heading NAMEDB: CGC added to WBGenennnnnnnn. These are typically the cases where a CGC name is added to a gene that previously was known only by its sequence name. If we've written a concise description for this gene using the sequence name, then I update the description to now use the CGC name using the concise_description_new_cgi.
    • Mary Ann Tuli and Jonathan Hodgkin send an email, on which they cc Cecilia Nakamura and me, confirming all of the updated persons, labs, and gene names as recorded by the CGC. In the body of the email is a list of new gene names and assignments that I also check. Note that there is some redundancy here: any new gene name mentioned in the updates email should also be added to the name server and thus come through as a NAMEDB email. In my experience, though, a little redundancy is not always a bad thing and helps to keep things from falling through the cracks. As above, I make any necessary gene name changes using the concise_description_new_cgi.

Building an Ontology Annotator interface for concise description curation

Please note these points may not be well-organized or complete, as this is just the initial brain-storming phase of this project:

  • Curation starts by querying for a gene, this is an autocomplete dropdown, that is populated from the OBO file for genes.
  • Querying for a gene either brings up data in Postgres or brings up a session populated with gene information, curator name, date, and new pgid (formats can be identical to the GO interface). Do we need anything else to be prepopulated?
  • Text boxes required for: concise description, Evidence, Human Disease Relevance, Database, etc. Each of the specific fields discussed below:
  • Concise description field: This is a free text field. May not be necessary for the text field to be a huge box to begin with, could expand as needed like the variation field in the GO interface.
  • Evidence: We've used several types of evidence, but paper evidence is used most often. An autocomplete dropdown that would allow us to check that the paper we're citing is the correct one would be great. For the other types of evidence, I don't know if any one has been used often enough to merit its own separate entry or if we should just have several additional generic evidence fields to accomodate this info.
  • Other thoughts:It is helpful to see how often the description has been touched, but if the same person updates a description more than once, the timestamps for the individual updates don't show on the current form. Are they in the history files?
  • Structured descriptions tags: Should these be in separate tabs or in the same tab? Only show if there's data already filled in? If a tag doesn't contain any data and a curator wants to add new info, what would be the best way to add or open the new box?

Back to Caltech documentation