Surface Network Ontology Design Patterns for Linked Topographic Data

Tracking #: 553-1759

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

Responsible editor: 
Pascal Hitzler

Submission type: 
Full Paper
The vision of Linked Topographic Data is critical for the Semantic Web, since topographic data are fundamental to a wide range of geoscientific analyses and mapping of geographic phenomena. Terrain datasets are probably the most im-portant for Linked Topographic Data. Terrain is computationally represented using a continuous field data model (2-D surfaces), but the Semantic Web needs discrete objects for assigning URIs. This prevents terrain surface datasets from being shared on the Semantic Web—which is ironical given the availability of incredibly high resolution terrain data. Surface networks, which are a topologically connected set of shape-critical points, lines, and areal districts, can be used to share information about surfaces on the Semantic Web. In this paper, we reinterpret surface network theory for Linked Topographic Data, and present two OWL ontology design patterns. Surface Network is a template pattern intended for any type of surface network. It formalizes only the topological connections between surface network elements, since formalized of the metric properties requires commitment to a domain-specific spatial ontology. Geospatial SNODP extends SNODP for metric geographic space through alignment with the GeoSPARQL geospatial ontology. It can be used to annotate any geospatial surface network, but is expected to primarily serve as a core terrain ontology for Linked Topographic Data.
Full PDF Version: 


Solicited Reviews:
Click to Expand/Collapse
Review #1
By Eva Blomqvist submitted on 05/Nov/2013
Major Revision
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?

Review #2
Anonymous submitted on 18/Nov/2013
Minor Revision
Review Comment:

This paper presents a study of the surface network theory for Linked Topographic Data and introduces two ontology design patterns: Surface Network ODP (SNODP), and Geospatial Surface Network ODP (Geospatial SNODP).
The authors present, describe and also use resolvables URIs for the patterns, but I'm missing a real use case example of those patterns, even a very simple use case. Moreover, I think the authors can include these patterns in some repository, e.g.,
Minor comments
- (such as this paper and [23].) ... missing )
- within the introduction the authors can also comment the efforts of the W3C community groups Location and addresses, and Geospatial Semantic Web.
- probably in section two authors can include a Figure that depicts graphical examples of the concepts they want to describe
- currently we only have access to the ttl files, but providing a documentation of the patterns would be a plus

Review #3
By Glen Hart submitted on 22/Nov/2013
Minor Revision
Review Comment:

The paper aims to cover the design of two ontological design patterns for describing abstractions of terrain data – surface networks. Overall the paper meets this aim. A pragmatic minimalist approach is taken to ontology construction that enhances the probability that the designs can be adoped and implemented by others.
1.2 The authors state that that as fields cannot be related to discrete object this prevents them being shared on the Semantic Web. This is true to a degree but also maybe too purist in that the Semantic web can at least recognise fields in their entirety not as real world objects but as abstractions of part of the terrain. It may also be possible to develop “terrainlets” – micro-terrains that correspond to identifiable objects such as fields and road surfaces. There should be some acknowledgement of this.
The paper does state that the authors’ solution does not solve the overall problem of the dichotomy between objects and fields, rather it covers the sharing of extracted terrain features – but perhaps it should do so more clearly in the abstract rather in the somewhat passive way that it is dealt with in 1.2.
“The National Map3, an online mapping and topographic data exploration service from the USGS is queried for a named landform, the answer is effectively a point location associated with the named landform, not the spatial extent and other physical properties or descriptors of that landform. “

There may be an implicit assumption that all landforms have well defined extents – often the reason that an object such as a hill is defined just as a point form is because the lack of an extent has no practical consequence – in short no one cares. There may be other circumstances where the extent cannot be determined in any meaningful way, that is to say that although an extent could be mathematically computed it is not a meaningful extent in human terms. This would be a case where geometry and geography do not correspond. However, this is not a problem in terms of design patterns merely its application. There should be some acknowledgement of this lest users feel that they have to start to define extents for no practical benefit.

“as noted in [41] notes” – I note there may be too many notes.

iv. Is there any evidence other than a logical argument to support this claim? In a logical sense the argument may well be right – people will be able to identify with the surface network features. But if given the actual terrain to classify would they do so in a way that fully agrees with the generate features? I don’t know one way or the other.
I think there is an implicit assumption suggested by statements such as “It is critical to start with methods that bridge the conceptual and technological divide between two historically disparate approaches to terrain data modeling:” that surface networks can act as this bridge. But I’m not convinced by this. How is this different from extracting roads or buildings from a point cloud or image? I don’t think anyone would claim that these bridge the divide, rather this just generate the other half of the divide!
“the surface network is a network of abstract entities. The surface from which it originates is similarly a mathematical entity that represents both material surfaces extending in physical space (e.g., earth’ crustal surface, earth’s gravitational (Geoidal) surface, exterior of an animal body, and microscopic surfaces as studied in physics and chemistry) and abstract surfaces extending in conceptual space (e.g., surfaces of: population density, crime potential, simulated terrain, and grayscale images). In case of a physical surface (e.g., the earth’s surface), some of the pattern’s classes may correspond to observable features of the real world surface (e.g., peaks, passes, ridge tops, valleys), but they remain mathematical entities that should not be confused with the real world physical entities that they idealize.”
And the point is? And again is this any different from the extract of a building structure from a field?

