User talk:Multichill/Archives/2019/July

Looperz

Please review this edit by User:Looperz, who, I believe, you have recently blocked, and see if further action is warranted.

The user added a start date without regard to using the correct calendar; the Gregorian calendar is obviously incorrect for an event in England in the 12th century. Jc3s5h (talk) 11:27, 10 July 2019 (UTC)

@Jc3s5h: you should first contact the user in question. If that doesn't sort it out, an admin might be needed. Can you please bring this up on Looperz's talk page? Multichill (talk) 12:54, 10 July 2019 (UTC)

@Jc3s5h: Did you know, that I corrected about 14.000 entries of that consecrator (P1598) claims? Incorrect was btw. not the claim itself but "only" the chosen qualifer. And I did not set the role intentionally wrong. I wanted to help differentiating between principal consecrator (Q18442817) and principal co-consecrator (Q18442822). For that purpose I chose a automatically proposed but incorrect qualifier. That was probably because the majority was set wrong before I started using this qualifier. In a few hours the correct qualifier will have the majority among the qualifiers used for consecrator (P1598). And I am really looking forward to having fixed not only the wrong entries but even the auto-proposal. That will happen, as soon as the auto-proposal-feature will renew its cache because of the new numbers, I expect.

I am making errors. But I also find and fix a lot of them. e.g. many many cardinal (Q45722)s are tagged as bishop (Q29182) or Catholic bishop (Q611644) just because authors of polish Wikipedia pages thought, that every cardinal is a bishop, too. When I find this errors, I look up the cardinal at a reliable source and if necessary I correct that bishop-error. So please: correct my errors, talk to me about them, stop me making them. But activating an administrator immediately, just because you found one of my errors, is imho not necessary.

--Looperz (talk) 21:47, 10 July 2019 (UTC)

Papiškės

Deze had je wellicht beter niet aan kunnen maken, want die moest al ergens aan worden geknoopt. Edoderoo (talk) 19:23, 25 July 2019 (UTC)

@Edoderoo: Je had wellicht beter een nieuw kopje kunnen starten, want dit heeft volgens mij niets met Looperz te maken.

De bot wacht een maand en als er dan nog steeds geen koppeling is gemaakt dan wordt er een nieuw item aangemaakt. Dat geeft wel eens wat dubbelingen, maar de achterstand is nooit meer dan een maand. Multichill (talk) 18:11, 27 July 2019 (UTC)

Het gaat dan wel heel erg met de Franse slag, want als er eenmaal een item is, neemt de kans zienderogen af dat iemand opmerkt dat er nog een is. Daarbij zijn er helaas maar heel weinig gebruikers die weten dat, en hoe, je twee items kunt samenvoegen. En zonder properties gevuld gaat een bot dat ook nooit opmerken. Ik heb trouwens sinds kort een script dat items aan kan maken, maar er ook wat properties aan toe kan voegen. Het script wordt er niet sneller door, maar jouw methode kan ook gewoon met PetScan (hoewel die de laatste tijd steeds vaker geen resultaten meer geeft). Edoderoo (talk) 18:27, 27 July 2019 (UTC)

@Edoderoo: Deze bot is puur een bezemwagentje zodat de achterstand niet te lang oploopt. Deze draait al jaren en heeft over het algemeen niets te doen. Op Wikidata:Database reports/without claims by site/nlwiki kan je zien welke items nog leeg zijn. Ik krijg het idee dat wellicht door vakantietijd de achterstand wat meer is opgelopen. Het nieuwe verwijderlijst systeem lijkt ook wat trager te zijn. De robot stond ingesteld op dat een pagina minimaal 28 dagen oud moet zijn en 21 dagen niet moet zijn aangeraakt, dit heb ik aangepast naar minimaal 49 dagen oud en 35 dagen niet zijn aangeraakt. Die bezemwagen moet je wel voor kunnen blijven.

Valt me trouwens op dat er op https://nl.wikipedia.org/w/index.php?title=Speciaal:OngekoppeldePaginas&limit=500&offset=500&namespace=0 wel een hoop pagina's zijn die wel een koppeling hebben. Multichill (talk) 19:17, 27 July 2019 (UTC)

Die items without sitelinks wordt al weken niet meer bijgewerkt, samen met vele andere pagina's, als de statistieken van labels, users/bots met de meeste edits, etc. Items zonder claims worden nu dus niet teruggevonden, en bij mijn weten kijken alleen Sjoerd en ik af en toe naar die lijst. Edoderoo (talk) 19:32, 27 July 2019 (UTC)

