Trivial Graph Format (TGF) is a simple text-based file format for describing graphs - wikipedia 
It consists of a list of node definitions, which map node IDs to labels, followed by a list of edges, which specify node pairs and an optional edge label. Node IDs can be arbitrary identifiers, whereas labels for both nodes and edges are plain strings.
Note: For an early discussion of these ideas see the - github issue
The graph may be interpreted as a directed or undirected graph. For directed graphs, to specify the concept of bi-directionality in an edge, one may either specify two edges (forward and back) or differentiate the edge by means of a label.
# Example A simple graph with 2 nodes and 1 edge might look like this:
1 First node 2 Second node # 1 2 Edge between the two
The # sign marks the end of the node list and the start of the edge list.
# Tradeoffs This approach comes with trade-offs:
**Pros**: * Human readable and writable * Easily converted to other representations and exported as CSV, graphml, TGF, etc. for offline analysis or for use in other tools, including JavaScript visualization libraries.
**Cons:** * Doesn't easily capture more complex k-partite networks containing multiple types of vertices, and so doesn't handle @coevolving's OPM use case; more formally, such networks are multipartite edge-labeled multigraphs and are the most complex that a wiki would need to support unless someone can make a case for hypergraphs. TGF does support edge labels, and so can handle multi-dimensional graphs, but I'm not aware of a way to support vertex types. * Doesn't capture vertex or edge properties other than a label. The TGF representation above omits the url's embedded in the SVG vertices for the moment...I'll return to that below.
These are serious drawbacks: Many types of systems are intuitively represented as a multidimensional network with different types of vertices and edges in the same diagram. Even for a unipartite directed graph, vertex and edge properties can be useful. TGF wasn't intended to be a universal graph format, however...hence "trivial".
I took the time to illustrate what a TGF representation looks like not to espouse it or yEd, but to show that the appeal of TGF is its simplicity. Leaving off any XML or JSON syntax and presentation allows for relatively easy human reading and writing while maintaining just enough structure to make programmatic parsing easy.
# See also
Here we look in more detail at how graphs in wiki can be specified. We look to define a markup, or domain specific language for authors wishing to create maps or network graphs.