HeidelTime is developed as a UIMA component so that we are able to integrate our temporal tagger into our existing document processing pipeline. It is an extension of the temporal tagger we already use for the extraction and exploration of spatio-temporal information in documents (Strötgen et al., 2010). UIMA is widely used for process­ing unstructured content such as audio, images, or text. Different components can be combined to create a pipeline of modular tools, and all com­ponents use the same data structure, the Common Analysis Structure (CAS). This allows to combine tools that were not originally built to be used to­gether, an advantage we are using for preprocess­ing tasks as well.

In general, a UIMA pipeline consists of three types of components, a Collection Reader for ac­cessing the documents from a source and initializ­ing a CAS object for each document. The analy­sis of the documents is performed by Analysis En­gines that add annotations to the CAS objects. Fi­nally, CAS Consumers are used for final process­ing, e.g., for storing the annotated information in a database or performing an evaluation.

In Figure 1, the document processing pipeline for designing and using our temporal tagger Hei­delTime is depicted. The design workflow (left arrows) contains the TempEval-2 Reader, which reads the TempEval-2 data, initializes a CAS ob­ject for each textual document and adds the anno­tated data to the CAS. For the test set of the temporal expression task, these include the sentence and token information, and for the training set also the gold standard Timex3 entities. Next, the OpenNLP part-of-speech tagger is used, which assigns the corresponding part-of-speech (POS) tag to each token. The information about sen­tences, tokens, and POS tags is then used by our temporal tagger HeidelTime for extracting and normalizing temporal expressions mentioned in the documents. The CAS Consumer TempEval-2 File Writer is used for creating the files needed for applying the scorer and which had to be sub­mitted for evaluation. During the rule develop­ment phase of HeidelTime, the CAS Consumer TempEval-2 Evaluator was used, which compares the gold standard Timex3 annotations with the Timex3 annotations extracted by HeidelTime, re­sulting in lists of true positives, false positives, and false negatives. These lists were then used for adapting existing or creating new rules.

On the right-hand side of Figure 1, a workflow for using HeidelTime in other scenarios is shown. This workflow reflects the fact that temporal tag­ging is just one intermediate component of our document processing pipeline. Here, the docu­ments have to be split into sentences and tokens using the two analysis engines Sentence Splitter and Tokenizer. The POS tagger and HeidelTime are used in the same way as described for the other workflow. In addition, other Analysis Engines can be used, e.g., for combining the extracted tempo­ral information with spatial information. Finally, CAS Consumers are used, e.g., for storing the spatio-temporal information in a database.

Every temporal expression te can be viewed as a three-tuple tei = (ei,ti,Vi), where is the expression itself as it occurs in the textual docu­ment, ti represents the type of the expression, and Vi is the normalized value. There are four possi­ble types, namely Date, Time, Duration, and Set. The normalized value represents the temporal se­mantics of an expression as it is specified by the markup language TimeML, regardless of the ex­pression used in the document. The goal of Hei­delTime is to extract for every temporal expression the expression e% and to correctly assign the type and value attributes U and Vi, respectively.

For this, HeidelTime uses hand-crafted rules,

http ://opennlp.sourceforge.net

Normalization norrnMov>th(" June") = "06" functions normSeason ("summer") = "SU"

Table 1 : Examples for extraction and normaliza­tion resources for months and seasons.

which are grouped into four types, namely the four possible types of temporal expressions. More pre­cisely, every rule is a triple of an expression rule, a normalization function and the type information. The extraction rules mainly consist of regular ex­pression patterns. However, other features can be used as well, e.g., a constraint what part-of-speech the previous or next token has to have. Heidel­Time contains resources for both the extraction and the normalization tasks of the rules. For in­stance, there are resources for weekdays, months, or seasons, which are realized as regular expres­sions and can be accessed by multiple extraction rules. In addition, there are knowledge resources for the normalization of such expressions. Exam­ples are given in Table 1.

