Surface Network Ontology Design Patterns for Linked Topographic Data

Tracking #: 675-1885

Authors: 
Gaurav Sinha
Dave Kolas
David M Mark
Boleslo E. Romero
E. Lynn Usery
Gary Berg-Cross
Anand Padmanabhan

Responsible editor: 
Krzysztof Janowicz

Submission type: 
Ontology Description
Abstract: 
The vision of Linked Topographic Data (LTD) is critical for the Semantic Web, since topographic data are fundamental to a wide range of geoscientific analyses and mapping of geographic phenomena. LTD involves a synergy between a wide variety of topographic information and services, but at its core is the theme of terrain, i.e., the shape of the earth’s sur-face. Terrain is generally computationally represented using a continuous field data model (2-D surfaces), which contain no explicit reference to identifiable entities. This makes it difficult to share surface datasets on the Semantic Web, which requires stable and meaningful objects that can be assigned independent identities through URIs. Moreover, terrain is understood by people not just as a surface, but more commonly as a wide variety of discrete landforms and landscape features. The semantics of such terrain objects can be made explicit only if discrete object based spatial representations and ontologies explaining the semantics of such objects are made available. Both problems can be addressed by extracting surface networks as discrete object representations of surfaces. A surface network is a collection of shape elements (critical points, lines, and areas) that are topologically connected and collectively describe the global shape of the surface. This paper presents the first ever effort to formalize surface networks as ontology patterns, which are small ontologies intended to capture domain semantics and are easily reusable in different application contexts. The primary pattern called the Surface Network ontology design pattern (SNODP) is intended for any type of surface network, not just terrain surfaces, and is designed to specify only topological relationships between surface network elements. For flexibility, it leaves specification of metric properties of surface network elements to domain-specific spatial ontologies. The second pattern, Geospatial SNODP, extends SNODP for metric geographic space through alignment with the W3C recommended GeoSPARQL spatial ontology. The patterns are designed as OWL ontologies, but all axioms are presented in this paper using the compact DL notation. In addition to a strong justification of the value of these patterns, an LTD motivated case study is also presented to demonstrate how terrain surface networks can be semantically annotated and queried on the Semantic Web with the help of these ontology patterns. The scope of the patterns and their limitations, as determined by the original theory and design choices, are also clearly described through multiple discussions distributed throughout the paper.
Full PDF Version: 
Tags: 
Reviewed

Decision/Status: 
Major Revision

Solicited Reviews:
Click to Expand/Collapse
Review #1
By Antony Galton submitted on 24/Jun/2014
Suggestion:
Minor Revision
Review Comment:

This is well organised and mostly well-written paper which may be of considerable interest to readers of SWJ. The aim of systematising a definitive set of topographical terms in order to facilitate interchange and linkage of data etc is clearly a laudable one, but I'm not convinced that the solution offered meets all the requirements for this. I'm somewhat concerned that a long list of axioms has been given without, apparently, any attempt to determine whether they are consistent or to explore what their consequences are. As noted below, at least one of them seems to me to be questionable. I also worry about whether all possible - or even all plausible - topographical configurations are covered.

Having said that, I am prepared to recommend that the paper be accepted subject to minor revisions to address the points of concern listed below.

p.8, col.2, ll.5-4 up: "which is part of the same hill that the peak is part of", and ll.2-1 up: "which is part of the same dale that the pit is part of" - these are not stated in the axioms, or, as far as I can see, implied by them.

p.9, col.1: There seems to be an inconsistency between a saddle point being "the lowest point on a ridge line connecting two peaks" and "saddle points are the lower end of exactly two ridge lines". The first implies that the whole path from a peak via a saddle to a neighbouring peak is one ridge line; but the second implies that this is composed of two ridge lines, meeting at the saddle. The same inconsistency applies to course lines.

p.9, Axiom 15d. I have evidently not understood the meaning of "pass" and "pale". Why is the saddle point shown in Fig.1, for instance, not simultaneously a pass (because it is the lowest point on a ridge line connecting two peaks) and a pale (because it is the highest point on a course line connecting two pits)? In which case, 15d would be false.

It seems to me that you can have branching ridge lines and course lines. The branch points are in some sense critical points but they are not peaks, pits, or saddles. There are several examples in Fig.4 - mainly branching course lines but also a branching ridge line between Boott Spur and Gulf Peak. In effect we have two ridge lines here which partially overlap. It is not clear how these fit into the theory presented.

