WebProtégé: a collaborative ontology editor that runs in a browser

The repository that is being replaced

The first thing in the README is a notice, and it changes how everything else should be read.

The repository is in the process of being superseded by a collection of other, more fine-grained repositories. The project is moving WebProtégé to a microservice architecture, and each microservice and each common library now has its own repository. While this repository still serves as the repository for the current WebProtégé release, all active development is now taking place in those other repositories, and the README points to the WebProtégé Next Generation Overview wiki for the detail.

So there are two things here, and they have different half-lives. The code in this tree is the application that people run today, and the newest tagged releases are v4.0.2, v4.0.1 and v4.0.0, all from July 2020. The future of the project lives in the finer grained repositories, and the module structure in this tree hints at what that looks like, with separate directories for the client, the server, a server API, server core, a Lucene-backed server component, shared core, shared code and a command line tool.

The last push to this repository was on 2026-07-28, so the tree is not frozen, it is just no longer where new features land.

The code is Java, the licence is a custom one that GitHub cannot classify, recorded in a license.txt file, and the application is Apache-licensed in the sense that the source is public, though the terms themselves are in that file rather than in a standard header.

What an ontologist actually gets

WebProtégé is described as a free, open source collaborative ontology development environment, and the feature list is the reason it exists.

It supports editing OWL 2 ontologies, and it ships a default simple editing interface that gives access to the commonly used OWL constructs without exposing everything at once. That is a deliberate simplification: the full OWL 2 language is large, and the everyday work of a modeller is classes, properties, individuals and constraints, not the corners of the language specification.

It also supports editing OBO ontologies, which matters for the biomedical ontologies that OBO was designed for, and it handles multiple file formats for upload and download, with RDF/XML, Turtle, OWL/XML and OBO named in the documentation.

The collaboration features are the differentiator against a plain editor. Change tracking and revision history are complete, and there is sharing with permissions, threaded notes and discussions, watches, and email notifications. In practice that turns an ontology from a file into a shared artefact with a history and a conversation attached to it.

The interface is customizable, and the application runs as a web application that end users reach through a browser, with no download or install. The project points users at a hosted instance, and a war file is available for anyone who wants to deploy it on their own server.

Running it locally with Compose and MongoDB

The Docker path is the most documented way to get a working instance, and the compose file in the repository root is small enough to read in one go.

It defines two services. The first is a MongoDB container named webprotege-mongodb, running the mongo:4.1-bionic image, with its data volume mounted from ./.protegedata/mongodb. The second is the application container, built from the protegeproject/webprotege image, with a restart policy of unless-stopped, the environment variable webprotege.mongodb.host set to wpmongo so it can find the database, its data volume mounted from ./.protegedata/protege, and port 5000 on the host mapped to 8080 in the container.

Starting it is one command:

docker-compose up -d

The next step creates the admin account, and it is a separate invocation of the command line jar inside the running container:

docker exec -it webprotege java -jar /webprotege-cli.jar create-admin-account

You are prompted for a username, an email address and a password. After that, the settings page at http://localhost:5000/#application/settings is where you define the System notification email address and the application host URL, and enable User creation, Project creation and Project import. Those three switches are what turn the instance from a single-user setup into a server for a group.

Stopping is the mirror image:

docker-compose down

Because the volumes live in the source folder, the data survives the containers stopping, and the path can be changed in the docker-compose.yml file if you want it elsewhere.

Building your own image takes twenty minutes

The compose file uses the published image, and the README explains how to build your own from source instead, which is what you want if you are working on the master branch.

The only requirement is Docker, and the README makes a point of that: you do not need Java or Maven, because the whole application is compiled inside the container. The build command takes a build argument for the version:

docker build -t protegeproject/webprotege:latest-dev --build-arg WEBPROTEGE_VERSION=5.0.0-SNAPSHOT .

The tag with latest-dev is chosen so it is easy to tell apart from the official image on Docker Hub. The README warns to be patient, because this compiles all of WebProtégé inside Docker and can take twenty minutes or more the first time.

The version argument is not decorative. The documentation states that the WEBPROTEGE_VERSION value must match the version number near the top of the pom.xml file, and that on the current master branch that version is 5.0.0-SNAPSHOT. Get it wrong and the build will look for a war file that does not exist.

