**RDC Guidelines for Time Attributes**

**(Addendum to \"Preliminary Guidelines for Relation Detection and
Characterization (RDC)\")**

# Version 1.4

**14** **January 2002**

**Beth Sundheim, SPAWAR Systems Center (sundheim@spawar.navy.mil)**[^1]

# 1. Introduction

RDC records certain types of reported associations between pairs of
entities. It also requires the reporting of the relation timestamps,
i.e. of the time when a relation is reported as existing. For the first
round of RDC, we take a conservative approach to associating times with
relations, and require that the text evidence be found within the
predication of a relation mention. Thus, we treat only Class A
(explicit) relations, and only those that include explicit temporal
evidence.

The text evidence of a timestamp may be in the form of a temporal phrase
that is an adjunct to the predicate (\"Bush\'s *Saturday* visit to
Manhattan\", \"Rumsfeld became U.S. Secretary of Defense again *in
2001*\"). A more general timestamp may be present in the form of a
finite verb that heads the predication of the relation. A large
proportion of Class A relation mentions will contain neither a time
adjunct phrase nor a finite verb, and will therefore be assigned null
temporal attribute values.

There may be more than one time at which a particular relationship is
reported as having existed, i.e., there may be more than one timestamp
on a relation. For example, a document may note that John Doe was
LOCATED at Las Vegas June and August in 2001, or that Jane Doe had the
ROLE of Technical Director for SPAWAR Systems Center in 1998 and 2000.
The two different times referenced in each example are not evidence of
different underlying relations; they are different attribute values for
the same underlying relation.

# 2. Approach

Our approach to timestamping relations reflects our interest in
extracting only highly reliable information and in posing a focused
challenge to extraction systems. It also reflects our concern about
achieving sufficient human interannotator agreement on the task. The
outlined approach requires recognition and interpretation of temporal
expressions that appear in adjuncts modifying relation mentions, and
recognition and contextual interpretation of finite verb forms that head
the predication of relation mentions.

With respect to temporal expressions, the outlined approach applies
previous work carried out under TIDES sponsorship. This work is
documented in two MITRE technical reports \[1, 2\]. These documents
provide guidelines for the use of a time expression tag called TIMEX2.

ACE relations that can be pinned down to a single point or interval in
time (on a clock, month-based calendar or week-based calendar) or to an
explicit time duration will be timestamped in RDC in a way that builds
from the TIMEX2 annotation. (See below re the RDC use of TIMEX2
annotations that do *not* have values.) The use of the Alembic Workbench
to support this activity is described in \[3\]. In an effort to keep the
ACE annotation effort relatively simple in the beginning, some of the
more complex aspects of TIMEX2 annotation are not reflected in the
target RDC output; in particular, the distinction between references to
single dates/times versus references to *sets* of dates/times is not
maintained in the RDC output, and explicit flagging of *non-specific*
dates/times is not included in the RDC output.

# 3. RDC Temporal Attributes

**3.1** **General Information**

Three temporal attributes are currently defined for RDC:
REL_TIME_SOURCE, REL_TIME_VALUE and REL_TIME_ANCHOR.[^2] These represent
the text form of a timestamp (in REL_TIME_SOURCE) and the corresponding
normalization (in REL_TIME_VALUE and/or REL_TIME_ANCHOR), in accordance
with the guidelines given in the following sections. These are
attributes of a relation *mention*, not of a relation overall. In the
future, we may consider defining temporal attributes for the overall
relation as well; the purpose of such attributes would be to fuse the
temporal evidence that is recorded at the mention level.

**3.2 Guidelines for Deciding Whether to Generate One Timestamp, or
Two**

There are a few different situations where the annotator will encounter
expressions that denote more than one time for a relation mention.

-   Two TIMEX2s, two RDC timestamps: It is possible for there to be more
    than one timestamp on a particular relation mention, as when both a
    duration and point are given (\"my last visit to Las Vegas was for
    *three hours* in *1968*\").

-   Two TIMEX2s, one RDC timestamp: When the endpoints of a range in
    time are given for a relation mention (\"my last visit to Las Vegas
    was *1-3 September*\"), they are captured as independent TIMEX2
    expressions, but for RDC, they are to be combined into a single,
    complex timestamp. Also, when two TIMEX2s of the same kind (e.g.,
    two point expressions) at different granularity are given for a
    mention (\"his arrival in Kabul in *January* on *the 3rd*\"), only
    the more specific VAL is used for RDC (in this case, the one for
    \"*the 3rd*\"), since it subsumes the VAL of the other TIMEX2.

-   One TIMEX2, one RDC timestamp: When there is an expression of a set
    of times modifying a relation mention (\"my visits to Las Vegas
    *every month*\"), these are captured as a single timestamp for RDC,
    and the fact that the expression denotes a set of times is ignored
    (for the time being).[^3]

# 

# **3.3 Three Types of Timestamps**

Some relation timestamps will come from temporal adjuncts, while others
will come from tensed predicates. One of three different types of
information is to be generated. The three types and the conditions for
generating them are listed below, in order of preference.

1\. **Specific, absolute time:** When a relation mention includes a
temporal adjunct with a TIMEX2 expression that has a VAL attribute, that
expression is to be used as the source of the relation timestamp.

2\. **General, relative time:** When condition 1 does not apply, a
general, relative time value is to be produced from the relation mention
predicate, if headed by a finite verb. The relative time value indicates
whether the relation is reported as existing at, before or after the
time of the report.

3\. **General temporal category:** If the first two conditions don\'t
apply, and if there is a TIMEX2 adjunct to the mention that has no VAL
attribute, an RDC time value that simply indicates the nature of the
expression is to be produced; this value is either POINT or DURATION,
depending on the interpretation of the TIMEX2 expression in the context
of the relation mention.

Here is an example of each type of timestamp, with the extracted
information encoded in \"pseudo-RDC\" format. The specifications for the
RDC attributes are found in section 4.

1\. Generation of RDC time attribute is licensed because the relation
mention includes an adjunct containing a TIMEX2 expression that has a
VAL attribute (and does *not* have a NON_SPECIFIC attribute).

> I was spending *two weeks* on vacation there *that summer.* (Context
> tells us that "that summer" is the summer of 1968. This example has
> two timestamps.)
>
> Relation: Located (I, there)
>
> Timestamp1 Source: "two weeks"
>
> Timestamp1 Value: P2W
>
> Timestamp1 Anchor: nil
>
> Timestamp2 Source: "that summer"
>
> Timestamp2 Value: 1968-SU
>
> Timestamp2 Anchor: nil

2\. Generation of RDC time attribute is licensed because the predication
of the relation mention is headed by a finite verb.

> The PDC\'s premises *are* located at 683 Sotomayor Street, in the
> downtown area of the city. (This example is from an article dated Sep
> 28, 1988.)
>
> Relation: Located (The PDC\'s premises, 683 Sotomayor Street\...)
>
> Timestamp Source: \"are\"
>
> Timestamp Value: nil
>
> Timestamp Anchor: AS_OF 1988-09-28

3\. Generation of RDC time attribute is licensed because the relation
mention includes an adjunct containing a TIMEX2 expression that is
encoded *without* a VAL.

> The petition is addressed to Mr Augusto Pinochet Ugarte \-- appointed
> president of the Republic for *another period of government* \-- and
> it points out some serious human rights violations, which must be
> explained.
>
> Relation: Role (Mr Augusto Pinochet Ugarte, the Republic)
>
> Role: appointed president
>
> Timestamp Source: \"another period of government\"
>
> Timestamp Value: DURATION

Timestamp Anchor: nil

# 4. Specifications for Filling Time Attributes

**4.1** **REL_TIME_SOURCE**

For timestamp types 1 and 3, the fill for REL_TIME_SOURCE is a text
string whose extent is the same as that of the corresponding TIMEX2
expression. For type 2 timestamps, the fill is a text string whose
extent is the same as that of the tensed verb form in the corresponding
predicate.

-   In the case of types 1 and 3, note that the extent of TIMEX2-tagged
    expressions excludes the leading preposition that heads many time
    adjunct phrases ("*on* Saturday", \"*before* 10:00\", "*for* two
    weeks"), and the specifications for REL_TIME_SOURCE follow that same
    practice. The *semantics* contributed by the prepositions are
    captured in the RDC .apf format in various ways \-- implicitly in
    REL_TIME_VALUE in cases such as \"on\", explicitly in the period
    notation for REL_TIME_VALUE in cases such as \"for\" (indicating
    duration), and explicitly in the RDC-specific use of REL_TIME_ANCHOR
    in cases such as \"before\".

-   In the case of type 2, the string fill documents the fact that the
    mention is headed by a finite verb, which is evidence that a time
    reference can reliably be generated. From the point of view of the
    end user of an RDC database, this string serves only as a link to
    the general text location where the evidence for the normalized form
    can be found. It is not intended to serve the user as direct and
    sole justification for that normalized form.

**4.2** **REL_TIME_VALUE**

The fill for REL_TIME_VALUE is derived from TIMEX2 annotations. Thus, it
is non-null for timestamp types 1 and 3, and it is null for type 2.

-   For type 1 timestamps, REL_TIME_VALUE always contains the value of
    the TIMEX2 VAL attribute. If there is also a MOD attribute on the
    TIMEX2 expression, REL_TIME_VALUE will have a two-part fill in which
    the value of MOD is prepended to the value of VAL.

-   Type 3 timestamps are based on TIMEX2 expressions that do not have
    an assigned VAL attribute. REL_TIME_VALUE in these cases is always a
    one-part attribute, with a set-fill value of either POINT or
    DURATION, depending on the interpretation of the TIMEX2 expression
    in the context of a relation mention.

**4.3** **REL_TIME_ANCHOR**

The fill for REL_TIME_ANCHOR provides a reference (anchoring) time and a
directionality of offset from that time. The attribute takes a two-part
fill, with a set-fill to indicate directionality as the first part and a
value in TIMEX2 VAL (ISO) format to represent the anchor as the second
part. The directionality set-fill options are AS_OF, BEFORE and AFTER.

This attribute is non-null for all type 2 timestamps and for some type 1
timestamps.

-   For type 1 timestamps, REL_TIME_ANCHOR is filled when anchoring
    information is provided either by corresponding attributes within a
    TIMEX2 annotation itself or by the context of the TIMEX2 expression
    in a relation mention.

    -   It is provided by TIMEX2 annotations that include the attributes
        ANCHOR_VAL and ANCHOR_DIR.[^4] To form the fill for
        REL_TIME_ANCHOR, the directionality value provided by ANCHOR_DIR
        is prepended to the anchoring value provided by ANCHOR_VAL.

> Examples: \"the past five days\"
>
> \"at least the next year\"
>
> \"now\"

-   It is provided contextually when the TIMEX2 expression appears in a
    temporal prepositional phrase in the relation mention that
    designates a begin or end point. Only prepositions that convey a
    BEFORE or AFTER relationship are considered. The interpretation of
    the temporal adjunct as a whole in the context of the relation
    mention provides the directionality value. The anchoring value is
    the same as the TIMEX2 value of the VAL attribute.

> Examples: \"before 5 pm\"
>
> \"until 5 pm\"
>
> \"from 5 pm on\"

-   For type 2 timestamps, the fill for REL_TIME_ANCHOR consists of a
    normalized form of the anchoring date/time[^5] in TIMEX2 VAL (ISO)
    format, prepended by one of the three directionality values,
    according to the general time reference of the predicate of the
    relation mention.

-   As mentioned earlier, the string that fills REL_TIME_SOURCE for type
    2 timestamps is not intended to provide a complete explanation for
    the normalized form. Here are a few examples in which a present
    tense verb is not reflected as AS_OF in the normalized form, or a
    future tense form is not reflected as AFTER.

\(1\) Annan *has* returned to New York City.

> Relation: Located (Annan, New York City)
>
> Timestamp Source: \"has\"
>
> Timestamp Value: nil
>
> Timestamp Anchor: BEFORE 1988-09-28
>
> \(2\) Annan *is* returning to New York City.
>
> Relation: Located (Annan, New York City)
>
> Timestamp Source: \"is\"
>
> Timestamp Value: nil
>
> Timestamp Anchor: AFTER 1988-09-28

\(3\) He *is* expected to return to New York City in a good mood.

> Relation: Located (Annan, New York City)
>
> Timestamp Source: \"is\"
>
> Timestamp Value: nil
>
> Timestamp Anchor: AFTER 1988-09-28
>
> \(4\) Annan *will* not return from Baghad until there is a truce.
>
> Relation: Located (Annan, Baghdad)
>
> Timestamp Source: \"will\"
>
> Timestamp Value: nil
>
> Timestamp Anchor: AS_OF 1988-09-28

**4.4 Summary Table of Attribute Specifications**

A summary of the fill specification of each type of fill is shown in the
table below, with examples in the lower half of each row.

+---------+------------------+------------------+----------------------+
| **Type  | **R              | **               | **REL_TIME_ANCHOR**  |
| of**    | EL_TIME_SOURCE** | REL_TIME_VALUE** |                      |
| **Time  |                  |                  |                      |
| stamp** |                  |                  |                      |
+---------+------------------+------------------+----------------------+
| Type 1: | Text string:     | *Either* a       | Two-part fill: set   |
| Sp      | TIMEX2           | one-part,        | fill (AS_OF, BEFORE  |
| ecific, | expression       | normalized fill: | or AFTER) plus       |
| a       |                  | value of TIMEX2  | normalized date/time |
| bsolute |                  | VAL              |                      |
| time    |                  |                  |                      |
|         |                  | *Or* a two-part  |                      |
|         |                  | fill: set-fill   |                      |
|         |                  | value of TIMEX2  |                      |
|         |                  | MOD plus value   |                      |
|         |                  | of TIMEX2 VAL    |                      |
+---------+------------------+------------------+----------------------+
|         | *September 26 of | 2001-09-26       | NIL                  |
|         | this year*       |                  |                      |
|         |                  | 2001-09-26T14:40 | NIL                  |
|         | *2:40 p.m. Sept. |                  |                      |
|         | 26, 2001*        | 2001-W40         | NIL                  |
|         |                  |                  |                      |
|         | *next week*      | APPROX 1999      | NIL                  |
|         |                  |                  |                      |
|         | *about two years | P2W              | NIL                  |
|         | ago*             |                  |                      |
|         |                  | P2W              | BEFORE 2001-W39[^7]  |
|         | *two-week*       |                  |                      |
|         |                  | AFTER 2000       | BEFORE 2001[^8]      |
|         | *the past two    |                  |                      |
|         | weeks*           | PRESENT_REF      | AS_OF                |
|         |                  |                  | 2001-09-26T14:40[^9] |
|         | *less than a     | 2001-09-26       |                      |
|         | year ago*        |                  | BEFORE               |
|         |                  | X                | 2001-09-26[^10]      |
|         | *currently*      | XXX-WXX-2TNI[^6] |                      |
|         |                  |                  | XXXX-WXX-2TNI        |
|         | \[before\]       |                  |                      |
|         | *today*          |                  |                      |
|         |                  |                  |                      |
|         | *everyTuesday    |                  |                      |
|         | night*           |                  |                      |
+---------+------------------+------------------+----------------------+

+---------+------------------+------------------+----------------------+
| Type 2: | Text string:     | Not applicable   | Two-part fill: set   |
| G       | finite verb      |                  | fill (AS_OF, BEFORE  |
| eneral, |                  |                  | or AFTER) plus       |
| r       |                  |                  | normalized date/time |
| elative |                  |                  |                      |
| time    |                  |                  |                      |
+---------+------------------+------------------+----------------------+
|         | *is*, as in \"He | NIL              | AS_OF                |
|         | is in Baghdad\"  |                  | 2001-09-26T14:40:30  |
|         | (& where         | NIL              |                      |
|         | doc-time is      |                  | BEFORE               |
|         | given down to    | NIL              | 2                    |
|         | the second)      |                  | 001-09-26T14:40[^11] |
|         |                  |                  |                      |
|         | *was*, as in     |                  | AFTER                |
|         | \"He was in      |                  | 2001-09-26[^12]      |
|         | Baghdad\" (&     |                  |                      |
|         | where doc-time   |                  |                      |
|         | is given down to |                  |                      |
|         | the minute)      |                  |                      |
|         |                  |                  |                      |
|         | *will*, as in    |                  |                      |
|         | \"He will be in  |                  |                      |
|         | Baghdad\" (&     |                  |                      |
|         | where doc-time   |                  |                      |
|         | is given down to |                  |                      |
|         | the day)         |                  |                      |
+---------+------------------+------------------+----------------------+
| Type 3: | Text string:     | Set fill: POINT  | Always NIL           |
| General | TIMEX2           | or DURATION      |                      |
| t       | expression       |                  |                      |
| emporal |                  |                  |                      |
| c       |                  |                  |                      |
| ategory |                  |                  |                      |
+---------+------------------+------------------+----------------------+
|         | *the appropriate | POINT            | NIL                  |
|         | time* (as in     |                  |                      |
|         | "his appearance  | DURATION         | NIL                  |
|         | in Baghdad at    |                  |                      |
|         | the appropriate  |                  |                      |
|         | time")           |                  |                      |
|         |                  |                  |                      |
|         | *another period  |                  |                      |
|         | of government*   |                  |                      |
|         | (as in           |                  |                      |
|         | "Pinochet,       |                  |                      |
|         | appointed        |                  |                      |
|         | president of the |                  |                      |
|         | Republic for     |                  |                      |
|         | another period   |                  |                      |
|         | of government,   |                  |                      |
|         | \...")           |                  |                      |
+---------+------------------+------------------+----------------------+

  ----------- ---------------------------- ------------------------------
                                           

                                           

                                           

                                           

                                           

                                           

                                           
  ----------- ---------------------------- ------------------------------

**5.0 References**

\[1\] L. Ferro, I. Mani, B. Sundheim, G. Wilson. 2001. \"TIDES Temporal
Annotation Guidelines, Version 1.0.2\". MITRE Technical Report
01W0000041, June 2001.

\[2\] L. Ferro. 2001. \"TIDES Instruction Manual for the Annotation of
Temporal Expressions\". MITRE Technical Report 01W0000046V01, June 2001.

# 

# 

# 

# 

# 

# 

1.  

2.  

3.  

4.  

5.  \[3\] L. Ferro. 2002. \"Automatic Content Extraction (ACE): Using
    the Alembic Workbench to Annotate RDC Temporal Attributes, Version
    1.0\". (draft)

[^1]: with significant contributions by Lisa Ferro (Mitre) and Laurie
    Gerber (Northrop Grumman IT)

[^2]: These attributes are actually labeled TIMESTAMP_SOURCE,
    TIMESTAMP_VALUE, and TIMESTAMP_ANCHOR in the early RDC releases of
    AWB. \"TIMESTAMP\" will change to \"REL_TIME\" in later releases, to
    avoid confusion with an existing, speech-related TIMESTAMP tag.

[^3]: To \"ignore\" the set-denoting information means to disregard the
    SET, GRANULARITY and PERIODICITY attributes of the TIMEX2
    expression.

[^4]: These are being documented in an updated version of the published
    (June 2001) TIMEX2 materials \[1, 2\].

[^5]: This anchor is usually the date/time of the document\'s production
    or its publication/release, and the source of that information
    varies. It may come from a dateline found within the TEXT tag in the
    document (e.g., a newspaper article), from a DATE attribute within a
    HEADER tag on a document (e.g., a newspaper article), from the value
    of a DATE_TIME tag on a document (e.g., a newswire item), or from
    within the value of a DOCNO tag on a document (e.g., a broadcast
    news story). The anchor may also be a narrative-dependent date/time,
    found somewhere within the text of the document.

[^6]: The TIMEX2 tag for this set-denoting expression would include SET,
    PERIODICITY, and GRANULARITY attributes, as well as VAL. All except
    VAL are currently disregarded for RDC.

[^7]: The week (in this case \"W39\") represents the current week. The
    interpretation of \"the past two weeks\" is \"the two weeks before
    some/any point that\'s within the range of the current week\". The
    information for REL_TIME_ANCHOR comes from the TIMEX2 annotation.

[^8]: \"2001\" represents the current year. The interpretation of \"less
    than a year ago\" is \"a time that\'s within the range of
    2000-2001\". The representation is not powerful enough to enforce a
    12-month constraint on the length of the interval. The information
    for REL_TIME_ANCHOR comes from the TIMEX2 annotation.

[^9]: The anchor value is the same as the reference time (document
    date/time or narrative date/time), and the granularity of the
    meaning of \"currently\" is the same as the granularity of the
    reference time. The information for REL_TIME_ANCHOR is obtained by
    converting the fill that\'s in REL_TIME_VALUE.

[^10]: See previous footnote. Note that the interpretation of \"before
    today\" is not accurate given the current representation. \"Today\"
    has some VAL, and its granularity is a day, i.e., it encompasses all
    the points within the 24-hour period. It keeps that VAL even when we
    tack BEFORE to the front of it. The representation of \"before
    today\" comes out meaning more like \"before sometime today\", not
    \"before the entire day today.\" So, for example, a downstream
    automatic reasoner that seeks to determine whether \"3 p.m. today\"
    is compatible with \"before today\" would have to conclude that yes,
    they are compatible, even though we know that they\'re not..

[^11]: See footnote above re inacurracy of interpretation.

[^12]: Ditto.