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:
A smaller set of query classes is for working with terms.
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
.