\section{Introduction}

The Hidden Markov Model Processing Resource(PR) has been developed
by the Ontotext Lab (www.ontotext.com) to solve information
extraction tasks. The PR's behaviour is based on learning from
annotated documents and afterwards annotating documents with
annotation types that are most likely according to the training
examples. The training data could be either manually annotated by
users, or automatically annotated by other processing resources.

To start with we need to train the PR over a corpus of documents
in GATE. We first have to provide the documents, and the
annotations over which the HMM PR should be trained. The training
phase of the PR follows. After this, the resulting internal
state/model of the HMM can be saved. Later, this trained model can
be loaded and used to start the annotation over the same or a
different set of documents. Finally we can measure the performance
of the HMM-generated annotations or use the resulting annotations
with another PR.

We have already provided a trained HMM model as part of the
musehmm application. That model was trained on a corpus of
business and political news articles, consisting of 210 documents
collected from the Web sites of three UK daily newspapers -
Guardian, Financial Times, and the Independent. They have been
manually annotated with named entity information and some of them
have been provided as part of the muse corpus.

Some terms used below are:
\begin{itemize}
\item Label - named entity, actually an annotation type used in the
HMM model to describe the input data for HMM PR train and
annotate.
\item State - named entity, actually an annotation type used in
the HMM model to describe the input/output data for HMM PR
     training/annotating.
\end{itemize}

\section{Running the MuseHMM application}

The MuseHMM application (musehmm.gapp) can be loaded and executed
in the GATE GUI or in any Java program as described in earlier
chapters.

The results of the application are the named entities recognised
in the text. Those named entities which are harder to recognise,
i.e., Person, Location, and Organization, have confidence scores
attached to them as features (called \texttt{hmm\_confidence}).


Since some of the JAPE rules used in this application
overgenerate, i.e., assign more than one type of annotations when
there is ambiguity, this application produces in some cases
overlapping named entities of different types and with different
confidence scores. For example, when the JAPE rules encounter
``Upmarket'' in the text, they cannot disambiguate it, so it is
assigned annotations of types Location, Organization, Person, and
NotName. The latter type is there to allow the HMM model to assign
highest confidence score to indicate that this might not be a
named entity of the kinds we want to recognise. All four
annotations will have different confidence measures and a
subsequent Processing Resource can remove such competing
annotations and just leave the one with the highest confidence
score. All other named entities which have only one type assigned,
i.e., no overlapping annotations of different NE types, will not
be affected. As can be seen in Figure
\ref{fig:hmm-example-output}, indeed the annotation type with the
highest confidence score is NotName (the top four annotations in
the annotation table). The figure also shows the confidence scores
assigned to some other named entities (e.g., Baron Philippe
Rotschild), which do not have competing types because they have
been recognised by an unambiguous rule.

Further processing is possible, so that annotations which have
very low confidence scores are removed by another PR, which simply
deletes all NE annotations with hmm\_confidence value below a
given threshold.

\begin{figure}[tbp]
\begin{center}
\includegraphics[scale=0.5]{hmm-output-example}
\caption{Example HMM Output} \label{fig:hmm-example-output}
\end{center}
\end{figure}


\section{Changing the parameters of ApplyHMM PR}

On creation of the Apply HMM PR, the URL of a trained model should
be selected. If a configuration file without a saved model has
been selected, there will be no error message, but instead random
annotations will be generated. A configuration file has a trained
model in it, if it has $<$MODEL$>$ tags with data between them.
The trained model on the news corpus is supplied in
muse/applications/hmm/config\_muse\_not\_name.xml.

The ApplyHMM PR adds GATE annotations or confidence features to
existing annotations, and this forms the result of this phase.
Since there is more than one known algorithm for annotation, the
user is able to manage the choice of algorithm. The parameters
specifying the annotation algorithm are entered in the options
runtime parameter of the Apply HMM PR. The parameter's processing
is case-insensitive. The possible parameters are:
\begin{itemize}
\item
     VITERBI - Starts the classical VITERBI algorithm for HMM. Minimizes the per-document error.
\item
     GATE - assigns confidence features to the existing annotations.
