Overleg Wikipedia:Wikiproject/WikidataOpWikipedia/Inwoneraantal

Woonplaatsenproject

Doel

Iedere gemeentepagina voorzien van een overzicht (lees: tabel) met daarin alle kernen en een (recent) inwoneraantal en een markering voor de hoofdplaats (kern waar het gemeentehuis staat).

Middel

Wikipedia

1. Een sjabloon/module die voor een bepaalde gemeente alle kernen verzamelt, deze in een tabel zet met bijbehorende inwoneraantallen en de hoofdplaats(en) markeert
   • Deze module zou zonder parameters moeten werken
   • Sjabloon:inwonertal wordt gebruikt voor inwoneraantallen
2. Deze module op iedere gemeentepagina zetten

Wikidata

1. Iedere plaats indelen bij een gemeente met Wikidata:Property:P131 (bij plaats) en/of Wikidata:Property:P1383 (bij gemeente)
   • Hiervoor zou organisaties.overheid.nl van pas kunnen komen ("Plaatsen binnen deze gemeente")
2. Iedere plaats voorzien van een recent inwoneraantal met Wikidata:Property:P1082
   • CBS?
3. Iedere gemeente voorzien van (een) hoofdplaats(en) (locatie gemeentehuis/bestuurscentrum) met Wikidata:Property:P1376 (bij plaats) en/of Wikidata:Property:P36 (bij gemeente)
   • Hiervoor zou organisaties.overheid.nl van pas kunnen komen ("Bezoekadres") of de website van de gemeente zelf

Voorlopig stappenplan

1. Welke property's gebruiken op Wikidata?
2. Sjabloon/module schrijven (WP.1)
3. Voor een testgemeente Wikidata (handmatig) invullen (WD.1, WD.2, WD.3)
4. Evalueren

Overleg

Stap 1 (WD)

@Dajasj, hier een eerste opzet (andere gebruikers zijn ook zeker welkom deel te nemen). Het lijkt erg op wat ik laatst stuurde op Discord, alleen wat uitgebreider. Ik denk dat het handig is om bij het begin te beginnen en te kijken welke property's gebruikt gaan worden op Wikidata. Zo zijn sommige misschien wel logisch, maar toch is het handig om dat even duidelijk te hebben.

1. Property voor inwoneraantal (was er ook niet zoiets als "belangrijkste inwoneraantal"?)
2. Property voor "ligt in gemeente x" o.i.d.
3. Property voor hoofdplaats (op gemeentepagina als "hoofdplaats" of op plaatspagina als "hoofdplaats van"?)

Ik heb geprobeerd het kort en bondig te houden, dus als dingen niet helemaal duidelijk zijn snap ik dat helemaal. Laat het gerust weten. Mvg, Ennomien (overleg) 6 jun 2022 12:23 (CEST)

Wat betreft vraag 1, op Wikidata kan je voorkeur geven aan specifieke waarden. Anders zou je de meeste recente kunnen kiezen of specificeren dat het van CBS moet zijn.

Wat betreft vraag 2, dat is Wikidata:Property:P131.

Wat betreft vraag 3, dat is Wikidata:Property:P1376. Dajasj (overleg) 6 jun 2022 17:10 (CEST)

@Démarche Modi, is dit project ook wat voor jou trouwens? Dajasj (overleg) 6 jun 2022 17:11 (CEST)

Hier al een query voor vraag 1 en 2. Nog wel wat werk te verrichten. Dajasj (overleg) 6 jun 2022 17:28 (CEST)

En query voor vraag 3. Zie hier. Dajasj (overleg) 6 jun 2022 19:47 (CEST)

@vraag 1: Het inwonertal ophalen uit Wikidata kan met het sjabloon:inwonertal.

@vraag 2: Wikidata kan ook een lijst leveren van woonplaatsen in een gemeente, mits iemand ze daar allemaal toegevoegd heeft: zie Help:Helpdesk/Archief/apr 2022#Gedachten, Vragen en Wikidata. Wikiwerner (overleg) 6 jun 2022 20:00 (CEST)

@Dajasj: Top, heb die property's erin gezet. Bij vraag 1 moeten we dus even kijken wat het handigst is: de meest recente, een waarde van het CBS, ...? Wat vind jij?

@Wikiwerner: Ik was denk ik ook wel van plan dat sjabloon te kijken. Ik kan zelf ook de broncode helemaal uitvogelen maar jij weet dit vast: geeft het sjabloon voorkeur aan bepaalde waardes (recent, CBS bijv.)? Mvg, Ennomien (overleg) 6 jun 2022 20:38 (CEST)

Dit staat ook in de sjabloonuitleg: als eerste het inwonertal dat 'preferred' is. Normaal gesproken markeert men het recentste inwonertal in Wikidata als 'preferredIs geen enkele waarde 'preferred', dan verschijnt de eerst gevonden waarde.'. Wikiwerner (overleg) 6 jun 2022 20:50 (CEST)

Dank. Die voorkeursvolgorde lijkt me ook goed dus dat is prima. Voor de volledigheid: onder welke property('s) slaan we de inwonertallen op? Ennomien (overleg) 7 jun 2022 11:47 (CEST)

Wikidata:Property:P1082 :) Dajasj (overleg) 7 jun 2022 11:55 (CEST)

Top! Ennomien (overleg) 7 jun 2022 18:14 (CEST)

