Network Models and Graph Structures: How Mathematical Models Represent Connected Systems

Last Updated June 12, 2026

Network models and graph structures represent systems through nodes, edges, connections, pathways, flows, and relationships. Instead of focusing only on isolated variables, they model how entities are linked: people in social systems, species in ecosystems, routers in infrastructure, firms in supply chains, neurons in brains, papers in citation networks, or risks in cascading systems.

A network model is useful when relationships are not background details but part of the system’s structure. In many systems, what matters is not only the properties of each entity, but also who or what is connected, how strongly, in which direction, through which pathways, and with what consequences.

Graph structures give these relationships mathematical form. They define vertices, edges, weights, directions, paths, components, adjacency matrices, incidence matrices, centrality measures, clustering, communities, flows, and structural constraints. These formal tools help modelers reason about connectivity, vulnerability, influence, diffusion, coordination, robustness, and cascading failure.

Network modeling is powerful because it changes the unit of analysis. A model no longer asks only what each part is doing. It asks how parts are connected and how those connections shape the behavior of the whole. This makes network models especially important for complex systems, infrastructure, public health, ecology, finance, information systems, supply chains, organizational analysis, and decision support under interdependence.

Why Network Models Matter

Network models matter because many systems are relational. The behavior of a node depends not only on its own attributes, but also on its neighbors, position, pathways, dependencies, and exposure to flows. A person’s risk may depend on contacts. A facility’s vulnerability may depend on upstream suppliers. A species’ persistence may depend on ecological interactions. A firm’s stability may depend on financial dependencies. A router’s importance may depend on traffic passing through it.

In such cases, isolated-variable modeling is not enough. The model must represent structure among entities.

Network models help reveal patterns that may be invisible in tables of node attributes. They show bridges, bottlenecks, clusters, hubs, isolates, feedback pathways, and cascading dependencies.

Back to top ↑

What a Network Model Is

A network model represents a system as a graph: a set of entities and the relationships among them. The entities are nodes or vertices. The relationships are edges, links, ties, arcs, or connections.

A network model may be descriptive, explanatory, predictive, or decision-supportive. It may describe structure, simulate diffusion, identify important nodes, assess vulnerability, compare designs, or support intervention planning.

A network model is not merely a picture. A visual graph may help interpretation, but the mathematical structure underneath determines what can be measured, simulated, tested, and validated.

Back to top ↑

Nodes, Edges, and Graph Structure

Nodes and edges are the basic components of graph structure. Nodes represent entities. Edges represent relationships. The meaning of each must be defined carefully.

For example, in a public health network, a node might represent a person, household, neighborhood, clinic, or city. An edge might represent physical contact, shared space, travel, information exchange, referral, or exposure. Each choice produces a different model.

The same real-world system can produce many different graphs. A transportation system can be represented as intersections connected by roads, stations connected by routes, cities connected by flights, or regions connected by freight flows. Network modeling begins by choosing the relational abstraction that matches the question.

Back to top ↑

Adjacency Matrices and Incidence Matrices

An adjacency matrix represents which nodes are connected. For a graph with \(n\) nodes, the adjacency matrix \(A\) is an \(n\times n\) matrix whose entries describe edges between nodes.

For weighted networks, adjacency entries can represent strength, capacity, distance, frequency, risk, probability, cost, or flow.

An incidence matrix represents relationships between nodes and edges. It is especially useful for flows, circuits, conservation constraints, and network optimization.

The choice of representation affects computation. A dense adjacency matrix may be clear for small graphs but inefficient for large sparse networks. An edge list may be easier to audit. A matrix may be better for spectral analysis or algebraic methods.

Back to top ↑

Directed, Weighted, Bipartite, and Multilayer Networks

Network models vary by edge meaning. A relationship may be mutual or directional, equal or weighted, one-type or multi-type, single-layer or multilayer.

Direction and weight can change conclusions. A node that receives many edges may differ from one that sends many. A network with many weak ties may behave differently from one with fewer strong ties. A graph that ignores direction or weight may simplify too much for the decision context.

Back to top ↑

Paths, Components, Distance, and Reachability

Paths describe how one node can be reached from another. A path is a sequence of nodes connected by edges. Network distance often means the length of the shortest path between nodes.

Reachability matters when networks represent transportation, influence, disease transmission, supply dependency, risk propagation, or communication. A node may be important because it connects otherwise separated parts of the graph.

