Semantic-Graph based approach to BIM, resilience, and spatial data interoperability

This paper introduces an approach towards interoperability between different standards for building information using semantic web technologies. At the core of the approach is an ontology design pattern called the Spatial Graph Adapter (SGA) pattern. The pattern is rather generic – which is, of course, the whole point of a pattern, but I think the paper lacks a discussion about how much of the work presented here is actually about BIM, and how much could be of broader use (please provide some examples).

I am a bit concerned about the design choice of introducing a the hasType relation. While I can see the argument about avoiding hierarchical confusion, I think the approach presented here may actually create a modelling confusion – now we have two ways of dealing with types, which one is the one to chose for the person using the pattern?

The ContextualisedRelation needs to be explained with a practical example. Its purpose remains on a very abstract level in the text. The connection of the pattern to the Linked Data Platform is also not entirely clear, if there is one.

- In general, the paper could be shortened and more focused. Several parts seem repetitive or not really relevant to the core content of the paper.
- Concerning the title, I would suggest to remove resilience from the title. The topic is barely mentioned in the paper and, in my understanding, simply one application area (among many) for BIM
- On p.2, it is not clear what the authors mean by "modular SPARQL endpoints". My hunch is that they talk about federated querying, but the wording here sounds more like every individual endpoint is modular. Please clarify.
- I got hung up a bit on the wording "smarter data" on page 4. Data isn't smart, just like computers cannot "understand" anything when we use semantic web technologies.
- In section 4.1, the described "inherent inconsistencies" are a bit unclear. Are they inconsistencies between the different schemas? Then they are not inherent. If they are within each schema, what are they (and again, why are they inherent)?
- In the text, GeoSPARQL is only mentioned in passing once – there should be explicit references to the examples that show the use of GeoSPARQL with the pattern.
- P.13: …Turtle (or RDF) → Turtle is an RDF serialisation. I think you mean "Turtle (or RDF/XML)".
- There are some typesetting problems in section 8.

The article certainly advertises its qualities idealistically, but it seems to be lacking in concreteness, especially in places where the reader needs to get acquainted with these concepts. The motives are strong, the potential benefits sound reasonable, and the authors may have done all the work correctly, but the issues lie within the article itself; namely, how the concepts are organized and how the methods are explained. The text raises enough concerns that I cannot recommend it for acceptance in its current state.

Criticisms
=============
Citations and figure references are not linked in the text.

> In section 2, paragraph 3 "...the approach to this work needed to be changed to ensure that the project would be modular, extensible, scalable, and Semantic Web compatible since the amount of data that needs to be processed is potentially exponential in complexity and extensive in quantity."

How can an "amount of data" be "exponential in complexity"? Exponential complexity is an analysis of algorithms, not a characteristic of data. Also, what exactly is meant by "extensive in quantity"? Isn't this just a roundabout way of saying that the applications demand scalability?

> "Fortunately these data standards contain recognizable information patterns that can be computationally predicted, making automatic data extraction a possibility."

This statement is quite vague. What is meant by "recognizable information patterns" and "computationally predicted"? As it stands, the conclusion is a bit of a non sequitur. How do these qualities lead to enabling automatic data extraction? Aren't there many more variables at play?

> Section 2.1, paragraph 1, "...these different data formats all need to be interoperable in a modular fashion so as to continue to expand upon these research ideas in an organized manner"

I don't understand how the quality of interoperability can possibly contain the quality of modularity. Perhaps, at best, "in a modular fashion" could describe the process of configuration of mappings.

The last paragraph in Section 2.1 feels like it finally explains concretely what are the purposes of this research. Why doesn't this information appear in the abstract?

> Last paragraph in Section 3.0, "The goal for the implemented Semantic Graph approach presented in this article is to maintain Linked Data principles as well as set up a modular approach that is easily integrated with GeoSPARQL, extensible, and scalable. It was designed to be part of a LDP useful for accommodating, interpreting, and semantically enhancing any BIM, spatial ontologies, or other data formats/taxonomies."

This seems much too broad. What exactly is being proposed here? There are many promises being made with seemingly little foundation.

> "Because coordinates and simple bounding boxes cannot represent the level of complexity needed to process and query data efficiently at the pace modern tools need or with the variety of tagging structures used, the geometry types and the SGA resolve the differences found between spatial data standards."

Is there proof or a citation for this? I'm not so easily convinced.

> On page 12, "Using a GeoSPARQL enabled graph database and server framework (Vituoso and GraphDB have been investigated) combined with the Semantic Graph data serialized in Turtle (or RDF), ..."

I am confused here, why is a graph database being combined with serialized RDF? Also, the way the parentheses are used here makes it sound like RDF is a serialization format, which it is not, or that is is an alternative to Turtle, which it is also not.

The bottom half of Figure 7 shows selecting a condition that always returns true since the exact same condition appears in the FILTER block of the query body (finding polygons less than 100 units away). Please revise. Even simple mistakes such as this one do not help establish the robustness of a paper.

Where is the justification for not reusing existing RDF ontologies or vocabularies for the rather simple schema/relationships presented here?

> "The framework can be easily extended to produce output in additional formats"

Please be more careful about these claims and promises. Here, the phrase "easily extended" is difficult to surmise. Why should the reader take your word that this is 'easy' when you don't thoroughly detail how the framework can be extended? What kind of background would be required to carry out such a task?