Review Comment:
The paper presents two Ontology Design Patterns (ODPs) for expressing surface network concepts, intended as a vocabulary for Linked Topological Data. Although the paper fits the scope of the journal very well, is clear and well-written, and contains a comprehensible yet easily understandable (by non-experts in the field) explanation section on the notions involved in surface networks, there are also some things lacking in the paper that makes me inclined to view it as unsuitable to be directly published in its current form.
I find the topic of publishing descriptions of ODPs of high importance, and presented in the right way such a publication would be a high-quality research paper. However, as the paper is written now, it contains more of an engineering contribution, rather than a research one. From my point of view the paper lacks two important elements:
1) A clear description of the requirements of the ODPs, and a verification of how these are met in the ODPs.
2) A clear motivating use case and/or case study, that shows the benefits of the ODPs.
With respect to 1) the lack of clearly expressed requirements makes the resulting ODPs seem almost like ad-hoc engineering artefacts, rather than carefully designed research contributions. I would suggest that the authors list a number of requirements that are currently not met in any existing ontologies or ODPs of the field, and then when presenting the actual ODPs, relate to that set of requirements to show how they have been realized in the models. Detailed requirements can be expressed as textual descriptions of the concepts, properties, and axioms needed, but could also be semi-formalized into so-called competency questions (which in turn should be possible to express as queries, e.g. SPARQL queries, over the asserted or inferred statements of the model and its associated data), complemented by inference requirements (i.e. expressing what will be asserted and what should be possible to infer from the asserted statements in a dataset). More general requirements could also be expressed, such as requirements on reasoning capabilities in general, which in turn renders requirements on the expressivity of the OWL profile to use, and on the other hand efficiency requirements (for querying and reasoning), which may set restrictions on what profile could be used for efficiency reasons.
Requirements should also be clearly motivated, with respect to some real-world scenarios or use cases that are envisioned, which relates to issue number 2). In this way, the selection of requirements does not in turn appear ad-hoc, but carefully motivated by real-world conditions. At the moment the model is mainly motivated through its theoretical foundations, and some high-level discussions of potential applications (in 2.2, 3.1 and 3.2 and further in 5.3 and 5.4). Theoretical foundations is not a less important topic, but mainly guides the realization of the model, e.g. its concrete terminology and axioms, but concepts being present in related theory does not necessarily mean that they are required to be present in the ODP, without an additional practically motivated requirement. However, such practical (ideally real-world) motivations are only mentioned very briefly, and on a high level - this needs to be further detailed in the paper so that the reader can follow the chain of motivation from use case/usage scenario, to ODP requirement, to ODP realization. For instance, the paper mentions Linked Topographic Data several times (e.g. in 5.4), but there is no running example, nor any detailed presentation of a use case that shows the benefits of Linked Topographic Data and how it can be realized, nor how the ODPs would be used to reach those benefits. I am not claiming that the authors need a formal evaluation of their ODPs (how to truly evaluate a pattern is still an open research question) but rather something that motivates how they have been realized, and clearly shows the need for the particular classes/properties/axioms that are indeed included in the patterns, at a concrete level rather than the abstract and theoretical discussions that are now present in the paper. The detailed theory discussion has a value of its own by both introducing the meaning of the concepts and expressing related work in conceptualizing the field of surface networks, hence, it should not be removed, but in my opinion it cannot replace the practical motivation through use cases that is currently missing.
The closest the paper comes to a list of requirements is in the conclusions section, where a number of general "features" are listed and discussed. However, the claims concerning how these are realized are poorly supported by the rest of the paper, and many statements are quite fuzzy. For instance:
- Expressive: What does it mean that both patterns are "quite expressive"? How expressive are they actually? What OWL profile? Why do they need to be expressive in the first place, what are the reasoning tasks they are to be used for? And the use of OWL in itself, according to the authors, "opens up the patterns to a wide range of inferences." - Well, that all depends on how OWL is used in the patterns!
- Simple: "since ontology patterns are about data sharing" - in general? Why? Some patterns may very well be about complex reasoning. "...minimum number of classes that are needed to semantically annotate typical surface network datasets..." - how do we know that? What are those typical datasets? What do they contain? How have you assured that the number of classes are at a minimum?
- Reusable: "The two patterns are quite generalized..." - How general is that? Can you show that they can cover different scenarios? What type of scenarios? Have they been applied in several different case studies?
- Scalable: This section talks more about surface networks as such, rather than about the patterns being scalable or not. To determine if they are, you need a deeper discussion on the tasks they are to be used for, e.g. querying, reasoning etc., and how the expressivity and other features of their design support those tasks in a scalable manner, e.g. though query optimization, or efficient reasoning due to the OWL profile chosen etc.
- Well-documented: The authors claim that the OWL-files contain comments, but the only "comment" I can find is the dc:description and other metadata of the ontology itself, however, the classes and properties are not documented at all through comments.
An additional issue that is not discussed clearly in the paper is the community support for the ODPs. VoCamps are great opportunities to get together and model some vocabulary, however, it is not necessarily the "right" people that happen to appear in each VoCamp, in terms of the actual users of such vocabularies. How will potential vocabulary users, e.g. data publishers, be made aware of the ODPs? Will you work towards some kind of standard/recommendation? Or simply publish the patterns in some ODP or ontology repositories and hope that people start to use them? How do the authors intend to assure that consensus is reached on their ODPs? What is the estimated level of consensus at present, e.g. have major stakeholders in Linked Topographic Data, for instance, already been involved in the process, or is this the next step? Have the ODPs already undergone several iterations of revisions, or is this a presentation of a first proposal? Are there other competing attempts to model surface networks? What has been the uptake so far of the ODPs, for what datasets are they used, in what projects? If the consensus of the patterns is in an early stage, then the authors should at least discuss their plans for reaching both some level of consensus and a certain level of uptake, and if the consensus and uptake is already high this should be described in the paper.
Detailed/minor issues:
- The acronym SNODP appears in the abstract without being introduced.
- Page 2, 1st paragraph: What does "...lack of reason-ability [58]." mean?
- Page 2, section 1.2, 1st paragraph: "The goal is to focus on a tractable concept..." sounds like a VoCamp always creates *one* single vocabulary for *one* concept.
- Page 2, section 1.2, 1st paragaph: Missing ")" at the end of the last sentence.
- Page 3, second paragraph: "Another major contribution of this work is the realization that surface network ontology..." -> "Another major contribution of this work is the realization that a surface network ontology..." ? Ontology, not pattern?
- Page 3, third paragraph: You mention several existing efforts for creating related ontologies - how do these relate to your effort more in detail? Can you make a comparison on the level of scope and coverage of concepts, for instance?
- Page 3, fourth paragraph: Do I understand correctly that only the SNODP was created at a GeoVoCamp? How was the GeoSNODP created then?
- Section 3.1, bullet ii: "As noted in [41] notes,..." -> "As noted in [41],..."
- Section 3.1, bullet iv: I am not sure I agree with the line of reasoning here - can a field have a strong cognitive validity in itself, and is the problem of engineering artefacts on the Semantic Web really that they are not models of fields with equally high "cognitive validity"? Many ontologies on the Semantic Web have a strong "common sense" basis, which should clearly give them cognitive validity despite not being based on some formalized field of research. Is the point you are trying to make that the ODPs will be easily understood and adopted, because the field they describe can be quite easily understood? I agree to that, however, I am not sure that this is in contrast with most of the Semantic Web vocabularies today.
- Section 3.2: Several acronyms are used, such as USGS (which I think has never been introduced) and TIN (which was introduced but not used for several pages, hence, the unfamiliar reader will have forgotten it by now) - try to reduce the use of acronyms that are infrequently used and/or not absolutely necessary.
- Section 3.2, first paragraph: Is "MeteorCrater" a given name or just referring to the concept of a meteor crater? Shouldn't it be "meteor craters"?
- Section 3.3, discussing ref. [13]: "...and readily expressible in any logical language." Really? Any? I know that the original intention was to have patterns on the conceptual level, that can then be realized in different concrete logical languages, but this is not really the case in practice, even with the patterns in [13], and there are many kinds of patterns that are tightly tied to a specific logical language.
- Section 3.3, first paragraph, last sentence: Is the text between " " a quote? In that case it needs a citation directly attached to it.
- Section 3.3, second paragraph, first sentence: Do you mean the two ODPs presented in the paper?
- Beginning of section 4: the authors mix a lot between using "Surface Network ODP" "Surface Network pattern" and SNODP, it would be better to stick to one term so that the reader doesn't have to remember that they are all the same. For instance, in the second sentence the authors explicitly say that the pattern name is "Surface Network", i.e. not SNODP or "Surface Network ODP" as it has been called earlier.
- Last sentence of the same paragraph: "that are not already evident from the schematic and the OWL ontology." What is "the schematic"? Also, the reader should not have to look into the actual OWL-file to understand the overall pattern, I hope that the authors do not mean that they are skipping important parts, because they think they are obvious if one looks at the OWL file?
- Subsections of section 4: It is not always clear from the context what "property" means in the text, the authors should be more specific and in each case (where it is not completely obvious) clearly distinguish if they are talking about, for instance, an object property or a datatype property.
- Section 4.1: I am not sure I understand the exact meaning of "These properties are transitive under parthood" that the authors mention. "These properties" seem to refer to the embeds and isEmbeddedIn, but those are not transitive, right? It's the part-of relations that are transitive?
- Later in the same paragraph: So the embeds and hasPart_directly are the two properties that comprise the chain, but which property do they imply? (I can see in the OWL file that it is embeds, but this is not evident from the text.)
- Following sentence: I was not aware that there was an actual OWL implementation that could be imported, attached to the SimplePartWhole OWL pattern that is referenced - please link to the actual OWL file in addition to the description that is now in footnote 8.
- Fig 1: I do not understand the property hasSubClass - is this something you defined in you pattern (which I cannot seem to find in the OWL-files though...)? Why? Why can't you just use the rdfs:subClassOf that is built into the language (and is that the property you mean when you write "SubClass of" in the figure - then better use the prefix and the exact spelling/capitalization)? And how do you exactly define it in a way that doesn't screw up reasoning with a standard OWL DL reasoner?
- Fig. 1: The figure is not that easy to read, when the reader has to constantly switch between reading the legend and looking at the graph structure. Would it be possible to use specific arrows only for a few very frequent properties, e.g. subClassOf and hasPart_directly, and then name the rest inside the actual figure?
- Fig 1: What does an arrow actually denote in terms of OWL axioms? It seems to be different things from case to case. In the case of hasSubClass (which I am not entirely sure how you model in the first place, see above) I guess the domain and range of the property is just any class, as for rdfs:subClassOf? But for properties like embeds, does the arrow indicate that the domain is Surface and the range is SurfaceNetwork? Obviously not, if you look into the file, because none of the properties have domain and range axioms. Or are you using other axioms to express property usage, so that the arrow starting in Surface actually means that there is an axiom expressing that individuals of the Surface class are related to some SurfaceNetwork through this property? This could be the case for embeds, since there is a someValuesFrom-axiom set on the Surface class, but is it the same for all the properties shown? Please make the notation of the figure more clear!
- Last paragraph of 4.1: "The surfaceData object property supported by the class..." What class? Supported?
- Same paragraph: "It takes If access..."???
- End of the paragraph: I am not entirely sure but, I don't think all OWL reasoners do that, i.e. actually add new individuals to the dataset. You mention "OWL rules" so do you mean that a rule-based reasoner would do that? But not for the someValuesFrom restrictions that you are frequently using in the OWL-file?
- Section 4.2: Second sentence, partOf_directly not entirely in italics.
- Section 4.2.1, first paragraph: "All CriticalPoint classes also support..." What do you mean with "support"?
- Overall in section 4: it is not so clear if you are actually describing all the features of the ontology or not. For instance, since you are not mentioning the use of any disjointness axioms, does that mean that none exist (actually, in the file I can see that you do not)? Please make it more clear what you are describing and what you are leaving out from the paper.
- Section 5: I have a hard time understanding the sentence "...when only the locations of critical points and lines are not of interest.."
- Section 5.1: Where can I find the GeoSPARQL ontology? I miss a URI for it.
- Many of the footnotes use the @ sign to say "available @" instead of "available at", which tends to look a bit sloppy in a scientific text.
- Section 5.2, 4th paragraph, last sentence: What does "contained classes" mean?
- Section 6, first paragraph: "Final Geospatial SNODP..." -> "Finally Geospatial SNODP..."
- Section 6, second paragraph: "There also will..." -> "There will also..."
- Section 6, last paragraph: Did you introduce the acronym DEM? TIN was introduced, but at the beginning of the paper, the reader has long since forgotten what it stands for - could you expand the acronyms instead?
- The conclusions section ends in a tone that seems to say that this is just a starting point for what we actually need, and that much more discussion and research is needed to actually arrive at something useful. So what's then the value of the proposed solutions actually?
|