Near Term Task Recommendations

Harold Solbrig

Apelon, Inc.

February 14, 2007

# Introduction

This document describes and refines selected recommendations drawn from
the set of recommendations submitted previously as Deliverable 4.2 for
contract number GS-35F-0009L, *Review of NCI Thesaurus for
OBO-Compliance and Training to Help NCI Achieve Compliance*. The purpose
of this document is to identify the subset of the recommendations that
we believe should, and could, begin to be adopted in the near term in
order to assure the long-term viability of the NCI Thesaurus (NCIT) --
both in terms of meeting its own user requirements and enhancing its
ability to be integrated with other related projects such as the still
nascent OBO Foundry.

# Background

The NCI Thesaurus is designed, first and foremost, to be a *thesaurus*
-- "a controlled vocabulary arranged in a known order and structured so
that the various relationships among terms are displayed clearly and
identified by standardized relationship indicators." ANSI/NISO
Z39.19-2005, in turn, defines a *controlled vocabulary* as "a list of
terms that have been enumerated explicitly" and proceeds to assert that,
ideally, "all terms in a controlled vocabulary must have an unambiguous,
non-redundant definition." ISO 704 asserts, "The quality of most
terminological products will be determined by the quality of their
definitions." Recent critiques of the NCI Thesaurus serve to reinforce
this statement.

The Ceusters, Smith and Goldberg critique was based on revision 4.08b of
the NCI Thesaurus. At this point, the NCIT had 37,261 entries, 33720
(90%) of which were stipulated as being *primitive* -- with the result
that the textual portion of the entry was necessary to understand its
intent and meaning. The critique (correctly) focused on the
lexical-linguistic aspects of the thesaurus, noting, in particular that
"It is the \[concept system\] which forms the basis upon which concept
definitions rest. *Unfortunately, it is very difficult to perform an
in-depth analysis of the NCIT concept system, precisely because of the
many ambiguities at the level of its terms and definitions.*" And
"...one can in many cases only speculate what the real entities are that
are supposed to qualify as instances for the concepts which are
included."

While NCI Thesaurus is beginning to "exhibit ontology like properties"
and is "shifting from being a controlled terminology toward what today
is often called an ontology", we believe that its primary role in the
near term remains that of a bridge for human to human communication
across specialties and data resources. Until it is possible to convey
the intent and meaning of a term or phrase between humans, it is
premature to attempt to encode the same information in a machine
readable form. To this end, we believe that the NCI Thesaurus should
focus on improving the quality of its lexical-linguistic content --
specifically, its terms, synonyms, definitions and corresponding
annotations.

As of early 2007, release 06.12d had grown to 55,826 active entries,
45,736 (82%) of which are still marked as being primitive, i.e., only
partially defined from the description logic (DL) perspective. Of the
45735 primitive entries, 24651 (54%) lack a primary definition, although
curiously, 6871 of these primitive entries *do* have an alternate
definition. Even when we take these into account, this still leaves us
with 17780 entries (39% of the primitive entries or 32% - one third - of
the entire thesaurus) that are *completely undefined*. While the
preferred terms, synonyms and taxonomic content obviously provide some
idea of the intent, the purpose of a thesaurus is to arrive at fixed
definitions -- to be something more than just an (organized) list of
words. Considering that the stated intent of the NCIT is to be
cross-disciplinary, it is highly unlikely that these words are going to
have obvious, single meanings to all of their potential consumers.

