This is the umbrella project for the concluded Structured Data on Commons programme, adding structured data for multimedia files (primarily on Wikimedia Commons). For structured data in general, see Wikidata. See also the documentation on Wikimedia Commons.
Ah, I updated the wrong wish. This isn't related to a wish, so I reverted that. Thanks for flagging!
@mikez-WMF Which current wish would this be related to?
I like the idea. The HTTP parameter could be something like this:
The existing MinervaNeue file ToC looks like this:
Yes, all skins should be supported (thanks to @Samwilson's review on gerrit).
@simon04 Just to check (I assume "yes"!), will these patches also work for
(A) Users (or wikis) with non-English language settings -- IIUC, this is already handled automagically.
(B) All other skins? -- I.e. Minerva, Monobook, Timeless, Vector (legacy); but also generic 3rd-party skins?
It might be good to add screenshots for those examples, to prove that the changes are suitable & tested for all easily-predictable situations.
P.s. Thank you immensely for working on this bug!
Change #1306092 had a related patch set uploaded (by Simon04; author: Simon04):
[mediawiki/core@master] ImagePage: Include foreign-repo description headings in the file TOC
Change #1306091 had a related patch set uploaded (by Simon04; author: Simon04):
[mediawiki/core@master] ImagePage: Integrate the file TOC into the page table of contents
Deployed, and post-deploy checks came back good. Also updated the registry. This is done.
Change #1305780 merged by Ryan Kemper:
[operations/puppet@production] query_service: allowlist QLever Commons
Change #1305780 had a related patch set uploaded (by Ryan Kemper; author: Ryan Kemper):
[operations/puppet@production] query_service: allowlist QLever Commons
Are not visible in the automated "filetoc" bar unless we click the red "x" to "Remove" (hide) the reuse-links.
@Zache Thanks a lot for the examples. That helped us find a subtle bug in our update script (not in the core qlever code). The bug occurred when two messages of the update stream that modified the same triple (one insert, one delete) arrived in reverse chronological order. This is now fixed, see https://github.com/qlever-dev/qlever-control/pull/299 . The fix is already live on https://qlever.dev/wikidata . A test suite we ran, including your test cases, showed no more difference between https://qlever.dev/wikidata and https://query.wikidata.org/
@Zache Can you be more specific regarding what you think is missing? A concrete example would help. Please report on https://github.com/ad-freiburg/qlever/issues . Note that potentially there are at least three sources for missing information in the endpoint: potential problems with the update stream, potential problems with the translation of the update stream messages into SPARQL updates, potential problems with the update processing inside QLever
Just FYI about QLever syncing. In april we tried to use QLever as backend for Ukbot (bot which calculates points for editing competitions) and least for wikidata sync, it misses some of the wikidata item creations (ukbot github) and probably edits too. It was not syncing lag problem as there were newer wikidata item creations which could be found on Qlever so it seemed just to be skipping some edits. I suppose that same feature is with SDC sync too.
@Hannah_Bast thank you. Once this is well advertised, data on how it is being used would answer one of the questions implied by @Gehel's original ticket here.
This is now resolved, Wikimedia Commons is supported via QLever.
@Hannah_Bast that's pretty nice! I would definitely post it in the Wikidata telegram group, and maybe on the mailing list(s) as well.
https://qlever.dev/wikimedia-commons provides an endpoint for this data. So far, it loaded the raw latest-mediainfo.ttl.gz from https://dumps.wikimedia.org/other/wikibase/commonswiki and was updated only irregularly.
JsonConfig has an prior art schema which we can just borrow from: https://phabricator.wikimedia.org/diffusion/EJSC/browse/master/sql/tables.json