Anonymous Reviewer 1: 

Numerical scores should be given from 1 to 10: Poor [1] ….. Middle [5] ….. Excellent [10]
				
1. NOVELTY:             [5]
Please see the additional comments.

2. PRACTICAL IMPACT:    [5]
Please see the additional comments.

3. TECHNICAL SOUNDNESS: [6]
Please see the additional comments.

4. APPROPRIATENESS AND ADEQUACY 
Literature review:      [7]
Background discussion:  [8]
Issue Analysis:         [3]

Please see the additional comments.

5. PRESENTATION
Overall organization:   [6]
English:               	[6] 
Readability:            [6] 

Please see the additional comments.

6. Additional Comments

This paper presents an approach and its implementation (called OnGIS) that supports semantic queries from heterogeneous data sources. The proposed system first builds semantically equivalent queries using a lattice structure and then searches the input query in the lattice to return semantically equivalent queries. There are two resulting cases from the search and return process. In the first case, the system can find the semantically equivalent queries (to the input query) in the lattice, which means the equivalent queries (associate with a set of data sources) are capable of answering the input query. The other case is that the semantically equivalent queries cannot be found. In this case, the approach splits the input query into sub-queries and search the lattice with the sub-queries. In the experiment, the paper provides an example to demonstrate how OnGIS split an input query into sub-queries to obtain answers from two data sources.

In general, the approach sounds valid, but if I understand correctly, it does not use much spatial properties in the query splitting and containment checking process that based on the papers [7] and [8]. (even the example in section 6 is nothing geospatial.) The paper should clarify this point. Also, the paper should provide a complexity analysis of the algorithms in section 5 to help understand the scalability of the approach (e.g., in terms of the number of data sources). Finally, the experiment (which has only one example) does not provide an evaluation to validate OnGIS as a geospatial query broker. The paper mentions a number of geospatial queries that OnGIS supports (e.g., distance), but none of them is demonstrated in the experiment.

More detailed comments:
1. The reader could use some explanation of the meaning of prototypical queries.
2. section 4.2: Since the main idea and proof of this section is based on the papers [7] and [8], the paper should explain the new idea here for geospatial queries.
3. section 4.2, last paragraph: it would be helpful to give a brief idea about algorithm used to reduce the number of combinations
4. section 5.2 ÒÉswitches to the splitting mode.Ó: Does this mean the system will switch to algorithm 4?
5. section 5.2 ÒBy the symbol |q|ÉÓ: There is no symbol |q| in the algorithms. 
6. section 5.2 paragraphs 7 and 8: The two paragraphs contradict. Does algorithm 5 split to the maximum number of subqueries or a limited number to fulfill the alignment?
7. SUMMARY AND RECOMMENDATION 

(a) Overall Quality:    [6]
			
What are the strong points of the paper?
Please see the additional comments.

What are the weak points of the paper?
Please see the additional comments. In general, there is no complexity analysis of the proposed algorithms (unknown scalability). The experiment only provide one example and does not use a geospatial query. 

(b) Recommendation
[] Accept
[] Minor revision 
[x] Major revision 
[] Reject

(c) If the paper is accepted, it should be published as
[x] a full research paper
[] a short communication
[] a review paper
[] a visionary paper

Anonymous Reviewer 2: 

Numerical scores should be given from 1 to 10: Poor [1] ….. Middle [5] ….. Excellent [10]

1. NOVELTY:             [6]
There are contributions on the work of querying multiple data sources by means of sets of prototypical queries and splitting of queries.
The novelty of this work lies on use of GeoSPARQL queries enhanced with OWL 2QL. 

2. PRACTICAL IMPACT:    [8]
Geospatial data is very important for a number of applications, and there are a large number of heterogeneous geospatial data sources.
Efficient approaches for querying such data are no doubt desired and have a high practical impact.

3. TECHNICAL SOUNDNESS: [7]
Authors suggest several formulae for the containment of GeoSPARQL queries, and provide sketchy proofs.
Algorithms for constructing the lattice of prototypical queries and for matching queries in the lattice are given, and implemented and tested.

4. APPROPRIATENESS AND ADEQUACY
Literature review:      [6]
Background discussion:  [7]
Issue Analysis:         [6]