When one examines the entries that do have definitions, the quality
varies greatly. A random walk through the thesaurus quickly reveals many
examples of the sort discussed in the 2005 Ceusters paper. The first
entry that we selected randomly, "Rat Nervous System and Sensory Organs
Neoplasms" has no definition and has a semantic type of "Neoplastic
Process". Its ancestor "Rat Disorder By Site", also lacks a definition,
but has a semantic type of "Classification". Following the inheritance
chain up, we reach "Rat Pathologic Diagnoses" which is undefined and
then to "Experimental Organism Diagnoses", which, while still primitive,
at least has a definition - "Any abnormal condition that causes
discomfort, dysfunction, or distress to the affected organism. Used
broadly to include injuries, disabilities, syndromes, symptoms, deviant
behaviors and atypical variations of structure and function." The
preferred term is in the plural, which implies that we are describing a
set rather than an individual. Even when substituting the non-preferred
term (display name) of Organism Diagnosis, the definition is somewhat
nonsensical -- "An organism diagnosis is any abnormal condition that
causes discomfort, dysfunction, or distress to the affected organism."
And "An organism diagnosis is used broadly to include injuries,
disabilities, syndromes, symptoms, deviant behaviors and atypical
variations of structure and function." Putting this all together, we can
conclude that "Rat Nervous System and Sensory Organs Neoplasms" is some
type of abnormal condition and are used broadly to include injuries,
etc."

While the above example may be viewed as nit-picking, the point we are
trying to make is either (a) the NCI Thesaurus is a hierarchically
organized collection of words and phrases, the meaning of which is
obvious to all who encounter them or (b) the NCI Thesaurus is an
artifact to precisely and unambiguously fix the *definition* of the
specialized words and phrases of a subject field or discipline for
cross-disciplinary communication -- be it spoken, written or contained
in databases. Any more ambitious goals such as computational reasoning
and inference will depend on the quality of the baseline resources.

Definitions and terms are the primary elements of any thesaurus. Given
correctly formulated definitions and the appropriate background
material, it is possible to validate or reconstruct a close
approximation of a formal representation of the Thesaurus content for
the appropriate machine processing tasks. The DL portion of the
Thesaurus cannot, and should not, be depended solely upon as a mechanism
for human comprehension of the thesaurus content. Even under the most
rigorous circumstances, the DL is generally only an approximation of the
actual intent of the thesaurus -- an approximation meant to be navigated
by software. The quality and usability of a thesaurus is determined
largely by the human language portion -- the quality of the terms,
definitions and links. Given that the DL portion of the NCI Thesaurus is
primarily designed for organization and validation, this becomes even
more critical. *The [meaning]{.underline} of the thesaurus cannot be
only embedded in the computational portion*.

# Recommendations

The NCI Thesaurus is obviously a work in progress, so any recommendation
needs to encompass both a proactive and retroactive component. Each of
the recommendations below start with a description of the goal and
motivation behind the recommendation and are then followed by the
outline of a possible approach that could be put into place that would:

\(1\) Establish an environment where ongoing (proactive) terminological
work could begin to occur using the new process and

\(2\) Provide a mechanism where the existing Thesaurus content could
gradually be transformed in accord with the new process.

Note that the approach component describes *a* possible approach. There
may be alternative approaches to accomplishing the same goals that would
be equally viable, and the details of such suggestions will obviously
have to be integrated with the NCI workflow and resources.

## Recommendation 1: Separate organizational nodes, common words, thesaurus concepts and external references.

### Description

The NCI Thesaurus consists of at least four different categories of
entry:

1)  *Navigational nodes* -- entries that are used to organize and
    navigate the contents of the thesaurus

2)  *Common words* -- entries that are simply words drawn from a
    vocabulary of everyday usage

3)  *Thesaurus concepts* -- entries that represent the classes
    (concepts) used by one or more of the specialized fields or
    disciplines covered by the thesaurus

4)  *External references* -- references to entries in external
    terminologies or ontologies.

It is important to begin the process of distinguishing these categories
as they each play a different role in the NCI thesaurus and, as a
consequence, have different requirements when it comes to formal
logic-based reasoning, definitions, etc. The following paragraphs
describe some of the characteristics of each type of node and contain
recommendations about how each category should be organized within the
Thesaurus itself

