-
Notifications
You must be signed in to change notification settings - Fork 4
Graph
This is an overview of the graph JSON structure used in BBOP, as well as some incidental discussion of the internals. See the topology graph and transitivity graph pages for the discussion of specific instances of graph that appear in GOlr.
By convention, these types of graph blobs in GOlr end in “_graph_json”.
While the API is fairly abstract, there is a standard JSON object to use during construction, and can be considered the common currency at this point.
In this model–and we’re going to be talking about the JSON model for construction and storage here on out, not the underlying model which is rather more complex)– a graph is a list of nodes and edges. A trivial degenerate graph would be:
{
"nodes": [],
"edges": []
}
Graphs may also have an arbitrary meta property passed along for user and sub-class purposes. (TODO: is this actually true?)
The minimum information needed to define a node is an id property. All IDs must (naturally) be unique; nodes with the same id will clobber each other internally.
Another common property of a node is its label, or identifying readable string. This is the property lbl. This is an optional property.
Nodes may also have an arbitrary meta property passed along for user and sub-class purposes.
A graph with a single simple node could be:
{
"nodes": [
{
"lbl": "single-organism metabolic process",
"id": "GO:0044710"
}
],
"edges": []
}
The minimum information needed to define an edge are the subject/source and object/target properties, defined as sub and obj respectively. Internally, there is also a default predicate/relation property, which must be defined–if you do not define one yourself explicitly, you will be automatically be given the APIs default one (which can be set).
Internally, edges are mostly “anonymous”, being defined my the sum of the sub, obj, and pred properties. If two edges share the same combination they will clobber.
Edges may also have an arbitrary meta property passed along for user and sub-class purposes.
{
"nodes": [
{
"id": "GO:0043474",
"lbl": "pigment metabolic process involved in pigmentation"
},
{
"id": "GO:0043475",
"lbl": "pigment metabolic process involved in pigment accumulation"
}
],
"edges": [
{
"sub": "GO:0043475",
"obj": "GO:0043474",
"pred": "is_a"
}
]
}
Given the above, let’s look at GO:0043474. The JSON that would fully define all aspects of the graph would be:
{
"nodes": [
{
"lbl": "single-organism metabolic process",
"id": "GO:0044710"
},
{
"lbl": "pigment metabolic process",
"id": "GO:0042440"
},
{
"lbl": "single-organism process",
"id": "GO:0044699"
},
{
"lbl": "pigment metabolic process involved in pigmentation",
"id": "GO:0043474"
},
{
"lbl": "pigmentation",
"id": "GO:0043473"
},
{
"lbl": "metabolic process",
"id": "GO:0008152"
},
{
"lbl": "biological_process",
"id": "GO:0008150"
}
],
"edges": [
{
"pred": "is_a",
"obj": "GO:0044699",
"sub": "GO:0043473"
},
{
"pred": "is_a",
"obj": "GO:0044699",
"sub": "GO:0044710"
},
{
"pred": "part_of",
"obj": "GO:0043473",
"sub": "GO:0043474"
},
{
"pred": "is_a",
"obj": "GO:0044710",
"sub": "GO:0042440"
},
{
"pred": "is_a",
"obj": "GO:0042440",
"sub": "GO:0043474"
},
{
"pred": "is_a",
"obj": "GO:0008152",
"sub": "GO:0044710"
},
{
"pred": "is_a",
"obj": "GO:0008150",
"sub": "GO:0008152"
},
{
"pred": "is_a",
"obj": "GO:0008150",
"sub": "GO:0044699"
}
]
}