ISWC 2026 · In-Use Paper Presentation

Does SPARQL federation work in the real world?

Elias Crum et al. International Semantic Web Conference 2026 · Bari, Italy

International Semantic Web Conference 2026 · Bari, Italy

Does SPARQL federation work in the real world?

A longitudinal case study over large biological SPARQL endpoints

Outline

Our five stage journey into the wild.

  1. MotivationFederation is tested on synthetic benchmarks01–02
  2. Our Design67 real queries, 20+ live endpoints, 12+ months03–05
  3. Finding 1Algorithmic federation succeeds far less often06–07
  4. Finding 2Both approaches progressively worsen08–09
  5. TakeawaysFor maintainers, users, and the community10–14

Viewer discretion
advised
This journey into the wild may, at times, prove unsettling. Rest assured: only some endpoints were harmed during this assessment, and all have since made a full recovery. Remedies for any frights encountered along the way are prescribed at the end.

01 · The promise

One question, multiple databases, no centralization.

“Which human transport proteins are expressed in the liver?”1 You your question Federation engine divides the query and mediates execution UniProt SPARQL endpoint SPARQL endpoint (RDF data) Bgee SPARQL endpoint SPARQL endpoint (RDF data) SPARQL endpoint (RDF data) UniProt proteins & what they do Bgee gene expression information other data sources each independently maintained = SPARQL endpoint, as defined in the SPARQL 1.1 ProtocolSPARQL endpoint serving RDF data model, as defined in RDF 1.1 Concepts and Abstract SyntaxRDF data one combined answer

Key messageFederation queries data where it lives and joins the results, without a central copy.

1 Paraphrased from query 109 which combines UniProt and Bgee.

02 · The gap

Federation works in the lab. Does it work in the wild?

In the lab prior benchmarks & engine papers2 BENCHMARKS ENGINES FedBench benchmark (Schmidt et al., ISWC 2011) FedBench LargeRDFBench benchmark (Saleem et al., J. Web Semantics 2018) LargeRDFBench FedX federation engine (Schwarte et al., ISWC 2011) FedX SPLENDID federation engine (Görlitz and Staab, COLD 2011) SPLENDID controlled stable reproducible In the wild everyday use, untested OMA SPARQL endpoint SPARQL endpoint (RDF data)OMA Rhea SPARQL endpoint SPARQL endpoint (RDF data) HERE BE DRAGONS Wikidata SPARQL endpoint SPARQL endpoint (RDF data) UniProt SPARQL endpoint SPARQL endpoint (RDF data) dynamic unpredictable untested ?

Key messageBenchmarks test controlled conditions; we tested federation in everyday use.

2 Benchmarks: FedBench · LargeRDFBench; engines: FedX · SPLENDID; see also FedShop · Saleem et al. 2016 · Hernández et al. 2016

03 · Two ways to federate

Source selection approaches:

“Which human transport proteins are expressed in the liver?” You Manual you name each endpoint { …human transporters… } SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE <Bgee> { …liver… } UniProt SPARQL endpointSPARQL endpoint (RDF data) Bgee SPARQL endpointSPARQL endpoint (RDF data) UniProt Bgee Algorithmic the engine selects sources SELECT … WHERE { …human transporters… …liver… } engine ? ? UniProt SPARQL endpointSPARQL endpoint (RDF data) Bgee SPARQL endpointSPARQL endpoint (RDF data) UniProt Bgee

03a · Manual federation

Federation following user-defined SERVICE clauses

Manual user defines query decomposition and endpoint targets with SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE clauses # + 8 PREFIX declarations SELECT ?rhea ?protein ?anat WHERE { GRAPH <https://sparql.rhea-db.org/rhea> { ?rhea rh:isTransport true . } ?protein up:annotation ?ann . ?protein up:organism taxon:9606 . ?ann up:catalyticActivity ?ca . ?ca up:catalyzedReaction ?rhea . BIND(uberon:0002107 AS ?anat) SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE <https://www.bgee.org/sparql> { ?seq genex:isExpressedIn ?anat . ?seq lscr:xrefUniprot ?protein . ?seq orth:organism ?organism . ?organism obo:RO_0002162 taxon:9606 . } } human transporters expressed in the liver UniProt SPARQL endpointSPARQL endpoint (RDF data) target Bgee SPARQL endpointSPARQL endpoint (RDF data) 1 whole query 2 SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE block 3 results ⋈ joins results 4 joined answer

03b · Algorithmic federation

Federation via a federation engine

