SOLID Server SPARQL Endpoint


#1

Hey guys !

I am wondering if there is (or if not, if there is it in roadmad?), to have a remote, server side SPARQL endpoint on SOLID POD servers ?

At the moment, when I need to query data from a SOLID POD document, I do it by getting the full document locally and running SPARQL queries on the local document. This is OK for small document, but to scale to bigger documents, real life cases, a SPARQL server side endpoint would be pretty useful, if not mandatory for decent performance. Also, it could be a security exposure to always transfer a full document to the client by the way …

Any feedback on this ?

Thank you for help!
Walter


#2

Hi Walter,

We should definitely think about different server-side interfaces to RDF.
However, I expect LDP to remain the only mandatory interface, and other interfaces such as a SPARQL endpoint (but there are others).

The reason for this is that SPARQL endpoints can be computationally expensive, and as such not a good idea to mandate.

However, it also brings the question of how we can build applications without making assumptions of the RDF interfaces present on the server side. I’ve covered that topic here: https://ruben.verborgh.org/blog/2017/12/20/paradigm-shifts-for-the-decentralized-web/#interfaces-become-queries

Best,

Ruben


#3

I remember to ask & have an open discussion about SPARQL integration into solid spec. You can look at it into the Solid Gitter chat room (just search for ‘sparql’) that may be of your interest :wink:

Also may be of your interest:

Regards


#4

Ruben,

How well could this work client side - for example using Comunica over LDP to support SPARQL queries?

I realise performance will be slow, but evenso it would be a useful capability.

How hard would it be to do this over a pod, or over multiple pods? Any examples over LDP?

I’d be very interested to try doing SPARQL client side, although I have my hands full with the basics at the moment - figuring out how to identify and characterise endpoints. Any tips in that direction welcome BTW. I’ve found a few papers, one with a bunch of useful queries, but looking for inspiration and examples of how others approach this.

For anyone curious about SPARQL I have to say it is very powerful, and SPARQL itself is not that hard, just hard to learn with the available resources. Two main aspects to this learning curve: first SPARQL itself although that’s a pleasure once you get the basics, second locating and learning what you can do with a particular public endpoint. I think these are both soluble problems, but at the moment present a significant barrier to outsiders.

More eyes on this area could help, so I encourage anyone curious to have a poke around. I’m able to give some pointers to save some of the early pain if anyone is interested, and am building some software to help with the issues mentioned - it will be great to see if this is useful to others and get some feedback on this too.


#5

Quick comments on that are: a) Solid servers support the SPARQL UPDATE format as a MIME type for PATCH requests, but not the SPARQL UPDATE protocol. b) Globbing has been removed (because of cost concerns).

Yes, and the benefit being that Comunica could detect SPARQL endpoint support on the server side, and use that whenever available. If not, it fall back to another strategy (such a the one you mention).

And we might as well do it with GraphQL really. The language shouldn’t be a blocker for anyone.

Feasible; these are questions that my team is working on.


#6

Can you elaborate. I haven’t touched GraphQL, remember watching your presentation to the GraphQL folks. So I’m thinking maybe you are talking about putting a GraphQL layer over SPARQL?


#7

Yes.

https://comunica.github.io/Article-ISWC2018-Demo-GraphQlLD/
demo


#8

Thanks. I’ve not looked into GraphQL and like JSON-LD I’m not drawn to it. They both ‘feel’ wrong. Its odd to me that GraphQL appears not to support graphs, but as in your article for instance, it turns them into trees. Its things like that that turn me away.

Anyway I shall watch with interest and if it looks useful at some point will look at GraphQL but for now it doesn’t appeal to me. Thanks again for your answers.


#9

Than

Thank you @RubenVerborgh , but with LDP you cannot retrieve just part of a document, can you ?
What about the scenario of a social app, with all your comments to posts stored on a document on your pod. With only a few comments , it is ok to retrieve the full document client side. But if the users have done thousands of comments, it does not makes sense to retrieve them all on the client and then handle the query in the comments (to get all the comments for a given post for example) client side… In this case I want to be able to query with SPARQL (or similar) just the comments I want and let the server do the work and give me back only what I need ! If we want to be able to develop real life, scaling applications on top of SOLID, this seems mandatory to me.

Also, I have noticed that when I want to retrieve just one entry of a document (using myuri#myentry), I realize that I retrieve client side the full document !


#10

You can retrieve everything with LDP, just like you can with a SPARQL endpoint.
It’s just that some queries require n operations with LDP, and m with a SPARQL endpoint, where usually m ≤ n, but can be different as well.

Simply said: you night need multiple requests.

But if the users have done thousands of comments, it does not makes sense to retrieve them all on the client and then handle the query in the comments (to get all the comments for a given post for example) client side…

It might or might not. If those thousands of comments are on thousands of different servers, I guarantee you that LDP will be faster, for instance.

That makes sense indeed.

No need to convince me that a SPARQL endpoint on the server has advantages. Obviously it would, so I can imagine it being part of at least some Solid servers (and this is what we have in mind). But that doesn’t mean it’s a good idea to mandate it on all servers.

In the vision I linked above, client applications would always be written with (a variation of) SPARQL queries. If the server has a SPARQL endpoint, then the server does the query. If the server does not, then the client does the query, for instance over LDP.

SPARQL endpoints don’t necessarily scale better for everything though; one pointer in that regard is https://linkeddatafragments.org/publications/iswc2014.pdf

Ruben


#11

To you and to me perhaps, yes :slightly_smiling_face:
But to thousands of front-end developers, it’s the exact opposite.

So it’s for them that we’re also building that option.


#12

Thank you @RubenVerborgh !

I am pretty new with all this stuff, so thank you for the time you take to explain to me :slight_smile:

If LDP is making the job and I can do partial request on documents server side, and this is the one standard that all SOLID servers will implement, and it is more efficient, then I will go for it !

Can you tel me where I can get good documentation / tutorials / examples about LDP ?

Thank you !
Walter