Ontology-based digital map integration

This paper introduces a two-level map ontology for the application of autonomous driving. Particularly, the ontology is designed to integrate maps in various formats following the Global-as-View architecture. The experiment also shows that it can be used to check inconsistency and reduce data size. The work is interesting, the paper is well structured, and the experiment is solid. However, I have some major concerns summarized according to reviewer criteria:

(1) Quality and relevance of the described ontology (convincing evidence must be provided).
- HLM ontology is the core of this paper. It is adopted from the HLM ontology requirements specification. I am skeptical on numerous points on the design though:
(a). What is the difference between “Current location” and “Current position”? Based on the definitions on Table 1, they seem to be the same. In Fig 4 (HLM ontology), only class Position is modeled. Then it makes me wondering how does Table 1 helped the design of HLM? Are they consistent?
(b). The geometry of RoadPart and Lane is represented as a set of Point with x and y coordinates. Why not use GeoSPARQL to directly represent the geometry of Lane as a line, for example?
(c). What is SpatialWindow in HLM? How different is it from Current Position? More elaboration and examples are needed.
(d). Page 10 line 7, Left/right is not technically topological relations. It is in fact ternary relations. Namely, the direction of the lane plays roles. So I believe the rules (binary) listed here do not work for left/right relations.
(e). Page 10 line 19, why CoordinateDistance is a ternary relation? There are only two points involved: source and target.
(f). Page 13 line 14-16, I am not sure why the name space and naming convention of the Core Ontology is changed, and how come it is a “good practice”? Will it impact the interoperability of the ontology?
(g). Page 16 line 32, in addition to simple 1-to-1 and complex n-1 transformation, will there be 1-n transformation? Also, how to validate the rules?

(2) Illustration, clarity and readability of the describing paper, which shall convey to the reader the key aspects of the described ontology.
- Figure 4, 7, and 8 need further elaborations. These figures show the high- and low-level ontology. Readers would better understand them if more detailed explanations and examples were provided. Otherwise, it is hard to justify the validity of the ontology. There might be many other ways to achieve the same modeling goal.

(3). Please also assess the data file provided by the authors under “Long-term stable URL for resources”. In particular, assess (A) whether the data file is well organized and in particular contains a README file which makes it easy for you to assess the data, (B) whether the provided resources appear to be complete for replication of experiments, and if not, why, (C) whether the chosen repository, if it is not GitHub, Figshare or Zenodo, is appropriate for long-term repository discoverability,
- The authors provide a GitHub page where the ontology diagram and the OWL file are documented. However, only the high-level HML is provided and I do not see the lower-level ontologies even though the paper discussed them. Also, the README is barely helpful for one to understand the GitHub directory. It needs substantial improvement to make the work replicable.

(4) whether the provided data artifacts are complete. Please refer to the reviewer instructions and the FAQ for further information.
- No data artifacts are provided, even though I think the authors should do provide the experiment data artifacts so that readers can test the data, the rulers, and the integration process in general.

In this article, the authors propose an ontology that can be used to integrate digital dynamic map data in autonomous driving. The high-level map (HLM) ontology was evaluated based on applying it to two different standard map data models. The authors translated the latter models to RDF, using Datalog rules to semantically enrich them with knowledge that can be used to query maps from a driving vehicle, as well as rules to map the different data models to the higher level ontology for finding inconsistencies and for firing common queries over both.

Overall, I think ontologies of dynamic map data for autonomous driving is a relevant subject of research, and I think the authors do a good job in modeling the most relevant functions of such kind of data for dynamic vehicle knowledge while driving. However I think that there are still many structural weaknesses in the way the paper is organized. The main weaknesses are:

- Article goal: The authors introduce the article by stating that they want to target dynamic vehicle knowledge, without explaining anywhere in the paper (except for some secondary details in table 1) what this kind of knowledge precisely consists in. What exactly does such a system need to be able to do? Such requirements are in order to judge whether goals were actually achieved using this ontology. A better way to structure the paper would therefore be to first introduce competency questions or use cases that capture essential knowledge tasks, and then show in the evaluation section that the ontology can answer them. Such goals could be diverse, including vehicle queries as well as integration goals. It should also be explicitly mentioned that the goal of translating between ontologies in this case only concerns the ABox (the facts/map data), not a mapping between ontological concepts (TBox). The latter was done manually I guess? The current paper lacks details about how this mapping was done.