@Edoderoo: nl:Speciaal:OngekoppeldePaginas is een live pagina, geen query die zo nu en dan draait met caching. Ik heb bijvoorbeeld net een null edit op nl:Julius Nieuwland gedaan en na een reload is die van de ongekoppelde pagina's verdwenen. Ik heb een bot even null edits laten doen en de lijst is van 828 naar 569 gegaan.

De bot wacht juist een tijd zodat gebruikers de tijd hebben om te koppelen.

Wellicht om met jouw bot ook in ieder geval langer dan een dag te wachten voordat je items zoals Motherless Brooklyn (Q65939583) aanmaakt? Multichill (talk) 20:14, 27 July 2019 (UTC)

Die had moeten worden overgeslagen, omdat er zoekresultaten waren, of hij zou die aan het zoekresultaat met voldoende matchende properties moeten hangen. Ik controleer de resultaten nu nog angstvallig, maar deze is er dan toch langs geslipt. Edoderoo (talk) 07:20, 28 July 2019 (UTC)

relation inventory number (P217)/collection (P195)

Hello, you seems to be used to uses those properties, example in Q61964390. I wonder why inventory number (P217) has both things:

property constraint (P2302)→item-requires-statement constraint (Q21503247)→property (P2306)→collection (P195)

property constraint (P2302)→required qualifier constraint (Q21510856)→property (P2306)→collection (P195)

is it not redundant? or is there a specific goal? Thanks you. Christian Ferrer (talk) 12:40, 27 July 2019 (UTC)

@Christian Ferrer: every painting is in a collection (P195), but not every painting has a (known) inventory number (P217) (for example in private collection (Q768717)) . If a work of a art has an inventory number (P217), that inventory number (P217) is only valid in a certain collection (P195), so that should be the qualifier and we also want to know what collection (P195) the work of art is in. We also try to keep full provenance and works can be in multiple collections at the same time. So no, it's not redundant. See for some fun examples The Night Watch (Q219831), The Bath of Diana (Q19925859), The Prayer of Tobias and Sarah (Q28073554) & Still Life with a Ginger Pot (Q28073663). Multichill (talk) 18:20, 27 July 2019 (UTC)

• Ok thanks you for the answer. I suspected this kind of reason after asking the question. In fact I have been interested about that because it is also used in taxonomy related topics, such as in this kind of item: NHM 2011.2080 (Q54854611), items which can also have media(s) in Commons. That makes me remember that I talked to you about free databases available on GBIF, I have started to upload a dataset in several reasonable batchs, each specimens depicted has indeed an inventory number, but I have not created the corresponding items. It would be very great to have a tool to synchronize the creation of files and of the potential associated items, though each museum specimens are maybe not worth to have an item here, but some (such as holotypes) yes. Christian Ferrer (talk) 18:48, 27 July 2019 (UTC)

I am not sure we don't want all specimens, but in any case we definitely want all holotypes, so yes to inventory+collection numbers for those, which brings me to my next question, for which I am creating a new subheading. Jane023 (talk) 06:18, 29 July 2019 (UTC)

How to deal with old inventory numbers

I remember discussing this back in the day for the Rijksmuseum paintings, and I am running into the same issue for the Hermitage paintings. Currently, the old inventory numbers I have added are only visible through catalog statements from old collection catalogs, but they are not identifiable as inventory numbers at the moment. I think these should also be listed as P217 statements (and I know you have more for Rijksmuseum than just the +/- 1,000 available through Catalogus der schilderijen, miniaturen, pastels, omlijste teekeningen, enz. in het Rijks-Museum te Amsterdam (1908) (Q64667619), which is that old 1952 catalog I worked on). I need these numbers in inventory number (P217) to aid in cross referencing to RKDimages ID (P350) and others. My question is, should I just add a new P217 + P195 statement with a qualifier for "point in time=catalog publication date" or should I add this old P217 with that point in time qualifier to the P195 statement? I don't want to mess up any query possibilities moving forward. Jane023 (talk) 06:27, 29 July 2019 (UTC)

Ugh after postinng thhis I forgot I also wanted to mention the choice of collection to use in such historic P195 statements, since of course the collection is somewhat similar over time, but gets moved & merged and renamed, like Amsterdam Museum vs Rijksmuseum, which is sort of split and merged at the same time. Jane023 (talk) 06:34, 29 July 2019 (UTC)