Stap 2 (WP)

Nu stap 1 gereed is, kunnen we door met stap 2 en 3. :D Ik hoop vanavond bezig te gaan met de sjabloon/module. Wil jij stap 3 uitvoeren? Mvg, Ennomien (overleg) 7 jun 2022 18:14 (CEST)

Ja, al ben ik nu gewoon bezig met alles, niet voor één gemeente. Is wel een taakje wat niet 123 gedaan is. Dajasj (overleg) 7 jun 2022 18:52 (CEST)

Is ook goed! Al zou het fijn zijn dat 1 gemeente helemaal compleet is als we willen evalueren, maar dat zal vast goedkomen. Ennomien (overleg) 7 jun 2022 19:02 (CEST)

Ik durf toch voorzichtig te zeggen dat het me al bijna gelukt is de module te maken. Had het niet verwacht dat ik zover zou komen met ongeveer 2 uur werk zonder Lua-kennis. Ik hoop morgen wat meer te laten zien. :) Welterusten voor nu, groet, Ennomien (overleg) 8 jun 2022 23:34 (CEST)

De module kan nu met als input het Wikidata-object (die Q-waarde, die "automatisch" te verkrijgen is op een pagina) het volgende:

• alle kernen in een tabel zetten op aflopende volgorde van inwoneraantal
• de hoofdplaats(en) dikgedrukt maken
• niet-aanwezige inwoneraantallen vervangen door bijv. "?" en onderin neerzetten

Drie vragen voordat ik hem wil publiceren:

1. Wat is een goede naam? Module:Gemeente? (Met in het achterhoofd dat je modules meer kunt laten doen, je kunt later functies toevoegen dus "Module:Tabel inwonertal gemeente" is wat specifiek)
2. Is een optelsom van alle inwoneraantallen onderin gewenst? (Of zogenaamd optellen maar gewoon het inwoneraantal van de gemeente uit Wikidata pakken)
3. Hoe moet de bronvermelding eruitzien? Een referentie met de gebruikte CBS-pagina('s)?

Mvg, Ennomien (overleg) 10 jun 2022 09:48 (CEST)

Ad 2) Het lijkt mij dat altijd een controle van de optelsom zou moeten plaatsvinden en dat het optioneel gebruik in het sjabloon een keuze voor de sjabloongebruiker is. Indien de optelsom niet hetzelfde is als het inwonertal van de gemeente dan een error tonen (dat wikidata of cbs data gecorrigeerd zou moeten worden) en indien de optelsom klopt de waarde tonen (ongeacht welke, want die is hetzelfde), indien de sjabloon-gebruiker dat wenst.

Ad 3) Zie {Inwonertal} voor een voorbeeld. Démarche Modi (overleg) 10 jun 2022 11:07 (CEST)

2) Dat is een goed idee. Echter, dat is alleen nuttig als de data daar ook echt geschikt voor is. Als het bijv. met de goede waardes ook niet klopt is het niet echt nuttig, dan toont hij altijd een error. Ik weet niet hoe consistent de gebruikte data met elkaar is namelijk.

Wat betreft 2, ik weet helemaal niet of alle woonplaatsen optellen tot het aantal inwoners van een gemeente. Of je bijvoorbeeld binnen gemeente maar buiten de woonplaatsen kan wonen. Dajasj (overleg) 10 jun 2022 16:34 (CEST)

Ja precies. Is Purmerend een gemeente waar ik dat kan testen? Is alles daar compleet? Als het daar op hetzelfde uitkomt geldt dat mogelijk ook voor andere gemeenten, als het daar niet gelijk is dan werkt het blijkbaar niet. Ennomien (overleg) 10 jun 2022 16:37 (CEST)

Ik betrap me nu op een denkfout bij mezelf. Eerder heb ik oppervlaktedata vergeleken en ik meen mij te herinneren dat de optelsommen toen klopten. Nu deed ik even een snelle optelsom van CBS data op deze set van 2017 en constateer dat de som der wijken (79915) niet hetzelfde is als het gemeentelijke totaal (79928). Démarche Modi (overleg) 10 jun 2022 17:07 (CEST)

Ook wanneer ik naar [het bronbestand] kijk die Dajasj gebruikte voor de upload, dan kloppen de optelsommen niet.

Het inwonertal van de wijken wordt afgerond, het eindigt altijd op 0 of 5. Meestal klopt de optelsom daarom ook niet. Cattivi (overleg) 10 jun 2022 20:51 (CEST)

Is het dan een idee om een foutmarge toe te voegen? Of gewoon niet checken of het (ongeveer) overeenkomt? Ennomien (overleg) 10 jun 2022 21:00 (CEST)

@Ennomien, ja Purmerend en Groningen zijn uit mn hoofd compleet. Zo niet, dan loop ik het nog na. Dajasj (overleg) 10 jun 2022 23:02 (CEST)

3) Voor ieder inwoneraantal dus een bron in de tabelcel? Ennomien (overleg) 10 jun 2022 16:31 (CEST)

Indien een waarde steeds dezelfde bron heeft dan denk ik dat een vermelding in de kopregel volstaat. Echter, ik neem aan dat de waarde steeds door Wikidata geleverd wordt en (in theorie) zou die dus kunnen afwijken of ontbreken.Démarche Modi (overleg) 10 jun 2022 18:09 (CEST)