**Navigational nodes** -- navigational nodes are used to organize and
navigate the thesaurus content. Navigational nodes form arbitrary groups
of thesaurus entries through the use of disjunctions (Diseases
[or]{.underline} Findings), organizational characteristics (Proteins
organized by Function), purpose (NCI Administrative Concepts), etc. The
key to recognizing navigational nodes is the fact that they don't have
any "identity" characteristics -- the "children" of navigational nodes
are not themselves real world *specializations* of the navigational
concepts. An instance of a chaperone protein, for instance, is not
itself a kind of "protein organized by function", nor is a data element
an NCI Administrative Concept.

It is important to separate navigational nodes because they do *not*
properly participate in the definitional component of a DL hierarchy.
Many of the issues involving definitional clarity, classification in a
subsumption hierarchy, etc. are either irrelevant or of considerably
lower priority for navigational nodes. Recognizing and isolating the
navigational nodes should simplify the task of maintaining the Thesaurus
because navigational nodes are arbitrary and, as such, do not require
the sort of rigor and scrutiny that needs to be applied to full fledged
thesaurus concepts.

**Common words** -- words such as "absolute", "aliquot", and "pathway"
can be found in many places throughout the thesaurus, although they are
primarily found under the "Properties or attributes" and "NCI
Administrative Concepts" organizational nodes. These entries appear to
serve two purposes:

1)  To provide particular senses of a definition -- to clarify how the
    particular word is, or at least should be (!) used throughout the
    rest of the thesaurus

2)  To provide a codified word list for data entry purposes.

Both of these use cases are important, but it needs to be recognized
that these are *words*, not *classes* whose instances are defined by the
thesaurus itself. Words should not be (and, by and large, are not)
included within the rest of the thesaurus structure itself. In some
cases, it may make as much sense simply to omit the word completely.
Does having a definition for "absolute", for instance, really add any
information to the Thesaurus that couldn't be acquired from a common
dictionary? In other cases, it may be important to keep the words for
the reasons stated above. In these cases, the word definitions may or
may not be included in the thesaurus itself but, in all cases, they
should be drawn from an external resource such as WordNet, an
authoritative dictionary, etc. The external reference should be
maintained in the thesaurus via a pre-specified property and the
definitions should *not* be subject to editing within the thesaurus
itself.

**Thesaurus Concepts** -- this is the "meat and potatoes" of the actual
thesaurus. A thesaurus concept represents a class of entity that exists,
or is posited to exist in the real world. A thesaurus concept serves two
complementary purposes:

1)  **Naming -** given an instance of some real world entity or event,
    the thesaurus allows a user to determine whether or not it is an
    instance of a given class named and defined by the thesaurus

2)  **Inference** -- given the assertion that some real world entity or
    event is an instance of a given class, what else must (or might) be
    true about the entity being observed?

To date, the primary focus of the NCI Thesaurus has been on naming,
which allows the information contained in forms, data bases and other
computerized media to be consistently and, to the extent possible,
unambiguously named.

In the future, however, it is obviously (and correctly) the goal of the
NCI to begin to utilize the inferencing as well. The value of this
second purpose depends, however, on how successful the naming has been.
It does little good to reason about the characteristics that can be
inferred about an antigen, for instance, if people don't have a clear
and shared understanding of what an antigen is to begin with. Similarly,
there is no way to verify that the inference component is correct and
complete if the people doing the verification don't have a correct and
consistent idea of what it is that is being verified.

**External References** -- the NCI Thesaurus cannot (and should not
attempt to) define every class or concept in the field of bioinformatics
and cancer research. We believe that the primary role of the thesaurus
should be to serve as an organizational resource that enables consistent
naming and, eventually, reasoning across the spectrum of cancer related
bioinformatics. Systems of "thesaurus concepts" are being defined in a
number of communities (e.g. FMA, Gene Ontology, Mouse Anatomy, etc.),
and, where the content and quality of these resources meet the NCI's own
needs, these resources should be *referenced* rather than re-defined.
External references are, first and foremost, *external*. While it may be
useful to copy part or all of the content of the external resource into
the thesaurus, it needs to be recognized that what is in the thesaurus
is exactly that -- a *copy*. External references need to carry a link to
their source, ideally in such a way that any information that has been
copied can be periodically verified and updated if appropriate. External
references should be treated as "read-only" -- they should not be
allowed to undergo local change.

