This may have been a temporary error. It works now.

BTW: This affect the ShEx validator.

Quite a number of panels in Scholia has been affected by the change/bug, e.g., https://tools.wmflabs.org/scholia/author/Q20980928 "Number of publications per year", "Number of pages per year" and "Citations by year".

As a tool provider it would (also) be nice to have the data transposed - so to speak: Eg. https://tools.wmflabs.org/toolviews/api/v1/tool/scholia where the returned data is across multiple days.

Further development issues are noted here: https://github.com/fnielsen/scholia/issues/721

This was related to Wikimedia-Hackathon-2019.

Javascript implementation being experiment on here: https://codepen.io/fnielsen/pen/oReLKE

Maybe this is not a bug per se, but intentional? There is not yet a Fon Wikipedia, - it is on Incubator.

Yes, it has been working fine now.

This seems to work fine now.

Another way to generate status code 500 is by, e.g.,

There seems to be another issue with the Wikidata.org/w/api.php?action=wbsearchentities: T222347. In the case of T222333 the result is just empty, while T222347 returns status code 500.

Commands such as these seems to have fixed it:

webservice --backend=kubernetes python shell
cd www/python
python3 /usr/lib/python3/dist-packages/virtualenv.py --python=python3.4 venv3.4
ln -s venv3.4 venv
cd ordia ; pip install -rrequirements.txt

It is a python3.4/python3.5 issue? The Virtualenv I can construct is 3.5. Kubernetes start Python 3.4.2.

Ordia's uwsgi.log looks basically the same as QuickCategories. And with restart I get the same message.

Yes. This may have been a temporary issue.

currentDay gadget for P813 now in troubles. I wonder if the fix/changes related to this issue.

The fix works for me. Thanks!

The issue must related to a change happening on 13 March or a few days before.

There have been slow response from Toolforge services. I use sourcemd and scholia. sourcemd was just slow, and have been slow from time to time. In scholia I have seen error messages like:

A new attempt succeeded: https://www.wikidata.org/wiki/Q59870754

"Non-tabular WDQS embeds do not display": Note embedded tables neither works. Embedded tables show the same errror

May clearing of deleted items be related? https://www.wikidata.org/wiki/Lexeme:L31707 has been deleted since 14 November 2018, but is still in WDQS:

This works nicely now. I wonder if there is a cache/delete issue. Sometimes are see results that no longer exists in Wikidata, perhaps because the statement has been changed.

Yeah, the standard does not specify the ordering "The order of the strings is not specified." - https://www.w3.org/TR/sparql11-query/#defn_aggGroupConcat see also https://stackoverflow.com/questions/47460803/sparql-group-by-and-order-by-not-ordered .

Here is one I did for JVJ's residence based on the @Jheald approach: http://tinyurl.com/yb3k84qj

The linked example no longer display the problem, as I as a workaround now uses Unicode characters instead of Wikimedia Commons images in the timeline. It is however, still a general problem.

If one switch to table view and back to timeline view with the left switcher then the timeline appears.

The status code associated with embeddings where the timeline is missing is 200 (as far as I can determine). In the console I identify no relevant errors.

This was also suggested by Andy Mabbett over 2 years ago "We should instead devise an equivalent of Wikipedia's 'Citation needed' tag. " - https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Verifiability_and_living_persons

Thanks! I can confirm subscription works for me.

"Next step: looks that we should have a new property for exact match data.nobelprize.org and Wikidata eg."

Regarding "not working" sparql endpoint: I think you need to provide the query parameter. This works for me http://data.nobelprize.org/sparql?query=SELECT%20COUNT(*)%20WHERE%20{%20?s%20?p%20?o%20}

In Scholia, we have an aspect for awards. For the Nobel Prize in Physics it is available here: https://tools.wmflabs.org/scholia/award/Q38104

I cannot reproduce it now. Perhaps it has been solved. These edits went though alright: https://www.wikidata.org/w/index.php?title=Lexeme%3AL1234&type=revision&diff=705379362&oldid=705379136

Thanks. It seems that the workers = 2 in $HOME/www/python/uwsgi.ini has worked. The response in Wembedder itself as well as in Scholia seems much better, and I do not see DAMN ! worker 4 (pid: 20) died, killed by signal 9 :( trying respawn ... in the log file anymore.

Thanks very much for the explanation.

I have also noted problems with items.

It doesn't "feel" like T182102 to me.

After https://www.wikidata.org/w/index.php?title=Lexeme:L1234&diff=686190332&oldid=686190168

The patch for the tag cloud bug seems to also have fixed the "Rate limit exceeded" error. As the tag cloud bug may have called the WDQS the double number of times I suppose that this could explain why we no longer see the problem.

This is also discussed in Scholia: https://github.com/fnielsen/scholia/issues/373

"HTTP 500 seem to have a syntax issue". So I suppose it might be an issue my SPARQL? (I see that the work variable is not returned in one SELECT, but it seems strange to me that it is usually working...)

I wonder how I can test this. Is there a test system? The only way I can imaging is to find a Danish article that needs translation to English.

Yes, you are right.

It seems to work for me too now, while I had the problem before.

Yes, it did happen. It can be closed.

In T189513#4044089, @Smalyshev wrote:

The server can return partial JSON in case of timeout. The HTTP status should be an error then, like 500, though. Not sure what the "cache" refers to here though. Maybe Vagrant caches cache 500 responses too?

Yet another related issue is SELECT * WHERE { wd:Q80 a ?object . } should give a wikibase:Item returned if I understand the documentation correctly here https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format#Entity_representation with its example of wd:Q3 a wikibase:Item ;.

I see the default of Wikimedia\WaitConditionLoop is 5 seconds which corresponds well with the 5-6 seconds delay I experience with the API when editing on a desktop where there are calls to, e.g., https://www.wikidata.org/w/api.php?action=wbparsevalue

I tried recently with a DOI, "hoping" that Fatameh would be able to add such an identifier.

"but it would be nice to have them plotted with lines in order of residence". This is not support by WDQS at the moment AFAIK. If you want that you might want such a specific functionality you might want to create a specific task and perhaps @Jonas could look into that at some point.

Yes, see for instance here https://tools.wmflabs.org/scholia/author/Q159552#Locations for Johannes V. Jensen or here https://tools.wmflabs.org/scholia/award/Q185667#Locations%20of%20recipients for awards. At present Scholia is mostly for science and scientist though it will also work for Rembrandt, see https://tools.wmflabs.org/scholia/author/Q5598#Locations

Sorry forgot about https://twitter.com/Jokrates/status/905168873011458048 I thougt I had reported it on Phabricator, - and I could not find it.

Added as a Scholia issue: https://github.com/fnielsen/scholia/issues/192