This page is meant as an explanation of the NCI Protege Extensions, why they were implemented and what they do.
The Editor's Guide for the most recent version of the NCI Protege extensions can be found here. This provides the user with instructions on how to edit within the NCI Edit tab, how to do searches using the Advanced Search tab, how to handle workflow, pull reports, etc.
EVS Protege Extensions Introduction and History
Version 220.127.116.11 is the first public release of the EVS Protege Extensions. There have been multiple revisions released, tested and used internally over the past year. The current version is considered stable and reliable and suitable for external release.
These extensions were created in response to a need for an open-source editing tool that could be customized to the needs of the EVS content editors. In addition, EVS wanted the ability to exchange and share editable content with external collaborators. The Protégé editing tool, developed by Stanford, was used as the basis and extended to meet these needs.
The extensions are built on the Protégé 3.1 codebase and utilize pellet 1.5. Some improvements to the Protégé software were required to meet the needs of EVS, but these have already been merged into the Protégé trunk. Both Protégé and Pellet are included within the download. The Explanation Server was developed in collaboration with Clark & Parsia LLC.
The Protégé and the extensions are built and expect to run on Java 1.5.
EVS Protege Extensions packages
The EVS Protégé Extensions are broken into three separate packages. The Explanation Server provides classification and explanation functionality. The Protégé Server provides access to a central editing project for multiple users. The Protégé Client is the end-user application for accessing the Protégé Server and editing content.
The Explanation Server is used to do classification of the ontology and provide explanations on demand to the Protégé Client gui. It runs directly against the database, independently of the Protégé Server. The Protégé Server queries the Explanation Server for information when needed and controls requests for classification, so multiple clients cannot try and classify at the same time.
The Protégé Server provides multi-user access to a single ontology stored in a database. It coordinates and controls user activities and resource allocation. It stores a history of user actions for use in tracking changes and resolving conflicts. The server also provides a centralized means of enforcing business rules and configurations upon client applications. EVS has extended the Protégé Server to allow tracking of workflow and assigning of editing tasks.
The Protégé Client is a java-swing based gui used for editing an ontology. EVS uses the client to connect to the Protégé Server application, allowing multiple editors to share the same ontology. The Protégé client can also be used in standalone mode to edit a single ontology but some of the client-server specific extensions are then disabled. The client is used in standalone mode by managers to perform Prompt comparisons and terminology exports.
Protege Business Rules
The following are EVS business rules that the NCI Edit tab was programmed to enforce. These rules are a major reason why it was necessary to write an extension rather than using the default Protege editor.
Rules for Editing
Each concept must have one and only one NCI/PT Full-Syn
Each concept must have one and only one Preferred_Name
HD, AQ and PT are equivalent Full-Syn term types. (i.e. and NCI/AQ can take the place of a NCI/PT)
NCI/PT value must match the Preferred_Name
Properties cannot be duplicated within a concept
Roles cannot be duplicated within a concept
Role groups cannot be duplicated within a concept
Superclasses cannot be duplicated within a concept
The last superclass of a concept cannot be deleted
Cannot create a restriction pointed at a retired, pre-retired, or pre-merged class
If concept has Def_Curator property present, only authorized users can create, modify or delete the DEFINITION
If concept has Def_Curator property present, only authorized users can modify or delete the Def_Curator
Def_Curators must exist in a configuration file. No "dummy" Def_Curators
Each DEFINITION must have 1 review date, 1 review name, 0 or 1 attributes, and no source
Only single spaces allowed in a DEFINITION unless preceeded by !, ? or .
No leading or trailing spaces allowed in properties
Only single spaces allowed between tokens in properties (except for DEFINITION)
Properties cannot include the characters :,!,? or @ (except for DEFINITION which allows ! and ?)
Rules for Retiring
*Pre-retired concepts are retreed under the preretired_concepts bin *Pre-retire process forces dependant classes to be fixed (children retreed, incoming roles re-pointed) *Pre-retire concept must have and Editor_Note added explaining the retirement *Only the lead editor may do the final retire on a concept *Only the lead editor may edit retired concepts *Roles in the retiring concept converted to annotation properties called OLD_ROLE *Retiring concept deprecated using owl:deprecatedClass
*Pre-merge retiring concepts are double-treed under premerged_concepts bin *Pre-merge identifying properties (Merge_From, Merge_To) are added to the surviving and retiring concepts *Pre-merge retiring concept must have an Editor_Note added explaining the merge *Only the lead editor may do the final merge on a concept *Non-redundant roles and properties of the retiring concept are added to the surviving concept *Non-redundant incoming roles pointed at the retiring concept are re-pointed at the surviving concept *Roles in the retiring concept converted to annotation properties called OLD_ROLE *Retiring concept deprecated using owl:deprecatedClass