 |
Page History
| Scrollbar | ||
|---|---|---|
|
...
| Section | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
LexGrid is the model used to store terminologies. The LexGrid Model is Mayo Clinic's proposal for standard storage of controlled vocabularies and ontologies. The LexGrid Model defines how vocabularies should be formatted and represented programmatically, and is intended to be flexible enough to accurately represent a wide variety of vocabularies and other lexically-based resources. The model also defines several different server storage mechanisms (e.g., relational database, LDAP) and a an XML format. This model provides the core representation for all data managed and retrieved through the LexBIG system, and is now rich enough to represent vocabularies provided in numerous source formats including:
...
- Application Service Layer - accepts incoming requests from all public interfaces and translates them, as required, to Java calls in terms of the native LexEVS API. Non-SDK queries Queries are invoked against the Distributed LexEVS API, which handles client authentication and acts as proxy to invoke the equivalent function against the LexEVS core Java API. The caGrid and SDK-generated services are optionally run in an application server separate from the Distributed LexEVS API.
The LexEVS caCORE SDK services work directly against the database, via Hibernate bindings, to resolve stored objects without intermediate translation of calls in terms of the LexEVS API. However, the LexEVS SDK services do still require access to metadata and security information stored by the Distributed and Core LexEVS API environment to resolve the specific database location for requested objects and to verify access to protected resources, respectively.
- Core API Layer - Local Java API implementation that underpins all LexEVS API requests. Search of pre-populated Lucene index files is used to evaluate query results before incurring cost of database access. Access to the LexGrid database is performed as required to populate returned objects using pooled connections.
- Data Source Layer - is responsible for storage and access to all data required to represent the objects returned through API invocation.
...
- Clients: Local, Distributed, and caGrid clients, and SOAP, REST, QBE Clients.
- Application Service: CTS2 (LexEVS Local Runtime), Distributed LesEVS, LexEVS caCORE API's.
- Core API: LesEVS Model Objects Extended for CTS 2 = > DAO
- Indexes and Data Source: Lucene Index Files and LexGrid DB
- Optional Arangodb support for high speed graph resolution of terminology hierarchy and relationship graphs
LexBIG Architecture
LexBIG Services
...
LexBIGServiceManager - The service manager provides a centralized access point for administrative functions, including write and update access for a service's content. For example, the service manager allows new coding schemes to be validated and loaded, existing coding schemes to be retired and removed, and the status of various coding schemes to be updated and changed.
Service Management Subsystem
...
Lexical Set Operations provides methods to return a lists or iterators of coded entries. Supported query criteria include the application of match/filter algorithms, sorting algorithms, and property restrictions. Support is also provided to resolve the union, intersection or difference of two node sets.
...
Graph Operations support the subsetting of concepts according to relationship and distance, identification of relation related source and target concepts, and graph traversal. Additional operations include enumeration and traversal of concepts by relation, walking of directed acyclic graphs (DAGs), enumeration of source and target concepts for a relation, and enumeration of relations for a concept.
...
History provides vocabulary-specific information about concept insertions, modifications, splits, merges, and retirements when supplied by the content provider.
LexEVS CTS 2 Services
Overview
...
Key is that implementations can be shared – No one organization has to offer all services
Standards
XML Schema
...
- used for REST, SOAP and JSON formatting
...
- Includes item / directory / list
Functions
...
- Read
...
- Query
...
- Update
...
- Import and Export content
Component Standards
- Code System
- Code System Version
- Entity Description
- Association
- Value Set
- Value Set Definition
- Resolved Value Set
- Map
- Map Version
- Map Entry
- Concept Domain
- Concept Domain Binding
- Statement
Assembly Rules
•Each
- Each component can be implemented by itself or in conjunction with other components
- Components reference other components via:
- URI’s – if the referenced component is not known to the service
- HREF’s (optional) – if the referenced component IS known to the service
LexEVS CTS2 Documentation
Scrollbar
