Synonyms and alternate IDs as legitimate input

[kltm]

From http://jira.geneontology.org/browse/GO-374

---

I open the Visualization form:
http://amigo.geneontology.org/amigo/visualize

I put the GO term "GO:0001589" into the search field, nothing else.

I click "visualize".

Then the error appears.

The URL that finally produced the error was:
http://amigo.geneontology.org/visualize?format=png&term_data=GO%3A0001589&term_data_type=string&mode=amigo&inline=false

---

This would require either a multipass resolution mechanism, or (preferably) a generalized personality hinted method of recovering a document (or documents) when the ID is definitely known (i.e. not a search) using the manager. Basically a more full-featured version of set_id().

[kltm]

Actually, in this case, the issue is with the perl GOlr client; since it's serial, a two-pass system may be easier to handle than a more complicated manager.

[kltm]

The error message in visualize is rather misleading in this case anyways. Need to make it clearer.

[kltm]

Generalizing this to be not just about visualize (change in title), since you can find this issue cropping up places like the alternate ID field when looking at ontology terms--they link to nothing since there is no term by that ID.

One could deal with this by having a few new fields; we could redefine as the following:

• id: the internal ID that is not generally exposed to users; in most cases it would be the
• annotation_class/canonical_id: the main ID to which people are annotating to, etc. (check with @cmungall)
• alternate_id/synonyms: other IDs that are used for the item
• annotation_class_union: an internal-only searchable field (union of the above) that would be used as the main resolution field; would only work if guaranteed to be disjoint
• similar might be applicable to annotation docs, etc., but probably not as important
  This is rather more than what we have, but it would allow for an internally clean and externally transparent solution to this irritation.

Fixing would involve monkeying with the loader, so pushing to 2.3 for now.

[cmungall]

I'm not totally sure #476 should have been merged in here, I don't fully understand this ticket but I may be different from #476?

[kltm]

Whoops, undone. I think I might have had another ticket in mind, but I forget now...

[kltm]

Noting some concern about this from @suzialeksander