Apelon DTS Distribution 3.5.1 API

Apelon DTS Components

See:
Description

Packages

com.apelon.apelonserver.client	The client side common classes provide a set of basic abstract classes that are used by application client side apis.
com.apelon.apps.dts.editor.modules	Provides the class and interfaces necessary for creating Plug-ins for the Apelon DTS Editor.
com.apelon.beans.dts.plugin	Provides the classes and interfaces that can be used to develop a plugin for the DTS Editor.
com.apelon.beans.dts.plugin.connection	Provides the classes and interfaces used in Connection Event notification.
com.apelon.beans.dts.plugin.subset.export	Provides the classes and interfaces for creating Subset Export Plug-in.
com.apelon.beans.dts.plugin.transferable	This package contains the Transferables used by DTS Beans in Drag and Drop.
com.apelon.dts.client	This package now consists primarily of deprecated classes maintained for compatibility with DTS 2.4.
com.apelon.dts.client.association	This package provides capability to work with associations between concepts, terms, or a concept and a term.
com.apelon.dts.client.attribute	Attributes are items of information attached to concepts or terms, or other attributes.
com.apelon.dts.client.classifier	This package provides API needed for classification of Ontylog Extension namespaces.
com.apelon.dts.client.common	This package provides a few common classes.
com.apelon.dts.client.concept	This package provides capability to access both Ontylog and thesaurus concepts in a DTS client application.
com.apelon.dts.client.events
com.apelon.dts.client.match	This package provides matching capability to flexibly search within predefined silos of data within the knowledgebase.
com.apelon.dts.client.namespace	This package includes classes for working with the namespaces (see Namespace) in a knowledgebase.
com.apelon.dts.client.plugins	This is the place to put plugin modules required by DTS.
com.apelon.dts.client.subset	This package provides the capability to access and manipulate subsets in a DTS client application.
com.apelon.dts.client.term	This package provides capability to access and manipulate terms in a DTS client application.
com.apelon.dts.common
com.apelon.dts.common.subset	This package has classes for working with subset data.
com.apelon.dts.common.subset.expression	This package provides classes for filters used in Subset Expression.

Apelon DTS Components

The Apelon DTS (Distributed Terminology System) is a client/server solution that enables delivery of concepts, terms, and relationships from Apelon knowledgebase’s to lightweight clients. The Apelon DTS is composed of the following components:

• An Apelon DTS Knowledgebase (KB). The specific healthcare terminology content included in any one knowledgebase is dependent on the needs and requirements of the particular customer.
• A highly concurrent and robust server that communicates with clients by using an XML-based messaging protocol. Application objects are loaded dynamically into the server as they are needed. The server supports logging and tracing, remote monitoring of load and thread use, connection statistics, and JDBC connection pooling to minimize resource use.
• Java-based client-side programming APIs that present an object-oriented view of the terminology knowledgebase. The API uses a hierarchy of classes to represent "concepts", "properties", "roles", "synonyms", and other abstractions.

The Apelon DTS Knowledgebase

A DTS knowledgebase (KB) is a collection of terminology objects called Concepts and Terms. Concepts are representations of logical entities (entities that have a single meaning, even though they may be called by different names). Terms designate a particular name for a concept. We can consider a Concept for which the meaning is that of heart attack. This Concept could have many names or terms ("heart attack", "myocardial infarct", "MI", "infarction of the myocardium") but they all refer to the same meaning.

DTS 3.0 introduces the idea of namespaces to organize terminologies that come from different vocabulary sources.

In Ontylog namespaces originally developed with Apelon's TDE (Terminology Development Environment) product Concepts are arranged formally in hierarchies; they have "higher level" or more general Concepts, called superconcepts, and lower-level, more specific Concepts, called subconcepts. Thus, our heart attack Concept could have a superconcept of the heart disease Concept, and a subconcept of the acute heart attack Concept. In DTS, Concepts can have multiple super- and subconcepts. This hierarchical arrangement of Concepts (known more formally as a "directed acyclic graph") is the backbone of an Ontylog namespace in a DTS KB. A second kind of relationship, which falls outside the hierarchy, is that of a Role. For example the heart attack Concept could have a Role with the name "is treated by," with a value that is the name of the Concept for the chemical nitroglycerin .

In thesaurus namespaces Concepts are arranged more informally with relationships, called Associations, between them that may imply a hierarchy ("Broader Than" or "Narrower Than", for example Biological Markers "Broader Than" Metabolic Markers) or describe some other relationship ("Onset", for example AIDS "Onset" Gradual Onset). Associations may also be added in DTS to an Ontylog namespace.

Besides their relationships with other Concepts, Concepts have attributes, which are name-value pairs associated with the Concept. Attributes can represent synonyms, codes, operational information, or any other characteristic of the Concept. There are two types of attributes in DTS, Properties and Synonyms. Properties are characteristics of a single Concept. For example, Reduction of fracture and dislocation may have a Property called "Semantic Type" with a value of Therapeutic or Preventive Procedure. Synonyms relate a Concept to a Term. For example, our heart attack Concept could have a Synonym of type "Entry Term" with a value of MI. One of the Synonyms can be designated as the Preferred Term.

