 |
Page History
| Scrollbar | ||
|---|---|---|
|
| Page info | ||||
|---|---|---|---|---|
|
| Section | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
- 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
LexBIG Architecture
LexBIG Services
This section describes architectural detail for services provided by the LexBIG system. These services are geared toward the administration, management, and serving of vocabularies defined to the LexGrid/LexBIG information model. A system overview is provided, followed by a description of key subsystems and components. Each subsystem is described in terms of its overall structure, formal model, and specification of key public interfaces.
...
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.
caGRID Hosting
The following figure shows the caGrid Hosting Environment. The Hosting Environment comprises the LexBIG Service which comprises the Service metadata, Query Service, Service Manager, and Extensions. A Service Discovery points to the Service Metadata component.
Service Management Subsystem
...
History provides vocabulary-specific information about concept insertions, modifications, splits, merges, and retirements when supplied by the content provider.
Common Terminology Services 2 (CTS 2) Architecture (Preliminary)
Structure of the Preliminary CTS 2 Service
The CTS 2 specification defines several functional profiles which are a focused subset of the functionality of a CTS 2 implementation. Functional profiles are defined to subset a group of operations which must be supported in order to claim conformance to the profile.
The following functional profiles are addressed by LexEVS 6.x:
Terminology Query Profile
- Searching and querying terminologies
- Provide access to terminology content and representational structures (description logic) consistent with the terminology author's intent.
Terminology Administration Profile
- Restricting administrative access
- Obtaining and loading terminologies
- Maintaining terminology access
- Control Content Access
Terminology Authoring Profile
- Functional terminology analysis/query
- Direct terminology edits
Each profile specifies the minimal functional coverage required to be provided by LexEVS.
- CTS2 Functional profiles: Query Profile, Administration Profile, and Authoring Profile.
- CTS2 STM Specific Methods: LexEVS Local Runtime, Distributed LexEVS, and LexEVS Analytical Grid.
LexEVS CTS 2 Services
The following figure shows the LexEVS CTS 2 Services.
LexEVS CTS 2 Services can be further categorized from the above profile details to include:
- Administrative Services
- Versioning Services
- Authoring Services
- Searching and Querying Services
- Association and Mapping Services
- Value Set and Pick List Definition Services
LexEVS CTS 2 API Architecture
The LexEVS CTS 2 API provides programmatic access to LexEVS 6.x implementation of the preliminary CTS 2 features and services. (For LexEVS 6.1 Query mechanisms have been implemented in REST based architecture and are fully compatible with the CTS2 Normative specification. This deprecates the work against the preliminary CTS2 SFM, but useful features for authoring and versioning have been left in place.)
Refer to LexEVS 6.0 CTS2 API for the documentation.
LexEVS API/Grid Service Interaction
LexEVS CTS 2 Services
Overview
The CTS2 standard is actually a collection of relatively small standards and a set of assembly rules.
The goal of the CTS2 standard is distribution and federation:
-Distribution means that different organizations can publish different aspects
-Federation means that organizations can share
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 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
See the LexEVS 4.2 Grid Service Design and Implementation.
| Scrollbar | ||
|---|---|---|
|