Algorithm 1 illustrates how rules are used in HeidelTime. First, the rules are applied to ev­ery sentence of a document, and extracted timexes are added to the CAS object. Then, two post­processing steps are executed to disambiguate un-derspecified values and to remove invalid tempo­ral expressions from the CAS. This functionality is detailed in the next sections with a focus on the linguistic clues for the normalization task.

Algorithm 1 ApplyRules.

foreach sentence in document addDatesToCAS(date_rules, CAS); addTimesToCAS(time_rules, CAS); addDurationsToCAS(dur_rules, CAS);

addSetsToCAS(set_rules, CAS); end foreach foreach timex3 in CAS

disambiguate Values(CAS); end foreach remo velnvalidsFromC AS (C AS );

There are many ways to textually describe tem­poral expressions, either explicitly, implicitly or relatively (Schilder and Habel, 2001). The extrac­tion for all temporal expressions works in the same way, but assigning the value attributes has to be done differently. Explicit temporal expressions are fully specified, i.e., the value attribute can directly

explicit temporal expressions datejrl = (reMonth)gi (reDay)g2, (reFullYear)g3 norm_rl(gl,g2,g3) = g3-normMonth(gl)-normDay(g2) implicit temporal expressions date_r2 = (reHoliday)gi (reFullYear)g2 norm_r2(gl,g2) = g2-normHoliday(gl)

be assigned using the corresponding normalization function of the rule. For example, the explicit ex­pression March 11, 1982 can be extracted with the rule date_rl of Table 2 containing the resources reMonth, reDay, and reFullYear (regular ex­pressions for possible month, day and year tokens of a date phrase, respectively). The matched to­kens can be accessed using the group ids so that the normalization function can be called with the extracted tokens resulting in the value 1982-03-11.

The value attribute of implicit expressions can be assigned once the implicit temporal semantics of such expressions is known. Holidays, for ex­ample, can be extracted using date_r2 with the resource reHoliday and normalized using the knowledge resource for normalization as shown in Table 2. An example is Independence Day 2010 to which the value 2010-07-04 is assigned.

The normalization of relative expressions for which a reference time is needed is the most chal­lenging task. Examples are last June, just June in phrases such as in June, or year-earlier in the year-earlier results. To such expressions, Hei­delTime assigns the values in an underspecified format depending on the assumed reference time and disambiguates them in a post-processing step. The underspecified values for the examples are UNDEF-last-Iune, UNDEF-Iune, and UNDEF-REF-last-year, respectively. For the first two ex­amples, the document creation time (dct) is as­sumed to be the reference time while for the last example the previously mentioned date is used for reference. In news texts (as used in TempEval-2) the dct is meaningful while other documents may not contain such a reference time. Then, the previ­ously mentioned date is used for all underspecified values. The disambiguation of such expressions is detailed in the next section.

The first post-processing step is to disambiguate underspecified value attributes (see Algorithm 1). If the value starts with UNDEF-REF, the previously mentioned date is used for disambigua­tion, otherwise the document creation time (dct) if meaningful. The value UNDEF-last-June of the previous section is disambiguated by calcu­lating the June before the dct. More complex are even less underspecified values like UNDEF-June. Here, linguistic knowledge is used to dis­ambiguate which June is meant: The tense of the sentence is determined by using the part-of-speech information of the tokens and checking the seman­tics of the verbs in the sentence. This method iden­tifies whether a sentence is past, present, or fu­ture tense. E.g., the tense of the sentence In June, new results will be published will be determined to be future tense and the new value UNDEF-next-June can be assigned instead of UNDEF-last-June if past tense was identified. Such values are then disambiguated using the methods described above.

If the reference time is assumed to be the previously mentioned date all previous extracted Timex3 are checked to be of the type Date. The value vref of the closest previously mentioned date is then used for further disambiguation. For example, UNDEF-REF-last-year is calculated by subtracting one year from vref. This can result in a specific day but also in a specific quarter if the last mentioned timex was a quarter.

The last post-processing step is to remove all extracted timex annotations that are invalid. In­valid are all expressions that are included in other expressions. For instance, having the phrase June 11 the whole phrase is found by a rule as well as just June. Since June is in June 11, it is removed.