Cognitively Sound Route Directions for Web Services

This paper contributes to current efforts towards automatically generating route directions that are more similar to human verbal route directions, and thus considered to be cognitively easier to access. In particular, the authors suggest including landmarks in route directions, as well as offering different levels of detail to choose from. The paper presents formal procedures to pursue these goals.

While the overall goals of this paper are certainly relevant for this journal and worthwhile pursuing, there are a number of problems, mostly with the presentation, but also in terms of practical matters. In a nutshell, the paper needs to state more clearly right up front what its main novel contribution is (and I will sketch below which elements are presented as new although they, in fact, are not), and it needs to provide clear and specific information about where the required landmark information (including various levels of detail) might come from. Although this is a clear challenge for routing services, the issue is only mentioned in passing by stating 'a suitable dataset offering various information regarding landmarks is provided by OpenStreetMap' (p.7). Here we need much more detail, including how the database suggested by the authors can be automatically filled. If this issue can be solved, the procedures suggested in this paper may be valuable for the automatic generation of route directions, as they make a number of valid points needing to be considered in such an endeavour.

More specific points:

Introduction
Just because human and automatic route directions differ doesn't mean that automatic route directions are less adequate for their purpose. Humans do not provide exact quantitative measures because they do not normally have access to this kind of information; however, this doesn't mean that it hurts when it is included. To take an extreme example (not suggested by the authors): automatic routing services could transform a measure such as '125m' into 'a bit more than 100m' (making it more human-like) - but why would system designers want this? In general, information should only be adapted to a different format if it is actually misleading. Since human problem solvers make use of whatever information they are given, wayfinders can deal with a variety of route direction types. Automatic systems have easy access to metric distances, and so this is what they provide.
The introduction should therefore focus on direct evidence that routing services need to be changed. The examples in Figure 2 (which support the claim that quantitative measures can be harmful) appear to be constructed rather than authentic; I do not know of any routing services that systematically provide ambiguous route instructions such as the ones shown here.

Example 2 (p1) should be in its original language - it would be useful to find an English example.

Footnote 3 (p2) raises a number of questions. How did you do the evaluation? Which routing services were evaluated? What exactly did you look at? I cannot imagine that 10 routing services do not differ in any way at all.

Last paragraph, second column, page 2: Previous research logically cannot confirm your observations!

Your introduction deals in detail with comparisons of human and automatic route directions, but it fails to discuss the results of a study (cited, without going into depth, elsewhere in this paper as no. [23]) that empirically addressed precisely this comparison and also suggested models of granularity.

First paragraph, page 3: you suggest, as your first aim, to remedy 'some confusing terminology' - however, so far your introduction has not raised any terminological issues at all. On the contrary, the state of the art appears to be quite straightforward. If you aim to resolve controversies you will need to motivate the problem first.
Your second aim is not motivated either; it is not clear what you mean by 'wayfinding ontology', and why it is needed. Later, you call this a 'cognitively sound ontology' - I am not sure what this means. Generally (also in the title) the term 'cognitively sound' is problematic; do you mean something like 'more human-like', 'easier to process' (which needs to be proved), 'presented in a way that corresponds to human cognition'? It might be worthwhile reconsidering the terminology chosen so as to reflect your goals more precisely.

I think the first paragraph in section 2.1 can be skipped - it doesn't add anything relevant (route instructions are not interesting because of the linearization problem, but they arguably do not have a linearization problem…!).

Replace 'worthy to mention' by 'worth mentioning' (several places)

What are 'pragmatic semantics'? (page 3)

Are you sure that 'it is assumed that quantitative information needs to be transformed into its qualitative counterpart'? If this is a theoretical position, it needs elaboration - I don't think this is self explanatory or intuitively evident. (Cf. the example above: We might not know exactly how long 125 meters are, but that doesn't mean we translate this information into something else - we might simply go with a rough estimation and be content with the remaining uncertainty.)

Page 4, first paragraph: What do you mean by 'signals'? What does the statement in brackets express ('I do not accept the information you presented') - surely this is not a natural reaction to a route description?

Please reformulate 'Research has long noted…' (Research is not a person)

The last paragraph of section 2, finally, lists some goals of this paper - this should be made much clearer (in an elaborate, well motivated way) right up front. (The last sentence in that paragraph is grammatically flawed)

