5
Graph Markup Language (GraphML)
Ulrik Brandes
University of Konstanz
Markus Eiglsperger
Zuehlke Engineering AG
Juergen Lerner
University of Konstanz
Christian Pich
University of Konstanz
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
5.2 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Header • Topology • Attributes • Nested Graphs • Hypergraphs • Ports
5.3 Extending GraphML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Attributes • Complex Types
5.4 Transforming GraphML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Means • Types • Language Binding
5.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Introduction
Graph drawing tools, like all other tools dealing with relational data, need to store and
exchange graphs and associated data.q Despite several earlier attempts to define a standard,
no agreed-upon format is widely accepted and, indeed, many tools support only a limited
number of custom formats which are typically restricted in their expressibility and specific
to an area of application.
Motivated by the goals of tool interoperability, access to benchmark data sets, and data
exchange over the Web, the Steering Committee of the Graph Drawing Symposium started
a new initiative with an informal workshop held in conjunction with the 8th Symposium
on Graph Drawing (GD 2000) [BMN01]. As a consequence, an informal task group was
formed to propose a modern graph exchange format suitable in particular for data transfer
between graph drawing tools and other applications.
Thanks to its XML syntax, GraphML can be used in combination with other XML based
formats: On the one hand, its own extension mechanism allows to attach <data> labels
with complex content (possibly required to comply with other XML content models) to
GraphML elements, such as Scalable Vector Graphics [W3Ca] describing the appearance
of the nodes and edges in a drawing; on the other hand, GraphML can be integrated into
other applications, e.g. in SOAP messages [W3Cb].
A modern graph exchange format cannot be defined in a monolithic way, since graph
drawing services are used as components in larger systems and Web-based services are
emerging. Graph data may need to be exchanged between such services, or stages of a
service, and between graph drawing services and systems specific to areas of applications.
The typical usage scenarios that we envision for the format are centered around systems
designed for arbitrary applications dealing with graphs and other data associated with
them. Such systems will contain or call graph drawing services that add or modify layout
0-8493-8597-0/01/$0.00+$1.50
c© 2004 by CRC Press, LLC 1

2 CHAPTER 5. GRAPH MARKUP LANGUAGE (GRAPHML)
and graphics information. Moreover, such services may compute only partial information
or intermediate representations, for instance because they instantiate only part of a staged
layout approach such as the topology-shape-metrics or Sugiyama frameworks. We hence
aimed to satisfy the following key goal.
The graph exchange format should be able to represent arbitrary graphs with
arbitrary additional data, including layout and graphics information. The addi-
tional data should be stored in a format appropriate for the specific application,
but should not complicate or interfere with the representation of data from other
applications.
GraphML is designed with this and the following more pragmatic goals in mind:
• Simplicity : The format should be easy to parse and interpret for both humans
and machines. As a general principle, there should be no ambiguities and thus a
single well-defined interpretation for each valid GraphML document.
• Generality : There should be no limitation with respect to the graph model, i.e.
hypergraphs, hierarchical graphs, etc. should be expressible within the same basic
format.
• Extensibility : It should be possible to extend the format in a well-defined way to
represent additional data required by arbitrary applications or more sophisticated
use (e.g., sending a layout algorithm together with the graph).
• Robustness : Systems not capable of handling the full range of graph models or
added information should be able to easily recognize and extract the subset they
can handle.
5.2 Basic Concepts
In this section, we describe how graphs and simple graph data are represented in GraphML.
The graph model used in this section is a labeled mixed multigraph, i. e. a tuple
G = (V,E,D),
where V is a set of nodes, E a multi-set containing directed and undirected edges, and D a set
of data labels that are partial functions from {G}∪V ∪E into some specified range of values.
Thus, our graph model includes graphs that can contain both directed and undirected edges,
loops, and multi-edges. This graph model will be extended in Sect. 5.2.3, where advanced
concepts for the graph topology, like nested graphs, hypergraphs, and ports, are introduced.
As an example, consider the document fragment and the graph it describes in Fig. 5.1.
5.2.1 Header
The document fragment shown above is not yet a valid XML document. Valid XML doc-
uments must declare in their header either a DTD (document type definition) or an XML
schema. Both DTDs or schemas define a subset of all XML documents that forms a cer-
tain language. The GraphML language has been defined by a schema. Although a DTD
is provided to support parsers that cannot handle schema definitions, the only normative
specification is the GraphML schema located at
http://graphml.graphdrawing.org/xmlns/1.0/graphml.xsd