Shortcuts: WD:PC, WD:CHAT, WD:?

Wikidata:Project chat

From Wikidata
Revision as of 11:33, 17 January 2021 by Matěj Suchánek (talk | contribs) (Reverted edits by Alialanezi33 (talk) to last revision by Jura1)
Jump to navigation Jump to search

Edit

The metadata of many book reviews is incorrect at Crossref, Google Scholar...

At the moment I am adding all citations using the "cites work" statement. When a paper has no links I google for it.. Often there is a link to Crossref and/or Google Scholar. This is one example.. Q93615130 is the item ... When you analyse the statements, they all refer to Crossref, they refer to the reviewed book and are NOT about the review. Consequently, MANY books have a DOI as well but they are of the review NOT of the book. Given the prevalence and the small set of data, it is likely a huge issue and not so much an incident.

I have reached out to Crossref, I have corresponded with Roderic Page who added the item from the data at Crossref. Thanks, GerardM (talk) 10:13, 3 January 2021 (UTC)[reply]

GerardM: I'm a little confused. When I run the doi 10.2307/4109011 on Crossref, it returns https://search.crossref.org/?from_ui=&q=10.2307%2F4109011+, and that's tagged by Crossref as a book review (or, rather, a journal article), not a book. AleatoryPonderings (talk) 16:51, 3 January 2021 (UTC)[reply]
The review has only one author. Many of such reviews are linked as citations in stead of the work they review. Many books DO have a DOI as well as a ISBN however, quite often the review is used in stead of the book. Thanks, GerardM (talk) 18:01, 3 January 2021 (UTC)[reply]
The review was published in Kew Bulletin (Q2675794) and not the book itself with was published by Blackburn Press. The statements in the item seem correctly about the review and not the book. ChristianKl ❪✉❫ 11:53, 4 January 2021 (UTC)[reply]
Did you check the history ... I needed that item. thanks, GerardM (talk) 19:48, 10 January 2021 (UTC)[reply]
  • I think I once noticed a case where the review metadata (from cross-reference) was added to the item about the work here. The reviewer ended up being seen as a co-author. --- Jura 12:19, 8 January 2021 (UTC)[reply]

Verses of the Bible

Currently, thanks to the work of LesserJerome, we have elements for all Bible verses from the gospels, like Luke 3:14 (Q64688743). Also, due to Ben Skála, parts of the verses of Genesis, Job, and Lamentations exist. However, the vast majority of Bible verses don't have an item yet. Anybody who could create them? 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 13:37, 4 January 2021 (UTC)[reply]

It's my understanding that Catholic and Protestant bibles divide the text into verses a little differently, and consequently, number the verses differently. How do you account for this? Jc3s5h (talk) 14:50, 4 January 2021 (UTC)[reply]
A possibility would be to use aliases and include the text of the verse in a property for identification. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 09:43, 11 January 2021 (UTC)[reply]
It seems to me like it would be good if the items of the verses would point to the corresponding text on Wikisource. ChristianKl ❪✉❫ 14:54, 4 January 2021 (UTC)[reply]
It is not as simple, as that one verse in one bible corresponds exactly with another verse in another bible. One translation can make a split mid sentence, while another let a whole sentence stay inside only one verse. Its the editors privilege to choose that. To make any sense of this, we should have one verse-item for every edition of the bible. 62 etc (talk) 07:11, 13 January 2021 (UTC)[reply]
Yes, that would be helpful and I thought about this, too. Is there any property for this? 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 14:56, 4 January 2021 (UTC)[reply]
Sitelinks aren't modeled via properties within Wikidata but on the right side in the sitelink menu that goes for Wikisource pages the same way it goes for Wikipedia pages. ChristianKl ❪✉❫ 15:06, 4 January 2021 (UTC)[reply]
@ChristianKl: Er, but we are talking about sections, right? Plus, there are multiple translations of the Bible on Wikisource, so there is no one-to-one correspondence anyway. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 19:26, 4 January 2021 (UTC)[reply]
Unfortunately, I don't know enough about WikiSource to know what would be best here. ChristianKl ❪✉❫ 15:59, 5 January 2021 (UTC)[reply]
@1234qwer1234qwer4, ChristianKl: On en.wikisource, the versicles have ids, so you can do Genesis 1:1 (Q4101743)full work available at URL (P953)https://en.wikisource.org/wiki/Bible_(King_James)/Genesis#1:1part of (P361)King James Version (Q623398) --Tinker Bell ★ ♥ 21:00, 11 January 2021 (UTC)[reply]

"Compress" same statements with different ref URL

Hello, is there bots to merge two "exacts" same statements into one? Same value, same point in time (P585), but different references . Eg : https://www.wikidata.org/w/index.php?title=Q630524#P3872 : go see the year 2019 ; it should be reading only one statement, not two. Thanks --Bouzinac 💬●✒️●💛 13:08, 7 January 2021 (UTC)[reply]

My bot has a subroutine for this. However, when I have it run over that item it does nothing. There is probably some internal "invisible" difference that makes Pywikibot treat them as different. --Matěj Suchánek (talk) 08:23, 8 January 2021 (UTC)[reply]
Dates are different: one has "+2019-00-00T00:00:00Z", the other "+2019-01-01T00:00:00Z"; both with "Precision 1 year" [1]. --- Jura 11:34, 8 January 2021 (UTC)[reply]
I understand what you said, but to my functional point of view, they look the same.
Could your bot consider these precisions as the same technical date ? Other example of pb with month precision : Q854130#P3872, see eg months of 2019 Bouzinac 💬●✒️●💛 15:41, 8 January 2021 (UTC)[reply]
You made me do it. --Matěj Suchánek (talk) 11:22, 9 January 2021 (UTC)[reply]
Good! --Bouzinac 💬●✒️●💛 16:19, 10 January 2021 (UTC)[reply]

Gender forms of surnames

Is there a fixed rule / policy on Wikidata modelling for surnames, which have different forms for different genders of people? This is a very important issue for Polish names. We've recently had a discussion about it in the main Polish-language Wikimedia related group on Facebook. Most people favoured creation of separate items for all forms and there was also an idea to link those items using surname for other gender (P5278). However, FB discussions in one language are obviously non-binding for Wikidata community, so I want to bring it up here. Powerek38 (talk) 17:08, 7 January 2021 (UTC)[reply]

Ash Crow
Dereckson
Harmonia Amanda
Hsarrazin
Jura
Чаховіч Уладзіслаў
Joxemai
Place Clichy
Branthecan
Azertus
Jon Harald Søby
PKM
Pmt
Sight Contamination
MaksOttoVonStirlitz
BeatrixBelibaste
Moebeus
Dcflyer
Looniverse
Aya Reyad
Infovarius
Tris T7
Klaas 'Z4us' van B. V
Deborahjay
Bruno Biondi
ZI Jony
Laddo
Da Dapper Don
Data Gamer
Luca favorido
The Sir of Data Analytics
Skim
E4024
JhowieNitnek
Envlh
Susanna Giaccai
Epìdosis
Aluxosm
Dnshitobu
Ruky Wunpini
Balû
★Trekker

Notified participants of WikiProject Names ChristianKl ❪✉❫ 21:55, 7 January 2021 (UTC)[reply]

Happens in many Slavic languages. Example: Stepanova in Russia and Ukraine. Klaas `Z4␟` V:  08:20, 8 January 2021 (UTC)[reply]
FB is free to do whatever they want there. I don't think this is the place to discuss Facebook. --- Jura 12:31, 8 January 2021 (UTC)[reply]
@Jura1: I'm sorry, but I don't think you've understood what I wrote above. I wrote that wikimedians were discussing this matter using FB and now I am bringing it up here. This has nothing to do with Facebook, apart from the fact that it was used as a convenient forum for initial discussion. Powerek38 (talk) 16:45, 8 January 2021 (UTC)[reply]
Ok. Wikidata generally doesn't care about FB discussions. Don't some wikis have explicit policies prohibiting offsite discussions? --- Jura 08:00, 9 January 2021 (UTC)[reply]
Please try to be less offensive, Jura. This is really unnecessary. If you have a problem with some user's behavior or some Wikidata policy, please bring it up separately.Vojtěch Dostál (talk) 16:03, 11 January 2021 (UTC)[reply]
Personally, I find it offensive to conduct policy discussion on another website. Can we know who were the users who participated in this? --- Jura 16:14, 11 January 2021 (UTC)[reply]
I'm sorry, but I think this is really getting absurd, apart from being totally off-topic. Wikimedia, in its various shapes and forms (WMF, projects, chapters, user groups) has had a very strong social media presence for years. There are numerous FB groups for different Wikimedia-related topics. Obviously, no binding decisions are made outside one of wikis, but those informal discussions take place all the time. Our main Facebook group in Polish, which is called simply pl.Wikipedia, is very far from being a secret and it has over 500 members and among its moderators you can find WMPL's Vice President and WMPL's Community Support Officer. And that's just Facebook. The we can talk about Discord with many Wikimedia servers etc. If you really consider it harmful, Jura, it's obviously your right to hold that opinion, but please, don't create any more off-tops out of it. If you fell you need to, initiate, just as Vojtech suggested, a separate discussion, probably on Meta, as it's a movement-wide issue. Powerek38 (talk) 18:12, 11 January 2021 (UTC)[reply]
It's really a matter you brought up here. If you don't want to address questions about it, don't. If you don't want to participate onwiki, it's unclear why you come here. Redoing onwiki discussions elsewhere doesn't seem very constructive. --- Jura 11:37, 13 January 2021 (UTC)[reply]

