What Is a Protein Interaction Network and How Do You Build and Interpret One?

Updated

A protein interaction network is a graph in which proteins are nodes and interactions between them are edges. You build one by collecting interaction data from experimental or predicted sources, filtering it by confidence and evidence type, mapping all identifiers to a common namespace, and then visualizing and analyzing the resulting graph. Interpretation focuses on topology — hubs, bottlenecks, and modules — but any conclusion should be checked against false positives, study bias, and the biological context in which the interactions occur.

Nodes, edges, and what the network actually represents

The core abstraction is simple:

  • Node — one protein (or gene, depending on the data source).
  • Edge — an interaction between two proteins.

Edges come in two broad flavors, and conflating them is a common mistake:

Edge type Meaning Typical source
Physical The two proteins physically bind Affinity purification, yeast two-hybrid, structural inference
Functional The two proteins are involved in the same process or pathway, but need not touch Genetic interaction screens, co-expression, text mining

A protein interaction network is not the same as a pathway or a complex. A pathway is a directed, often curated model of a process; a complex is a stable assembly of subunits. A network is a broader, usually undirected map that can contain both, plus interactions that belong to neither.

Where the interaction data comes from

You rarely generate a network from scratch. Most projects assemble one from existing resources:

  • Experimental databases — curated records of published interactions, such as STRING and BioGRID.
  • Predicted interactions — inferred from text mining of the literature, from structural similarity, or from genomic context.
  • In-house data — your own screens, which can be layered on top of public data.

Because sources differ in coverage and reliability, the same pair of proteins may appear in one database and not another. Treat the choice of source as a modeling decision, not a neutral lookup.

Building the network step by step

  1. Collect interactions. Query one or more databases for the proteins or the biological question you care about. Decide up front whether you want physical, functional, or both.
  2. Filter by confidence or evidence type. Most databases attach a score or an evidence category to each interaction. Set a threshold and record it — a network built at a high-confidence cutoff will look very different from one built at a permissive cutoff.
  3. Map identifiers. Proteins are referenced by many names (UniProt, Ensembl, gene symbols). Map everything to a single namespace before merging, or you will silently create duplicate nodes and miss real edges.
  4. Merge and de-duplicate. Combine sources, resolve conflicts, and keep track of which evidence supports each edge.
  5. Visualize. Layout algorithms (force-directed layouts are common) place highly connected proteins near each other. Visualization is for exploration; the numbers come from the graph analysis.
  6. Analyze. Compute topology metrics and look for structure.

The expected result at the end is a graph you can query: which proteins connect to a protein of interest, which groups are densely connected, and which nodes sit between otherwise separate regions.

Reading the topology

Once you have a graph, a handful of concepts carry most of the interpretive weight:

  • Degree — the number of edges a node has. High-degree nodes are hubs.
  • Betweenness centrality — how often a node lies on the shortest path between other nodes. High-betweenness nodes are bottlenecks, often connecting distinct modules.
  • Modules — groups of nodes that are more densely connected to each other than to the rest of the network. These often correspond to complexes or functional units.
  • Hubs vs. bottlenecks — a hub is well connected locally; a bottleneck is strategically placed globally. They overlap but are not the same, and both are candidates for follow-up.

Biologically, hubs are frequently essential or broadly involved in regulation, while bottlenecks tend to link processes. Neither is a guarantee — the pattern is a hypothesis generator, not a conclusion.

Common pitfalls

  • False positives. High-throughput screens produce spurious edges. A single unconfirmed interaction is weak evidence.
  • Study bias. Well-studied proteins (for example, p53) accumulate many reported interactions simply because they have been examined more. This inflates their degree and can dominate your network.
  • Context dependence. An interaction may exist only in a particular tissue, cell state, or condition. A static network hides this.
  • Identifier collisions. Merging datasets without consistent ID mapping is a silent source of error.
  • Threshold sensitivity. Conclusions that flip when you change the confidence cutoff are not robust.

Cross-check findings against independent evidence — a second database, co-expression, or a targeted experiment — before treating a hub or module as real.

What networks are used for

Two practical applications recur:

  • Drug target prioritization. Proteins that sit at bottlenecks or in disease-associated modules are candidate targets, because perturbing them may affect a whole process rather than a single reaction.
  • Disease module discovery. If proteins linked to a disease cluster in one region of the network, that region suggests shared mechanism and new candidate genes.

In both cases the network narrows the search space. It tells you where to look, not what you will find — the follow-up experiment is what confirms it.

Where custom tooling fits

Public databases and standard visualization tools cover many needs, but they assume your data fits their model. When you have in-house databases scattered across departments, non-standard identifiers, or a specific analysis pipeline, custom integration and tailored interfaces become the practical route. biobyte solutions GmbH, for example, positions itself around customised bioinformatics tools and services — including database and resource integration, data visualization, and consulting — for teams whose data does not map cleanly onto off-the-shelf workflows. The relevant question is whether your bottleneck is the biology or the plumbing: if it is the plumbing, a custom build is worth evaluating; if it is the biology, start with the public resources above.