Connectivity is not only a structural property. It can become a risk property. Highly connected systems may be efficient, but they may also allow shocks to travel quickly. Fragmented systems may be resilient to contagion but poor for access or coordination.

Back to top ↑

Degree, Centrality, and Influence

Centrality measures try to identify important nodes. Importance can mean many things: many connections, short distance to others, control over pathways, connection to important nodes, or exposure to flow.

Degree is simple, but it is not always the right measure of influence. A node can have few connections and still be critical if it bridges two communities. Another node may have many connections but little control over flow.

Centrality measures are not interchangeable. A responsible network model explains why a particular measure matches the model’s purpose and what kind of importance it claims to measure.

Back to top ↑

Clustering, Communities, and Modular Structure

Networks often contain clusters or communities: groups of nodes more densely connected internally than externally. Community structure can reveal social groups, ecological modules, supply-chain regions, knowledge domains, functional subsystems, or vulnerability zones.

Clustering can also affect dynamics. Information, disease, innovation, or failure may spread rapidly inside a cluster but more slowly across bridges between clusters.

Community detection should be interpreted carefully. Different algorithms may produce different communities. A detected cluster is a modeling result, not automatically a real social, ecological, or institutional group.

Back to top ↑

Flows, Diffusion, Contagion, and Cascades

Network structure often matters because something moves through the network. That movement may be material, information, money, electricity, disease, influence, risk, traffic, demand, or failure.

A graph structure alone does not define the process. The model must specify how flow, diffusion, contagion, or cascading behavior occurs.

Network process assumptions should be explicit. A contagion model, a flow model, and an influence model may use the same graph but imply different dynamics and interventions.

Back to top ↑

Random Network Models and Generative Structure

Random network models describe how graph structures might arise under probabilistic rules. They are useful for comparison, simulation, hypothesis testing, and uncertainty analysis.

Random graph models can serve as baselines. If a real network has much more clustering, skewed degree distribution, or community structure than a random graph, those differences may be meaningful.

Generative network models require caution. A model that reproduces one network statistic may fail on others. A random graph baseline is not a neutral truth; it is a comparison structure shaped by assumptions.

Back to top ↑

Dynamic Networks and Changing Graphs

Many networks change over time. Edges form and dissolve. Nodes enter and leave. Weights fluctuate. Direction changes. Layers interact. A static graph can hide timing, sequence, duration, and adaptation.

Dynamic network models are important when timing changes reachability or causality. If node \(A\) contacts node \(B\) after \(B\) contacts \(C\), the possible transmission pathway differs from a static graph that shows all edges at once.

Dynamic network modeling connects graph structure to systems modeling. The network is not only a fixed structure; it may be a changing state variable in the model.

Back to top ↑

Mathematical Lens: Graphs as Relational Structure

A graph can be represented through sets, matrices, operators, and functions. These forms make network structure available for computation and analysis.

The degree matrix \(D\) records node degrees on the diagonal, while the adjacency matrix \(A\) records connections. Their difference gives the graph Laplacian:

For a simple diffusion-like process on a graph, the Laplacian can describe how node states change relative to neighbors:

For path counting, powers of the adjacency matrix are useful:

This mathematical lens shows why network modeling is more than drawing connected dots. Graph structure can be translated into matrices, dynamics, optimization problems, stochastic processes, and decision-support tools.

Back to top ↑

Example: Infrastructure Risk Network

Consider a regional infrastructure system. Nodes represent facilities: power substations, water treatment plants, hospitals, transportation hubs, communication centers, and emergency depots. Edges represent dependencies: electricity supply, water service, data connectivity, fuel delivery, patient transfer, or logistics routes.

This network can be modeled as a directed, weighted graph. Direction matters because dependency is not always symmetric. A hospital may depend on a substation, but the substation does not depend on that hospital. Weight matters because some dependencies are stronger, more frequent, or more critical than others.

A simple risk model might assign each node a disruption probability and each edge a dependency strength. The model can then estimate which nodes are vulnerable to cascading disruption. But the model must be validated: dependency data may be incomplete, hidden redundancies may exist, and actual recovery behavior may differ from structural vulnerability.

This example shows the core value of network modeling. It helps analysts move from isolated asset lists to interdependent system structure.

Back to top ↑

Calibration, Validation, Sensitivity, and Uncertainty

Network models require validation because graph structure often depends on incomplete, noisy, or constructed data. Missing edges, false edges, uncertain weights, aggregation choices, and boundary decisions can all change conclusions.

