Not a very happy situation, though, if there is no way in WDQS to retrieve a Julian-format date that is what is entered on the wikidata item and would be universally used on sources.

Text used for the layers pop-up in the map view has also become tiny (ie the text from hovering over the layers button at the top right in a query like https://w.wiki/5L4s)

It is also particularly annoying that at the moment one cannot even add the badge to an existing redirect sitelink, without the above error message and the edit being blocked. It would be really good to get this fixed.

Just to note that the proposed recommended user behaviour has not yet been implemented:

• GIVEN an Item
• AND a page on the client that is a redirect
• WHEN adding the page as a sitelink to the Item
• AND adding a redirect badge in the same edit
• THEN the sitelink and associated badge are stored (even if the redirect target is already used in another Item)

Thanks for that clarification, Lucas, that's useful. So yes, I can use the "search" API instead: https://w.wiki/5BsM and successfully retrieve far more entries (??? albeit very slowly -- query took almost 100 seconds, just for 500 returns); but then I cannot restrict the search to just the labels of items. (I can restrict the search to titles of pages -- but for wikidata the titles appear to be Q-numbers, so that doesn't help). So I still can't get the items I need.

Previously raised on-wiki at

• https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Archive/2019/10#Search_is_very_poor_at_mis-spellings
• https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Archive/2021/04#Search_is_very_intolerant_of_mis-spellings

Am I right that there is currently no way to get continuation via MWAPI from SPARQL at all ? (cf MWAPI docs, Wikibase/API docs , wbsearchentities docs)

Duplicate of T189423

Yes: it seems that where there are multiple results with the same coordinates, in the same layer, only one is shown, the others are suppressed

(Note: previous comment inadvertently saved when only 1/3 written, so it may be needed to check web version (if not here already) for full text).

There are a few more examples of queries using the service that can be found by searching the archives of the Request-a-Query page, here, and a few more still if the search is widened further to all wiki pages on wikidata (here; limited to pages in English, to suppress translation duplicates).

This would be difficult to do within WDQS (and a distraction from the main purpose of WDQS ?)

We really ought to be doing better than this

@CBogen Can you clarify the 'decline' here?

@WDoranWMF Will, could you clarify in what sense this ticket is "invalid" ?

@Bugreporter : On many wikipedias the template "wikidata redirect' is available : https://www.wikidata.org/wiki/Q16956589

Re not removing a badge : note that it may be important for a user or bot to be able to change a badge, in particular from 'sitelink to redirect' (Q70893996) to 'intentional sitelink to redirect' (Q70894304), if the user determines that the redirect is valuable.

Addshore's suggested way forward from 10 February seems very sensible.

Probably an effect of T168341 , if the count values were not unique

I just got bitten by this, as described here at WD:RAQ.

A couple of follow-up things.

A bit more about the use-case. Early next month the external Viae Regiae project, with which Wikidata:WikiProject Early Modern England and Wales is closely co-operating, will start a mass participation effort to transcribe all of the places and placenames on several series of 16th and 17th century maps, like this 1576 Saxton map of Essex on Commons. (They will actually be using a higher-resolution copy, which we will be uploading).

A couple of days ago I have switched Tempate:Map to use the lua Module:Map rather than wikitext. Thanks to everyone on this thread who put so much work in to get Module:Map to this stage!

Platform team's IIIF project homepage: https://www.mediawiki.org/wiki/Core_Platform_Team/Initiatives/IIIF_API

I've written up a bit about today's zoom call at Commons:Village Pump, here. Feel free to add / correct / amend as desired.

Oh, now I've found it. The speech-bubble button at the top left of the view toggles a display of all of the annotations recorded on the image -- very, ''very'' nice work. Thank you!!

That Mirador view is very nice. I like the way that it is able to operate from an IIIF JSON manifest generated from the wikidata item for the underlying object (code built by @LucasWerkmeister I think), which then allows a description of the image to be displayed using the (i) button at the top right.

Long-term subscribers to this ticket will be excited to see T261621 Support the addition of the IIIF API for Wikimedia projects regarding content partnerships created two weeks ago
plus this announcement that's just appeared on the IIIF community's IIIF-discuss list ( https://groups.google.com/g/iiif-discuss/c/r9yf2GnaF1U ) :

The answer is, we ought to remove the unused ones from the RDF dump too, as discussed at T258474

@dcausse It *does* hurt a person who is trying to make sense of the dump, because they will see all these unfamiliar prefixes declared that they may then assume there will be corresponding kinds of predicates or objects that they have to make sense of.

Ticket description should be re-written.

In some ways it's quite nice that WCQS uses tinyurl rather than the w.wiki shortener -- at least it means there is not such a limit on how long the query can be. (T220703).

It would be helpful if at least one of the rdf:type statements were retained, as they make it easy to select a subset of M-IDs for a query to work on

Most of the above prefixes will be unnecessary, unless we propose to create any new properties local to Commons not defined on Wikidata.

Given that mediainfo items are just of the form sdc:M12345, is much meaningful autocompletion for these actually possible?

It also might be worth making the M-ID number prominently visible on the structured data tab of the filepage, given that this is where the information related to that ID is shown.

@Lucas_Werkmeister_WMDE : I think it would be more feasible to add the Special:FilePath URL to the WikibaseMediaInfo RDF, and combine WDQS and WCQS that way

PS. It's also stupidly hard to find the M-ID from a WikiCommons file page at the moment. This would be a good thing to display in the "structured data" tab there, I think.

I think you meant

wd:Q123  wdtn:P18  sdoc:M6919529

in that second line ?

IMO the best solution here would be to add triples of the form

Yes, there's a cost to you of providing a service based on current WDQS, that then has to be ripped out for a new version based on WDQS 2.

Engineering a completely new search facility for Commons Data rather than using SPARQL is a *stupid* *waste* *of* *time* *and* *resources*.

That's a bit of a problem, given what the badges are for...

I tried to add an "intentional sitelink to redirect" badge on the English sitelink for asteroid 6765 Fibonacci, but got "Could not save due to an error. The save has failed."

regarding editors : it looks like some works have multiple editors, none of which have Wikidata items. These ought to be given in separate statements distinguished by "series ordinal".
But it may be that because the statements both have the same 'main value' (or, rather, they both have somevalue for the main value), the software used to add the statements may have coalesced them together. QuickStatements tends to do this, I think.

• "named as" = name given to the subject of the statement
• "stated as" = how the object of the statement was stated

@Lucas_Werkmeister_WMDE The qualifier "stated as" (p1932) is currently used on 6.6 million statements. I couldn't get a query to complete to count how many of those statements have an object that's a blank node. My guess might be on the order of about 10,000 but that's just a number pulled out of the air, not based on anything. Could be a *lot* more, if this mechanism has been used eg for scientific papers with unmatched editors, publishers, etc.

Example of a Listeria tracking page, counting how many blank nodes are being used this way for the properties used on a particular set of items (in this case: a particular set of books, where the publisher (known) may not yet have an item, or at least not yet a matched item): https://www.wikidata.org/wiki/Wikidata:WikiProject_BL19C/titles_stmts

Please don't think or refer to the blank nodes as just "unknown values".

Thanks Matthias, but that doesn't seem to help with the use-cases above, if a claim is just sitting there as a claim, and not being used by any Lua template (as most "depicts" claims probably wouldn't be?)

