Enriching the Notion of Path in ISOspace

This paper proposes a modification to the notion of PATH as used in ISOspace, in order to both simplify the semantics of the MOVELINK tag as well as improve its coherence as a link structure, as defined in Bunt et al. (2016). This follows a suggestion by Lee (2016), where a reformulation of MOVELINK is proposed, in effect restoring an earlier proposal by Pustejovsky et al. (2010), where a motion is a relation between a MOVER and an EVENT PATH. This simplifies the specification in ISOspace, maintains a coherent abstract syntax, and avoids redundancy with the annotation of semantic role labels. 1 Elements of ISOspace As part of an ISO international standard on semantic annotation, ISOspace (ISO-24617-7, 2014) provides an abstract syntax, represented in UML diagrams, two concrete syntaxes, and a set of guidelines for the annotation of spatial entities and motions in language. It specifies: (a) how to annotate spatial entities such as places, paths, and spatially involving non-locational objects and motions and other non-motion events in language; and (b) how to annotate and represent their relations in a concrete format, either XML or predicate-logic-like form. The specification for ISOspace distinguishes between four major types of spatially relevant elements for markup in natural language (Pustejovsky, 2017). (1) a. PLACES AND SPATIAL ENTITIES: natural or artificial locations in the world, as well as objects participating in spatial relations. b. EVENTS AND MOTION EVENTS: Eventualities involving movement and static situations. c. SPATIAL SIGNALS AND SPATIAL MEASURES: linguistic markers that establish relations between places and spatial entities. d. SPATIAL RELATIONSHIPS: The specific qualitative configurational, orientational, and metric relations between objects. In the discussion below, we focus on those elements of ISOspace that are most relevant for modeling motion events. We begin with the six basic entity types, given below. (2) a. PLACE b. PATH c. SPATIAL ENTITY (non-locational) d. MOTION events e. EVENT (non-motion) f. SIGNAL (three types) The PLACE tag is used for annotating geographic entities like lakes and mountains, as well as administrative entities like towns and counties. (3) shows extents that should be captured with PLACE. (3) a. [Bostonpl1] is north of [New Yorkpl2]. b. John entered the [storepl3]. c. Kiyong flew to [Montpellierpl6]. With the exception of implicit, non-consuming tags, a PLACE tag in ISOspace must be directly linked to an explicit span of text. The PATH tag is used to capture locations where the focus is on the potential for traversal or functions as a boundary. This includes common nouns as in (4a) and (4b) as well as proper names as in (4c). The attributes of the PATH tag are a subset of the attributes of the PLACE tag, but with the additional beginID, endID, and midIDs attributes. (4) a. . . . I arrived at the end of the [roadp1]. b. . . . a massive mountain [rangep2] that hugs the west [coastp3] of Mexico. c. I followed the [Pacific Coast Highwayp4] along the coastal mountains . . . Finally, a SPATIAL ENTITY is a named entity that is both located in space and participates in an ISOspace link tag. It is generally anything that is spatially relevant but does not fit into either the PLACE or PATH categories. In practice, moving objects and objects that have the potential to move are most commonly tagged as a SPATIAL ENTITY. In both (5a) and (5b), car should be marked as a SPATIAL ENTITY. In the first case, it is the mover and, in the second case, it behaves like a PLACE. Note, though, that it should still be annotated as a SPATIAL ENTITY and not be annotated as a PLACE since cars still have the potential for movement. (5) a. The [carsne1] drove down the street. b. [Johnsne1] arrived at the [carsne2]. c. My [fathersne1] and [Isne2] biked for two days. ISOspace has four types of relation tags, called links, holding between entity structures, illustrated below. (6) a. QSLINK – qualitative spatial links; b. OLINK – orientation information; c. MOVELINK – movement links; d. MLINK – measuring dimensions of locations A QSLINK captures the topological relationship between two spatial objects, and are usually triggered by topological SPATIAL SIGNALs. Topological information primarily refers to containment and connection relations between a pair of locations. ISOspace uses the Region Connection Calculus (RCC) as the basis for its qualitative spatial relationships (Randell et al., 1992). RCC8 is concerned with how regions (spatial objects) are connected to each other. The combination of RCC8’s jointly exhaustive and pairwise disjoint relations, along with IN (the disjunction of TTP and NTTP) is referred to in ISOspace as RCC8+. Figure 1 visualizes the basic RCC8 relations. Figure 1: Visual Correspondence of RCC8 Relations Briefly, the OLINK tag covers those relationships that occur between two locations that are non-topological in nature. Orientation links essentially fill in information that QSLINKs fail to capture, including direction, orientation, and frame of reference. Finally, the MLINK tag serves two purposes in ISOspace: to capture the distance between two spatial objects; or to describe the dimensions of a single object. See Pustejovsky (2017) for details on both of these relation types. Finally, we come to the MOVELINK. The MOVELINK tag is used to connect all of the elements that are involved in a motion event, including the MOTION event itself, the mover, the source, goal, midPoints, and ground of the MOTION, an explicit path, if there is one, (i.e., pathID) and any adjuncts that are present (i.e., adjunctID). The trigger of a MOVELINK is always a MOTION ID and the mover is normally a SPATIAL NE. Table 1 shows the attributes for the MOVELINK tag. id mvl1, mvl2, mvl3, . . . trigger identifier of the motion event that triggered the link source identifier of the place, path, spatial named entity, or event at the beginning of the path goal identifier of the place, path, spatial named entity, or event at the end of the path midPoint identifier of the place, path, spatial named entity, or event in the middle of the path mover identifier of the entity that moves along the path ground identifier of a place, path, spatial named entity or event that the mover’s motion is relative to goal reached TRUE, FALSE, UNCERTAIN pathID identifier of a path that is equivalent to the one described by the MOVELINK adjunctID identifier of the spatial signal that participates in the link Table 1: Attributes for MOVELINK 2 Problems with MOVELINK It is perhaps important to understand that the motivation for the MOVELINK tag in ISOspace comes originally from an interest in tracking objects in motion, as described in texts, and then linking them to maps or other visual geographic displays (Pustejovsky and Moszkowicz, 2008). As such, this results in a conflation of two kinds of information structures: (i) a relation between a motion and the mover in the motion; and (ii) all of the semantic roles that are involved in a motion event. This has the unintended consequence of creating a link structure that overlaps with efforts to annotate semantic roles generally, i.e., SemAF-SR (24617-4, 2014), and specifically within spatial language (Kordjamshidi et al., 2012). Moreover, it is unlike the other relational structures in ISOspace, in that it identifies no actual relation type, independent of the motion event itself. In this sense, it fails to conform to the definition of a link structure, as proposed in Bunt et al. (2016). For these reasons, following Lee (2016), we propose to simplify the structure of the MOVELINK tag as a relation between a MOVER and the path created by the movement, namely the EVENT PATH. 3 The Return of EVENT PATH In ISOspace version 1.3e, Pustejovsky et al. (2010) introduced an additional tag to the elements listed in Section 1 above, namely an EVENT PATH. The original intuition behind this type was to have a record of the movement as carried out by the mover: that is, to encode the path created by the traversal of an entity in motion. In order to make this more transparent, following Mani and Pustejovsky (2012), Pustejovsky and Yocum (2013) introduce two axioms of motion into the abstract syntax of ISOspace, given below. (7) a. Axiom 1: Mover Participants Every motion-event involves a mover. 8e9x[motion-event(e)! mover(x, e)] b. Axiom 2: Event Paths Every motion-event involves an event-path. 8e9p[motion-event(e)! [event-path(p) ^ loc(e, p)]] These axioms presuppose the following definitions1: (8) MOVER: participant in a motion-event that undergoes a change in its location.2 PATH: non-null sequence of locations (places). See Pustejovsky and Yocum (2013). 2 Langacker (2008) (p.356) introduces mover as one of the six archetypal roles associated with actions and events, while defining it as ”anything that moves (i.e. changes position in relation to its external surroundings)”. He also treats the mover as a trajector in contrast to a landmark that provides a ground for the activity or motion of a trajector. These two terms, trajector and landmark, correspond to the terms figure and ground in our use related to motion-events. EVENT-PATH: Formal: path which is directed, finite, and bounded with a begin-point, an endpoint, and a sequence of midpoints between them; Functional: path triggered by a motion-event, that traces or represents the locational (physically necessary spatio-temporal) transition or trajectory of the mover, of a motion-event. To illustrate the role of EVENT PATH in the context of motion, let us consider some examples.