AmiGO 2 Manual: JSON

From GO Wiki
Revision as of 18:16, 5 November 2014 by Sjcarbon (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Warning: These are proposals that may still acquire changes. Please check back regularly or "watch" this page.

Topology and Transitivity Graphs

The most recent documentation on general graph handling (rather than the special format for visualizations--see below) can be found here: https://github.com/kltm/bbop-js/wiki/Graph .

Node Description Format

This format describes the graphic quality of nodes in a graph. It is actually a simple JSON description of nodes in the graph. While the user cannot specify what nodes appear in the graph beyond the ones used to seed it, they may completely specify the contents of those nodes (e.g. add additional annotation, change the names, or alter coloration).

So far, the following keys are recognized:

  • "title": The title of the node (must be unique).
  • "body": The text appearing under the title.
  • "fill": The color of the node.
  • "font": The color of the font.
  • "border": The border color around the text of the node.

Currently, while the body tag should be able to take simple psuedo-HTML as GraphViz does, the HTML support in GraphViz is fiddly (e.g. spaces *do count* and some tags don't work in certain combinations)--it takes a little experimentation.

Example

{"GO:0002244":{"title": "foo",
               "body":  "bar",
               "fill":  "#ccccff",
               "font":  "#0000ff",
               "border":"red"},
"GO:0005575":{"title":"alone",
              "body":""},
"GO:0033060":{}}

Standard Envelope

For many services producing JSON in AmiGO 2 (not including direct GOlr/Solr queries, which is a fairly common use case), the results are delivered in an easily parsable envelope to make it clear if the query went correctly. This is a different use case compared to GOlr returns (which have their own protocol) and graphs (which are usually embedded in another protocol or format anyways).

Example (degenerate)

The minimally correct parsable output for something returning in this format would look like:

{
 "type":"",
 "errors":[],
 "warnings":[],
 "info":[],
 "arguments":{},
 "results":{}
}