Wikipedia:Wikidata-café/Archief/apr 2022

Tools

Vandaag heb ik Gebruiker:Edoderoo/last-xxx-no-wikidata weer net even handiger gemaakt. Met een extra link naar de duplicity-tool, kun je veel makkelijker controleren of er al een item bestaat, en deze gelijk koppelen. Deze lijst wordt nu elke 3 uur ververst, maar als er hard aan gewerkt wordt kan ik die ook wel elk uur laten lopen.

Dit is dan weer een toevoeging op de onderstaande Duplicity-links.

Wikidata ITEM/koppeling mist

NL-persoon

BE-persoon

intl-persoon

Doorverwijspagina

Lijsten

Taxonomie

NoCat

– De voorgaande bijdrage werd geplaatst door Edoderoo (overleg · bijdragen) 1 mrt 2020

Aloha Wikidata!

Zeer geachte dames en heren,

Mijn naam is Démarche Modi (overleg) en ik ben sinds kort op de hoogte van Wikidata. Hiermee kwam ik in aanraking vanwege het gebruik van sjablonen. De naam, Wikidata, had ik eerder wel voorbij zien komen, maar pas sinds kort kijk ik er concreet naar.

Van @Dajasj begrijp ik dat er geen of onvoldoende consensus is met betrekking van het gebruik van Wikidata. Tevens begrijp ik dat er weinig of geen belemmeringen zijn om de Wikidata server te gebruiken. Volgens mij hoef ik hier niet in te gaan op de voordelen...

Nadat ik in aanraking kwam met Wikidata ben ik de cli, de wikidataintegrator en de wikibaseintegrator (python) gaan bekijken. Mijn eerste indruk is dat het zeer professioneel opgezet is en dat er specifieke kennis vereist is om goed met de data om te gaan. Voorts is me opgevallen dat de kwaliteit van de data hier en daar te wensen overlaat. Gedateerd (jaren achterlopen), onvolledig (een datum notatie ala '2018'), en, ik durf het bijna niet te schrijven, wellicht niet conform de pijlers van Wikidata (informatie zonder bron(?)). Enfin, ik kom hier niet binnenvallen om direct alles af te branden. Ik hoop juist iets toe te kunnen voegen.

Vragen

1. Klopt het dat Wikipedia:WOW vooral bezig is met het ophalen van gegevens uit Wikidata naar Wikipedia?
2. Zijn er ook mensen bezig met het toevoegen van data aan Wikidata via data imports?
3. Hoe belangrijk vinden jij consensus binnen wiki-nl om Wikidata meer te gebruiken? (en wat zijn jouw verdere gedachten wat dit onderwerp betreft?)

Mijn lesstof

Op dit moment probeer ik de volgende onderwerpen beter onder de knie te krijgen.

1. Hoe selecteer en filter ik de data (neem bijvoorbeeld Q727#1082)? Het liefste zou ik dit in een Pandas Dataframe laden om verder mee te werken. Vermoedelijk lukt mij dit eerdaags, maar mocht je hier concrete voorbeelden voor hebben, dan ben ik liever lui dan moe ;)
2. Zodra ik die data heb, hoe stel ik (in python) dan onomstotelijk vast dat het de Q727 Amsterdam is die ik wil gebruiken en dat de Q478456 Amsterdam dat niet is...(in een dataframe waarin ik geen wd pageid of q-id heb) mijn eerste indruk is dat ik met een tussentabel moet gaan werken waarin ik pageid of dat q nummer laat refereren. Of moet het ook met een andere unieke sleutel kunnen, bijvoorbeeld een url redirect naar de nl-wiki waar mogelijk wel een uniek bruikbare sleutel in zit. Ja, volgens mij draaf ik nu door... pardon
3. Hoe doorloop ik de Wikidata data import? De beschrijving is redelijk te volgen en eerdaags zal ik een eerste bestand aanbieden om te ervaren hoe dat gaat.

Tot zover! Later meer. Jouw reactie en/ of vragen verwelkom ik van harte. Ook indien ik nog niet het juiste jargon gebruik...

Groet, Démarche Modi (overleg) 9 apr 2022 22:38 (CEST)

PS: ik ben afwisselend online/ beschikbaar. Démarche Modi (overleg) 9 apr 2022 22:38 (CEST)

Hoi! Leuk je zo enthousiast te zien. Wat betreft je vragen:

1. Wikipedia:WOW is vooral voor het gebruik hier inderdaad.
2. Ja die zijn er zeker veel, maar die activiteit vindt vooral op WikiData zelf plaats. Zoals ik dus :)
3. Zonder consensus moet je eigenlijk er niet aan beginnen. Vaak kun je wel wat kleine zaken doen.

Het klopt dat WikiData nog veel te wensen overlaat, maar zoals je al aangeeft, het heeft enorm veel potentie. Wikipedia is niet af, en WikiData evenmin ;) Mijn inziens is het beetje kip-ei verhaal. WikiData wordt kwalitatief beter als we het meer gebruiken op Wikipeddia, maar we gaan het pas gebruiken als het kwalitatief goedd genoeg is.

Ik stuur op een later moment wel even mijn python code die ik gebruik om een Sparql query om te zetten naar een pandas Dataframe. Het tweede probleem kun je het beste aanpakken met OpenRefine. Daarmee kun je geautomatiseerd data uit je tabel koppelen aan WikiData items, bijvoorbeeld door te specificeren dat het om een gemeente gaat. Ik kan je daar bij helpen, net als vermoedelijk velen hier. Begin in ieder geval klein, is mijn tip. Het uploaden is vaak makkelijker dan het herstellen van foutjes ;) Dajasj (overleg) 9 apr 2022 22:51 (CEST)

Ook ik doe data imports op Wikidata. Je moet hierbij wel opletten wat je importeert (betrouwbaarheid bronnen, licentie data). En ook welke tool het beste is. Er zijn tig tools, afhankelijk van wat je bron is. Wat betreft consensus is het belangrijk een afweging te maken in hoeverre een beroep op WP:VJVEGJG veel of weinig gedoe gaat opleveren. In infoboxen gebruiken we Wikidata als een fallback optie, oftewel indien een parameter is ingevuld pakt hij die, anders de waarde uit Wikidata. Dat levert weinig gedoe op, zou je je alleen beroepen op Wikidata is de kans op gedoe groter. Er zijn mensen hier die falikant tegen het gebruik van Wikidata zijn en die krijg je nooit mee. Mbch331 (overleg) 10 apr 2022 14:12 (CEST)