Algorithmic engine decides query decomposition and endpoint targets itself3 # + 8 PREFIX declarations SELECT ?rhea ?protein ?anat WHERE { GRAPH <https://sparql.rhea-db.org/rhea> { ?rhea rh:isTransport true . } ?protein up:annotation ?ann . ?protein up:organism taxon:9606 . ?ann up:catalyticActivity ?ca . ?ca up:catalyzedReaction ?rhea . BIND(uberon:0002107 AS ?anat) SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE <https://www.bgee.org/sparql> { ?seq genex:isExpressedIn ?anat . ?seq lscr:xrefUniprot ?protein . ?seq orth:organism ?organism . ?organism obo:RO_0002162 taxon:9606 . } } human transportersexpressed in the liver federation engine UniProt SPARQL endpointSPARQL endpoint (RDF data) Bgee SPARQL endpointSPARQL endpoint (RDF data) # + 8 PREFIX declarations SELECT ?rhea ?protein ?anat WHERE { GRAPH <https://sparql.rhea-db.org/rhea> { ?rhea rh:isTransport true . } ?protein up:annotation ?ann . ?protein up:organism taxon:9606 . ?ann up:catalyticActivity ?ca . ?ca up:catalyzedReaction ?rhea . BIND(uberon:0002107 AS ?anat) { # no SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE: the engine decides ?seq genex:isExpressedIn ?anat . ?seq lscr:xrefUniprot ?protein . ?seq orth:organism ?organism . ?organism obo:RO_0002162 taxon:9606 . } } 1 whole query 2 asks all endpoints human transportersexpressed in the liver 3 sub-queries & results ⋈ joins results 4 joined answer

3 Run with Comunica using ASK-, COUNT- and VoID-based source selection; see S4.

03 · Two ways to federate

Source selection approaches:

“Which human transport proteins are expressed in the liver?” You Manual you name each endpoint { …human transporters… } SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE <Bgee> { …liver… } UniProt SPARQL endpointSPARQL endpoint (RDF data) Bgee SPARQL endpointSPARQL endpoint (RDF data) UniProt Bgee Algorithmic the engine selects sources SELECT … WHERE { …human transporters… …liver… } engine ? ? UniProt SPARQL endpointSPARQL endpoint (RDF data) Bgee SPARQL endpointSPARQL endpoint (RDF data) UniProt Bgee

Key messageBoth approaches can theoretically provide the same answers to the same queries.

04 · The queries

Real research questions, written by domain experts.

Domain experts using SIB’s public endpoints Question + query pairs published as endpoint examples 67 federated queries in our study What they ask (paraphrased) “Which human cancer genes have counterparts in the rat brain?” UniProt · OMA · Bgee “Which protein patents have already expired?” UniProt · European Patent Office “Which human transport proteins are expressed in the liver?” UniProt · Bgee · our running example Why “real world”? > ½ confirmed use or open question ≈ ¼ results in peer-reviewed papers 2–3 sources, ≈ 15 triple patterns

Key messageQueries answer real biological questions, and most were written by a domain expert.

Per-query complexity: S5 · General Query Statistics ↗ in the results explorer.

05 · Study set-up

The same real-world queries, repeated over one year.

67 real queries target SPARQL endpoint (RDF data) 20+ public endpoints × 2 ways to federate manual vs. algorithmic × 25 runs over 14 months Spring 2025 Fall 2025 Winter 2026 Spring 2026 1 run = every query executed once · 25 runs (4 manual, 21 algorithmic) · Mar 2025 – Jun 2026, shown in 4 periods

Key messageA longitudinal study on live endpoints, i.e. federation as users actually experience it.

QR code linking to the results explorer: https://ecrum19.github.io/fed-survey-results/ Explore every query and run in the interactive results explorerecrum19.github.io/fed-survey-results ↗

06 · Finding 1

Algorithmic source selection rarely produced results.

