Creating RESTful APIs over SPARQL endpoints using RAMOSE

Tracking #: 2752-3966

Authors: 
Marilena Daquino
Ivan Heibi
Silvio Peroni
David Shotton2

Responsible editor: 
Armin Haller

Submission type: 
Tool/System Report
Abstract: 
Semantic Web technologies are widely used for storing RDF data and making them available on the Web through SPARQL endpoints, queryable using the SPARQL query language. While the use of SPARQL endpoints is strongly supported by Semantic Web experts, it hinders broader use of RDF data by common Web users, engineers and develop-ers unfamiliar with Semantic Web technologies, who normally rely on Web RESTful APIs for querying Web-available data and creating applications over them. To solve this problem, we have developed RAMOSE, a generic tool developed in Python to create REST APIs over SPARQL endpoints, through the creation of source-specific textual configuration files which enable the querying of SPARQL endpoints via simple Web RESTful API calls that return either JSON or CSV-formatted data, thus hiding all the intrinsic complexities of SPARQL and RDF from common Web users. We pro-vide evidence that the use of RAMOSE to provide REST API access to RDF data within OpenCitations triplestores is beneficial in terms of the number of queries made by external users to such RDF data using the RAMOSE API compared with the direct access via the SPARQL endpoint. Our findings prove the importance for suppliers of RDF data of having an alternative API access service, which enables its use by those with no (or little) experience in Semantic Web tech-nologies and the SPARQL query language. RAMOSE can be used both to query any SPARQL endpoint and to query any other Web API, and thus it represents an easy generic technical solution for service providers who wish to create an API service to access Linked Data stored as RDF in a conventional triplestore.
Full PDF Version: 
Tags: 
Reviewed

Decision/Status: 
Accept

Solicited Reviews:
Click to Expand/Collapse
Review #1
By Pierre-Antoine Champin submitted on 30/Apr/2021
Suggestion:
Accept
Review Comment:

Compared to the previous version, the authors have adequately addressed my remarks.

A few minor typos are remaining:

* p2: "easily and quickly provide" → "to easily and quickly provide"
* §3.3.2: "Only the rows compliant with the filter specified" → "Only the rows complying with the specified filter"
* Table 2: "curly brackets" should be "parenthesis" in the description of '#preprocess" and '#postprocess'
* Table 2: "split by a space" → "separated by spaces"
* §3.3.6: why is "Rather" underlined? Is this the template's style for emphasis? I doubt it.
Also, I would write "Instead" rather than "Rather".
* §3.4.1: "-o (the output" → replace the opening parenthesis by a comma (","); that parenthesis is never closed (and it is inside another pair of parenthesis)

Review #2
By Sergio Rodriguez Mendez submitted on 06/May/2021
Suggestion:
Minor Revision
Review Comment:

* Summary: the article describes RAMOSE (the "RESTful API Manager Over SPARQL Endpoints"), an open-source generic Python software artifact that allows the creation of Web RESTful APIs over any SPARQL endpoints by editing a configuration file based on "hash format". It also generates automatically HTML-based documentation and a Web server for testing/monitoring purposes.

* Overall Evaluation (ranging from 0-100): 91
[Criterion 1]
+ Quality: 95
+ Importance/Relevance: 85
+ Impact: 85
[Criterion 2]
+ Clarity, illustration, and readability: 95
[Criterion 3]
+ Stability: 100
+ Usefulness: 90
[Perspective]
+ Impression score: 90

* Minor corrections:
- page 01 (abstract): "Our findings prove the importance..." --> replace "prove" with "shows". "Prove" in this context is too strong: you are not proving a foundational theorem.
- page 03: "RAMOSE, the RESTful API Manager Over SPARQL Endpoints, is an ..." --> "RAMOSE is an ..." (the RAMOSE abbreviation has already been defined in page 2)
- page 13: In the last line of the table description: "..., and 'Rest API service', which... " --> 'REST'
- page 13: In the table header: "Ramose" --> "RAMOSE"

Review #3
By Jonathan Yu submitted on 13/May/2021
Suggestion:
Minor Revision
Review Comment:

The authors have revised Section 4 to add content in a part of the manuscript that is now named Sec. 4.1.1 showing that users are querying content in the OpenCitation's REST API in a way that has a high similarity score to user queries of the SPARQL API endpoint, i.e. users are querying similar things in both the REST APIs and the SPARQL APIs. This gives readers a sense that they are functionally equivalent and combined with the number of queries to the REST APIs and the SPARQL endpoint, they show there is potentially a shift towards using the REST APIs. This suggests a possible change in user behaviour in querying using RAMOSE REST APIs from SPARQL queries showing potential adoption of the REST APIs from users in the context of OpenCitations data reuse.

In closely revisiting the SWJ's definition of demonstrable impact (http://www.semantic-web-journal.net/faq#q20), an evaluation of RAMOSE's impact follows:
"(I) impact beyond your own range of influence (e..g., uptake of your work by other research groups)"
- There isn't sufficient evidence of this given as it is too early to expect widespread community uptake of RAMOSE at this moment in time. It appears there has not been additions in the manuscript on this issue
"(II) impact within your own range of influence (e.g., use of your results in a collaborative research project)"
- There is evidence in the manuscript to demonstrate some indirect impact, i.e. RAMOSE's key role in OpenCitations. Section 4.1.2 lists other endpoints using RAMOSE but are related to OpenCitations events. Sec. 4.1.2. demonstrates adoption of OpenCitations REST APIs in other tools. The outcome of third party tools accessing OpenCitations' REST APIs demonstrates indirect impact - as the RAMOSE tool was used to develop those REST APIs and access OpenCitation's content successfully. The examples provided for third party applications are are potentially impactful ones (e.g. a Zotero client for OpenCitations). However, there is a question about whether this could be achieved without RAMOSE, that is, developing a REST API without RAMOSE.
"(III) potential impact"
- Anecdotal evidence is provided that RDF data providers would require such a tool as RAMOSE for delivering RDF data via REST APIs

As noted in a previous review, tools like RAMOSE have an important contribution to the Semantic Web community as a tools that may allow RDF data to be more easily accessed. On the above basis, there is demonstrable impact on the Criterion (II) - using RAMOSE helped develop the OpenCitations REST API, which led to third party adoption of OpenCitations and benefits to the Open Science community.

Overall, this revision addresses previous comments (such as the comparison table in page 13). Some minor revisions suggested below.

Minor revision
- p.12 "SQARQL" -> SPARQL?
Section 4. Section headers 4.1.1 and 4.1.2 are added, i.e. sub-subsections. However, would it make more sense to have them as subsections, e.g. 4.1 and 4.2 respectively?