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

Hi Kingsley,

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

Exactly. See it rather as a questioning of apples instead.

> Thus, that important
> context cannot be dislocated or cloaked in any comparison about SPARQL
> endpoints.


If we take it as a comparison of SPARQL endpoints,
then it’s not a fair one indeed.

However, we should take this as a comparison of
“complex ecosystem in which SPARQL queries
 can be executed by multiple actors”.

So see the SAGE client+server solution
as a system that processes SPARQL queries,
and see Virtuoso as one representative
of a specific class of such systems that do so,
namely SPARQL endpoints.

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

Yes; I’ve made it a habit to always refer to
“the SPARQL query language” and “the SPARQL protocol”.
I consider the former to be a great thing for the public Web,
the latter not so much.
It’s very confusing that both things are named “SPARQL”,
and that this double definition was baked into the acronym.

>> 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 mean that the SPARQL Protocol is, in my opinion,
unfit as an API to provide reliable access to public data,
because it is very expressive and hence expensive for one side.
I knew few (if none) other APIs that require similar server efforts.

I do see a usage for the SPARQL Protocol in closed networks.

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

The moment they support the SPARQL Protocol
is the moment they will have similar problems
as other servers supporting the SPARQL protocol.

What I have been arguing with the Linked Data Fragments research,
is that the problems with public SPARQL endpoints
are inherent due to their choice of interface, not their implementation.

SAGE proposes a client/server ecosystem
that is able to evaluate SPARQL queries,
and because of their different choice of interface/protocol,
they are able to do so with different performance characteristics.

> I am
> trying to understand the context of their audacious claims that
> reference Virtuoso i.e., "apples vs apples" rather than "apples vs
> oranges” .

In order to follow the comparison,
consider SPARQL endpoints and their clients
as ecosystems evaluating queries.
Then it’s apples versus apples.

Best,

Ruben

Received on Sunday, 9 September 2018 16:55:46 UTC