DTS Editor Plug-in Framework

DTS Version 3.4 provides a framework for customizing or extending the capabilities of the DTS Editor. Using the Plug-in Framework, developers may create new plug-in ‘modules’ designed to interface and work with existing DTS Editor features. This provides the DTS developer the ability to provide targeted, custom functionality without having to spend time and effort developing a GUI and the supporting DTS connection framework. For more information, see the document Introduction to DTS Editor Plug-ins.

Server API (com.apelon.apelonserver package)

The Apelon DTS server side is provided by an application class called a QueryServer that is loaded dynamically into the ApelonServer framework when the server starts up. (Refer to the figure below for an overview of DTS data flow and package architecture.) Client API calls using the ServerConnection construct XML streams that are parsed by the server and appropriate methods are called in the application layer class. Results, usually from the knowledgebase, also are encoded in XML and passed back to the client side, where the appropriate objects are created from XML elements (Concepts, Properties, etc.).

The server is highly concurrent: it can support multiple simultaneous connections to client programs and to the underlying relational database (where the DTS KB resides). In addition to connection pooling for JDBC connections (which are the most resource intensive) all server side objects (including the threads) are pooled and reused in order to make minimal use of garbage collection. The number of database connections supported is configurable, as is the cache size and other parameters of the server. Log and tracing files can be specified, and users can customize the server by implementing their own reporting objects. The server also supports User Authentication for secure knowledgebase transactions. Further details on server startup and management parameters can be found in the DTS Server Operations Guide.

Programming with Apelon DTS

Apelon DTS provides an API to allow for development of custom applications that can make use of accessing information from a DTS Knowledgebase. Prior to beginning any development using the API it is suggested that the developer review the API documentation as well as the provided DTS Programming Tutorial .

Client API Overview (com.apelon.dts.client.* and com.apelon.apelonserver.client packages)

Important Note: The Apelon DTS API relies on the use of a SAX parser. When utilizing the DTS API for any program, the following argument must be specified when starting the JVM:

-Dorg.xml.sax.driver=org.apache.xerces.parsers.SAXParser

The client APIs present a rich collection of classes for accessing information from the server. The DTS client API classes which send concept-related queries to the server are:

• BaseConceptQuery
• DTSConceptQuery
• SearchQuery
• BaseOntylogConceptQuery
• OntylogConceptQuery
• NavQuery
• OntylogClassQuery
• MatchQuery
• ThesaurusConceptQuery
• OntylogExtConceptQuery
• SubsetQuery

A smaller set of query classes is for working with terms.

• BaseTermQuery
• TermQuery
• TermSearchQuery

BaseConceptQuery is the base class for many of the other query classes. BaseConceptQuery is used to fetch concepts and their attributes. You can fetch a single concept, or an array of concepts.

DTSConceptQuery can be instantiated to use the methods of BaseConceptQuery.

SearchQuery enables fetching of concepts based on matching an input string to concept names, property values, role values, synonym values, or concepts associated with a concept. It supports exact matching as well as matching properties over normalized forms (meaning that the words can be in any order). The property word searches can be configured with respect to which properties can be searched by editing a SQL script (setContains.sql) and running the kbadmin utility. (See the DTS KB Administrator Guide for details.) SearchQuery uses the DTSSearchOptions class for configuring searches.

BaseOntylogConceptQuery builds on BaseConceptQuery and adds methods that are specific to concepts in Ontylog namespaces. Role types can be retrieved using BaseOntylogConceptQuery.

OntylogConceptQuery can be instantiated to use the methods of BaseOntylogConceptQuery.

NavQuery enables the ordered tree-like traversal of a terminology hierarchy, beginning with the root concepts. For any concept, the NavQuery can obtain a NavParentContext that contains the concept's immediate parents or a NavChildContext that contains its immediate children. NavQuery also enables traversal of concept association chains. Since natural roots do not exist for concept association chains, a focus concept has to be specified to start the chain.

OntylogClassQuery provides answers to subsumption questions (e.g. is one concept a subconcept of another, or retrieve all subconcepts of another). DTS precomputes the transitive closure over each Ontylog namespace in the knowledgebase, optimizing the performance of these lookups.

MatchQuery provides pattern matching, normalized searches and searches with and without spell checking within prepared "silos" of terminology. It uses the MatchOptions class for configuring searches. To prepare the silos for access with MatchQuery, it is necessary to run the Selectors and Extractors utility. (See the DTS KB Administrator Guide.)

OntylogExtConceptQuery provides API that allows users to add defining concepts, roles to concepts in Ontylog Extension namespaces. This query also provides access by which Ontylog Extension concepts can be grouped or ungrouped and the concept status can be updated to be either primitive or defined.

SubsetQuery provides subset related query and edit methods by which a subset can be added or modified or computed (built) and or exported to a thesaurus namespace or to a file.

For further information on programming to the DTS client API follow this link to the DTS Programming Tutorial .