User talk:Ladsgroup

From Wikidata
Jump to: navigation, search


P107 removal, P31[edit]

"claim[107:618123] and noclaim[31]" - 110000+ items. That means, they are not classified. Could you set P31=Q618123, so the items appear within "claim[31:(tree[618123][][279])]"? And delete P107 for these items. I started this task with Widar, but that is very slow. If it is done, GND will only have ~6000 items left. Andrea Shan (talk) 10:01, 18 November 2014 (UTC)

Please don't do this. The idea behind the deletion of P107 was to get more specific claims with P31. With turning P107=Q618123 to P31=Q618123 we win nothing. During the last 30 days we have replaced 80,000 claims of P107 to more specific P31 claims [1] and I'm optimistc we can continue with that. --Pasleim (talk) 10:13, 18 November 2014 (UTC)
(edit conflict)I like to do that but during our talks about migration away from P107 people decided not to do this task and start by adding a reasonable P31 from the start and remove P107 anywhere that there is P31 (I do this task once in month) Amir (talk) 10:16, 18 November 2014 (UTC)
I see no rational. For editors that work manually it is easier to change the value of a property than to create a new statement, and delete another statement. 22 000 in two days or less. That looks like a very special factor that helped to have 80 000 in 30 days. There could be more such things, but the fewer are left, the less likely it is. Ladsgroup could fix Property talk:P107#Having separate properties for controlled ontologies is silly in a day. For those people that use bots, altering instanceOf to a more specific value is very easy too. Having items without instanceOf or subClassOf, apart from "entity" is silly too. Ladsgroup could help to get more items tagged with instanceOf. People that have nothing to do with GND editing but are interested in fixing this bug, will benefit, since their list of items having this bug is reduced by 110 000 items in one day. Unbundling the two tasks
  • assigning any instanceOf and deleting P107 (within 24h)
  • improving instanceOf
allows people to do what they can do best. Andrea Shan (talk) 20:40, 18 November 2014 (UTC)

Already in P31 tree 618123[edit]

"claim[107:618123] and claim[31:(tree[618123][][279])]" ~4500 items. P107 can be removed. Andrea Shan (talk) 00:24, 19 November 2014 (UTC)

Already done by PLBotAmir (talk) 12:15, 19 November 2014 (UTC)

Replace P31=lake with P202 value[edit]

For all "claim[202]" could you copy the P202 value to P31 and remove any P31=lake if it exists? The items will still be lakes, since the P202 values are subclasses of lake, but the instanceOf values will be more specific. Depending on the outcome at Wikidata:Properties for deletion#.7B.7BPfD.7CProperty:P202.7D.7D P202 can be removed. Andrea Shan (talk) 23:08, 18 November 2014 (UTC)

I'll write a script for it tonight Amir (talk) 12:36, 19 November 2014 (UTC)
Done Amir (talk) 08:41, 20 November 2014 (UTC)
Thank you. That was of great help. Now there is no more item for https://www.wikidata.org/w/index.php?title=Special%3AWhatLinksHere&target=Property%3AP202&namespace=0 Andrea Shan (talk) 07:02, 26 November 2014 (UTC)

Creator and institution imports[edit]

Hi Amir, how is it going? Nice work on the imports. See this list and this list. You should be able to import that based on the "homecat". Do you think you're able to match some more institutions templates? See also this conversation. Multichill (talk) 19:48, 19 November 2014 (UTC)

Hey, I started importing as much as possible information from these lists, it'll be finished by tomorrow and you can see the results Amir (talk) 21:16, 19 November 2014 (UTC)
It's finished, we have to wait until next report comes out Amir (talk) 09:14, 20 November 2014 (UTC)

Copy P289 ship class to P31[edit]

  • "claim[289] and noclaim[31:(tree[11446][][279])]" - this should be zero. Copy P289 value to P31. Andrea Shan (talk) 20:59, 23 November 2014 (UTC)
Done partly, others can be done by hand Amir (talk) 21:54, 23 November 2014 (UTC)

Badge for "Nordstrand"[edit]

Thank you very much for this badge, but why did the de.voy article get it? de:Nordstrand is ranked "Brauchbarer Artikel", not "Empfohlener Artikel". -- FriedhelmW (talk) 21:21, 24 November 2014 (UTC)

Hey, These kind of articles are being marked as recommended (in English Wikivoyage, Usable articles are also marked as recommended. See interwikis). i.e. "Recommended" shouldn't be taken into account literally Amir (talk) 21:33, 24 November 2014 (UTC)
I understand. In de.voy the highest article rank is voy:de:Kategorie:Empfehlenswerte Reiseführer, which sounds like "Empfohlener Artikel" but corresponds to voy:en:Category:Star articles. -- FriedhelmW (talk) 22:04, 24 November 2014 (UTC)
The first rank pages get featured article badge, second ones get "good article" badge and third ones get "recommended article" so "Empfehlenswerte Reiseführer" should get featured article badge Amir (talk) 22:29, 24 November 2014 (UTC)