Ik zal betreft vraag 1 gaan voor Module:Gemeente in Nederland. Wat betreft vraag 2 en 3 ga ik gewoon bezig en kijken wat handig is. Dat kunnen we dan altijd weer veranderen natuurlijk. Ennomien (overleg) 10 jun 2022 19:46 (CEST)

Resultaat

De module is gepubliceerd, inclusief het bijbehorende sjabloon: Module:Gemeente in Nederland en Sjabloon:Tabel woonplaatsen Nederlandse gemeente. Ping naar @RonnieV en twee vragen (voor hem): kun je de code bekijken/controleren en 2) is het toegestaan stukken code van het internet te kopiëren? De drie aparte, niet heel speciale, functies zijn namelijk gekopieerd van het internet. Voor de rest: zie de module hier in werking of probeer het vooral uit op een gemeentepagina. Mvg, Ennomien (overleg) 10 jun 2022 22:19 (CEST) Edit: het werkt voor nu alleen als je zoals op mijn kladblok een ID opgeeft. Ik kijk morgen verder. Groet, Ennomien (overleg) 10 jun 2022 22:42 (CEST)

Hoi Ennomien,

Ik heb vast eens zitten kijken.

'getEntityIdForTitle' en ook 'getEntityIdForCurrentPage' kan in ieder geval alleen een resultaat geven, als de betreffende pagina ook gekoppeld is aan Wikidata. Dat is jouw kladblok waarschijnlijk niet ;) Je kan ervoor kiezen om niet de standaard foutmelding te laten verschijnen, maar de tabel weg te drukken als page_id een lege waarde blijkt te zijn. Dat kan met deze wijziging. Voor --De hoofdsteden van, kernen in en totale bevolking van de gemeente worden opgehaald uit Wikidata.

Ik heb een paar kleine dingen veranderd (aangevuld) in je code, om het resultaat te verbeteren: aanvullingen.

In je aanroepend sjabloon zou ik niet van 'gemeente_id' spreken. Ik was op zoek naar de 'CBS-code', me ondertussen afvragend of ik 'gwb_code_10' of 'gwb_code_8' zou moeten hebben, of nog iets anders. Het gaat om het Wikidata-id van de betreffende gemeente, dus 'Wikidata-id', 'WD-ID', 'WdIdGemeente',... Je kan wat je doorgeeft aan het sjabloon wel laten staan en daar onder die naam blijven gebruiken.

Zoals je vast ziet op jouw test, krijg je met 'getBestStatements' en met 'normal+' in de invoke (zie inwonertal), de waarde die als 'preferred' is aangemerkt. Dat gaat goed als altijd overal de meest recente waarde preferred zou zijn. Bij Ransdorp is er geen preferred value. Dan krijg je de eerste waarde terug die gevonden wordt, in dit geval die van 1830. Daar valt wel een mouw aan te passen, om toch de meest recente waarde te krijgen (vergt wat programmeerwerk, maar in Module:Zandbak/RonnieV/NMBS ben ik ook niet uitgegaan van de preferred value.

Dit brengt me ertoe om, met de opmerking hieronder van Dajasj over de maandelijkse cijfers voor gemeenten en de jaarlijkse cijfers voor kernen etc., voor te stellen om het iets anders op te pakken. Probeer van de gemeente niet het meest recente inwonertal te pakken, maar dat van de 1e januari van het (meest recente) jaartal waarvan je een kern-inwonertal vindt. Als de waarden per 1 januari optellen tot die van de gemeente per 1 januari, heb je geluk, dat ze gelijk zijn aan het gemeentetal per 1 april is ehhh, onverwacht. Voor dit moment heb ik een peildatum aan de uitkomst van de module toegevoegd, per meting.

Wat betreft het verschil, misschien kan je ook een extra regel toevoegen met 'buitengebied' of 'overig', waarin je het verschil aangeeft. Alleen opnemen als er daadwerkelijk een verschil is. Wellicht beter dan op iedere pagina een foutmelding genereren.

Je sorteert de uitkomst nu op het (aflopende) inwonertal. In het verleden waren de meeste vergelijkbare tabellen gesorteerd op de plaatsnaam. Heb je een goede reden voor deze wijziging?

Op Gebruiker:RonnieV/TestGemeenteTabel mis ik bijvoorbeeld Clinge. Clinge hangt wel (P131) onder Hulst, maar is niet opgenomen in de P1383 van Hulst. Idealiter zou je beide uitlezen en samenvoegen (ontdubbelen!), om zo een completer beeld te krijgen. Maar goed, we kunnen ook proberen om Wikidata completer te krijgen. Het rijtje onder Hulst (gemeente)#Kernen is in ieder geval niet gelijk aan wat ik nu te zien krijg op mijn testpagina. (O ja, het kan handig zijn om je Kladblokpagina's een logische naam te geven, er zit geen limiet op het aantal pagina's dat je aanmaakt en een benoemde pagina zal wellicht langer een nuttige link blijven (en anders herkenbaar zijn) dan een link naar je algemene Kladblok, waar je volgende maand iets heel anders hebt staan).

Wat betreft de code die je van elders haalt, het zou netjes zijn als je aangeeft waar je die vandaan hebt gehaald. Alles wat op internet staat, valt ook onder het auteursrecht, tenzij het is vrijgegeven. Maar goed, iets dat is gepubliceerd zoals op [1], is natuurlijk wel bedoeld om zelf te gebruiken. En dergelijke kleine stukjes gebruiken, is natuurlijk prima toegestaan. Idealiter geef je natuurlijk wel de credits aan de schrijver.

Na het weekend ga ik eens kijken wat je er verder van gemaakt hebt. Met vriendelijke groet, RonnieV (overleg) 11 jun 2022 01:41 (CEST)

Dankjewel! Ik zal per puntje even reageren.

1. Vandaar de optie voor het meegeven van de (ik had al iets verder gelezen) slecht genoemde parameter "gemeente_id". Ik vind een leeg resultaat wat verwarrend overkomen, ik maak daar zo even een foutmelding van (edit: gedaan).
2. Goede aanvullingen!
3. Dat zijn inderdaad betere parameternamen, ik zal een of meerdere daarvan gaan gebruiken en het onduidelijke gemeente_id weghalen (edit: gedaan). Ik moest gewoon even gauw een naam verzinnen. :)
4. Voorkeurswaarden: oh ja, @Dajasj zou als ik het goed zeg alle meest recente waarden als voorkeurswaarde markeren, of denken jullie dat het beter is om gewoon de meest recente waarde zelf op te halen? (na lezen punt 5: niet de meest recente waarde, maar die van 1 januari jongstleden).
5. Goed idee van die datums. Daar ga ik mee bezig. (edit: lijkt niet te hoeven, wordt voor gezorgd op Wikidata)
6. Ja, als de waardes zo betrouwbaar zijn kunnen we dat doen. Dat bouw ik even erin (edit: gedaan).
7. De gedachte daarachter was de belangrijkste kernen bovenaan. Als meer mensen liever sortering zien o.b.v. plaatsnaam wil ik dat uiteraard wel veranderen. @Démarche Modi, @Dajasj?
8. Oh ja, het is de bedoeling dat dat aan de Wikidata-kant opgelost wordt! Zo zijn enkele gemeenten, Purmerend en Groningen, daar al compleet gemaakt.
9. Van het kladblok: dan krijg ik zo veel pagina's, haha. Ik houd het in mijn achterhoofd maar link zelf vaak naar oldid's. In mijn bericht hierboven niet, het was laat denk ik. :)
10. Auteursrechten: beide functies in zijn geheel (en verder ook geen enkele stuk originele code) komen volgens mij van fora als Stack Overflow. Wel bedoeld om zelf te gebruiken dus, maar ik zal ze de credits geven (edit: gedaan bij eentje, de andere 2 waren niet echt originele functies). Bedankt! Mvg, Ennomien (overleg) 11 jun 2022 14:18 (CEST)