A network model should be tested not only for whether the graph looks plausible, but also whether its conclusions survive reasonable changes in edges, weights, boundaries, and process assumptions.

Back to top ↑

Ethical Stakes of Network Modeling

Network models can reveal hidden structure, but they can also expose, rank, surveil, or misclassify people and institutions. In social, organizational, security, health, or policy contexts, network analysis can carry significant ethical risks.

Responsible network modeling requires clear purpose, data minimization, careful interpretation, uncertainty communication, and governance. A network measure should not be treated as proof of intent, blame, authority, or social meaning without supporting evidence.

Back to top ↑

Python Workflow: Network Register and Graph Diagnostics

The Python workflow below uses dependency-light graph routines to build a small infrastructure dependency network, compute degree and reachability diagnostics, identify components, and generate a network model audit card.

# network_models_graph_structures_workflow.py
# Dependency-light workflow for network registers and graph diagnostics.

from __future__ import annotations

from collections import defaultdict, deque
from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json


ARTICLE_ROOT = Path(__file__).resolve().parents[1]
OUTPUTS = ARTICLE_ROOT / "outputs"
TABLES = OUTPUTS / "tables"
JSON_DIR = OUTPUTS / "json"


@dataclass(frozen=True)
class NetworkRecord:
    key: str
    component_type: str
    expression_or_structure: str
    interpretation: str
    review_question: str
    status: str


@dataclass(frozen=True)
class Edge:
    source: str
    target: str
    relationship: str
    weight: float
    evidence_quality: str


def network_register() -> list[NetworkRecord]:
    return [
        NetworkRecord(
            key="node_definition",
            component_type="node",
            expression_or_structure="facility or service asset",
            interpretation="Nodes represent infrastructure assets.",
            review_question="Are critical assets included at the right scale?",
            status="review",
        ),
        NetworkRecord(
            key="directed_dependency_edge",
            component_type="edge",
            expression_or_structure="source -> target",
            interpretation="Directed edge indicates dependency or service flow.",
            review_question="Does edge direction match operational reality?",
            status="review",
        ),
        NetworkRecord(
            key="edge_weight",
            component_type="edge_weight",
            expression_or_structure="w_ij",
            interpretation="Weight represents dependency strength or criticality.",
            review_question="How was weight estimated and validated?",
            status="review",
        ),
        NetworkRecord(
            key="centrality_diagnostic",
            component_type="diagnostic",
            expression_or_structure="in_degree, out_degree, reachability",
            interpretation="Diagnostics identify structurally important nodes.",
            review_question="Does structural centrality match practical importance?",
            status="active",
        ),
    ]


def infrastructure_edges() -> list[Edge]:
    return [
        Edge("power_substation", "hospital", "electricity_supply", 0.95, "high"),
        Edge("power_substation", "water_treatment", "electricity_supply", 0.90, "high"),
        Edge("communications_hub", "hospital", "data_connectivity", 0.70, "medium"),
        Edge("fuel_depot", "power_substation", "fuel_dependency", 0.60, "medium"),
        Edge("transport_hub", "hospital", "patient_transfer", 0.50, "medium"),
        Edge("transport_hub", "fuel_depot", "fuel_delivery", 0.65, "medium"),
        Edge("water_treatment", "hospital", "water_service", 0.80, "high"),
        Edge("emergency_depot", "hospital", "emergency_supply", 0.75, "medium"),
        Edge("communications_hub", "emergency_depot", "coordination", 0.55, "medium"),
        Edge("power_substation", "communications_hub", "electricity_supply", 0.85, "high"),
    ]


def build_adjacency(edges: list[Edge]) -> dict[str, list[str]]:
    adjacency: dict[str, list[str]] = defaultdict(list)
    for edge in edges:
        adjacency[edge.source].append(edge.target)
        adjacency.setdefault(edge.target, [])
    return dict(adjacency)


def reachable_count(start: str, adjacency: dict[str, list[str]]) -> int:
    seen = {start}
    queue: deque[str] = deque([start])

    while queue:
        node = queue.popleft()
        for neighbor in adjacency.get(node, []):
            if neighbor not in seen:
                seen.add(neighbor)
                queue.append(neighbor)

    return len(seen) - 1


