You should end up with a box that says "35 terms found" and a button to search with these 35.Īnother scenario is where the user enters IDs one at a time, e.g.īoth text annotation (for terms or genes) and autocomplete based list building are equally useful for GO Text annotation can be seen as a special case of resolution. TE) and many places where we want to include the bulk query part. There are many cases where we might want to plug in the resolution part (e.g. Really resolution and bulk query are separate concerns. There is no way for the user to see which subset of entered IDs resolve. Perhaps a more fruitful long term approach would be grebe with the ability to enter lists? Breaking resolution into a separate step But I think the experience will be alienating for a user here. It's great that this is driven by the schema metadata. If we are serious about this functionality we should be sure we have similar behavior for term enrichment (the gene use case can be seen as a degenerate case of TE)
Guaranteed that all kinds of mad IDs will be entered. there are checkboxes for bioentity label and bioentity name, but none for the ID. Hooking up to the SG annotator would be awesome here. Entering in GO term labels is fun, but again most people don't know the strings by memory, and getting the required list may be a challenge for some. Arriving at a list of GO IDs is obviously a challenge for many users, be awesome when this is hooked up, e.g. It appears to use the closure (which is actually what most users want, even if they don't have the language to express it) "GO class (direct) (annotation_class)" is pretty opaque. It's not completely clear what box to click on the right. This is v useful when you have a set of GO IDs. Some comments on current status of bulk search (not sure if this is redundant with some of the extensive info above). If it sounds right, I'll add another issue for basic bulk search, and let this be the second step. It would also mean that the perl bits could be ignored for a while longer (possibly allowing us to stall long enough to get rid of them completely). If this makes sense, I think this might be a way to go for now: we'd get some parts running immediately, and could grow it out into other needed functionality (at the cost of single steps). with these term ids, give me all annotations with this evidence) but you can image either extending this or feeding it into itself (we'd need kick in to get things like TE results links to work) so there somebody could take multiple steps through the different document types, filtering and joining with the next one. One thing would be lost in an interface like this, at least in the beginning, would be filtering on the second step (e.g. these results will include buttons or links (a la current live search pages) that have options like: download, get direct annotations for these IDs, get all annotations for these IDs. clicking search will produce the results (maybe just a preview, 100?). #DOWNLOAD FROM AMIGO READER NOT ENABLED DOWNLOAD#
maybe needs a download field selector too?. nice bulk search: live filters, search fields, and bulk input (essentially the current bulk mock-up). Shelving those reasons for the moment though, if one was willing to sacrifice easy kick-ins and the single-step satisfaction of going straight from gp symbols to terms, a possible workable interface would be: Reading this thread though, it seems my final deciding factor for wanting to do it on the server was to make it easier to directly create links and kick-ins for the service, so that these bulk pages could be treated in much the same way that term and gp pages are currently treated. In large or complicated cases, maybe not something that one would want to handle in a single pass from the client (time), and breaking it up (a la the matrix tool) is rather unwieldy in practice. This would require the Solr equivalent of an RDB join, and I think can only practically be done with an initial query to get the "key ids" from one doctype and then using another query to get the wanted data from the target doctype. The other set of issues (this issue) is along the lines of: I want to put in random gps and get annotation data I want to put in terms and get gp (annotation) data. That said, this is not the actual issue open here. This is essentially the way the current bulk interface prototype is heading, and would probably be workable for non-huge numbers by composing large queries (will require some new stuff in the manager, but probably not too bad). 
One set of issues that users are having seem to be along the lines of: I want to put in a bunch of term ids and get a listing of those terms I can work with (link, download, etc.). Well, looking at the issues and requests above again, I think I can explain the rationale better this time around.
0 kommentar(er)
