WASM?

[bherr2]

Has there been any exploration of compiling qlever to WASM for running queries on browsers client-side?

[lpugin]

Where would the data be stored?

[bherr2]

Probably an option of either in-memory or indexeddb

[valentinedwv]

Maybe the question can this be duckdb'd... leave data inplace, create in-memory indexes...
And what's a parquet like format for rdf?

[bherr2]

The use case I have in mind is to be able to run qlever in the browser for serverless deployments and experimentation. I'm not very familiar with qlever's architecture, but I was just thinking it'd startup with no data, then you would add rdf data either via sparql updates or functions or the like.

[ktk]

That works with Oxigraph already.

[ktk]

This is definitely something that we should have at some point in the future but it does not have very high priority for the moment. As usual this changes if someone pays for it.

Meanwhile I recommend using Oxigraph in WASM, that's what we do as well.

[bherr2]

No worries, yeah, I'm using Oxigraph WASM now. Blazegraph is our go to server-side triple store, but I'm always keeping tabs on the landscape as we will eventually need to move away from it (abandonware).

As such, I'm working on a project that can switch out "backends" on the client (currently N3.js, Quadstore, and Oxigraph). I also have a server-side version with backends I can switch too. Anyway, I'm sure you know each triple store has slight differences in SPARQL processing, scalability, etc and something like this would allow test driving different techs pretty easily.

[hannahbast]

@bherr2 I am curious why Blazegraph is still your "go to triple store on the server side". It is not longer maintained and the performance is ... well: https://qlever.dev/evaluation

[bherr2]

Yes, absolutely! It's also in use in the biomedical community still, like with Ubergraph and the like. I continue to keep tabs on other triple stores, but so far when it comes to the types of complex queries I run as part of the Human Reference Atlas, I haven't found a suitable replacement. So, primarily its handling of complex queries with decent performance, compatibility with other groups in the biomedical ontology circle, stability when deployed, and the ability to add data on the fly are all important factors. Perhaps qlever or oxigraph can do all these things now, but each time I dip my toe in, I feel it's not quite ready for us. But one day!

[valentinedwv]

Why blazegraph... tech debt... but one of the missing is the full text capabilities. Similarity scores.