The authors miss to include and discuss important references about SPARQL containment and federation approaches.
Although these existing literature does not focus on spatial data, they should be also included. For example,
* Melisachew Wudage Chekol: "On the Containment of SPARQL Queries under Entailment Regimes", AAAI 2016: 936-942 2016.
* Reinhard Pichler, Sebastian Skritek: "Containment and equivalence of well-designed SPARQL". PODS 2014: 39-50, 2014
* Melisachew Wudage Chekol, Jérôme Euzenat, Pierre Genevès, Nabil Layaïda:
"Evaluating and Benchmarking SPARQL Query Containment Solvers". International Semantic Web Conference (2) 2013: 408-423, 2013
* Melisachew Wudage Chekol, Jérôme Euzenat, Pierre Genevès, Nabil Layaïda:
"SPARQL Query Containment Under SHI Axioms", AAAI 2012
* Melisachew Wudage Chekol, Jérôme Euzenat, Pierre Genevès, Nabil Layaïda:
"SPARQL Query Containment under RDFS Entailment Regime", IJCAR 2012: 134-148, 2013
* Please also check the paper (http://www.ronpub.com/publications/OJSW_2015v2i1n04_Groppe.pdf) for recent work on federation approaches. 
This paper contains also in Section 2.3 a lot of other references to state-of-the-art federation approaches.

5. PRESENTATION
Overall organization:   [8]
English:                [6]
Readability:            [7]

This work is generally well presented and easy to understand, but there are some grammatical errors, and this paper should be carefully proofread.

In Section "6 Example", authors use an example to explain their approaches: how to construct the lattice of prototypical queries and how to search a user's query in the lattice.
When I read the section "7 Conclusion and Future Work", if I understood correctly, Section 6 describes not only an example, which explains the suggested approaches, but also a text example, which is successfully tested by the implementation.
The implementation and test of the approaches are very important contributions, which should be highlighted. Unfortunately, authors did not mention them in Section 6.
The heading title of Section 6, Example, should  be also improved.

6. OTHER ASPECTS
    Please provide additional comments to the author(s) for improving and revising the manuscript.

* "prototypical queries": Please define this term before you use it the first time.

* Query containment is also not defined where it appears the first time.

* English issues, including English errors and unclear expressions, for example,
- "Some parts of it ...  has been ..."
- "...they propose interesting..." => "...they propose an interesting..."
- "Prototypical queries fully capture relevant capabilities of a data source, both in terms of data and operations it provides.":
What is "it"?
- "It also contains axioms that ..." => "It also contains axioms like ..."???

* Section 3.1: Discuss shortly alternatives to GeoSPARQL like stSPARQL. Why you have chosen GeoSPARQL instead of the alternatives

* Section 3.1: There are a lot enumerations (e.g. when describing the "families"). Please explain shortly each property (maybe use a table for this purpose.)

* Section 3.2: Please shortly discuss the other OWL 2 Profiles and why OWL2QL is chosen (maybe you can add this already to Section 3).

* Section 4.2 and Section 4.3: Mathematical definitions typically use "if", but you use "when", e.g. in the definitions of COM(OP/DP...), r_e..., x~_r y
The definition of COM(OP...) should be in the style
COM(OP...) = A(i_y) union B(i)
          {...} if i_x in I_{V2}
A(i_y) ={
          {} otherwise

B(i) analogous,
COM(DP...) analogous.


* End of Section 4.2: Please explain why you do not discuss the simple algorithm to reduce the number of combinations.

* The font size in Figure 3 is too small. The font sizes in figures should be comparable to the font sizes in the normal text.

* Page 8, in the end of the left column: "Therefore, the completed ABox for geo:asWKT (¡CZ+SK¿ in q2) will not be extended with ¡CZ¿ from...".
My Acrobat Reader displays strange symbols in ¡CZ+SK¿ and ¡CZ¿. Maybe a font is not correctly embedded in the generated PDF. If this is the case please use another font or check how to embed fonts in latex...

* A lot of algorithms contain broken lines (one line in the algorithm going over two lines in the paper), e.g. algorithms 2, 4, 5 and 6. Please correct these broken lines by e.g. spanning the algorithms over two columns.

* Missing references: Any mentioned techniques/approaches/standards/work ... should be given references
(Some references may be given before, but they should be given again), for example,
- "In comparison with our previous work, and the work of others, ...":
Please provide refs for "our previous work" and "the work of others"
- "For example the Catalogue Service (CSW), a standard by OGC,"
- ESRI ArcGIS services, DBPedia, LinkedGeoData, SuQL, WFS, OIL, SHIQ, ...
- References should be given when a term is used first time (e.g., Linked Data).


7. SUMMARY AND RECOMMENDATION

(a) Overall Quality:    [7]

What are the strong points of the paper?
+ Containment of GeoSPARQL queries
+ Query lattice construction and query matching in lattice
+ Algorithms and implementation

What are the weak points of the paper?
- Experimental Evaluation:
Authors state: "...with succesfull tests on a few nonlarge samples..." Can you quantify the number of successful tests? Can you provide any further statistics, which strengthen your (experimental) evaluation? Can you provide an experimental evaluation in terms of processing times? How long does your prototype take for your tested queries? Is there a speedup compared to not using OnGIS? (I ask you these questions such that you sell your OnGIS approach better to the readers...)


(b) Recommendation
[] Accept
[x] Minor revision
[] Major revision
[] Reject

(c) If the paper is accepted, it should be published as
[x] a full research paper
[] a short communication
[] a review paper
[] a visionary paper

Anonymous Reviewer 3: 

Numerical scores should be given from 1 to 10:	Poor [1] ... Middle [5] ... Excellent [10]
	
1. NOVELTY:             [5]
This paper proposes broker techniques for answering a user’s complex spatial query: find relevant data sources (from a catalogue of many) capable of answering the query, eventually split the query and find relevant sources for the query parts, when no single source suffices. 
The similar idea with this work has been presented in other papers. The authors could check the similar works and compared with them, which can improve the quality of the presented work.

2. PRACTICAL IMPACT:    [7]
The proposed algorithms were implemented in a proto-type, with tests on a few nonlarge samples. It needs to be improved for a larger scale.

3. TECHNICAL SOUNDNESS: [7]
The paper is easy to read and understand, is well redacted and offers reader the information necessary to understand it. It establishes a great goal: to create a framework proposal for efficient querying multiple heterogeneous geospatial sources: one part is describing them by sets of prototypical queries the sources can answer, another part is the method how to find which sources to use for answering a user’s query.
There were a few typos and grammar errors.

The paper gives an example in section 6, but it lacks comparison with other similar works, which is important for certifying the value of the work.

4. APPROPRIATENESS AND ADEQUACY 
Literature review:      [6]
Background discussion:  [6]
Issue Analysis:         [6]

The background discussion is not sufficient. The literature review and issue analysis should focus much on query answering, but not on the geospatial data linking and integration.

5. PRESENTATION
Overall organization:   [7]
English:                [7] 
Readability:            [7] 

The paper is well organized and is easy to read and understand, but there were a few typos and grammar errors. I suggest letting a native speaker revise the paper. 

6. OTHER ASPECTS
Please provide additional comments to the author(s) for improving and revising the manuscript.

I think it is good for authors to add comparisons with other similar works.
In addition, it would be better if authors could give the detailed descriptions about the experiments, such as how large dataset can be used in the current OnGIS.

7. SUMMARY AND RECOMMENDATION 

(a) Overall Quality:    [7]
What are the strong points of the paper?
This paper finds relevant data sources (from a catalogue of many) capable of answering the query, and splits the query and finds relevant sources for the query parts. In addition, it provides a prototype OnGIS to show the given approach.
 
What are the weak points of the paper?
It lacks experimental analysis and comparisons with other similar works.

(b) Recommendation
[] Accept
[] Minor revision 
[V] Major revision 
[] Reject

(c) If the paper is accepted, it should be published as
[V] a full research paper
[] a short communication
[] a review paper
[] a visionary paper

Authors' Response to Reviews Round 1: 

Dear OJSW reviewers,

below are the changes made to our paper 'OnGIS: Semantic query broker for heterogeneous geospatial data sources' upon your reviews.
The changes are in the order how they appear in the text:
• Explained prototypical queries in the 3rd paragraph of Sec. 1.
• Linked Data reference moved earlier to Sec. 1, also citing W3C standards.
• References to OGC CSW, ArcGIS services, DBpedia, LinkedGeoData, SuQL, WFS, OIL,
referring for all description logics constructs to description logics handbook – in Sec. 2.
• Relating to the works of Chekol, Pichler, and Groppe mentioned in reviews at the end of Sec. 2.
• Comparing GeoSPARQL and stSPARQL at the very end of Sec. 2.
• Added 2nd paragraph to Sec. 3 to briefly describe other OWL 2 profiles, and stating in the 1st two paragraphs what is the advantage of QL (possible to use it for querying from respective source, e.g. relational databases).
• Sec. 3.1 (GeoSPARQL) uses more bullet points for item enumerations; topological relations families are in a new Table 1 (with a brief meaning of each property).
• A change not invoked by a review: Figure 2 (topology relations) in Sec. 4.1 has been fixed (there have been some discrepancies in DE9-IM definitions of topological relations in GeoSPARQL standard and GeoSPARQL ontology, and some my mistakes).
• What has been added over Horrocks query containment articles [17,18] has been added to the 3rd paragraph of Sec. 4.2.
• Com(*) definition equations in Sec. 4.2 have been restructured to the proposed way.
• Replaced “when” with “if” in equations in Sec. 4.2 and 4.3.
• A complexity analysis of the query containment method has been analyzed in Sec. 4.2 in the paragraph overflowing from the end of page 7 to the beginning of page 8 and in Sec. 4.3 at the bottom of the left column in page 9.
• A brief description how the variable mapping algorithm works is in the last paragraph of Sec. 4.2.
• Fixed less-than and greater-than signs in CZ and SK area symbols in the last paragraph of Sec. 4.3 (it was a LaTeX encoding issue, not a font problem).
• Fig. 3 has been changed a little to make the fonts larges.
• A complexity analysis of constructing and searching a lattice is in the last paragraph of Sec. 5.1 and the 3rd paragraph of Sec 5.2.
• Splitting mode references the algorithm in 1st paragraph of Sec. 5.2
• The |q| definition moved where appropriate (it is used in Algorithm 6).
• Algorithms 2, 4, 5, and 6 span two columns now.
• The next to last paragraph in Sec. 5.2 – reworded how the limiting of splitting works, not to confuse a reader (that is a maximum number of split queries, satisfying certain condition).
• The Sec. 6 has been renamed from Example to Examples of Testing, and we are being specific there that the examples actually work.
• To Sec. 6.2, another larger example with spatial restrictions has been added. Also some statistics have been added to both examples.
• A comparison to another system performing query containment (Pellet) is added as Sec. 6.3.
• Syntax and grammar has been checked by hand and by grammarly.com.

Best regards,
Marek Smid