\item
     GATEVITERBI - the same as GATE + usage of VITERBI algorithm.
\item
     (DEFAULT) - gamma maximization - another approach to annotation used in HMM is
     the minimization of the per-token error. Gamma
     maximization performs this task.
\item
     THRESHOLD - generates multiple annotations over a single pos/token/main label with
     different confidence factors. The purpose of this
     approach is the results to be used later for threshold processing and adjustment.
\end{itemize}

The museHMM application is configured with the GATE option.

\section{Specifying the features for HMM training}

Prior to training a new HMM model one needs to perform two steps:
determine what features will be used for training and then
pre-process the training corpus to contain these features. In this
section we'll focus on the first task, the second task will be
covered in the following section.

The configuration file is used to set up the HMM PR's internal
state initially. It defines the labels (annotation types), which
are going to be used from the PR as training features. From these
labels the PR will make judgements about the other ones, which
have been defined as target states (or just states). The
configuration file also sets up a number of constants used for
purposes such as limiting the iterations of the learning algorithm
and smoothing the model's probability matrices. The predefined
values of the labels are also stated in the configuration file, if
not then this information is retrieved during the training phase.

For example, one of the training features in
muse/applications/hmm/config\_muse\_not\_name.xml is the kind of
Token - word, number, etc. It is specified as:

\begin{verbatim}
        <LABEL ANNOT_SET_NAME="Muse" FEATURE_NAME="kind" NAME="Token.kind">
            <VALUE IS="number"/>
            <VALUE IS="symbol"/>
            <VALUE IS="word"/>
            <VALUE IS="punctuation"/>
        </LABEL>
\end{verbatim}

The annotation set name specifies in which annotation set the PR
will find the annotations. The feature name should be unique for
this model and is specified by the user. The name is either an
annotation type or an annotation type followed by a feature name.
If an annotation type is specified, then the model looks for the
presence or absence of this annotation type. If a feature is
specified, then its values can be enumerated in the model, as
shown above.

The PR can collect these values from the training corpus instead
and then save them in the configuration file when the model is
saved, so these values can be used in the future. To tell the
TrainHMM PR to collect the values from the corpus, specify the
label in the following way:

\begin{verbatim}
        <LABEL ANNOT_SET_NAME="Muse" FEATURE_NAME="kind" NAME="Token.kind">
        </LABEL>
\end{verbatim}

Documents from the training data should be annotated with
annotation types from the LABELS section of the configuration file
and the STATES section. Annotations for LABELS are used as
background knowledge for training, and annotations for STATES are
used as examples. One LABEL should be set as MAIN with the same
attribute in the configuration file. The main label is used as a
pattern over a document. Every observed event is created for every
annotation of main label type. We use Tokens.POS as the main
LABEL, because these work well for named entities.

The states currently specified in the model are:

\begin{verbatim}
    <STATES BACKGROUND="6">
        <STATE ANNOT_SET_NAME="Key" NAME="Person" OUT_ANNOT_SET_NAME="Muse"/>
        <STATE ANNOT_SET_NAME="Key" NAME="Location" OUT_ANNOT_SET_NAME="Muse"/>
        <STATE ANNOT_SET_NAME="Key" NAME="Organization" OUT_ANNOT_SET_NAME="Muse"/>
        <STATE ANNOT_SET_NAME="Key" NAME="NotName" OUT_ANNOT_SET_NAME="Muse"/>
    </STATES>
\end{verbatim}

What this means is that there are 6 background states, apart from
the 4 named states - Person, Location, Organization, and NotName.
The ANNOT\_SET\_NAME value specifies in which annotation set the
TrainHMM PR can find the annotations. We use Key, because our
evaluation tools and marked corpora use the Key set for the
gold-standard annotations. The automatically produced annotations
can be in any output set, including the default. In this
application we use the Muse set, as OUT\_ANNOT\_SET\_NAME, because
this is where the results of the earlier PRs are put. Unlike other
PRs where one can change the output set at run time, the HMM PRs -
ApplyHMM and TrainHMM take this information from the configuration
file, so it needs to be changed there if the application is being
changed.

