Home

Home

Graphs are an expressive and intuitive data structure. GraphJSON documents are a standardized way to represent graph information, while keeping intact the expressiveness and elegance of the underlying data. The GraphJSON project is heavily influenced by GeoJSON.

GraphJSON is a standard format and can be used to describe structural and stylistic features of graphs, regardless of the data domain or content. The end goal is proliferation of meaningful graph representations through visualizations and analytics by greatly increasing the interchange of graph data and the prototyping of graph representation.

Overview

• 1. Home

  • 1.1. Definitions
  • 1.2. High Level
  • 1.3. Usage
  • 1.4. Contributing

• 2. GraphJSON

  • 2.1. nodes
    • 2.1.1. id
    • 2.1.2. properties
    • 2.1.3. labels
    • 2.1.4. caption
    • 2.1.5. nodeMeta
  • 2.2. edges
    • source/target
    • type
    • properties
    • caption
    • edgeMeta
  • 2.3. meta

Definitions

JavaScript Object Notation (JSON), and the terms object, name, value, array, and number, are defined in IETF RTC 4627, at http://www.ietf.org/rfc/rfc4627.txt.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119, at http://www.ietf.org/rfc/rfc2119.txt.

High Level

GraphJSON refers to a well formatted JSON object. Naked GraphJSON will contain the bare minimum that it takes to construct a graph - the two top level keys: nodes and edges and no associated style information. When an API or data service provides Naked Graph JSON any styles associated by the Graph are taken into account by the Applications defaults. However, when it comes to conveying important information through graph visualization, style is incredibly important. Additionally, since the graph visualizations are as generic and expressive as Geographic Maps, there needs to be a well defined framework for articulating important information related to how Graph data should be consumed for visualization.

Complete GraphJSON will also contain a top level meta key that will implement graph styles, including layout, sizing, color, and other descriptive and style features.

In summary:

A well formatted Naked GraphJSON object must include the following top level keys:

• nodes - nodes object documentation
• edges - edges object documentation

Complete GraphJSON will also include:

• meta - meta object documentation

Usage

GraphJSON objects can be used in a wide variety of situations. Prototyping and designing small graphs for documentations, as an interchange format from a graph database like [Neo4j], [Titan], [Orient DB], for use in a Network analysis package like [Networkx], to be rendered in a visualization application like [Gephi], or even as documents within a document store. Additionally, libraries are in the works to easily convert CSV, XML, or even traditional network files (like UCINET or Pajek) into GraphJSON files.

Contributing

The GraphJSON contributors and graph community wholeheartedly invite you to weigh in on how the specifications can be made better. Additionally, if you'd rather work on living breathing GraphJSON based applications, check out the following:

• GraphJSON.io

Thoughts

While nodes are sometimes referred to as "vertices", edges inherit even more of a naming controversy and can be referred to as "links", "lines", or "relationships". We've chosen nodes and edges because they are a humane way to refer to the underlying data model, while remaining non-generic and unique to the graph world. Feedback is welcome.