Add autocomplete (or clone from same model) for PMIDs

[krchristie]

It would be a real time saver if there was a better way to enter the PMID.

It would be really cool if

• the autocomplete could work on PMIDs already used in the same model
• OR if there was a way to clone existing PMIDs. For those who use multiple PMIDs in the same model

It would probably also help if you could enter some identifying info associated with the PMID, e.g. First author & year, but really whatever is useful to the curator, so that it could be easily selected from the clone list. This extra info for each PMID wouldn't, and shouldn't, make it into the final annotation.

[kltm]

So this would be a method for autocompleting/copying PMIDs independent of the evidence (functionality in the current clone)?

[krchristie]

When I'm putting in a new evidence line, I either have to remember to copy the PMID before I open the editing window (which I haven't remembered to do, or have thought it was more important to have the ID I need in the with field in my copy/paste buffer), or I have to manually enter it.

[kltm]

Hm. I thought there was another PMID autocomplete ticket somewhere, but I have been unable to find it.

Related issue to #308 and geneontology/amigo#397; we need the ability to have the PMIDs available as something besides psuedo-docs in AmiGO, or to pick an external API to use.

[cmungall]

How about this:

The noctua client maintains an in-memory list of publication objects, i.e. a mapping from PMIDs to objects. Any time a new PMID is entered into a model, it does a lookup using eutils (possibly using same js wrapping as in amigo - one of these? https://www.npmjs.com/browse/keyword/pubmed) and caches this in memory.

It can then use this info when rendering, or for doing a server-free autocomplete.

This should gracefully degrade if external service unavailable. E.g. as current behavior, but still allow autocomplete by ID only.

Perhaps we can also make use of model-level annotations here. Frequently there will be a 1:1 mapping between model and paper. The curator can enter this at the start. This would then be the default, minimizing redundant select actions from the curator. Of course, this needs to be nonobstructive when >1 paper is used for a model.

It would also be nice to search for anything in pubmed but that should be a separate ticket.

[kltm]

We do indeed have a ticket floating around somewhere about model-level annotations being used to hint the interface--it would be nice to link back to that when I find it.

The issue with a pure in-memory model is the general statelessness of the clients--when they pass control, anything not encoded in the model would be lost. I think we might be better off squirreling it away in the extended evidence model and just doing the scan with that (as injected top results if available) and external service otherwise.

[kltm]

That said, some frameworks do allow for better built-in persistence across reloads; although I am not a fan of some of these as it makes control a bit harder, that would offer a way forward.
I do believe that thinking about the problem in a way that makes client status equal will generally improve the support and the annotation experience.

[krchristie]

Chris's suggestion to have some sort of interface to enter the info for the references used for the model might work really well. A long time ago, OBO-Edit (or perhaps its predecessor GO-Edit) had the ability to enter in info for commonly used references so that you could select references for definition dbxrefs from a list that included the human readable info like the first author & year, instead of just the PMID, and it was super helpful when working on a project where you created lots of terms in a specific area of biology using a set of references common to all of the terms.

For this use, I was really just asking for the model to be aware of references currently used so that when I am entering the reference, I don't have to keep entering the PMID every time. While I tend to generate 1 model per 1 paper, I do sometimes pull in info from a second paper, and others use multiple papers in a model routinely, so I think this would have to allow entry of info for multiple papers to be generally useful.

[krchristie]

Having a lookup for PMIDs would also be really great. Protein2GO has that feature, and it is really nice to get the immediate feedback that you've entered the correct PMID when the lookup displays the citation for the PMID you've just entered. This would definitely be a really great feature, though separable from the request to have the model be aware of references already being used within the model.

[vanaukenk]

Improved PMID entering and field value reuse has been implemented in the Noctua form-like interfaces.