def degree_table(edges: list[Edge]) -> list[dict[str, object]]:
    nodes = sorted({edge.source for edge in edges} | {edge.target for edge in edges})
    adjacency = build_adjacency(edges)

    incoming: dict[str, int] = {node: 0 for node in nodes}
    outgoing: dict[str, int] = {node: 0 for node in nodes}
    incoming_weight: dict[str, float] = {node: 0.0 for node in nodes}
    outgoing_weight: dict[str, float] = {node: 0.0 for node in nodes}

    for edge in edges:
        outgoing[edge.source] += 1
        incoming[edge.target] += 1
        outgoing_weight[edge.source] += edge.weight
        incoming_weight[edge.target] += edge.weight

    rows: list[dict[str, object]] = []
    for node in nodes:
        rows.append({
            "node": node,
            "in_degree": incoming[node],
            "out_degree": outgoing[node],
            "weighted_in_degree": round(incoming_weight[node], 4),
            "weighted_out_degree": round(outgoing_weight[node], 4),
            "reachable_nodes": reachable_count(node, adjacency),
        })
    return rows


def edge_rows(edges: list[Edge]) -> list[dict[str, object]]:
    return [asdict(edge) for edge in edges]


def network_risk_score(record: NetworkRecord) -> float:
    score = {"active": 1.0, "review": 5.0, "revise": 8.0, "archive": 2.0}.get(
        record.status.lower(),
        4.0,
    )
    text = f"{record.component_type} {record.expression_or_structure} {record.review_question}".lower()
    for term in ["edge", "weight", "centrality", "direction", "critical", "dependency", "scale"]:
        if term in text:
            score += 1.0
    return round(score, 3)


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    if not rows:
        raise ValueError(f"No rows supplied for {path}")
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)


def write_json(path: Path, payload: object) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    with path.open("w", encoding="utf-8") as handle:
        json.dump(payload, handle, indent=2, sort_keys=True)


def main() -> None:
    records = network_register()
    edges = infrastructure_edges()

    register_rows = [
        {**asdict(record), "network_risk_score": network_risk_score(record)}
        for record in records
    ]

    diagnostics = degree_table(edges)

    write_csv(TABLES / "network_edge_list.csv", edge_rows(edges))
    write_csv(TABLES / "network_node_diagnostics.csv", diagnostics)
    write_csv(TABLES / "network_model_register.csv", register_rows)

    write_json(JSON_DIR / "network_model_audit_card.json", {
        "article": "Network Models and Graph Structures",
        "node_count": len({edge.source for edge in edges} | {edge.target for edge in edges}),
        "edge_count": len(edges),
        "network_model_register": register_rows,
        "node_diagnostics": diagnostics,
        "audit_checks": [
            "nodes are defined at the correct scale",
            "edge meaning is documented",
            "edge direction and weight are validated",
            "centrality is interpreted cautiously",
            "network conclusions are tested against missing-edge uncertainty",
        ],
    })

    print("Network models and graph structures workflow complete.")
    print(f"Wrote outputs to {OUTPUTS}")


if __name__ == "__main__":
    main()

This workflow treats network structure as an auditable model object. It preserves edges, relationship meanings, evidence quality, node diagnostics, and review questions rather than producing only a visual graph.

Back to top ↑

R Workflow: Network Review and Connectivity Diagnostics

The R workflow below reviews generated network outputs, classifies structurally important nodes, and creates a simple degree comparison plot using base R.

# network_models_graph_structures_review.R
# Base R workflow for network review and connectivity diagnostics.

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")
dir.create(tables_dir, recursive = TRUE, showWarnings = FALSE)
dir.create(figures_dir, recursive = TRUE, showWarnings = FALSE)

node_path <- file.path(tables_dir, "network_node_diagnostics.csv")
edge_path <- file.path(tables_dir, "network_edge_list.csv")
register_path <- file.path(tables_dir, "network_model_register.csv")

if (!file.exists(node_path) || !file.exists(edge_path)) {
  stop("Missing network outputs. Run the Python workflow first.")
}

nodes <- read.csv(node_path, stringsAsFactors = FALSE)
edges <- read.csv(edge_path, stringsAsFactors = FALSE)

nodes$structural_review <- ifelse(
  nodes$reachable_nodes >= median(nodes$reachable_nodes, na.rm = TRUE) &
    nodes$weighted_out_degree >= median(nodes$weighted_out_degree, na.rm = TRUE),
  "high structural review priority",
  ifelse(
    nodes$in_degree + nodes$out_degree == 0,
    "isolated node review",
    "routine review"
  )
)

write.csv(
  nodes,
  file.path(tables_dir, "r_network_node_review_summary.csv"),
  row.names = FALSE
)