In the longer term, it will become important to assure that external
references subscribe to the same degree of consistency, quality checking
and shared semantics as the NCI Thesaurus itself. This, in no small
part, is what the NCBO/OBO Foundry project is about. In the near term,
however, the important thing is to (a) identify external references and
(b) include them in such a way that they are not absorbed into the
NCI-created content of the thesaurus itself, but remain as references.

**Approach**

1.  Assign separate branches (kinds) in the thesaurus -- one for
    navigational nodes and one for common words.

2.  Create associations to reflect the thesaurus-specific organizational
    terms -- broader "term", narrower "term", "use", "see also", and
    others as needed to allow organizational entries to reference other
    terms in the thesaurus.

3.  Use the sample subset and additional nodes as needed to validate and
    solidify the relations and tooling to support this approach.

4.  Once validated, adjust the curation process to include the entry
    categorization step in all future entries introduced into the
    Thesaurus.

5.  Initiate a process to systematically pass over the thesaurus
    content, categorizing the elements into one of the four types listed
    above:

    a.  Integrate thesaurus nodes within the navigational hierarchy
        using the associations in step 2 to link them to other thesaurus
        entries.

    b.  Remove unneeded or unambiguous words from the Thesaurus
        completely

    c.  Move needed words to the word branch of the thesaurus and assign
        an appropriate definition reference. Unlink the words from any
        hierarchy or roles that they may currently be participating in
        in the Thesaurus itself. Verify that word/word associations are
        reflected in WordNet and, if they are, assume that they are
        common knowledge. If any associations remain, determine whether
        they are necessary. If so, reconsider the classification of the
        entry as a word. If not, discard them.

    d.  Rejoin the remaining definitional hierarchy (DL taxonomy) by
        splicing around the missing terms.

    e.  Begin to mark external ontology references as such, providing a
        computable link to the external resource and importing the
        resource content (making it read only).

## Recommendation 2: Provide structured definitions for (almost) all [thesaurus concepts]{.underline}.

### Description

Any thesaurus concept that is marked as "primitive" is at least
partially dependent on the lexical-linguistic component (e.g. terms,
definitions, etc) for an understanding the intent of the entry. Even
when description logic (DL) components are specified, their principal
current purposes are validation and organization, and they are *not*
intended to be the primary source of meaning for the content of the
thesaurus itself. With the possible exception of faceted classifications
(as typified by LOINC and anatomical constructs) all thesaurus concepts
should have a structured, human readable definition. As advised in ISO
704, these definitions must, first and foremost, meet the needs of the
thesaurus and should be "adapted, not adopted" in almost every case.

Structured definitions serve as the bridge between meanings that are
understood by human beings and computational resources. Structured
definitions can be validated by subject matter experts to make sure that
they accurately and completely reflect the intent of a term or phrase
within their domain of expertise. Structured definitions can also be
validated by ontologists and description logic experts to verify that
they are accurately and completely reflected in a formal computational
language. Structured definitions allow a "loose coupling" between the
thesaurus and computational aspects, which allows the expressivity of
the computational component to be determined without restricting what
can and cannot be said in the thesaurus itself.

Without structured definitions, the thesaurus is far more likely to
become a brittle and/or ambiguous system. Simple terms and borrowed
definitions vary widely in their intent and quality, which subjects the
content of the Thesaurus to the nuances and ambiguities of everyday
language. Dependency on the description logic (DL) component, however,
potentially restricts what a subject matter expert is able to say about
a given entry, and the introduction of new logic capabilities will
require the re-engagement of the same experts to add the additional
information that previously couldn't be said. Structured definitions
allow *all* of the defining information to be recorded even when only a
subset of the information can be recorded in the formal logic.

