Wn: a Python interface for wordnets beyond English

What Wn solves that a WordNet reader does not

Most Python code that touches WordNet today goes through NLTK's corpus reader, which is built around one resource: the Princeton WordNet 3.0 files. That works until you need a second language. Then you are writing your own loader for another wordnet's format, mapping its synsets to English ones by hand, and maintaining that mapping as the upstream data changes. Wn takes the opposite position. It treats a wordnet as a downloadable, versioned package with a specifier such as oewn:2025+ or odenet:1.4, keeps an index of known projects in wn/index.toml, and loads them into a local SQL database. Interlingual links go through the Collaborative Interlingual Index, so a synset in the German wordnet and a synset in the English wordnet can be related without you writing the join. The audience is developers and researchers who treat wordnets as data sources rather than as a single fixed artifact: people building multilingual retrieval, cross-lingual annotation tools, or lexical resources that have to outlive one WordNet release.

The SQL backend and what it changes

The mechanism worth understanding is that Wn does not parse WN-LMF files on every import. It adds a wordnet to a database and queries that. The README lists this as a feature: a SQL-based backend that offers fast startup and better performance on many kinds of queries. The trade-off is state. Your queries depend on what has been added to the database, not only on what is installed in your environment. The README is explicit that existing users may hit an error about an incompatible database schema, and it gives two remedies: wn.reset_database(rebuild=True) to re-add indexed lexicons, or wn.reset_database() to initialize without re-adding and start from scratch. That is a real operational cost. Any deployment that upgrades Wn across a schema change needs a step that rebuilds or resets the database, and a CI job that only runs pip install will not catch the problem. The search API is otherwise conventional: you get a Wordnet object for a specifier, call synsets() with a word and optionally a part of speech, and read definitions off the result. Similarity metrics and taxonomy traversal are exposed as separate modules, which keeps the core object small.

Installing Wn and running a first query

Wn is on PyPI. The README gives pip as the primary install path and uv as an alternative. The package requires Python 3.10 or newer according to pyproject.toml, and its only runtime dependencies are httpx plus tomli on Python versions below 3.11.

pip install wn

After that, the library has no data. You download a wordnet with the module entry point, naming the specifier exactly as it appears in the index. The README uses the Open English WordNet 2025+ release for this example.

python -m wn download oewn:2025+

The download populates the local database, so the next step is a normal Python session. The README's getting-started snippet creates a Wordnet object for the specifier, takes the first verb synset for 'win', and reads its definition. The expected output is the string 'be the winner in a contest or competition; be victorious'.

>>> import wn
>>> en = wn.Wordnet('oewn:2025+')
>>> ss = en.synsets('win', pos='v')[0]
>>> ss.definition()
'be the winner in a contest or competition; be victorious'

If you are upgrading an existing installation rather than starting fresh, run the reset shown above before assuming the new version is broken.

Where Wn is the wrong choice

The failure modes are mostly about scope. First, if your project is English-only and pinned to Princeton WordNet 3.0 for replicability, Wn's multilingual machinery buys you nothing, and its API is not the one your code already uses. The repository ships a migration guide at docs/guides/nltk-migration.html, which is an admission that the two interfaces differ enough to need documentation. Second, if you need a wordnet that is not in the index and is not in WN-LMF 1.4 format, the README's claim of full WN-LMF 1.4 support is the boundary: anything outside that schema needs conversion first. Third, the database is local state. In a container or a serverless function you either bake the database into the image or download a wordnet on cold start, and the README does not document a rollback path for a failed schema migration beyond resetting. Finally, the package classifiers mark it Development Status 4 - Beta. Treat version pinning as mandatory rather than optional.

How this differs from NLTK's WordNet interface

NLTK's wordnet module is a reader over a bundled corpus, and its identifier for a synset is the offset-and-pos form tied to the Princeton files. Wn's identifier space is different: synsets come from whichever lexicon you loaded, and cross-lingual identity is expressed through CILI rather than through WordNet 3.0 offsets. That difference is the whole point. It means you can query odenet:1.4 and oewn:2025+ in the same process and relate them, which NLTK does not attempt. The cost is that anything you wrote against NLTK's synset objects, its lemma names, or its similarity functions will need rewriting, and the results will not be numerically identical because the underlying lexicons are different releases. If your requirement is a stable, frozen English WordNet for experiment replication, NLTK or a direct read of the OMW English WordNet based on WordNet 3.0 files is the more conservative choice. If your requirement is coverage across languages, Wn is doing work NLTK was never designed to do.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-05. Releases are frequent enough to matter: v1.0.0 in February 2026, v1.1.0 in March, and v1.1.1 in August. The licence is MIT, declared in pyproject.toml as an OSI-approved MIT License classifier and shipped as a LICENSE file at the repository root. MIT is permissive, so embedding Wn in a commercial product is not the obstacle; the obstacle is the data. Each wordnet you download carries its own licence, and the README's index lists projects from several upstream groups, so the licence of oewn:2025+ is not automatically the licence of Wn itself. Check the upstream project before redistributing a database file. On upgrade cost, the schema note in the README is the concrete item to budget for: a version bump can require wn.reset_database(rebuild=True), which re-downloads or re-adds indexed lexicons. This is not legal advice, and the licence terms of the individual wordnets are outside what the repository documents.

Editorial conclusion

Adopt Wn if your work crosses languages, if you need CILI-linked synsets, or if NLTK's WordNet reader has become a bottleneck. Do not adopt it if you only need Princeton WordNet 3.0 and already have NLTK wired into a pipeline: the migration guide exists precisely because the two APIs differ. Before committing, verify that the wordnets you need are in the index at wn/index.toml, check that your Python is 3.10 or newer, and plan for the database reset. The library is beta-classified, so pin the version in pyproject.toml rather than tracking main.

Frequently asked questions

Official sources

1. goodmami/wn on GitHub
2. License: MIT
3. Project website
4. README
5. Releases