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

I can confirm that the quite wobblying graphs that I previously experienced with Scholia are now all gone.

There are many of these problems for Karl Zilles, see:

It should be fixed now, e.g., https://tools.wmflabs.org/wembedder/most-similar/Q76#language=en

I think someone pointed to error-line{border-bottom:2px dotted red} (I forgot who). https://query.wikidata.org/css/style.min.0d7eafbda8bb1aa11051.css. Changing red to white seems to do it.

In my opinion it is not outside the component developer, as the SPARQL.js just could be disabled here on WDQS. In my opinion the red dots confuse more than syntax highlighting helps (when there is no WITH). If WDQS could be personalized I would switch SPARQL.js off.

I see the individual pages are put up. I we suppose to do anything?

Include "https://gist.github.com/lucaswerkmeister/28608c3667a7064455152959a6e0e4cc" and attempt to see the graph: It is not possible on Ubuntu Firefox

The UX for scrolling is still terribly bad. It makes it close to unusable for some queries. Try with this gist https://gist.github.com/lucaswerkmeister/28608c3667a7064455152959a6e0e4cc

Yes, the 404s is a known problem, that I should fix

Can you confirm that it no longer loads from third-party or should I just close the task myself?

This is now fixed with https://github.com/fnielsen/cvrminer/commit/49975504a590a1ae53e2e8cc81aadea277cc5600 I have checked at https://tools.wmflabs.org/cvrminer/

Thanks for reminding me of this. I will change it to a toolforge serving.

See also https://www.wikidata.org/w/index.php?title=User_talk:GZWDer&oldid=531264407#Dot_after_title

@Smalyshev Try to add an empty newline at the top. That usually does it.

With http://tinyurl.com/y9ekltr7 WITH and its parts in "{ ... }" get sometimes dotted and I agree that it is distracting. It would be better with SPARQL.js switched off then or something like

I still get "502 Bad Gateway". It seems to be tied to one worker. Currently, I get "Respawned uWSGI worker 1" several times, while the other workers (that I see with different pid) does not seem to run into problems.

On my Flask development server, Python3 is using 1.2 GB fairly constantly (somewhat more than I anticipated). I suppose that I run into memory problems. I wonder how I can get around this.

I do not know how to start it with few workers. Isn't the number 4 hardcoded into /usr/lib/python2.7/dist-packages/toollabs/webservice/services/uwsgiwebservice.py?

I see "/usr/lib/python2.7/dist-packages/toollabs/webservice/backends/kubernetesbackend.py"

I have managed to get it going with --backend=gridengine uwsgi-plain, but I suppose it would perhaps be nice to have the kubernetes issue fixed, - if it is not something that is specific to me.

I see a related task here https://phabricator.wikimedia.org/T133999

<s>I am embarrassed to say that I am not sure what what Toolforge is. I do not think I need a dedicated machine. Just one like "Scholia" (tools.wmflabs.org/scholia) where I can "become" and put a Python Flask in www/python/src, so it is available at tools.wmflabs.org/wembedder. I do not need a dedicated server like the one librarybase is running from https://librarybase.wmflabs.org/. </s>

https://fnielsen.github.io/littar/ could also provide a nice map.

https://github.com/fnielsen/scholia & https://tools.wmflabs.org/scholia/