User Details
- User Since
- Oct 22 2014, 12:37 AM (400 w, 4 d)
- Availability
- Available
- IRC Nick
- fnielsen
- LDAP User
- Unknown
- MediaWiki User
- Fnielsen [ Global Accounts ]
Fri, Jun 24
@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.
Tue, Jun 21
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
Thu, Jun 16
It works. Thanks!
Tue, Jun 14
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
Feb 26 2020
There might be a bug in webservice migrate: https://wikitech.wikimedia.org/w/index.php?title=Talk%3ANews%2F2020_Kubernetes_cluster_migration&type=revision&diff=1856814&oldid=1856342
Feb 25 2020
Feb 21 2020
I think was due to our tool (import error on lxml on new server) as well as the problem with virtual environment change during migration. It seems to work now. https://tools.wmflabs.org/scholia/
Also tracking this at https://github.com/fnielsen/scholia/issues/1013
Dec 11 2019
Both the entity IDs and the label searches were slow. The search is now fast again, so I can make it "Resolved" (or something else?). I suppose it could have been a temporary lag in elasticsearch.
Dec 10 2019
Is @Multichill able to add 172.16.0.0/12 to https://www.wikidata.org/wiki/MediaWiki:Autoblock_whitelist ?
This seems not to be confined to lexemes but also the case for Q-items.
A possible unrelated issue is Magnus Manske's sourcemd that is also in non-working condition. https://twitter.com/MagnusManske/status/1204000679116849152
Dec 3 2019
My two tools came up nicely yesterday evening/night.
Oct 28 2019
I think the design of Wikidata lexeme was inspired by the work around wordnets and Ontolex. In the wordnet world, a sense is the intermediate step between a lexeme and a concept/synset, see Ontolex specification where the sense is called LexicalSense https://www.w3.org/2016/05/ontolex/
I suppose this issue was inspired by the discussion after Lydia's talk at WikidataCon 2019: https://media.ccc.de/v/wikidatacon2019-2-wikidata_and_languages#t=2788 . I have now gone back to see how I actually handle there situations for Danish.
Oct 2 2019
Sep 27 2019
The query is a bit hard on WDQS. If one execute it twice then the second time can apparently use some caching from the first.
Here a variation on @Yurik's query with count on within-language forms: https://w.wiki/8y8 (current count is obfuscated by Tamil annotation). For instance, 'led' in Ordia shows 9 lexemes from 3 language: https://tools.wmflabs.org/ordia/representation/led
I count over 30 basic lexemes on https://en.wiktionary.org/wiki/for while there may be more when we start to count inflections and derived terms ...
Sep 18 2019
Maybe the priority should just be "high" as few users might be viewing the 3D models?
There was some work on I18N branches in Ordia: https://github.com/fnielsen/ordia/branches It is not yet implemented in Scholia
I have changed the priority to unbreak now. I do not know if that is appropriate. The problem is that it is currently not possible to interact (basically) with 3D models on the Wikimedia sites, - only by downloading and viewing them in e.g. meshlab.
I can confirm this on Ubuntu Firefox 69.0:
Sep 16 2019
It seems that this was the only one.
I have now edited the lexeme back and forth (https://www.wikidata.org/w/index.php?title=Lexeme:L10531&action=history) which switched the language to wd:Q9056.
Sep 13 2019
Aug 29 2019
Thanks, that was apparently not submitted but just shown as preview
Aug 22 2019
Aug 16 2019
Aug 15 2019
There has been a recent namespace change announced at https://lists.wikimedia.org/pipermail/wikidata/2019-August/013350.html but this was with dcatap.
Yes, there is a Q/P mixup. DESCRIBE wd:P20980928 gives 512 results.
Aug 14 2019
Aug 2 2019
Works for me now too. Thanks!
Aug 1 2019
Yes. It is back.
Yes, fixed at my end too.
My browser is Firefox.
The lexeme has these language fields for word stem.
Yes, I experience no error on the main sight now.
Jul 15 2019
The error also appears when the first gloss is reedited
If the page is reloaded by the browser then it is possible to enter the second gloss.
Jul 2 2019
Jun 18 2019
This may have been a temporary error. It works now.