Manual 4 runs 47% non-empty default-service-test-1: 30 non-empty, 8 empty, 23 errors of 61 default-service-test-1: 30 non-empty, 8 empty, 23 errors of 61 default-service-test-1: 30 non-empty, 8 empty, 23 errors of 61 service-control-31-03-25-comunica: 40 non-empty, 0 empty, 26 errors of 66 service-control-31-03-25-comunica: 40 non-empty, 0 empty, 26 errors of 66 service-control-31-03-25-endpoint: 43 non-empty, 0 empty, 23 errors of 66 service-control-31-03-25-endpoint: 43 non-empty, 0 empty, 23 errors of 66 service-control-20-4-26: 10 non-empty, 3 empty, 54 errors of 67 service-control-20-4-26: 10 non-empty, 3 empty, 54 errors of 67 service-control-20-4-26: 10 non-empty, 3 empty, 54 errors of 67 non-empty result set empty result set explicit error one column = one run of every query Algorithmic 21 runs 2% non-empty EX1-17-9-25: 4 non-empty, 2 empty, 54 errors of 60 EX1-17-9-25: 4 non-empty, 2 empty, 54 errors of 60 EX1-17-9-25: 4 non-empty, 2 empty, 54 errors of 60 EX2-13-10-25: 5 non-empty, 4 empty, 51 errors of 60 EX2-13-10-25: 5 non-empty, 4 empty, 51 errors of 60 EX2-13-10-25: 5 non-empty, 4 empty, 51 errors of 60 EX3-16-10-25: 6 non-empty, 4 empty, 50 errors of 60 EX3-16-10-25: 6 non-empty, 4 empty, 50 errors of 60 EX3-16-10-25: 6 non-empty, 4 empty, 50 errors of 60 EX4-24-10-25: 5 non-empty, 3 empty, 52 errors of 60 EX4-24-10-25: 5 non-empty, 3 empty, 52 errors of 60 EX4-24-10-25: 5 non-empty, 3 empty, 52 errors of 60 EX1-NRL-14-11-25: 6 non-empty, 3 empty, 51 errors of 60 EX1-NRL-14-11-25: 6 non-empty, 3 empty, 51 errors of 60 EX1-NRL-14-11-25: 6 non-empty, 3 empty, 51 errors of 60 EX1-17-11-25: 2 non-empty, 2 empty, 56 errors of 60 EX1-17-11-25: 2 non-empty, 2 empty, 56 errors of 60 EX1-17-11-25: 2 non-empty, 2 empty, 56 errors of 60 EX2-19-11-25: 0 non-empty, 0 empty, 60 errors of 60 EX3-24-11-25: 0 non-empty, 0 empty, 60 errors of 60 EX4-26-11-25: 1 non-empty, 0 empty, 59 errors of 60 EX4-26-11-25: 1 non-empty, 0 empty, 59 errors of 60 EX2-NRL-01-12-25: 0 non-empty, 0 empty, 60 errors of 60 EX1-31-1-26: 0 non-empty, 0 empty, 60 errors of 60 EX1-17-4-26: 0 non-empty, 0 empty, 60 errors of 60 EX2-17-4-26: 0 non-empty, 0 empty, 60 errors of 60 EX3-17-4-26: 0 non-empty, 0 empty, 60 errors of 60 EX4-17-4-26: 0 non-empty, 0 empty, 60 errors of 60 EX1-NRL-17-4-26: 0 non-empty, 0 empty, 60 errors of 60 EX1-12-06-26: 0 non-empty, 0 empty, 60 errors of 60 EX2-12-06-26: 0 non-empty, 0 empty, 60 errors of 60 EX3-12-06-26: 0 non-empty, 0 empty, 60 errors of 60 EX4-12-06-26: 0 non-empty, 0 empty, 60 errors of 60 EX1-NRL-12-06-26: 0 non-empty, 0 empty, 60 errors of 60 ≈ 21× lower success rate using algorithmic federation 96% of algorithmic executions ended in an explicit error

Key messageAlgorithmic federation was far less reliable than manual federation.

All 25 runs, Mar 2025 – Jun 2026: Manual 47.3% non-empty / 48.5% explicit errors (260 executions) · Algorithmic 2.3% / 96.3% (1,260 executions). In April 2026, when both ran: 10 vs. 0 of 67 queries returned a non-empty result set (these runs ↗).

07 · Why algorithmic federation failed

Algorithmic probing exceeds endpoint usage limits.

Requests rejected early 54 queries · all 21 algorithmic runs requests 1 … 6 HTTP 403: ForbiddenHTTP 403 Forbidden (MDN) SPARQL endpoint (RDF data) 3–6requests before the endpoint starts replying HTTP 403: ForbiddenHTTP 403 Forbidden (MDN) Request explosion query 6 · one run SwissLipids SPARQL endpoint (beta) SPARQL endpoint (RDF data) Rhea SPARQL endpoint SPARQL endpoint (RDF data) UniProt SPARQL endpoint SPARQL endpoint (RDF data) 924,299requests for a single query, without a result Classification of the 1,027 explicit errors 577 Rejected requests (HTTP 4xx) 222 Server errors (HTTP 5xx) 228 Other (network, parsing, time-outs)

Key messageAlgorithmic federation can exceed what live public endpoints are able to serve.

3–6 requests: 533 of 814 algorithmic executions rejected with HTTP 4xx, mostly UniProt HTTP 403: Forbidden, Sep 2025 – Jun 2026; error groups: S6. 924,299 HTTP requests were issued by one algorithmic run of query 6 before it failed (S7; results explorer ↗).

08 · Finding 2

Over 14 months, the share of answered queries declined.

all 67 queries 0 20 40 60 queries answered Spring 2025 Fall 2025 Winter 2026 Spring 2026 Manual Algorithmic 38 → 10 Spring 2025 → Spring 2026 5 → 0 Fall 2025 → Spring 2026

Key messageSuccess declined over time, for both manual and algorithmic federation.

Small dots = individual runs (25); large dots = period average. Manual runs took place in Spring 2025 and Spring 2026; algorithmic runs from Fall 2025 on. Per-run figure: S8.

09 · Changes over time

Public endpoints evolve as demand grows.

