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?
|