if (file.exists(register_path)) {
  register <- read.csv(register_path, stringsAsFactors = FALSE)

  register$priority <- ifelse(
    register$network_risk_score >= 8,
    "high",
    ifelse(register$network_risk_score >= 6, "medium", "low")
  )

  write.csv(
    register,
    file.path(tables_dir, "r_network_model_review_queue.csv"),
    row.names = FALSE
  )
}

png(file.path(figures_dir, "r_network_degree_diagnostics.png"), width = 1100, height = 720)

degree_total <- nodes$in_degree + nodes$out_degree
names(degree_total) <- nodes$node

barplot(
  sort(degree_total, decreasing = TRUE),
  las = 2,
  ylab = "Total degree",
  main = "Network Node Degree Diagnostics"
)

grid()
dev.off()

print(nodes)

The R layer supports review by identifying nodes that may deserve additional scrutiny because of reachability, degree, or weighted dependency structure.

Back to top ↑

Haskell Workflow: Typed Network Records

Haskell is useful for this article because network model components should not collapse into one informal category. Nodes, edges, weights, diagnostics, and process rules have different roles in the model.

{-# OPTIONS_GHC -Wall #-}

module Main where

data NetworkComponent
  = NodeDefinition
  | EdgeDefinition
  | EdgeWeight
  | DirectionRule
  | CentralityDiagnostic
  | ProcessRule
  | ValidationDiagnostic
  deriving (Eq, Show)

data ReviewStatus
  = Active
  | RequiresReview
  | RequiresValidation
  | RequiresSensitivityTest
  | Revise
  deriving (Eq, Show)

data NetworkRecord = NetworkRecord
  { key :: String
  , component :: NetworkComponent
  , expression :: String
  , interpretation :: String
  , reviewFocus :: String
  , status :: ReviewStatus
  } deriving (Eq, Show)

networkRegister :: [NetworkRecord]
networkRegister =
  [ NetworkRecord
      "node_definition"
      NodeDefinition
      "V"
      "Nodes represent infrastructure assets."
      "Boundary and scale."
      RequiresReview
  , NetworkRecord
      "directed_dependency_edge"
      EdgeDefinition
      "source -> target"
      "Directed edge indicates dependency."
      "Direction and evidence quality."
      RequiresReview
  , NetworkRecord
      "edge_weight"
      EdgeWeight
      "w_ij"
      "Weight represents dependency strength."
      "Weight estimation and validation."
      RequiresValidation
  , NetworkRecord
      "centrality_diagnostic"
      CentralityDiagnostic
      "in_degree, out_degree, reachability"
      "Diagnostics identify structurally important nodes."
      "Practical meaning of centrality."
      Active
  ]

needsReview :: NetworkRecord -> Bool
needsReview item =
  case status item of
    Active -> False
    _ -> True

main :: IO ()
main = do
  putStrLn "Typed network model records:"
  mapM_ print networkRegister

  putStrLn "\nNetwork records requiring review:"
  mapM_ print (filter needsReview networkRegister)

This typed layer supports network governance by making node definitions, edge meanings, weight assumptions, and diagnostics explicit before graph outputs are interpreted as evidence.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-modeling workspace. It contains article-specific code, data, documentation, notebooks, schemas, and generated outputs for network model registers, graph diagnostics, adjacency and edge-list representation, centrality review, typed Haskell network records, validation planning, and reproducible computational workflows.

Back to top ↑

A Practical Method for Network Model Design

Network model design should begin with the relationship being modeled. A graph is useful only when nodes, edges, weights, direction, boundaries, and process assumptions match the modeling purpose.

This method helps prevent network modeling from becoming decorative. It links graph structure to purpose, data, computation, validation, and responsible interpretation.

Back to top ↑

Common Pitfalls

Network models can fail even when the graph looks compelling. Many failures arise from unclear edge meaning, incomplete data, overinterpreted centrality, or confusion between structure and process.

• Decorative network diagrams: drawing a graph without defining what nodes and edges mean.
• Edge ambiguity: mixing different relationship types without labeling them.
• Boundary distortion: excluding nodes or edges that change conclusions.
• Centrality overreach: treating a centrality score as proof of influence, authority, or blame.
• Ignoring direction: using undirected edges when relationships are asymmetric.
• Ignoring weights: treating weak and strong relationships as equivalent.
• Confusing structure with process: assuming that a path means actual flow, contagion, or causality.
• Overtrusting community detection: treating algorithmic clusters as real groups without validation.
• Static graph error: using a fixed network when timing and sequence matter.
• Missing-edge uncertainty: presenting network metrics without testing data incompleteness.

These pitfalls can be reduced through edge codebooks, boundary audits, weight documentation, uncertainty tests, metric justification, process validation, and careful communication of what the graph does and does not claim.

Back to top ↑

Conclusion: Networks Make Relationships Modelable

Network models and graph structures make relationships modelable. They allow mathematical modeling to represent not only entities, variables, and equations, but also connections, dependencies, pathways, flows, communities, and structural vulnerabilities.

Their strength is relational clarity. Network models can reveal hubs, bridges, clusters, bottlenecks, pathways, isolated components, fragile dependencies, and potential cascades. They can support explanation, prediction, simulation, optimization, and decision support in systems where interdependence matters.

But network models require discipline. Nodes must be defined. Edges must mean something specific. Weights and directions must be justified. Boundaries must be documented. Metrics must match purpose. Network processes must be validated. Centrality, community, and connectivity should not be overinterpreted.

Used responsibly, network models help analysts reason about complex systems as systems of relationships. They make structure visible, testable, and discussable without pretending that a graph alone can explain the whole world.

Back to top ↑

Related Articles

• What Is Mathematical Modeling?
• Variables, Parameters, and Constraints
• Functional Relationships and Mathematical Structure
• Optimization Models and Objective Functions
• Probabilistic and Stochastic Models
• Agent-Based Models and Emergent Behavior
• Simulation and Computational Modeling
• Sensitivity Analysis and Robustness
• Model Interpretation and Decision-Making
• Cascading Failure and Contagion

Back to top ↑

Further Reading

• Newman, M.E.J. (2018) Networks. 2nd edn. Oxford: Oxford University Press.
• Barabási, A.-L. (2016) Network Science. Cambridge: Cambridge University Press. Available at: https://networksciencebook.com/
• Easley, D. and Kleinberg, J. (2010) Networks, Crowds, and Markets: Reasoning About a Highly Connected World. Cambridge: Cambridge University Press. Available at: https://www.cs.cornell.edu/home/kleinber/networks-book/
• Diestel, R. (2017) Graph Theory. 5th edn. Berlin: Springer.
• Bondy, J.A. and Murty, U.S.R. (2008) Graph Theory. London: Springer.
• Wasserman, S. and Faust, K. (1994) Social Network Analysis: Methods and Applications. Cambridge: Cambridge University Press.
• Borgatti, S.P., Everett, M.G. and Johnson, J.C. (2018) Analyzing Social Networks. 2nd edn. London: SAGE.
• Jackson, M.O. (2008) Social and Economic Networks. Princeton: Princeton University Press.
• Watts, D.J. (2003) Six Degrees: The Science of a Connected Age. New York: W.W. Norton.
• Kolaczyk, E.D. and Csárdi, G. (2020) Statistical Analysis of Network Data with R. 2nd edn. Cham: Springer.

Back to top ↑

References

• Barabási, A.-L. (2016) Network Science. Cambridge: Cambridge University Press. Available at: https://networksciencebook.com/
• Bondy, J.A. and Murty, U.S.R. (2008) Graph Theory. London: Springer.
• Borgatti, S.P., Everett, M.G. and Johnson, J.C. (2018) Analyzing Social Networks. 2nd edn. London: SAGE.
• Diestel, R. (2017) Graph Theory. 5th edn. Berlin: Springer.
• Easley, D. and Kleinberg, J. (2010) Networks, Crowds, and Markets: Reasoning About a Highly Connected World. Cambridge: Cambridge University Press. Available at: https://www.cs.cornell.edu/home/kleinber/networks-book/
• Jackson, M.O. (2008) Social and Economic Networks. Princeton: Princeton University Press.
• Kolaczyk, E.D. and Csárdi, G. (2020) Statistical Analysis of Network Data with R. 2nd edn. Cham: Springer.
• Newman, M.E.J. (2010) ‘Networks: An Introduction’, Oxford: Oxford University Press.
• Newman, M.E.J. (2018) Networks. 2nd edn. Oxford: Oxford University Press.
• Wasserman, S. and Faust, K. (1994) Social Network Analysis: Methods and Applications. Cambridge: Cambridge University Press.
• Watts, D.J. (2003) Six Degrees: The Science of a Connected Age. New York: W.W. Norton.
• West, D.B. (2001) Introduction to Graph Theory. 2nd edn. Upper Saddle River, NJ: Prentice Hall.

Back to top ↑