SWAT4HCLS revision

[egonw]

hi co-authors (@Daniel-Mietchen, @pfps, @KonradLinden, @larsgw, @WolfgangFahl),

this is the instructions from the SWAT4HCLS organizers:

I am pleased to inform you that your abstract 81 "Scholia 2026: Compliance with SPARQL 1.1,
has been accepted for Demonstration + Oral (short) presentation at SWAT4HCLS 2026.
 
We cordially ask you to process the reviewer comments in preparing your submission for the
conference proceedings. We trust that you will follow their recommendations to improve your
submission. Please upload a revised version (strictly following the CEUR template and
including an AI statement) until 8.2.

[..]

This year, we are pleased to announce a SWAT4Ls special issue in the Journal of Biomedical
Semantics, to which authors of accepted conference papers will be invited to submit extended
versions of their work. (more information will follow)

I am looking up the reviewer comments...

I strongly propose we keep any great additions for a full paper in the Journal of Biomedical Semantics? Are you okay with that?

cc @hannahbast

[egonw]

I do not know about confidentiality of the reviewer comments (and copyright), but it boils down to two items (and the co-authors received the rather favorable comments in full):

1. mention I will demo the /event/ and /event-series/ aspects
2. clarify how we get labels

[pfps]

I strongly propose we keep any great additions for a full paper in the Journal of Biomedical Semantics? Are you okay with that?

Agreed. This is a short, quick paper.

[pfps]

We should be able to put the reviewer comments somewhere all the authors can read them. So this repository might not be a good place. (Although I have seen reviewer comments distributed widely, I don't view this as a great idea.)

Putting the reviews in a file in the Overleaf project seems reasonable.

[pfps]

Here is a replacement for the "unbound" property. It is shorter than the current one. It might be necessary to update the paragraph if Hannah is an author.

Perhaps the most problematic construct to eliminate was the Wikibase label
service, as it involves preference. Based on suggestions from Hannah Bast,
the leader of the QLever team, Jinja templates were implemented that
generate standard SPARQL 1.1 constructs to efficiently determine the best
labels or descriptions.  The templates take a Wikidata item plus a sequence
of language codes and the generated SPARQL effectively iterates the over the
language codes and returns the label with the first language code for which
the item has a label or description in that language code.  Versions of the
templates had to be written that worked well with unbound query variable, as
arise in Scholia queries with OPTIONAL constructs.

[WolfgangFahl]

Perhaps the most problematic construct to eliminate was the Wikibase label service, as it is responsible for selecting a label based on a user's language preferences.

...iterates over the language codes..

[pfps]

What is the plan? Should I just make the change above, which addresses the main comment?

[hannahbast]

I will send my comments tonight

[egonw]

@pfps, yes, please go ahead.

@hannahbast, thank you. Please also let me know if you still like to be added as co-author. I asked, and organization is okay with that.

[hannahbast]

Dear all, here is a first round of comments:

Abstract: "Scholia is a graphical user interface" -> no, it is not; the second paragraph of the introduction gives a much better description, calling it a "specialized portal"; anyway, the description of what Scholia is should be consistent throughout the text

Abstract: "... we discuss a solution involving standard SPARQL 1.1 queries, compatible with any SPARQL 1.1 engine, for example QLever" -> the sentence provides no clue as to why QLever is named as an example of a SPARQL 1.1 engine here; instead, write it as it is, namely that there was a concerted effort to make Scholia run with QLever as backend, and that that was used as an opportunity to remove all the Blazegraph-specific stuff and make the queries SPARQL 1.1 compliant

Introduction, second paragraph: "with a decommissioning date in January 2026" -> the decommissioning has already happened in the meantime, so just say so and name the exact date

Introduction, second paragraph: "Preparing for this change, the Scholia team investigated three primary recovery routes." -> What follows is a list, so format it as a list (with enumerated items 1, 2, 3); the text currently has a wall-of-text quality, which makes it hard to read; lists like this are as easy opportunity to break that up (lists are much easier to digest in list form then inline)

Introduction, second paragraph: "this allows the use of any SPARQL 1.1 engine that can effectively evaluate queries against the entire Wikidata graph, including QLever [7]" -> same comment as for the last sentence of the Abstract above; write it as it is; it will be clearer that way without loss of information

Page 2, first paragraph: "a special Wikidata query service" -> I would call this neither "special" nor a "service"; it was a SPARQL endpoint powered by QLever, that's it

following sentence: "A benchmark of SPARQL backends [10 ] showing that QLever was fast on
Scholia queries supported this decision" -> clumsy sentence, rewrite to "This decision was supported by the benchmark from [10], where "QLever was the fastest overall."

Paragraph starting with "Some queries were initially slower under QLever than under Blazegraph ..." -> We will merge ad-freiburg/qlever#2673 in the next two days; when that is merged, OPTIONAL joins will be as fast as ordinary joins; in particular, when there is only a moderate number of items, for which a language label is needed (which is the typical case in Scholia and Wikidata queries), the time for OPTIONAL joins should reduce from seconds to a small fraction of a second; then we can and should remove this paragraph

Next to last paragraph: "the few remaining problems with the QLever backend do not indicate a reduction in overall performance of Scholia" -> this is a very weak claim (the performance is not worse); if this is only because of the OPTIONALs (which I think it is), this should be revised once that is merged

Last paragraph: "to set up an official Wikimedia Foundation Wikidata query service using a SPARQL 1.1 engine" -> this sounds weird, in particular the "using a SPARQL 1.1 engine" (how else should one set up a SPARQL endpoint if not with a SPARQL engine); rewrite it

following sentence: "If, contrary to current expectations ..." -> why formulate the negative case and not the positive case?

[Daniel-Mietchen]

Thanks all - I've worked most of these changes in and will do another round of brushing later.

[hannahbast]

@Daniel-Mietchen @egonw @pfps @WolfgangFahl We now have a working version of an efficient OPTIONAL and we already deployed it on https://qlever.scholia.wiki . Please click around and tell us whether (1) you can feel the difference, and (2) you find any queries that worked before and don't work now

I tried it myself, found it to be dramatically faster (as expected because almost all of the queries use OPTIONAL and that was the only reason that slowed them down), and found no mistakes so far

In the meantime, we will properly review the corresponding ad-freiburg/qlever#2695, add unit tests, and merge it into the QLever master

Also tagging @joka921 @KonradLinden @RobinTF