Dank jullie beide voor de terugkoppeling. Niets menselijks is mij vreemd, inclusief halsstarrige houdingen. Dat hoeft niet te betekenen dat Wikidata niet nu een leuke hobby kan zijn en wellicht later meer waarde heeft. Voorlopig zal ik geen grote hoeveelheden data aanbieden. Laat ik eerst maar eens kijken wat ik kan samenstellen en hoe goed dat is. Overigens moet ik steeds aan Fokke en Sukke denken zodra ik lees over de onwil om iets te veranderen. ;) Voorlopig laat ik de wiki-nl onderwerpen maar even buiten beschouwing. Daar valt ongetwijfeld nog veel te leren voor mij, bijvoorbeeld zo'n fallback. Om het behapbaar te houden richt ik me nu eerst op een enkele dataset. Zodra ik dat gereed heb deel ik het ter review... over een tijdje, want het wordt weer mooi weer :) Démarche Modi (overleg) 10 apr 2022 15:02 (CEST)

Zo'n fallback is niet zo moeilijk als je weet hoe de syntax van sjablonen werkt. Gewoon een stukje if ... then ... else.

En laat je niet ontmoedigen door halsstarrige lui. Mbch331 (overleg) 10 apr 2022 15:22 (CEST)

Zie Help:Parserfuncties. Wikiwerner (overleg) 10 apr 2022 15:35 (CEST)

@Démarche Modi Als je gegevens uit Wikidata wilt gebruiken, controleer de gegevens dan eerst. Het barst er echt van de fouten. Eerder zijn op WP:NL duizenden blind overgenomen gegevens in één dag van WP:NL verwijderd omdat de foutenbrij niet te harden was. Het kan zijn dat de Wikidata-gegevens zelf zonder welke controle dan ook zijn overgenomen van een van de vele Wikipedia-versies of misschien wel zelf (foutief) zijn bedacht door degene die ze plaatste. Let vooral op de "nationaliteit". Zoals wij die kennen bestaan ze pas sinds de Napoleontische tijd en toen alleen nog in de gebieden die Napoleon veroverd had. De rest volgde pas (veel) later. Zo kennen we pas een Duitse nationaliteit sinds 1871. Belgen en Nederlanders hebben pas sinds 1806 een nationaliteit en die heette "Hollander". Lukt het je niet om een Wikidata-gegeven te controleren op juistheid, neem het dan niet over. mvg HT (overleg) 18 apr 2022 19:03 (CEST)

_{(Deze reactie is geheel mijn interpretatie en berust mogelijk op onvoldoende kennis van zaken.)}

Je benoemt een belangrijk punt. Wat mij opvalt is dat de data items vaak onvolledig zijn, dat een logisch top down datamodel ontbreekt (land - provincie - gemeente - plaats bijvoorbeeld) en dat alles zo'n beetje aan alles gekoppeld kan worden. Maar niet per se gedaan wordt. En als het al gedaan is, verouderd raakt. Zoals bijvoorbeeld de Nederlandse gemeentelijke (her)indeling.

Na mijn eerste kennismaking met Wikidata legde ik het de afgelopen dagen grotendeels naast me neer. Door het spaghettimonster was ik mijn eetlust kwijt. Na de opmerkingen hier en daar vermoed ik dat er een essentieel probleem is met Wikidata. Misschien zelfs een wereldwijd probleem: het gebrek aan eigenaarschap, (strenge) richtlijnen voor completeren van data items en het bijhouden van deze items. Het is als stevig project neergezet met het belangrijke argument dat data altijd te herleiden is. Binnen de Wikidata server klopt dat en het heeft veel potentie. De herleidbaarheid naar gezaghebbende bronnen - buiten Wikidata, de echte wereld - is alleen niet afgedwongen, wat een probleem is en - zoals je zelf ook laat doorschemeren - het gebruik in de weg staat. De data moet vertrouwd kunnen worden en als dat niet kan moet je het niet gebruiken. Wat dat betreft begrijp ik de Wikidata sceptici heel goed, waarom zou je een secundaire server gebruiken indien de data toch eerst gecontroleerd dient te worden? Dat kan je dan net zo goed - op de bekende manier - op je eigen server doen. Easy does it...

Eigenaarschap binnen WPNL lijkt voor een groot deel wel gerealiseerd te zijn. Veel Wikipedianen controleren hun volglijst om na te gaan wat er gewijzigd is. Controlelijsten worden nagelopen om te kijken of wijzigingen kloppen. Binnen de gemeenschap worden mensen aangespoord als er controlewerk blijft liggen. En de artikelen die nog ontbreken of echt verbeterd moeten worden komen vanzelf aan de beurt zodra iemand daar tegenaan loopt. Zo komen er ook nieuwe Wikipedianen bij. Eigenaarschap binnen Wikidata lijkt mij een heel ander verhaal. Het is veel meer uit het zicht. Mensen die er al zicht op hebben richten zich vooral op de elementen die ze op dat moment van belang vinden. Wijzigingen worden dan pas (vermoedelijk) later gezien zodra de data in een artikel in aangepaste vorm getoond wordt. En, tot slot, zijn er (überhaupt) mensen die een compleet beeld hebben van wat een data item moet bevatten? Wanneer is het goed genoeg?

Als ik zo vrij mag zijn zie ik bij Edo veel kennis, het gebruik van scripts en actief op de WPNL en WD servers. Mogelijk zie ik ook zijn uitdaging / probleem / frustratie. Het gebrek aan overzicht. Veelal kleine wijzigingen, in bulk, die niet slecht zijn, maar ook niet per se de datakwaliteit verbeteren. Puntjes op de 'i' van woorden zonder dat zinnen geschreven zijn. Die uitdaging plus de sfeer die soms in discussies heerst lijkt mij bijzonder moeilijk. En daarom vraag ik mij nu ook af waarom hij gestopt is. Juist Edo, waarom is hij gestopt? Werd het technisch te moeilijk of was de gemeenschap te oneerbiedig?

1. Waar de verschillende Wikipedia's volgens mij juist bestaansrecht ontlenen aan de verschillen (met name taal, maar ook cultuur) zijn het diezelfde verschillen die er wellicht voor pleiten om voor Wikidata de zaken juist globaal aan te laten pakken. 2. Waar Wikipedia in het verleden (en soms nog steeds) worstelde met betrouwbaarheid en er veel inspanning binnen de gemeenschap nodig was om te groeien staat Wikidata nu daar waar Wikipedia vroeger stond. 3. Binnen de geest van de vrije encyclopedie en de open source software van Wikimedia zou het eeuwig zonde zijn als die big data uitdaging niet net zo voortvarend aangepakt - en gedragen - gaat worden... Démarche Modi (overleg) 18 apr 2022 20:15 (CEST)

