SPARQL is a standard query language for retrieving and manipulating RDF data. However, the majority of SPARQL implementations require the data to be available in advance, i.e., to exist in main memory or in a RDF repository (accessible through a SPARQL endpoint). Nonetheless, Linked Data exists in the Web in various forms; even an HTML Web page can contain RDF data through RDFa, or RDF data may be dynamically created by a Web Service. In this paper, we propose and demonstrate an extension of SPARQL 1.1, called SPARQL-LD, that allows to directly and exibly exploit this wealth of data. SPARQL-LD allows to fetch, query and integrate in the same SPARQL query: i) data coming from online RDF or JSON-LD les, ii) data coming from dereferenceable URIs, iii) data embedded in Web pages as RDFa, iv) data that is dynamically created by Web Services, and v) data coming by querying other endpoints. A distinctive characteristic of this extension is that it enables to fetch and query even data in datasets returned by a portion of the query, i.e. discovered at query-execution time.
Linked Data [
In this paper, we propose and demonstrate an extension of SPARQL, called SPARQL-LD (from Linked Data), that overcomes the aforementioned limitations enhancing thereby the flexibility of the language. SPARQL-LD extends the applicability of the service operator enabling to fetch and query any Web source containing RDF data (even RDF data that is created dynamically, e.g. by RESTful Web APIs). SPARQL-LD does not require to have declared the named graphs, thus one can even query a dataset returned by a portion of the query, i.e. its IRI is derived at query execution time. Fig. 1 illustrates an example of a query that can be answered by SPARQL-LD. The query returns all co-authors of P. Fafalios (1st author of this paper) together with the number of their publications and the number of distinct conferences in which they have a publication. Notice that this query combines and integrates: i) data embedded in a Web page as RDFa (lines 3-4), ii) data coming from dereferenceable IRIs derived at query-execution time (line 5), and iii) data coming by querying another endpoint (lines 6-8).
For answering the above query with the original SPARQL, one must download and load to a repository the triples that are contained in the Web page (line 3) as well as the triples regarding the publications of all co-authors (line 5), considering of course that these triples are not available through an endpoint. The problem may become unfeasible if these resources are derived at query-execution time, i.e. in case we are unaware of their IRIs at query-writing time. On the contrary, using SPARQL-LD and exploiting the Linked Data principles, such different types of resources can be directly queried without needing to retain a repository.
Note also that the proposed extension is actually a generalization of SPARQL in the sense that every query that can be answered by the original SPARQL can be also answered by SPARQL-LD. Specifically, if the IRI given to the service operator corresponds to a SPARQL endpoint, then it works exactly as the original SPARQL (the remote endpoint evaluates the query and returns the result). Otherwise, instead of returning an error (and no bindings), it tries to fetch and query the triples that may exist in the given resource.
Related Works. SPARQL-LD offers a method to execute queries over the Web of
Linked Data. Such approaches can be classified in three categories: query
federation (integrated and transparent access to distributed sources, e.g. the DARQ
engine [
The service operator of SPARQL 1.1 (service a P ) is defined (in [
The implementation can be described through the following process: we first
check if the IRI corresponds to a SPARQL endpoint by submitting the ASK query
“ASK f?x ?y ?zg”. In case we get a valid answer, we continue just like the
default query federation approach, i.e. the corresponding graph pattern (query)
is submitted to the endpoint. In case we do not get a valid answer, it means
that the IRI is not the address of an endpoint. Then, we read the content type
header field of the IRI by opening an HTTP connection and setting the value
application/rdf+xml to the ACCEPT request header. Now, according to the
returned content type, we fetch and query the corresponding triples. For the case of
HTML Web pages (the content type is text/html or application/xhtml+xml),
we try to fetch and query the RDF triples that may be embedded in the Web
page as RDFa. If the Web page does not contain any RDF data, the query
returns no bindings. For reading possible RDF triples in a Web page, we
exploit the Semargl framework [
Optimizations. We adopt the following optimization techniques for saving both time for the user side and load for the server side. -Index of known endpoints. We have seen that, compared to the original service operator, the only additional cost is the time to run an ASK query (which is in average less than 200 ms). To eliminate this cost, we keep a small index with the IRIs of known endpoints (like DBpedia’s) and of endpoints that have been 1 https://github.com/fafalios/sparql-ld 2 http://users.ics.forth.gr/~fafalios/sparql-ld-endpoint.html already checked. Thereby, if the service IRI exists in the index, the query is directly forwarded to the endpoint, otherwise an ASK query is first submitted. -Request-scope caching of the retrieved dataset(s). A SPARQL query may contain multiple service invocations against the same Web resource. In such cases, fetching and loading repeatedly the same resource triples costs both in time and in computer resources. To avoid this, for a submitted query we use a requestscope cache of datasets that have been already fetched. Thereby, in each new service invocation, we first check if the corresponding IRI exists in the cache in order to avoid re-fetching its triples. The cache is cleared after query execution. Demonstration. The ISWC’15 participants will have the opportunity to experiment with SPARQL-LD for several query scenarios including: parameterize and call a named entity extraction Web service at query-execution time, query Web pages containing RDFa, query dereferenceable IRIs that derive at query-execution time, query ontologies, query JSOL-LD, N3 and N-Triples les.
We have proposed SPARQL-LD, a SPARQL 1.1 extension that allows to directly fetch and query RDF data from heterogeneous sources via service calls. Using SPARQL-LD one can even query a dataset coming from query’s partial results, i.e. identified at query-execution time. Such a functionality motivates Web publishers to enrich their documents with RDF since it makes their data directly accessible via SPARQL (without needing to set up an endpoint), while it also enables the direct exploitation of RDF data that is created dynamically (e.g. by RESTful Web applications). In future, we will study query planning approaches and more optimization techniques aiming to reduce the transfer of data between server/endpoint and remote sources.
Acknowledgements. This work was partially supported by DIACHRON (FP7-ICT, 2013-2016) and BlueBridge (H2020 Research Infrastructures, 2015-2018).