اپیزودها[edit]

سلام اینجا ربات پیوند فهرست را برای پیش از P155 و پس از P156 به آیتم اضافه کرده. مثلا این را ببین مثلا این را الان حذف کردم Yamaha5 (talk) 19:57, 25 November 2014 (UTC)

حدس می‌زنم تعداد کمی از کارهای ربات من باشه. می‌تونم یک کد بزنم که هر چیزی اوکی نبود را حذف کند (مثلا هر وقت فهرست بود) Amir (talk) 21:24, 25 November 2014 (UTC)
کد بزن که اینها تو بحث من چند مورد دیگر را هم گفتند که کار ربات تو بوده Yamaha5 (talk) 06:44, 26 November 2014 (UTC)
@Yamaha5:: این فهرست موارد مشکل‌دار. Amir (talk) 12:45, 2 December 2014 (UTC)

Dexbot error removal of P31[edit]

I think it had some server issues but I should write my code to avoid that. Sorry, Is anything fixed or more coding is needed so I'll do it. Amir (talk) 21:34, 27 November 2014 (UTC)

Wrong P31:Q5 instance of human[edit]

There are completely wrong statements from your bot - 1, 2. --Movses (talk) 10:54, 26 November 2014 (UTC)

Hi, For the first one I checked the source [2] and it was an error since the template has birth date and my bot checks it and the second one is because of having "Living people" category in the article in English WikipediaAmir (talk) 21:22, 27 November 2014 (UTC)

Commons Creator approximate dates[edit]

Hi Amir,

Can I check how your bot is handling instances of Commons c:Template:Other date in Creator templates, in particular for artists' dates of death extracted from Creator templates ?

I noticed that with Jacob van der Croos (Q18516579) (edited 20 November), c:Creator:Jacob van der Croos has {{Other date|>|1691}}, but the bot just wrote simply 1691.

Also, for Jan Baptist van der Meiren (Q16580735) (edited 8 November), c:Creator:Jan Baptist van der Meiren has {{other date|between|1736|1756}}, but the bot just wrote 1736.

It's really important to accurately reflect uncertainty in these dates of death, because they are often used to match with other databases. If Wikidata is apparently showing certainty for one date, but another database is showing certainty for a different date, this can make the match look wrong, even when it isn't.

Thanks for taking the time to have a look at this. All best, Jheald (talk) 19:00, 1 December 2014 (UTC)

Hi, Thank you for your notice, I just wrote a code to report all mistakes and probably after that I'll start removing them. Amir (talk) 21:21, 1 December 2014 (UTC)
User:Multichill: Are you okay with removing these statements? It can increase size of the reports Amir (talk) 21:26, 1 December 2014 (UTC)
Can you put the list onwiki here? How long is it? It's probably best to remove the errors and try again. Multichill (talk) 21:33, 1 December 2014 (UTC)
I checked them the list is about 700 items which birth date, death date or both of them are imported incorrectly, my suggestion is fixing them instead of removing and trying again. let me find some algorithms about the templates Amir (talk) 10:20, 2 December 2014 (UTC)

"Wikimedia categorie" => "Wikimedia-categorie"[edit]

Is it just me or is your bot still using "Wikimedia categorie" instead of "Wikimedia-categorie". Please fix it and it would be great if you can correct the current ones. Sjoerd de Bruin (talk) 21:01, 3 December 2014 (UTC)

Hey, In which language? Amir (talk) 21:48, 3 December 2014 (UTC)
Dutch (nl). Sjoerd de Bruin (talk) 21:53, 3 December 2014 (UTC)
My bot works correctly since the beginning [3] and It fixes mistakes too (it changes "Wikimedia categorie" in nl to "Wikimedia-categorie") but the script that works for new categories hadn't - and it's okay now Amir (talk) 21:58, 3 December 2014 (UTC)

Dexbot[edit]

Have done 20,000,000 edits.--GZWDer (talk) 12:14, 6 December 2014 (UTC)

You made my day :) Amir (talk) 12:18, 6 December 2014 (UTC)

And the next ~200 000 are here: "(Will be delete) type of administrative territorial entity (P132)". The bot can remove them all, but before deletion it should be checked if P31 has the same value. If not, add it to P31 first. Frank Robertson (talk) 16:40, 7 December 2014 (UTC)