In section 3.1. you present several previous accounts of route direction elements, repeatedly by referring to previous authors' 'attempts'. This is derogatory and should be avoided. In fact, your proposed ontology builds heavily on this previous work (as it should). More precisely, section 3 does NOT add anything new at all. You do end up with a new (re)classification, but basically you go with Denis' approach, in part modified by new terminology. It is of course not problematic to do so, but please be clear: You propose (in section 4) an ontology that is entirely motivated from previous research, using some distinctions and categorisations proposed by other authors while rejecting some of their finer distinctions (such as Lovelace's meaningful distinction between on-route and off-route landmarks), presumably because they do not appear to be relevant for your current purposes. (If you wanted to achieve a thorough reconciliation of previous classifications you would have to do a far broader review - there's more out there! But I don't think this is your goal).

I am not sure about your category 'Meta' - as seen in Figure 3, this appears on the same level as 'NonLocatingLM', suggesting that you're subsuming descriptions that do not locate a landmark (or anything else) nor describe a landmark, but provide other types of information. So how do you deal with 'walk for 100m' (until the next decision point) - would this be 'Meta' as well? (I think it would be - but shouldn't, because this is not on a meta level.)

What is 'an atomic route instruction' (p6)?

Section 4.2.:
What do you mean by 'creating individuals'? (A brief technological explanation would be helpful)
How do you derive (2) 'ThereIsARestaurantInFrontOfYou' - this is not part of the route instruction. Please explain.
Figures 4 and 5 appear on the next page (it took me a moment to find them) and they require some explanation.

This ontology seems to relate systematically to the (much more comprehensive) GUM ontology presented in
Bateman, John, Joana Hois, Robert J. Ross, and Thora Tenbrink. 2010. A linguistic ontology of space for natural language processing. Artificial Intelligence 174: 1027–1071.
It would be useful if you could briefly outline how they relate (beyond the fact that both use Protégé for formalisation), and motivate why a new ontology is required here.

On p8, are you talking about human-like route segments or about practical / technological solutions for implementation? If the former, please provide a natural language example for '(Edge, Node, Edge)' - this doesn't seem natural to me.

Page 9 seems to suggest that route information should be hard coded in a data base for each direction of travelling. Are you sure this is necessary - and can this be achieved automatically based on available information? Without suggesting procedures for this, it seems like an immense effort - if generic web services are to profit from it. (You only say that 'a database can be populated'.)

What do you mean by 'producing at least qualitative information'?

So the first aim in your paper (providing landmark information) hinges on the availability of data (including populating a database), and as pointed out you need to state much more clearly to what extent this is possible using currently available resources. The second aim (providing different levels of detail in a route description) firstly hinges on the same issue, but secondly has another problem: As you mention (in passing) on page 9, the user needs to specify the desired level of detail up front. This, of course, does not lead to the automatic generation of route directions that sound like human route directions: As shown, for instance, by Tenbrink & Winter (2009), humans flexibly adapt the level of detail according to the presumed needs on the part of the addressee, depending on various context factors. Your paper, in spite of centrally dealing with levels of detail, does not address this problem at all - and on page 9 you seem to downplay it by stating that the user can choose the desired level. Of course, it is nice for a user to be able to obtain further information about any given landmark, but current routing services do already provide various relevant options (Google Maps, for instance, has quite detailed information on buildings of public interest that can be easily accessed using the mouse, interacting with the map) - so you would have to specify what is new about this idea, beyond the suggestion that this kind of hierarchically structured information needs to be in the routing database.

Page 13: I don't think that individuals necessarily generally prefer one reference frame over the other - rather (more relevant for your purposes), some situations may call for one frame rather than the other.

What are 'semantically aware' route instructions?

Note that some routing services already offer choices between the 'fastest' and the 'simplest' route. This is not a major problem needing to be tackled.

The authors present an ontology for route directions with the intention that it will help build routing services that can provide more cognitively sound route descriptions. The proposed classification divided into actions and descriptions is interesting, as is the proposed algorithm for matching route segments in a street network to qualitative descriptions. Bringing the research on landmarks and cognitively sound route directions in line with semantic web technologies is a laudable goal. In addition, I am sympathetic to the goal of creating as simple (and lightweight) of a taxonomy as possible. Unfortunately, in its present form I cannot endorse its publication as a full paper in the journal. The primary reason is that while the paper presents and makes available the ontology, it does not adequately explain why this reclassified ontology for wayfinding is preferable over existing formalizations for various tasks.

