Snapquery: FAIR Management of Query Sets to Mitigate Query Rot in Knowledge Graphs

Abstract

Will the “cats” Wikidata SPARQL query example still work in the future? While link rot has been a known issue, the Query Rot problem has not been investigated much in the past. We introduce an approach for quality assessment and refactoring of query sets and evalu- ate its implementation for SPARQL. By applying information hiding and dependency inversion principles, we hide the details of the query and introduce the snapquery SPARQL query endpoint middleware to maintain expected query behavior independently of technical details, context, and even, as a future option, the query lan- guage. “snapquery cats” is designed to work consistently in the future no matter what changes. This approach enables the swapping of endpoints, conceals the complexity of (federated) queries, and manages SPARQL query sets by making the queries FAIR first-class citizens of the Knowl- edge Graph infrastructure. The increased abstraction aligns well with state-of-the-art Artificial Intelligence approaches that allow the use of natural language input to generate query sets. This novel, systematic, and semi-automatic approach is generally useful in most knowledge graph management scenarios. It allows for the gath- ering of query metadata from real-world environments on the fly, sup- porting the creation of test suites, benchmarks, challenges, dashboards, and other analytical applications for query performance and health moni- toring. Our approach contributes to advancing knowledge engineering by bridging gaps between knowledge graphs, software engineering, and large language models. We reproduce use cases of the Scholia, QLever and general Wikidata projects to demonstrate functionality and measure non-functional quality improvements over those projects.We conclude that advancing Knowledge Graph management requires 1. introducing queries as FAIR first-class citizens by developing platform- independent named parameterized queries (thus confirming a 2019 pro- posal), 2. structured, implementation-independent error messages, and 3. shifting to higher abstraction levels that support human and machine generated general text input. We suggest corresponding improvements to the SPARQL standard.