- From: Jacopo Scazzosi <jacopo@scazzosi.com>
- Date: Tue, 7 May 2024 12:05:17 +0200
- To: public-rdfjs@w3.org
Hi all, As some of you might already know, I’m the maintainer of quadstore [1], an embedded and persistent RDF graph database for JS runtimes. A bit like SQLite but for RDF. Though multiple orders of magnitude far from established libraries such as N3.js, over the last few months I’ve noticed occasional increases in downloads that made me wonder whether others are actually using quadstore (as opposed to checking it out and then move on to different alternatives). The only project (that I’m aware of) that builds on quadstore is m-ld [2] but that doesn’t seem to be what’s pulling the number of downloads upward. I think it would be sensible to either move it into a dedicated organization or perhaps into the RDF/JS organization itself, much like what happened with N3.js. The only trouble with the latter option is that, from a code perspective, quadstore is actually four different repositories: - quadstore itself - quadstore-comunica (a SPARQL engine built as a custom configuration of Comunica and distributed as a no-dependencies bundle) - quadstore-browser (reference project for how to use quadstore in browsers) - quadstore-perf (stuff related to performance testing) The main goal of moving quadstore into an organization would be to ensure the project’s long-term survival, opening it up for more involvement from the community and reducing the proverbial "bus factor”. The project itself is, IMHO, in a relatively good state: - the API has stabilized a couple of years ago - the store’s performance levels are really good - it works in browsers and across major server-side runtimes (Node.js, Deno, Bun) - it is built and distributed as both CJS and ESM - dependency count is low (3 direct, 15 between direct and indirect) - it can use any storage backend compatible with the Level interfaces [3] - > 98% coverage of SPARQL tests [4] What can be improved is SPARQL query optimization in quadstore-comunica, introducing dedicated optimizing actors to push filtering operations down to quadstore itself and make the most out of its indexes (as opposed to having to comb through entire datasets in memory). Support for RDF* is also missing. What do you think? Do you happen to use quadstore or be aware of someone/something that does? Best, Jacopo. [1]: https://github.com/jacoscaz/quadstore [2]: https://m-ld.org/ [3]: https://github.com/Level [4]: https://github.com/jacoscaz/quadstore-comunica/tree/master/engine#sparql-coverage
Received on Tuesday, 7 May 2024 10:05:35 UTC