OBSERVED LIMITATIONS OF PUBLIC FEDERATION · MAR 2025 – JUN 2026 Endpoints move DBGI/EMI moved to the METRIN-KG SPARQL endpointMETRIN-KG endpoint URL Which 14 queries (S10)14 of 67 queries affected Services retire BioSODA’s temporary federation server, deprecated Sep, removed Nov 2025 Which 14 queries (S10)14 of 67 queries affected Limits tighten UniProt traffic rose abruptly (likely AI crawlers4), resulted in stricter limits requests rejected: HTTP 403HTTP 403 Forbidden (MDN) 2 in 3 queries returned a different number of results from run to run. Same query, same configuration: results were not reproducible. Open the query outcome heatmap in the results explorer Result heatmap ↗

Key messageEndpoint changes broke working queries; federation clients could not adapt.

68.7% of queries showed result-count variation across repeated runs, including switches between returning results and returning none (paper, Sec. 5.1). Details on each change: S9; the 14 affected queries: S10. 4 Suspected, not proven: R. Taelman, “Did AI Crawlers Kill SPARQL Federation?” (blog, 13 Apr 2026).

10 · Two sides of one problem

Users want answers; maintainers need sustainability.

Query users Complex, multi-source questions Reliable answers Reproducible results SPARQL endpoint (RDF data) Endpoint maintainers Limited hardware and funding Fair access for all users Sustained service availability more automated traffic tighter limits more failed queries retries & workarounds a reinforcing cycle UniProt SPARQL endpoint SPARQL endpoint (RDF data) REAL EXAMPLE UniProt updated its usage limits as traffic grew; federation clients then received HTTP 403HTTP 403 Forbidden (MDN) (S9).

Key messageBoth needs are legitimate; what is missing is coordination between them.

11 · Recommendations

Reliable federation necessitates coordination.

Researchers → Test on live endpoints (repeatedly, over months) Engine developers → Plan within the limits (request budgets, back-off, caching) SPARQL endpoint (RDF data) Endpoint maintainers → Publish the limits (in machine-readable form5) Shared, machine-readable agreements SPARQL endpoint (RDF data) what each endpoint allows rate limits · time-outs · result caps what each engine will send request budget · back-off · caching

Key messageDependable federation needs maintainers, engine creators, and users working together.

5 Existing starting points: VoID · SPARQL 1.1 Service Description

12 · What’s next

From silent failures to limit-aware federation.

Today: silent failures, errors, empty or unstable results Goal: federation that knows and respects its limits NEAR TERM SPARQL endpoint (RDF data) ① Publish limits and status Endpoints state their limits, e.g. VoRD →Vocabulary of Restrictive Datasets (S11) ② Make engines limit-aware Engines plan requests within published limits LONGER TERM ③ Evaluate in the wild, over time Test on live endpoints, repeatedly over time ④ Sustainable infrastructure Share the load: gateways, caches, TPFTriple Pattern Fragments, etc.

Key messageWhen endpoint limits are visible, engines can plan around them instead of failing.

For more details see Discussion and Recommendations sections 6.3 & 8.

13 · Beyond federation

A tragedy of the commons for public data services.

Ars Technica, 25 March 2025: Open source devs say AI crawlers dominate traffic, forcing blocks on entire countries TechCrunch, 2 April 2025: AI crawlers cause Wikimedia Commons bandwidth demands to surge 50% GitHub community discussion 159123, 13 May 2025: Error 429: Too Many Requests when accessing repository files without login UniProt SPARQL endpoint: over 3 million visitors a month, up from tens or hundreds of thousands, on the same hardware Zenodo, 28 January 2026: Planned improvements and support expectations OpenStreetMap community forum, 6 February 2026: More technical updates to the tile.openstreetmap.org service; rate limits to better manage scrapers Wikimedia incident report, Wikidata Query Service, 7 to 11 May 2026: aggressive scrapers decreased service availability Zenodo, 15 September 2026: Zenodo performance: an update on the current situation Wikimedia Foundation, 5 October 2026: OpenAI rogue agent activities found on Wikimedia projects

Key messageHow will public services be accessed (or guarded?) in the increasingly agent-populated web?

Sources: Ars Technica · TechCrunch · GitHub · Zenodo, Jan and Sep 2026 · OpenStreetMap · Wikidata incident report · Wikimedia. Tragedy of the commons: Hardin, Science 1968 · UniProt traffic from its server administrator (paper, Sec. 6.2).

14 · Conclusions

Federation over public endpoints is not yet reliable.

Resources

QR code linking to these slides: https://ecrum19.github.io/iswc-2026-slides/ Slides Link

Key messageTesting federation in the wild exposes what benchmarks miss: endpoint limits and change.

What can be done?Endpoint limits can be represented with VoRD, engines can start to consider them.
Should concerns linger, please reach out! We would be happy to try to help.

Supported by FWO · SolidLab Vlaanderen · Swiss National Science Foundation · EU Horizon Europe (MICROBES-4-CLIMATE) · Swiss Government SERI · NIH.

Acknowledgements

This work was made possible by many people.

Research stay

