Protege open source tool

Protege Protege is an open source ontology editor. Create new ontologies. Populate ontologies with concrete instances of classes. Execute reasoners that can perform inferences on an ontology i.

Technical Expertise Required:. Website for more information:. An essential goal of the system is to make knowledge browsing and entry as simple for users as possible. When the system generates a knowledge-acquisition tool from an ontology, users enter domain information by filling in the blanks of intuitive forms, selecting items from lists, and by drawing diagrams. We are currently working on providing support for the OWL language, which is a language designed for the next generation of the World-Wide Web—the Semantic Web.

There is an active discussion list with more than subscribers. National Center for Biotechnology Information , U. Natalya F. Musen , MD, PhD.

Author information Copyright and License information Disclaimer. Copyright This is an Open Access article: verbatim copying and redistribution of this article are permitted in all media for any purpose.

The taxonomy of Radlex is shown as an expandable tree on the left. The right panel displays the details of a RadLex term selected from the tree on the left. For example, the left coronary sinus has been selected left and it is a branch of the supraaortic valve area. The tree view of RadLex can facilitate the process of curating the terminology to find problems to be corrected, because the various hierarchies can be easily expanded and browsed to detect inconsistencies.

In this tree view, for example, we see that the supraaortic value area is a child of thoracic aorta Fig. The classes tab permits full editing of the ontology. In the tree view of the ontology on this tab, users can drag and drop classes to reorganize the hierarchy, create and rename classes using intuitive GUI paradigms.

The values for attributes of classes can also be directly edited. The slots tab enables users to view and edit all slots in an ontology; the instances tab displays all instances associated with the classes; and the forms view permits users to customize the layout of the elements on display forms. Ontologies change over time. They are developed iteratively, with incremental changes contributed by people working collaboratively on them.

RadLex will soon be releasing a new version, adding new terms as well as changes to the original terminology based on suggestions from users of the first version. There is a need to maintain and compare versions of ontologies, similar to the need for document version management in large projects. Document versioning systems enable users to compare versions, examine changes, and accept or reject changes. However, a versioning system for ontologies must compare and present structural changes rather than changes in the text of a document.

The results are presented to the users enabling them to view classes that were added, deleted, and moved. The users can then act on the changes, accepting or rejecting them. Suppose we edited a copy of RadLex to update it based on community feedback. Consider that we move the class supraaortic valve area and place it under the anatomic location class, and rename it to supraaortic area. In addition, suppose we create a new class noncoraonary sinus under supraaortic area, and that we update the Part-of relationship on supraaortic area to say it is Part-of thoracic aorta.

Displaying changes in PromptDiff. The output from PROMPT is shown in after comparing RadLex with a version of the terminology that was edited to move a class, change its name, and add a slot value. Left panel : Changes to the class hierarchy are shown. Different styles represent different types of changes: added class is underlined and in blue; moved classes are flagged out in their old positions and appear in bold in their new ones. Right panel : Individual changes to the slot values for a selected class are shown in this case, for the supraaortic area class.

In addition to viewing versions of ontologies, PROMPT also includes a tool to align two different ontologies to locate classes that are the same or similar to each other. Although an expandable tree is suitable for many ontologies and terminologies, it can be difficult to visualize those that have multiple types of relationships among the terms.

A tree shows the relationships among terms using one relationship usually the is-a relationship. RadLex contains several types of relationships, which are best shown using a graph Fig. Ontology classes are shown as boxes, and the relationships among them are shown as arcs. The label on the arc is the name of the relationship. The user can select the classes to be displayed in the graph lower left panel as well as the types of information to display, such as subclasses, superclasses, and relationships upper left panel.

This visualization paradigm is particularly helpful when an ontology contains more than one type relationship, since the tree view left only shows the ontology classes according to one relationship is-a. OntoViz produces its graphs using the Graphviz software package.

Unlike OntoViz, the user can dynamically navigate the ontology and interrogate each of its components in real time. This visualization paradigm makes the terminology display simple and intuitive. The graph is initially created by selecting a root class from the tree view upper left panel ; the root class is shown in the center of the graph right panel. Classes are shown as the names of the class, and the relationships between classes are shown as arcs, with the type of relationship appearing when the mouse passes over the arcs upper left part of graph in right panel.

Users navigate the ontology by double-clicking on a class name in the graph, which zooms into that class, producing a new TouchGraph rooted at that class. A key challenge for maintaining a large terminology such as RadLex is to collect and process the feedback from the large community of users.

The current model for feedback on terminologies and ontologies is for users to contact the developers or to post comments to online discussion forums. The problem with this approach is that the user feedback is disconnected from the ontology under discussion; it is difficult for the ontology developer to keep track of these discussions, to prioritize the feedback, and to decide which parts of the ontology need updated first.

A set of annotation components can be accessed by people viewing terminologies such as RadLex, enabling them to associate their comments directly with the parts of the ontology to which they apply.

Thus, for example, if a user noticed that there is a duplicate term in RadLex, that person could create an annotation on the class in question in which the nature of the problem is described Fig. At a later time, the RadLex curator can view the parts of the ontology for which users have made annotations, either acting on them or making annotations on the annotations themselves. All annotations can be viewed by the community as well, enabling a dialog on ontologies that is tied to the specific components under discussion.

This mechanism can streamline the process of acquiring and reviewing community feedback on ontologies. It also supports searching and filtering of user annotations based on different criteria. The RadLex curator can search, filter, and browse annotations created by the community, and create annotations serving as to-do items for incorporating changes and suggestions in future releases of RadLex.

This screenshot shows that the curator agrees with the user feedback and creates an annotation reflecting the need for the duplicate term to be removed in the next release of RadLex. There are also two types of voting mechanisms that can be used for voting of change proposals. All annotations made by one user are seen immediately by other users, enabling a community-based discussion about ontologies to be directly linked to the applicable portions of the ontologies.

To find these classes in RadLex, a program would be needed to traverse all classes in the RadLex ontology, looking for those that have missing values for the slots in question.

Thus, in our example above, we could perform the query to find classes having missing values for slots by entering a few lines of code into the Script Tab and viewing the results. An example of the output of a few simple commands entered into the Script Tab is shown in Figure 9. This screen shot shows some example interactive commands to the Protege API and their results. For example, if one wanted to use RadLex in a structured reporting application to enforce use of controlled terminology, it would be necessary for that application to access terms in the ontology.

In this section, we highlight an example application relevant to RadLex that was created in this manner—WebProtege. A large terminology such as RadLex needs to be both widely available and locally editable.

A common method for distributing a terminology is via the Web; however, once a user downloads the terminology, it will be become out of date as soon as a new version is posted. An alternative method for disseminating RadLex is to provide a Web-based program for viewing the terminology. However, because the version of RadLex that is deployed in the Web application is separate from the working draft, it is challenging to keep the development and production versions of RadLex tightly synchronized.

An approach whereby a single version of RadLex could be edited by curators and disseminated on the Web could be advantageous to make a current working draft available. The goal was to distribute Radlex in a Web application while providing the means to keep it synchronized with the version in development.