Creating RESTful APIs over SPARQL endpoints using RAMOSE
CCreating Restful APIs over SPARQL endpoints with RAMOSE
Editor(s): - Solicited review(s): - Open review(s): - Marilena Daquino a,b , Ivan Heibi a,b , Silvio Peroni a,b,* , David Shotton a,c a Research Centre for Open Scholarly Metadata, Department of Classical Philology and Italian Studies, University of Bologna, Bologna, Italy b Digital Humanities Advanced Research Centre, Department of Classical Philology and Italian Studies, University of Bologna, Bologna, Italy c Oxford e-Research Centre, University of Oxford, Oxford, United Kingdom
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 these data by common Web users, engineers and developers unfamiliar with Semantic Web technologies, who normally rely on Web RESTful APIs for querying Web-available data and creating applications with 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 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 from common Web users. We provide evidence for the use of RAMOSE to provide REST API access to RDF data within OpenCitations triplestores, and we show the benefits of RAMOSE in terms of the number of queries made by external users to such RDF data 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 users with no (or little) experience in Semantic Web technologies and the SPARQL query language. Because RAMOSE is generic and can be used with any SPARQL endpoint, it represents an easy technical solution for service providers who wish to create an API service to access Linked Data stored as RDF in a conventional triplestore. Keywords: REST API, OpenCitations, citation data, SPARQL endpoint, RDF, Linked Data, triplestore, RAMOSE, data access, query language Introduction
Application Programming Interfaces (APIs) are powerful means of automating communication be-tween application programs and data services. The aim of an API is to expose service functions and data so as to facilitate the interaction with users or (partic-ularly) machines. In particular, Representational State Transfer (REST) APIs expose on the Web a set of stateless operations which enhance performance, * Corresponding author. E-mail: [email protected]. enables a broader Web audience (Web de-velopers and scholars) to query RDF data available in triplestores behind SPARQL endpoint interfaces without having to use the SPARQL query language; and 2. allows Semantic Web developers easily and quickly to provide REST API access to their RDF data, a situation that we di-rectly experienced in the context of OpenCitations [5] (https://opencita-tions.net/). OpenCitations is an independent infrastructure or-ganization for open scholarship dedicated to the pub-lication of open bibliographic and citation data by the use of Semantic Web technologies, and engaged in ad-vocacy for open citations. Initially, the data within the OpenCitations Corpus [6] were queryable only by us-ing our SPARQL endpoint. However, we received several suggestions from people working in different scholarly disciplines for a more holistic approach for data querying, to enable users with no skills in Seman-tic Web technologies to access these data and to reuse them for building Web applications. In addition to providing a standard Web REST API for access to our Corpus data, we also needed a method whereby we could quickly and easily create new Web REST APIs to extend such access to new RDF datasets that we ourselves might publish, while at the same time providing a generic tool for adoption by the Semantic Web community as a whole. To address such needs, we developed RAMOSE, the Restful API Manager Over SPARQL Endpoints (https://github.com/opencitations/ramose), which was explicitly created to foster reusability of RDF data across common Web applications. While developed to solve the specific problem of providing REST APIs for OpenCitations data, RAMOSE has been developed in a way which permits it to interact with any
SPARQL endpoint, following the rationale we adopt for all our software development (available at https://github.com/opencitations), namely: while ad-dressing the problem at hand, do this in a manner that provides a generic, open and public tool which can be reused by others with similar requirements. RAMOSE is an open source Python software tool released under an ISC license. It allows one to create a Web REST API, with the related documentation, which acts as an interface to one or more SPARQL endpoints, regardless of the kinds of data hosted in a RDF triplestore. The creation of an API only requires the creation of a configuration file in a specific textual Markdown-like format which includes the SPARQL queries used by the API to retrieve RDF data. At OpenCitations, we now use RAMOSE to implement all the REST APIs introduced at http://opencita-tions.net/querying. In this article, we provide a quick introduction to the context in which we have made this development (Section 2), followed in Section 3 by a description of RAMOSE, its architectural model, and how to config-ure and deploy it. In Section 4, we document how Web users engaged with OpenCitations data both before RAMOSE was developed and after we started using it to provide Web REST API access to OpenCitations datasets. After a discussion on past works concerning other software that addresses similar scenarios (Sec-tion 5), we conclude the article (Section 6) by sketch-ing out some planned future developments. Background: OpenCitations and its data ince then OCC has been used as a publication platform for citations derived from the ExCITE Project (http://excite.west.uni-ko-blenz.de/website/), the Venice Scholar Project (https://venicescholar.dhlab.epfl.ch/about) and other sources, and now contains 13,964,148 bibliographic citations to 7,565,367 cited publications. Following our development in 2018 of Open Cita-tion Identifiers (globally unique PIDs for citations treated as first-class data entities in their own right [10]), and using open references supplied by Crossref, we switched OpenCitations’ bulk publication of cita-tion links from OCC to COCI, the OpenCitations In-dex of Crossref open DOI-to-DOI citations [11], which was first released in July 2018 and currently contains 721,655,392 bibliographic citations between 58,876,621 DOI-identified publications. Also in July 2018, as a consequence of the development of COCI, we released the first version of RAMOSE and started to expose all OpenCitations data via Web REST APIs. RAMOSE: a technical introduction
RAMOSE, the Restful API Manager Over SPARQL Endpoints, is an open-source application written in Python which allows the agile development and publication of documented REST APIs for query-ing against any SPARQL endpoint. In particular, it is possible to customize RAMOSE to generate a Web REST API for the URL of a given SPARQL endpoint simply by creating an appropriate textual configura-tion file. The modularity of RAMOSE allows a complete definition and customization of API operations and their input parameters. In addition, it enables one to apply pre-processing and post-processing steps by us-ing external Python libraries that can be easily im-ported, and automatically generates HTML documen-tation of the API. RAMOSE has been designed to be consistent with the following principles: 1.
It must work with any legacy RDF triple-store providing a public SPARQL end-point. 2.
A Semantic Web expert should only be re-quired initially, to define the SPARQL queries hidden behind the API operations, while all the other aspects of the REST API configuration and use should not re-quire Semantic Web skills. 3.
API operations and their input parameters must be fully customizable according to the particular needs of the infrastructure exposing the data. 4.
The configuration file of a RAMOSE-based API must be easy to write and must avoid technicalities as much as possible. 5.
Pre-processing and post-processing steps, developed as pure Python functions, must be specified in any operation, so as to bet-ter customise the interpretation of the in-put parameters and call outputs. 6.
Basic built-in filters and refinement mech-anisms must be provided by default. 7.
It must be possible to use the REST API within another Python application, to run it as a command line application, and to make it available as a proper service within a web server. The source code of RAMOSE, its documentation, and examples of its use are all available on GitHub at https://github.com/opencitations/ramose. RAMOSE is licensed under the ISC License.
Architecture overview
RAMOSE is a middleware interface between the data consumer and one or more SPARQL endpoints. Figure 1 shows an overview of the application. It con-sists of the application file (i.e. the file ramose.py ) nd one or more configuration documents (one for each Web REST API service that is created by means of RAMOSE). The RAMOSE application file handles the follow-ing aspects: service builder for running API operations, definition of built-in filters and refinement mecha-nisms, SPARQL query dispatcher, results format con-verter (either in CSV or JSON), generation of HTML documentation, setting up of a web server for testing purposes. Each RAMOSE configuration document contains metadata of the REST API service (name, contacts, li-cense, description, etc.), the URL of the SPARQL endpoint to use, the optional specification of a Python file containing functions that can be used to pre-pro-cess the API call input parameters and/or to post-pro-cess the result of the execution of the SPARQL query, and the definition of all the operations. Each operation must specify the SPARQL query to run against the SPARQL endpoint, the URL to call the operation which includes also the name and shape of its input parameters, the HTTP method to use for the request, optional pre-processing/post-processing functions to execute before/after the execution of the SPARQL query, the types of all the fields returned by the oper-ation, and additional documentation text (description of the operation, example of use, and an exemplar out-put in JSON). As shown in Figure 2, every time someone executes an operation, the related URL of the call is parsed and the values of the input parameters are retrieved accord-ing to the shape (i.e. data type and textual form) spec-ified in the configuration file. The preprocessing func-tions are executed on the specified input parameters. Following this preprocessing, any input parameter included in the SPARQL query of the operation be-tween [[...]] is replaced with its current value, and finally the SPARQL query is performed against the SPARQL endpoint according to the HTTP method specified. When the SPARQL endpoint returns a re-sult, RAMOSE runs the post-processing functions on it, applies filters and refinements if specified in the call URL, and converts the results either into CSV or into JSON according to what has been specified in the re-quest. Where JSON is chosen as the output format, it is possible to ask RAMOSE, via a particular refine-ment parameter included in the call URL, to transform the default JSON outcome into a more structured one. An example of the whole process is presented in Fig-ure 2.
Configuration document
The configuration of the REST API is specified us-ing a hash-format file (extension: .hf ). The hash-for-mat syntax, shown in Listing 1, is based on Markdown. An hash-format document includes several key-values introduced by an hashtag, where the token attached to the hashtag defines the name of a field and the rest of the text after the hashtag is a Markdown content acting as a value associated with that field. A RAMOSE configuration document includes two main conceptual sections, as shown in Listing 2. The first one contains general metadata and mandatory in-formation about the REST API, and the other one in-cludes a description of all the operations exposed by
Figure 1. An overview of the main components of RAMOSE. he REST API. As examples, the RAMOSE configu-ration documents we use in OpenCitations are availa-ble at https://github.com/opencitations/api. Table 1 lists all the fields used in the first section of the configuration document to describe the REST API, while Table 2 lists all the fields used to define all the operations included in the second section of the con-figuration file. In both sections, must be always the first field of each block.
Filters and refinements
RAMOSE implements optional filters and refine-ment mechanisms that can be used to control the re-sults returned by the API. These can be specified as HTTP parameters (i.e. “ ?
These filters and refinement mechanisms work in-dependently from the configuration file, the SPARQL endpoint specified in it, and the scope of the RDF data available. They provide common and advanced filter-ing, sorting, and manipulative functionalities that can be used with any result set returned by the API. The operations that can be used are described as follows.
Excluding rows with empty data
Parameter: exclude=
Filtering rows
Parameter: filter=
Sorting rows
Parameter: sort=
Formatting results
Parameter: format=
Accept: text/csv and the URL of such request includes format=json , the final table is returned in JSON.
Table 1.
The key-value pairs containing general information about the API.
Description
The base URL of the API (e.g. “ /api/v1 ”) The section type – only “ api ” is al-lowed
The base URL of the webpage from which the API is available (e.g. “ https://w3id.org/oc/in-dex ”) The HTTP methods supported, that can be “ get ”, “ post ”, or both
The title or name of the API
A textual description of the API
The textual string defining the version of the API
The textual string defining information about the licenses associated to the API, the data it returns, etc.
The contact information for the API.
The SPARQL endpoint URL to query
The path of a Python file implementing functions that can be called in the pre-processing and postprocessing steps of each operation
Listing 1. The hash-format syntax.
Listing 2. An excerpt of the structure of a RAMOSE configu-ration document, organised in two conceptual sections: the one with information about the API (in italic in the listing), and the other describing all the operations that the API ex-poses. .3.5.
Transforming JSON results
Parameter: json=
In an API call, it is possible to specify one or more parameters of the same kind if you want to run the same filter and/or refinement multiple times. For in-stance, exclude=citing&exclude=cited ex-cludes from the result all the rows that have unspeci-fied the value of either the field citing or the field cited . Table 2. The key-value pairs defining each operation of the API. All the fields accompanied with an “ [O] ” are optional in the configuration file.
Description
The URL of the operation. It may contain zero or more parameters name between {…} (e.g. “ /cita-tions/{doi} ”) The section type – only “operation” is allowed [O]
The shape (type and textual form) an input parameter of the operation must have (e.g. “ str(10\..+) ”). Possible types are strings (“ str ”, which is the default value), integers (“ int ”), floating numbers (“ float ”), durations (“ duration ”), and date times (“ datetime ”). The regular expression is used to catch the value of the parameter from the URL. [O]
The Python functions used to preprocess the input parameters. One can specify one or more functions separated by “ --> ” which must take in input the name of one or more parameters (separated by a comma) between curly brackets, (e.g. “ lower(doi) --> encode(doi) ”) [O] The Python functions used to postprocess the results returned after the execution of the SPARQL query. One can specify one or more functions separated by “ --> ” which must take in input the name of zero or more variables (separated by a comma) returned by the SPARQL query between curly brackets (e.g. “ decode_doi(citing, cited) ”) The HTTP method used to send the request to the SPARQL endpoint for this operation, that can be either “ get ” or “ post ” A textual description of the operation
A list of types of the variables that will be returned by executing the operation, split by a space (“
The SPARQL query to perform on the specified SPARQL endpoint. The query may include any input parameter of the operation between “ [[...]] ” (e.g. “ [[doi]] ”) which is replaced with its current value before calling the SPARQL endpoint he order in which each parameter of the same type of a filter/refinement is run by RAMOSE depends on the order in which it is specified in the URL. However, the order of execution of the particular types of fil-ter/refinement do not follow the actual order in the URL of the API call. Rather, RAMOSE first processes exclude , then filter , which is followed by sort . Then it applies format and, if the requested format is JSON, it finally executes json . Run and deploy RAMOSE
There are three ways to run RAMOSE. First, one can use its command line interface (CLI) to execute it. Second, it can be executed directly within a web server. Finally, it can be used directly within a Python code by using its main class, i.e.
APIManager . These pos-sibilities are described in the following subsections.
Command line interface (CLI)
RAMOSE can be run via CLI by specifying one or more configuration documents (parameter -s ) and the operation to call (parameter -c ), composed by concat-enation of the API base URL with the operation URL, plus the wanted parameters for filtering and refining if needed. Also, it can take as input additional optional parameters (a) to specify the format of the output (pa-rameter -f , JSON being the default), (b) to specify the [ { "citing":"10.3233/ds-190019", "cited":"10.1108/jd-12-2013-0166" }, { "citing":"10.3233/sw-160224", "cited":"10.1108/jd-12-2013-0166" }, … ] Listing 4. The same result set returned by RAMOSE shown in Listing 3, but in JSON format. [ { "citing":"10.3233/ds-190019", "cited":["10.1108","jd-12-2013-0166"] }, { "citing":"10.3233/sw-160224", "cited":["10.1108","jd-12-2013-0166"] }, … ]
Listing 5. The same result in JSON shown in Listing 4, trans-formed according to the rule array("/",cited) , which splits the string value of the field cited according to the separator / and organises the resulting strings into a list. [ { "citing":{"prefix":"10.3233", "suffix":"ds-190019"}, "cited":["10.1108","jd-12-2013-0166"] }, { "citing":{"prefix":"10.3233", "suffix": "sw-160224"}, "cited":["10.1108","jd-12-2013-0166"] }, … ] Listing 6. The same result in JSON shown in Listing 5, trans-formed according to the rule dict("/",citing,pre-fix,suffix) , which splits the string value of the field citing according to the separator / and organises the re-sulting strings into a JSON object with the new field labels prefix and suffix . [ { "citing":{"prefix":"10.3233", "suffix": "ds-190019"}, "cited":[ {"one":"1","two":".1108"}, {"one":"jd-12-2","two": "13-0166"} ] }, { "citing":{"prefix":"10.3233", "suffix": "sw-160224"}, "cited":[ {"one":"1","two":".1108"}, {"one":"jd-12-2","two": "13-0166"} ], }, … ] Listing 7. The same result in JSON shown in Listing 6, transformed according to the rule dict("0",cited,one,two) , which splits each string value of the list in the field cited according to the separator and organises the resulting strings into a JSON object ac-cording to the new fields one and two . citing,cited 10.3233/ds-190019,10.1108/jd-12-2013-0166 10.3233/sw-160224,10.1108/jd-12-2013-0166 … Listing 3. A result set returned by RAMOSE in CSV format. ame of the file in which to store the output (parameter -o , (the output is printed in the shell output stream if a filename is not specified), and (c) to specify the method to use for the API request (parameter -m , GET being the default). The template of a CLI call of RA-MOSE is shown as follows: python ramose.py -s
RAMOSE can also be used within a web server which is instantiated by using the parameter -w spec-ifying the IP address of the host and the related port separated by “:” (e.g. ). RA-MOSE uses Flask to run the web server on the speci-fied host machine. To deploy the REST API in lo-calhost (i.e. 127.0.0.1), one can use the following command: python ramose.py -s
RAMOSE The Python class
APIManager imple-ments all the functionalities made available by RA-MOSE. The signature of the class is as follows:
APIManager(conf_files)
The constructor of the class takes as input a list of API configuration files defined according to the hash format, and makes all the operations they define avail-able to call using the following method: exec_op(op_complete_url,method,content_type)
This method takes as input a string containing the complete URL of the operation to execute, i.e.
Figure 3. The number of requests received by the OpenCitations SPARQL endpoints vs. the calls to the OpenCitations REST APIs between January 2018 and March 2020 – listed by trimester. The orange line represents the moving average of the number of Web REST API calls. Note that the vertical axis has a logarithmic scale. https://github.com/zuphilip/zotero-open-citations). Our interactions with the developers of those services have been instrumental in guiding the development of the facilities that RAMOSE makes available, includ-ing the filters and refinement mechanisms that have demonstrated their usefulness is several scenarios, and have led, for example, to the adoption of JSON as the default data format returned by RAMOSE, to meet to the input requirements of VOSviewer. Related works
In the past, several tools, in particular REST APIs on top of SPARQL endpoints, have been developed to leverage RDF data served through SPARQL query in-terfaces, often employing bespoke solutions tailored to their data, such as the DBpedia REST APIs (https://wiki.dbpedia.org/rest-api) and the Europeana Search API (https://pro.europeana.eu/page/search). Among works that are closer to what RAMOSE pro-vides, the following deserve specific mention. BASIL [14] is a cloud platform that supports shar-ing and reusing of SPARQL queries, and automati-cally generates Web APIs from those, which can be easily embedded into users' applications. Moreover, it allows one to reuse results as HTML snippets, called “views”. While pre-processing operations are possible, the only way to undertake post-processing operations is separately to implement ad-hoc procedures on the returned results. BASIL runs using Java and requires the installation and configuration of a MySQL server on the running machine. Another important tool in this category is grlc (http://grlc.io/) [15], a lightweight server that trans-lates on the fly to Linked Data API calls SPARQL queries stored in a GitHub repository, in a local filesystem, or listed at a URL. The idea behind grlc is to implement an API mapping along with the use of SPARQL decorators which extends the original que-ries with other generated metadata which add extra functionalities to the APIs. In order to make this hap-pen, the specified archive must contain a collection of SPARQL queries as .rq files and include the decora-tors as comments inside each .rq file. With grlc the pre-/post-processing operations are defined as decora-tors, and each API call can point to a different SPARQL endpoint by specifying the decorator “end-point” before the SPARQL query. A useful add-on to integrate with the grlc, suggested by its authors, is SPARQL Transformer [16]. This tool allows one to simplify the JSON outputs of a SPARQL query by re-shaping and simplifying the final JSON schema. SPARQL Transformer relies on a single JSON object to define which data should be extracted from the endpoint and what shape should they assume. Although this approach refines the final output, using it alone does not allow one to perform custom opera-tions on the returned results (e.g. data normalisation or cleansing), which are delegated to separated post-pro-cessing operations, e.g. using the grlc features, or ad-hoc functions. SPARQL Transformer is written in Ja-vaScript and can be imported and integrated in an HTML module. In [17], Schröder et al . present a generic approach to convert any given SPARQL endpoint into a path-based JSON REST API. This work focused mostly on simple CRUD (create, retrieve, update, delete) work-flows. The idea behind this approach is to build API paths that follow RDF triple patterns, e.g. the call /class/dbo:Country/dbr:Germany returns a JSON object for the specified entity (i.e. the DBpe-dia resource representing Germany). Despite being very intuitive for Semantic Web practitioners, it is not of immediate usage for adopters that are not ac-quainted both with RDF knowledge organisation and the scope of the dataset at hand. In [18], Hopkinson et al Conclusions
In this article, we have introduced RAMOSE, the Restful API Manager Over SPARQL Endpoints. RA-MOSE is an open source Python software develop-ment that allows one to create Web REST API inter-faces to one or more SPARQL endpoints by editing a configuration file in Markdown-like syntax, automat-ically generating documentation and a web server for testing and monitoring purposes. This generic soft-ware can be used over any SPARQL endpoint simply by creating the appropriate configuration text file. We have illustrated all the features that RAMOSE imple-ments and we have presented the analysis of our mo-tivating scenario, namely the dramatic increase in us-age of OpenCitations data demonstrated by our access logs, so as to demonstrate the benefit that such a tool has brought to OpenCitations in terms of user interac-tion with its data. We commend the use of RAMOSE to others wishing to expose their own RDF data via a REST API. In the future, we aim at extending RAMOSE with missing CRUD (Create, Read, Update, Delete) opera-tions so as to fully support Semantic Web developers when interacting with the triplestores they own. Sec-ondly, we want to enhance RAMOSE capabilities and support web developers in interacting with other types of data sources, such as JSON, XML, CSV data dumps and relational databases, so that it will be possible to leverage the same software solution over different data sources.
References [1]
R. T. Fielding, ‘REST APIs must be hypertext-driven’,
Untan-gled musings of Roy T. Fielding , Oct. 20, 2008. https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyper-text-driven. [2]
S. Peroni and D. Shotton, ‘OpenCitations, an infrastructure or-ganization for open scholarship’,
Quantitative Science Studies , vol. 1, no. 1, pp. 428–444, Jan. 2020, doi: 10.1162/qss_a_00023. [6]
S. Peroni, D. Shotton, and F. Vitali, ‘One Year of the OpenCi-tations Corpus’, in
The Semantic Web – ISWC 2017 , Cham, Switzerland, 2017, vol. 10588, pp. 184–192, doi: 10.1007/978-3-319-68204-4_19. [7]
S. Peroni and D. Shotton, ‘The SPAR Ontologies’, in
The Se-mantic Web – ISWC 2018 , Cham, Switzerland, 2018, vol. 10842, pp. 119–136, doi: 10.1007/978-3-030-00668-6_8. [8]
G. Hendricks, D. Tkaczyk, J. Lin, and P. Feeney, ‘Crossref: The sustainable source of community-owned scholarly metadata’,
Quantitative Science Studies , vol. 1, no. 1, pp. 414–427, Feb. 2020, doi: 10.1162/qss_a_00022. [9]
L. L. Haak, M. Fenner, L. Paglione, E. Pentz, and H. Ratner, ‘ORCID: a system to uniquely identify researchers’,
Learned Publishing , vol. 25, no. 4, pp. 259–264, Oct. 2012, doi: 10.1087/20120404. [10]
S. Peroni and D. Shotton, ‘Open Citation Identifier: Definition’. Figshare, Jan. 23, 2019, Accessed: Jun. 21, 2019. [Online]. Available: https://doi.org/10.6084/m9.figshare.7127816. [11]
I. Heibi, S. Peroni, e D. Shotton, ‘Software review: COCI, the OpenCitations Index of Crossref open DOI-to-DOI citations’,
Scientometrics , vol. 121, n. 2, pagg. 1213–1228, set. 2019, doi: 10.1007/s11192-019-03217-6 [12]
M. Daquino, I. Heibi, S. Peroni, and D. Shotton, ‘OpenCitations 2018-2020 requests: SPARQL endpoints vs REST APIs v2’. Zenodo, Jul. 13, 2020, doi: 10.5281/ZENODO.3953068. [13]
N. J. van Eck and L. Waltman, ‘Software survey: VOSviewer, a computer program for bibliometric mapping’,
Scientometrics , vol. 84, no. 2, pp. 523–538, Aug. 2010, doi: 10.1007/s11192-009-0146-3. [14]
E. Daga, L. Panziera, and C. Pedrinaci, ‘BASIL: A Cloud Plat-form for Sharing andReusing SPARQL Queries as Web APIs’, in
ISWC-P&D 2015 - ISWC 2015 Posters & Demonstrations Track , Aachen, Germany, 2015, vol. 1486, [Online]. Available: http://ceur-ws.org/Vol-1486/paper_41.pdf. [15]
A. Meroño-Peñuela and R. Hoekstra, ‘grlc Makes GitHub Taste Like Linked Data APIs’, in
The Semantic Web , vol. 9989, H. Sack, G. Rizzo, N. Steinmetz, D. Mladenić, S. Auer, and C. Lange, Eds. Cham: Springer International Publishing, 2016, pp. 342–353. [16]
P. Lisena, A. Meroño-Peñuela, T. Kuhn, and R. Troncy, ‘Easy Web API Development with SPARQL Transformer’, in
The Se-mantic Web – ISWC 2019 , vol. 11779, C. Ghidini, O. Hartig, M. Maleshkova, V. Svátek, I. Cruz, A. Hogan, J. Song, M. Lefrançois, and F. Gandon, Eds. Cham: Springer International Publishing, 2019, pp. 454–470. [17]
M. Schröder, J. Hees, A. Bernardi, D. Ewert, P. Klotz, and S. Stadtmüller, ‘Simplified SPARQL REST API: CRUD on JSON Object Graphs via URI Paths’, in
The Semantic Web: ESWC 2018 Satellite Events , vol. 11155, A. Gangemi, A. L. Gentile, A. G. Nuzzolese, S. Rudolph, M. Maleshkova, H. Paulheim, J. Z. Pan, and M. Alam, Eds. Cham: Springer International Pub-lishing, 2018, pp. 40–45. [18]
I. Hopkinson, S. Maude, and M. Rospocher, ‘A Simple API to the KnowledgeStore’, in
ISWC-DEV 2014 - ISWC Developers orkshop 2014 , Aachen, Germany, 2014, vol. 1268, [Online]. Available: http://ceur-ws.org/Vol-1268/paper2.pdf. [19]
L. Rietveld and R. Hoekstra, ‘The YASGUI family of SPARQL clients’,
Semantic Web , vol. 8, no. 3, pp. 373–383, Dec. 2016, doi: 10.3233/SW-150197. [20]
D. V. Camarda, S. Mazzini, and A. Antonuccio, ‘LodLive, ex-ploring the web of data’, in
Proceedings of the 8th International Conference on Semantic Systems - I-SEMANTICS ’12 , Graz, Austria, 2012, p. 197, doi: 10.1145/2362499.2362532. [21]
I. Heibi, S. Peroni, and D. Shotton, ‘Enabling text search on SPARQL endpoints through OSCAR’,
Data Science , vol. 2, no. 1–2, pp. 205–227, Nov. 2019, doi: 10.3233/DS-190016. [22]
F. Å. Nielsen, D. Mietchen, and E. L. Willighagen, ‘Scholia, Scientometrics and Wikidata’, in
The Semantic Web: ESWC 2017 Satellite Events , vol. 10577, Cham, Switzerland: Springer International Publishing, 2017, pp. 237–259. [23]
N. Zaki and C. Tennakoon, ‘BioCarian: search engine for ex-ploratory searches in heterogeneous biological databases’,