The FWO funded a two-month research stay (grant V416635N) at the SIB in Lausanne, where this work was undertaken.

These slides were prepared with the help of Claude Opus 5.5 (Anthropic) in October 2026.

Supplementary slides

Details and evidence

  1. Terms and definitions
  2. S1Terminology: talk and paper
  3. S2What counts as an answer
  4. S3SERVICE vs. no-service query
  5. Details behind the talk
  6. S4Algorithmic approachesslide 03B
  7. S5How complex the queries areslide 04
  8. S6Error breakdownslide 07
  9. S7Request explosionsslide 07
  10. S8Answers per runslide 08
  11. S9Endpoint changesslide 09, 10
  12. S10Queries affected by the EMI moveslide 09
  13. S11Publishing endpoint limits (VoRD)slide 12
  14. Further material
  15. S12Every query × every run
  16. S13The running example
  17. S14Limitations of the study
  18. S15References

S1 · Terminology

Terms in this talk and in the paper.

IN THIS TALK IN THE PAPER WHAT IT MEANS Manual federation SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE experiments server-side manual federation Query keeps its SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE clauses; one target endpoint federates and joins. 4 runs. Algorithmic federation no-service experiments client-side automated federation SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE clauses removed; Comunica selects sources, plans and joins. 21 runs. Federation engine Comunica v4.3.0 one client for both settings Federates only in no-service runs; in SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE runs it just submits the query. Algorithmic approaches NOMETA-ASK · NOMETA-COUNT VOID-TRIPLE · VOID-BLOCK · -NRL Comunica configurations for source selection and join planning (S4). Run experiment 25 experiments, Mar 2025 – Jun 2026 Every query of the workload executed once, with one approach and configuration. Answered / success execution success rate Sec. 4.4 Share of executions that return a non-empty result set.

Definitions from the paper, Sec. 4.3 (federation approaches) and 4.4 (experimental set-up).

S2 · Measurement

What counts as an answer?

Non-empty result

Parseable SPARQL Results JSON with result count > 0.

Empty result

Parseable output, but zero bindings returned.

Explicit error

No usable output or an exception/error path.

Result-set size agreement is used as a proxy for consistency; the study does not claim semantic binding equality. Direct endpoint execution and the Comunica control were close (65.2% vs. 60.6% non-empty).

S3 · From SERVICE to no-service

The running example, as SPARQL.

SERVICE form (manual)original/109_uniprot_transporter_in_liver.rq
# Datasources: https://sparql.uniprot.org/sparql/
PREFIX genex: <http://purl.org/genex#>
PREFIX lscr: <http://purl.org/lscr#>
PREFIX obo: <http://purl.obolibrary.org/obo/>
PREFIX orth: <http://purl.org/net/orth#>
PREFIX rh: <http://rdf.rhea-db.org/>
PREFIX taxon: <http://purl.uniprot.org/taxonomy/>
PREFIX uberon: <http://purl.obolibrary.org/obo/uo#>
PREFIX up: <http://purl.uniprot.org/core/>
SELECT
  ?rhea
  ?protein
  ?anat
WHERE
{
  GRAPH <https://sparql.rhea-db.org/rhea> {
    ?rhea rh:isTransport true .
  }
  ?protein up:annotation ?ann .
  ?protein up:organism taxon:9606 .
  ?ann up:catalyticActivity ?ca .
  ?ca up:catalyzedReaction ?rhea .
  BIND(uberon:0002107 AS ?anat)
  SERVICE <https://www.bgee.org/sparql> {
    ?seq genex:isExpressedIn ?anat .
    ?seq lscr:xrefUniprot ?protein .
    ?seq orth:organism ?organism .
    ?organism obo:RO_0002162 taxon:9606 .
  }}
no-service form (algorithmic)no-service/109_uniprot_transporter_in_liver_ns.rq
# Datasources: https://sparql.uniprot.org/sparql/ https://www.bgee.org/sparql
PREFIX genex: <http://purl.org/genex#>
PREFIX lscr: <http://purl.org/lscr#>
PREFIX obo: <http://purl.obolibrary.org/obo/>
PREFIX orth: <http://purl.org/net/orth#>
PREFIX rh: <http://rdf.rhea-db.org/>
PREFIX taxon: <http://purl.uniprot.org/taxonomy/>
PREFIX uberon: <http://purl.obolibrary.org/obo/uo#>
PREFIX up: <http://purl.uniprot.org/core/>
SELECT
  ?rhea
  ?protein
  ?anat
WHERE
{
  GRAPH <https://sparql.rhea-db.org/rhea> {
    ?rhea rh:isTransport true .
  }
  ?protein up:annotation ?ann .
  ?protein up:organism taxon:9606 .
  ?ann up:catalyticActivity ?ca .
  ?ca up:catalyzedReaction ?rhea .
  BIND(uberon:0002107 AS ?anat)
  {
    ?seq genex:isExpressedIn ?anat .
    ?seq lscr:xrefUniprot ?protein .
    ?seq orth:organism ?organism .
    ?organism obo:RO_0002162 taxon:9606 .
  }}