ad 7) wellicht interessant om de sjabloongebruiker de keuze te geven uit 1. sortering op plaatsnaam, 2. sortering op inwonertal en 3. de hoofdkern bovenaan te plaatsen (in combinatie met 1 en 2)

ad 8) Volledig mee eens! Toch even mijn reactie die ik niet voor me wil houden... Om omwille van de datakwaliteit functionaliteit te programmeren om de wikidata heen zou persoonlijk niet mijn voorkeur hebben. Streef een logisch en zo eenvoudig als mogelijk sjabloon/module na en pak vervolgens de wikidata aan indien er iets niet goed genoeg is. Persoonlijk zou ik juist graag de foutmelding begrijpen zodat de data op wikidata verbeterd kan worden (@RonnieV, waar ging het precies mis bij Hulst?, kan ik ontbrekende koppelingen uitvragen via de pywikibot en vervolgens corrigeren in wikidata zodat die foutmelding in de toekomst niet optreedt? En waarom een ongelukkig voorbeeld (Ransdorp) van te verbeteren wikidata gebruiken om te pleiten voor omzeilende code? Ik ben wat dat betreft blij dat je schreef: Maar goed, we kunnen ook proberen om Wikidata completer te krijgen. - Wat mij betreft dient dat het uitgangspunt te zijn (goede data zorgt voor goed en simpel gebruik)

Tot slot, op basis van mijn eerdere inspanning om prioriteit van de populatie per gemeente goed te zetten heb ik het script dat ik daarvoor gebruikte doorgetrokken naar de kernen. Ik doe dat top down (Gemeente -> Kern) en maak daar een overzicht van. Dit is relatief veel data en 'work in progress'. Het idee is om daarin op basis van de CBS-bron een controle te doen op de kernen, populatie en datum. Mede vanwege mijn geloof in Wikidata en mijn hoop dat mijn eigen inspanningen nuttig zijn hoop ik dat kwalitatieve data leidend is voor succesvol sjabloongebruik. Dan gaan quasi automatisch ook de datumnotatie en de juiste selectie van de meest recente populatiewaarde goed op basis van rank = preferred. Démarche Modi (overleg) 11 jun 2022 15:12 (CEST)

7. Dat brengt mij op een goed idee! Standaard hoofdkernen bovenaan en de rest op alfabet eronder, gebruikers kunnen met de sortering van de tabel dan op plaatsnaam en inwoneraantal sorteren. Ik denk niet dat er een optie hoeft te zijn voor de sjabloongebruiker (degene die hem toevoegt) wat de standaardsortering is, alle gemeentepagina's mogen hetzelfde lijkt mij.

8. Top! Dus jij zegt dat onvolledigheden in Wikidata niet moeten leiden tot ingewikkeldere modules? Dat is overigens een lange tabel. :D Ennomien (overleg) 11 jun 2022 15:24 (CEST)

Ja, kiss, indien het corrigeren van wikidata gegevens iets - bij de verwerking van wikidata itmes - oplost, dient dat nagestreefd te worden. Indien het euvel niet verholpen kan worden op wikidata, pas dan is een oplossing buiten wikidata, bijvoorbeeld in een module op wikipedia, de overweging waard. _{Die tabel gaat vermoedelijk langer worden, het cbs heeft 1 land aangeleverd, met 352 gemeenten, 3248 wijken en 14080 buurten (1-1-2021)... maar die gebruiken we vermoedelijk niet allemaal. Wel jeukt dit om een bot te maken... maar dat is verder off-topic ;)} Démarche Modi (overleg) 11 jun 2022 15:42 (CEST)