The prototypical application shows promise but does not provide a satisfying evaluation demonstrating why this ontology enables better applications than existing methods. If the paper did include such an evaluation then that would improve the impact of the paper, or as alternative if it is repurposed as an "description of ontology" paper that would be preferable. Alternately, if the "prototypical" application can be presented as an available and working application with appropriate evaluation, then it can be written as an application paper.

As far as I can tell, the algorithm only works because the difficult problem of building the dataset of "landmarks relative to a route-segment" is not addressed. Certainly it is possible to e.g. import open street map road network data and POI information, but it is unclear how the two are coupled. How are salient landmarks for a segment identified? A problem further complicated by the context-dependence of the saliency (see Raubal 2004, "Formalizing Conceptual Spaces"). Likewise, the routing information shown in Figure 10 looks good, but only because the authors have hand-picked POIs with descriptions like "with owl sculpture". It is unclear to me how much of the value-added (in terms of "cognitive soundness") comes from the content of these descriptions vs. the structure of the proposed ontology.

The paper also misses some important related work that this research should be put in context with. In particular:

Hansen, Richter, and Klippel (2006) "Landmarks in OpenLS - A Data Structure for Cognitive Ergonomic Route Directions"

Sabine Timprf (2002) "Ontologies of Wayfinding: a Traveler's perspective". This reference is relevant to the the action/description taxonomy presented in this paper for its discussion of actions and operations.

Some comments regarding the writing. Before presenting any research contributions, the introduction spends quite a long time presenting the differences between computer generated descriptions and human route descriptions. This is not a new observation -- it would be better to integrate the many citations listed in the last paragraph of page 2 throughout the text of the introduction. It would also be better to move the contributions of the research earlier on to make it clear where the paper is headed. There is also quite a bit of repetition of content between the introduction and related work sections.

I would refrain from using "LoD" to abbreviate "levels of detail" as that is commonly interpreted as Linked Open Data, especially by the audience of this journal.

Authors discuss in this paper the problem of navigation, and especially the lack of qualitative instructions for the route by the current systems. The paper is well written: the story brings the reader nicely from the problem definition to the ontology and clear application example of the use.

The contribution as I see is an OWL ontology and an excellent literature study that discusses where the concepts of the proposed ontology come from. I have one concern about the description of the ontology: could authors elaborate more about how the inference gets from the asserted model to the inferred model (as briefly described in 4.2). Perhaps an example of one individual and its automatic classification would be enough to make this section more clear. Other than that, the examples and argumentation seem to work.

There is no real evaluation in terms of users actually trying to navigate with the generated qualitative route instructions but that can be a focus of a follow-up work. In any case, getting some more evidence of how well the instructions work in different types of places and with different types of modes of movement would be very interesting and necessary. Are there some differences? Are people able to get more reliably to the destination with qualitative descriptions than with current state-of-the-art tools? Are they more satisfied about the experience? Further on, is it possible to make a real working system out of all the ideas mentioned in the paper? Will there be challenges in building that? If yes, what kind of challenges the authors expect?

Nevertheless, I think this work proposes an interesting and well argued way to produce and deal with qualitative instructions. Thus I suggest a revision that takes into account the comments above and minor comments below.

Minor details that I suggest authors take an action at:

- Fig. 6. is before Fig 4. and Fig 5. Please reorder.
- There are some pointers to other sections (like "See section 5.2.1" in 4.1) which suggests that the structure of the paper is not ideal.
- Please use the full name for OWL (with a reference) when mentioning it for the first time: not all readers now about it.
- Harmonize the use of the acronym for "levels of detail". Now you use LOD and LoD. LOD is especially problematic as it typically refers to Linked Open Data in the Semantic Web community.
- Authors say: "Using the GPS device in your automobile works because it gives you a reasonable accurate measurement of distance to the next decision point. This information is periodically updated as you move. Even then, however, it might not be a good idea to constantly check with the navigation system (traffic!) to figure out when exactly one should turn." I agree that many GPS devices work that way. However, some navigation systems I have experience about tell with a nice voice when and where to turn next. The point is that there is no need to "check", the system simply tells you. So in some of the state-of-the-art systems that are already in production this kind of problem has been at least partially solved?