W3C home > Mailing lists > Public > public-lod@w3.org > September 2018

Re: Release of SAGE 1.0: a stable, responsive and unrestricted SPARQL query server

From: Ruben Verborgh (UGent-imec) <Ruben.Verborgh@UGent.be>
Date: Sun, 9 Sep 2018 11:52:06 +0000
To: Kingsley Idehen <kidehen@openlinksw.com>
CC: "public-lod@w3.org" <public-lod@w3.org>
Message-ID: <6F31238D-A6F6-4E4E-8357-D96F9754426E@ugent.be>
HI Kingsley, all,

> Can you provide a live SPARQL endpoint or not? 

While not involved in the SAGE research,
I’d like to make a remark in this context.

If I read between the lines, I interpret Kingsley’s question
as an objection that, indeed, SAGE does not provide a SPARQL endpoint interface.
That is, SAGE does not implement the SPARQL Protocol part of the W3C standard—
notwithstanding its implementation of the SPARQL Query Language standard,
which it achieves through a combination of server and client software.
So another thing I’m reading between the lines is that SAGE,
by not implementing the SPARQL protocol,
participates in a different kind of competition than Virtuoso does.

Very similar claims can be (and have been made)
in the context of our Triple Pattern Fragments research
and related work that has come out of it.

However, this was precisely what we wanted to achieve
with the Linked Data Fragments initiative:
to question existing Web APIs for querying Linked Data on the Web.
It was my belief back then—and still is—that the SPARQL protocol
is unfit as an API for the public Web.
We need a discussion on different kinds of APIs,
and solutions where servers and clients work together.

So rather than saying that the lack of SPARQL Protocol support
is a weakness of SAGE, I would say it’s a strength.
I hope to see more solutions where the interface is not the SPARQL Protocol.
Importantly, this doesn’t mean you can’t execute SPARQL queries.
Just set up a local client that runs the SAGE code,
and treat it as a local SPARQL endpoint.

My prediction is that, especially if decentralization becomes successful,
we’ll see more and more non-SPARQL interfaces to RDF.
Let’s embrace the resulting heterogeneity, keep SPARQL as a query language,
and think about clever clients to deal with these new opportunities.


Received on Sunday, 9 September 2018 11:53:55 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 9 September 2018 11:53:55 UTC