The theory seems to assume a kind of "normal" terrain which excludes situations such as a linear peak (i.e., a line of points at the same locally maximal elevation), an areal peak (i.e., an area in which all points are at the same locally maximal elevation - a plateau in other words), the analogous constructions for pits, also discontinuities such as vertical cliffs and overhangs. I presume these are all included in the "uncommon possibilities" referred to in the second paragraph of section 3 on p.5? Are the features mentioned in the last paragraph of section 6.1 in this category as well? The "plateau" type mentioned above does not occur in the dataset in Fig.4 under the analysis given ("there were no flat cells with all equal elevation neighbours" - p.15), but under a coarser granularity for elevation measurement there might be, leading to plateau-like features of geographical significance.

Section 4.1.3. Odd use of the term "Territory" - it doesn't correspond to normal usage, but maybe it is part of some specialised usage which I am not aware of?

I am concerned that not much is said about granularity. This is highly relevant to the definition of things like peaks and troughs. There is a reference to "short-ranged 'noise'" in section 6.2.1 which alludes to this issue. A relevant reference is P. Fisher, T. Cheng, and J. Wood, "Higher Order Vagueness in Geographical Infomation: Empirical Geographical Population of Type n Fuzzy Sets".

p.15, col.2. I'm puzzled by the "universal pit". I thought a pit was defined to be a point? And in any case, postulating this makes the surface non-continuous - here I'm assuming the universal pit is the white space beyond the margin of Fig 4, say: but what elevelation is assigned to it? Also, some ridge lines terminate there too, so it seems to be a "univeral peak" as well.

Further down in the same paragraph: "this limitation is not a serious concern". Saying it is not a serious concern does not mean that it isn't one. I'm not convinced - Fig. 4 seems to point to some inadequacies in the model.

p.16, end of 6.2.1. "quite satisfactorily" - with respect to what criteria? I can't judge if it's satisfactory if I don't know exactly what the target is.

Typos, English etc