One change: the SERVICE <https://www.bgee.org/sparql> wrapper becomes a plain group and Bgee joins the data sources, so the engine must place every pattern itself. Files verbatim from fed-survey-results/queries ↗.

S4 · Algorithmic approaches

All algorithmic approaches showed low success rates.

CONFIGURATION WHAT IT USES TO SELECT SOURCES AND PLAN RUNS NON-EMPTY RESULTS NOMETA-ASK live ASK probes ✓ ASK COUNT VoID Large est. ✓ Rate limit 8 runs incl. 3 -NRL 12 / 480 · 2.50% NOMETA-COUNT live COUNT probes ASK ✓ COUNT VoID Large est. ✓ Rate limit 5 runs incl. 1 -NRL 5 / 300 · 1.67% VOID-TRIPLE VoID, per triple pattern ✓ ASK COUNT ✓ VoID Large est. ✓ Rate limit 4 runs 6 / 240 · 2.50% VOID-BLOCK VoID, larger query blocks ✓ ASK COUNT ✓ VoID ✓ Large est. ✓ Rate limit 4 runs 6 / 240 · 2.50% Manual (SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE) for comparison the target endpoint follows the SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE clauses 4 runs 123 / 260 · 47.3% 1.67–2.50% for every configuration. VoID metadata helped only slightly; turning off client rate limiting (-NRL) made no clear difference.

Configurations and results from the paper, Sec. 4.3 (Table 1) and 5.4; all ran in Comunica 4.3.0. Manual figure from the 25-run results explorer data.

S5 · The queries

Moderate syntax, non-trivial federation.

Bar chart showing the 67 queries ordered by number of triple patterns and grouped by two or three federation members.
Live ↗ 2 federation members 3 federation members O OPTIONAL · U UNION Hover a bar for details · Open full screen ↗

Average: 14.9 triple patterns (2–34) · 2.24 federation members · few OPTIONAL/UNION.

S6 · Errors

The errors had an operational signature.

ERROR GROUP EXECUTIONS ■ algorithmic ■ manual WHAT IT LOOKS LIKE MEDIAN REQ. Client-side HTTP 4xx 850814 / 36 Endpoint refused the request: mostly 403 Forbidden, some 400/404 5 requests Server-side HTTP 5xx 245216 / 29 Endpoint failed while answering (HTTP 500 and other 5xx) 4 requests Transport-level network 9191 / 0 Connection dropped mid-transfer: “fetch failed”, request failed 2,004 requests Other malformed 9053 / 37 HTML error page sent as HTTP 200, parse errors, client out of memory 78 requests Timeout-related long runs 6339 / 24 Long runs aborted or terminated before finishing 699 requests 82% were 4xx/5xx from endpoints, usually within ~5 requests: the queries were not faulty. Open the error-type heatmap in the results explorerError heatmap ↗

1,339 errors in 1,520 executions (results explorer); the paper (Sec. 5.2) lists 242 / 82 / 102 for 5xx / transport / other, before 12 records were reclassified.

S7 · Request explosions

Query 6: 1,308 requests to succeed, 924,299 to fail.

HTTP requests per execution · one linear scale Query 6 · failed NOMETA-ASK · 9–10 Oct 2025 924,299 24.7 h · 0 results Query 12 · largest success NOMETA-ASK-NRL · Nov 2025 368,952 14.2 h · 52,700 results Query 6 · succeeded 3 other runs · Oct–Nov 2025 1,308–1,321 2.5–3.5 min · 1,216 results What the 924,299 requests of the failed run were One lookup per binding 303,503 bind-join steps, each a small (~170-byte) request carrying one bound value. Sent to all three endpoints 303,503 each to SwissLipids and Rhea; 317,293 to UniProt, incl. 13,790 retries after “429 Too Many Requests”. Steady for a full day About 37,000 requests per hour for 24.7 h, until the connection failed (“fetch failed”).

Successful query 6 runs sent 13 ASK probes per endpoint, then queried only Rhea and UniProt; the failed run did not log request bodies (results explorer ↗). Query 6 was not alone: in the same NOMETA-ASK run (Sep–Oct 2025), queries 13 and 16 also failed, after 742,417 and 553,202 requests.

S8 · Answers per run

Non-empty result sets for each of the 25 runs.

Bar chart of queries with non-empty result sets per experiment run, chronologically: SERVICE runs answer 30 to 43 queries in Spring 2025; no-SERVICE runs answer at most 6 in Fall 2025 and Winter 2026 and 0 in Spring 2026; one SERVICE run in Spring 2026 answers 10.
Live ↗ SERVICE (manual) no-service (algorithmic) Hover a bar for details · Open in explorer ↗

Queries with result set > 0, per experiment run (dashboard order); chronological version in the paper (Fig. 2).