- A related problem of the article is that one of its purported subgoals is way too general for the task at hand. To "propose a practical methodology for building a generic high-level ontology" would be on a meta-level of ontology engineering, and quite unrelated to the task. What the authors do there (methodology section) is neither convincing as a general ontology engineering, nor is it needed for the actual goal to propose an ontology for dynamic vehicle knowledge. Instead, I would recommend to entirely remove all "meta" -level aspirations in this paper. Instead, the authors should just follow a standard ontology engineering approach (such as METHONTOLOGY) for mapping/translating ontologies (consisting of the indicated steps outlined in section 3). Methodologically, this would mean however that everying in table 1 needs to be part of the argumentative flow of the article, and not just listed in a table. Thus: the authors should start to describe the scope and purpose, and the requirements of the ontology in the paper (not in table 1), before they describe the ontology design and before they finally evaluate it. That is, Table 1, in a way, needs to become the first half of the article, and goal 1 on page 2 needs to be removed and rewritten.

- Related to this last point is also that the current title of the article is way too general. It pretends to suggest a general solution for "ontology-based map integration". Yet what it does is only proposing an ontology for intregrating a particual kind of map data, namely road data for dynamic vehicle driving. This needs to be changed to scale down expectations, given that there are hundreds of other types of map data about which this article does not anything have to say.

- The conceptualisation in 5.3 is in a way the most important part of the paper because it describes the HLM ontology. It should be in its own section. Currently it remains however unclear how the related ODPs were actually used here. Also later in 6.1, it would be better to make examples to illustrate how these models were used in context.

- The reasoning as well as computations are currently implemented in Datalog. This has the advantage that relations as well as computational tasks can all be expressed in one language, but the drawback is lack of efficiency. Probably one might want to use graph algorithms in order to efficiently determine distances over a road network, not Datalog rules. Why do the authors think this could be a generalizable implementation model for vehicle software? I think this is a confusion of data models and conceptual models: One might use an efficient data model for computation, and still use another conceptual model for data integration tasks.

- Regarding the evaluation, it remains unclear how this evaluation answers the goal set in the introduction. Why are inconsistency detection , data aggregation and unified map view needed for the goal? Furthermore, it seems to me that the second aspect of evaluation (data aggregation) is not beneficial because (as the authors say) of the reduction of data, but rather because you can change map representations from models of higher resolution to lower resolution, and back. Note the difference: the task seems about a change of resolution levels in all directions, not one of reducing amounts of data. In general, the authors need to better evaluate their ontology.

- Regarding clarity and readability, I think the HLM ontology classes should be better illustrated with examples in order to better understand what they are used for. Furthermore, there are some conceptual issues with these classes that remained unclear to me: we have the concepts "path", 'route' and 'road(part)' that somehow refer to a road network. But it remains unclear to me whether the authors mean a road network (graph) or rather a linear route (taken by some vehicle) with such concepts. Thus, the paper remains unclear with respect to its most central concepts.

Data file: a ttl file on github without readme, which does not contain the code to replicate any experiment (e.g, in Datalog). Data artefacts seem incomplete.

Summary: This paper discusses the development of a high-level map ontology that provides a generic and unified view of the road environment. The purpose of this is to allow integration of digital maps of different formats, and using different map models and ultimately allowing them to be used in Automated Driving systems efficiently. This paper describes the methodologies that were used to build the low-level map specific ontologies (LNDS and LHERE), the high-level generic map (HLM) ontology and the transformation between the two-level ontologies. Finally they evaluate the two-level ontologies through some use cases. Moreover this work builds on the authors’ previous work on building a static module of the same ontology (i.e., in this paper they demonstrate the methodological framework and show how it can be made dynamic by integrating another HD map).

Overall Review: Overall I think the paper targets a very interesting and important use-case, i.e. the use of ontologies (that combines both static and dynamic information) in the setting of autonomous driving. The paper is motivated by reviewing limitations of existing approaches that do not accommodate dynamic data input, semantic enrichment of data, and data aggregation at the global level in the general road environment setting. Existing ontologies also do not model certain critical information (e.g. lane information) that is important to support autonomous driving functions. These are some limitations that the authors in this paper set out to address. Therefore I consider the impact of this work would be very high in the domain of autonomous driving, where good knowledge representation models in addition to other forms of AI technologies are an absolute necessity.

