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: Kingsley Idehen <kidehen@openlinksw.com>
Date: Sun, 9 Sep 2018 12:41:12 -0400
To: "Ruben Verborgh (UGent-imec)" <Ruben.Verborgh@UGent.be>
Cc: "public-lod@w3.org" <public-lod@w3.org>
Message-ID: <7d51aedb-e48f-ecab-faa7-1740c91e2940@openlinksw.com>
On 9/9/18 7:52 AM, Ruben Verborgh (UGent-imec) wrote:
> 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.

Hi Ruben,

Yes, and that means it isn't an "apples to apples" comparison.

As you know, Virtuoso (like other SPARQL-compliant database management
systems or stores) supports the use of the HTTP-based SPARQL Protocol
for leveraging SPARQL as the query language for performing data
definition (DDL) and/or data manipulation (DML) operations on data
represented as RDF sentence/statement collections. Thus, that important
context cannot be dislocated or cloaked in any comparison about SPARQL
endpoints.

> 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.

Okay, which makes this matter more confusing regarding its use of SPARQL
as its prime context, and additional reference to Virtuoso.

> 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.

Clearly!

>
> 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.

I don't really know what an API for the public Web means. I think its
time for us to collectively knock-up a glossary of terms to avert such
confusion.

As you know, even more so with the emergence of work from the Solid
Project, now is the time for us to finally deal with the lingering issue
of too little dog-fooding of the very technology we (and others on this
list) have collectively envangelized and supported for eons i.e., let's
use RDF and Linked Data principles to solve the pressing issue of
terminology clarification via construction and publication of glossaries
that clarify the meaning of important terms.

> We need a discussion on different kinds of APIs,
> and solutions where servers and clients work together.

Yes, of course.

>
>
> So rather than saying that the lack of SPARQL Protocol support
> is a weakness of SAGE, I would say it’s a strength.

I am not claiming that SPARQL Protocol support is a SAGE weakness. I am
trying to understand the context of their audacious claims that
reference Virtuoso i.e., "apples vs apples" rather than "apples vs
oranges" .

> 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.

We can be much clearer than this, hence the need for a glossary of 
terms [1].
> Let’s embrace the resulting heterogeneity, keep SPARQL as a query language,
> and think about clever clients to deal with these new opportunities.

That may have already happened on other fronts, but it means little if
we don't have terminology for clear  communications. As a group, we have
to be able to stop talking past ourselves circa., 2018 :)

Links:

[1] http://www.openlinksw.com/data/turtle/general/GlossaryOfTerms.ttl --
our Glossary

>
> Best,
>
> Ruben


-- 
Regards,

Kingsley Idehen	      
Founder & CEO 
OpenLink Software   (Home Page: http://www.openlinksw.com)

Weblogs (Blogs):
Legacy Blog: http://www.openlinksw.com/blog/~kidehen/
Blogspot Blog: http://kidehen.blogspot.com
Medium Blog: https://medium.com/@kidehen

Profile Pages:
Pinterest: https://www.pinterest.com/kidehen/
Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
Twitter: https://twitter.com/kidehen
Google+: https://plus.google.com/+KingsleyIdehen/about
LinkedIn: http://www.linkedin.com/in/kidehen

Web Identities (WebID):
Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
        : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this



Received on Sunday, 9 September 2018 16:41:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:22:47 UTC