*Note: this process is equally applicable to instructions, annotations,
etc. We are focusing on definitions because we see it as the critical
component in the near term.*

**Approach**

Note that this process applies strictly to *thesaurus concepts* --
navigational nodes, common words and external references should be
isolated and treated according to recommendation 1 above.

1)  Review the NCI Guidelines for name and synonym formation, augmenting
    and enhancing it with the recommendations supplied in the
    Requirements Detail spreadsheet supplied in Deliverable 4.2 from
    this project.

2)  Review the thesaurus curation process to determine what needs to be
    done to assure that these guidelines are easy to use and are
    consistently followed. Would NLP tools such as word stemmers and
    morphological analyzers be useful? Would semi-automated checklists
    be of value? Getting this step right is vital to the functioning of
    the rest of the process, as a poorly formed name has a high
    likelihood of skewing or distorting the intent of the entry.

3)  If the preferred name or synonyms have changed, re-determine that
    the entity is still a thesaurus concept, not one of the categories
    above.

4)  Record the resources that are used (people, books, online
    resources); formulate a *structured* definition following the
    guidelines listed in the "Definitions" tab of the requirements
    spreadsheet. Whenever possible, the resulting definition should
    match the form:

> Every [*entry* *preferred name*]{.underline} is a kind of *parent
> [preferred name]{.underline}* that *[relationship]{.underline}*
> *[target preferred name]{.underline}* and (or) *[another
> relationship]{.underline}* *[another target preferred
> name]{.underline}* ...
>
> While the syntax of this form can be subject to minor variation, the
> Aristotelian form of the definition should be preserved.

5)  Record the entry in the thesaurus using markup that approximates the
    following (the exact format will be determined later):