Wat we dan wel krijgen, is een vicieuze cirkel: Wikidata is onbetrouwbaar -> we gebruiken de data niet in artikelen -> fouten blijven onder de radar -> Wikidata blijft onbetrouwbaar. Hoe het ook kan, zie je bijv. op Overleg sjabloon:Grafiek inwonertal gemeente Frankrijk en Help:Helpdesk/Archief/apr 2022#Gedachten, Vragen en Wikidata. Onze inwonertallen zijn van 2011, en die in Wikidata zijn van 2019, voor een groot deel met dank aan RonnieV. Daar komt bij dat de rest van de wereld de data ook kan gebruiken, aanvullen, corrigeren, ... Wikiwerner (overleg) 18 apr 2022 22:08 (CEST)

@Démarche Modi Dank voor je reactie en je wijze woorden. @Wikiwerner Je suggereert denk ik om juist Wikidata-gegevens in artikelen te plaatsen om op die manier er de fouten uit te laten halen. Dat lijkt mij geen goede opzet van werken. We hebben eerder gezien bij de geboorte- en sterflijsten dat er vele malen meer Wikidata-gegevens geplaatst kunnen worden, dan menselijkerwijs kan worden gecontroleerd. Het is correct wat Démarche Modi opmerkt dat veel Wikipedianen hun volglijsten in de gaten houden, maar er is geen garantie dat ook daadwerkelijk alle Wikidata-gegevens achteraf door anderen gecontroleerd worden. En het blijkt ook niet altijd te gebeuren. Daarnaast vertrekken ook Wikipedianen van dit project of houden een Wikibreak. Mogelijkheden voor Wikidata-gebruik zie ik zeker in inwoneraantallen, mits de bron bijvoorbeeld voor Nederland het CBS is. @Démarche Modi Op de OP van Edo en in zijn laatste bewerkingen kan je de reden van zijn vertrek lezen. We hopen natuurlijk allemaal dat hij terugkomt. HT (overleg) 18 apr 2022 22:29 (CEST)

Je moet niet massaal informatie gaan plaatsen, maar één voor één bijvoorbeeld infoboxen vervangen nadat je deze gecontroleerd hebt, lijkt me meer wat Wikiwerner bedoelt. Ik ben bijvoorbeeld de lijsten uit Categorie:Lijsten_van_Eerste_Kamerleden_naar_partij aan het verwerken in Wikidata. Als die klaar zijn, doen die kwalitatief niet onder aan nlwiki.

Dan even wat reacties op @Démarche Modi.

• Het datamodel is continu in ontwikkeling. Een recente frustratie van mij is bijvoorbeeld dat gemeenten en plaatsen niet gescheiden zijn op Wikidata, zoals je volgens mij zelf ook opmerkt. Dit is overigens het gevolg van hoe we het op Wikipedia doen, waar we die twee ook samenvoegen, tot we het dus moeten afsplitsen. Zie bijvoorbeeld Purmerend en Purmerend (gemeente). Het probleem van veroudering speelt ook op nlwiki. Mijn inziens zijn we echter beter af als alle taalprojecten samenwerken aan dit soort informatie. Het lukt ons op zich om de Nederlandse gemeenten te updaten, maar de Amerikaanse wordt al zeer lastig op dit project.
• Je schrijft "De herleidbaarheid naar gezaghebbende bronnen - buiten Wikidata, de echte wereld - is alleen niet afgedwongen, wat een probleem is en". Ik vind dit opvallend, want Wikidata is juist strenger in het signaleren van ontbreken van bronnen. Je krijgt daar gewoon uitroepteken als er bij bepaalde zaken geen bron staat, dat is er op Wikipedia niet. Een groot deel is weliswaar van Wiki's gehaald, maar bij gebruik op Wikipedia kun je vaak selecteren dat info zonder bron of met Wiki als bron niet meegenomen wordt.
• Wikidata is inderdaad een spaghettimonster. Het helpt om in te zoomen op kleine projecten. Splits bijvoorbeeld die gemeenten af. Het helpt ook om een specifiek doel voor ogen te hebben, een toepassing op nlwiki. Ik wil bijvoorbeeld nog wel graag een grafiek met aantal gemeenten in Nederland over tijd, zou moeten kunnen uiteindelijk met Wikidata. Maar goed zo zijn er talloze voorbeelden van interessante dingen te doen.
• Met eigenaarschap komen we uit op hetzelfde punt. Mensen zijn nu geen eigenaar omdat het nu nog is voor een select groep gebruikers die heel veel pagina's beheren. Als we echter het breder gaan toepassen op Wikipedia, moeten artikeleigenaren op Wikipedia ook Wikidata in de gaten houden. Die prikkel is er nu niet zonder gebruik. Het voordeel is dan uiteindelijk dat per pagina meer mensen meekijken, omdat het door meerdere projecten gecontroleerd wordt.
• Wanneer is een item klaar? Wanneer is een Wikipedia artikel klaar? ;) Er lopen heel wat projecten daar die aangeven wat je normaal kan verwachten bij een bepaald item, zoals een politicus, verkiezing of muzieknummer. Maar soms is iemand twee dingen, Ernst Kuipers bijvoorbeeld.

Zoals Wikiwerner terecht opmerkt, de vicieuze cirkel is het probleem. Er is een toekomst waarin Wikidata net zo betrouwbaar is als Wikipedia en als centraal datapunt kan fungeren voor Wikipedia. Die toekomst komt echter niet vanzelf :) Dajasj (overleg) 18 apr 2022 22:53 (CEST)

Dank jullie allen voor de reacties. Wederom stof tot nadenken en om te lezen... _{(ik richt me ondertussen onder andere op een CBS tabel, inwoners per gemeente per maand. CBS kant is m.i. klaar. Liep vervolgens spaak op het uitvragen van Wikidata om pageid's te koppelen aan de gemeente... pageid krijg ik wel, maar het is nog niet altijd zeker weten de juiste (bijvoorbeeld Q727 Amsterdam vs Q9899 Amsterdam gemeente maar ook Q9901 Bergen vs Q9804 Bergen...) work in progress. Zodra ik dat hier ter review aangeboden heb wil ik je wel proberen te helpen met een grafiek (combinatie van RonnieV's aanpak en [dit]).} Démarche Modi (overleg) 18 apr 2022 23:43 (CEST)

