In Ticket Virtuoso wikidata import performance - virtuoso wikidata endpoints as part of snapquery wikidata mirror network · Issue #1326 · openlink/virtuoso-opensource · GitHub, @TallTed offered me to start a discussion here. GitHub - WolfgangFahl/snapquery: Frontend to Introduce Named Queries and Named Query Middleware to wikidata is an open source project that started at the Wikimedia Hackathon 2024 in Tallinn with idea to mitigate query rot by introducing a middleware to provide named parameterized queries independent of the query execution context. The idea is explained in a scientific paper with a preprint being available at Snapquery/Paper2024-07 - BITPlan cr Wiki. Current use cases are
- scholia which might have to rewrite some 300 named parameterized queries due to query rot
- wikidata in general due to the necessary migration away from blazegraph to another endpoint
- other projects that need to use federated queries and benefit from a blackbox approach of handling queries as first class citizens in a knowledge graph
To make the snapquery idea happen, we are working on a technology-independent mirror infrastructure for wikidata, that has copies of the wikidata content leveraging different endpoint technologies. Currently we have blazgraph, qlever, triply, and virtuoso endpoints included, but we are also investigating others as outlined in Get your own copy of WikiData - BITPlan Wiki.
We would love to motivate more organizations and individuals to run wikidata copy endpoints and make them available publicly and therefore accessible for the snapquery middleware. What do you think?