Page MenuHomePhabricator

[SPIKE] How to handle porting of label and mwapi services to the new backend
Closed, ResolvedPublic

Description

We need further investigate and document paths forward to migrate ad-hoc services.
In particular wikibase:label and wikibase:mwapi services as they impacts 50-60% of daily traffic on the main instance.

This scope of this task is not providing a prod implementation, but running some PoCs at most.

What we would like to learn is (create sub-tasks as required):

Details

Related Changes in GitLab:
TitleReferenceAuthorSource BranchDest Branch
initial commit: add query analysis.repos/wikidata-platform/notebooks!1gmodenamwapi-label-analysismain
Customize query in GitLab

Event Timeline

The label service is indeed pervasive. How much are the mwapi services used?

gmodena updated the task description. (Show Details)
trueg renamed this task from [SPIKE][NEEDS GROOMING] How would we handle label and mwapi services? to [SPIKE] How to handle porting of label and mwapi services to the new backend.Feb 17 2026, 2:30 PM

The label service is indeed pervasive. How much are the mwapi services used?

These are some estimated based on crude regexp filters, but in the first 6 weeks of 2026 about 22.8% of the queries used wikibase:mwapi, 68.4% used wikibase:label and 22.4% used both in the same query.

Re wikibase:mwapi: as part of this task we'll do a further breakdown of which APIs are actually called.

trueg changed the task status from Open to In Progress.Feb 18 2026, 8:56 AM
trueg claimed this task.
trueg triaged this task as High priority.

Even more important than just plain label service usage numbers: how many queries actually use the fallback function of the label service? Because only when using the fallback (with multiple languages) does the label service provide any advantage over a plain SPARQL solution as mentioned here: https://github.com/ad-freiburg/qlever/issues/1829

It turns out that fallback functionality has become more important with the introduction of the mul "language". If I want English labels I need to have mull as a fallback or I may miss many labels.

Fortunately it is relatively easy to have fallbacks using standard SPARQL 1.1. The SCHOLIA system is using standard SPARQL 1.1 in their replacement of the label service. They implement this using macros that expand into a BIND (to take care of unbound variables, if necessary) followed by a sequence of OPTIONALs (one for each desired language). For more information see https://github.com/ad-freiburg/scholia/tree/qlever, particularly https://github.com/ad-freiburg/scholia/blob/qlever/scholia/app/templates/sparql-helpers.sparql

This is fast in QLever and doesn't even seem to be too slow in Blazegraph. For a speed comparison (although it isn't quite finished) see https://github.com/ad-freiburg/scholia/issues/128

@Pfps I am not entirely sure what I am looking at here: https://github.com/ad-freiburg/scholia/blob/qlever/scholia/app/templates/sparql-helpers.sparql. These macros are not used to rewrite existing label service queries, are they?

@Pfps I am not entirely sure what I am looking at here: https://github.com/ad-freiburg/scholia/blob/qlever/scholia/app/templates/sparql-helpers.sparql. These macros are not used to rewrite existing label service queries, are they?

No. All the queries were rewritten and part of that rewriting was to turn the label service invocations into one or more macro calls. What you are looking at is the macro code that does the expansion. Using macros was easy in SCHOLIA because a macro system was already used to instantiate the query templates. To see a query template that uses these macros look at https://github.com/ad-freiburg/scholia/blob/qlever/scholia/app/templates/author_coauthors.sparql The macro call is nearly at the end of the template and expands to SPARQL 1.1 constructs that produce the label for the values of two variables. The language parameter to the macro is set to the accept languages for the browser (plus mul).

gmodena changed the status of subtask Restricted Task from Open to In Progress.Feb 20 2026, 1:25 PM
BTracy-WMF subscribed.

Acceptance criteria have been met and final output published to wikitech. Resolving this issue.

BTracy-WMF closed subtask Restricted Task as Resolved.Apr 8 2026, 11:41 AM