Have a generic configurable "display known JSON blob as list/table" engine

[kltm]

This would be similar to--and hopefully a replacement for--pages like this:

http://amigo2.berkeleybop.org/cgi-bin/amigo2/xrefs

The Xrefs page takes a JSON blob (incidentally produced by AmiGO at install time) and displays it as a list. The idea would be to have a configuration variable that could generally take a list of JSON blob locations and produce nice pages for them in a section of their own. The driver here is to also have a replacement for:

http://www.geneontology.org/GO.annotation_qc.shtml

as well as maintain the Xrefs page.

[kltm]

Would be useful to take over references.cgi as well, see geneontology/go-site#10.

[cmungall]

So the options are

0. Native github rendering
1. AmiGO
2. Some kind of embeddable widget (which could of course be reused in amigo)
3. GitHub pages/Jekyll/Liquid
4. Readthedocs

RTD may seem an odd choice but I think it could work well for some kinds of metadata. Not having to worry about style is a big advantage IMO.

The choices may not be mutually exclusive; e.g. a widget could be deployed in amigo or gh pages. But I think we want to avoid overcomplicating.

In general 3 and 4 have the advantage of easier interleaving of explanatory text, having non-developers edit and release immediately.

1 and 2 has the advantage of showing the metadata in the context of the data it is used to describe. E.g.

• For any goref, show amigo annotation widget
• For any gorule, show annotations that may have violated it
• For any evidence code, show annotations for that type
• For any relation, show annotations with extensions that use it, or ontology relationships
• For any prefix, show annotations that reference (subject, object, evidence, provenance) entities with that prefix
• For any user or group, show classic annotations, noctua annotations, GO terms with provenance to them

(I think we have tickets for some of these already)

Should be easy to deliver all of these from the biolink api (except perhaps rules, we have to think about how that interacts, perhaps results could be loaded into rdf store, in which case it's a simple sparql query)

[kltm]

I think there are more options there. While I had some independent code floating around for this purpose at one point, I'm a little less enthused about actually following through with it now as a separate system.
My druthers is to have something that is tied very stylistically and contextually to its environment; something floating around between 1 and/or 3, and definitely taking in metadata separately for the render.
I'm not sure about the biolink api here--I think we might have different use cases in mind.