In 3.3 it is stated that the objects extracted from the field data are abstract entities. However in 5.2 they are effectively promoted features for the good reasons given. There should be some consistency here they can’t be both – the latter arrangement seems to me to be the better one for the reasons stated by the authors.

Overall this paper has met its state aims and should be published. I have few specific comments to make because I agreed with so much of it. It would be nice the authors to now test the ontologies to prove that they have indeed achieved their purpose and I would suggest this as future work.

Review #4
Anonymous submitted on 26/Nov/2013
Major Revision
Review Comment:

This paper mainly sets the scene for, and introduces, SNODP ontology and patterns for describing surface network data.

Text is very well written and it is clear that the authors have a good level of expertise in the domain of this manuscript. Topic is also a good fit to this journal.

My main issue with the paper is its length. This paper is submitted as a ‘full paper’, and is nearly 20 double-column pages long. However, the real contribution is a description of a small ontology, with the background and rational of course. I agree that the ontology could be of value, but the question for me is whether this work is suitable as a full journal paper. My suggestion would be to submit this work as an ‘ontology description’ type of paper ( It is unclear why the authors did not go for that type of submission in the first instance.

The paper provides a rational behind the ontology, why we need it and how it could potentially be used to describe data, and what applications and reasoning could be done with it. However, what the paper does not do is demonstrate a use case, show how some surface dataset was described by this ontology, and/or how some application or applications were built over it. Paper also does not assess the ontology, e.g. in terms of answering some competency questions, that authors could have acquired from, say, owners of such surface datasets. I would think that such additions would merit a journal publications. I understand the complexity involved in achieving all this, but without it I would no recommend anyone to read this paper, just to get a description of a small ontology, that is yet to be used by anyone.

I also found some of the text rather confusing. Perhaps my fault for having a higher expectation, or perhaps the text needed to be clearer with respect to what the paper is actually selling. Reading the first few pages, I was left with an impression that this work is trying to render all surface data as linked data, and hence assigning a URI to every part of this surface data. However, it turns out that this is not the case, and that the actual surface data will only be pointed to, which could still reside in a zip file or in a geo database. This is perhaps the best and most feasible approach, but the paper painted to me a much much bigger picture, followed by the anti climax in section 4.1.

other comments:
Section 2.2 gives some ideas on ‘practical applications’ over this ontology/patterns/LD. Firstly, are there ‘impractical applications’ that we need to distinguish this section from? ;) Secondly, it is a little ironic to start a practical section with a four line sentence that is pretty complex and long winded, which I had to read three times to understand what it’s trying to say! I find this opening sentence hardly practical: “Surface networks abstract surface-specific information about surface structure of single-valued fields in a highly condensed form using identifiable features such as critical points and special slope lines”.

While reading this section, and the paper as a whole, I was often wondering where do the authors see a good old GIS system fitting it. Surely many of the proposed applications could draw much value from linking a GIS to the proposed semantic descriptions, or getting the GIS to help identifying some of the surface concept instantiations we are after. Not worth mentioning somewhere?

Section 3.1 provides several speculative benefits of semantically representing surface networks. Although useful, but would have been good to back these speculations with some concrete examples if possible, just to give these suggestions more scientific weight. E.g. when talking about data reduction, would it not be possible to demonstrate this with a real example?

Section 3.2 gives various examples of how such LD descriptions could be used to run queries to determine which part of the terrain is a river, a mountain, a valley, etc. Any chance of showing this working with a dataset that was rendered into LD using SNODP? This is especially beneficial, given that later in the paper (section 4) it is said that surface datasets are pretty difficult to convert automatically into the proposed semantic descriptions, and not mandated by the ontology.

Section 3.3. Wonder whether the paragraph that starts with “Realization of metric surface networks” is a good fit for this section. Looks rather general.

Section 4.1 typo — “It takes If access ..”

Section 4.2. Why the word “directly” in the property name “hasPart_directly”? ideally, A hasPart B, B hasPart C, and all direct, and hence we can infer that A hasPart C is an indirect one. Do you have a hasPArt_indirectly property?!

In summary, good work, not substantial, wrong submission type.