Wikidata:Requests for permissions/Bot/SlingWikiBot

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

 Approved--Ymblanter (talk) 20:49, 5 October 2018 (UTC)

---

SlingWikiBot

SlingWikiBot (talk • contribs • new items • new lexemes • SUL • Block log • User rights log • User rights • xtools)
Operator: Anders-sandholm (talk • contribs • logs)

Task/s: Import facts derived from Wikipedia category memberships. E.g., members of the category "1611 births" without an existing birth date would get 1611 added as date of birth (P569).

Code: On github

Function details: The bot uses pywikibot and loops over extracted facts in a record file. If the item in question already has the given property set or even if it has ever had the property set some time in the past, the fact is skipped/ignored. Otherwise, a claim is added to the item with an "inferred from" (P3452) source linking to the category that gave rise to the claim/fact.

An example of code for extracting date of birth facts is here. This code generates records for all combinations of items that are instances of human and members of a birth category. The code is leaving out an item if it already has a "date of birth" property (P569). An item is also left out if it is a member of birth categories that are conflicting, e.g. both "1670s births" and "1680s births".

100 test edits: See this list for the first handful of test edits.

--Anders-sandholm (talk) 11:27, 24 September 2018 (UTC)

Wouldn't it be better to read the date of birth from the Wikipedia page? For instance your edit is about w:Cecil Hall which bears a more exact date of birth. Lymantria (talk) 05:25, 25 September 2018 (UTC)

Thanks for the question. Yes, in the particular case of birth dates, there will be some items where reading and understanding the English Wikipedia page (if it is available) might eventually give more precise information than what can be inferred from a birth category. Once someone has the ability to (/ a bot that can) read and understand contents of Wikipedia articles and extract claims from them, it should be relatively easy to update "date of birth" property in WikiData with a more precise value, though.

An important property of the proposed approach, I think, is that information is only added where items in WikiData don't already have the property, e.g., date of birth, and only correct information is stored (assuming the category membership is correct). I.e., the state of WikiData will be more complete after running the bot than before running it. It might be that other sources/approaches over time can give more precise values to some of the properties, which can then later be updated accordingly.

The planned approach is also more general in the sense that it will apply to many more categories, e.g., for Category:Danish_male_cyclists, the approach could add claims for P21 (sex or gender) being Q6581097 (male), P27 (country of citizenship) being Q35 (Denmark), and P106 (occupation) being Q2309784 (sport cyclist) for all members of the category that don't already have these properties. --Anders-sandholm (talk) 10:20, 25 September 2018 (UTC)

It is unclear to me whether I have answered the question properly. It is also unclear to me what I need to do - if anything - in order to move forward with this process. I am happy to run/add more test edits if that is helpful. --Anders-sandholm (talk) 13:58, 4 October 2018 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

• @Anders-sandholm:. Somehow I missed this request. I'd rather not see this done for P569/P750 as we prefer to have full dates, not available through categories. Please use the relevant reports instead. --- Jura 14:14, 8 October 2018 (UTC)

I am not sure I understand the concern about adding date of birth claims now for years, decades, etc. based on category memberships. Is the concern that it won't be possible to update the claims later when a more precise value is available? I was looking through the updates and many of them didn't have more precise birth dates in the corresponding Wikipedia articles. For those that do, I would expect it to be relatively easy to make the claim more specific once there is a safe, established way to parse birth dates from Wikipedia articles. I am still relatively new to WikiData, so maybe I missed something obvious. --Anders-sandholm (talk) 09:14, 9 October 2018 (UTC)

• There are a series of reports at Wikidata:Database reports/Deaths at Wikipedia that monitor such categories at Wikipedia. We then use more suitable tools to import dates (infobox parsing or the dedicated tool for birth/death dates). The concern is not that it wont be possible, but that it isn't being done. --- Jura 09:20, 9 October 2018 (UTC)

• It seems like the similar/corresponding [scripts] for date of birth captures the case of WikiData having a less precise date than Wikipedia articles in the Report 2.1 (for both birth and death apparently). Although it seems these are not being run anymore. Ideally, it would be helpful to add missing date of birth information to Wikidata - also when some of the data points have more precise info elsewhere. I am wondering if it would be possible to extend the "Deaths at Wikipedia" script to also include items that only have "year" or lower precision in their date of death property along with the existing items that don't have a P750 property at all (similar to the "Differences in birth and death dates" scripts above). I wasn't aware of the dedicated tool for birth/death dates and wasn't able to find it with a quick online search. Would be interested in more info on that as well. --Anders-sandholm (talk) 12:47, 10 October 2018 (UTC)
• @Jura1:. FWIW, I now managed to dig out more precise dates for P569/P570 and moreover found a way to "changeTarget" for items that already have non-conflicting yet less precise dates for P569 and/or P570. See, e.g., the history of Q7529228. HTH. --Anders-sandholm (talk) 13:57, 21 December 2018 (UTC)
• I had noticed the addition of full dates. Excellent! BTW, if you use changeTarget, please make sure to not do this when the statement has a reference. The precision of the statement should match the precision in the reference on the date it was retrieved. Despite the single value constraint, it's not a problem to have several dates with varying precisions and references. --- Jura 09:05, 22 December 2018 (UTC)