Six Degrees of Wikipedia: Link Paths and Local Setup

The Wikipedia connection problem in Six Degrees of Wikipedia

Six Degrees of Wikipedia answers a specific graph question: which sequence of Wikipedia page links is shortest between two articles? The README states that the site traverses page links to find that shortest path across Wikipedia's millions of pages. Its audience includes readers investigating unexpected relationships, educators demonstrating network effects, and developers interested in building an interface over Wikipedia's link structure.

The service offers a different kind of lookup from ordinary Wikipedia search. Search retrieves articles that match a query. Six Degrees of Wikipedia instead treats articles as vertices and links as edges, then calculates the connecting route. The intermediate pages can be more important than either endpoint. Finding a path from one historical figure to another can expose a chain of concepts that neither article mentions directly.

That focus also defines the project's boundaries. A discovered route represents connectivity through Wikipedia links. It does not, by itself, demonstrate causation, endorsement, historical importance, or a relationship asserted by the people who wrote the articles. Six Degrees of Wikipedia is therefore useful for graph exploration, while questions about historical or factual interpretation remain outside the shortest-path result.

The README connects the project to six degrees of separation and to link-based games such as Wikiracing and WikiRace. Those references explain the intended experience: select an article, select another, and inspect the shortest chain of links connecting them. The site's `/blog/search-results-analysis` page discusses patterns found in its first 500,000 searches, although the README does not summarize those findings.

How the link graph reaches a shortest-path result

The architecture has two clear operational stages. The first builds the Wikipedia link data and database. The second serves path queries through the website. This division appears in the repository documentation, which separately directs readers to `./docs/data-source.md` for downloading or generating the database and `./docs/web-server-setup.md` for production deployment.

Based on that separation, the graph flow can be described without claiming a specific graph library or algorithm. Wikipedia pages act as nodes, and links between them form connections. The data-preparation stage converts upstream information into the project's queryable database. The application then uses that prepared structure to return the shortest route for a selected pair of pages. The README confirms the result, but it does not document whether the implementation uses Breadth-First Search, A*, bidirectional search, a precomputed distance matrix, or another method.

Repository directories support the broader design. `sql/` contains database-related resources, `sdow/` contains the application package, `scripts/` contains processing support, and `website/` contains the public site. `config/` holds configuration files. The repository identifies TypeScript as the primary language, while `requirements.txt` lists Python dependencies such as Flask, Gunicorn, protobuf, Requests, and supervisor. This suggests a mixed web and processing repository, but the README does not explain which components are TypeScript and which are Python.

The documentation is therefore strongest at the architectural level and weaker at the implementation level. A developer can identify that a database preparation stage exists and that a production server is expected, but cannot confirm from the README how edge types, redirects, namespaces, or duplicate links are handled. Those details belong in the repository's data-source and server documentation, not in an assumed API contract.

Preparing Wikipedia data before using the service

Data preparation is the main adoption constraint. The README sends users to `./docs/data-source.md` for instructions on downloading or generating the Six Degrees of Wikipedia database. It does not include those instructions, so this review cannot give a confirmed database dump command, import command, schema, storage engine, or build flag.

The README identifies three relevant resources: the Wikipedia API, Wikipedia's database layout documentation, and English Wikipedia database dumps. These sources explain where upstream data can come from and how Wikipedia organizes its data. They do not establish that every dump can be imported unchanged by this project. A local deployment may need substantial storage and processing, and it may need a decision about article language, namespaces, and link semantics.

The hosted website at `https://www.sixdegreesofwikipedia.com` is a separate option from local operation. Readers can use the hosted service without building their own graph. Reproducing the service locally requires following both the local setup document and the web server setup document. The README does not state whether the hosted service exposes a public API, whether its database can be downloaded directly, or how frequently the hosted graph is refreshed.

The correct first technical check is data provenance. Confirm which Wikipedia source the project consumes, what a generated database represents, and whether a stale graph is acceptable for the intended use. Without those answers, a successful local installation could still produce results that differ from the hosted site or current Wikipedia data.

