Wikipedia:Wikidata-café/Archief/sep 2023

PostgreSQL 16 release candidate 1 (16rc1)

Zojuist is PostgreSQL '16 release candidate 1' uitgekomen.
Ik heb in wikidata onder PostgreSQL '16 release candidate 1' als laatste versie toegevoegd. Me dunkt dat het nu in wikipedia in het 'Laatste bètaversie' item zou moeten verschijnen (al is het strikt genomen een rc). Kan iemand dat een beetje in de gaten houden/in goede banen leiden/bespoedigen? PostgreSQL hoopt op zoveel mogelijk testers van de Release Candidate. Thx! Kweetal nl (overleg) 31 aug 2023 15:19 (CEST)

In Sjabloon:Infobox software staan alleen de stabiele versie en de bètaversie, dus wil je dat deze versie weergegeven wordt dan zul je in het wikidata-item het versietype moeten veranderen in bètaversie en er voor zorgen dat alleen die bètaversie een voorkeursrang heeft. Behanzane ☎✉ 1 sep 2023 12:46 (CEST)

Hoe kom ik aan de rechten om die voorkeursrang te zetten? Kweetal nl (overleg) 1 sep 2023 15:57 (CEST)

nevermind... It's fixed now. bedankt. Kweetal nl (overleg) 1 sep 2023 16:30 (CEST)

Onvriendelijke beperkingen, vriendelijke onzin

Nadat ik iets had gedaan aan Sint-Nicolaasbasiliek (IJsselstein) besloot ik ook het bijbehorende d:Q2522046 aan te pakken. Ik zit gewoonlijk vreselijk te worstelen met Wikidata, zie de 21 bewerkingen die ik nodig had: wanneer is iets nou een verklaring, wanneer een kwalificatie, waarom zie je eigenschapsbeperkingen altijd te laat, waarom zie je suggesties en 'deze verklaring heeft mogelijk een probleem' pas na het opslaan? Dat moest ik even kwijt. Juist door mijn ergernis maak ik ook onnodige fouten, dat moet gezegd. Concreet:

• Als d:Property:P8897 (Reliwiki-identificatiecode voor pagina) ingevuld is, verwacht Wikidata dat ook straat (P669) en adres (P6375) ingevuld worden. Dat lijkt me zeer ongewenst, want daaraan is alleen te voldoen door de straat dubbel in te vullen. Is die beperking nodig of zelfs maar wenselijk? Indien ja, dan zou het of/of moeten zijn. Wikidata zou mijns inziens moeten verhinderen of ontmoedigen dat beide eigenschappen tegelijk in een item gespecificeerd worden. (Ik ga nog maar voorbij aan de suggestie dat Reliwiki en indirect Rijksmonumenten een geschikte bron zou zijn voor BAG-info)
• Als gebruiker (P466) wilde ik invullen [P/p]arochie H. Drie-eenheid, maar dit werd onmogelijk gemaakt, zonder toelichting. Met Aartsbisdom Utrecht lukte het wel, maar dat zegt weinig en staat elders al vermeld. Moet er eerst een Wikidata-item van de gebruiker zijn?

Dit hoort eigenlijk op Wikidata zelf thuis, maar ik ben doodop van het gedoe; even geen Engels voor mij  →bertux 4 sep 2023 16:14 (CEST)

• adres (P6375) zou het volledige adres moeten zijn inclusief postcode en plaatsnaam; de straat (P669) is een link naar een item, Wikidata biedt geen manier om tekst met itemlinks te combineren (en dat zou ook niet echt in het paradigma van gestructureerde data passen).
• Bij gebruiker (P466) zie je staan: gegevenstype: item, dus er moet daar inderdaad gelinkt worden naar een Wikidata-item.

–bdijkstra (overleg) 4 sep 2023 16:53 (CEST)

Maar als je bij P669 de kwalificatie huisnummer invult en tevens de postcode (P281), zoals hier is gedaan, dan is het toch onwenselijk om ook nog P6375 in te vullen? Dat leidt tot redundantie: onvermijdelijk gaat mensen adressen aanpassen zonder weet te hebben van de andere kenmerken; daarom is dit in strijd met de grondprincipes van database-ontwikkeling: basisgegevens moeten niet gedoubleerd worden. Mijns inziens zou:

• P887 (Reliwiki) XOR moeten vragen naar adres of straat, of nog beter naar geen van beide;
• P6375 (adres) automatisch samengesteld moeten worden uit P667 (straat plus nummer) en P281, als die beschikbaar zijn; handmatig invullen zou dan ontmoedigd moeten worden;
• er een waarschuwing moeten zijn als er iets wringt tussen P6375 en de rest. Ik vind dat Adres niet gebruikt zou moeten worden voor de hedendaagse gestandaardiseerde adressen in Nederland. Voor minder gestandaardiseerde of vervallen adresaanduidingen kan deze eigenschap (of een variant daarop) natuurlijk wel diensten bewijzen, zoiets als A52 a3 (in de jaren 1930 het adres van onze buren), een dagreis stroomopwaarts van New Orleans en neven den Swarten Hont.

 →bertux 4 sep 2023 17:28 (CEST)

Het adres is een bepaalde notatie, die kan je niet uit de straat en het nummer halen (althans niet voor alle landen). En niet elk adres heeft een straat, zie bv. Kokyo (Q500681). Voor Nederlandse adressen zou je inderdaad een bot kunnen gebruiken om het adres te genereren en om rapportages te maken over inconsistenties, maar dat neemt niet weg dat beide wenselijk zijn om te hebben. –bdijkstra (overleg) 4 sep 2023 19:27 (CEST)

Hebben ze daar geen templates? Dan zou je bij adres zou kunnen invullen: {{P669}} ((P669|huisnummer}} {{P281}} {{P131}}. Nog beter zou in de definitie van P6375 staan: als a, b, c en d beschikbaar zijn, schrijf dan a b c d.

Als je voor zoiets een bot nodig hebt is dat een lelijke tekortkoming van Wikidata  →bertux 4 sep 2023 21:07 (CEST)

Er zijn geen templates, maar dat is ook niet echt nodig, want veruit de meeste gegevens worden ingevoerd met een bot, of met hulpmiddelen zoals QuickStatements. En zoals ik al schreef, zou zo'n definitie niet gelden voor alle landen. –bdijkstra (overleg) 5 sep 2023 15:20 (CEST)

wikidata 'current' page?

Ik ben aan het experimenteren met wikidata-info ophalen, voor gebruik in wikipedia. Daartoe heb ik de '{{Infobox software}}' sjabloon van de PostgreSQL pagina gekopieerd naar mijn Kladblok3. Maar daarheen gekopieerd verliest het zijn PostgreSQL identiteit. Kan ik die (Q192490 ?) op de ene of andere manier 'SETten', zodat de PostgreSQL (versie)details weer in de box verschijnen? Bedankt! Kweetal nl (overleg) 14 sep 2023 14:21 (CEST)

Specifieke aanroepen naar {{wikidata}} kan je zo voorzien van het juiste item. In andere gevallen zal je de voorvertoning moeten gebruiken op het artikel zelf of via Speciaal:SjablonenSubstitueren. –bdijkstra (overleg) 14 sep 2023 14:31 (CEST)

Die subs-truuk ziet er wel heel handig uit (al doet-ie nu nog niet wat ik wil :P). Bedankt! Kweetal nl (overleg) 14 sep 2023 14:44 (CEST)

PS Ah! de contexttitel moest natuurlijk 'PostgreSQL' zijn; dan wordt de box inderdaad uitgevuld. Handig! Kweetal nl (overleg) 14 sep 2023 14:52 (CEST)

PostgreSQL's beta-loze half jaar

re: laatste_beta_versie in het '{{Infobox software}}' sjabloon:

In PostgreSQL's development cycle is er geen beta gedurende het halfjaar tussen de jaarlijkse release in het najaar (14 sept 2023 = vandaag!) en de eerste beta in het voorjaar (voor een binary van master in die periode wordt men geacht zelf een git-copy te compileren). De hele regel 'laatste_beta_versie' zou dus eigenlijk uit de infobox of sjabloon gehaald moeten worden voor die periode. Is dat enigszins te doen? De 'laatste_beta_versie' in de wikipedia box wijst nu naar 9.6beta1 van jaren geleden (2016) -- misschien ook niet zo'n ramp omdat hopelijk iedereen meteen duidelijk is dat dat fout is. Evengoed zou het mooi zijn als er iets op gevonden kon worden. Kweetal nl (overleg) 14 sep 2023 15:46 (CEST)