Section 1.2, l.11, "post" should be "after" (I can't see that there is ever any justification for using "post" as a preposition in English!) - there is another occurrence near the end of p.5

p.3, col.1, l.22: "a group"

p.4, col.1, l.9 (and repeatedly elsewhere): I'm not sure about the use of the word "bound" - I would say "bounded" here but maybe there's a difference between US and UK English? (In UK English, "bound" is the past participle of "bind", whereas "bounded" is the past participle of "bound").

ibid, l.14, "descend to a single pit"

p.5, col.2, l.14 up: "it might make"

ibid., l.11 up: "and would have made"

p.6, col.1, l.2: Something missing between "topological properties" and "surface netwrod features" - is it "of" or "and"?

p.7, col.2, l.4 up: Delete "from each other" (it's already said by "mutually").

ibid, l.3 up: "brevity's sake"

p.9, col.2, 6 lines above Axiom 17a, "never extend below saddle points"

p.10, col.2, l.3. Spurious "and"

p.11, col.1, ll.7-8, "minimum" or "minimal", not "minima"

p.12, section 5.1, l.7: "location semantics"

p.12, col.2, l.6, "independently"

p.13, section 6.1, l.10, What does "at least" apply to? Do you mean "at least by some groups"? If so, the comma after "least" should be deleted.

ibid, l.6 up: "and are often not"

p.15, col.2, l.5 up: I think you mean "was simple in that it ivolved"

ibid, l.4 up: "higher than that"

ibid, bottom line: "filling pits"

p.15, col.2, 9up: "ridge lines" duplicated

Review #2
By Harith Alani submitted on 11/Jul/2014
Suggestion:
Major Revision
Review Comment:

Major RevisionSurface Network Ontology Design Patterns for Linked Topographic Data

This ontology paper describes SNODP; an ontology pattern for describing topographic relationships between surface objects, and GeoSNODP, which connects SNODP with GeoSPARQL. One use case is presented to demonstrate the use of the proposed ontology patterns.
Paper is generally well written, and the arguments put forward sound convincing. The design decisions of the patterns seem well thought out and justified. The use case is useful, although rather weak due to lack of qualitative and quantitative detail. Ontology papers are expected to be "short", but this submission is 20 pages long, which might be a bit too long for this type of submission.

Many related works are mentioned in the paper, which is very useful. However, there is very little comparison to what has been developed by others, i.e. to other related ontologies. For example, it would have been useful to show how the proposed ontologies compare to what the Ordnance Survey built, and others, to help showing the gaps that SNODP is meant to fill. This is also a requirement in ontology paper submissions.

In the first paragraph of section 3, you seem to argue that there is no need for competency questions here, given that you are trying to represent surface theory. I think this position is not a very defendable one. True that surface theory gives you the requirements you need, but competency questions can help to assess whether the ontology delivers what it promised. Having such questions always make ontology papers, and the proposed ontologies, much stronger.

In Section 6.2.1, what is “short ranged noise”? In this section you explain that you had to apply smoothing 5 times to decrease the number of critical points four folds, with no visually detectable implications. This part is very under described. It is important to know how the smoothing was done, how necessary it is to do this in general, whether it’s a special case of your case study or a common case, what was the resolution before and after each smoothing, and more importantly, what were the quantitate implications of these multiple smoothings. Since this step is changing the data, it must be fully explained and backed up with evidence.

Another related vague step was the filling of cell pits, which is mentioned in the second paragraph of section 6.2.1. How many of such cell pits were filled? “several” is not a scientific answer. You mention that those are “spurious artefacts of data processing” and so they had to be filled. This needs to be far better explained and justified to help us reader understand what needs doing before SNODP can be applied to our datasets.

“However, it can still be said with confidence that this particular surface network abstracts terrain shape quite satisfactorily, keeping in mind certain theoretical limitations” another not too scientific remark I’m afraid. I would suggest replacing such a statement with qualitative and quantitative data to demonstrate this satisfaction level.

In section 6.2.2 you list 5 questions, and use them as examples of sparql queries. Would it not be possible to expand these questions, and use them also as competency questions? Also, are these questions only for GeoSNODP or for SNODP as well? Why not elevate them to fit both?

In the conclusions section, you provide some quantitative data about the use case. I was hoping to see such data, and more of it, in the use case section as well. It is strange to see them only appearing in the conclusions section. Also surprising to see that only here you mention that SNODP is not compliant with OWL 2 profiles, unless I missed it elsewhere! This is significant, to some ontologists, and needs further justification.

minor comments:

Abstract: "first ever effort to formalize surface networks" too strong a claim (probably as strong as it gets). I suggest softening it, especially given that others have done some work on spatial/geographical/topographical ontologies.

"traditional methods that limited domain experts to merely provide feedback to the ontology engineers" I wouldn't portray this is the conventional method. It is certainly the case that ontology design methods include an early step on acquisition of requirement and knowledge from the domain experts. Perhaps not all follow this procedure, but that's practice, not method.

"Large, comprehensive ontologies, especially for a domain as varied and complex as the geospatial domain, are almost guaranteed to be useless, if not also difficult to design and reuse" this statement is rather too strong and over generalised. Later you discuss how SNODP can be integrated with such ontologies anyway. Better rewrite this statement to put this in context.

Section 6.2.1, second paragraph starts with strange character. same paragraph has a missing ‘the’ in “marginally higher [than] that of"

In general, SNODP seems interesting and valuable. The paper is publishable, after some modifications.

Review #3
By Adila Krisnadhi submitted on 24/Jul/2014
Suggestion:
Minor Revision
Review Comment:

The authors presented two ontology patterns. The first one is called Surface Network ODP (SNODP), which models purely topological relationships between elements of a surface network. The second one, GeoSNODP, specializes SNODP for geospatial domain (metric geographic space) through alignment with GeoSPARQL spatial ontology. The authors also described some examples of use case for the patterns in the geospatial domain.

Admittedly, I am not a domain expert, so my understanding regarding the specific notions modeled in the pattern is largely limited to what the authors have described. My review is then more focused on the generic quality of the patterns. After reading through the paper, I suggest a decision of "Minor revision" for the paper as I believe the improvement can be made without major reworking. The detailed review is given below.

ON READABILITY AND CLARITY OF PRESENTATION:

Overall the paper is quite readable. Key notions are well-explained. Illustrations, especially Fig. 1, provide clarity to the key notions modeled in the pattern. Apart from a few minor issues in the writing (detailed at the end of this review), but I think, the paper is generally well-written. The literature review, as far as I can tell as a non-expert of surface network theory, seems adequate.

ON THE PATTERN DESCRIPTION:

One thing I like is the modeling decision to separate purely topological relationship and geospatial information into the primary, more generic SNODP, and the more specific, geospatial-oriented, GeoSNODP. Indeed, this makes the treatment easier to understand and also potentially increases the degree of re-usability of SNODP in non geospatial domains. The resulting patterns are quite well-designed, though there are several issues below that need to be addressed, at least from my point of view

1. In SNODP, the notion of Contour seems to be outside of Surface Network, though it is included to define Basin and Hilltop, which are actually not essential to Surface Network. Section 4.2 briefly explained that contours are often used to represent surfaces independent of the surface network elements. What is a contour anyway? It seems to me that Countour is included simply to enable the non-essential definition of Basin and Hilltop. Is there a more fundamental justification why Contour is included? I think, if Contour is not an essential part of SNODP, it is better to drop it, and we can afterwards define another pattern as a kind of enrichment of SNODP with Contour. On the other hand, if it is essential, there should be a stronger justification than just as a means of defining Basin and Hilltop. Note that in GeoSNODP, Contour is a subclass of geo:Feature, like all of the defined surface network elements.

2. The axiomatization of SNODP looks great, though there are a few things missing/needs improvement for the sake of readability and completeness below:

2a. Please include axiomatization of the domain and range restrictions of the properties in SNODP. If the list is too long, the authors can select some representative axioms to be presented and explain that the others look similar. I suggest the authors to use guarded domain and range restrictions: for a property P with domain A and range B, guarded domain restriction for P is of the form Exists P.B SUBCLASSOF A, and guarded range restriction for P is of the form A SUBCLASSOF Forall P.B

2b. Please use equality, instead of at-least and at-most, in the cardinality restrictions. For example, axiom 4 can be read better if written as: SurfaceNetwork SUBCLASSOF (=1 embeddedIn.Surface).

2c. Would CriticalPoint, SlopeLine, and District be disjoint?

2d. In Axiom 2, why don't the authors use a SurfaceData class (use surfaceData as the property name)? Using this class makes more sense to me than simply using the top class. In the simplest case, SurfaceData contains just URIs that link external resource hosting the surface dataset. I also don't see surfaceData property in the picture.

2e. A few properties seem to have inverse relationship, e.g., embeds and embeddedIn. Why don't the authors assert such an inverse property relationship, e.g., by asserting embeds EQUIVPROPERTYOF inverseOf(embeddedIn)? The authors wrote that property chain reasoning for the inverse properties holds automatically in OWL 2. I don't think this is true, unless the appropriate inverse property axioms are provided.

2f. Please write the axioms explicitly for the transitivity of some of the properties as well as the property chains. This also includes the relevant axioms from the Part-Whole OWL pattern, for the sake of completeness. Also, if such property chains are made explicit, footnote 5 won't be required.

2g. I don't quite understand the discussion regarding instantiating or not instantiating the Surface and SurfaceNetwork classes. If we look at axiom 6, 7, and 8, we can always infer an instance of SurfaceNetwork from any concrete instance of CriticalPoint or District or SlopeLine. By axiom 1 and 2, this will infer an instance of Surface and an instance of SurfaceData. Realistically, I would assume that the data will frequently, if not always, generate instances of CriticalPoint, District, or SlopeLine. Consequently, SurfaceNetwork and Surface will always be instantiated by reasoning anyway. So, such a discussion regarding instantiating Surface and SurfaceNetwork, as in page 7 and 8, is rather meaningless.

2h. Please use surfaceValue instead of SurfaceValue for consistency of property naming. Also, surfaceValue seems to be a simple data property ranging over double values. In the narration, this is intended to record surface heights. The potential problem is that a double value may represent a lot of things, e.g., the value 101.5 may mean 101.5 meters, 101.5 feet, etc. I think this is relatively simple to fix by incorporating unit information to surfaceValue. On the other hand, if I understand correctly, the design motivation in the beginning was to separate topological relationships from metric properties and relationships. Thus, one may suspect that surfaceValue here is a metric property, and possibly better be included in GeoSNODP. I'm inclined to think that surfaceValue is critical for SNODP, but the authors should more clearly explain why this should not simply be put in GeoSNODP.

2i. Axiom 33a is redundant, since it is implied by axiom 33b and 33c.

ON THE CASE STUDY

I find the case study of Presidential Range map adequately justifies GeoSNODP, i.e., the use of GeoSNODP in geospatial domain. Do the authors also have a case study in a non geospatial domain?

OTHER MINOR PRESENTATION ISSUES:

p2, left column (under section 1.1):
- paragraph 1, line 4: dangling parenthesis on "... [17,27])..."
- paragraph 1, line 16: [20-21] --> [20,21]
- paragraph 3, line 36: domain and ontology engineering knowledge experts --> domain experts and ontology engineers?

p2, right column (under section 1.1):
- line 3: ontology pattern design --> the (actual) design of ontology patterns
- line 3/4: Semantic engineering --> Ontology engineering

p2, right column (section 1.2)
- paragraph 2: "The first incentive was to ..." --> there's the first incentive, but not clear what is the second incentive.
- paragraph 2: ".. and the implication for algorithms ... " --> and their implications for algorithms
- paragraph 2: "Thus, the ontology patterns will serve as the basis for other patterns ... " --> You mean: "Thus, the Surface Network Ontology Patterns will serve as the basis for other (ontology) patterns to guide ..."

p3, under section 2.1
- paragraph 2: [39] was the first --> Reech [39] was the first
- paragraph 2: Following the terminology of [52] --> Following the terminology of Warntz [52]

p4:
- left column, 3rd line from bottom: [52-53] --> [52,53]
- right column: Warntz [52] also included --> He also included

p5:
- left column, paragraph 1, section 2.2: Still, there is substantial data abstraction --> Still, there is a substantial data abstraction
- left column, paragraph 3: anal-yses --> ana-lyses
- left column, paragraph 3: [40-41] --> [40,41]
- right column, end of paragraph 2 of section 3: "...never been researched, would have made ..." --> "... never been researched and would have made..."

p6:
- left column, paragraph 3: "... require the storage of .. " --> require the storing of
- right column, paragraph 1: please cite the reference for the OWL 2 standard
- right column, paragraph 1: please cite the reference for the DL notation.

p14:
- right column, 2nd/3rd last line: cells which have the highest cell values --> cells with the highest cell values

p15:
- label of Fig.4: Network --> network
- left column, beginning of paragraph 2: sThe study area --> The study area
- left column, paragraph 2: There are no such regions known to exist in this area --> No such region is known to exist in this area?
- left column, paragraph 2: was simple in that involved raising --> was simple in that it involved raising
- left column, paragraph 2: marginally higher that of --> marginally higher than that of

p16:
- left column paragraph 1 after Section 6.2.2: systemat-ically --> systema-tically
- right column, paragraph 2: GeSPARQL --> GeoSPARQL

p19:
- in acknowledgements, Gary Berg-Cross is mentioned, but he is also co-author. I think, Gary's name should be omitted from the acknowledgements?

p20:
- Reference 35: Is it supposed to be year 2008 or 2010?

Review #4
By Jens Ortmann submitted on 03/Aug/2014
Suggestion:
Reject
Review Comment:

The paper presents an ontology design pattern for surface networks. The ontology design pattern is presented first as Surface Network Ontology Design Pattern and then as specialized Geospatial Surface Network Ontology Design Pattern. The pattern is based on surface network theory and applied to query surface network data extracted from a Digital Elevation Model.

The idea of an ontology design pattern for surface networks is novel, and the paper is well structured. The authors seem competent in the domain of surface network theory. However, there are problems with the formalization of the pattern, with the presentation and also with compliance to submission guidelines. In its current stage the paper is not fit for publication, but the paper can be a valuable contribution if corrected, stripped of unnecessary ballast and unwarranted claims, and motivated by a concrete, real domain problem.

The first problem with this paper is, that it makes many bold and sometimes even wrong claims that are not backed up properly. This starts already with the first sentence of the abstract. The pattern is largely motivated from a vision called “Linked Topographic Data”. The vision seems to be not much more than linking data using the pattern, so that the motivation for the pattern is circular. No real motivating use case or domain problem is brought forward, where the need and benefit can be seen. Furthermore, the Linked Topographic Data vision seems to be mainly the personal agenda of the first author, and no real evidence is given to back up the claimed importance. A presentation in one track of the annual AAG meeting does not qualify to back up the claims made. Even worse, the paper claims that the vision “is critical for the Semantic Web”. This claim cannot be accepted to stand like that in a semantic web journal. There is no reason presented how Linked Topographic Data would help with any of the issues of the semantic web. Too little data is definitely not the problem. Instead the pattern should be motivated from real applications or needs and problems in the domain to answer questions that cannot be answered without using the pattern. If the claims made about the importance of the pattern and the Linked Topographic Data vision, it should be very easy to find several really compelling examples. In its current stage the relevance of the ontology is unclear.
The second problem is that there are inconsistencies in the formalization and description. The use of direct parthood between peak-hilltop, hilltop-hill and then also between peak-hill cannot be true at the same time. The modeling of dependency between surface and surface network is flawed. Moreover, the alignment of mathematical objects to the GeoSPARQL class for physical object (even though mentioned by the authors!) simply cannot be true. Cardinality restrictions are first ruled out and then used. Reasoning concerns are used to back up an assumption, and later the ontology turns out to be not tractable anyways.
The third problem, is the sheer length of the paper. Even though advised in a previous round of reviews, the paper has not been shortened, but actually been extended! The paper could do with half the length, if the focus was on the actual pattern and its application. The length hampers the readability and clarity of the paper and violates the submission guideline of ontology descriptions to be brief and pointed. The confusion of terms like “linked data” – “semantic web”, or “meaningful” - “semantic” and the use of “semantic” in conjunction with words like “spatial”, “essential” or “class” makes it more difficult to understand what the authors want to convey and where they see the benefit.
Finally, if not giving an evaluation, at least a critical review of what the pattern contributes (and to whom), where it falls short of the domain needs and what can be done that was not possible before should be given, ideally tied to real application scenarios or competency questions (as suggested in a the previous round of reviews).

Detailed comments:

Section 1
The terms linked data and semantic web are mixed up. While the semantic web relies on ontologies, linked data does not even require formal semantics or logical languages.
It is unclear how the requirement for minimalism derives from diversity, and the claim that “large, comprehensive ontologies […] are almost guaranteed to be useless” is already wrong in the geo-domain with SWEET being a prominent counterexample.
The lengthy discussion of the processes at the GeoVoCamps does not contribute to understanding the pattern and should be removed. Acknowledgements to the GeoVoCamp should go into the acknowledgements section at the end of the paper.
The long discussion of Linked Topographic Data does not help with the pattern and should be removed from the paper. Instead a real life problem from the domain should motivate the pattern.

Section 2
Section 2 provides the background on Surface Network theory. Generally the section is ok, but it should be shortened, especially by focusing on the theory, and no so much on the people who developed it.
I still do not understand the mathematical difference between a pass and a pale.

Section 3
The rationale leaves many questions open. It comprises rather general talk about patterns and the GeoVoCamp. Competency questions and use cases are mentioned, but none are given in the paper. The main idea is presented in one paragraph in the middle where the division into two patterns is explained: One pattern with a geo-independent pattern and an extension for the geo domain. Even though, the terminology of the surface network theory (hill, peak, dale, …) indicates a strong influence of the geo domain on the theory. Section 3 can be shortened dramatically, and I would even suggested removing it completely and including the essential parts in the introduction & motivation section.

Section 4
Section 4 presents the actual surface network ontology design pattern in OWL. The pattern is intended to be applicable to domains outside geoscience, but the terminology is borrowed from geography. The general idea of the pattern seems feasible, and the classes make sense, but the formalization contains several issues and the description should be made more explicit and clear in some places.
It is not clear what is a “fundamental relationship” between the surface and the surface network. What is the difference to a non-fundamental relationship? What makes this relationship fundamental? And why is a relationship between a real world object and a mathematical object fundamental?
The dependency of the surface network on the surface is stated in the text, but not captured in the formalization. Axiom 1 does not express a dependency of the Surface network on the Surface! Here one of the (later shun) foundational ontologies would help, I do not know SUMO in detail, but DOLCE and BFO have good and mature formalizations of dependency.
The reason for the class surface to be uninstantiated is not clear, especially because later on in the use case it turns out that the class needs to be instantiated.
Axiom 4 introduces cardinality restrictions. In section 4.1 an argument was made against cardinality restrictions.
It is not clear what the parts of the class surface network are, in particular, it is not clear what a part of a class is at all, nor what “essential semantics” are.
Making reasoning simpler is given as the reason to assume the uniqueness of the parts of the surface class, yet, later in the paper it is acknowledged that the formal language the pattern is encoded in is not even tractable for reasoners. Thus, simpler reasoning cannot be a reason here.
The intention of the surface value is not clear. The value is not restricted in any way. It is also not clear why for example a critical point must have exactly one surface value.
The direct parthood is misused. The peak is a direct part of a hill and of a hilltop, and the hill is a direct part of a hilltop, too. Thus, the peak is a direct part of the hill, as well as an indirect part of it. That should not be possible.

Section 5
Section 5 presents the extension of the Surface Network Ontology Design Pattern for the geospatial domain. It is unclear however, what spatial semantics are, and how the geo extension adds this to the Surface Network Ontology Design Pattern.
The major problem with the extension is the alignment to GeoSPARQL, which knowingly contradicts the specification of the surface network. The suggestions that the GeoSPARQL class for real objects must subsume the classes representing mathematical objects renders the whole alignment inconsistent and the confusion of mathematical objects and real objects harms the semantic integration of data.
The part on heights can be shortened.

Section 6
Section 6 presents a small use case for the Geospatial Surface Network Ontology Design Pattern. The first subsection posits the ontology design pattern as a kind of upper level ontology for terrains. This subsection repeats many of the things said before, and reiterates the development story of the pattern. It does not make a convincing claim how the pattern can be a suitable core ontology. This subsection can be drastically shortened.
The use case is about extracting the surface network of a small area and storing it as OWL. The queries presented as evidence for the application are all rather simple, no real application or domain need is presented to make a stronger claim for the usefulness of the pattern. Who should use the pattern and how? Should datasets be automatically harvested like in the use case, of are the problems where the manual application is useful?
Several claims about what can be said with confidence, what is important or what is a clear benefit are made, without giving a proper reason for it. Especially, the many unwarranted qualifications of things as “important” are irritating. Instead, examples of concrete real benefits should be given.
The alignment with a gazetteer is a good idea, but it leaves the question which queries can be answered with the presented pattern, that cannot be answered by the gazetteer alone.

Section 7
The integration with other ontologies discusses a potential alignment with three foundational ontologies, concluding that none of them is suitable as an upper ontology for the pattern. This should already raise some red flags that there might be something wrong (such as the alignment to GeoSPARQL and the modeling of dependencies). The final part of the section is speculative (as indicated by the use of “would”, “could”, …). I suggest to remove the section and if necessary keep a few parts as future work. The decision to not use foundational ontologies would have been better explained in section 3.

Section 8
The conclusion sums up the goals and presents some new(!) findings on the use of the pattern. In particular on how the pattern abstracts data. Representing a 13,5MB uncompressed raster format as 3,5MB RDF seems not very sparse, it is compression of raw raster data by factor four.
What is more interesting is the amount of information that is lost during the abstraction process. The paper should also discuss this, what is lost and what is gained? What are the great new things that people can do to solve their problems that they could not do without the pattern?

Minor things
Being abstract and being understandable by non-logicians are two different things. Abstract and logic do not mean the same.
In 1.2 the heading is missing the word “pattern” and the second goal is missing in the text.
The term “Geomorphometry” should be explained.
4.1.1: “A basin provides additional “context” to the pit”, what is “context” here and what is “’context’” in quotation marks?
6.1. What is “’core’” in quotation marks?
6.2.1 How does the pattern deal with flat regions?
6.2.2: GeSPARQL -> GeoSPARQL
What are “important mountain passes”? How do you measure or judge the importance?
What is “important information about the topographic eminences”? How do you judge or measure the importance of the information?
8: Who is “the LTD community”?
What is the “wealth of information” that can be unlocked? Are there any concrete examples to support this?
What is “relatively comprehensible”? Relative to what?
What are the “rare cases” that are not covered by the pattern? Are they generally rare, or only rare in the geo domain? Any evidence for the claim?
Reference: presemted -> presented