Lead ticket for Vue migration for Wikidata would appear to be T157014 . After sustained activity in 2017, followed by a short spike in June-July 2018, it's not clear how much further progress has been made, or is currently anticipated on this. There is a mention that the Lexemes roll-out in 2018 included some Vue templates and widgets with PHP server-side rendering, which was going to be reviewed.

WMF projects use OOUI and org-wide design principles. Wikibase does not.

Given the endless, and seemingly ongoing, difficulties the decision to fork the wikibase UI is leading to, and seems to be continuing to produce -- most types of statement still not available, somevalue not available, deprecation not available, references not available -- at what point does it make more sense to withdraw the forked UI as a costly experiment that hasn't worked, and is causing more trouble than it is worth?

@Pintoch That's great. I'll try and get matching these this weekend. Is there any chance of the full dataset, beyond the first 1000? We currently have 1660 items for bodies of water in the UK (plus more that possibly don't have P31s), so it would be nice to be able to try to match them all. But thanks again for this!

If maxlag is to be based on the maximum lag of the pooled servers, will there be active measures to monitor these, and take any really badly lagged server (ie significantly worse lagged than any of the others) out of the pool, and out of the maxlag calculation, to give it a chance to recover ?

I would love it if somebody would take this on. I think it's a really worthwhile resource to link to, and a really significant topic to improve our data for.

Hi @Pintoch. Thanks for this.

One thing that seems odd (to an outsider like me who knows very little about the system) is that some servers seem to be performing so much worse than others.

@Lucas_Werkmeister_WMDE How dependent is the wikibase constraint system on SPARQL ?
Maarten was just suggesting that a functioning SPARQL service is required for any of the constraint checking to operate (and so this ticket would be completely blocked until CDQS is reliably up and running)
Is that correct? Or are any of the simplest of the constraint checks (eg format constraints, one-of constraints, etc) available without SPARQL ?

I very strongly agree with this ticket. It needs to be as easy as possible for query-service users to find queries that illustrate "how do I do this?"

Use-case example to show why this is urgently needed: The property source of file (P7482) is intended to show the broad nature of the origin of a file.

Example: property source of file (P7482) is intended to show the broad nature of the origin of a file.

@Lydia_Pintscher - Having now kicked a few possibilities around on Project Chat, can we go for creating badges with:

There is some sense in what MisterSynergy says, but I also think there is sense in what @deryckchan wrote in the RfC (here), namely that there still ought to be some warning if someone tries to sitelink to a redirect page, and the user should be made to actively confirm that they didn't want to instead link to the redirect target. Otherwise I could see us ending up with a lot of accidental sitelinks to mis-spellings, which the present system mostly keeps us safe from.

Thanks Lydia. I've started a thread at Wikidata:Project_chat#Badges_for_sitelinks_to_redirects to quickly see if there are particular icons people would prefer; and created two items, Q70893996 ("sitelink to redirect") and Q70894304 ("intentional sitelink to redirect") where we can start to assemble translations.

The badges, and corresponding bot, might be a nice quick win for Wikidata's 7th birthday.

Mostly, the existence of a sitelink to a redirect indicates a potential data problem on Wikidata: a sitelink that has been left over when two Wikipedia articles have been merged, but no corresponding merge has been made on Wikidata. A sitelink to a redirect can therefore be a strong indication that an item on Wikidata is a duplicate of another one, and should be merged with it. However, at the moment it is not possible for somebody browsing a Wikidata article to readily spot that a sitelink points to a redirect. A badge to identify this would bring the fact into plain sight.

For discoverability, maintenance, and reuse, it is as important to be able to store metadata for datasets via SDC as it is to be able to store metadata for images.

Are we any further forward with this?

On a separate but related issue: we now have quite a lot of images of old maps on Commons, with coordinate georeferencing allowing the maps to be "warped" to standard coordinate systems. It would be nice to be able to serve the warped versions of the maps as tilesets, allowing users to compare different historical representations of given places as layers.