S9 · Endpoint changes

A live endpoint is part of the experimental treatment.

WHAT CHANGED WHY QUERIES BROKE WHAT WOULD HELP old URL SPARQL endpoint (RDF data) DBGI/EMI moved SPARQL endpoint (RDF data) METRIN-KG SPARQL endpointMETRIN-KG Queries still named the old URL; clients got no machine-readable notice, so the requests failed. Announce moves redirects & migration signals SPARQL endpoint (RDF data) BioSODA Mar 2025 in use Sep 2025 deprecated Nov 2025 removed 14 of 67 queries federated through this temporary server; once it was removed, they could only fail. Publish service status status & deprecation notices 1× ~5× 2024 2026 UniProt traffic peaks >3M visitors/month backend → QLever SPARQL endpoint (RDF data) Stricter limits on response time, concurrency, request rate and volume: request-heavy plans got HTTP 403HTTP 403 Forbidden (MDN). Publish and respect limits VoRD (S11); budgets & back-off Query 92 in the results explorerquery 92 ↗ Fall 2025 194 results later empty 2026 error 2 in 3 queries varied in result count. Data releases (UniProt: 3, +28B triples), endpoint changes and failures. Keep query records query, sources, results (QVMC) e.g. Solid Cockpit with Solid Pods

From the paper: changes Sec. 5.1, 5.5 and 6.2; recommendations Sec. 6.3 and 8. Query records: QVMC specification, implemented in Solid Cockpit.

S10 · Affected queries

14 queries depended on one endpoint that moved.

EMI knowledge graph (DBGI) on the BioSODA server biosoda.unil.ch/emi/sparql moved SPARQL endpoint (RDF data) METRIN-KG SPARQL endpointMETRIN-KG kg.earthmetabolome.org/metrin Mar 2025 in use Sep 2025 deprecated Nov 2025 removed THE 14 QUERIES Spring 25 manual Fall 25 algorithmic Winter 26 algorithmic Spring 26 algorithmic Spring 26 manual with Wikidata (4) 001 006 007 009 with IDSM (1) 002 with Wikidata on QLever (9) emi#examples011a emi#examples011b emi#examples012 emi#examples013 emi#examples015 emi#examples018 emi#examples019a emi#examples019b emi#examples021 non-empty emptyexplicit error 9 of 14 answered in Spring 2025 · 0 of 14 in any later run NEXT: RE-ASSESS THESE QUERIES 1 Retarget the queries swap biosoda.unil.ch/emi/sparql for METRIN-KG SPARQL endpointMETRIN-KG in both query forms 2 Re-check positive controls run each query in the endpoint’s web interface, as in March 2025 3 Re-run both approaches SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE and the algorithmic configurations, as in the study 4 Compare with the baseline 9 of 14 answered in Spring 2025; are the answers the same?

Queries and targets: SIB query corpus; outcomes: 25-run results explorer; changes: paper Sec. 5.5. The re-assessment is planned future work, not part of the paper. METRIN-KG endpoint as documented in Tandon et al., GigaScience 2026.

S11 · Publishing endpoint limits

VoRD: machine-readable descriptions of endpoint limits.

SPARQL endpoint (RDF data) Endpoint maintainer describes its limits once, next to its SPARQL endpoint query.wikidata.org/sparql VoRD description ↗ Anonymous clients ≤ 10 requests / min → HTTP 429 + Retry-After With a User-Agent ≤ 200 requests / min Established users ≤ 2,000 requests / min Parallel requests ≤ 3 at once per IP (guidance) → HTTP 503 ex:anonymous a vord:RateRestriction ; vord:maxValue 10 ; vord:windowDuration "PT1M" . Federation engines plan requests within the limits and adapt before reaching them Users know the limits before querying, and why a request was rejected Without published limits: the cycle from slide 10 traffic → tighter limits → failed queries → retries → more traffic With published limits, the cycle breaks plan within limits → fewer rejections, fewer retries

Key messageIf endpoints publish their limits, engines and users can stay within them.

VoRD (v0.2) extends SPARQL 1.1 Service Description and is validated with SHACL and ShEx. Card values: VoRD’s Wikidata example, derived from Wikimedia’s public rate-limit documentation (May 2026).

S12 · All outcomes

Failures were widespread across the query set.

Heatmap of query outcomes across 25 chronological experiment runs: non-empty results, empty results, explicit errors and missing data.
Live ↗ non-empty result set empty result set explicit error missing ≠ result count varies across runs Hover a cell for details · Open in explorer ↗

Rows = experiment runs, columns = queries (dashboard order); chronological version in the paper (Fig. 3).

S13 · The running example

Query 109: transporter proteins in the liver.