> A(n) \<superclass\>*parent preferred name*\</superclass\>
> that/what/... \<definingRole\>\<rel\>*relationship preferred
> name*\</rel\> a/an/... \<target\>*target preferred name\</*
> definingRole \> and/or \< definingRole \>\<rel\>*anogher relationship
> preferred name*\</rel\> a/an/... \<target\>*another target preferred
> name\</* definingRole \>
>
> The tags, which potentially could be drawn from ISO TC 37, are
> intended to record the following information:
>
> \<superclass\> - this can be used to create/verify the asserted
> superType of the entry being defined. It (a) validates that the link
> is as defined and (b) validates that the preferred name of the
> supertype is correctly formulated.
>
> \< definingRole \> - this is a role that is formally defined -- we may
> want to play with additional markup to disambiguate what it points at,
> but it should reference a formal role as defined in the thesaurus and
> the preferred name for the role should make sense.
>
> \<target\> - this should match the preferred name of a thesaurus
> concept that is also the target of the corresponding role

6)  Create and incorporate software that allows the above definitions to
    be displayed strictly as text, as text with markup (a variety of
    formats may be useful such as coloring, etc) and can also be used to
    validate formal DL definitions of the concept

## Recommendation 3: Separate the definitional characteristics in the DL from the "knowledge" characteristics and restate or remove all characteristics that can't be fully represented in the DL

### Description

A *structured definition*, as described in Recommendation 2 above,
contains only the characteristics that are needed to define the intent
of the concept itself. As described further in the Definitions tab of
the requirements spreadsheet, it shouldn't contain embedded definitions
or additional characteristics that, while interesting, don't serve to
identify the concept itself. As an example, the fact that a given drug
has FDA approval to treat a particular disease is largely irrelevant
when attempting to determine whether one does or does not have an
instance of the drug itself. Of course, such information can be retained
as annotations which supplement the definition itself*.*

Currently, the NCI Thesaurus does not distinguish between defining roles
and the (debatable) use of roles for non-definitional purposes. In
addition, the Thesaurus sometimes attempts to record relationships that
have semantics that not expressible in the particular description logics
under consideration. Both of these issues need to be addressed before
the NCI Thesaurus can be either verifiable or correct.

Non-definitional roles include relationships like
"Gene_Is_Biomarker_Of", "Disease_May_Have_Normal_Cell_Origin", etc. --
relationships that, once you know you've got a gene or once you know you
have a disease, provide additional useful information, but do not
*define* the gene or disease in question. While the information from
these sorts of things is quite useful, they may well confuse the
classification and definitional process.

Knowledge that cannot be expressed in the semantics of the description
logic -- be it Ontylog, OWL, or something else, should not be forced
into that DL. The logical definition has to be stated as a definition --
not just a snippet of logic. Attempts to circumvent the limitations of a
given logic system may result in assertions that are incorrect and
potentially dangerous. Take, for example, the entry "Lipomatosis" which
contains the assertion:

"*all* Disease_Excludes_Abnormal_Cell Neoplastic_Lipoblast"

The presumed intent of this statement is to say that Neoplastic
Lipoblasts are *not* included in the definition of Lipomatosis. What is
actually being asserted in the DL, however, is that any *instance* of
Lipomatosis must exclude at least one *instance* of Neoplastic
Lipoblasts, if it excludes any abnormal cells at all. It would be
entirely consistent were I to have a case of Lipomatosis that consisted
entirely of Neoplastic Lipoblasts as long as either (a) my case didn't
exclude any abnormal cells or (b) my case excluded at least one
Neoplastic Lipoblast somewhere.

Another question that arises with the above statement is the intent of
the *all* quantifier. Take a second assertion about "Lipomatosis", which
asserts:

"*all* has_abnormal_cell Neoplastic_Lipocyte"

The strict interpretation of this statement would be, for any instance
of Lipomatosis, if it has any abnormal cells at all, then all of them
will be instances of Neoplastic Lipocyte. Is it the intent of the
authors that it is possible for instances of Lipomatosis to exist
without any abnormal cells at all?

While both OWL and trial versions of the Apelon classifier do support
the forms of negation that would allow the first statement above to be
expressed correctly, and the ambiguity of the second statement would be
removed if we could be certain that the authors intended to omit a
second "*some*" quantifier, the message remains the same:

(1) The complete definition and associated annotations should always be
    represented in the textual portion of the concept.

(2) Only the components definitions that can be adequately be
    represented in the DL section should be recorded there.

It makes perfect sense to assert that "A Lipomatosis is a kind of benign
lipomatous neoplasm that is made of any type of neoplastic mature
adipocyte, but specifically excludes neoplastic lipoblasts" (at least I
assume so -- I'm not a doctor), but it *doesn't* make sense to attempt
to express this phrase formally in the description logic used today. If
you record this fact, however, it can be formally encoded at a later
date without having to refer back to the original author.

**Approach**

1)  As structured definitions are created, compare the supertypes and
    role relations with the asserted (*not* inferred) DL hierarchy.

2)  Double check any roles and supertypes in the DL hierarchy that
    aren't included in the definition itself and:

    a.  Add them to the structured definition if they are a part of the
        definition

    b.  Change them to associations if they are informational rather
        than definitional.

3)  *All* role names that involve negation (not, excludes, etc.) should
    be moved to the associations section (or removed?) -- pending use of
    a richer description logic such as OWL or the trial version of
    Ontylog -- whether they appear in the structured definition or not.

4)  (Future) all roles now in the association section that don't occur
    in the definition should be given corresponding textual annotations
    reflecting the same information.

# Summary

The future of knowledge integration, federation, and reasoning clearly
lies with computable resources where the underlying definitions and
knowledge are accessible via computable, logic-based resources. Getting
to this point, however, is dependent first on the ability to record the
definitions and knowledge content of a subject area in a precise,
unambiguous fashion -- one that is both accessible and verifiable to
subject matter experts and computer and logic experts. The NCI Thesaurus
is positioned to serve a key role in this process if it can continue to
focus, first and foremost, on its role as a *thesaurus*. To this end, we
recommend that the NCI focus, in the near term, on strengthening and
formalizing the thesaural aspects of its products by: (a) separating the
formal thesaurus content from navigational nodes, everyday words, (b)
identifying external references and treating them as read-only
resources, (c) following a methodological process for constructing entry
names, (d) creating structured definitions to bridge the human/computer
boundary and (e) treating the description logic (DL) resources as a
supporting image of the knowledge, refraining from attempting to record
information in the DL that it is unable to correctly represent.

# Appendix A: Term Selection

Terms should be differentiated according to their purpose:

1)  Primary term (primary name) -- this will be the term that will be
    used to designate the thesaurus entry under most circumstances

2)  Secondary terms -- these are alternative terms that can also be used
    to designate the entry in special contexts and situations. While
    these are often referred to as "synonyms" it should be understood
    that both true-synonyms and near synonyms as well as variants such
    as acronyms, abbreviations, etc. also belong in this category.

3)  Index terms -- these are terms that have an association with the
    conceptual entry, but should not be used to represent it. This
    category includes a wide variety of things such as "generic
    postings" (terms that are narrower than the preferred term, but
    aren't being included as subtypes), deprecated terms, etc.

Note that the entity entitled "Concept Name" in the current thesaurus
implementation should *not* be considered the preferred term. We have
noted that there is a drift in meaning between the terms used to
identify the concepts and the preferred terms and recommend terms such
that either:

(a) the concept names be updated to more closely reflect the preferred
    names (which may not be possible if any secondary resources are
    using the name as a unique identifier) --or-

(b) Browsers and other software should be changed to show preferred
    names rather than formal concept names.

### The Preferred Term

The preferred term (preferred name) is used to designate the thesaurus
entry under most circumstances. It must be as transparent and
unambiguous as possible, and the following criteria need to be taken
into consideration:

1)  **Concise** - The preferred name should be as concise as possible.
    Avoid lengthy and drawn out phrases.

2)  **Unambiguous** - The preferred name should be unambiguous *within
    the subject area and context of use*. While, ideally, a preferred
    term would have exactly one meaning within the context of the whole
    thesaurus, this is not always possible. There will be cases,
    however, where more than one thesaurus entry will have the same
    preferred name. When this is the case, do not use suffixes,
    parenthesized contexts or other mechanisms for disambiguation.
    Instead, be certain that each overlapping name has a secondary
    annotation that can be called on for disambiguation when
    appropriate.

3)  **Transparent** -- A preferred name should be selected that clearly
    represents the intent of the thesaurus entry in the broadest
    possible community. Avoid acronyms, abbreviations, eponyms, etc.
    unless they are widely recognized and accepted

4)  **Widely accepted** - Preferred names should be used and widely
    accepted within their community of interest. When in doubt, search
    Google, Medline or another appropriate resource and be highly
    suspicious of terms or phrases which get few hits.

Warning: generic postings (terms that are narrower than the preferred
term, but aren't being included as subtypes) should be clearly labeled
and used with caution. They should only be used in "leaf nodes" and
strong consideration should be given to using subtypes as an alternative
whenever practical.

### Term Annotation

1)  Where appropriate, identify the relationship(s) between a secondary
    term and the *preferred name*. Examples include

    a.  Exact synonym (SY)

    b.  Near synonyms

    c.  Lexical variants

    d.  Generic posting

2)  Identify and label term usage

    a.  Identify and label deprecated or not widely accepted terms

    b.  Identify terms that are mandated by external organizations and
        include a reference to the organization that is mandating the
        term

    c.  Identify the user community and usage context for terms that
        have the potential to mean different things in different
        contexts

Additional information about term formation can be found in the
"Designations and Notes" tab of the Requirements Detail spreadsheet.