User Details
- User Since
- Oct 22 2014, 12:37 AM (449 w, 23 h)
- Availability
- Available
- IRC Nick
- fnielsen
- LDAP User
- Unknown
- MediaWiki User
- Fnielsen [ Global Accounts ]
Tue, May 9
How do the WMF developers communicate? IRC, Phabricator, Slack, Wikimedia Chat?
I think that sticking to one in probably the best to avoid babelification. I would think that Mattermost is ok, - though I haven't tried it. Matrix.org could also be a solution.
For Scholia, we are tracking the problem at https://github.com/WDscholia/scholia/issues/2285
Wikimedia Chat does currently not work for me due to an email problem, see https://phabricator.wikimedia.org/T335471
I have tried with another email account, - a gmail-based account. That account does neither receives a verification email. And I still haven't received an verification email from my first try.
Apr 27 2023
Yes, I tried after that, but no email came.
@Aklapper No, but according to https://wm-bot.wmcloud.org/logs/%23wikimedia-cloud/20230426.txt and https://openstack-browser.toolforge.org/project/chat he is the one assigned to the chat project. Should he not have been assigned?
I have rechecked my spam folder.
Apr 25 2023
Thanks! I did not know or remember Wikimedia Chat. The sign up procedure is not documented though https://meta.wikimedia.org/wiki/Talk:Wikimedia_Chat#Registration
Currently it is not even clear how you log in. The page https://chat.wmcloud.org/login has no "Create account".
Feb 22 2023
I haven't noted this since.
Feb 2 2023
It works now. Thanks
Feb 1 2023
Also tracked at https://github.com/WDscholia/scholia/issues/2237
Dec 13 2022
I see a recovery now for mediawiki, wikidata and da.wikipedia.
This seems to be a general problem: https://www.wikimediastatus.net/#day The number of "Successful edits" have dropped.
Nov 11 2022
Example
Nov 9 2022
I have now edited the example I gave https://dreams.wikibase.cloud/w/index.php?title=Item:Q1149&diff=6989&oldid=6689 . That seemed to update the triple store.
Oct 31 2022
This seems no longer to be a problem.
There is one here with 4 simultaneous queries: https://people.compute.dtu.dk/faan/dreams.html#projecttype/Q264
Oct 17 2022
I can see the drop in the database:
MariaDB [s53734__toolviews_p]> SELECT * FROM daily_raw_views WHERE tool = "scholia" ORDER BY request_day DESC LIMIT 20; +---------+-------------+--------+--------------+ | tool | request_day | hits | uniqueiphits | +---------+-------------+--------+--------------+ | scholia | 2022-10-17 | 18 | 0 | | scholia | 2022-10-16 | 68112 | 1411 | | scholia | 2022-10-15 | 74693 | 1365 | | scholia | 2022-10-14 | 72876 | 1382 | | scholia | 2022-10-13 | 110044 | 2102 | | scholia | 2022-10-12 | 147107 | 2228 | | scholia | 2022-10-11 | 213019 | 2241 | | scholia | 2022-10-10 | 109272 | 2113 | | scholia | 2022-10-09 | 21 | 8 | | scholia | 2022-10-08 | 50422 | 1581 | | scholia | 2022-10-07 | 78 | 0 | | scholia | 2022-10-06 | 101794 | 2028 | | scholia | 2022-10-05 | 148375 | 2239 | | scholia | 2022-10-04 | 109421 | 1940 | | scholia | 2022-10-03 | 85109 | 1959 | | scholia | 2022-10-02 | 50857 | 1645 | | scholia | 2022-10-01 | 57698 | 1329 | | scholia | 2022-09-30 | 56043 | 1332 | | scholia | 2022-09-29 | 44681 | 1499 | | scholia | 2022-09-28 | 90834 | 1861 | +---------+-------------+--------+--------------+ 20 rows in set (0,001 sec)
For Ordia at https://toolviews.toolforge.org/api/v1/tool/ordia/daily/2018-04-29/2022-10-16 I see that 9 October is entirely missing in the returned JSON (perhaps because of a zero in the database I could imaging) and so does quickstatements (https://toolviews.toolforge.org/api/v1/tool/quickstatements/daily/2018-04-29/2022-10-16).
The toolviews API now works again. There has not been any change drop since 9 October 2022
After a considerable time I get "502 Bad Gateway" from https://toolviews.toolforge.org/api/v1/tool/scholia/daily/2018-04-29/2021-11-18
I now experience complete lack of response from toolviews. Neither Scholia nor Ordia works (e.g., no response from https://toolviews.toolforge.org/api/v1/tool/ordia/daily/2018-04-29/2021-11-18)
Oct 12 2022
Two issues:
- Would one be interested in linking senses rather than lexemes? A lexeme does not not necessarily correspond to one Q-item. For instance, Danish lexeme https://ordia.toolforge.org/L33929 would be a lighthouse (Q39715) or a heating unit (Q1409761). Is the sense the more appropriate level?
- Could the feature be implemented as just a Wikidata property that would link the lexeme/sense?
Oct 11 2022
Graphana for Scholia seems not to reveal anything: https://grafana-labs.wikimedia.org/d/toolforge-k8s-namespace-resources/kubernetes-namespace-resources?orgId=1&var-namespace=tool-scholia&from=1665024544239&to=1665354435147
I would mean both UI and the database. It is a question of how series this is: there is already the labels and description for a large number of languages.
Oct 10 2022
The items will have many links then. For water (Q29053744) there are current 849 language links (see https://ordia.toolforge.org/Q29053744). I think that will clutter too much.
Sep 22 2022
I am not into the code, but the Wikidata Query Service code here seems quite innocuous: https://github.com/wikimedia/wikidata-query-gui/blob/master/wikibase/queryService/ui/resultBrowser/GraphResultBrowser.js#L218
Sep 21 2022
Sep 19 2022
I am under the impression that it is developed by @bd808.
No, it seems to begin to work again a couple of minutes ago.
Sep 13 2022
Interestingly, with LIMIT 154 it works. With LIMIT 155 it does not work.
As a note: There is a similar task: https://phabricator.wikimedia.org/T261116 but in my case the order of the nodes and edgelabel is correct, - unless I am mistaken.
Sep 7 2022
Jun 30 2022
I am wondering why this is moved to "Review". Isn't it already applied?
Update to the SPARQL server seems to work now. I have checked with
It works now. Thanks!
Jun 28 2022
Jun 27 2022
@AGutman-WMF Spelling variants in Ordregister are each associated with a specific identifier. If the spelling variants are just a representation, then it is not possible to associate the identifier with the specific representation (unless a new property is proposed). On the other hand if the spelling variant is associated with a separate form then the Wikidata property can be used for the Ordregister spelling variant identifier.
Jun 24 2022
@AGutman-WMF https://www.wikidata.org/wiki/Lexeme:L348129 does have the same inflection. The Ordregister is presumable also for machines and lumps forms together. For instance, https://ordregister.dk/id/COR.53473/ corresponding to https://www.wikidata.org/wiki/Lexeme:L250372 lumps 6 different forms together in the lexeme. And each as a separate COR identifier.
I have entered this Danish lexeme today: https://www.wikidata.org/wiki/Lexeme:L348129. In authoritative works https://ordnet.dk/ddo/ordbog?query=m%C3%B8rkel%C3%A6gge&search=Den+Danske+Ordbog , https://dsn.dk/ordbog/ro/moerkelaegge/ and https://ordregister.dk/ they are regarded as one lexeme. The Ordregister has one identifier for the lexeme and we have different Ordregister form identifiers for each of the variants. The hyphenation is different between the variant.
Jun 21 2022
In Danish, we are currently using multiple forms and linking them with https://www.wikidata.org/wiki/Property:P8530 See also the discussion at https://www.wikidata.org/wiki/Wikidata:Property_proposal/Alternative_form
Jun 16 2022
It works. Thanks!
Jun 14 2022
I see that the query.wikidata.org sparql service sets access-control-allow-origin * while I do not see that this part of the response header is set at wikibase.cloud.
My Referrer Policy is "strict-origin-when-cross-origin".
Dec 10 2021
I am taking the liberty to polute the thread with a reference to "MillenniumDB: A Persistent, Open-Source, Graph Database" https://arxiv.org/pdf/2111.01540.pdf from November 2021. Millennium may have some serious limitations in terms of requirements that can be setup, but interestingly they write "However, MillenniumDB was designed with the complete version of Wikidata – including qualifiers, references, etc. – in mind." and their benchmarks seems strong. They compare against Blazegraph, Jena, Virtuoso and Neo4J.
Nov 10 2021
Thanks. Perhaps it was me mishandling Firefox. I was under the impression that shift+left mouse button on the refresh button would clear the cache. I get 200 all over from WDQS when i do shift+left mouse on the refresh button, while 200 and some 304 with a left mouse button on the refresh button.
It is working now. It may have been a insufficient cache clearing in Firefox. With a refresh it now works.
Oct 30 2021
The paper reports benchmarks favorable for QLever. I cannot get path queries working on the public endpoint.
Aug 19 2021
Aug 16 2021
Aug 5 2021
Wikicite.org (Jakob Voß) http://wikicite.org/statistics.html states 39 994 937 = 43% for 2021-06-28. The Scholia statistics is only for the "scholarly article" item. I think Voß counts instances of scholarly + non-scholarly publications.
"percentage, number of Wikidata entities that are scholarly article":
37.246.721 Scholarly articles, so 37/97 ~ 40% are scholarly articles.Could I get an idea of what the 97 was and where the number was listed maybe?
Jun 29 2021
"percentage, number of WDQS queries per month that involve scholarly articles (including authors and publications)"
Going back to the quantifiable: "percentage, number of scientific papers that are connected to non-scientific paper items in WD (not including authors and publications)"
Jun 20 2021
@Andrawaag "it is becoming more difficult to see other topics (sometimes unrelated to scholarly articles)" Do you have concrete examples on this? It may sometimes be difficult to find out what is a topic and what is a scientific articles, but once a few scientific articles about the topic has been annotated with the "main topic" property then the topic usually shows up on the top.
Jun 9 2021
Today there has been some 502 on, e.g., quickstatements and scholia.
May 26 2021
May 5 2021
"rate of growth of scholarly articles"
wikicite.org updates this statistics: http://wikicite.org/statistics.html I suppose that is Jakob Voß (@nichtich) that updates these numbers? The graph shows a bit of plateauing recently for publications, while there is a recent increase in citations. I would think that James Hare is doing the citations? As far as I remember, the citations have been mentioned as a issue of concern with respect to Wikidata data size. They are probably a good deal of the number of triples.
Some of the statistics that is wanted are listed on Scholia, currently on the frontpage: https://scholia.toolforge.org/ (UPDATE: now here: https://scholia.toolforge.org/statistics)
Mar 4 2021
Feb 4 2021
Jan 28 2021
Dec 3 2020
This item is ok for me: https://www.wikidata.org/wiki/Q102004398
The problem reappeared. There are missing edits for this item: https://www.wikidata.org/wiki/Q88191391
Dec 2 2020
The error seems to be no longer present.
Oct 30 2020
Thanks
Oct 28 2020
I have updated the code for Scholia, so the RSS error should no longer occur. I do still see the 502 occasionally.
Thanks for the rss error. We will look into that https://github.com/fnielsen/scholia/issues/1224
Oct 27 2020
At around 2020-10-27 14:29 UTC I got 502 Bad Gateway on https://scholia.toolforge.org/
At around 2020-10-27 13:38 UTC I got 502 Bad Gateway from the lexeme-forms tool
Oct 26 2020
It may have been related to [2020-10-26T20:37:08Z]. I will take a note on the exact time if it happens next time. I wonder if we should close this issue now?
For Ordia, tracked at https://github.com/fnielsen/ordia/issues/115
Aug 17 2020
I can confirm that the issue is no longer present: one can enter the L-identifier and there is no longer a delay in what the popup displays.
Jun 9 2020
Mar 15 2020
The indexing in connection with lexemes are now slow again. For instance, during creation of L270066, the form L270066-F3 is not available for use.
I am wondering whether @Bstorm could clarify if -m 1Gi is a typo and should have been -m 1G?
Mar 1 2020
Feb 29 2020
Thanks for the explanation and the restart