Another example similar to T233204#6571446: in this query by @Moebeus and myself, the Unicode character (flag) for Australia (🇦🇺) is incorrectly displayed as the ligature Ꜷ (“AU”).

Solution this task covers

Use the Blazegraph CANCEL POST request to stop the query from running on one of the query servers.

For me they look exactly the same – I suspect the first URL is still in your browser cache.

I think @Ratso56’s original title was more accurate. The core issue isn’t that some JS/CSS is failing to load – as far as I can tell, the server is sending the completely wrong HTML to begin with. It’s sending the same HTML as for https://query.wikidata.org (main Wikidata Query Service UI), whereas this is supposed to be a different service.

Steps to reproduce: take the SPARQL query at the beginning, paste it into https://query.wikidata.org, run the query (press Ctrl+Enter or clilck the blue “run query” button).

Rolling back the merge still works, apparently, and afterwards it’s also possible to restore the old version. I used this on Q38906046 (rollback diff), and @MisterSynergy also had success with this on Q34836264 (rollback diff).

Note that this can also occur on grouping queries:

SELECT ?x (COUNT(*) AS ?total) (SUM(?y) AS ?ys) (?ys/?total AS ?ratio) WHERE {
  ?x wdt:P31 wd:Q1.
  BIND(1 AS ?y)
}
GROUP BY ?x

And an alternative workaround is to inline the variables into the SELECT, i. e. (SUM(?y)/COUNT(*) AS ?ratio). The advantage of this is that you can still use ?ratio in a HAVING clause on the grouping query (a FILTER in the outer query is less efficient).

Yes, that’s what I meant with:

I think these are the same issue:

Here’s a variation that triggers the error: query

Here is the real query – the relevant part is: either a statement is a normal statement and has a proper object (?object), in which case I want its label, or it’s a “no value” statement, in which case I want to bind ?objectLabel to "no value"@en. (In the real query, in the end I had to use rdfs:label anyways to make the GROUP_CONCAT in the SELECT clause work.)

Yup, LGTM. Thanks!

Another query with the same error message:

This is not true, properties have labels too.

I don’t really like the choice of rdfs:label as predicate. Currently, as far as I’m aware, only items have triples with that predicate, and queries that rely on this assumption might break (and the straightforward fix, ?item a wikibase:Item, isn’t available on WDQS). There’s also the datatype issue that @Esc3300 mentioned, but I don’t think it would be correct to claim that every title on enwiki is in English, either (random examples: Q300 is just some identifier, Sposalizio is Italian, …).

This seems to have been done, both less and wget are available in my server at least.

Actually, @yuvipanda suggested to use an IPython.display.IFrame directly instead of an ipywidgets.HTML with an <iframe> inside it, and that works like a charm. I’ve now packaged that into an importable notebook, [embedWDQS.ipynb](https://paws-public.wmflabs.org/paws-public/46618563/embedWDQS.ipynb).

The name/title would be a property of the sitelink, not the item. An item can have multiple sitelinks, but each sitelink ought to have exactly one title.

I would suggest a triple with the predicate schema:name, or perhaps schema:headline.

Alright, sure, I’m going to publish it anyways :D

Hrm, perhaps I over-reduced it. In the original query, I of course select ?personLabel in the inner query as well – I only noticed that it wasn’t necessary to get the error message, so I threw it out.

Ah… I should have thought of that. Because I actually saw an odd date string for that item at one point, and fixed it. Sorry, I really should have mentioned that. (But it probably won’t be the only item with such a date string…)

Huh, so it’s the discrepancy in the precision?

That’s odd, because occasionally curly braces also cause problems, and according to MDN encodeURIComponent always escapes those. I guess that perhaps the browser gets confused when it partially decodes the URL to display it in the location bar…

@Smalyshev: Good to know. So the client would send the cancel request while the query GET request is still pending, and that would then return… 204 No Content? 408 Request Timeout? (I suppose it doesn’t matter – the client knows it canceled the query, it doesn’t need to check the response to detect that.)

I actually used to use the short bit.ly links, but stopped because

👍, though I hope that the display won’t require ORDER BY ?date to function?