- Vocabulary service providers: Describes organizations currently supporting externalized API-level interfaces to vocabulary content for the caBIG® community.
- Vocabulary integrators: Describes organizations within the caBIG® community that desire to integrate new vocabulary content to be served to the caBIG® community.
- Vocabulary users: Describes the caBIG® community those interested in utilizing vocabulary services within the context of other caBIG® projects.
- Vocabulary authors: Describes the caBIG® community those interested in authoring vocabularies within the context of other caBIG® projects.
Overview of LexEVS Local Runtime
- Service Management consists of and an API and example programs to load, index, publish, and manage both vocabulary content and service metadata for the vocabulary server. Examples are found in the
admindirectory of the LexEVS root installation directory.
- LexEVS Application Programming Interface (API) is comprised of methods to support Lexical Operations, Graph Operations, Value Set Operations, Authoring Operations, and History Operations. Examples are found in the
examplesdirectory of the LexEVS root installation directory.
- Documentation consists of detailed JavaDocs and the LexEVS 6.0 Programmer's Guide and LexEVS 6.x Administration Guide.
- Automated Test Suite is provided to validate the LexEVS installation. It includes relatively small sample vocabularies that can be loaded by the user. These can be found in the
testdirectory and its sub-directory,
- Configuration and Resource Files provide custom configuration of the LexEVS runtime to users.
- Loading– Loading extensions to LexEVS accessed through a Service Management API that supply the following:
- Terminology Loads from various formats:
- Loading OWL, OBO, RRF and native LexGrid XML as well as less universal formats
- Examples Available in the
admindirectory: LoadOWL, LoadOBO, LoadNCIThesOWL
- Examples Available in the
- Manifest Loads that load Coding Scheme metadata changes to an terminology in the service
- Example: LoadManifest or as -mf option to most coding scheme loads.
- Supplemental Coding Scheme Loads that load supplements to existing coding schemes.
- Example: Load option for a coding scheme. Currently only available as an option in the lbGUI application.
- Revision Loads that load changes to any given coding scheme element using a LexEVS XML schema compliant document, pushing these changes through a revision engine.
- Example: LoadLgXML using the revision XML entry point to LexGrid XML.
- History Loads that load histories of coding scheme changes, currently specific to NCI Thesaurus and Metathesaurus.
*( Mappings between coding schemes loaded from MRMAP and MRSAT RRF files, or from LexGrid XML.
- Value Set and Pick List Loads:
- Examples: LoadLgXML using ValueSetDefinition or PickListDefinition as entry points in a LexGrid XML document.
- Examples: SourceAssertedValueSetDefinitionLoad
- Graphing Database loads for high speed resolution of terminology hierarchies and relationships
- Map Loads for mapping between terminologies.
- Example: LoadMrMap or LoadLgXML
- Exporting– Exporting any terminology in a LexEVS terminology service to one of three formats:
- Export to OWL
- Example: ExportOWL
- Export to OBO
- Example: ExportOBO
- Export to LexGrid XML
- Example: ExportLgXML
- Indexing– normally takes place during a terminology load, but re-indexing using the Service Management API is possible:
- Examples: RemoveIndex, RebuildIndex, BuildAssertedValueSetIndex
- Coding Scheme Metadata Management:Loading Manifests to adjust most elements of coding scheme metadata.
- Examples: See loading manifest for metadata changes above or examples ActivateScheme, TagScheme in the admin directory.
- Plug-in access:All plug-ins developed for LexEVS are accessed through Service Management.
- Examples: LexEVSService.getExtension(<plug-in class name>);
- Loader Preferences for entity(concept) loads– Customization of how entities are loaded allows users to make choices as to how a terminology appears in LexEVS.
- Available during load time only and as option -lp to most loaders
- Post Load Processing– Specialty processing options for post load, such as providing the approximate number of concepts examples in the source for the lbGUI application.
- Example for post processor implementation is in org.LexGrid.LexBIG.gui.load.PostProcessorLauncher using the LoaderPostProcessor class.
- Coded Node or Lexical Set Operations:Set operations for coded entities which group, query and apply set functions to sets of coded entries.
- Query Functions: Based on restrictions to a set of coded nodes retrieved from a given coding scheme a list of nodes is returned:
- Set Operations: sets of coded nodes have set operations performed upon them.
- Coded Node Graph Operations:Based on a set of restrictions, including types of relationships, a coded node graph is returned.
- Value Set Operations:Operations on Value Sets and Pick Lists.
- Source Asserted Value Set Operations: Operations on Value Sets Asserted in the Source Terminology
- Authoring Operations: Creating Coding Schemes and all subelments
- Mapping Operations: Creating mappings (a part of Coding Scheme creation)
Overview of LexEVS Distributed
(No longer available to the public as a service from NIH/NCI) It is still possible to run and install this service yourself, but it is being sunsetted as an application and will eventually be deprecated. See the CTS2 service below.
The Distributed LexEVS environment is distributed as a single WAR archive designed to be installed in a web application container.
- A Subset of the LexEVS API: Management, administration and authoring tools are not included for Java remote method invocation (RMI). Central querying functionality is the emphasis.
- Query By Example Querying Services (Deprecated - Removed in 6.5): A Java based version of the database querying interface that makes queries based on calls defined by LexGrid model elements.
- Web Services for SOAP messaging (Deprecated - Removed in 6.5, Replaced by the CTS2 Service): Providing a platform independent service to the database for LexGrid model elements to users of Perl, .net, C/C++, C#, Python and so on.
- XML-HTTP or REST Services(Deprecated - Removed in 6.5, Replaced by the CTS2 Service): Providing LexGrid Model query access to any user with a browser or browser like application.
The following figure shows SOAP via web services, Query by example, and XML-HTTP or REST Services grouped together, and Distributed Remote LexEVS JAVA API with Coded Node Set Operations, Coded Node Graph Operations, Mappings, and History.
Overview of LexEVS Graph-Resolve REST Service and NodeGraphResolutionExtension
Provides a graphing database REST Service wrapped by a LexEVS extension compatible API in java.
A SpringBoot enabled REST service queries an Arangodb instance for graph resolutions originally loaded from the LexEVS associations tables.
A set of methods designed to allow high speed resolution of larger graphs insuring a knowledge of graph resolution result sizes in a timely manner.
A REST service for Non-LexEVS users that provides a platform independent format for resolved graph elements.
Overview of LexEVS Grid Services (No longer available or Supported – Removed in 6.3)
Separate Analytical and Data Services are distributed in war archives for installation in web application containers.
Analytical Grid Service (Deprecated - Removed in 6.3)
Provides the same subset of the LexEVS APIs as the Distributed environment but is ISO 21090 compliant. The following figure shows the LexEVS Grid Service Java API with Coded Node Set Operations, Coded Node Graph Operations, Mappings, and History.
Data Grid Service (Deprecated - Removed in 6.3)
Allows users to make federated queries, using the CQL XML based query language, of LexGrid model elements hosted at LexEVS grid service nodes. The following figure shows a Federated CQL Queries element.
x CTS2 Specific Installations
LexEVS 6.1 features a CTS2 Compatible REST API. The REST server and an accompanying URI resolution service are installed to support this service.