The manuscript not only requires some language cleanup, but some significant rearrangement of content for a better flow. For instance in a rule in Page 10 you use the relation hasSource, but I do not know what it means or where it comes from until I get to Fig 7 on page 14. Overall I think the paper needs some reorganization for better readability and understanding. The paper also needs a lot of additional technical description, especially descriptions for rules and concepts/properties indicated in the schema-diagram and text. I had to guess the semantics of about 90% of concepts/properties mentioned in this paper. A good ontology paper should describe all the concepts and properties that they talk about and not just include it in the diagram. A schema diagram is absolutely necessary, but additional description in the text is vital too. If you are re-using concepts from a previously published paper, at least a one line description should be added here as well. Same thing goes for rules/axioms. A big issue I found in this paper is that random concepts, relations pop-up here and there and I have no idea what they mean. And when they are used in rules, I do not know how to interpret them or what variables they take. Although I found the paper very interesting, this paper makes the reader do a lot of guess-work, which made reading it quite exhausting. I have listed below for a list of issues, which from my perspective definitely needs to be addressed and fixed if this has to be accepted to be published in SWJ:

1. Page 3, line 13 - Imran and Young [22] demonstrate the potential of formal reference ontologies to support interoperability – how is this relevant to this work? Isn't that the purpose of ontologies in general? What is the focus of this reference to the work in this paper?
2. Page 5, Section 3.1 - II would suggest that the authors mention at the beginning or the end of Section 3.1 that they intend to use METHONTOLOGY for the high-level map ontology. That may be obvious to the authors but not to the readers at first glance.
3. Page 5 - Why are the stages of METHONTOLOGY italicized with Pascal Case, whereas the stages in the bottom-up approach are bulleted with regular case? I would suggest being consistent.
4. Page 7 - Table 1 provides HLM ontology specifications - under Location Awareness - line 11, isn't the current position specified by a GPS position.
5. Page 7, line 34 – NFR1.The ontology must follow the naming conventions — what are the naming conventions or maybe provide suitable citation.
6. Page 7, line 42 – QC9 under CQG1 – Is lane diver supposed to be lane divider?
7. Page 7 - Fig 4 – in the top diagram, hasTrafficSign is mis-spelt.
8. Page 9, referring to Fig 4 – As someone who is not an expert in the transportation domain, I would have appreciated it if there was some sort of an abstract diagram that mapped some of the concepts to objects in the real-world. For instance a figure that actually depicts the lateral and longitudinal road parts that is meant to be indicated using hasSibling and hasNext relations.
9. Page 9 - A little bit of a modeling question here – I see that direction is attributed sort of indirectly to a Route (using the hasStart and hasEnd relations). But I see that in the (traffic)-direction of a RoadPart or Lane is not modeled? Is that on purpose? I would assume that for driving purposes knowing the driving direction of a road segment is crucial, and many road datasets capture this sort of detail.
10. Page 9 - Fig 4 – the relation hasNext in the ontology ttl file is domain and range set as RoadPart. Is this exclusive? The schema diagram indicates the relation to also be between instances of the Lane class.
11. How are existing ontologies re-used in the modeling? You mention it in Table 1 in Page 4, but I do not see it actually executed. For instance the Point class can be mapped to Point in GeoSPARQL standard, but it is not mentioned in the paper.
12. Page 9, Fig 4 – Spell out entire relations in the figure. For instance, remaining/travelledDisOnRoad/Lane —-> remainingDisOnRoad; remainingDisOnLane; travelledDisOnRoad; travelledDisOnLane.
13. Page 9, Fig 4 - Why are Position and CurrentPosition two different classes — what is the purpose of distinguishing them? Likewise what is the difference between RoadPart and CurrentRoadPart. I understand that this is meant to capture the current localized position of a vehicle, but maybe instead of introducing new classes say CurrentRoadPart, you can make the relation isOnRoad to be more semantically meaningful (say isCurrentlyOnRoad), and have the range of it to be RoadPart?? Otherwise it also makes sense to include some temporal attributes to CurrentRoadPart and CurrentLane, to state that the was the RoadPart/Lane occupied by a vehicle at a particular point of time.
14. Page 9, line 32 - that sentence does not make sense to me, perhaps it is not constructed the way it was meant to be?
15. Page 9, line 49 – what is the hasIdx relations?
16. Page 9, line 49 and page 10, line 2 (including the other examples that follow) – would be a lot better if there was a description against each example mentioning what that specific formula/rule actually means.
17. Page 10, lines 9-10 – how are the two rules here different from saying hasNext(x,y) is a transitive object property?
18. I do not see a lot of the rules from the paper in the ttl file. For example, I do not see the EndLane, or other topological and distance rules. Is that intentionally left out? If so, why? The paper must be written with future readers and their interests in mind, therefore I suggest to also include all the rules as supplementary material.
19. According to NFR2. in the HLM ontology requirements specification document, which mentions “re-use existing ontologies” I would assume that you may have take a look at some of the key W3C standards for space and time (GeoSPARQL and OWL-Time). Earlier on in the paper GeoSPARQL was briefly touched upon. So why are none of the spatial functions from GeoSPARQL such as distance reused here. Essentially are you trying to write a new rule here to calculate distance between two point coordinates? If this is intentional, maybe you should clarify why the distance function from GeoSPARQL cannot be re-used. Also what are the input variables for CoordinateDistance, hasSource, hasTarget ?? They appear here all of a sudden, and they were not mentioned in the schema description in the previous page, nor do they exist in the ttl file.
20. Page 11 – the relation hasImmediatePrevious from the figure and the text below is not mentioned in the ttl.
21. Page 11 – the rule in line 39, 40 does not make sense. Where is remainingDistance defined? The formulas in the figure need to be written out as rules as well?
22. Page 12 – Fig 6 – As I understand you start with CurrentRoadPart, and you iterate to the immediate next road part.
23. Page 12, line 24 – what is the isPlanned relation – this is suddenly introduced here.
24. Page 12, line 30 – what is isMaxProbability?
25. Page 12, line 41 – the rule is missing a closing parentheses
26. Section 5.4.1 talks about re-used ontologies. But then in page 13, line 17, you mention renaming classes to follow the CamelCase naming convention. This is not ontology re-use. You can reuse a pattern this way, but it's hard to say you are reusing an ontology this way. When you say ontology reuse you are using the concept names verbatim, but in the new namespace.
27. Page 14, lines 36, 37 - how is a data property used to “infer” relationships between entities?? Or do you mean to say the lane group ID relates or is an identifier for instances of Lane, LaneGroup, and LaneBoundary? Infer in the context of ontologies generally means deduction using a set of rules.
28. Given the fact the you are overviewing the LNDS ontology in Section 6.1, I think it would definitely be helpful to mention at least in one sentence what some of the concepts in Table 3 mean, because clearly they are not part of the HLM ttl file e.g. what are lnds:Link, lnds:ShapePoint, lnds:Tile?
29. Page 15, line 27 – the rule written here is incorrect. Looking at the schema diagram the range of laneGroupId is a xsd:integer. So the correct way of writing this would be:
hasLane(x,y) ← LaneGroup(x), laneGroupId(x,i), Lane(y), laneGroupId(y,j), (i = j)