My view is that -ova feminine forms should only be created as separate items if it is unclear what the masculine version of the surname actually was. This happens in some languages due to grammatic changes in word endings.

Tobias1984 Vojtěch Dostál YjM Jklamo Walter Klosse Sintakso Matěj Suchánek JAn Dudík Skim Frettie Jura1913 Mormegil Jedudedek marv1N Sapfan Daniel Baránek Draceane Michal Josef Špaček (WMCZ) The photonaut Hartasek Zelenymuzik Gumruch Shadster Dænča M.Rejha Janek Jan Kameníček Eva Vele Linda.jansova Lukša Packa Fukejs Hugo Xmorave2 J.Broukal Lenkakrizova Steam Flow Pavel Bednařík Sanqui

Notified participants of WikiProject Czech Republic as this has been discussed in the Czech community as well and someone may come up with a good example of it happening. Vojtěch Dostál (talk) 16:03, 11 January 2021 (UTC)[reply]

Good question, Powerek38. A very important topic for many Slavic languages. I see two possible ways of modelling this. First, have one item per surname and distinguish the gender forms with male form of label (P3321) and female form of label (P2521). Second, have separate item for each gender variant, connected via surname for other gender (P5278) (and I can see now we need a better label in Czech, so it's obvious that this property is symmetric). But most importantly, we should stick to one of these schemes and do not mix them up and make no exceptions. --YjM | dc 17:06, 11 January 2021 (UTC)[reply]

The problem is both approaches have their upsides and downsides.
For the scheme (currently my slight preference) of sharing one item for both the male and female forms, noted using female form of label (P2521), it is a surname of the father inherited by the daughter / the name of the husband / the name of the sons of the woman; it is also the version used by/for some women internationally (see e.g. Otilie Suková (Q60467588), with randomly found [2], [3], and also “Photo of Josef and Otilie Suk” at en:Josef Suk (composer)). Basically, both gendered and non-gendered version are the same surname, only in a grammatically differing role. The downside is you cannot distinguish women who normally use the gendered version from the exceptional cases of women using the non-gendered version (e.g. Emma Smetana (Q11878748)); also, other languages would always reconstruct the non-gendered version using given name (P735)+family name (P734) (e.g. in English, Petra Kvitová (Q30812) would get Petra (Q740790)+Kvita (Q62740665)).
On the other hand, the separate-items scheme is basically the reverse: The name of the person is trivially composable with the proper version of the surname already set, but you cannot determine what is the “family name” of the woman, i.e. what was her father named / what is her husband’s name / what is her son’s name. And please note surname for other gender (P5278) does not really help with that: There are many surnames which share the gendered version, so the item for the gendered version will have multiple P5278 claims (e.g. Blažková (Q43371396): Blažková might be a daughter of Blažek, Blažke, Blažka, Blažko…). On the other third hand, there are even exceptional cases where there are multiple female versions of a single male surname, depending on the family tradition (e.g. for Jirků (Q50308708), the normal female version is identical, Jirků, however, there are women who use Jirkůová). And, this also means the shared-item scheme has a similar drawback for less known persons: you might have an item about e.g. “Jarmila Blažková”, but without other information, you just don’t know if the family name is Blažek, Blažko, etc.
And… to be honest… the choice depends on the use cases for the properties, which I’m not really sure what they are.
--Mormegil (talk) 09:01, 12 January 2021 (UTC)[reply]
Another problem with the first model is, that there are (and will be) trigger-happy bots on hunt for people without surname statement. They won't care about verifiable sources and will fill in the missing piece of information using random choice, or maybe some “heuristical” method: e.g., they will add a family name (P734)Suk (Q20998030) statement for any unspecified Ms Suková, claiming that “Suk” is certainly more common surname than “Suka”. Some of them may even check this assumption in statistics but better don't count on it.
The second scheme is less prone to this kind of corruption since the bot (or even the human editor) is not forced to lie about knowing the male form while adding a surname statement to a woman's item. But as you pointed, the missing link to the male form will be still percieved as a problem and sooner or later somebody will introduce some way to fill it in (via a qualifier, maybe). And then we have the aforementioned army of trigger-happy bots here again. In this case though, it wouldn't be an intrinsic problem of the data model, it's just that people expect Wikidata to content even data that are not available in the real world.--Shlomo (talk) 21:32, 14 January 2021 (UTC)[reply]
Oh, don’t be that optimistic about trigger-happy bots, they are happy to say such things like Zuzana Dobiašová (Q81902636)given name (P735)Žužana (Q12808063), nothing will stop them in any model.
I don’t have a real solution. The most thorough solution would be to have multiple instances of “Blažková”, each with a different value of surname for other gender (P5278). Plus possibly one more with unknown value there for those people we just don’t know. That would be a “correct” model, IMHO, but it is a lot of work with doubtful benefit. I guess I was primarily just objecting to the “we should stick to one of these schemes and do not mix them up and make no exceptions” statement which took quite a simplistic view of the reality…
--Mormegil (talk) 09:05, 15 January 2021 (UTC)[reply]

BorkedBot non-valid additions

User:BrokenSegue's bot BorkedBot has been non-validly adding (&limit=2500) social media followers (P8687) as sole statement to person's items filling data with number of followers – right for Twitter accounts. It is biased (maybe very biased) addition and should be reverted (by bot, there is a lot of pages, if possible earlier because following edits can prevent undo). --5.43.83.177 23:40, 7 January 2021 (UTC)[reply]

Addition: Instead of this, diffs should look like this (for the item I gave as example, that number was duplicated by adding it in a wrong place, as a statement; only change that can be useful there is to give number of followers/subscribers with social media followers (P8687) instead of number of subscribers (P3744) but that can be other bot task as broader-meaning P3744 is used widely too accompanied with point in time (P585) for social media services beside other website services such as databases as I know). --5.43.83.177 23:54, 7 January 2021 (UTC)[reply]

With all due respect, you are mistaken. that way of adding this data is no longer best practice. BrokenSegue (talk) 00:01, 8 January 2021 (UTC) (sorry for being so harsh but you could've privately messaged me and I would've explained your confusion but you choose this venue instead BrokenSegue (talk))[reply]
@BrokenSegue: You got "approval" (not from me, so that is not kind of approval at all but 'partial consensus' if that exists) for "Task/s: Populate meta-data/qualifiers for entities with Twitter username (P2002) and YouTube channel ID (P2397). Qualifiers I will populate include: number of subscribers (P3744), Twitter user numeric ID (P6552), start time (P580), number of viewers/listeners (P5436) and named as (P1810).". You populated items with social media followers as Statements statement (adding Twitter numbers, which is completely arbitrary [why not add Facebook, then YouTube, then Twitter, then other social media followers numbers then in that statement qualifiers], plus controversial because Twitter was used for allegedly, effectively or not, bot-campaigning US politicians [one reason why it is biased, aside from obvious inconsistency, and you weirdly say "that way of adding this data is no longer best practice.") instead of adding it as qualifier to Identifiers statement (what's usual use of that property and what was intended task, as you said: "... Qualifiers I will populate include..."). Regarding User:Trade's comment on the page Rfp you cited, "Regarding Twitter: named as > Twitter user numeric ID > number of subscribers > start time > has quality > point in time. [...]", I think it was better to arrange them Twitter user numeric ID > start time > named as > number of subscribers [or social media followers, which one to choose is question also for YouTube which obviously has or should have followers but website itself cites 'subscribers' for channels even if it's free] > point in time > has quality. Point in time should follow qualifier it can be applied to (number stats). --5.43.83.177 00:21, 8 January 2021 (UTC) [e][reply]
please read the full conversation in the request for permission and remember that the policy states that "Bots must stay within reasonable bounds of their approved tasks. The general guideline is to use common sense, and if in doubt, file another request for approval" which this falls under regardless. It is not my fault you did not participate in the request for permission discussion. We cannot store multiple number of subscriber counts using the method you describe which is the point of the new property. Also I have no idea what "plus controversial because Twitter was used for allegedly, effectively or not, bot-campaigning US politicians" has to do with anything involving this work. I intend to do the same thing for the other social networks later but we have the best coverage for twitter at the moment. It seems like you have an axe to grind that has nothing to do with me. BrokenSegue (talk) 00:30, 8 January 2021 (UTC)[reply]
No need to read the full conversation if you are doing both wrong and outside of your task. I do not want to bite you but say that these need to be reverted; bounds of tasks (e.g. possible coverage, number of qualifiers operated) is not same as wrong-way adding properties (in this case, properties as statements instead of as qualifiers of Identifier statements). You might have used sense but it is still wrong, and not falling under that request (your bot's contribution seemed good until 2021 started, changing youtube qualifier number statistics can be compared to what needs to be done with Twitter qualifiers, it's basically same). It's false argument; it is not your fault, true, but consensus is still invalid unless everyone participated (if we want consensus and not foolish show-off terms). It is old property and should works same as for YouTube channel (as done in these edits); everything can be stored. It could be related to recent contributions of BorkedBot because you did not stop to see discussion outcome but are still adding it wrong way, in the midst of problems in the US. Do not do that for other social networks because these changes will be reverted; that falls under Identifiers statements' qualifiers, why would you duplicate it (instead, number of subscribers should be changed to social media followers as Twitter username's (P2002) qualifier). Who 'we'? Wikidata is not made for coverage but for having structured data in one place. I simply don't see birth date or birth place statement comparable to social media followers as statement. --5.43.83.177 01:24, 8 January 2021 (UTC)[reply]
I cannot follow what you are saying (appears we have a language barrier). Nothing about "problems in the US" has anything to do with anything. You don't seem to get that the old way of doing this had limitations and so a new way was introduced which is what I'm following. You are simply mistaken about "number of subscribers should be changed to social media followers". I'm unsure why you are so confident you are right when you appear to have limited experience here. Please wait for more people (with experience in this area) to weigh in before saying things you might regret. BrokenSegue (talk) 01:43, 8 January 2021 (UTC)[reply]
@ChristianKl: I don't want to comment this that way. Why is registered account or comment with signature more valued? --5.43.83.177 23:55, 9 January 2021 (UTC)[reply]
@5.43.83.177: registered accounts have stable identity and as such can be trusted based on previous behavior. Nonregistered accounts that raise issues against registered account might be nonregistered because of a desire to avoid accountability. ChristianKl ❪✉❫ 12:12, 10 January 2021 (UTC)[reply]
Please stop the Bot at once. The Twitter Followers are already present in the objects, so the bot is adding qualifiers that the object already has. It would be tedious to revert all edits by this bot regarding Twitte by hand. Sigh. --Gereon K. (talk) 13:56, 8 January 2021 (UTC)[reply]
@Gereon K.: if consensus were reached to revert I would revert it all with my bot. So no worry about tedium. I do not expect that to happen as it is doing the right thing and people are just confused. BrokenSegue (talk) 15:05, 8 January 2021 (UTC)[reply]
You are not even able to explain why would that be right. It is expected from your side to stop doing that action (if not to revert what's already done, just because you want more proofs even if it is obvious) until its described positively or negatively in a conclusion... --5.43.83.177 23:55, 9 January 2021 (UTC)[reply]
I'm sorry. I can't fully make out what you are trying to say here. I am not going to stop a bot because one anonymous user has a problem with it. If consensus is reached that this is a mistaken I will undo it all. There is no rush to act. BrokenSegue (talk) 00:43, 10 January 2021 (UTC)[reply]
  • The bot's approach is actually consistent with the data model we chose. The previously favored approach was to add the same Twitter ID multiple times, but that didn't really work out. --- Jura 15:01, 8 January 2021 (UTC)[reply]
Could you explain how it's consistent and what's that 'data model' (I don't see that first of two sections, Statements in Statements and Identifiers, is free to define in it just any description one finds – especially when it is unpopular or controversial, and in this case it's actually inconsistent because there is not only one social media to define its followers [property is named 'social media followers'; cannot be compared to instance of, sex or gender, date of birth, official website etc. that require one value nor occupation, educated at, genre etc. that require one or more values as it other way implicates more values])? Your next sentence is unclear and might be contrary to previous one, so needs explanation. --5.43.83.177 23:55, 9 January 2021 (UTC)[reply]
"especially when it is unpopular or controversial". It isn't, and it isn't. hth. --Tagishsimon (talk) 23:58, 9 January 2021 (UTC)[reply]
It's clear that Twitter is rubbish, unused and nonsense website, so it is unpopular. It is controversial because bases itself on hashtagging instead of content (in difference to Facebook, Instagram, YouTube etc. which have applicable and normal flow use). I don't know what's current purpose of which but the latter mentioned sites are at least with supposed applicable usage. --5.43.83.177 00:14, 10 January 2021 (UTC)[reply]
You are making a ton of unrelated claims to support your position all of which are wrong. Twitter is popular in many countries and is widely used by important figures. Hashtags are not unique to twitter. There is no intent to favor twitter here as I intend to do this for e.g. youtube later. Even if twitter were totally terrible we already store follower counts but in a schema that is problematic. All I am doing is moving the data to a new schema. I do not see how this hurts wikidata at all. I'm guessing english is not your native language so you may not realize this but you are coming across as slightly unhinged. I will not reply to you further unless someone else steps forward to oppose the bot. BrokenSegue (talk) 00:40, 10 January 2021 (UTC)[reply]
I should have read this thread bottom-up, because that "Twitter is rubbish, unused and nonsense" comment makes it really easy to dismiss this complaint.--Matthias Winkelmann (talk) 01:12, 10 January 2021 (UTC)[reply]
And that would be both ordinary mistake and logical error. --Ageuser (talk) 21:02, 10 January 2021 (UTC)[reply]

I'm tired of reverting or formatting all pages but you now have task to format that statement like this or it is not valid or consistent and thus needs to be reverted sooner or later to get desired format. Those websites are ordered: first useful and normal Facebook (which does not have publicly available [since recent times] followers or subscribers so can be omitted in the discussion), second (as unneeded also-as-Twitter:-rubish Facebook's limpet) Instagram (which disables access to its website but numbers can be get via archiving URL in https://archive.is/), third YouTube (which also some way hides numbers by not giving full number but thousands precision), [...], and Twitter (which hides day in the date of account creation) as last. --Ageuser (talk) 21:02, 10 January 2021 (UTC) [e][reply]

Ageuser, it would be helpful if you knew what you were doing. You do not. Reordering statements on an item - which is what I understand you to be doing here - is just nonsense. For a set of statements on social media audience, it does not matter, at all, what order the statements are presented in. I really cannot even put into words just how unnecessary and futile your action is. You have been here fpr 5 minutes. Please take it from those who have been here every day for years that you are not helping. In very short: items are a collection of statements. They are mainly designed to be discovered via reports of one sort or another. The presentation order of statements through the manual edit user interface is a matter of little or no moment; especially where the preferred order you specify has no relation to anything beyond your own preference. --Tagishsimon (talk) 21:13, 10 January 2021 (UTC)[reply]
I will arrange them for myself however I want; currently I like to follow present everything-cleaned-up style. --Ageuser (talk) 01:08, 11 January 2021 (UTC)[reply]
@Ageuser: Reverting is a waste of time. My bot can edit much faster than you can revert and will redo whatever you revert. There is no need to "reorder" things as wikidata has no concept of "order". Also you are clearly evading a ban so I will notify WD:AN promptly. It didn't have to end this way. BrokenSegue (talk) 21:14, 10 January 2021 (UTC)[reply]
You obviously want then your edit as last and don't want to cooperate.
I disagree with that about ordering.
We are alive so be happy!
--Ageuser (talk) 01:08, 11 January 2021 (UTC)[reply]

I am not sure if there is a consensus to record in items social media followers numbers of multiple social networks on a regular basis, as it requires a huge number of edits, which is evident from the number of edits of BorkedBot. For example in the case of weather data, there is consensus to use Commons tabular data (see for weather history (P4150)). --Jklamo (talk) 10:48, 11 January 2021 (UTC)[reply]

@Jklamo: this is a legitimate concern. I personally think there is value in having the data searchable via SPARQL. Plus we were already storing this data just in a worse format. If we record the data annually then we're talking about 260k updates per year for twitter (the rest are lower volume). The works out to about 0.1% of all edits in a year. However, I would also be willing to compromise and only add social media data for accounts with lots of followers. Currently I only add data for accounts with >1k followers but that could be 10k or 50k. That would massively reduce the edit volume and preserve much of the value. BrokenSegue (talk) 14:49, 11 January 2021 (UTC) The 50k limit reduces the number of edits by 75%, 10k halves it and in my opinion both preserve most of the value. BrokenSegue (talk) 14:59, 11 January 2021 (UTC)[reply]

Prohibiting batches for P5034

Hello. Is it possible to prohibit the batches or scripts that are running for National Library of Korea ID (P5034)? It will take years or decades till all the wrong IDs that were added get corrected by a human. Apparently, after the National Library of Korea ID (P5034) were then added, a bot runs and then also adds the wrong VIAF-ID based on the wrong Korean Library ID. --Christian140 (talk) 08:42, 8 January 2021 (UTC)[reply]

  • Did you try talking to the bot owner? ChristianKl ❪✉❫ 11:40, 8 January 2021 (UTC)[reply]
  • If there is a bot that adds incorrect data, please ask its operator to stop it and repair. If it's still running and you don't receive any response, contact a bureaucrat or an administrator to have it blocked.
If some or all data should be deleted, you might want to ask at Wikidata:Bot requests. --- Jura 11:41, 8 January 2021 (UTC)[reply]
I don't even know where those batches come from. I only always see them in the version history. --Christian140 (talk) 05:26, 9 January 2021 (UTC)[reply]
Just check the history for the account who added them. From statistics, it appears that some 26k values were added around November 27, 2020. --- Jura 07:59, 9 January 2021 (UTC)[reply]
Wow. Immediately 26k. Might have been better to test the batches before with a small number instead of going all in immediately. Wouldn't be surprised if more than 25k of these are wrong. If three people would check ten objects each day, it would take 2.4 years to have verified all. So, how can we prevent another disaster like this? --Christian140 (talk) 12:42, 9 January 2021 (UTC)[reply]
@Epìdosis: might know more about it [4]. --- Jura 12:53, 9 January 2021 (UTC)[reply]

If there are no objections, I would move this discussion to Property talk:P5034. The sequence of the facts is:

  1. November 2019: addition of about 570k VIAF ID (P214) through QuickStatements by @Bargioni: (see Property talk:P214#Recent synchronisation), in all cases in which VIAF linked to Wikidata
  2. November 2020: upload by me in collaboration with Bargioni of four Mix'n'match catalogs for NLK (3992, 3993, 3994, 3995)
  3. November/December 2020: Mix'n'match makes automatic matches on the basis of date of birth (P569)/date of death (P570) and on the basis of VIAF ID (P214) and ISNI (P213); different users, mainly me, have then synchronised Mix'n'match with Wikidata, importing these (about 40-50k) automatic matches from Mix'n'match to Wikidata through QuickStatements

It is plainly sure that in the above process a significant number of errors has been imported, in two phases, from VIAF (which is the main responsible) to Wikidata. I'm particularly suspicious about items in which

  1. the only external IDs are VIAF ID (P214)+National Library of Korea ID (P5034): these 1081 as of now
  2. the only external IDs are VIAF ID (P214)+National Library of Korea ID (P5034)+ISNI (P213): 93 as of now
  3. the only external IDs are VIAF ID (P214)+National Library of Korea ID (P5034)+another external-id different from ISNI (P213): 2446 as of now

I tend to think that the percentage of error outside these items should be very low. Regarding the above 3.5k items, I'm not sure a bot-removal of VIAF ID (P214) and National Library of Korea ID (P5034) would be the best solution, since it may affect the identifiability of the subject - manual check is probably a better solution. When you remove NLK, please be sure to remove the match also on Mix'n'match (enable User:Magnus Manske/mixnmatch gadget.js in your common.js), otherwise some user may reinsert the wrong values from Mix'n'match in good faith. I'm ready to discuss further ways to clean the errors. --Epìdosis 13:35, 9 January 2021 (UTC)[reply]

  • If some subsets of statements are found to be incorrect, these should be deleted or deprecated by bot. One shouldn't leave it for other contributors to fix manually. --- Jura 09:11, 11 January 2021 (UTC)[reply]
    @Jura1: I agree, but my statement about the incorrectness of the items resulting from the above queries is purely hypothetical, I'm not able to verify them and I would tend not to remove possibly correct data as a precaution; I could also think about VIAF doing a good job, until some systematic verification is done. If a Korean-speaking user verifies i.e. 20 items resulting from query 1 and affirms that VIAF ID (P214) and National Library of Korea ID (P5034) are both wrong in 15 cases or more, I've no problem in removing the properties from all the 1081 items; same for query 2 and query 3. --Epìdosis 14:25, 11 January 2021 (UTC) P.S. Removing all the VIAF ID (P214) and National Library of Korea ID (P5034) has the problem that, leaving the incorrect match between NLK entry on Mix'n'match and the Wikidata item from which the wrong NLK was removed, the NLK will probably be reinserted sooner or later from MnM and than VIAF will be added on its basis. Mix'n'match should have a system of batch-removing incorrect matches, which is at the moment absent. --Epìdosis 14:29, 11 January 2021 (UTC)[reply]
I don't get the argument why objects should be looked into where the only external IDs are VIAF, ISNI and Korean library number. I usually add those three to objects, so, also the first that comes when doing the SPARQL query was added by me. I would rather look into everything that was added through batches. I went to maybe the first 15 of these 1081 and Q12172968, Kang Ghil-boo (Q12582750), Q12582880, Q12583170. --Christian140 (talk) 16:48, 16 January 2021 (UTC)[reply]

Property for redirects after deprecated rank of official website (P856)

On this item Google Photos (Q20007086) the official website (P856)(URL) links to photos.google.com but when I visit that website it redirects to www.google.com/photos/about. I'd like to add a deprecated rank to photos.google.com and add the reason that it redirects to another URL. Is there a property for redirects that websites do? LotsofTheories (talk) 03:00, 9 January 2021 (UTC)[reply]

@LotsofTheories: deprecating it is actually the wrong thing to do. assuming the URL was correct at some point instead add an end time (P582). see Help:Deprecation for more details. BrokenSegue (talk) 05:15, 9 January 2021 (UTC)[reply]
The URL stays the same when signed in, otherwise it redirects. Also redirects are not always deprecated, the purpose of a redirect can be to provide a more stable or easier to remember URL. Peter James (talk) 15:47, 9 January 2021 (UTC)[reply]

Comment – Leave it as is. That longer URL is variable based on cookies and other (unknown) factors. photos.google.com is the permanent URL. Senator2029 13:40, 14 January 2021 (UTC)[reply]

Merging given names

Should Tali (Q85439304), Tali (Q96652117), Tali (Q96653951) and Tali (Q96675834) be merged? They seem to be the same name, just from different languages. Or if not merged, could someone go fix the descriptions and labels, as they now are conflicting with each other? The same probably applies for Tali (Q96651126) and Tali (Q96655111), too. Kissa21782 (talk) 11:23, 9 January 2021 (UTC)[reply]

Property proposals: should they close?

Hello. In Wikidata:Property proposal/Generic there are more than 75 proposals. The discussion of some of the them started at 2019 and the last comment was 6 or 7 or 12 months ago. Why these proposals are still "under discussion"? Data Gamer play 06:52, 10 January 2021 (UTC)[reply]

  • The question is if we have a better solution to address the modeling question or not. Delay as such isn't an issue if the users are still interested. Proposals sometimes just lack sufficient interest to be implemented.
Obviously, there are a few proposals that are seen as incompatible with Wikidata's modeling or are insufficiently specified to be implemented. --- Jura 16:21, 11 January 2021 (UTC)[reply]

Abbey of Monte Cassino (Q765737, Q334051)

I think "Territorial Abbey of Mont-Cassin (Q765737)" and "Abbey of Monte Cassino (Q334051)" should be merged. There is no difference!--Utilo (talk) 10:14, 10 January 2021 (UTC)[reply]

No. Per the italian wikipedia articles (which in any event preclude the merge) one is mainly about the C6 building, the other about a regional territory of the Catholic church. Obvs there is a great deal of overlap, but equally it is possible to tease out differences. Please take a little more time to investigate properly, especially, things linked to items that you suppose should be merged. Whilst the need to merge is frequent enough that your report really did not need its final exclamation mark, sadly it is also a commonplace for users to suggest or enact merges becuse they have not troubled to look properly at the information before them. --Tagishsimon (talk) 10:43, 10 January 2021 (UTC)[reply]

Associated Wikipedia page removed. Should entry be removed too?

Crystal Lake (Q5191245) points to a water feature in a mobile home park. The associated Wikipedia page was removed. Should we remove this entity as well? Gettinwikiwidit (talk) 12:38, 10 January 2021 (UTC)[reply]

No. Why on earth would we? It satisfies Wikidata:Notability criterion 2 per the GNIS ID. --Tagishsimon (talk) 12:49, 10 January 2021 (UTC)[reply]
@Tagishsimon: I just added the GNIS ID, which actually points to the Mobile Home populated area rather than the water feature itself. Should we remove that and then delete the entity? Gettinwikiwidit (talk) 12:57, 10 January 2021 (UTC)[reply]
My inclination is still to keep the lake item; I imagine it will still satisfy criterion 2, although perhaps not via GNIS nor Geonames. It satisfies C3, the structural criterion, in that it gives its name to the settlement built around it (named after (P138)); on which subject, the GNIS ID should not be on the lake item, but on an item for the village. There's also a geonames ref - https://www.geonames.org/7193367/crystal-lake-mobile-home-park.html I think. --Tagishsimon (talk) 15:29, 10 January 2021 (UTC)[reply]
  • I changed it to the mobile home park, which is what the link is to. There is no water on Google maps or in any available satellite imagery to date, if they are going to build a lake we can always make a new entry. --RAN (talk) 05:07, 11 January 2021 (UTC)[reply]
Well. There is a lake on the ESRI image. RAN, changing an item from one thing (a lake) to another thing (a village) IS NOT HOW WIKIDATA WORKS. It is bad and damaging and wrong. Users are entitled to expect that the nature of items is consistent over time. Although it is unlikely anyone has a dependency on this specific item, as a general point, you do not know what external uses of the item have been made and are not in a position to know whether changing the item's nature will break anything. I have reverted your edit. Please do not do this ever again. --Tagishsimon (talk) 12:06, 11 January 2021 (UTC)[reply]
@Tagishsimon: This was an odd entry, which is why I brought it up here. It was originally linked to a en-wiki page which described the mobile home park but was removed (possibly because it's a commercial venture). That page was removed and left the intent of the entry unclear. Can you please explain what type of breakage you're referring to? Regards, Gettinwikiwidit (talk) 12:37, 11 January 2021 (UTC)[reply]
I take it you're saying it's better to create a new entry and possibly delete the old in this case? I can understand this, but I want to make sure I understand your point. Regards, Gettinwikiwidit (talk) 12:40, 11 January 2021 (UTC)[reply]

How to develop and deploy documentation for Q items ?

Here is a request for comments : Wikidata:Requests for comment/How should we develop and deploy documentation for items ? PAC2 (talk) 17:55, 10 January 2021 (UTC)[reply]

Wikiversity article representation in Wikidata and P31 values?

I've created a Wikidata object for a Wikiversity learning resource neurodiversity movement (Q104773840) "The Neurodiversity Movement". I considered adding an instance of Wikimedia article page (Q15138389) to that Wikidata item but seeing P31 has a none constraint for Q15138389 I'm puzzled at how to go forward with this. Even if I added P31 = "Wikiversity Learning Resource"(if I made a new Wikidata item for that) would that also be a none contraint for P31? How should I tag learning resource for P31 on Wikiversity articles so they get their Wikidata objects? Can I skip adding an instance of (P31) or subclass of (P279) altogether for Wikiversity articles and just tag them as good as I can? LotsofTheories (talk) 23:14, 10 January 2021 (UTC)[reply]

Indicating favorites

Is there any way to indicate a person's favorite color, lucky number, or similar? {{u|Sdkb}} talk 11:53, 11 January 2021 (UTC)[reply]

I hope not. --Tagishsimon (talk) 14:28, 13 January 2021 (UTC)[reply]
@Sdkb: You can state someone's favourite sports team using supported sports team (P6758) Piecesofuk (talk) 18:39, 13 January 2021 (UTC)[reply]
If someone actually use their lucky/favorite/important thing in daily life, there is Moka Akashiya (Q3860183)uses (P2283)Rosario Cross (Q63184654) and Thor (Q717588)owner of (P1830)Mjolnir (Q1401384). --Lockal (talk) 19:58, 13 January 2021 (UTC)[reply]

Wikidata weekly summary #450

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Tool of the week
    • QueryGraph is a web tool for creating queries in SPARQL from graphs.
  • Development
    • Continued working on the Query Builder. We focused on making it possible to query for Item values and being able to limit the number of Items in the result. We also looked into how to query for quantity values.
    • Changed P920’s data type from string to external identifier (phab:T269205)
    • Finished working on the problem of Items that have the page prop wikibase:statements set to 0 but actually do have statements (phab:T145712)
    • Continued work on the “Publishing” step of the Wikibase release pipeline by building and testing three components of the software suite: Wikibase (phab: T267893), Query Service frontend (phab:T268025), and Query Service backend (phab:T268022)

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.


subclass of (P279) for city districts of Tallinn (Q2864118)

  1. Territory of Estonia Administrative Division Act, Chapter 1, § 2. Administrative division of territory of Estonia is directly stated that Rural municipality districts or city districts (linnaosi) may be formed in a rural municipality or city, respectively, pursuant to the procedure provided by law;
  2. Local governments in Estonia work about administrative reform in Estonia (Q16410284) by Ministry of Finance (Q12373345) says that Local governments may form rural municipality and city districts in their territories for the decentralisation of power;
  3. Tallinn (Q1770) is divided into 8 areas with certain boundaries (city districts of Tallinn (Q2864118));
  4. These areas have their own statutes and local governments which form a hierarchy with Tallinn goverment. For example, we have clear information from the statute of Kesklinn (Q1230929) that it has own local two-branch government (Linnaosa haldusorganid: 1. Tallinna Kesklinna linnaosakogu; 2. Tallinna Kesklinna Valitsus). Also § 2 (3) says that Linnaosa täidab oma haldusterritooriumil lisaks käesolevas põhimääruses sätestatule teisi riigi ja Tallinna õigusaktides talle pandud ülesandeid (In addition to the provisions of these statutes, a district shall perform other functions assigned to it by state and Tallinn legislation in its administrative territory).

With the above in mind, what should be specified in subclass of (P279) of city districts of Tallinn (Q2864118) and can we use items like Kesklinn (Q1230929) with located in the administrative territorial entity (P131)? Сидик из ПТУ (talk) 17:40, 11 January 2021 (UTC)[reply]

city district (Q4286337) is the right subclass for either city districts of Tallinn (Q2864118) or an intermediate "city districts of Estonia" and, yes, I see no reason why located in the administrative territorial entity (P131) would not work in the way you describe. There is perhaps some confusion here because "city district" sometimes describes one of multiple suburbs within one city, and at other times describes a structure that has the same territory as a larger city, but takes at the administrative role of a rural district (or "county"), i. e. one level ''up'' from the city government.Wikidata:Administrative_territorial_entity might also be helpful --Matthias Winkelmann (talk) 01:36, 12 January 2021 (UTC)[reply]

I agree with you. The problem is that such edits are rolled back by anonymous author for several years. Сидик из ПТУ (talk) 07:40, 12 January 2021 (UTC)[reply]
  • It might be easier to use a new item for "district" in Estonia (per specific organizational meaning for (the quoted) "Rural municipality districts or city districts (linnaosi)")
    and add this where applicable. Possibly in addition to the more vague "district of Tallinn".
    As the English label of Q2864118 is "city districts of .." (note the plural), it might not even be a class, but a list or some other item about all districts. --- Jura 13:18, 12 January 2021 (UTC)[reply]
city district (Q34985575)? Now Kesklinn (Q1230929) has city district (Q34985575) at instance of (P31). Сидик из ПТУ (talk) 17:33, 12 January 2021 (UTC)[reply]
Not sure: there seems to be some back-and-forth around Q34985575. Currently it's labeled "city district", which a "rural municipality district" (from the explanation above) would probably not be, nor is it (per item's current P31 value description) a "human-geographic territorial entity". So P31 and (English) label would need some changes. --- Jura 11:30, 13 January 2021 (UTC)[reply]
So, if we want to state that Q34985575 is a "city district" from "Rural municipality districts or city districts" then it should be city district (Q4286337) in instance of (P31). Сидик из ПТУ (talk) 16:52, 13 January 2021 (UTC)[reply]

Could someone do this?

I don't know if it's the right place to ask for this, but I'd like to ask for someone to add the link to an article in Silesian Wikipedia (code: szl) titled "Zwjyrzynta" to a semi-protected page Q729. I can't do this myself. --Psiŏczek (talk) 17:46, 11 January 2021 (UTC)[reply]

publisher

What is the structured data problem with the P123(property:publisher) Q88359373(Nels)? This is simply a postcard published by 'Nels'.Smiley.toerist (talk) 23:58, 11 January 2021 (UTC)[reply]

I think it's a constraint added by Uzume recently, restricting usage to Wikibase item (Q29934200). Ghouston (talk) 00:35, 12 January 2021 (UTC)[reply]
@Ghouston, Smiley.toerist: Is this Special:Diff/1339340150/prev what you are looking for? That should fix the SDC issue with c:Special:EntityPage/M20856711. Previously there was no allowed-entity-types constraint (Q52004125), so I added one but I did not realize it was being used on Wikibase MediaInfo (Q59712033) at SDC. It was an easy enough fix. —Uzume (talk) 04:16, 12 January 2021 (UTC)[reply]
I have been adding a publisher to the SDC in postcard images in the Commons for several months. This is certainly more than one case. Everytime I encounter a postcard Commons file I add the Q192425 property. In the future bots will probably automaticaly add Q192425 and other properties (a recent one: Wikidata:Property proposal/date posted), to file s in postcard Commons categories.Smiley.toerist (talk) 11:22, 12 January 2021 (UTC)[reply]
@Smiley.toerist: I do not really understand what you are saying. postcard (Q192425) is a Wikibase item (Q29934200) not a Wikibase property (Q29934218) (both are Wikibase entities). Perhaps you mean you add statements to Wikibase MediaInfo (Q59712033) entities (SDC: structured data at Commons) claiming instance of (P31) postcard (Q192425)? You are welcome to add such statements along with others claiming publisher (P123) as well. The reason instance of (P31) did not complain when you added it to a Wikibase MediaInfo (Q59712033) is because it already had a constraint allowing it to be added to Wikibase MediaInfo (Q59712033) (look at the qualifiers on the property constraint (P2302) statements specifying allowed-entity-types constraint (Q52004125) at Property:P31#P2302). —Uzume (talk) 18:17, 12 January 2021 (UTC)[reply]
Question: File:Kasteel de “Mick”.jpg. The castle is located in 'Brasschaat'. I get an error message if I try to use the location property. Should I always set the location in the 'depicts' property? The scanned postcard itself can be located anywhere, but this is not really relevant.Smiley.toerist (talk) 12:08, 12 January 2021 (UTC)[reply]
@Smiley.toerist: Properties like location (P276) have constraints. One of the possible constraints is allowed-entity-types constraint (Q52004125). For example one can look for this at Property:P276#P2302 (you might have to scroll to find it as there are often many constraints). You can find help on that constraint at Special:MyLanguage/Help:Property constraints portal/Allowed entity types. From the help and your issue you can surmise that you want to add an item of property constraint (P2305) qualifier to the allowed-entity-types constraint (Q52004125) constraint statement with the value of Wikibase MediaInfo (Q59712033). That is what I did for publisher (P123) above and the same can be done for location (P276) removing the error when added to SDC MediaInfo items like c:Special:EntityPage/M30301411 (I refer to it by its SDC Wikibase entity name and not its Commons File name c:File:Kasteel de “Mick”.jpg since we are talking about the associated Wikibase JSON structured data and not the File wikitext description or the File contents, in this case a JPEG image). —Uzume (talk) 18:17, 12 January 2021 (UTC)[reply]
@Smiley.toerist: I added Special:Diff/1339687796/prev the constraints qualifier allowing location (P276) to be used on SDC Wikibase MediaInfo (Q59712033) rectifying your issue with c:Special:EntityPage/M30301411. —Uzume (talk) 18:25, 12 January 2021 (UTC)[reply]

Atoka Reservoir (Q19864939) the same as Atoka Reservoir (Q6474858) but have different e-wiki entries

It seems having distinct wiki entries produces a conflict on merge. Is the idea to first merge the two entries in en-wiki? Does anyone have any experience with that? Regards, Gettinwikiwidit (talk) 12:19, 12 January 2021 (UTC)[reply]

They should be merged at enwiki. Lymantria (talk) 12:27, 12 January 2021 (UTC)[reply]
@Gettinwikiwidit: Specifically, pick one of them to keep, copy any missing content from the other one, and replace the content of the other one with a #REDIRECT link - see en:Wikipedia:Redirect for details. ArthurPSmith (talk) 18:14, 12 January 2021 (UTC)[reply]
@ArthurPSmith: Thanks for the pointers. This is now done. Gettinwikiwidit (talk) 23:28, 13 January 2021 (UTC)[reply]

New dashboard for lexicographical data statistics

Hello all,

Since the middle of December, we have a new dashboard for statistics about lexicographical data on Wikidata: Wikidata Datamodel Lexemes. Similar to other dashboards (e.g. Wikidata Datamodel Statements), it collects various statistics (in this case, using a collection of SPARQL queries). The data is similar to some of the results gathered at Wikidata:Lexicographical data/Statistics, and shows the evolution of data over time.

This dashboard highlights the efforts of the editors to improve the content by adding new Lexemes, Senses and Forms (for example the recent import of Lexemes in Estonian), but also areas where improvements could be made (83% of Lexemes without Senses).

We hope you will find this useful. If you have any feedback or notice an issue, feel free to contact us on this page. Thanks, Lea Lacroix (WMDE) (talk) 12:42, 12 January 2021 (UTC)[reply]

In the telegram group we have discussed the need to reference all forms present in the lexeme namespace. Could you include a measure to capture that (forms with "stated in" or similar property)? Also having a sense with no P5137 is not useful at all, so could we have a measure for that too (senses with P5137)?--So9q (talk) 10:51, 14 January 2021 (UTC)[reply]
see also Wikidata talk:Lexicographical data#New dashboard for lexicographical data statistic. --- Jura 16:30, 14 January 2021 (UTC)[reply]

References displayed in one vertical line

Hi, the displaying of the references and of some qualifiers is sometimes really boring, more details there, although I'm not sure this is the best place there. See also this screenshot. Christian Ferrer (talk) 11:52, 13 January 2021 (UTC)[reply]

Should probably go to WD:DEV. --Matěj Suchánek (talk) 14:13, 13 January 2021 (UTC)[reply]
Ok it's done, thanks you. Christian Ferrer (talk) 14:41, 13 January 2021 (UTC)[reply]

aircraft hijacking (Q898712) and its operator (P137)

Hello, for a aircraft hijacking (Q898712), what should be operator (P137)? The airline that operate(s|d) the flight as I would have first thought or the hijackers that have "performed" the hijacking (they performed the "service" of hijacking...) ? Eg LOT Polish Airlines Flight 165 hijacking (Q1434061) / Air France Flight 8969 (Q1574009) Bouzinac 💬●✒️●💛 12:45, 13 January 2021 (UTC)[reply]

I would use perpetrator (P8031) to describe the hijackers, and operator (P137) to describe the airline. --Cavernia (talk) 08:20, 14 January 2021 (UTC)[reply]

Link hover text feature request

I can't find anywhere else where this has been suggested so I'll ask it here.

Does anyone else think that the hover text of any Wikidata Property, Item, Qualifier, link etc. should show the item description instead of its identifier?

As a new contributor, I often find myself having to click on property, qualifier, or item links for elements that I don't know, or even ones that I know, like instance of (P31) so that I can differentiate it between other extremely-similar properties like subclass of (P279).

This would of course make editing faster for anyone, since they wouldn't have to navigate between the page they want to edit, and the elements in statements that they do not know of.

Here is the current hover text of instance of (P31). I would like it to show that class of which this subject is a particular example and member instead of Property:P31.

Lectrician1 (talk) 14:57, 13 January 2021 (UTC)[reply]

Preferences > Gadgets > Descriptions. (MediaWiki:Gadget-Descriptions.js) Ayack (talk) 17:09, 13 January 2021 (UTC)[reply]

Fix typo request

I noticed that on Dagbani (Q32238), in the column language, it is wrote “dagbanli” instead of “Dagbanli”. It is possible to change? Thanks in advance!!! --2001:B07:6442:8903:1DA4:7C70:DD0B:2897 16:12, 13 January 2021 (UTC)[reply]

The French label was dagbanli so I capitalised the D for you MSGJ (talk) 16:32, 13 January 2021 (UTC)[reply]
Why did you that? I suggest to undo the change. Languages are not capitalized in French. --Dipsacus fullonum (talk) 17:23, 13 January 2021 (UTC)[reply]
Reverted. --Tagishsimon (talk) 17:25, 13 January 2021 (UTC)[reply]

Is it possible to add the calorific value of the coal burnt in a power station?

The source of energy (P618) of Kangal power station (Q85773487) is lignite (Q156267). Is it possible to add that the average combustion enthalpy (P2117) or Energy value of coal (Q5377228) of that particular lignite (Q156267) is 1100 kCal/kg please? If so how?

Reference: The owners website

When I try to add an item of property constraint (P2305) of "kilocalorie per kilogram" to combustion enthalpy (P2117) I get an error: "No match was found".

Chidgk1 (talk) 17:29, 13 January 2021 (UTC)[reply]

Perhaps energy storage capacity (P4140) - if the constraints are changed to allow kCal/kg? But on an item for the lignite burnt in that power station rather than on the power station item, I think. --Tagishsimon (talk) 17:53, 13 January 2021 (UTC)[reply]
Thanks - I am not likely to work on any coal mine items soon but if I do so in future that may be useful.Chidgk1 (talk) 06:09, 14 January 2021 (UTC)[reply]
@Tagishsimon, Chidgk1: About allowed units in general: Per property we should allow only units of compatible dimensions. For instance, combustion enthalpy (P2117) currently allows both kJ/kg and kJ/mol. This is bad because it does not allow direct comparison of values: While they are related by, say, the molar mass, it makes consumption of the property difficult in general. Moving forward, we should pay attention to this issue when proposing new properties and before allowing new units in constraints. Ideally we would try to fix existing properties. Toni 001 (talk) 11:08, 16 January 2021 (UTC)[reply]

Hi,

What is the best way to deal with an official website URL (P856) Property_talk:P856, which is now invalid?

The item in question is https://www.wikidata.org/w/index.php?title=Q2665351&oldid=733581269

Happily, archive.org got some snapshots of the URL, including:

https://web.archive.org/web/20080506045212/http://www.nec.de/hpc/software/super-ux/index.html

This is the last valid archive for the URL.


For the now invalid valid, should any of the following be set?

Also the URL appears to have been invalid when imported into Wikidata on 14 March 2017 from the Russian Wikipedia, see https://www.wikidata.org/w/index.php?title=Q2665351&oldid=466252341

Does this alter the qualifier properties that should ideally be set?

The Wikidata information is used by the https://en.wikipedia.org/wiki/Template:Infobox_OS of the page https://en.wikipedia.org/w/index.php?title=SUPER-UX&oldid=999525330 .

Thanks! --Lent (talk) 06:29, 14 January 2021 (UTC)[reply]

OK, I think I did it reasonably. Added an end time (P582) of 6 May 2008, a reference URL (P854) of https://web.archive.org/web/20080506045212/http://www.nec.de/hpc/software/super-ux/index.html with a retrieved (P813) of 15 January 2021. Anything I should still do, or should have done? See: SUPER-UX (Q2665351) . Thanks! --Lent (talk) 06:24, 15 January 2021 (UTC)[reply]

Listeriabot: request to implement

I'm posting here to ask if someone here is able to show me how to set up Listeriabot to run on a new wiki (in this case, Wikiversity; see notice). The original bot creator is typically very busy, and I don't have any bot-running expertise. Is anyone able to show me how to set it up an activate it. I'm not certain whether it's just a case of adding an extra line of code somewhere in the the github repo, or if there's more to it than that. Thanks in advance for any assistance - I'm keen to get it up and running on that site asap. T.Shafee(evo&evo) (talk) 06:36, 14 January 2021 (UTC)[reply]

Cleanup after User:GZWDers bots

Now that all bots by this user has now been blocked we have a cleanup effort to do. How do we best organize it? Create a new WikiProject Cleanup? See https://www.wikidata.org/wiki/User_talk:GZWDer#Items_with_mismatched_ORCID_and_name I'm generally in favor of deletion and reimport rather than trying to correct millions(?) of bad items/statements by hand or semi-automatic edits. WDYT?--So9q (talk) 06:45, 14 January 2021 (UTC)[reply]

  • @So9q, GZWDer: I don't think this is the same bot account that was blocked; the problem in any case is that it is too trusting of EuropePMC for ORCID id's; they occasionally mess up those assignments. The vast majority however are correct so deleting and reimporting seems unwarranted to me. If we had some way to detect the problem cases that would certainly be useful. ArthurPSmith (talk) 16:45, 14 January 2021 (UTC)[reply]
    • As a very general note, many data with varying quality are imported by different users, usually without discussion. We need to discuss good practice of data import in general.--GZWDer (talk) 17:33, 14 January 2021 (UTC)[reply]
@GZWDer: Radical idea: staging area?? It could be as simple as a "staging" property that people could FILTER out of their queries knowing that the quality is not assured. Gettinwikiwidit (talk) 02:04, 15 January 2021 (UTC)[reply]
This is similar to what is proposed in User:ChristianKl/Draft:New_Ranks#Uncertain. However every imports (by others) may have some issue (while the error rate is low, the total number may still be considerable), and it may not be easy to find out. However, a new rank does not address the issue of possible conflated entities, nor issues in labels, nor duplicated entities (this is the major issue to fix).--GZWDer (talk) 03:00, 15 January 2021 (UTC)[reply]
Also, while clean up is ongoing, we still need a guide about what are acceptable practices on new imports (i.e. even you can flag some data as need checking, how should we assure the issues are fixed eventually instead of making backlog growing without end). @Multichill: for notice.--GZWDer (talk) 03:03, 15 January 2021 (UTC)[reply]
@GZWDer: The data would presumably be "unstaged" at some point when it's been verified. Only things still tagged would be in the backlog. Maybe it would help to start the conversation with policy goals and technical goals. Should we require some sort of review on imports? Should we have some sort of easy rollback for imports? Should we have some automated reports tracking imports? Are we trying to avoid people using "suspicious" data? What balance are we looking between encouraging contributions and discouraging bad contributions? It seems the current policy is to let people do whatever until they get found out and slapped down. Gettinwikiwidit (talk) 05:06, 15 January 2021 (UTC)[reply]
The review is done by the respective WikiProject the import is touching. The problem is that importers can ignore the respective project. I'd suggest allowing imports only when importers can show they posted on a project's talk page about the import. --SCIdude (talk) 07:21, 15 January 2021 (UTC)[reply]
Yeah, I will post the dataset at such WikiProject talk page (if exists) before import, unless there are a dedicated bot approval. This may allow users to point out existing issues.--GZWDer (talk) 09:04, 15 January 2021 (UTC)[reply]
@Gettinwikiwidit: Such a topic should be discussed in a RfC; there are too many undiscussed imports by different users already.--GZWDer (talk) 09:06, 15 January 2021 (UTC)[reply]
@GZWDer: Fair enough. It's not my axe to grind. I was only trying to help. Gettinwikiwidit (talk) 09:09, 15 January 2021 (UTC)[reply]
FWIW, I think something as simple as stating "Our primary goal is to serve as a data store for Wikipedia content" would go a long way towards putting people on the same page. I'm not saying this specific goal should be the focus, but just that having a stated focus helps to orient discussions. Gettinwikiwidit (talk) 11:16, 15 January 2021 (UTC)[reply]
I totally agree, I try all the time to avoid thinking about Wikidata as THE knowledge graph of the world. It's not, its simply one of multiple spiders in the web of linked data and this particular spider has a big fat "made to interconnect WMF projects"-stamp on the back. WMF projects appear to touch most of the worlds "notable" knowledge concepts and cultural symbols so it's easy to forget. Anyone can create a Wikibase and start linking and storing their data themselves with or without a link to Wikidata. My latest idea was to have all the worlds shelters in Wikidata, it's in the scope of wikitravel, but collecting it on Wikidata first as I began doing is a really no-no I now understand. We link to other stuff. We are not the source of truth for anything.--So9q (talk) 19:45, 15 January 2021 (UTC)[reply]
Although not well defined in WD:N, the practice is we may include every knowledge with a reliable source. Maintaining a common Wikidata will make information easily searchable, quaeyable and usable by Wikipedia. Also, it may be a governance and maintanence burden if there are many Wikibase instance in Wikimedia (consider how to deal with conduct disputes - Wikidata already have inefficient procedures on this). In Wikidata:WikiCite/Roadmap, it is proposed that citation data may live in a separate namespace or a new wiki, but it is not a practice accepted by community.--GZWDer (talk) 05:01, 16 January 2021 (UTC)[reply]
I suspect this "choice" is what leads much of the effort here to resemble the Wild West. Without a common purpose, people will follow their own whims. Gettinwikiwidit (talk) 10:17, 16 January 2021 (UTC)[reply]
@Gettinwikiwidit: That's like saying that every city is like the Wild West because different people who live in the city have different goals. Part of what makes Wikidata great is that allows people with different goals to collaborate and benefit from each others efforts. ChristianKl ❪✉❫ 13:13, 16 January 2021 (UTC)[reply]
@ChristianKl: This is probably stretching the metaphor farther than is useful, but in the context of this thread it's worth noting that cities have traffic lights and parking spaces and mass transport that requires a fare. The controls are essential for the smooth interaction of people working closely together. In any event, I'm just sharing a personal opinion. Make of it what you will. Regards, Gettinwikiwidit (talk) 09:29, 17 January 2021 (UTC)[reply]

Songs in an album

What is the best way to express which songs are included in an album?
Example: The album His Hand in Mine (Q1755467) contains the songs In My Father's House Are Many Mansions (Q16996744), Milky White Way (Q6858155), Joshua Fit the Battle of Jericho (Q749116), Swing Down Sweet Chariot (Q7658557) and Mansion Over the Hilltop (Q6751756). I could then go to the album item and add the songs as has part(s) (P527), or I could go to the song items and use part of (P361). Or maybe both? Is there a better property to use? A possibility is published in (P1433) which is used to identify songs published in a songbook. Is a music album similar to a songbook? --Cavernia (talk) 08:12, 14 January 2021 (UTC)[reply]

I believe it is tracklist (P658). Jean-Fred (talk) 16:36, 14 January 2021 (UTC)[reply]
"tracklist" is correct. I updated the album with the twelve tracks in question. Moebeus (talk) 15:27, 15 January 2021 (UTC)[reply]

Help merging

Will anybody merge Q7421267 and Q32430219? I cannot solve "Error: Conflicting descriptions for language fa.". Thanks. --95.127.172.126 18:33, 14 January 2021 (UTC)[reply]

✓ Done. iXavier (talk) 18:35, 14 January 2021 (UTC)[reply]

Sorry for my ignorance

What is "LTA spam", I see it in deletion rationales, but can't find a definition. --RAN (talk) 03:58, 15 January 2021 (UTC)[reply]

"Long term abuse", I assume? AleatoryPonderings (talk) 04:06, 15 January 2021 (UTC)[reply]

Alexander Altmann

Hi, There is a big confusion being two painters: Q37846275 and Q546341. One is Ukrainian (1878-1932), the other one is Russian (1885-1950). Links to Wikipedia and Commons are jumbled, and even the Identifiers are wrong and mixed up. Help needed. Thanks, Yann (talk) 23:12, 12 January 2021 (UTC)[reply]

I fixed the links to Wikipedia and Commons. Regards, Yann (talk) 23:45, 12 January 2021 (UTC)[reply]
Moved from Administrators' noticeboard. ‐‐1997kB (talk) 05:58, 15 January 2021 (UTC)[reply]
@Yann:, they actually are the same, just different sources provide different dates. Also, Kiev Governorate was a part of Russian Empire until 1919, and Altmann left Russian Empire in 1905 (by all sources) and never returned back (which was very common for people of that time). --Lockal (talk) 16:05, 15 January 2021 (UTC)[reply]
@Lockal: The same? I could understand that there are uncertainities about the birth date, but how do you explain that one died in 1932 and the other in 1950? And that one is born in Odessa, and the other one in Kiev? [6] seems to support your claim, but we have a precise date and place of death in France: September 14th, 1932, Nemours (77). It should be easy to get the death certificate. Regards, Yann (talk) 21:11, 15 January 2021 (UTC)[reply]
@Yann: Yes, just dates are wrong. There are no contradictions about birth place (and no statements anywhere that he was born in Odessa). He was born in Sobolevka village, Kiev province (frwiki states that as "nee a Kiev", but that's just an approximation). There is a bigger article about him, which mention both 1932 and 1950 as death years. But the main evidence that that they are the same are signatures on paintings, on every source, on every auction, they are just the same no matter which period of life is mentioned. As for the question about primary source of "died in 1950" claim - I have no answers. 1932 has much stronger sources, 1950 just looks like a widely distibuted alternative value out of thin air. --Lockal (talk) 11:06, 16 January 2021 (UTC)[reply]
@Lockal: If you are sure about this, the 2 WD entries should be merged, as well as links to WP and Commons. Regards, Yann (talk) 17:40, 16 January 2021 (UTC)[reply]

How to delete someone's twitter account

I have to say I do not understand WikiData, despite being (very sporadic) Wikipedia editor for >10 years :(

This person

Steven Frank (Q7614717)

has a wrong Twitter account there. The twitter account is deactivated. I removed {{Twitter}} from his wikipedia entry, but it is still here in wikidata.

I have no clue how to remove it. Clicking on the remove icon causes failure. Uhh, what to do exactly?

--Running (talk) 07:03, 15 January 2021 (UTC)[reply]

I guess I should "deprecate" it? How? What to do? --Running (talk) 07:05, 15 January 2021 (UTC)[reply]
ok.... I did something I guess. --Running (talk) 07:24, 15 January 2021 (UTC)[reply]
@Running: there is no need to deprecate valid statements about deactivated accounts. Setting qualifier end time (P582) is enough in this case (there is also has characteristic (P1552)deactivated account (Q56631052), but this is rare). --Lockal (talk) 15:00, 15 January 2021 (UTC)[reply]
@Lockal: Well, I don’t know when did he deactivate it. So I can’t set end time. --Running (talk) 04:44, 16 January 2021 (UTC)[reply]
you can set the time to "unknown". BrokenSegue (talk) 14:41, 16 January 2021 (UTC)[reply]

online communication

I amm the parson from Tanzania - Zanzibar. I want to communicate with the stakeholder whose deal with technology. So what am suppose to do?

Why are we importing all science articles we can possibly find?

So linked to the discussion about scope of wikidata in my comment in the discussion above, what is your arguments? I have two: 1) we could need them sooner or later in Wikipedia as reference and then it's easier if they are already in Wikidata (but this accepts a truckload of bloat items that are perhaps never linked from any other WMF project which is possibly a strain on the infrastructure and/or volunteers) 2) science is the basis of knowledge in our culture, so to describe the sum of all knowledge (goal of Wikipedia, no?) needs science and references to it. Importing an article in Wikidata is only the beginning. WDYT?--So9q (talk) 20:43, 15 January 2021 (UTC)[reply]

I noticed the scope discussion. Very very odd. Scope is already established in Wikidata:Notability. Ideas such as "Our primary goal is to serve as a data store for Wikipedia content" is for the birds and shows a very profound lack of understanding/appreciation of the non-wikipedia uses of wikidata. Given WD:N, we do not need to make an argument for the inclusion of scientific papers. --Tagishsimon (talk) 20:50, 15 January 2021 (UTC)[reply]
This is the proposal of WikiCite - it powers a lot of things including [7]. This also provides information of many researchers. Adding new scientific articles will have building a database of open citations and linked bibliographic data (e.g. eventually you may easily find a PDF copy from a given PubMed ID, if it is in free license). However whether to include non-scientific articles, even those with DOI, is disputed; welcome to participate in Wikidata_talk:WikiProject_Source_MetaData#Encyclopedia_articles_and_notability.--GZWDer (talk) 23:25, 15 January 2021 (UTC)[reply]
See also Special:Diff/1342067604.--GZWDer (talk) 05:02, 16 January 2021 (UTC)[reply]
Thanks for your comment and for taking my question seriously. We have not met here in years. I recognize the tone of your comment from our previous interactions and I don't recognize it as friendly, correct? I have not heard https://en.wiktionary.org/wiki/for_the_birds before, but then again I'm not so well versed in English culture insults. We are unfortunately missing a lexeme describing the expression it seems, would you be willing to create it now that you seem to have a firm grasp of the concept? You are very welcome to import other insults and English idioms to the lexeme namespace e.g. from Wiktionary to help out (if you know Javascript you can adapt this botcode).
Anyway, you did not clarify why all the millions of scientific papers are in scope, I'm guessing you mean they fill a structural need WD:N 3)? I'm guessing 3) because 1) mentions sitelinks and most science papers are missing that and 2) says "It refers to an instance of a clearly identifiable conceptual or material entity. The entity must be notable, in the sense that it can be described using serious and publicly available references." which is pretty broad and vague (which of course could very much be the reason why I and others have a little trouble understanding what we agreed should be included and what should be excluded).
I don't think every single science paper and book ever written is notable, do you? If the community agree with you I suggest we clarify that in WD:N and clean up the science objects immediately.
I would prefer if we could link to other places where all the science papers we need are, e.g. I don't see why Elsevier and other big journal corporations could not provide a SPARQL endpoint we can federate with, have you or anyone else asked them?
We could even have a selected import of only science papers that are currently used in WP (unfortunately no Wikibase or similar source of truth linked data hub with the worlds science papers exist yet and WD is far from complete and full of errors because of low quality imports by bots if I understood correctly).
This is stated in WikiCite: "The idea is curate the collection of citations in Wikidata, or perhaps in local instances of the Wikibase platform at particular institutions. To the extent that Wikidata has capacity and data is compatible, then information is in Wikidata."
So it's not clear at all that Wikidata is the place for all the articles and books in the world. I suggest we contemplate how to best move forward. What we have now is an incomplete mess (for example when I search Swedish science articles in Wikidata:Scholia I find nothing, no authors, no articles and we cannot import from the Swedish universities because they don't publish metadata as CC0 (I asked them to release it but they answered that they mix in proprietary Elsevier metadata into their stream without marking it up so they can't release it, also the Swedish Royal Library are collecting (in SwePub) but not publishing this data under a suitable license for the same reason apparently). So maybe we should create a Wikibase to hold all the metadata that has not yet been released properly? That metadata database could be populated by many sources and not have the same license related problems as Wikidata.
According to https://www.wikidata.org/wiki/Special:MostLinkedPages we now have 23 mio. science articles out of a total of around 95 mio. on SciHub (that's only 24%). That is only the digitized ones, there are many older articles missing in SciHub.--So9q (talk) 11:33, 16 January 2021 (UTC)[reply]
Deletionism is bad for Wikipedia and part of the reason why Wikipedia lost editors about a long time. The idea that we should get more deletionist because someone doesn't like incomplete data seems to be problematic. While it's good when people speak in a friendly tone, you shouldn't surprised when an very unfriendly proposal to delete data in which a lot of users spent a lot of effort get strong pushback.
If there's a mix with proprietary Elsevier metadata, then you also can't publish simply publish the data in an Elsevier database. To have the data in the open you actually need to have a state of affairs where it becomes valuable for researchers to release data about their papers in CC0. Tools like Scholia help provide value. There will be a time where we have enough papers to calculate our own metric that works like the impact factor.
As far as our notability rules are concerned scientific articles are conceptual entities that are described in multiple reliable sources and thus notable. ChristianKl ❪✉❫ 13:16, 16 January 2021 (UTC)[reply]
In Wikidata_talk:WikiProject_Source_MetaData#Encyclopedia_articles_and_notability, it is concerned whether encyclopedia articles are notable. An encyclopedia article may be cited by other sources. Previously, there was a similar discussion about news articles in Wikidata:Project_chat/Archive/2020/03#Notability_of_news_articles. GZWDer (talk) 17:04, 16 January 2021 (UTC)[reply]

I think the above reaction of User:So9q to "profound lack of understanding/appreciation of the non-wikipedia uses of wikidata" shows there is a need to provide better information about these uses. Compsci students may have no problems immediately associating exciting AI research and its vast broadness of uses but this is apparently not everyone's bread and butter. --SCIdude (talk) 08:30, 17 January 2021 (UTC)[reply]

Can we keep at least one example of an exploited entry

For example we have Q104755571 which has over 22 valid Identifiers, but they almost all have no data at the host site. I think we need to keep an example to show which Identifiers can be exploited for SEO. It can be used at a Wikidata project page to discuss which websites we point to can be exploited. For instance you can get an IMDB entry without having an credits or even being an actor. I think more editors need to be aware of what websites that can be exploited, or in this case are already exploited with empty entries. --RAN (talk) 22:31, 15 January 2021 (UTC)[reply]

I have archived it at Special:Permalink/1341920262.--GZWDer (talk) 23:20, 15 January 2021 (UTC)[reply]
Another example is Prem Raj Pushpakaran (Q61656939), though this item is notable as it is used in other items.--GZWDer (talk) 23:28, 15 January 2021 (UTC)[reply]
We generally use Wikidata property for an identifier that does not imply notability (Q62589320) on properties for identifiers where this is the case. ChristianKl ❪✉❫ 00:13, 16 January 2021 (UTC)[reply]

Find items of a wikipedia category

Is there a way to find the wikidata items (Q numbers) of articles, subcategories, templates that are included in a category in enwiki? Data Gamer play 13:21, 16 January 2021 (UTC)[reply]

yes, you might be interested in petscan which does this and more. BrokenSegue (talk) 14:14, 16 January 2021 (UTC)[reply]

Wikiversity Quiz

I've seen a lot of even fairly experienced people here get confused by the subtleties of wikidata's model. We have help pages but I thought it would be good if we had a quiz that people could take to ensure they've understood everything. I threw together a sample quiz on wikiversity about statement rank. I imagine us writing a collection of quizzes and linking them into our help documents.

I'm interested in feedback on:

  • if this is a good direction
  • if anyone found it helpful
  • if I made any errors
  • if anyone is interested in helping

Feel free to directly edit the quiz too. BrokenSegue (talk) 18:00, 16 January 2021 (UTC)[reply]

This does not show qualifiers, which in many cases are important.--GZWDer (talk) 23:01, 16 January 2021 (UTC)[reply]

Can I add the property "country of origin" in Structured commons data on files?

Like in this file, for example. Tetizeraz (talk) 21:58, 16 January 2021 (UTC)[reply]

Yes, that would be very welcome. --Tagishsimon (talk) 22:08, 16 January 2021 (UTC)[reply]
Tagishsimon I added country of origin to the linked file and there's a warning. Should I ignore it? Tetizeraz (talk) 22:19, 16 January 2021 (UTC)[reply]
IMO yes, ignore. There's no logic in constraining the use of that property to wikidata when commons items can usefully be described by it. Constraints are often wrong or not useful. --Tagishsimon (talk) 22:23, 16 January 2021 (UTC)[reply]
I've changed the constraint - diff. Warning gone. --Tagishsimon (talk) 22:25, 16 January 2021 (UTC)[reply]

Is it possible to capture bulk metadata from URLs using Zotero?

I found a discussion in the Zotero Forums and came across this code:

var path = '/home/username/Desktop/urls.txt';

var urls = Zotero.File.getContents(path).split('\n').map(url => url);

await Zotero.HTTP.processDocuments(

urls,

async function (doc) {

var translate = new Zotero.Translate.Web();

translate.setDocument(doc);

var translators = await translate.getTranslators();

if (translators.length) {

translate.setTranslator(translators[0]);

try {

await translate.translate();

return;

}

catch (e) {}

}

await ZoteroPane.addItemFromDocument(doc);

}

)

The idea is, you save the URLs you gathered in the urls.txt and Zotero parses it, adding to the library of citations you have. However, I can't choose the folder I'm saving, and when I export the saved citation to QuickStatements, I get generic metadata, like the link is a webpage, not a video recording (i'm trying to pull metadata from youtube videos, so it should be at least video recording). I'm wondering if anyone has a solution to this problem! Thanks for any help! Tetizeraz (talk) 02:28, 17 January 2021 (UTC)[reply]

Python PEPs in WD

https://www.python.org/dev/peps/ seems to be missing in WD. WDYT about importing them. How best to do it? Scrape with a bot?--So9q (talk) 07:32, 17 January 2021 (UTC)[reply]

Inflated bogus edit statistics in WD

Before we fall over ourselves in gratulation about WD contributing with 40% of all WMF edits last year I would like you to take a look at Special:MostRevisions and explain to me why these science article objects have so many edits?

Could it be that pywikibot was used to import it and it was done in a way that did not upload it once after populating the item with authors (similar to what I do in Wikidata:LexUse using wikibaseintegrator) but instead each author added resulted in one edit? If yes, what do we do about that? How does that affect our interpretation of the statistics? WD stats seem bogus to me. WDYT?--So9q (talk) 07:47, 17 January 2021 (UTC)[reply]

I wouldn't get excited about edit counts, although BayGenomics: a resource of insertional mutations in mouse embryonic stem cells (Q39790431) having 8326 versions is surprising. It doesn't seem to be authors in that case, but cell lines, added one by one with QuickStatements. Even viewing the item is difficult, but the history is accessable. Most of the others are probably articles with hundreds of authors, and the edits may just be conversions of author name string (P2093) values to author (P50). Ghouston (talk) 08:37, 17 January 2021 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=1342830358"