Some Protégé Advice

The editor and its versions

Protégé is in constant evolution. Furthermore, it is made of an editing core and a number of plugins on top of it. The core and the plugins evolving, it is useful to know the following points :

• The Protégé community urges to use the latest build of the latest version avaliable, even if it is a beta version. Indeed, the latest build is likely to be the most debugged one. Still, if you experience some problems with either the latest build itself or interfacing it with the plugins you use, or anything threating your work in good conditions, it is obviously better to get back to your former version. Thus, it is strongly advised to install any new version in a separate directory and test it before deleting any former version.

• As for the plugins versions, things are a bit trickier for the following reason : some plugin versions require specific version/builds of Protégé. Thus, if you plan to install a rather "exotic" plugin, it is advised to check if there are such known requirements before installing version X of a plugin with version Y of Protégé. In any case you may try but it may or may not work correctly. This issue is rather uncommon nowadays though.

• Similarily, if you use plugins which are not included in the releases of Protégé and you change your version of Protégé, it is best to check if there is any incompatibility and usually it is a good idea to change the plugin version to tha latest avaliable if you do not ahve already the latest one.

• Generally speaking, it is best to install only the plugins you need. Indeed, some plugins tend to be incompatible or there may be a risk of one interfering with the other. Moreover, the less plugins you install, the less are likely to be loaded at some point, thus saving up resources and reducing the risk of possible errors. For instance, to use Protégé with OWL ontologies, it is best to install a basic Protégé with the OWL plugin (there is a specific option during the installation process) than installing everything.

• Another thing to know is that if backward compatibility is usually very good if not perfect, it is not unusual for minor differences to appear. Most of the time this has little to no impact, but in some rare occasions it can change the way a project file is interpreted by the editor, which can lead to necessary corrections or even re-building from scratch in the most extreme cases (e.g. new axioms appearing for no apparent reason OWL ontology import, which can be either harmless or terrible depending on the axioms). In such a case, it is always better to import only the main file (e.g. OWL file for an OWL ontology) instead of the project file. And if even then you cannot import correctly your work, you will have to keep working on your former version of Protégé or re-build from scratch your work in the new version (more than one version of Protégé can be run simultaneously, which helps tremendously in case you have to redo your work completely).

• Last but not least, it is obviously advised to save your work often, and to save it in different files as you work, so that if ever a save file was to become overwritten of corrupted, you would still have the others at hand. Of course, the versionning system built in Protegé can keep track of the changes (proviging you actually archive your versions in Protégé) but nothing is safer than using different names and thus separate files for all your (major) versions. One thing to remember is that it can be tremendously difficult if not impossible to restore an earlier state of an ontology you have been modifying because of the number of modifications whithin concepts and roles a single change can lead to. And Protégé is good at modifying ontologies from a given state, not undoing its own work.

Protégé-OWL

Important: Since version 3.2, the DLSyntaxDisplay option the OWL>preferences menu is bugged and may even lead to data loss! So if you want a DL-like syntax representation of restrictions on properties, select the CompactOWLClassDisplay instead. Else, keep the ManchesterDisplay, it is the safest of all. (A bug report has been sent to the Protégé-OWL team concerning these problems; but since Protege 3.2 the standard display is the Manchester one and debugging the other modes is not a priority so I highly recommend to stick to the Manchester for the time being. The problem should be corrected in the next version.)

• Installation : providing you will use Protégé only for OWL purposes, the best is to choose the "Basic + OWL" option during the installation of Protégé

• After a version change, it's safer not to load a project file (.pprj) but instead to rebuild a new project from the OWL file. If ever the loaded ontology is different in any way, check thoroughly if it is only harmless changes (e.g. a few new axioms added under things which can be removed without any other effect) or if it is serious in which case it will be safer to keep using a former version of Protégé (or redo your work from scratch on the new version).

• It is strongly advised to check the consistency of the ontology often. The first step is to use the 'run ontology tests' option in Portégé and the second and most important is to use the 'check consistency' option. However this consistency check requires you to have a reasoner with a DIG interface to work (e.g. RACER, FaCT++, Pellet) running at the same time. Furthermore, you will not be able to check the consistency of an ontology which uses a higher level of expressivity than the reasoner allows. Last, reasoners usually report the inconsistencies but usually do not explain exactly the problem, which is why it is better to use them often enough to know what changes may have implied a problem.

• If Protégé shows a different visual representation of the ontology or a different way of writing the restrictions than what you are used to see, you can select them to your taste using the OWL >Preferences menu

• Disjoints properties stay even if the concepts are defined later and/or the hierarchy modified (which can lead to inconsistencies). Furthermore, it is usually unwise to always add some disjoints between primitive concepts, for instance because the 'run ontology tests' suggests it in its results and offers to 'repair the items'. Indeed, depending on your ontology, some primitive concepts must not be disjoint from others! (e.g. the "______Component" in the astronomical object types ontology). And in general, it's unwise to use the 'repair item' of Protégé since the editor does not give the details of the modification he makes.

-- AlexandreRichard - 14 Jun 2006