Local installation and a first path search

The README does not provide copyable installation commands or a first-query example. It directs contributors to `./.github/CONTRIBUTING.md` for local setup and to `./docs/web-server-setup.md` for production server setup. Inventing a command such as a package installation, database flag, or server port would not be justified by those documents.

A practical first use can begin with the hosted website. Choose two Wikipedia articles that have a plausible connection, submit them through the site's search interface, and inspect the returned chain. The README describes the site's purpose as finding the shortest path, but it does not specify the exact form fields or URL pattern. For a local check, follow the contribution guide, prepare the database using `./docs/data-source.md`, configure the application, and repeat the same pair of articles.

The requirements file lists Python packages with exact versions, including `flask == 3.1.3`, `gunicorn == 26.0.0`, `requests == 2.34.2`, and `supervisor == 4.3.0`. These entries document Python dependencies, not a complete installation procedure. The repository entries do not show a Node.js or TypeScript package manifest, so the web application's JavaScript setup cannot be reconstructed from the README.

A useful acceptance check is repeatability. Run the same query locally and compare its route with the hosted result. If the local database is incomplete or generated differently, the paths may differ. Record the data source and configuration used for that comparison rather than treating a differing route as an application bug automatically.

Limitations of link-only shortest paths

The main limitation is that the result reflects a link graph, not a complete semantic model. Wikipedia pages may be connected through sections, templates, category pages, redirects, or other structural relationships, but the README does not specify which of these edges the database includes. A shortest route can therefore be mathematically valid for the project's graph while still feeling unexpected to a reader.

Page titles create another edge case. The README points to `./docs/miscellaneous.md` for interesting searches and edge-case titles, which indicates that unusual input handling matters. It does not document whether the service normalizes redirects, handles punctuation identically across languages, or distinguishes a page title from a search phrase. Developers embedding the service should not assume that two different inputs map to the same node without checking the data-source documentation.

There is also a freshness limitation. The repository links to English Wikipedia database dumps, but it does not promise real-time updates or publish a refresh cadence. The hosted site may have newer or older data than a locally generated graph. Wikipedia itself changes continuously, so reproducibility requires recording which dump or generated database was used.

Finally, the repository has no GitHub releases. That means the README does not offer a conventional release series from which to select versions. The last push was on 2026-10-01, so the repository is not archived, but an evaluation should inspect compatibility among the code, database format, Python dependencies, and deployment configuration before upgrading.

License and maintenance considerations

The repository lists an MIT license. That license is relevant to reviewing the project's own source code, but it does not automatically settle questions about Wikipedia content, database dumps, trademarks, or third-party dependencies. An organization deploying a public copy should inspect `./LICENSE` and the applicable Wikipedia source terms rather than assuming the MIT license covers every distributed component.

The repository is not archived. Its last push was on 2026-10-01, which indicates recent repository activity, but the README does not describe a release process, migration policy, compatibility matrix, or supported production upgrade path. The absence of GitHub releases is another practical constraint. Operators should treat the current code and documentation as the source of truth and verify database compatibility before replacing a running deployment.

The Python requirements are pinned, which helps identify the intended dependency set for the service and processing components. The repository does not state whether those pins are tested across environments, whether Python versions are fixed, or whether frontend dependencies follow a separate upgrade schedule. Those gaps matter for maintenance planning.

Editorial conclusion

Six Degrees of Wikipedia fits developers who need a focused shortest-path interface for Wikipedia links and can prepare its database and service configuration. It does not suit teams seeking a packaged API, documented one-command install, or flexible graph platform. Verify first that `./docs/data-source.md` supports the required Wikipedia dataset and that `./.github/CONTRIBUTING.md` produces a working local service. If those two steps fail, the repository is not a viable deployment base.

Frequently asked questions

Official sources

1. Issues
2. jwngr/sdow on GitHub
3. License: MIT
4. Project website
5. README