Introduction

Turning vertices into edges and edges into vertices is not one single graph transformation. It can mean different constructions depending on which information you need to preserve. In practice, the two most useful interpretations are the line graph, where original edges become new vertices, and the incidence graph, where original vertices and edges both remain explicit in a bipartite structure.

Decide What the Transformation Is For

The phrase sounds symmetric, but graph transformations are driven by a goal:

• edge-centric analysis such as conflict detection or edge coloring
• a bipartite representation that keeps original vertices and edges visible
• a representation better suited to matrix or constraint methods

If the purpose is unclear, it is easy to build a graph that is mathematically valid and operationally useless. The transform should follow the algorithm you want to run next.

Use a Line Graph When Edges Should Become Nodes

In a line graph L(G), every edge of the original graph G becomes a vertex in the transformed graph. Two transformed vertices are connected when their original edges share an endpoint.

That is useful when relationships between edges matter more than relationships between original vertices. A scheduling or routing problem can often become simpler after this shift.

1import networkx as nx
2
3G = nx.Graph()
4G.add_edges_from([
5    ("A", "B"),
6    ("B", "C"),
7    ("C", "D"),
8    ("B", "D"),
9])
10
11L = nx.line_graph(G)
12
13print("original edges:", sorted(G.edges()))
14print("line-graph nodes:", sorted(L.nodes()))
15print("line-graph edges:", sorted(L.edges()))

In the result, each node label is an original edge. That mapping should be preserved carefully if later stages need to recover the original graph semantics.

Use an Incidence Graph When You Need Both Sides

If you want a structure where original vertices and original edges are both explicit, build an incidence graph. This is a bipartite graph with one partition for original vertices and another for original edges.

1import networkx as nx
2
3G = nx.Graph()
4G.add_edges_from([
5    ("A", "B"),
6    ("B", "C"),
7    ("C", "D"),
8])
9
10B = nx.Graph()
11
12for v in G.nodes():
13    B.add_node(f"v:{v}", kind="vertex")
14
15for idx, (u, v) in enumerate(G.edges()):
16    edge_node = f"e:{idx}:{u}-{v}"
17    B.add_node(edge_node, kind="edge")
18    B.add_edge(f"v:{u}", edge_node)
19    B.add_edge(f"v:{v}", edge_node)
20
21print(B.number_of_nodes(), B.number_of_edges())

This form is especially useful in constraint models, matching problems, and workflows where you need to move between entity-centric and relation-centric reasoning without losing one side.

Directed Graphs Need Explicit Semantics

For directed graphs, the transformation rules cannot just be copied from the undirected case. A directed line graph should respect direction: an edge from u to v should connect to an edge from v to w, not to every edge that merely touches v.

1import networkx as nx
2
3DG = nx.DiGraph()
4DG.add_edges_from([
5    (1, 2),
6    (2, 3),
7    (2, 4),
8    (4, 5),
9])
10
11LD = nx.line_graph(DG)
12print(sorted(LD.nodes()))
13print(sorted(LD.edges()))

If you ignore direction here, the transformed graph can support invalid paths and break any algorithm built on those paths.

Preserve a Reversible Mapping

Whatever transformation you choose, keep a stable mapping between transformed identifiers and original graph objects. Relying on string formatting alone makes reverse mapping brittle, especially once graphs are serialized or merged with other data.

A simple dictionary is often enough:

edge_to_id = {edge: idx for idx, edge in enumerate(G.edges())}
id_to_edge = {idx: edge for edge, idx in edge_to_id.items()}

This becomes important the moment a downstream algorithm produces an answer in the transformed graph and you need to explain that answer in the language of the original problem.

Validate the Transformation

A transform should come with invariants you can test. For a line graph, the number of transformed nodes should equal the number of original edges. For an incidence graph of a simple undirected graph, every transformed edge-node should connect to exactly two transformed vertex-nodes.

Those checks are cheap and prevent silent schema drift when the transformation code evolves.

Common Pitfalls

The most common mistake is using the term "swap vertices and edges" without specifying which formal construction is actually intended. Another is forgetting direction when the original graph is directed. Teams also lose information by failing to keep a stable reverse mapping from transformed nodes back to original graph objects.

Summary

• "Vertices into edges and edges into vertices" can mean different graph transforms.
• Use a line graph when original edges should become the primary nodes.
• Use an incidence graph when original vertices and edges both need to remain explicit.
• Handle directed graphs with direction-aware transformation rules.
• Preserve reversible mappings so transformed results can be interpreted correctly.