Het datamodel van Wikidata is bewust heel open opgezet, om geleidelijke groei mogelijk te maken, zowel in het model als in de beschikbare data. Hierdoor kan een item op Wikidata geleidelijk groeien, net zoals een pagina op Wikipedia kan groeien. Stel dat we zouden vereisen dat degene die begint aan het vastleggen van het item Amsterdam meteen alle velden en waarden zou moeten invullen, dat zou velen afschrikken. Ik kan best de omschrijving in het Nederlands verzorgen, en ook wat andere talen kom ik daar wel uit, maar de omschrijving in het Arabisch (بلدية في شمال-هولندا، هولندا)? Chinees (荷兰北荷兰省市镇，包含阿姆斯特丹城)? Oekraïens (Муніципалітет у Нідерландах)? En of ik alle zusterplaatsen in een keer bij elkaar had gesprokkeld? Bovendien was bij het begin van Wikidata nog niet bedacht dat we ook een burgerinitiatief-url als eigenschap zouden hebben.

Een aantal jaren geleden ben ik vol enthousiasme aan de slag gegaan om de (inmiddels ruim) 243.000 personen over wie we een artikel op deze Wikipedia op te nemen in lijsten als Gebruiker:RonnieV/Lijst van personen overleden in 1948 aan de hand van de informatie op Wikidata, omdat ik allang doorhad dat het handmatig opzetten van Lijst van personen overleden in 1948 eenvoudig is, maar het zorgen dat die lijst compleet is lastig en het bijhouden ervan onmogelijk. En dan gaat het hier over 1 overlijdensjaar, maar we hebben dergelijke lijsten voor alle jaren vanaf 1948 en kunnen die ook hebben voor alle jaren ervoor (al dan niet in decennia gegroepeerd). En dan ook de lijsten per geboortejaar en de lijsten per dag. Ja, er stond een aantal fouten in die lijsten (omdat er gegevens verkeerd waren ingevoerd in Wikidata) en het was iets te optimistisch om nationaliteiten van oudere personen op te nemen (maar zie Hermannus Amya, die wordt aangeduid als een Nederlandse advocaat), Louis Jolliet (Franse ontdekkingsreiziger en aardrijkskundige) en William Russell (Engels liberaal politicus), allen overleden in 1700), maar deze lijsten hebben wel veel inzicht gegeven en veel verbeteringen teweeggebracht. Sommigen zagen deze informatie liever niet in de hoofdnaamruimte, maar gelukkig is dit wel in mijn persoonlijke naamruimte behouden. Deze lijsten hebben veel verbeteringen op Wikidata zien passeren en zichtbaar gemaakt, maar ook een aantal wijzigingen die al dan niet per ongeluk gemaakt waren (ook op Wikidata geldt AGF). Door de informatie niet te verbergen totdat er op enig moment door een of ander wonder opeens een perfecte Wikidata zou zijn, maar de informatie zichtbaar en toegankelijk te maken, wordt deze steeds verder verbeterd.

Voor de inwonertallen van Nederlandse gemeenten in het CBS inderdaad een goede bron. De Nederlanders onder ons spreekt dat aan, omdat het ons dicht aan het hart gaat en dan pakken we dat op. Met die gegevens kunnen we eigenzinnig op ons eigen eilandje gaan zitten en dit bijvoorbeeld opnemen in een array dat als sjabloon verhuld wordt binnen onze eigen Wikipedia, of we kunnen die informatie delen met de hele wereld, via Wikidata. Laat het delen van kennis nu juist een doel zijn van alle Wikimedia-projecten...

Voor de Sloveense gemeenten is die informatie te vinden bij de Sloveense tegenhanger van het CBS, voor andere landen bij andere bronnen. Waar zouden onze lezers beter mee geholpen zijn? Met de gegevens die iemand in 2011 heeft opgeduikeld van een volkstelling uit 2002 en toen hard heeft opgenomen in een beginnetje over een plaats in een of ander land, of met aanzienlijk recentere gegevens die iemand uit een vergelijkbare bron heeft opgeduikeld en in Wikidata beschikbaar heeft gesteld aan de hele wereld? Ik wil graag met mensen uit verschillende landen samenwerken om hun lokale data te ontsluiten voor een breed publiek, om er zo voor te zorgen dat niet alleen die lokale Wikipedia de recente informatie toont, en de Nederlandse en Engelse Wikipedia daar gebruik van kan maken, maar ook de zwaar onderbezette Wikipedia in het Papiaments, Fries of Bretons daarmee geholpen wordt. Waarom zouden we in vijf talen vijf verschillende inwonertallen opnemen, alleen maar omdat er niet voor iedere taal mensen paraat staan om de nieuwste gegevens over te nemen?

Zoals Dajasj al aangeeft, moet er bij Wikidata bij een aantal gegevens een bron worden opgegeven, wordt het gemeld als die ontbreekt. Vaak kan je veel informatie uit een enkele bron halen, en op Wikidata kan je gelukkig die bron kopiëren van het ene veld naar het andere. Op deze Wikipedia kan iedereen in ieder artikel alles schrijven zonder enige bron op te geven. Tegelijkertijd moeten we ook oppassen ons niet blind te staren op bronnen, overal bronnen voor gaan eisen of de lat voor informatie uit Wikidata aanzienlijk hoger leggen dan voor informatie uit andere bronnen. En leg ik hier bij een artikel vast dat ik dat een bepaalde bron heb gebruikt, dan is totaal niet duidelijk welke informatie uit specifiek die bron is overgenomen.

Vanwege een beveiligingsprobleem met de MediaWiki Graph-software is het momenteel niet mogelijk deze grafiek weer te geven. Zodra de software is bijgewerkt zal de grafiek vanzelf weer zichtbaar worden.

Zie bron Wikidata query.

Dat @HT in de veronderstelling leeft dat ieder artikel en iedere bewerking op deze Wikipedia grondig gecontroleerd wordt, veel grondiger dan de informatie op Wikidata, het zij hem vergeven. De Urker vistaart heeft hier vele jaren gestaan, en in vele artikelen zijn dingen te vinden die verbeterd kunnen worden. Maar informatie die niet zichtbaar is, wordt niet gecontroleerd en zal derhalve ook niet verbeterd worden.