Since the HMM requires nominal values, all features with numerical
values need to be nominalised by using JAPE grammars and
converting them. For example, we convert the length of tokens from
numerical into nominal by using
\texttt{normalise-tok-length.jape}, which converts the length of
tokens into nominal values: 1, 2, 3, 4, 5-10, 11\_or\_more. The
choice of these values has been based on human intuition and it
may be possible to improve in the future. Other transformations of
information and creation of features include punctuation
information - given as string; the creation of the NotName
annotations - created when the system wrongly thought that there
is a named entity annotation, while there was none in the Key set;
token position information - whether a token is the first/last
token in the sentence; and the named entity information from the
rule-based system - which rule created the annotation, its type,
and the length of the coreference chain as a nominal value. All of
these are currently used as LABELs (i.e., training features), but
future experiments might show that some might not be needed.

\section{Preparing the training data}

Prior to training new model with trainHMM PR, one needs to prepare
the training data. This includes running all PRs needed to create
the annotations used as LABELs in the configuration file + those
used for STATEs.

The gold-standard annotations to be used as training data, i.e.,
Organization, Person, Location, need to be annotated manually or
semi-automatically by running the rule-based system and correcting
its mistakes (i.e., deleting the wrong annotations and adding the
missed ones). In order to enable the use of GATE's evaluation
tools for measuring the system's performance against the
gold-standard annotations, these need to be added in a special
set, called Key. Therefore, if the muse.gapp application is used
to bootstrap the manual annotation process, its output sets need
to be changed from Muse to Key.

In addition, if nominalisation of feature values is required or
some more complex transformations of annotations are required for
the training features, i.e., the annotation types and features
given as LABELs, then the necessary JAPE grammars need to be
written. For debugging purposes, first try them on a small subset
of the entire training corpus.

The final step is executing muse-learning.gapp, followed by the
specific JAPE grammars to create the training annotations on the
entire training corpus. muse-learning.gapp looks very much like
muse.gapp - the difference is in the grammars that get executed.
The learning ones can label one and the same string with
alternative annotation types if the context is not sufficient to
solve the ambiguities. Basically, there are two sets of grammars:
the main set which contains very reliable rules and they are
shared with muse.gapp and the context set which overgenerates. The
orthomatcher module is executed after the reliable rules, but
before the context ones, because it helps to disambiguate the
types of some annotations. For example, Rotschild on its own may
not be easy to classify, but if the reliable rules have already
found a ``Mr Rotschild'' somewhere else in the text, then the
orthomatcher will disambiguate Rotschild correctly as a person.
These disambiguated annotations have a special feature
\texttt{NMRule} with value \texttt{Unknown}, which indicates that
an annotation of an unknown type is classified using the name
matcher.

If the training corpus is quite big, loading and processing it all
in memory might not be possible. Please refer to the GATE User
Guide for information on how to use file-based datastores, which
allow the documents to be processed one at a time, thus
substantially reducing the memory requirements.

\section{Training a new HMM model}

Once the corpus has been pre-processed and the configuration file
has been created, all that remains is to train the new HMM model.
Load a trainHMM PR in GATE, giving it the configuration file as a
create-time parameter - \texttt{modelURL}. Then create a new
corpus pipeline and add the trainHMM PR to it. There are no train
options that can be specified at present. The
\texttt{reconstructModel} option specifies whether or not we are
training a new model or extending an already saved on (taken from
the configuration file provided at create-time). We have only
tested it with full re-creation of the model.

In the root tag of the configuration file, the attribute
SPLIT\_ANNOT\_NAME can be set. If this attribute is set and there
are annotations from the same annotation type as the attribute
value in the training data, these annotations will be used to
construct the observation sequences smaller than a document. For
example you can use SPLIT\_ANNOT\_NAME=``Sentence" in order to
train on one sentence at a time, instead of taking the entire
document as one observation sequence. Using shorter observation
sequences is faster and also prevents the probabilities from
getting too close to zero.

Once training is finished (which may take a while), the resulting
model is saved by right-clicking on trainHMM PR and choosing Save
trained model or Save trained model As. Once saved, the model is
ready to be applied (see above).
