Review Comment:
This manuscript was submitted as 'Tools and Systems Report' and should be reviewed along the following dimensions: (1) Quality, importance, and impact of the described tool or system (convincing evidence must be provided). (2) Clarity, illustration, and readability of the describing paper, which shall convey to the reader both the capabilities and the limitations of the tool.
* Summary: the article describes RAMOSE (the "RESTful API Manager Over SPARQL Endpoints"), an open-source generic Python software artifact that allows to create Web RESTful APIs over any SPARQL endpoints by editing a configuration file. It also generates automatically HTML-based documentation and a Web server for testing/monitoring purposes.
* Overall Evaluation (ranging from 0-100):
[Criterion 1]
+ Quality: 95
+ Importance/Relevance: 85
+ Impact: 85
[Criterion 2]
+ Clarity, illustration, and readability: 90
[Criterion 3]
+ Stability: 100
+ Usefulness: 90
[Perspective]
+ Impression score: 80 | some design improvements can be made
* Comments:
- The tool could have a better code design (there's room to improve): modularity, parametrization. # future work?
- The structure of the HTML and CSS response chunks for the API documentation/monitoring_dashboard are defined inside the Python script. The design can be improved to offer the developers the possibility to customize the structure of the HTML and CSS response.
* Major:
pag. 05: The last paragraph of 3.1, basically, states that sorting results is an "expensive and time-consuming" operation if performed via SPARQL (over the triplestore engine) than over the RAMOSE middleware (a Python script). Is this correct? Do the authors have evidence of such claims? if so, citation need it!
Also, from the cover-letter of the second submission, the authors mention the following:
"Later in the same section, we explained why we prefer having refinement operations on results rather than inject those directly in the SPARQL query, namely: (1) to allow users to perform such operations on top of a predefined SPARQL query that cannot be modified, and (2) to speed up the retrieval process by means of efficient SPARQL queries and secondly perform basic operations faster on the retrieved JSON data."
However:
(a) Even though the SPARQL query is predefined, the tool allows basic variable/value replacements via "[[...]]". Wouldn't be the same mechanism to manage the SPARQL "ORDER BY" definition clause?
(b) The retrieval process might be faster but, how fast the basic operations are performed on the retrieved data? Do the authors have stats and measured the speed to support these claims?
* Minor corrections:
pag. 11: "Table 4" should be "Table 3".
pag. 11: http://github.com/opencitations/ramose/eval incorrect link. It should be https://github.com/opencitations/ramose/blob/master/eval/RAMOSE_logs.ipynb
pag. 14: "to be as far as possible clearto those who are" --> *clear to*
pag. 14: "web developers" --> *Web*
* Others:
@https://github.com/opencitations/ramose / Configuration / Requirements
The link https://github.com/opencitations/ramose/requirements.txt is broken: "Not found!"
|