Ennomien (overleg) 11 jun 2022 15:45 (CEST)

Misschien mis ik hier iets hoor, maar wat zijn "hoofdkernen"? Om diverse praktische redenen zou ik voor deze tabel zeker buurten buiten scope laten. Wijken zijn in aantal nog te doen, maar komen vaak niet overeen met woonplaatsen waarover wij artikelen hebben. Dajasj (overleg) 11 jun 2022 16:05 (CEST)

O met hoofdkern bedoelen jullie de hoofdplaats. Dat is ofc prima! Dajasj (overleg) 11 jun 2022 16:09 (CEST)

Terechte opmerking @Dajasj, ik moet nog even kijken hoe ik goed ga koppelen, mogelijk op naam maar ik wil ook nog even naar BAG kijken. Vraagje: hoe weten wij welke woonplaatsen binnen een gemeente horen en hoe heb jij de inwonertallen van de woonplaatsen gevonden? Démarche Modi (overleg) 11 jun 2022 16:18 (CEST)

De link krijg je later van me, maar CBS heeft overzicht van de BAG-kernen icm gemeenten en provincie. De inwoneraantallen haal ik uit de dataset van wijken en buurten. In veel gevallen komt een woonplaats overeen met een wijk of een aantal buurten. Soms kijk ik af hoe het is ingevuld op Wikipedia, dan moet je het even navragen. Het komt er eigenlijk op neer dat je dit handmatig moet doen, niet automatisch, want het is veel maatwerk. Dajasj (overleg) 11 jun 2022 16:24 (CEST)

@RonnieV ik heb het meeste erin verwerkt, zie Speciaal:Diff/62246188. Zie ook de edits in mijn lange bericht hierboven, dat je waarschijnlijk nog niet had gelezen. In het vervolg hoop ik de module niet nog een keer zo grondig overhoop te gooien, dan blijft het wat makkelijker te volgen wat er verandert. Ik zie nu dat je mijn "Edit: het werkt voor nu alleen als je zoals op mijn kladblok een ID opgeeft. Ik kijk morgen verder." waarschijnlijk verkeerd begreep. Natuurlijk moet op mijn kladblok een ID gegeven worden, maar op een pagina mét ID werkt het ook niet. Vermoedelijk pakt hij het ID van het sjabloon dan. Edit 22:38: er zijn nu nog drie dingen open:

1. Kun je kijken naar de functie compare_rows? Zie de comment aldaar. Deze moet zorgen voor een sortering op plaatsnaam, met de hoofdkernen bovenaan (en ook op plaatsnaam gesorteerd). (18:01: opgelost)
2. Het zou ideaal zijn als het sjabloon geen input van Wikidata-ID nodig heeft. Is er een manier om dat wel werkend te krijgen? Of zit er niks anders op dan een parameter meegeven? (18:35: stomme LUA ziet een lege string niet als en:falsy, opgelost nu)
3. We moeten nog even kijken hoe we het gaan aanpakken met voorkeurswaarde, peildatum etc. Démarches en mijn voorkeur is dus het toekennen van voorkeurslabels in Wikidata zodat de module die direct kan ophalen en gebruiken.

Ennomien (overleg) 11 jun 2022 18:39 (CEST)

Stap 3 (WD)

Off-topic 

Wat betreft stap 2 van Wikidata, hier heb ik in het verleden een vraag over gesteld op Wikidata. Zie hier. Het script dat ik geschreven had om de inwonertallen van het CBS op te halen en klaar te maken voor import in Wikidata zou maandelijks gaan draaien. Dit leverde bezwaar op zoals je kunt teruglezen, maar er is ook gelijk een voorstel aangedragen. Het bezwaar is dat het een te lange lijst met P1082 statements oplevert. Het verbetervoorstel is om met twee statements te werken; één P1082 en één P4179. De P1082 is de primaire waarde die het meest recente inwonertal bevat en periodiek moet worden overschreven. De P4179 bevat een verwijzing naar Commons met een tabular population, dit is een lijst met alle historische waarden. Démarche Modi (overleg) 8 jun 2022 15:52 (CEST)

Hmm interessant. Ik snap wel waarom ze maandelijke inwonertallen wat veel vinden, maar jaarlijkse moet gewoon binnen P1082 vallen. Dus niet altijd overschrijven. Die maandelijkse kunnen dan beter binnen P4179. Ook wel benieuwd hoe je P4179 gaat doen als er meerdere bronnen zijn, zoals voor veel oudere jaren het geval is. Overigens moet men gewoon de interface van Wikidata verbeteren: per property maar drie statements laten zien (voorkeur voor preferred) en de rest uitklapbaar. Dajasj (overleg) 8 jun 2022 16:06 (CEST)

