Protege4Migration
Choosing between versions of Protege
This page contains a high level outline of the major differences in features between Protege 3.x and Protege 4.0.
Contents
Overview
There are a number of differences between the Protege 3 series (Protege 3.3.1 & Protege 3.4 beta) and the beta version of Protege 4.0. This page is designed to highlight some of the major factors that may influence which of the two systems would be most appropriate for your project at present. It will also serve as a useful reference point for identifying major features that need priority migration from 3.x to 4.0. This list is by no means exhaustive and is only intended as an overview.
Recommendations
Frames
For working with frames-based ontologies there is only one choice - the 3.x series is built on a very mature and stable codebase. Frames support is not currently available in P4.x.
OWL (and RDF)
For working with OWL there are several factors that may influence your decision whether to use P3.x or P4.x.
Developers
For coders writing purely OWL applications, we would recommend P4.x. For applications where you cannot cleanly break away from RDF you should consider P3.x.
The P4.x framework is based on the open source java OWL API that is proving very popular with many developers around the world. This makes writing or migrating code to and from other systems much more straightforward and a larger developer community means more assistance and a more robust codebase. In addition, the OWL API already supports much of the upcoming OWL2.0 recommendation, and this is unlikely to be supported in the existing Protege-OWL API.
However, for developers that require access to the underling RDF model at the level of a triple store, the Protege-OWL API is build on top of the frames system, with RDF and OWL constructs being modelled down into protege-frames. This is much harder to develop with as all levels of abstraction are visible at the API level, but allows for more control over the relationship between the different models.
Users
For ontology developers the choice is harder as the tasks that any given user/application needs to perform can be very different. For users creating purely OWL ontologies or needing OWL2.0 features we would recommend P4.x. For users wanting access to RDF or that require particular tools that have not yet been converted, P3.x is currently still the choice.
Ultimately, P3.x is coming to a stable state such that the features of the platform are well known and the behaviour is predictable. There are many plugins available that aid particular tasks that are not currently available for P4.x. So for example, those wanting SWRL support will find the framework in P3.x much more substantial than in P4.x. Equally, users that need access to RDF(S) level constructs will need to use P3.x.
P4.x is much more lightweight, being a wholly OWL editing environment currently, and is therefore optimised considerably for dealing with even modestly large OWL ontologies in memory. The number of groups producing additional tools for visualisation, mining etc is growing. The framework uses more standard mechanisms for customisation and can therefore be more easily tuned to a particular group's workflow. P4.x will also support all OWL2.0 features, such as QCRs, role chains, additional property characteristics etc, many of which are already implemented.
Side by Side Comparison
Protege 3.x | Protege 4.0 |
---|---|
Frames Support | Frames Support |
Frames editing supported via the Protege-Frames editor | None (Protege-Frames editor has not been migrated yet) |
OWL Support | OWL Support |
OWL 1.0 language support | OWL 2.0 language support |
OWL and RDF(S) support | Pure OWL framework |
OWL and RDF(S) files are accessible via the Protege-OWL API. This API layered OWL and RDF support over the existing Frames API. | OWL files are accessible via the OWL API, which was developed at the The University Of Manchester (not the Protege-OWL API, which was used in the 3.x series). This is a very clean API that closely follows the OWL specification and the parser is optimized to be faster and use less memory. |
SPARQL support | No SPARQL support yet |
SWRL support | No SWRL support yet |
Support for meta-modeling (allowing OWL Full) | No OWL Full |
Reasoner support through HTTP DIG interface allows connection to any DIG compliant reasoner, as well as direct connection to the Pellet reasoner | Direct connection to FaCT++ and Pellet for optimum speed of classification |
Configuration settings stored in Protege Project files (.pprj) | No project files, configuration settings persist across installations of Protege |
OWL imports handled through a repository mechanism | Simplified imports resolution from a common folder (repositories also supported) |
Plugins | Plugins |
Plugin framework developed at Stanford for tab widgets, slot widgets, back-ends, projects, importing, and exporting | Plugin framework was switched to the more industry standard OSGi, which allows for any type of plugin extension |
Large set of plugins available, developed both in-house and externally by the Protege community | Migration of plugins to Protege 4 is in the beginning stages, but an increasing number are becoming available |
User Interface | User Interface |
Tab and slot widgets make much of user interface configurable | Plugins define all user interface elements including tabs, views, and menus making everything configurable |
Access is provided to the meta model and can be used to configure the user interface | Menu and drag and drop user interface elements |
Support fill-in-the-blank style of setting property values in individuals | Property values of individuals are added as axioms
|
Multi-user Support | Multi-user Support |
Multiple users can edit the same ontology using the client-server version of Protege | None (Protege Client-Server has not been migrated yet) |
Database Storage Model | Database Storage Model |
Ability to store ontologies in a database provided by the JDBC database back-end | None (database back-end has not been migrated yet) |