Review Comment:
I thank the authors for vastly improving the paper and addressing most of the comments made by the reviewers. The paper’s contribution is original, and the authors have refined the paper to strengthen or clarify some of the claims. The quality of writing has also been improved. As for the significance of the results, this version of the paper does indicate what the paper tries to improve in the state of the art, though the future work could still be expanded to refer to some of the limitations. Identifying future work could benefit the community and tackle problems that the authors face, but not necessary want to work on themselves.
Reading through the paper, I have the following (minor) comments.
Abstract. What are “query abilities”? I still have a problem with “real use cases”, wouldn't “realistic scenarios put forward by the community” not be better? Alternatively, the authors could state in which sources/communities those scenarios/use cases were identified. In the last sentence, the authors mention the development of something, but it’s not clear what.
Section 1. The authors could maybe add a footnote to “plain SPARQL” indicating that they refer to SPARQL queries that are compliant with the SPARQL 1.1 Recommendation. Figure 1 is not clear; what do the arrows mean? Be consistent referring to floats; the authors used “Fig. 1” in Section 1, and “Figure 2” in the second section. I believe references to figures should use “Fig.”.
Section 2. In the last paragraph, you mention “standard language”. SPIN has never been a standard. Also, with the advent of SHACL becoming a W3C Recommendation, the authors may want to say something in Future work how another prototype implementation can adopt SHACL instead of SPIN (see: http://spinrdf.org/spin-shacl.html).
Section 3.3. Triplestore(s) in one word instead of two. A reference to the Parliament triplestore is missing.
Section 5. In the caption of Listing 10, it should be “TURTLE” instead of “Turtle”.
Section 6. Restate what you mean with “real-world”. At the beginning of this section, be explicit and mention what you are evaluating or validating (both have different semantics).
In Section 7, the authors could restate that possible extensions are manifold, an exhaustive list of functions is practically impossible, and that Section 7 therefore aims to demonstrate how one could extend BimSPARQL for custom/specific scenarios. The authors could also indicate here that, while allowing (to some extent portable) extensions for specific cases are already a step forward, the knowledge/rule/ontology engineering processes is a non-trivial problem that would require appropriate method and tools that are not within the scope of this paper and maybe the subject of future work.
Section 8. Something is wrong with the reference in the last paragraph.
Throughout the paper, any mention of “section X” should be replaced by “Section X”.
I would encourage the authors to actually put in the paper some of the clarifications and comments they have provided the authors in their letter.
For instance, the authors acknowledge that the extended rules are only portable in terms of the data model (RDF) and the rule engine (SPIN), and that these have to be installed on each BimSPARQL-enabled endpoint in order to function. The authors also acknowledged the knowledge engineering activities that are required as I have indicated above, but could be stated more explicitly in the paper. Because the authors allow one to extend functions using SPIN and “arbitrary programming”, the whole problem of ensuring tractability, correctness, … can be shifted to an appropriate methods and tools for those knowledge engineering activities.
The authors used a particular representation for geometries in Section 4.3. The authors, as they pointed out in their letter, should emphasize that the same representation should be used by other implementation in order to facilitate interoperability or results that are the same across implementations. While they currently focus on triangulated boundary representations, I can understand that this can change. Yet the argument can still be made that, at the end of the day, a consensus about a representation has to be made. Especially if one wishes to put forward BimSPARQL as a standardized extension of SPARQL.
In Section 4.4.1, the authors can, maybe again, explicitly state that their aim was not to provide a full coverage of possible functions, but to provide a basis that one can extend. The authors could also elaborate on how they, perhaps, looked into other initiatives for providing their 6 functions (e.g., looking into OGC standards for commonly used functions).
|
Comments
minor typo
p.13 Table 7 -> s/betwteen/between/