30. Page 15 - Likewise, as the previous comment the same can be said for the rule on line 33, however I don’t even know what speed, and speedVal relations are. They are not mentioned or described previously. I cannot really evaluate your complex transformation rule because I do not know what hasConn is, as it is not described. Also do you have the entire list of transformation rules for both LNDS and LHERE documented somewhere that can be publicly accessed?
31. Page 18, line 48 – the ego vehicle is white rather than black as mentioned? I see that E is white in the figure below.
32. Fig 10, caption – spell out the entire relation as-is in the diagram/ontology, otherwise it is confusing to a reader. If you want to abbreviate it, you have to mention this somewhere.
33. The example in Section 7.2.1 is not clear or there are some problems. Let me try to understand it a bit here. All the relations (isInFrontOf, isInRightFrontOf, isIn) between objects in the middle box in Fig 10 are obtained from the Object Tracking System. In that case if you say isInFrontOf(E,C2), then that means the isIn(E, Lane2), but the figure is missing this. In such a case once a Fault is determined how do you actually say which position statement is actually incorrect?
34. For the example in Section 7.2.2, how do you deal with aggregating the geometries of individual lanes. I think this is crucial, given that in Fig 8. You indicate that lanes have an associated ShapePoint.
35. Was the query in Section 7.2.3 tested on the data-graph? If so, what is the efficiency/query-time? I am curious because you do not use GeoSPARQL, which has a lot of inbuilt spatial functions to do some of these operations.

Other Language Fixes:
1. Page 1, line 41 - commas following “LiDAR(light detection and ranging)” and “Global Navigation Satellite Systems (GNSS) [4]”
Section 2.1 - While referring to related work please be consistent with tense. In some places you use present tense (page 3, line 13), whereas in some places you use past tense (line 10).
2. Page 2, line 17 - existing work → existing works
3. Page 5, line 22 - semicolon must follow “population of the ontology using the data sources”
4. Page 9, line 32 - Vehilce → Vehicle
5. Page 10, lines 44 - 45 – This sentence can be rephrased a little to simplify reading, such that there is not not an example inside an example.
6. Page 10, line 50 - vehicles → vehicle.
7. Page 10, line 51 - manoeuvre decisions → manoeuvring decisions.
8. Page 14, line 28 - semicolon must be a full-stop?
9. Please refer to this to see how to properly use commas, especially when writing a list (https://www.grammarly.com/blog/how-to-use-commas-in-your-writing/).
10. Page 19, line 35 – In order model → In order to model