Review Comment:
First of all, I would like to thank the authors for their responses and clarifications. However, they have only partially addressed my concerns, and I am still not fully convinced that the paper presents a research contribution rather than a resource.
- The authors justify excluding RML engines (or other KG construction engines such as SPARQL-Generate or Ontop) from the comparison by stating that the paper focuses on different configurations of Façade. However, their justification is primarily technological and lacks formal definition. If the studied problem differs from other approaches, it would be beneficial to explicitly state those differences. From my perspective, the core problem remains the same as in other methods: converting data into RDF graphs while minimizing execution time and memory consumption. In fact, on page 5, section 1c, line 30, the authors state: "In other words, a façade function takes as input a data source and a query and returns a graph." which closely resembles how (materialized) OBDA is defined.
- The paper lacks explicitly stated research questions. Additionally, I wonder whether a stronger motivation could be provided from a performance perspective rather than a user-oriented one. The authors highlight user concerns in Section 2, but IMHO, the focus of this paper should not be on justifying the use of Façade, but rather on why optimizing execution time and memory consumption is relevant from its perspective.
- I previously requested a clear comparison with prior approaches tackling similar problems, such as Morph-CSV and MapSDI, from a theoretical perspective. Both of these works provide a formal description of their proposals, and I would like to understand the exact differences between them and the approach presented in this paper. To be clear, I am not concerned with the specific mapping language used (RML, R2RML, SPARQL-Anything/Generate, TARQL, etc.), but rather with the main distinctions in methodology and execution.
- The related work section focuses on the technologies used by different engines but does not analyze the underlying approaches and solutions they propose. Furthermore, the paper assumes that OBDA is inherently virtual, but this is not necessarily the case—OBDA can also be materialized. Indeed, Ontop supports materialized OBDA using query rewriting techniques. W3C Direct mapping does not impose any ontology, defines basic rules to convert RDB (or any tabular source with few constraints) into RDF, and is comparable to this proposal.
If this paper aims to be considered a research paper, these points need to be clarified.
|