Het grafiekje met het aantal Nederlandse gemeenten in de loop der jaren is niet zo moeilijk ;) En doordat deze informatie op Wikidata staat, kan dat niet alleen op de Nederlandse Wikipedia gebruikt worden, maar ook op de Engelse, Portugese of Noorse: kwestie van de title aanpassen. En dan lopen die ook altijd mee met de ontwikkelingen die wij Nederlanders vastleggen in Wikidata. Met vriendelijke groet, RonnieV (overleg) 19 apr 2022 01:31 (CEST)

Beste RonnieV Je schrijft: "Dat @HT in de veronderstelling leeft dat ieder artikel en iedere bewerking op deze Wikipedia grondig gecontroleerd wordt, veel grondiger dan de informatie op Wikidata, het zij hem vergeven." Ik schrijf helemaal niets daarover. Als je goed leest, dat schrijf ik alleen dat informatie in Wikipedia afkomstig van Wikidata niet altijd gecontroleerd wordt én dat informatie van Wikidata in zulke groten getale blind op Wikipedia wordt gezet, dat controle menselijkerwijs niet mogelijk is. Over het algemeen heb ik - na tien jaar controle op Wikipedia - de indruk dat over het algemeen weinig van de informatie op WP:NL op juistheid gecontroleerd wordt. Met het geringe aantal daadwerkelijk actieve Wikipedianen die zich daarmee bezighouden is het gewoon niet te doen. Dat veel informatie bronloos gepubliceerd mag worden, helpt daarbij evenmin. De rest van je reactie heb ik niet gelezen. Het is mij echt te lang. HT (overleg) 19 apr 2022 06:59 (CEST)

@Dajasj: Je schrijft: "Er is een toekomst waarin Wikidata net zo betrouwbaar is als Wikipedia". WP:NL is echt niet betrouwbaar. Ook daar is de foutenbrij niet te harden. Je schrijft over het omzetten van alle infoboxen naar informatie op Wikidata, één voor één. Ik zie daar het nut niet van in. Waarom zou je een bepaalde infobox met keurig correcte informatie die niet meer zal veranderen overzetten naar een van Wikidata met de kans dat die informatie automatisch aangepast wordt en er dus fouten in komen? Ik geloof ook niet dat daarvoor consensus is. HT (overleg) 19 apr 2022 07:11 (CEST)

@Happytravels:, de voordelen van zo'n infobox zijn inderdaad groter bij personen waarvan de info veranderlijk is. Maar uiteindelijk is het voordeel dat die info ontsloten is voor alle andere projecten. Dat daar vermoedelijk geen consensus voor is, heb ik reeds eerder in deze draad genoemd. Overigens betekent automatisch toevoegen van data niet dat er dus ook fouten in komen. Dajasj (overleg) 19 apr 2022 08:08 (CEST)

@Dajasj. Ik was op dit vroege uur wat te snel. In mijn vorige reactie had moeten staan: "en er dus fouten in kunnen komen". Zolang Wikidata deels (volgens mij zelfs grotendeels) gebaseerd is op blind overgenomen gegevens van Wikipedia-versies, is er in zijn algemeenheid helaas niets van te maken. Wel kan het als inspiratie dienen. HT (overleg) 19 apr 2022 08:25 (CEST)

Kop koffie nog niet gedronken? ;) Je hebt gelijk dat een groot deel van de informatie "blind" is overgenomen van Wikipedia-versies, en daarmee dus net zo zwak is als Wikipedia zelf met als aanvullend nadeel dat de bron een stap verder is. Maar de toekomst is hopelijk juist eentje waar dat allemaal is vervangen door nette bronnen :) Dajasj (overleg) 19 apr 2022 08:50 (CEST)

@RonnieV, thanks voor de query! :) Waar ik echter aan dacht was binnen Wikidata het aantal gemeenten tellen (ik wist overigens niet dat dit op deze manier bijgehouden wordt). Nu bevat dat nog een aantal fouten, maar zorgt wel voor minder dubbel werk. Je past namelijk sowieso de gemeente aan na herindeling, maar hoeft dan niet langer de teller bij te houden. Hoe kijk je daar tegen aan? Dajasj (overleg) 19 apr 2022 08:58 (CEST)

Hoi Dajasj,

Ik wist ook niet dat dit zo werd bijgehouden, maar Gebruiker:Démarche Modi bracht me op dit spoor. Toen was het maken van het grafiekje zo geregeld.