Off-topic 

Mijn eerste gedachte (toen, nog niet verwerkt) was om het gewoon jaarlijks te gaan verwerken. Dan levert het script een lijst met de inwonertallen per gemeente per 31/12 bijvoorbeeld (afhankelijk van moment van draaien script) Is dat wat jullie graag willen en kan hiervoor een pythonscript worden gebruikt? Zo ja, dan zal ik daarvoor deze week een concept aanleveren. Iemand anders dient het dan verder op te pakken voor een bot of een import in wikidata.

Jouw idee om historische statements in te klappen vind ik een mooi idee.

Wat betreft P4179, indien er meerdere bronnen zijn, dan dient dit correct in de tabel geschreven te zijn. Zie Data:Taipei Population.tab als voorbeeld. Indien daar waarden bijgeschreven worden uit een andere bron, dan kan deze daar toegevoegd worden en zou de kolom P854_source bijgewekt moeten zijn. Ironisch genoeg zien we daar gelijk een fout, de kolomnaam heeft het over S854 terwijl het property P854 betreft.

P4179 is ruim 2000 keer gevuld in Wikidata. zie hier bij current uses Mijn eerste indruk was eerst positief, echter ik heb geen concreet voorbeeld gevonden (misschien onvoldoende gezocht) Het eerste resultaat - canton of Mérignac-2 bracht me bij de franstalige wiki om uiteindelijk een handmatig gevulde template te vinden.

Het 'formele voorbeeld' op Wikidata laat niet alleen een foute kolomnaam zien, we missen mogelijk ook belangrijke data. In het franse voorbeeld zien we al iets meer datakolommen gevuld. Echter, het is daar een tamelijk technisch verhaal geworden die niet meer leesbaar is zonder de Q items te kennen (zo zou ik een import tabel maken, niet een gepubliceerde lijst). Al met al constateer ik een niet consistente aanpak van Property 4179. Verder heb ik bewust niet verder gezocht naar geschikte voorbeelden van het gebruik van P4179 en riekt de reeds aanwezige data meer naar data creatie - omdat de data beschikbaar was en het nu eenmaal kan - dan naar gewenst data gebruik en daarvoor gerealiseerd (wat mijns inziens leidend moet zijn om explosie van big data te vermijden).

Kortom, mijn (jumping to) conclusie was dat er vanuit Wikidata irritatie was omtrent ellenlange data items met veel statements zoals de populatie en dat er vervolgens voor gekozen is om deze informatie maar over de schutting van Commons te gooien. Een slecht besluit mijns inziens omdat Wikidata haar eigen rol daarmee niet vervult (de dataserver die de data liever op een andere server opslaat). Toen heb ik het maar links laten liggen (tot het nu weer ter sprake kwam). Démarche Modi (overleg) 8 jun 2022 17:30 (CEST)

Inwonertallen per gemeente heb ik nu eigenlijk al gedaan met OpenRefine (een Pythonscript is daar niet waard voor). Woonplaatsen hebben we nog hulp bij nodig, maar daarvoor is geen stabiele identifier zoals er wel gemeentecodes bestaan. Dus daarvoor moet je nog veel handwerk doen. Je kan overigens nog kijken of je "preferred rank" kan wijzigen met Python, maar dit heb ik niet kunnen vinden.

Ik volg ook je betoog over P4179. Interessanter is de opmerking "dan naar gewenst data gebruik en daarvoor gerealiseerd (wat mijns inziens leidend moet zijn om explosie van big data te vermijden)." Ik ben het daar he-le-maal mee eens. Beetje discussie buiten de scope van dit miniproject, maar we moeten gewoon steeds naar concrete usecases toe en zorgen dat die data dan tiptop in orde is, voordat we verder gaan naar het volgende. Alleen Wikidata wordt regelmatig geblokkeerd op Wikipedia waardoor die usecases niet gestart kunnen worden. Nou goed, dat weer mijn mening. Dajasj (overleg) 8 jun 2022 17:37 (CEST)

Zelf ken ik OpenRefine nog onvoldoende. Indien je volgend jaar met een druk op de knop de inwonertallen kan toevoegen dan ben ik het met je eens dat het geen Pythonscript waard is. Indien dat (veel) handwerk is, dan denk ik dat een heroverweging op zijn plaats is.

Voor woonplaatsen (Wijken en Buurten binnen een gemeente) zijn wel CBS identifiers beschikbaar:

::import pandas as pd
::import cbsodata
::WijkenEnBuurten = pd.DataFrame(cbsodata.get_meta('83765NED', 'WijkenEnBuurten'))
::WijkenEnBuurten.to_excel('wijkenenbuurten.xlsx', index=False)

Zo is bijvoorbeeld BU16800000 Annen een buurt binnen de gemeente Aa en Hunze GM1680. De vraag die nu bij mij opkomt is of Wikidata hier ook goed mee om kan gaan en er niet een 'GM' voorzet zoals ik me meen te herinneren.

