Notice: This application will enforce Multi-factor authentication (MFA) for NIH users beginning the evening of Wed Aug 3rd.
NIH | National Cancer Institute | NCI Wiki  

Error rendering macro 'rw-search'

null

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Section
Column
width28%25%
Panel
titleContents

Table of Contents
maxLevel1
Column

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 1.2.3.25 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.

Explanation Server

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.

Protege Server

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. 

Protege Client

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

Retire

*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

Merge

*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