Het (steeds) tellen van de gemeenten per een bepaalde datum, is ook een mogelijkheid. Vereist is dat alle gemeenten bekend zijn in Wikidata, dat de begindatum ingevoerd is (in ieder geval als deze na de eerste datum van je grafiek ligt) en dat alle eventuele einddata ingevoerd zijn. Vervolgens zou je eigenlijk per datum moeten gaan tellen, tenzij je ergens bijhoudt wat je allemaal hebt gevonden en welke data relevant zijn (als ik naar 2022 kijk, is het louter tellen op 1 januari niet genoeg (fusie Weesp-Amsterdam per 24 maart 2022), maar in vele jaren volstaat dat wel. Heb je de gegevens van alle gemeenten in een array ingelezen, dan kan je daar wel uithalen wat de relevante data zijn.

Nadeel is wel dat je voor een vrij statisch gegeven iedere keer al deze data moet gaan ophalen en verwerken, voordat je het in beeld kan brengen. Performance is niet iets waar wij bewerkers ons zorgen om hoeven te maken, maar toch... Waar het wel goed voor kan zijn, is om te zien of de aantallen aansluiten. Dan hoef je het script maar incidenteel te draaien, en kan je laten aangeven of het vermelde aantal overeenstemt met het berekende aantal. Desgewenst kan een rijtje met gemuteerde gemeenten per een bepaalde datum worden opgehoest: stel dat je een verschil hebt per 1 januari 2022, dan is snel te zien dat er x gemeenten aangepast moesten worden en dat de opheffing van gemeente Y nog niet verwerkt was. Of de vorming van gemeente Z. Dat helpt zeker om Wikidata te verbeteren. Met vriendelijke groet, RonnieV (overleg) 19 apr 2022 09:14 (CEST)

RonnieV ik vind het mooi om te zien hoe snel je zo'n grafiek gemaakt hebt. Wat ik nog mis is een echte bronvermelding, welke wel bij de data aanwezig is (P854)

SELECT ?datum ?aantal {Kan die query aangevuld worden met:SELECT ?datum ?aantal ?bron {

Waar bron dan de URL toont die in Property 854 staat. Bijvoorbeeld (Bron) of gewoon de URL.

Mijn kennis van sparql syntax is nog extreem beperkt en ik was zojuist begonnen me in te lezen. Ik zie alleen hoe snel jij dingen voor elkaar krijgt en dacht ik leg het gewoon voor.

Ps: De grafiek nullijn ontbreekt, zo lijkt het net alsof er in 2022 geen gemeenten meer zijn. Zien jullie dit ook zo en kan de as vanaf 0 beginnen? Démarche Modi (overleg) 19 apr 2022 09:46 (CEST)

Het kan ook vanaf nullijn! Op zich zou het toegankelijker maken van de bron wenselijk zijn, als dat al technisch mogelijk was. Anderzijds krijg je dan dus 100 referenties erbij op een pagina... Dajasj (overleg) 19 apr 2022 09:51 (CEST)

1 kolom extra. Indien de grafiek nu getoond wordt en ik doorklik om te herleiden dan kom ik niet verder dan een tabel en de query. Het zou mooi zijn om verder te kunnen, wellicht is de URL per regel teveel van het goede, maar dan op zijn minst het het data item Q2039348 gelinkt aan de tabel. En dan volgen daar de URL's per property wel weer. Démarche Modi (overleg) 19 apr 2022 10:04 (CEST)

Vanwege een beveiligingsprobleem met de MediaWiki Graph-software is het momenteel niet mogelijk deze grafiek weer te geven. Zodra de software is bijgewerkt zal de grafiek vanzelf weer zichtbaar worden.

Zie bron Wikidata query.

De y-as vanaf 0 laten beginnen, is de standaard. Maakt de lijn beter zichtbaar, de waarden wat minder. RonnieV (overleg) 19 apr 2022 10:13 (CEST)

Vanwege een beveiligingsprobleem met de MediaWiki Graph-software is het momenteel niet mogelijk deze grafiek weer te geven. Zodra de software is bijgewerkt zal de grafiek vanzelf weer zichtbaar worden.

Zie bron Wikidata query.

Zoiets bedoelde ik, begrepen danzij deze info. Titel is alleen om onderscheid met RonnieV's grafiek iets duidelijker te maken. Démarche Modi (overleg) 19 apr 2022 11:08 (CEST)

De discussie is wat onoverzichtelijk geworden met de grafieken. Maar nog even een reactie op @RonnieV:. Dank voor je toelichting. Je hebt wel gelijk dat het misschien wel efficiënter is. Een automatische waarschuwing als die twee out-of-sync zijn, zou wel interessant zijn. Frustrerender vind ik het gebrek aan wederkerigheid. Dat je bij twee personen moet invullen dat ze getrouwd zijn, waardoor de waarden en bronnen bijvoorbeeld kunnen verschillen. Of dat je dus kan kiezen tussen "kandidaat in verkiezing" bij een persoon of een ander bij de verkiezing zelf, waardoor je bij inconsequent gebruik niet kan querien. Maar goed, einde frustratie. Overigens valt me de perfomance van die Sparql omgeving wel tegen. Vooral als je de nlwiki-naam wilt hebben van een item. Dajasj (overleg) 19 apr 2022 15:01 (CEST)

Personen met instance=human zonder verdere attributen

Ik zag dat er op Wikidata enkele dagen geleden een groot aantal items waren aangemaakt van personen met een artikel op deze Wikipedia. Hierbij was enkel het attribuut instance of ('human') toegevoegd. Hoe is dit makkelijk queryen, zodat ik dit kan aanvullen? Ik heb op mijn kladblok enkele pogingen gedaan waarbij ik personen met instance human en zonder geslacht en nationaliteit eruit probeerde te halen, maar daar kreeg ik een foutmelding op. GeeJee (overleg) 17 apr 2022 14:21 (CEST)

Of wordt dit vanzelf opgepakt door botjes die hier nationaliteit, geslacht en meer gaan toevoegen? GeeJee (overleg) 17 apr 2022 14:31 (CEST)

Misschien met Petscan. Overigens heb ik niet zo'n hoge pet op van die botjes. Als ik mijn volglijst bekijk zijn het vooral labels en voornamen die met een botje aangepast worden. De Edoderoobot vond ik wel goed, maar die bot is na het vetrek van Edo dood. Ldhank (overleg) 18 apr 2022 09:01 (CEST)

Misschien heb je dan een bepaald soort artikelen op je volglijst staan @Ldhank? Ik ken namelijk vooral veel bots die zaken rondom musea, archieven en bibliotheken toevoegen (kunstwerken, boeken, auteursrechten etc); die doen een hoop (goed) werk. De EdodeRoobot deed vooral heel veel nuttig werk rondom het aanvullen van labels, descriptions en omschrijvingen.

@Geejee, het zou inderdaad heel goed kunnen dat iemand of iets later het wikidata-item afmaakt. Ik doe het zelf ook vaak met bijvoorbeeld makers, boeken of kunstwerken. Ik maak dan eerst de wikidata-items aan (handmatig of met behulp van OpenRefine) en hang daar dan alleen is een (P31) aan. Ik noem dergelijke items eigenlijk een soort 'haakjes'. In een vervolgstap hang ik heel veel andere eigenschappen aan dat allereerste haakje en tuig ik het wikidatarecord helemaal op. Dit 'optuigen' doe ik meestal met behulp van Quickstatements. Quickstatements omdat ik dan in mijn ene browser de wikidata records kan aanvullen met QS en in mijn andere browser nieuwe datasets kan voorbereiden in OpenRefine (OR). (Ik houd er niet van als ik moet wachten wanneer OpenRefine zelf bezig is om WD-records aan te vullen, vandaar QS om twee keer zo productief te zijn) Er is ergens wel een bestaande query 'spel' (in mix 'n match??) om items van mensen zonder dat sekse of geslacht (P21) aan te kunnen vullen; ik zal even voor je kijken. Waar heb je anders jouw SPARQL-query staan? Ik kan kijken waarom je een foutmelding krijgt? Ecritures (overleg) 18 apr 2022 23:43 (CEST)

even ter aanvulling over Mix 'n Match, want deze gebruikerstool verdient echt beter. Er zijn inderdaad wikidata spellen, maar zo beschouw ik mix 'n Match niet. Mijn werkwijze is alsvolgt: als ik er vrijwel zeker van ben, dat er nog geen wikidata element is bij een nieuw artikel van een schrijver, kunstschilder of wetenschapper dan begin ik altijd met Mix 'n Match. Dus alleen, wanneer er een gerede kans is dat er claims zijn. Deze tool zoekt dan naar mogelijke claims (viaf, rkd dbnl enz.) voor personen of anderszins. Als er een of meerdere 'matches' zijn kan er een wikidata element met claims en statements gecreëerd worden, indien WD element aanwezig is kan voorgestelde claim gkoppeld of afgewezen worden.Ldhank (overleg) 19 apr 2022 09:49 (CEST)

@Ecritures: Ik heb op Gebruiker:GeeJee onder andere queries voor Belgische en Nederlandse personen staan waarbij geen geboorte- en sterfdata gevuld zijn. Hierbij check ik uiteraard wel op nationaliteit. Deze werken. Ik heb op mijn kladblok (Gebruiker:GeeJee/Kladblok, zie ook de history) wat pogingen gedaan om een query te maken op personen waarbij de instance gevuld is met human, maar waarbij geen geslacht en(/of) nationaliteit is gevuld. Melding die ik krijg is "Last line: ERROR: run_sparql_query: String("error decoding response body: expected value at line 1 column 1")". Deze melding heb ik ook wel eens op andere queries gehad; het ligt wellicht niet aan de code maar aan het resultaat?! Het staat je vrij om de query op mijn kladblok aan te passen. GeeJee (overleg) 19 apr 2022 17:00 (CEST)

Hulpmiddelen en beheer

Het viel mij op, dat een aantal artikelen zijn gearchiveerd, maar daar stonden enkele queries in, die ik nog wel eens gebruikte (Aug. 2020). ik vroeg mij af of activiteiten, die gebuikers kunnen doen voor onderhoud en beheer op wikidata elders op nl.wiki vermeld staan. (Ik bedoel niet de tools van Edo, die geven geen relevante output meer) Ldhank (overleg) 18 apr 2022 09:01 (CEST)

Jammer dat die van Edo het niet meer doet. Deze geeft in ieder geval links naar nl-wiki items zonder enige claim. Ciell need me? ping me! 18 apr 2022 10:12 (CEST)

In deze discussie staan er een aantal: Wikipedia:Wikidata-café/Archief/feb_2022#Artikelen_koppelen_aan_Wikidata-items. Zou inderdaad handig zijn om ergens op een vaste plek een overzicht te maken. GeeJee (overleg) 18 apr 2022 10:20 (CEST)

Wellicht op de Help:Alfabetische_index met Wikidata als nieuwe pagina? Démarche Modi (overleg) 18 apr 2022 10:30 (CEST)

We kunnen in de groep WP:WOW (Wikidata op Wikipedia) een dergelijke pagina gewoon opzetten: is vast een handige plek om die informatie te verzamelen. Groet, Ecritures (overleg) 18 apr 2022 14:55 (CEST)

Lijkt mij een heel goed plan. Maar Hoe kunnen we dit het best aanpakken? 2. De eerder genoemde queries ken ik natuurlijk wel, maar deze zijn volgens mij alleen te vinden in kroegdiscussies. Ldhank (overleg) 18 apr 2022 18:09 (CEST)

Hier staan ook nog wat 'Edo scripts'. Geen idee of de gewenste scripts daar bijstaan. Démarche Modi (overleg) 18 apr 2022 18:45 (CEST)

Hoi Ldhank: kun je aangeven welke queries je gebruikte? (Ik neem aan dat je met queries SPARQL-queries bedoelt?) Misschien kunnen we ze opnieuw schrijven of handiger nog, terugvinden? Als ik weet of je queries of toch scripts bedoelt dan kan ik (en ieder ander) in WP:WOW een pagina aanmaken. – De voorgaande bijdrage werd geplaatst door Ecritures (overleg · bijdragen)

Hoi Ecritures, Heel eenvoudig, het mag wel, maar er hoeft wmb niets geschreven te worden. Mijn insteek voor deze discussie was, de twee lijsten genoemd in de kroegdiscussie Aug. 2020 vind ik niet terug bij de WP Beheer en Onderhoudstaken, en kunnen misschien beter ergens vast vermeld worden, dan alleen in een gearchiveerde kroegdiscussie. Dus het betreft de lijst nl.wp zonder WD element, en de lijst WD element met nl.wp, maar geen statements of claims. Overigens vind ik alle uitbreidingen op deze beheerstaken welkom. Ldhank (overleg) 19 apr 2022 10:38 (CEST)

Handleiding Wikidata-driven infobox

Hai, is er al ergens een handleiding hoe je een op Wikidata gebaseerde infobox kan maken? Ik neusde al een beetje in de documentatie, en ik heb een paar infoboxen voor personen gezien, maar ik wil iets dergelijks voor wat missende Franse stations doen. Ik kon ook zo snel niet in andere taalversies iets dergelijks vinden. Als iemand de nodige weetjes heeft hoe zo iets aan te pakken wil ik er wel een kookboek voor maken. (Nuttige linkjes: deze en deze). Milliped (overleg) 19 apr 2022 10:28 (CEST)

Wikidata:Wikidata:Infobox Tutorial al gezien? Zelf nog niet gedaan, maar wie weet helpt het? Dajasj (overleg) 19 apr 2022 11:46 (CEST)

Ik keek daarnaar en dacht: als ik nou eens een kwart zo knap was als bdijkstra, dan zou ik daar iets mee kunnen. Maar dat tutorial is een beetje zoals iedere tutorial op internet, en ik heb maar een klein denkraampje. Ik gok dat het op nl-wiki simpeler kan, ik geloof dat de benodigde modules al bestaan? Milliped (overleg) 19 apr 2022 14:21 (CEST)

Wat m.i. de meeste documentatie over Wikidata en Lua mist, en zo ook deze tutorial, is informatie over de datastructuur van Wikidata-items. Want als je niet weet hoe je kan navigeren naar de gegevens die je wil ophalen, kan je geen module schrijven en begrijp je niet goed wat je kan verwachten van de geboden functies. Hier staat vrij uitgebreide info, maar is hier en daar nog wat summier. Dit hoofdstukje was voor mij erg verhelderend.

En dan: we hebben al heel veel infoboxsjablonen. Veel hiervan zijn erbij gebaat om de meest basale gegevens uit Wikidata te halen. Dat kan veelal met bestaande sjablonen die bestaande modulen gebruiken, zoals {{wd}} die Module:Wd gebruikt, en Module:Wikidata (zonder sjabloon). Zo is het sinds kort niet meer nodig om IMDb-nummers in infoboxen van acteurs, films, etc. in te vullen, maar hiervoor was een module nodig omdat er één property is voor zowel personen als producties en omdat er regelmatig meerdere IMDb-codes op een Wikidata-item staan. Misschien kan je beginnen met het gebruik van bestaande modules om basale gegevens met weinig complicaties in te vullen en zo je denkraam verruimen. –bdijkstra (overleg) 19 apr 2022 15:37 (CEST)

Review commentaar gevraagd

Na wat puzzelwerk heb ik een script geschreven welke hier terug te vinden is. Uiteindelijk vermoed ik dat het me gelukt is om de CBS data te koppelen aan de WD items. Dit script heeft als doel om van alle huidige gemeenten meest recente inwonertallen op te halen uit de CBS bron. Er wordt hiervoor met een aantal datasets gewerkt die een spreadsheet als resultaat heeft. Het is herschreven (ingekort) om als één script te werken. In mijn omgeving staat het meer losgetrokken met als doel te hergebruiken. Deze vertaalslag zie je nog een beetje terug in het script.

De eerste regel van het resultaat ziet er als volgt uit:

	Gemeentecode	GemeentecodeGM	Gemeentenaam	Provinciecode	ProvinciecodePV	Provincienaam	Perioden	BevolkingAanHetEindeVanDePeriode_15	DateRegistration	source	DateRetrieval	PageID
0	1680	GM1680	Aa en Hunze	22	PV22	Drenthe	2022 februari	25563	2022-03-31T02:00:00	https://opendata.cbs.nl/statline/#/CBS/nl/dataset/37230ned/table?dl=666B1	2022-04-19T20:16:31.784	Q300665

1. Zijn er datakolommen die je zou toevoegen voor een import naar Wikidata?
2. Heb je bevindingen op basis van de code zelf? Démarche Modi (overleg) 19 apr 2022 22:40 (CEST)

Ten eerste is "PageID" een lichtelijk verwarrende term, elke wikipagina heeft namelijk een paginanummer (bv. 20750 voor Aa en Hunze en 289712 voor Q300665) maar dit gaat om het item-ID. Ten tweede neem ik aan dat je "Perioden" gaat toevoegen als tijdstip (P585)-kwalificatie en ook een kwalificatie voor methode van vaststelling (P459) toevoegt en indien van toepassing ook gebruikt criterium (P1013). Over de code: in update_cbs_population_37230NED() zou ik een regex gebruiken om een eventueel deel tussen haakjes weg te laten, maar waar gebruik je die namen precies voor? En de gemeentecode staat toch ook in de CBS-data? Zo ja, dan kan je CBS-gemeentecode (P382) gebruiken om je tabellen te koppelen. –bdijkstra (overleg) 19 apr 2022 23:03 (CEST)

Dank! PageID ga ik aanpassen, de naam baseerde ik op wat de WikidataSPARQLPageGenerator teruggaf. Een detail bij die generator is dat indien ik de sparql query in de browser uitvoer ik netjes twee kolommen (item-ID en naam van de gemeente) te zien krijg. Het lukte me alleen niet om die uit het object generator te halen ( generator = pg.WikidataSPARQLPageGenerator(QUERY, site=wikidata_site, item_name='muni'). Daarom itereert de code later result._set_value(index, 'Label' (etc) per item-ID om de naam van de gemeente uit Wikidata te halen. Op die naam joint de code later (weer). Nu begrijp ik dat het beter de CBS code is die als sleutel fungeert.

Het CBS geeft in de tabel 37230NED helaas geen CBS-code mee terwijl hier wel de actuele inwonertallen in staan. Daarom ben ik op zoek gegaan naar een andere bruikbare sleutel en zo kwam ik op de Gemeentenaam. Zodoende de manipulaties, want het CBS hanteert soms verschillende namen. Het gebruik van regular expressions heb ik vermeden omdat ik die behoorlijk eng vindt. Indien ze goed gebruikt worden kunnen ze heel efficient zijn, maar ze zijn zo gedetailleerd... wellicht waag ik me er binnenkort aan. Mits het nut heeft, want de set heeft nog altijd Bergen (L.) en Bergen (NB.)

De properties die je noemt, daar ga ik op letten. Die kunnen er wel bijgezet worden. Vervolgens wil ik graag een import doorlopen, om te zien waar ik nog meer tegenaan loop. Die import ga ik eerdaags proberen met een enkele regel...

Tot slot de CBS codes in wikidata... die heb ik gemist. Nu begrijp ik ook waarom ik die fout maakte. In het begin deed ik veel met Amsterdam Q727 welke geen CBS code heeft. In de eerste pogingen om correct te koppelen liep ik spaak, ik kreeg niet per se het juiste item terug. Tot ik later de Nederlandse gemeente Q2039348 vond en dus weer ging name mappen. Had ik maar gelijk hiernaar en naar Amsterdam Q9899 gekeken... LOL.. to be continued dus. Démarche Modi (overleg) 20 apr 2022 00:07 (CEST)

Tools voor vergelijken Lijsten/Categorieën met Wikidata

Hallo collega's. Ik ben op Wikidata met wat toevoegingen bezig die deels in lijstvorm of categorievorm ook op Wikipedia staan. Soms zet ik dan een Listeria lijst op de overlegpagina zodat Wikidata als inspiratie voor Wikipedia gebruikt kan worden en andersom. Bij lange lijsten is dat echter onoverzichtelijk en wil ik vooral weten welke ontbreken in één van beide projecten. Mijn vraag is dus of er tools zijn om sparql queries te vergelijken met ofwel outgoing links van lijsten ofwel leden van een categorie? Ik hoor het graag! Dajasj (overleg) 29 apr 2022 16:07 (CEST)

Als zo'n tool er nog niet is kunnen we het misschien wel zelf schrijven met behulp van de pywikibot. Démarche Modi (overleg) 29 apr 2022 19:31 (CEST)

Ja ik zat daar ook al aan te denken. Zowel de query als inkomende links zijn vrij makkelijk. Moet je alleen wat doen met redirects, dat zou ik moeten uitzoeken. Maar wilde eerst kijken wat er al is voordat ik het wiel opnieuw uitvind. Dajasj (overleg) 29 apr 2022 21:35 (CEST)