Viewer discretion advisedThis 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.
Key messageBoth approaches can theoretically provide the same answers to the same queries.
04 · The queries
Real research questions, written by domain experts.
Domain expertsusing SIB’s public endpointsQuestion + query pairspublished as endpoint examples67federatedqueries in our studyWhat 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 exampleWhy “real world”?> ½confirmed use or open question≈ ¼results in peer-reviewed papers2–3sources, ≈ 15 triple patterns
Key messageQueries answer real biological questions, and most were written by a domain expert.
The same real-world queries, repeated over one year.
67real queriestarget20+public endpoints×2ways to federatemanual vs. algorithmic×25runs over 14 monthsSpring 2025Fall 2025Winter 2026Spring 20261 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.
Algorithmic source selection rarely produced results.
Manual4 runs47% non-emptydefault-service-test-1: 30 non-empty, 8 empty, 23 errors of 61default-service-test-1: 30 non-empty, 8 empty, 23 errors of 61default-service-test-1: 30 non-empty, 8 empty, 23 errors of 61service-control-31-03-25-comunica: 40 non-empty, 0 empty, 26 errors of 66service-control-31-03-25-comunica: 40 non-empty, 0 empty, 26 errors of 66service-control-31-03-25-endpoint: 43 non-empty, 0 empty, 23 errors of 66service-control-31-03-25-endpoint: 43 non-empty, 0 empty, 23 errors of 66service-control-20-4-26: 10 non-empty, 3 empty, 54 errors of 67service-control-20-4-26: 10 non-empty, 3 empty, 54 errors of 67service-control-20-4-26: 10 non-empty, 3 empty, 54 errors of 67non-empty result setempty result setexplicit errorone column = one run of every queryAlgorithmic21 runs2% non-emptyEX1-17-9-25: 4 non-empty, 2 empty, 54 errors of 60EX1-17-9-25: 4 non-empty, 2 empty, 54 errors of 60EX1-17-9-25: 4 non-empty, 2 empty, 54 errors of 60EX2-13-10-25: 5 non-empty, 4 empty, 51 errors of 60EX2-13-10-25: 5 non-empty, 4 empty, 51 errors of 60EX2-13-10-25: 5 non-empty, 4 empty, 51 errors of 60EX3-16-10-25: 6 non-empty, 4 empty, 50 errors of 60EX3-16-10-25: 6 non-empty, 4 empty, 50 errors of 60EX3-16-10-25: 6 non-empty, 4 empty, 50 errors of 60EX4-24-10-25: 5 non-empty, 3 empty, 52 errors of 60EX4-24-10-25: 5 non-empty, 3 empty, 52 errors of 60EX4-24-10-25: 5 non-empty, 3 empty, 52 errors of 60EX1-NRL-14-11-25: 6 non-empty, 3 empty, 51 errors of 60EX1-NRL-14-11-25: 6 non-empty, 3 empty, 51 errors of 60EX1-NRL-14-11-25: 6 non-empty, 3 empty, 51 errors of 60EX1-17-11-25: 2 non-empty, 2 empty, 56 errors of 60EX1-17-11-25: 2 non-empty, 2 empty, 56 errors of 60EX1-17-11-25: 2 non-empty, 2 empty, 56 errors of 60EX2-19-11-25: 0 non-empty, 0 empty, 60 errors of 60EX3-24-11-25: 0 non-empty, 0 empty, 60 errors of 60EX4-26-11-25: 1 non-empty, 0 empty, 59 errors of 60EX4-26-11-25: 1 non-empty, 0 empty, 59 errors of 60EX2-NRL-01-12-25: 0 non-empty, 0 empty, 60 errors of 60EX1-31-1-26: 0 non-empty, 0 empty, 60 errors of 60EX1-17-4-26: 0 non-empty, 0 empty, 60 errors of 60EX2-17-4-26: 0 non-empty, 0 empty, 60 errors of 60EX3-17-4-26: 0 non-empty, 0 empty, 60 errors of 60EX4-17-4-26: 0 non-empty, 0 empty, 60 errors of 60EX1-NRL-17-4-26: 0 non-empty, 0 empty, 60 errors of 60EX1-12-06-26: 0 non-empty, 0 empty, 60 errors of 60EX2-12-06-26: 0 non-empty, 0 empty, 60 errors of 60EX3-12-06-26: 0 non-empty, 0 empty, 60 errors of 60EX4-12-06-26: 0 non-empty, 0 empty, 60 errors of 60EX1-NRL-12-06-26: 0 non-empty, 0 empty, 60 errors of 60≈ 21×lower success rate usingalgorithmic federation96%of algorithmic executionsended 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 ↗).
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 queries0204060queries answeredSpring 2025Fall 2025Winter 2026Spring 2026ManualAlgorithmic38 → 10Spring 2025 → Spring 20265 → 0Fall 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.
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 usersComplex, multi-source questionsReliable answersReproducible resultsEndpoint maintainersLimited hardware and fundingFair access for all usersSustained service availabilitymore automated traffictighter limitsmore failed queriesretries &workaroundsa reinforcingcycleUniProt SPARQL endpointREAL EXAMPLEUniProt 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)Endpoint maintainers→ Publish the limits(in machine-readable form5)Shared, machine-readable agreementswhat each endpoint allowsrate limits · time-outs · result capswhat each engine will sendrequest budget · back-off · caching
Key messageDependable federation needs maintainers, engine creators, and users working together.
Today: silent failures, errors, empty or unstable resultsGoal: federation that knows and respects its limitsNEAR TERM① Publish limits and statusEndpoints state their limits, e.g. VoRD →Vocabulary of Restrictive Datasets (S11)② Make engines limit-awareEngines plan requests within published limitsLONGER TERM③ Evaluate in the wild, over timeTest on live endpoints, repeatedly over time④ Sustainable infrastructureShare the load: gateways, caches, TPFTriple Pattern Fragments, etc.
Key messageWhen endpoint limits are visible, engines can plan around them instead of failing.
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.
IN THIS TALKIN THE PAPERWHAT IT MEANSManual federationSERVICE in the SPARQL 1.1 Federated Query specificationSERVICE experimentsserver-side manual federationQuery keeps its SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE clauses; one targetendpoint federates and joins. 4 runs.Algorithmic federationno-service experimentsclient-side automated federationSERVICE in the SPARQL 1.1 Federated Query specificationSERVICE clauses removed; Comunica selectssources, plans and joins. 21 runs.Federation engineComunica v4.3.0one client for both settingsFederates only in no-service runs; inSERVICE in the SPARQL 1.1 Federated Query specificationSERVICE runs it just submits the query.Algorithmic approachesNOMETA-ASK · NOMETA-COUNTVOID-TRIPLE · VOID-BLOCK · -NRLComunica configurations for source selectionand join planning (S4).Runexperiment25 experiments, Mar 2025 – Jun 2026Every query of the workload executed once,with one approach and configuration.Answered / successexecution success rateSec. 4.4Share of executions that return anon-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).
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.
CONFIGURATIONWHAT IT USES TO SELECT SOURCES AND PLANRUNSNON-EMPTY RESULTSNOMETA-ASKlive ASK probes✓ ASKCOUNTVoIDLarge est.✓ Rate limit8 runsincl. 3 -NRL12 / 480 · 2.50%NOMETA-COUNTlive COUNT probesASK✓ COUNTVoIDLarge est.✓ Rate limit5 runsincl. 1 -NRL5 / 300 · 1.67%VOID-TRIPLEVoID, per triple pattern✓ ASKCOUNT✓ VoIDLarge est.✓ Rate limit4 runs6 / 240 · 2.50%VOID-BLOCKVoID, larger query blocks✓ ASKCOUNT✓ VoID✓ Large est.✓ Rate limit4 runs6 / 240 · 2.50%Manual (SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE)for comparisonthe target endpoint follows the SERVICE in the SPARQL 1.1 Federated Query specificationSERVICE clauses4 runs123 / 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.
Live ↗2 federation members3 federation membersO OPTIONAL · U UNIONHover 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 GROUPEXECUTIONS■ algorithmic■ manualWHAT IT LOOKS LIKEMEDIAN REQ.Client-side HTTP4xx850814 / 36Endpoint refused the request:mostly 403 Forbidden, some 400/4045requestsServer-side HTTP5xx245216 / 29Endpoint failed while answering(HTTP 500 and other 5xx)4requestsTransport-levelnetwork9191 / 0Connection dropped mid-transfer:“fetch failed”, request failed2,004requestsOthermalformed9053 / 37HTML error page sent as HTTP 200,parse errors, client out of memory78requestsTimeout-relatedlong runs6339 / 24Long runs aborted orterminated before finishing699requests82% 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 scaleQuery 6 · failedNOMETA-ASK · 9–10 Oct 2025924,29924.7 h · 0 resultsQuery 12 · largest successNOMETA-ASK-NRL · Nov 2025368,95214.2 h · 52,700 resultsQuery 6 · succeeded3 other runs · Oct–Nov 20251,308–1,3212.5–3.5 min · 1,216 resultsWhat the 924,299 requests of the failed run wereOne lookup per binding303,503 bind-join steps, each a small(~170-byte) request carrying onebound value.Sent to all three endpoints303,503 each to SwissLipids and Rhea;317,293 to UniProt, incl. 13,790 retriesafter “429 Too Many Requests”.Steady for a full dayAbout 37,000 requests per hour for24.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.
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 CHANGEDWHY QUERIES BROKEWHAT WOULD HELPold URLDBGI/EMImovedMETRIN-KG SPARQL endpointMETRIN-KGQueries still named the old URL;clients got no machine-readablenotice, so the requests failed.Announce movesredirects & migration signalsBioSODAMar 2025in useSep 2025deprecatedNov 2025removed14 of 67 queries federated throughthis temporary server; once it wasremoved, they could only fail.Publish service statusstatus & deprecation notices1×~5×20242026UniProt trafficpeaks >3M visitors/monthbackend → QLeverStricter limits on response time,concurrency, request rate and volume:request-heavy plans got HTTP 403HTTP 403 Forbidden (MDN).Publish and respect limitsVoRD (S11); budgets & back-offQuery 92 in the results explorerquery 92 ↗Fall 2025194 resultslaterempty2026error2 in 3 queries varied in result count.Data releases (UniProt: 3, +28B triples),endpoint changes and failures.Keep query recordsquery, sources, results (QVMC)e.g. Solid Cockpit with Solid Pods
EMI knowledge graph (DBGI) on the BioSODA serverbiosoda.unil.ch/emi/sparqlmovedMETRIN-KG SPARQL endpointMETRIN-KGkg.earthmetabolome.org/metrinMar 2025in useSep 2025deprecatedNov 2025removedTHE 14 QUERIESSpring 25manualFall 25algorithmicWinter 26algorithmicSpring 26algorithmicSpring 26manualwith Wikidata (4)001006007009with IDSM (1)002with Wikidata on QLever (9)emi#examples011aemi#examples011bemi#examples012emi#examples013emi#examples015emi#examples018emi#examples019aemi#examples019bemi#examples021non-emptyemptyexplicit error9 of 14 answered in Spring 2025 · 0 of 14 in any later runNEXT: RE-ASSESS THESE QUERIES1Retarget the queriesswap biosoda.unil.ch/emi/sparql forMETRIN-KG SPARQL endpointMETRIN-KG in both query forms2Re-check positive controlsrun each query in the endpoint’sweb interface, as in March 20253Re-run both approachesSERVICE in the SPARQL 1.1 Federated Query specificationSERVICE and the algorithmicconfigurations, as in the study4Compare with the baseline9 of 14 answered in Spring 2025;are the answers the same?
VoRD: machine-readable descriptions of endpoint limits.
Endpointmaintainerdescribes its limits once,next to its SPARQL endpointquery.wikidata.org/sparqlVoRD description ↗Anonymous clients≤ 10 requests / min → HTTP 429 + Retry-AfterWith a User-Agent≤ 200 requests / minEstablished users≤ 2,000 requests / minParallel requests≤ 3 at once per IP (guidance) → HTTP 503ex:anonymous a vord:RateRestriction ; vord:maxValue 10 ; vord:windowDuration "PT1M" .Federationenginesplan requests within the limitsand adapt before reaching themUsersknow the limits before querying,and why a request was rejectedWithout published limits: the cycle from slide 10traffic → tighter limits → failed queries → retries → more trafficWith published limits, the cycle breaksplan within limits → fewer rejections, fewer retries
Key messageIf endpoints publish their limits, engines and users can stay within them.
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.
01Domain-specificWorkload from users of SIB-hostedbiological endpoints (7 target, 14federated); other domains may differ.02Meaningful, not exhaustive67 expert-written queries: realisticevidence of practice, not auniversal benchmark.03Causality is incompleteLogs show when an outcome changed,not always which change caused it.BIOLOGICAL LINKED DATAOMA?otherdomains~¼ led to published resultstogether >½ with a real-world useavg. 14.9 triple patterns · 2.24 sourcesdata releasebackend changenew limitsmigration?resultsfailuresWhat 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.
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. ↗
Bolleman, J., et al. A large collection of bioinformatics question–query pairs over federated knowledge graphs: methodology and applications. GigaScience 14, 2025. ↗
The UniProt Consortium. UniProt: the Universal Protein Knowledgebase in 2025. Nucleic Acids Research 53(D1), 2025. ↗
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. ↗
Schmidt, M., et al. FedBench: A benchmark suite for federated semantic data query processing. ISWC 2011. ↗
Saleem, M., Hasnain, A., Ngonga Ngomo, A.-C. LargeRDFBench: A billion triples benchmark for SPARQL endpoint federation. Journal of Web Semantics 48, 2018. ↗
Schwarte, A., Haase, P., Hose, K., Schenkel, R., Schmidt, M. FedX: Optimization techniques for federated query processing on Linked Data. ISWC 2011. ↗
Dang, M.-H., et al. FedShop: A benchmark for testing the scalability of SPARQL federation engines. ISWC 2023. ↗
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. ↗
Hernández, D., Hogan, A., Riveros, C., Rojas, C., Zerega, E. Querying Wikidata: Comparing SPARQL, relational and graph databases. ISWC 2016. ↗
Taelman, R., Van Herwegen, J., Vander Sande, M., Verborgh, R. Comunica: a modular SPARQL query engine for the Web. ISWC 2018. ↗
Alexander, K., Cyganiak, R., Hausenblas, M., Zhao, J. Describing Linked Datasets with the VoID Vocabulary. W3C Interest Group Note, 2011. ↗
Williams, G. T. SPARQL 1.1 Service Description. W3C Recommendation, 2013. ↗
Crum, E. VoRD: Vocabulary of Restrictive Datasets, v0.2. ↗