Aangezien ik geen bot draai kan ik geen wijzigingen doorvoeren op Wikidata met behulp van een script. Wel kan ik desgewenst een overzicht maken met welke items de rank preferred hebben (cbs_claim.getRank() == 'preferred'). Hiervoor moet ik dan weten over welke preferred rank we precies praten. (P1082 neem ik aan) En indien de resultaten niet in de duizenden lopen dan kan ik ze wel handmatig corrigeren (dit heb ik met P382, de CBS codes, al gedaan). Démarche Modi (overleg) 8 jun 2022 18:15 (CEST)

Als iemand die zelf ook eerst begon met Python uploads, kan ik je echt OpenRefine aanbevelen, het is echt makkelijker.

Wat betreft de CBS identifier, er is geen property voor op Wikidata en wat ik begreep zijn de identifiers ook niet stabiel, ze wisselen per jaar. Dat zou ik even moeten navragen aan Wikiwerner, anders is het creëeren van property wellicht het waard.

Wat betreft preffered. Het gaat voor gemeenten al om 350 ofzo, dus handmatig is nuttig maar niet leuk. Het gaat om P1028 inderdaad. Wel benieuwd waarom je geen bot runt trouwens? Dajasj (overleg) 8 jun 2022 18:21 (CEST)

Met P1082 ga ik aan de slag. De wijzigingen in de identifiers vallen volgens mij te overzien; jaarlijks de gemeentelijke herindelingen die zorgen voor nieuwe, gecombineerde en vervallen CBS codes met daaronder de verplaatste Buurten en Wijken naar de nieuwe gemeente. Jaarlijks publiceert het CBS deze wijzigingen op GMcode niveau. https://www.cbs.nl/nl-nl/onze-diensten/methoden/classificaties/overig/gemeentelijke-indelingen-per-jaar Maar wellicht heeft Wikiwerner of iemand anders andere argumenten.

Off-topic 

En de bot mist omdat ik nog nooit de moeite heb genomen om door de aanvraag en acceptatie stappen te lopen. Heb me een klein beetje verdiept in wat de eisen (wikidata) zijn maar nog niet meer dan dat. Démarche Modi (overleg) 8 jun 2022 18:53 (CEST)

@Wikiwerner, ergens las ik van jouw hand dat de identifiers voor buurten en wijken steeds wisselen. Beperkt zich dit tot gemeentelijke herindelingen, of is het in het algemeen te instabiel? Dajasj (overleg) 8 jun 2022 18:58 (CEST)

Ik heb zelf geen idee hoe dat werkt, dus ik kon me niet voorstellen dat ik dat beweerd heb. Een zoektocht door mijn bijdragen in de Helpdesk bracht me echter als eerste hier, waar ik het inderdaad niet zelf beweer, maar citeer uit de uitleg bij het sjabloon:Statistiek kerngebieden Nederland inwoners: "CBS-codes zijn ieder jaar onderhevig aan wijzigingen. Zo had Lobith in 2017 CBS-code 01960000 en in 2018 na gemeentelijke herindeling, 029909. Om deze reden blijft dit sjabloon voorlopig naar de cijfers van 2017 verwijzen". Gek genoeg is het inwonertal van Lobith wel van 2021, gebruikmakend van de {{Infobox plaats in Nederland}}, {{Statistiek woonplaats Nederland inwoners}} en vervolgens ... {{Statistiek kerngebieden Nederland inwoners 2021}}! Ik snapte het toen al niet, en nu nog steeds niet. Wikiwerner (overleg) 8 jun 2022 20:18 (CEST)

Hmm dank voor je toelichting! Dat suggereert wel een zekere consistentie, aangezien gemeentelijke herindelingen redelijk beperkt zijn :) Dajasj (overleg) 8 jun 2022 20:23 (CEST)

Wat mogelijk nog noemenswaardig is, is dat die laatstgenoemde vervolgens een module aanroept: Module:Array_Nederland_kerngebieden_inwonertallen_2021. In deze module treffen we vervolgens een 'array' met inwonertallen en nog wat code aan (hoezo array?). Enfin, ik begrijp Wikiwerner denk ik en ik volg de logica ook niet helemaal maar kan het gebruik denk ik wel toelichten (oude sjablonen bruikbaar houden met laatste data en de titels verder gewoon negeren). Maar dat lijkt me verder off-topic.

Voor wat betreft die gemeentelijke herindelingen en (on)verwachte wijzigingen van CBS coderingen, wellicht is het de overweging waard om jaarlijks, wanneer de gegeven van het laatste jaar weer verwerkt gaan worden, een vergelijk te maken _{(kan bijvoorbeeld met pandas of beyond compare)} van de voorlaatste tabel en de nieuwe. Wat we hier namelijk lijken te missen is de metadata van deze metadata en daar kan dus niet op gestuurd worden. Die voorlaatste moet dan wel goed opgeslagen worden om misverstanden te voorkomen. De gevonden wijzigingen die dan niet gerelateerd zijn aan gemeentelijke herindelingen zijn problematisch en mogelijk kritische vragen aan het CBS (hoewel ze dat al weg-gedisclaimd hebben) en drastische maatregelen voor ons hier. Démarche Modi (overleg) 8 jun 2022 23:26 (CEST)

Ik zie zelf niet in waarom we historische data moeten bewaren. Daar gaat dit project (in eerste instantie) toch niet over? Mvg, Ennomien (overleg) 8 jun 2022 18:35 (CEST)

