{scrollbar:icons=false} |
Author: Craig Stancl, Scott Bauer, Cory Endle |
The purpose of this document is to collect, analyze, and define high-level needs for and designed features of the National Cancer Institute Center for Biomedical Informatics and Information Technology (NCI CBIIT) LexEVS Release 6.4.
The focus is on the functionalities proposed by the stakeholders and target users to make a better product.
The LexEVS 6.4 Scope Document can be found here: LexEVS 6.4 Scope Document
The following sections specify how the design will satisfy the requirements for the Lucene search upgrade. This design reflects the wide ranging changes that will be necessary to LexEVS to fully update over three full releases of Lucene. Since Lucene is the heart of the search mechanism that powers efficient searches in LexEVS these changes are necessarily extensive. The focus of these changes can be broken down, to some extent, into three areas.
Some classes are called out to indicate the extent of the changes and to document some of the details of intended adjustments.
LexEVS Multi-index Lucene Implementation
LexEVS Lucene Relational Representation
LexEVS Per-segment Search Implementation
This update will be to Lucene 5.0. This version of Lucene has some backwards compatibility with Lucene 4.0 indexes. However it is completely incompatible with indexes versions 3.x and earlier. While LexEVS API's will maintain backwards compatibilities, any indexes from previous installed will have to be re-indexed in the latest implementation.
Lazy loading pagination is a broad concept in LexEVS and can encompass both graph and node set capabilities. Because this scope is large we are going to consider this out of scope for this project unless we can define a fairly narrow definition of what we want to do with Lucene's version of this. Currently some lazy loading occurs under the covers in the iterators returned by the coded node set implementation. We also have node graph pagination. In either case we may not need a reimplementation in order to update our Lucene implementation. We are suggesting this become a possible priority for a later implementation and won't fully describe how this might be done here.
Impact Description | Reference to documented impact |
---|---|
Text Matching Algorithm Changes. Support for a wide ranging text matching capability creates potential for heavy maintenance. We have attempted to characterize the similarities between some term matching implementations with an eye towards exclusion or combination. This exclusion and combination only affects end users if we remove labels as algorithm switches. | Not specifically impact documentation but a background document: LexEVS Text Match Algorithm Audit |
Reference: LexEVS 6.4 Software Design Document
Sign off | Date | Role | CBIIT or Stakeholder Organization | Approver's Comments (If disapproved indicate specific areas for improvement.) |
---|---|---|---|---|
Larry Wright | --- | — | — | --- |
Sherri de Coronado | — | — | --- | — |
Kumar Kuntipuran | --- | — | — | — |
Reference: LexEVS Text Match Algorithm Audit
Text Matching Algorithms to be continued: <list here>
Sign off | Date | Role | CBIIT or Stakeholder Organization | Approver's Comments (If disapproved indicate specific areas for improvement.) |
---|---|---|---|---|
Larry Wright | --- | — | — | --- |
Sherri de Coronado | — | — | --- | — |
Kumar Kuntipuran | --- | — | — | — |
Reference: LexEVS Code Decoupling
Sign off | Date | Role | CBIIT or Stakeholder Organization | Approver's Comments (If disapproved indicate specific areas for improvement.) |
---|---|---|---|---|
Larry Wright | --- | — | — | --- |
Sherri de Coronado | — | — | --- | — |
Kumar Kuntipuran | --- | — | — | — |