Thanks. I just started the bot Amir (talk) 17:09, 7 December 2014 (UTC)
Currently there are ~30 000 that still have P132. I checked some, they all needed copying P132 to P31 first. Frank Robertson (talk) 18:34, 12 December 2014 (UTC)
It's not that simple. For start I wrote my script in a way to delete P132 in case that P132 is a superclass of one of P31. For instance: [4] since "municipality of Belgium" is superclass of "Belgian municipality with city privileges". I will make this more complicated to reduce the number as low as possible Amir (talk) 01:48, 13 December 2014 (UTC)
The superclass removal is a different operation. You could run it about all P31 claims. Here the task is just to copy and delete. I also fear that a false superclass assignment could lead to unwanted claim removal. The example you gave is a good one - You removed "municipality of Belgium" because there is "municipality of Belgium with city privileges". If there was a time when it was a municipality without that privileges then your edit was wrong. Please just copy and don't try to remove claims in knowledge domains that you don't fully understand. Frank Robertson (talk) 10:18, 13 December 2014 (UTC)
The thing is, that the class hierarchy is not trustworthy. Otherwise the superclass removal is a very good thing. I really suggest to first just copy and later create a review process for all items with more than one P31 claim. Frank Robertson (talk) 10:21, 13 December 2014 (UTC)
Implementing what you said is pretty easy but I rather like to have this discussion in a more general place to avoid unseen problems, Can you start a discussion in WD:PC? Thanks Amir (talk) 14:22, 13 December 2014 (UTC)
The discussion was at properties for deletion and the resolution was to replace with instance of. The 30 000 are blocking the deletion of P132 and on these objects certain queries may fail since the claim is not in P31. I see no reason for discussion. I think the one that sees a reason for discussion would start it. I am not a good messenger for reasons, if I don't understand the reasons. Frank Robertson (talk) 12:30, 14 December 2014 (UTC)

Metropolitan regions aren't part of the administrative region of their central town[edit]

Hey @Ladsgroup:,
your bot "Dexbot" assigned a number of German metropolitan regions as being part of the administrative region (P131) of their central towns, which is incorrect, see Cologne, Hannover, Hamburg, Stuttgart, Rhine Neckar, Berlin, Rhine Main. You might be interested in fixing the bug, so it won't produce more errors.
Regards, --PanchoS (talk) 03:14, 8 December 2014 (UTC)

Hey, thank you for letting me know. That happens because in English Wikipedia the Infobox Settlement have been incorrectly used take for instance w:Frankfurt Rhine-Main: |subdivision_type3 = Largest Cities is incorrect. I will fix it before the next run. Amir (talk) 11:23, 8 December 2014 (UTC)

Double redirect[edit]

Maybe of your interest - phab:T77971? — Revi 15:22, 9 December 2014 (UTC)

Hey, took the bug, Will be fixed soon Amir (talk) 15:30, 9 December 2014 (UTC)

P766 change to P276[edit]

(DEPRECATED) event location (P766) is up for replacement with P276 and then deletion. 4,360 items. Frank Robertson (talk) 18:44, 12 December 2014 (UTC)

My bot fixed as much as it could Amir (talk) 22:33, 12 December 2014 (UTC)
Thank you. Frank Robertson (talk) 10:18, 13 December 2014 (UTC)

Why could your bot not remove it here: Q15260073 where it is used directly as a property of the item? I manually changed it for another item where it was used in a qualifier. Frank Robertson (talk) 10:30, 13 December 2014 (UTC)

Because reference of P766 is not straightforward for bot to handle, I can make the bot work in this situation but takes a little bit time. If you think it's important, let me know Amir (talk) 14:19, 13 December 2014 (UTC)
Reference for P766 is different from reference of other properties? I think it is important to delete P766 and I think this is a work best done by a bot. On Q101751 the P766 statements have no references. Any idea why the bot did not copy them to P276? There are several more cases like this, the following examples I fixed manually:
Frank Robertson (talk) 12:40, 14 December 2014 (UTC)

Fixed and ran the bot. I think it's okay now Amir (talk) 09:10, 15 December 2014 (UTC)

Help needed with Atossa (Q5955546)[edit]

Hey Amir. I don't understand Persian but I have the feeling that the family relations on Atossa (Q5955546) are completly meesed up. As the statements were added by a bot, I'm scared that also other items are messed up. Could you check it? Thanks. --Pasleim (talk) 14:49, 17 December 2014 (UTC)

Hey, Even though I'm a native Persian speaker but understanding the text is hard for me, there are too many marriages and murders but as far as I understand the text, Atossa married both Artaxerxes II and Artaxerxes III (the former is her father!!). Name of the article in Persian Wiki is "Atossa (wife of Artaxerxes II and Artaxerxes III)". If you want I can ask one of my friends in fa.wp who is studying history of Achaemenid dynasty in university and ask him to improve these material. Amir (talk) 21:00, 17 December 2014 (UTC)
Now I'm confused about history and no longer about Wikidata claims. Thanks for investigating it. --Pasleim (talk) 08:16, 18 December 2014 (UTC)