Is volgens mij volgens mij gewoon bredere Wikidatavraag, inderdaad niet specifiek hiervoor. Dajasj (overleg) 8 jun 2022 18:56 (CEST)

Vanuit Wikipedia's perspectief; Voor items waar de verandering door de loop de tijd beschreven en onderbouwd wordt met een tabel of grafiek denk ik dat het nuttig kan zijn. Bijvoorbeeld de groei van de inwonertallen van een groeiregio en die van een krimpregio. Vanuit Wikidata's perspectief heb ik argumenten gelezen om nooit data te verwijderen, zelfs niet foutieve data en dat hiervoor de deprecated-rank bestaat. Om achterhaalde informatie te kunnen onderbouwen en een geschikt plekje te kunnen geven. Démarche Modi (overleg) 8 jun 2022 19:02 (CEST)

Oké, bedankt beiden. Ik ben het met jullie eens hoor. Maar om toch even streng te zijn: houd deze pagina wel een beetje on-topic. :) Ennomien (overleg) 8 jun 2022 19:08 (CEST)

Zie hier een eerste analyse van de P1082 en ranking. Dit pak ik wel handmatig op voor nu. (1. KeyErrors zoveel als mogelijk eruit, 2. Rank preferred op laatste waarde (2021) en 3. re-run script om te kijken wat het opgeleverd heeft.

Dajasj, binnen de pywikibot is er ook de functie setRank(). Geen idee hoe dat in OpenRefine zit, wel weet ik dat je er ook op kan kweerieën via wikibase:rank.Démarche Modi (overleg) 9 jun 2022 09:33 (CEST)

Oe nice gevonden. Nou als je je verveelt, kun je wel botje maken om bij gemeenten de recente de voorkeursrang te geven en de rest te verlagen. Help ik wel met de aanvraag van toestemming :) Dajasj (overleg) 9 jun 2022 10:15 (CEST)

Gisteren stagneerde ik omdat iets ervoor zorgt dat de loginsessie eruit gegooid wordt... ik ga later nog een poging wagen. Indien ik al niet succesvol op test kan werken heeft het verder geen zin. Voor nu richt ik me op 'mijn task at/by hand'. Démarche Modi (overleg) 10 jun 2022 11:13 (CEST)

Iedere huidige gemeente is nu voorzien van populatie rank = preferred indien er gegevens aanwezig waren. Drie gemeenten hebben geen populatie omdat die op 1 jan 2021 nog niet bestonden. Het [Gebruiker:Démarche_Modi/Kladblok/python/controle_p1082_rank | script] dat ik hiervoor gebruik hanteert de huidige gemeentelijke indeling en CBS code als filter. Démarche Modi (overleg) 10 jun 2022 15:49 (CEST)

Dank :D Dajasj (overleg) 10 jun 2022 16:32 (CEST)

Top! Dan kan ik die voorkeurswaarde gebruiken indien het idee bij vraag 2 onder stap 2 (10 jun 2022 11:07) doorgaat. Zijn er nog geen cijfers van 2022 (zie namelijk dit)? Ennomien (overleg) 10 jun 2022 16:34 (CEST)

Het CBS publiceert maandelijks een update in deze tabel. Démarche Modi (overleg) 10 jun 2022 16:54 (CEST)

Waarom hebben die nieuwe gemeenten dan geen waardes? Die bestonden 1 jan 2022, 1 feb 2022 enz. Ennomien (overleg) 10 jun 2022 19:34 (CEST)

Omdat de data die Dajasj toegevoegd heeft over 1 jan 2021 gaat. Vermoedelijk komen de waardes van de nieuwe gemeenten in die dataset medio Q3 van dit jaar. Démarche Modi (overleg) 10 jun 2022 19:52 (CEST)

Oh, Dajasj gebruikt dus niet de data die maandelijks geüpdatet wordt? Zo ja, dan begrijp ik het. Ennomien (overleg) 10 jun 2022 19:58 (CEST)

Ja Démarche Modi (overleg) 10 jun 2022 20:04 (CEST)

De cijfers die het CBS vrijgeeft over de afgelopen maand(en), zijn voorlopige cijfers. Pas na verloop van tijd worden die definitief. Ik zou er voor de blijvende gemeenten niet voor kiezen om de voorlopige cijfers al te presenteren (om die na een paar maanden weer weg te halen en te vervangen door de definitieve). Voor een net gevormde gemeente zou ik me nog kunnen voorstellen dat we eenmalig de cijfers van net na de vorming gebruiken, met daarbij een indicatie dat het een schatting is. Met vriendelijke groet, RonnieV (overleg) 10 jun 2022 22:52 (CEST)

Nog even een belangrijke opmerking: het gaat niet alleen over gemeenten. De gegevens over de woonplaatsen zelf worden wel maar één keer per jaar gepubliceerd. Die van 2022 moet nog gepubliceerd worden zover ik zie. Dajasj (overleg) 10 jun 2022 23:00 (CEST)

Goede opmerkingen van jullie. Dan lijkt het mij handig voor de gemeentes, waar dus vaker data van bekend is, dezelfde peildatum te pakken als van de kernen. Ennomien (overleg) 11 jun 2022 13:47 (CEST)

Hey, klopt het dat jullie zorgen dat voorkeurswaarden op de goede datum staan? Dat de module daar geen rekening meer mee hoeft te houden. Ennomien (overleg) 11 jun 2022 18:22 (CEST)