Hm. Ik heb op wikidata een 'beta version' gemaakt die '-' heet (die moet staan voor 'geen beta') en die pakt de infobox op (goed). NMaar het passeert de regex die op de naam ligt niet (dus een of andere wijsneus gaat dat item binnenkort ongetwijfeld weer deleten; ik zie ook geen plek om uitleg te geven). Nou ja, niets aan te doen. De werkelijkheid is vaak/altijd anders dan de software engineer dacht. Ah well.. Kweetal nl (overleg) 14 sep 2023 16:44 (CEST)

Die regex kan natuurlijk met '^[-]$' uitgebreid worden. Maar ik wil daar eerst even een wikidata veteraan over horen... Kweetal nl (overleg) 14 sep 2023 16:49 (CEST)

'-' is geen release, dus dat heb ik weer ongedaan gemaakt. De laatste bèta verdwijnt niet omdat er iets gebeurt in de release cycle. Dus ik snap niet wat je bedoelt met "er is geen bèta". –bdijkstra (overleg) 14 sep 2023 19:13 (CEST)

Het is toch wel redelijk eenvoudig: ik bedoel met 'er is geen beta', dat er geen beta is die nieuwer is dan de laatste release (16). Het heeft uiteraard geen zin een oude beta uit 2016 te vermelden. Kweetal nl (overleg) 14 sep 2023 22:16 (CEST)

Je denkt niet tijdloos. Oude informatie vermelden heeft op Wikidata wel zin. Het feit dat er geen bèta is die nieuwer is dan de laatste release, is geen onafhankelijk gegeven, maar iets dat volgt uit de informatie over de laatste bèta en de laatste release. –bdijkstra (overleg) 14 sep 2023 22:22 (CEST)

Uit dat antwoord begrijp ik dat je niet naar de waarden (zoals ze nu op PostgreSQL te zien zijn) hebt gekeken en ik moet toegeven dat het mij zo langzamerhand ook niet meer zo erg interesseert. Misschien kijk ik er volgende release, volgende jaar, weer eens naar. Kweetal nl (overleg) 15 sep 2023 08:27 (CEST)

Tot nu toe ben ik slechts ingegaan op je vraag "Is dat enigszins te doen?" Dat die bèta uit 2016 wordt getoond, is een ander issue. Dat is in principe op te lossen door de laatste bèta 'voorkeursrang' te geven op Wikidata, maar dat zou weer andere problemen kunnen veroorzaken, dus ik weet niet of dat de bedoeling is. Netter zou zijn om een degelijk stukje Luacode te schrijven hiervoor. –bdijkstra (overleg) 15 sep 2023 10:02 (CEST)

Hoe beeld je eenheden verkort af

Na min werk op Sjabloon:Infobox molen ben ik nu aan het uitdagender Sjabloon:Infobox satelliet begonnen.

{{wd|property|Q646764|P2244}} geeft 693 kilometer met als eenheid kilometer, waar eigenlijk km wil. Heeft iemand een tip? SvenDK (overleg) 18 sep 2023 21:36 (CEST)

{{wd|property|raw|Q646764|P2244}}: 693. De km moet je er dan zelf bij zetten. Wikiwerner (overleg) 18 sep 2023 22:40 (CEST)

Dat is inderdaad een mogelijkheid en in dit geval ook bruikbaar, maar ik hoop dat er nog een betere manier bestaat. SvenDK (overleg) 19 sep 2023 22:46 (CEST)

Het kan ook met Module:StringReplace: {{#invoke:StringReplace|replace_all|{{wd|property|Q646764|P2244}}|kilometer|km}} geeft: 693 km. –bdijkstra (overleg) 20 sep 2023 13:42 (CEST)

Deze oplossing vind ik een stuk eleganter. Als er toevallig meter of miles komt, staat er al zeker geen fout. SvenDK (overleg) 20 sep 2023 21:16 (CEST)