To make Compose use your image rather than downloading the official one, you create a docker-compose.override.yml next to docker-compose.yml, and Compose reads that file automatically:

version: "3"

services:
  webprotege:
    image: protegeproject/webprotege:latest-dev

After that, docker-compose up -d starts it, and the admin creation and settings steps from the Docker section apply unchanged, with the application available at http://localhost:5000. If you change the source later, you repeat the build and restart.

The Maven build and the SuperDev loop

Building from source outside Docker is the traditional route, and it is four steps in the README.

You clone the repository, open a terminal in the directory, and package the application with Maven:

git clone https://github.com/protegeproject/webprotege.git

mvn clean package

The war file lands in the webprotege-server directory.

For development there is a SuperDev mode, which is the detail worth copying. The client code is compiled by the GWT code server, and the application is served by Tomcat, and the two run in separate terminal windows:

mvn gwt:codeserver

mvn -Denv=dev tomcat7:run

Then you browse to http://localhost:8080. The value of this split is that the GWT code server recompiles Java into JavaScript on demand, so a change to the client is picked up without a full rebuild, and the Tomcat side stays up. For a Java and GWT project of this size, that is the difference between a two minute feedback loop and a twenty minute one.

For deployment on your own server, the README points to a separate installation page for the 4.0.0 beta x line, which is where the war file deployment instructions live.

Why Tomcat 9 and why MongoDB appears twice

The Dockerfile has two details that explain a lot about how the project is maintained, and both are the kind of thing that costs an afternoon if you hit it cold.

The first is the Tomcat version. The runtime stage is tomcat:9-jre11-temurin-jammy rather than Tomcat 10 or later, and the comment says why: WebProtégé uses the javax.servlet API, which Tomcat 10 replaced with jakarta.servlet. The namespace change in Jakarta EE 10 is a hard incompatibility, so the container image is pinned to the older major version. Anyone planning to run this on a modern Tomcat has to deal with that directly.

The second is MongoDB, which appears twice in different roles. In the build stage, MongoDB is installed from MongoDB's own apt repository because the test suite needs it during the Maven build, and the comment explains that Ubuntu no longer ships a mongodb package. In the compose file, the runtime database is the mongo:4.1-bionic image. The build stage uses the 8.0 repository while the runtime uses a 4.1 image, which is a mismatch in age between the two halves of the same project.

There is a third detail that explains a strange step. The runtime image has no unzip, so the war is exploded in the build stage, which has a full JDK, and copied into the runtime image as a directory rather than as an archive. The command line jar is copied across separately, because that is the tool the admin account step uses.

When a browser editor is the wrong answer

The limits of WebProtégé are the limits of the web application model, and they are worth being concrete about.

The first is that everything happens in a browser. That is the point for a team with many occasional contributors, since nobody installs anything, but it means the editing experience is bound by what the web platform offers, and a large ontology means a large amount of state in the browser. It also means the application is only as available as the server, and the README's own answer to a team with a slow or restricted network is not a better offline mode.

The second is the direction of travel. If you are starting something new, this repository is the wrong place to start, because the README is explicit that active development happens in the finer grained repositories and that this one serves the current release. Building a new deployment on the master branch here means building on 5.0.0-SNAPSHOT while the real work continues elsewhere.

The third is the alternative, and it is a real one for many teams. Ontologies are text files, and they live well in a text editor with Git: the format is RDF/XML, Turtle, OWL/XML or OBO, all of which diff and review cleanly. That route gives you version control with no server to run, at the cost of the ontology-aware interface, the change tracking, the permissions, the notes and the discussions.

The trade is between a shared, tracked, discussion-carrying environment and a plain file in a repository, and it is a genuine trade rather than a quality comparison. What you should not do is start a new project here without reading the Next Generation overview, because the project is telling you where the future is.

Editorial conclusion

WebProtégé suits a team that wants to edit ontologies in a browser with change tracking and collaboration built in, and it is the wrong starting point for a new deployment, because the README states that active development has moved to a set of microservice repositories and that this one serves the current release only. Verify first which repository you should build on, and if you stay here, read the compose file and the Dockerfile, because the runtime uses a mongo 4.1 image while the build stage installs MongoDB 8.0 for the test suite, which tells you the two halves were written at different times.

Frequently asked questions

Official sources

1. Issues
2. protegeproject/webprotege on GitHub
3. README
4. Releases