Per Laske, SPARQL for this issue in Germany [https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Surplus_of_coordinates_-_T198078]

Ditto http://www.wikidata.org/entity/Q17567523 ... there are probably others.

@Smalyshev Please check out the single coords property at https://www.wikidata.org/wiki/Q6522893#P625 versus the two rows returned by this query, suggestive of 'hidden' triples lurking still.

And note Ethan's assertion: The scheme for Geonames URIs requires a trailing forward slash.

Fix by all means, but I note "It is an error for aggregates to project variables with a name already used in other aggregate projections, or in the WHERE clause." https://www.w3.org/TR/sparql11-query/#aggregateExample

Tested - works for me in situation in which it previously didn't work.

Can I gently detach this issue, somewhat, from disputed territory. The current situation is that maps served by Wikipedias & (my key use) Wikidata WDQS use "OSM Bright for Mapbox Studio" tiles ( https://foundation.wikimedia.org/wiki/Maps_Terms_of_Use#Where_does_the_map_data_come_from? )

Worth noting that user:Twofivesixbot

@FriedhelmW ... purge != clear cache. https://www.refreshyourcache.com/en/home/

Seems more likely it's a data input issue than a query issue @matej_suchanek, given that WDQS doesn't exhibit the same sort of error for analogous wdtn:, such as wdtn:P244 (Library of Congress authority ID) - see for instance https://w.wiki/48X

de link is showing. local caching issue for @FriedhelmW ?

+1 for this. Further example of a long SPARQL report is at https://twitter.com/Tagishsimon/status/1128769104674996234 fwiw

And the clear risk with this issue is that if one enters a search term that should get a match ... for instance - Judith Schwarz - and places a reliance on the dropdown, then seeing no dropdown, as if the search term did not match anything, will, for instance, lead to the creation of duplicates.

That's not a fix, so much as a helpful workaround.

closed as duplicate of or subsumed within T214984

@Aklapper thanks - I've moved the contents to that ticket & will close this.

Let me add content from << T217103: Extension:Kartographer producing "Couldn't parse JSON" errors when SPARQL includes queryhints >> since this seems a part of the issue raised here and may provide an additional failure-mode example:

No, I'll not be doing that, any more than you just have. Whilst a serious outage is being treated merely as a curiosity, it is well worth reminding WMF employees that outages like this are far from acceptable.

Day 2 of no Quickstatements, no Listeria, no ETA for a resumption of service ... no comment from WMF on why what is a critical service - if we're taking this whole wikidata business at all seriously - is fritzed.

And to prove the curate's egg, http://petscan.wmflabs.org/?psid=7075446&al_commands=P31%3AQ5%0AP21%3AQ6581072 when run again, 502d.

Mixed results. The following three worked like a charm:

Sorry to burden you with this. As a user 502s are v.frustrating, but I can also imagine it's v.frustrating for you to be asked to debug when you could be making snowmen instead.

502 examples in the last couple of minutes:

Thanks Magnus. I run those two daily; get perhaps 20% 502s, without an obvious pattern. There are others (e.g. listed on https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Women_in_Red/Metrics/Wikidata ) which more reliably 502

How about we work out what's going on BEFORE we peremptorally close this issue. "As far as I know" does not cut it.

Ideally Cloud-Services will liaise with @Magnus either to bottom out & solve the issue; or else to provide an explanation for the 502 issue which we can use to console ourselves each time it happens.

So far as I know, the fault is not with Petscan, but with the WMF infrastructure on which it operates. Please do not be so hasty to dismiss problems like this.

@Jdlrobson Do we need to provide a description? Would not <meta name="twitter:card" content="title"/> provide our extant <title></title> contents to the twitter card. (I really don't know, but from first principles that seems to be what specifying content="title" would be likely to do.)

Is it really blocked, or is the best driving out the good? Would not something as simple as <meta name="twitter:card" content="title"/> be a massive improvement on the current highly suboptimal rendering - example: https://twitter.com/Tagishsimon/status/1064868689995071488

thx

Thx @LucasWerkmeister. All makes sense now :)

My regex is not great, but \?(\S*?)[\s\)}\.]

@Jonas - is there not a pattern that we could use instead of /^[\w\d]*/ ... we have a questionmark followed by not white space followed by a space or by ) or } or .

This issue is still occurring, lest anyone think we're done. I just got it on https://www.wikidata.org/wiki/Q55471970 when logged in.

see also T193214 which has a similar URL encoding issue.

You probably want to specify the issue here, Salgo60, rather than hope that the URL you provided will work in, say, 2 weeks time. (Hint: it won't.) The post in question says:

I think it might fall into the category of "being able to search for a formula without knowledge of the arcane ways in which it was mangled downstream of data entry".