# sent to sparql.uniprot.org (PREFIXes omitted)
SELECT ?rhea ?protein ?anat
WHERE {
  GRAPH <https://sparql.rhea-db.org/rhea> {
    ?rhea rh:isTransport true .
  }
  ?protein up:annotation ?ann .
  ?protein up:organism taxon:9606 .
  ?ann up:catalyticActivity ?ca .
  ?ca up:catalyzedReaction ?rhea .
  BIND(uberon:0002107 AS ?anat)
  SERVICE <https://www.bgee.org/sparql> {
    ?seq genex:isExpressedIn ?anat .
    ?seq lscr:xrefUniprot ?protein .
    ?seq orth:organism ?organism .
    ?organism obo:RO_0002162 taxon:9606 .
  }
}
Spring 2025manual · 3 runs
Fall 2025algorithmic · 4 runs
Winter 2026algorithmic · 7 runs
Spring 2026algorithmic · 10 runs
Spring 2026manual · 1 run

non-empty empty explicit error

  • Spring 2025: one manual run hit a malformed response (parse error).
  • Fall 2025: empty results (~21 requests); one run aborted after 609 requests.
  • From Nov 2025: HTTP 403 Forbidden within 2–12 requests; UniProt (and Bgee, Jun 2026) rejected the engine’s ASK probes.

Query: UniProt SPARQL example 109_uniprot_transporter_in_liver, federating UniProt and Bgee. Per-run logs: fed-survey-results ↗. The paper’s Figure 1 shows a different query, query 7 (SwissLipids), which never returned a non-empty result.

S14 · Limitations

What this study does, and does not, claim.

01 Domain-specific Workload from users of SIB-hosted biological endpoints (7 target, 14 federated); other domains may differ. 02 Meaningful, not exhaustive 67 expert-written queries: realistic evidence of practice, not a universal benchmark. 03 Causality is incomplete Logs show when an outcome changed, not always which change caused it. BIOLOGICAL LINKED DATA SPARQL endpoint (RDF data) SPARQL endpoint (RDF data) SPARQL endpoint (RDF data) OMASPARQL endpoint (RDF data) SPARQL endpoint (RDF data) ? other domains ~¼ led to published results together >½ with a real-world use avg. 14.9 triple patterns · 2.24 sources data release backend change new limits migration ? results failures What we do show: on live public biological endpoints, federation was unreliable and degraded over time, for both approaches.

From the paper: workload Sec. 4.2, limitations Sec. 7.

S15 · References

Sources cited in this talk.

  1. Crum, E., Tam, B.-E., Hanski, J., Sima, A.-C., Mendes de Farias, T., Bolleman, J., Taelman, R. Does SPARQL federation work in the real world? A case study over large biological SPARQL endpoints. ISWC 2026. ↗
  2. Bolleman, J., et al. A large collection of bioinformatics question–query pairs over federated knowledge graphs: methodology and applications. GigaScience 14, 2025. ↗
  3. The UniProt Consortium. UniProt: the Universal Protein Knowledgebase in 2025. Nucleic Acids Research 53(D1), 2025. ↗
  4. Bastian, F. B., et al. Bgee in 2024: focus on curated single-cell RNA-seq datasets, and query tools. Nucleic Acids Research 53(D1), 2025. ↗
  5. W3C. SPARQL 1.1 Federated Query. W3C Recommendation, 2013. ↗
  6. Schmidt, M., et al. FedBench: A benchmark suite for federated semantic data query processing. ISWC 2011. ↗
  7. Saleem, M., Hasnain, A., Ngonga Ngomo, A.-C. LargeRDFBench: A billion triples benchmark for SPARQL endpoint federation. Journal of Web Semantics 48, 2018. ↗
  8. Schwarte, A., Haase, P., Hose, K., Schenkel, R., Schmidt, M. FedX: Optimization techniques for federated query processing on Linked Data. ISWC 2011. ↗
  9. Görlitz, O., Staab, S. SPLENDID: SPARQL endpoint federation exploiting VOID descriptions. COLD 2011. ↗
  10. Dang, M.-H., et al. FedShop: A benchmark for testing the scalability of SPARQL federation engines. ISWC 2023. ↗
  11. Saleem, M., Khan, Y., Hasnain, A., Ermilov, I., Ngonga Ngomo, A.-C. A fine-grained evaluation of SPARQL endpoint federation systems. Semantic Web 7(5), 2016. ↗
  12. Hernández, D., Hogan, A., Riveros, C., Rojas, C., Zerega, E. Querying Wikidata: Comparing SPARQL, relational and graph databases. ISWC 2016. ↗
  13. Taelman, R., Van Herwegen, J., Vander Sande, M., Verborgh, R. Comunica: a modular SPARQL query engine for the Web. ISWC 2018. ↗
  14. Alexander, K., Cyganiak, R., Hausenblas, M., Zhao, J. Describing Linked Datasets with the VoID Vocabulary. W3C Interest Group Note, 2011. ↗
  15. Williams, G. T. SPARQL 1.1 Service Description. W3C Recommendation, 2013. ↗
  16. Crum, E. VoRD: Vocabulary of Restrictive Datasets, v0.2. ↗