Wikipedia:Wikidatafrågor

Lägg till länkar
Från Wikipedia
Kontakta Wikipedia
Frågor

Bildfrågor · Faktafrågor · Fikarummet · Persondatafrågor · Vanliga frågor · Wikidatafrågor · Wikipediafrågor · Översättningsfrågor

Kontakt

Anmäl ett fel · Bybrunnen · Faddrar · IRC · Kontakt · Pressfrågor · Wikipedia i media · Wikiträffar

Deltagarsidor
Grundprinciperna
Policy och riktlinjer
Kontakt och frågor
Introduktion
Handbok
Lägga till bilder
Att göra
Deltagarsidor
Viktigt
Kontakt och frågor
Skriva och redigera
Lägga till bilder
Att göra
visa • redigera
 Arkiv för denna sida     Genväg WP:WD
Wikidatafrågor
Frågor om hur Wikidata fungerar
Deltagarsidor
Grundprinciperna
Policy och riktlinjer
Kontakt och frågor
Introduktion
Handbok
Lägga till bilder
Att göra
Deltagarsidor
Viktigt
Kontakt och frågor
Skriva och redigera
Lägga till bilder
Att göra
visa • redigera
Vikning av mappar för datalagring 1917.

Här går det att ställa frågor om hur Wikidata fungerar och om vad som är brukligt. Både rena nybörjarfrågor och frågor från dem som varit med ett tag är välkomna. I de flesta fall droppar svar in inom någon timme. Frågor som visar sig återkomma ofta kan läggas till på listan med vanliga frågor och svar.

Signera ditt inlägg med fyra tilde (~~~~) så skapas signatur med tidpunkt automatiskt. Tänk på att inte signera med e-postadress, telefonnummer, bostadsadress och annat som du inte vill ska spridas över Internet.

Ställ din fråga genom att klicka här
Sidan är till för frågor om Wikidata och hur innehåll där ska adderas eller kompletteras. Det går naturligtvis att fråga vad som helst var som helst, men så här blir det lite precisare:
Fler frågemöjligheter

Du kan också ställa frågor kring Wikidata på:

I sämsta fall får du inget svar, i bästa fall får du ett eller en hänvisning någonstans.

Det finns arkiv för denna sida.
Diskutera inte på arkivsidor. Starta istället en ny diskussion under ny rubrik.
Den här sidan arkiveras automatiskt av roboten EnBotEn efter 70 dagar.

Botkörning o dyl för sammanslagningar av objekt?[redigera | redigera wikitext]

Det finns i skrivande stund 1871 Lsjbot-artiklar om Kina som inte ens länkar till cebWP. Skulle det vara möjligt att formulera en botkörning eller något ditåt som slår ihop WD-objekt där följande gäller:

  1. Det ena objektet länkar endast till svWP
  2. Det andra objektet länkar endast till cebWP
  3. De uppger samma värde på | geonames =

Objekt där det andra villkoret inte är uppfyllt skulle också vara intressanta att identifiera men där kanske sammanslagningen bör göras manuellt för säkerhets skull. //Essin (diskussion) 5 februari 2024 kl. 19.29 (CET)[svara]

Det låter som en mycket bra idé, det verkar ha skett en omfattande miss där. Men bra om vi undersöker rejält före så att vi är 100 % säkra på att det blir rätt. Jag minns ett fall där det blev rejält förvirrat då ett objekt på något sätt länkats om och kopplats felaktigt till ett objekt från kinesiska wikipedia. En kinesisk användare och jag och en till person från svenska wikipedia försökte bägge fixa till det, men från varsin horisont. Det tog ett bra tag innan vi ömsesidigt kom fram till att den andra inte var någon vandal.. (med flyttar kan wikidatas loggar lätt bli rejält svårföljda). Gunnar Larsson (diskussion) 6 februari 2024 kl. 15.10 (CET)[svara]
Ja, det är delvis därför som jag tänkte att det är säkrast att inte involvera icke-robotskapade artiklar i en robotkörning. Jag har börjat titta på cebWP-artiklar om "orter" och "indelningar" i Kina som inte länkar till svWP men som länkar till andra WP-upplagor, och har hittat rätt många som har länkats till zhWP och verkar vara okontroversiella. Där de länkar till andra språkversioner finns det skäl att se upp för konstiga omdirigeringar på svWP, åtgärdade Geonamesrelaterade fel mm. Det finns också några fall där artiklarna har gamla sortens iw-länkar som pekar fel, ofta för att cebWP-artikeln skapades senare med ett annat namn än planerat. Jag tror att det är ett liknande problem som ligger bakom röda grensideslänkar till "sockenhuvudorter" som hann uppgraderas till "köpinghuvudorter" mellan varven, se Wikipediadiskussion:Projekt alla platser-städning/Arkiv 2021#Kina osv.
Jag bör förresten förtydliga att med "De" i punkt 3 menar jag de kopplade artiklarna, inte själva WD-objekten som i många fall saknar Geonames-parameter. //Essin (diskussion) 6 februari 2024 kl. 16.08 (CET)[svara]
Tittade på Qibu vars geoname är <ref name = "gn1798095">[{{Geonameslänk|gnid=1798095|name=qibu}} Qibu] hos [{{Geonamesabout}} Geonames.org (cc-by)]; post uppdaterad 2012-01-18; databasdump nerladdad 2016-03-31</ref>. Geoname togs bort från infoboxen eftersom den inte fanns något wikidataobjekt för geoname 1798095 innan oktober 2022. Qibu (Q11180210) och Qibu (Q10864673)n i ceb har redan länkar med sv. En jättebra lista att beta av manuellt men troligen inte något för en robot. Vet inte varför lsj inte skapade grensidor för Kina.
  • Qibu geoname 1798095
  • Qibu (sockenhuvudort i Kina, Jiangxi Sheng, lat 28,72, long 116,86) ‎geoname 1798093
  • Qibu (köpinghuvudort i Kina, Fujian Sheng, lat 27,08, long 119,34) ‎geoname 1798094
Bägge de långa har interwiki med zh. På en karta ligger alla tre på olika platser. Maundwiki (diskussion) 6 februari 2024 kl. 19.12 (CET)[svara]
Tack för påpekandet att det är bättre att leta efter \<"gn.*\>" än i infoboxen.
I just det här fallet skulle varken det ursprungliga eller det modifierade tredje villkoret vara uppfyllt eftersom någon cebWP-artikel om 1798095 aldrig verkar ha funnits, ceb:Qibu har alltid omdirigerat till cebWP-artikeln om 1798093. Den artikeln var dock (av allt att döma felaktigt) WD-kopplad till svWP-artikeln om 1798095, inte till svWP-artikeln om 1798093, fram till oktober 2022, dvs när infoboxparametern togs bort med bot. Efter att 1798093 fördes ihop till Qibu (Q11180210) blev Qibu utan WD-objekt och Qibu (Q114861447) skapades. Detta fall är alltså inte ett argument mot botkörning.
Det finns närmare 200 artiklar om "orter" och "indelningar" på cebWP som länkar till någon annan WP-upplaga men inte svWP, så även om säg 5 % av de kvarvarande ~1600 utan iw-länkar på cebWP har problem med Geonames och därmed stoppas av villkor 3 skulle en botkörning vara värdefull. //Essin (diskussion) 7 februari 2024 kl. 11.20 (CET)[svara]
Som t.ex. att slå ihop Pingba (Q31853002) och Pingba (Q49287966) med bot i wikidata baserat på att de har samma geoname i noten i artiklarna? Via 坪坝镇 kanske interwiki med. Men "härad" är inte samma som (troligen) är ett fel i geonames. Det finns inga härader för Chongqing i geonames "drop down list" förutom Chongqing. Går andra steget att göra med en bot? Kanske lista något som är nära? Det var hur jag från två artiklar på en förgreningssida i zhwp fick fram förslaget på interwiki. Många av dessa Kategori:Wikipedia:Artiklar med geonames-parameter utan P1566 på Wikidata när de är artiklar om Kina borde vara samma som i petscanlistan. Maundwiki (diskussion) 7 februari 2024 kl. 14.47 (CET)[svara]
Ja, precis så med Pingba. För matchning med zhWP i ett tänkbart nästa steg behövs en djupare analys av hur Geonames och Lsjbot har (miss)tolkat Kinas geografiska och administrativa struktur, förmodligen också kunskaper i kinesiska. Utifrån det jag har läst på Wikipediadiskussion:Projekt alla platser-städning förstår jag att det finns problem, men jag är inte tillräckligt insatt för att föreslå en lösning. //Essin (diskussion) 7 februari 2024 kl. 15.47 (CET)[svara]
Stora jobbet är att matcha, att fixa wikidatalänker går fort. I vilket fall är de två inte en match med (Q10928852) eftersom det är en köping (Q735428). Möjligen kan Pingba (Q31853002) (orten) vara inom det administrativa området (P131) (Q10928852) (köpingen). Svenska arikeln bör ha en annan källa om det länkas till köpingen. Om vi skriver om svenska orten till köpingen så bör den inte ha interwiki med cebartikeln om orten. Maundwiki (diskussion) 7 februari 2024 kl. 20.00 (CET)[svara]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Jag har inte läst och förstått alla detaljer in diskussionen ovan, men om det skulle vara till någon hjälp att få en lista över robotskapade Kinaartiklar i cebwp och svwp som var och en helt saknar interwiki men i wikitexten har en <ref name = "gn<geonames ID>"> med samma värde på <geonames ID> så kan jag bjuda på en tabell som innehåller 1 450 rader med följande kolumner:

  • Geonames ID
  • Cebwp-artikel (wikilänkad) med referens till detta Geonames ID
  • Wikidataobjekt som är kopplat till denna cebwp-artikel
  • Svwp-artikel (wikilänkad) med referens till detta Geonames ID
  • Wikidataobjekt som är kopplat till denna svwp-artikel

Tabellen är framtagen på följande sätt:

  1. Skapa en tabell över svwp-artiklarna i sv:Kategori:Robotskapade Kinaartiklar som saknar interwiki med uppgift om geonames-id i en referens med format enligt ovan.
    Av 21 954 artiklar var det 1 735 som uppfyllde dessa kriteria.
  2. Skapa en tabell över cebwp-artiklarna i ceb:Kategoriya:Pangmasang Republika sa Tśina paghimo ni bot som saknar interwiki med uppgift om geonames-id i en referens med format enligt ovan.
    Av 36 594 artiklarna var det 15 794 som uppfyllde dessa kriteria.
  3. Samkör de två tabellerna för att hitta artiklar med ett gemensamt geonames-id.
    Det fanns alltså 1 450 artikelpar som hade gemensamt geonames-id i referensen.

Bland dessa finns det dock några där geonames-id i artiklarna inte stämmer med värdet på Geonames-ID (P1566) i de kopplade Wikidataobjekten. De kan också ha olika värden på egenskapen instans av (P31) och det förekommer också att det helt saknas värde på instans av (P31) i något eller båda Wikidataobjekten. Innan man slår ihop några av dessa objekt-par i Wikidata behöver man nog kontrollera vad det egentligen är för slags "plats" som beskrivs i de två artiklarna och vilken "feature" som respektive geonames-ID avser.

--Larske (diskussion) 8 februari 2024 kl. 00.28 (CET)[svara]

Tack Larske, den tabellen är en utmärkt utgångspunkt.
  • Om Geonames-ID skiljer sig åt behöver det kontrolleras manuellt vad som hänt, en tabell över sådana fall skulle också vara användbar.
  • Olika värden på P31 beror antagligen på osystematisk manuell inläggning av P31, men kanske ändå helst bör kontrolleras och åtgärdas innan robotkörning.
  • Saknat P31 är bara ett tecken på att WD-objekten för Lsjbot-artiklar generellt är ganska dåliga, det behöver inte fixas innan sammanslagning.
  • Typ av plats kanske bäst jämförs med den Geonames-platskod som finns utkommenterad tidigt i brödtexten, t ex <!--P.PPLA4--> som i ceb:Baiyi (kapital sa baranggay sa Pangmasang Republika sa Tśina, Hunan Sheng, lat 29,46, long 111,87) står direkt efter geoboxen och i Baiyi (köpinghuvudort i Kina, Hunan Sheng, lat 29,46, long 111,87) efter ''' är .
  • Posterna där ett Q-nummer eller båda är utanför de vanliga intervallen (31847701-31856556 för svWP, 34848592-34849843 och 49007024-49467184 för cebWP) ser suspekta ut efter ett par stickprov, och jag kommer att gå igenom samtliga manuellt.
  • Någon verkar ha gått igenom platsnamnen på A-M redan.
Maundwiki, förstår jag det rätt att du utgår från att Geonames objektsklassificering är pålitlig? Jag har som sagt inte detaljkunskaper om Kina utanför Wikipedia, men intrycket jag har fått från diskussioner (t ex 1, 2, 3, 4) bland insatta användare är att om namn och koordinater används som identifiering har klassificeringen i Kina stora systematiska fel -- Roufu eller Bairuilong kan kanske fylla i med detaljer. Det stämmer också med mina erfarenheter från områden där jag är mer påläst, t ex Kanada och Finland. En djupare analys behövs som sagt, om/när vi går vidare till det steget. //Essin (diskussion) 8 februari 2024 kl. 11.22 (CET)[svara]
Jag har nu kompletterat tabellen med kolumner för geonames-platstypkoder från Wikipedia-artiklarna och värden på instans av (P31) från motsvarande Wikidata-objekt. Jag utgick ifrån den tidigare tabellen och fann då att några sammanslagningar redan är gjorda under dagen. Dessa artikelpar är utbrutna till en separat tabell.
-- Larske (diskussion) 8 februari 2024 kl. 15.17 (CET)[svara]
Tack! Jag ögnade igenom den snabbt och det verkar inte finnas några motsägande platstypkoder. De ovanliga värdena på P31 är så få att jag redan har hanterat dem manuellt (på Sifangtai (berg i Kina) (Q28805000) och Hsi-ku (Q29620756) såg det ut som att cebWP-länken hade hamnat på fel objekt, sen var det bara fyra där svWP-länkade objekt hade P31). Finns det någon motsvarighet på cebWP till Kategori:Wikipedia:Artiklar där geonames-parametern och P1566 på Wikidata inte överensstämmer, och ligger några av de här aktuella artiklarna i den? //Essin (diskussion) 8 februari 2024 kl. 15.53 (CET)[svara]
Nej, den åtgärdskategorin tror jag inte finns i cebwp. Kategorin sätts i svwp med ett anrop från mallen Geobox till funktionen tracking som finns i modulen P1556. Motsvarande modul i cebwp har inte den funktionen.
Bland de robotskapade Kinaartiklar i cebwp som jag undersökte igår fanns det bara två som skulle har ramlat in i en sådan åtgärdskategori och det ser ut som du har redan har pysslat om dem lite idag:
som tidigare var kopplade till två olika objekt. Nu är de båda kopplade till d:Q31854956, ett objekt som saknar det mesta, till exempel Geonames-ID (P1566). Jag noterar att inte ens Geonames idag vill kännas vid detta ID, se länk, så frågan är varifrån det kommer.
som tidigare var kopplade till två olika objekt. Nu är båda kopplade till Zhouqu Chengguanzhen (Q31852121), ett objekt som också är mycket magert men där du ändå har lagt in nämnda Geonames-ID (P1566)
-- Larske (diskussion) 8 februari 2024 kl. 17.32 (CET)[svara]
Genoames är både pålitlig och totalt skräp. Allt beror på källorna geonames använde för att skapa databasen. För Sverige t.ex. "http://www.bebyggelseregistret.raa.se", "http://www.lantmateriet.se/" etc. som vi tycker är ganska bra. Längst ner finns globala källor som jag tror (inga bevis) orsakat mycket av felen. En som jag inte alls litar på är "worldgazetteer" ofta en ort mitt i skogen med mycket folk men mycket svårt/omöjligt att hitta vad det kan vara.
Jag litar på att de lsjbotskapade artiklarna är en kopia av geonames och platstypen bestämd av GeoNames Feature Codes som databasen såg ut 2015/2016.
Jag litar inte på hur Valterbot 2014 la till geoname i wikidatobjekt. Platstypen stämde inte med innehållet i instans av (P31) när det gjordes 2014.
Ett följdfel av Walterbots införande av fel geoname var fel interwiki för lsj skapade artiklar eftersom botarna matchade på geoname. Det gav upphov till att fel artikel togs bort t.ex. kommunartikeln när det skulle varit ortsartikeln. Exempel Österrike (ångrar att jag inte begärde återställning men var för lat).
Vi hade en lista på vilka som hade fel interwiki, olika geoname i wikidata och lsj's källa från geonames (infoboxen), men på svenska wikipedia kördes den bort av en bot som tog datat från wikidata (litade på valterbot inte lsjbots källa).
Jag litar inte på att platstypen är rätt i geoname men den är vad den är skapad för i artikeln enligt källan geonames. Finns den så kan den vara kvar eller raderas beroende på relevans, men den bör inte göras om till något annat med geoname som källa för en annan platstyp. T.ex. Pingba (se ovan) en ort (PPL) enligt geonames och hur det ser ut på kartor troligen sant enligt hur vi ser på orter. I geonames finns inte köpingen (ADM?) (i Kina en adminenhet inte ort). Tror att data saknas i geonames för mycket i det området. Om vi vill skriva om köpingen bör vi ha en källa för det och börja en ny artikel. Om orten inte är relevant bör den raderas. Men vi ska inte tolka att den är något annat än det geonames anger och framför allt ska vi inte lägga till ett geoname i wikidataobjektet som inte är samma platstyp som instans av (P31).
Samma gäller för andra nivåer. Det är mycket lättare att lösa detta om wikidata är uppdaterad enligt något liknande SCB för landet. Jag har get upp om det inte finns bra wikidata för de olika adminnivåerna. Mina försök att fixa slutar vanligen på lägsta admin nivån.
Som jag tolkade diskussionen om Kina så gällde det att fixa inte titta på om källan geonames var rätt eller fel. Jag tyckte det fixades utan att ta hänsyn till att artiklar var skapade via geonames med en viss platstyp men följde det inte eftersom min kunskap i kinesiska är begränsad till vad Ctrl-F och google kan hjälpa till med.
Det jag saknar i din lista ovan är inom det administrativa området (P131) för admin ovan objektet men efter det ser jag inget problem med att slå samman wikidata object skapade ur samma geoname id när det enbart är artiklar i sv och ceb. Att lägga till P131 baserat på koord kan ge problem eftersom koord för PPL kan vara fel. Det har skett i geoname men det gick fel när t.ex. "worldgazetteer" inte hade koord för en "riktig" ort. P131 bör troligen göras av en person. Jag har därimot problem med att ändra svwp till något annat med samma geoname id.
Maundwiki (diskussion) 8 februari 2024 kl. 17.47 (CET)[svara]
Jo, jag kom på efter att jag ställt frågan om P1566 att om cebWP hade en sån kategori skulle t ex ceb:Nangu (kapital sa baranggay sa Pangmasang Republika sa Tśina, Gansu Sheng, lat 38,54, long 100,46) ligga i den, eftersom Nangu (köpinghuvudort i Kina, Gansu Sheng) hamnade där efter att jag slog ihop Nangu (Q31853051) med Nangu (Q10907108) som redan hade två värden på P1566.
Jag noterade också att 2035677 hade försvunnit från Geonames och därför la jag inte in det på Naji (Q31854956). Egentligen borde det väl flaggas på något sätt. I det här sammanhanget vill jag upprepa vad jag har sagt i ett annat sammanhang om mitt arbete med botstädning: jag är sällan kapabel att åstadkomma ett bra resultat, det skulle kräva för mycket arbete. Däremot strävar jag efter att resultatet alltid ska vara bättre än tidigare, och att det hjälper senare redigerare att göra ytterligare förbättringar. Jag antar att det är någon sorts eventualism, och att jag har gjort en dygd av nödvändigheten för att inte bli desperat och sluta redigera WP helt.
Geonames kvalitet beror inte bara på källorna utan också på hur de har tolkats i Geonames. Objektstyperna är väl inte så standardiserade att alla källorna använder dem också? Risken för systematiska fel är stor när en källas objektstyper ska kopplas till Geonames objektstyper, och jag misstänker att det är en sak som har gått fel i Kina. Skillnaden mellan "ADM" och "PPL" är inte alltid så glasklar som man kan tro. Jag är därför helt emot att vi ska låta Geonames struktur ensam styra WP:s och WD:s struktur, även om vi förstås så långt det är möjligt bör koppla WD till Geonames.
Om vi nu fokuserar på det ursprungliga förslaget, som inte innehåller några avvikelser från Geonames: Visst kan en jämförelse av provinskategorierna i resp WP-upplaga och i förekommande fall P131 vara av godo, även om jag inte förväntar mig några diskrepanser. Sedan borde det vara klart att slå ihop WD-objekten på den återstående listan. //Essin (diskussion) 9 februari 2024 kl. 13.00 (CET)[svara]
@Larske: Behövs det ytterligare kontroll, eller är det klart att köra? Hur gjorde du vid ett liknande fall 2021? Wikidata:Help:QuickStatements? //Essin (diskussion) 21 februari 2024 kl. 12.02 (CET)[svara]
Efter att ha brottats en del med QuickStatements och rensat ut de WD-objekt som slogs ihop under tiden tror jag att jag lyckades genomföra en körning ordentligt. Jag ska titta lite på restposterna och se om det går att göra något för hand, återkommer eventuellt med frågor om andra databassökningar. //Essin (diskussion) 29 februari 2024 kl. 11.00 (CET)[svara]
@Larske: Det skulle vara intressant att få två listor över objekt som uppfyller samma villkor 1 och 3, men där villkor 2 är utbytt mot å ena sidan "Det andra objektet har iw-länkar till cebWP och andra upplagor men inte till svWP" och å andra sidan "Det andra objektet har iw-länkar till cebWP och andra upplagor, inklusive till svWP". Särskilt den senare skulle förmodligen mest innehålla felmatchningar. Jag har också hittat en del fall där Lsjbot (ofta felaktigt) har trott att en redan existerande svWP-artikel handlat om ett visst Geonames-objekt och omdirigerat dit, men sådana är kanske svårare att identifiera automatiskt. //Essin (diskussion) 29 februari 2024 kl. 13.41 (CET)[svara]
@Essin: Det verkar ha hänt en hel del de senaste tre veckorna. Den tabell på 1 450 rader som jag tog fram 8 februari har nu reducerats till en enda rad.
  • Antalet artiklar i Kategori:Robotskapade Kinaartiklar har minskat till 21 903 (från 21 954)
    • Av dessa är det nu 240 (tidigare 1 735) som saknar interwiki med uppgift om geonames-id i en referens med format enligt ovan.
  • Antalet artiklar i ceb:Kategoriya:Pangmasang Republika sa Tśina paghimo ni bot är oförändrat 36 594
    • Av dessa är det nu 14 054 (tidigare 15 794) som saknar interwiki och har en uppgift om geonames-id i en referens med format enligt ovan.
  • Det finns nu alltså bara 1 artikelpar som har ett gemensamt geonames-id i sina referenser, men som alltså båda saknar interwiki.
Detta artikelpar, som båda har 1783626 som geonames-id är:
Både d:Q31852102 och d:Q29622550 är extremt magra Wikidataobjekt som inte ens har något värde på egenskapen instans av (P31).
I det sistnämnda var du själv inne och ändrade Geonames-ID (P1566),
  • från 9972733 (som i Geonames är en ADM3 som heter Kangxian)
  • till 1783626 (som i Geonames är en PPLA3 som heter Longnan Shi Zuitai korrigering, jag läste på fel rad i Geonames).
Ovanstående är mer som en uppföljning av mitt tidigare inlägg än ett svar precis på dina senaste frågor, men här är några PetScan-frågor som kanske kommer i närheten.
När du skriver "har iw-länkar till cebwp och andra upplagor", hur ska man tolka det kursiverade? Jag har tolkat det som att antalet andra upplagor kan vara vilket antal som helst, från 0 och uppåt, men man skulle också kunna tolka det som att det ska vara minst 1 annan upplaga förutom cebwp. Eller minst 2 andra upplagor...
Jag antar också att det är går bra att utgå från artiklarna i Kategori:Robotskapade Kinaartiklar och motsvarigheten i cebwp.
Det som saknas ovan är en jämförelse mellan geonames-referenserna i de 22 035 cebwp-artiklarna som har iw-länk till svwp och geonames-referenserna i motsvarande svwp-artiklar. Så här kommer det:
Av de 22 035 cebwp-artiklarna som har iw-länk till svwp är det
  • 2 797 som saknar en geonames-referens i svwp artikeln
  • 19 238 som har en geonames-referens i svwp artikeln. Av dessa är det
    • 18 874 som har samma geonames-referens i svwp-artikeln och i cebwp-artikeln
    • 254 som har en annan geonames-referens i svwp-artikeln än i cebwp-artikeln. Av dessa är det
      • 108 som har samma geonames-referens i svwp-artikeln som Geonames-ID (P1566) i det länkade Wikidataobjektet
      • 146 som har en annan geonames-referens i svwp-artikeln än Geonames-ID (P1566) i det länkade Wikidataobjektet. Av dessa är det
Det är väl de 146 som kan vara värda en närmare titt och som kan behöva en åtgärd i svwp och/eller Wikidata.
Notera att ett antal av dessa artiklar har "botstädats" genom att parametern geonames tagits bort från anropet av mallen {{Geobox}} då dess värde inte överensstämde med Geonames-ID (P1566) för det kopplade Wikidataobjektet. I faktarutan hämtas därmed Geonames id från Wikidata, men i geonames-referensen i svwp-artikeln ligger det gamla värdet kvar. Se till exempel historiken för Yixi.
-- Larske (diskussion) 1 mars 2024 kl. 13.07 (CET)[svara]
Angående Zuitai: Geonames 1783626 heter Zuitai men ligger i Longnan Shi. Det var tidigare ett fall av felaktig matchning men jag missade tydligen att slutföra uppstädningen. Tack för att du upptäckte det!
Med och andra upplagor menade jag och minst en annan upplaga. Jag ska titta på "de 146" senare. Om det går att identifiera om några av "de 411" har samma Geonames-referens som några av "de 240" skulle det också vara värdefullt. //Essin (diskussion) 1 mars 2024 kl. 13.28 (CET)[svara]
Ja, det finns tre av "de 411" som har samma geonames-referens som någon av "de 240" (som nu har blivit 239), nämligen
Larske (diskussion) 1 mars 2024 kl. 14.40 (CET)[svara]
Tack, jag har nu slagit ihop de tre. Något som skulle vara mycket praktiskt är om det går att utöka tabellen över "de 411" (nu förstås 408) med en kolumn med vilken eventuell annan svWP-artikel (bland "de 240", nu 236) som har samma Geonames-referens som cebWP-artikeln, samt dennas WD-objekt. //Essin (diskussion) 1 mars 2024 kl. 17.06 (CET)[svara]
Jag gjorde en kontroll över de cebwp-artiklar som ingår i "de 411" och kollade om de var kopplade till ett Wikidataobjekt som hade ett Geonames-ID (P1566) som även förekommer i något annat Wikidataobjekt som i sin tur är kopplat till en svwp-artikel. Det blev 72 träffar:
  • Länk till fråga som ger en lista på 72 cebwp-artiklar som den 1 mars 2024 hade iw-länk till minst en annans språkversion men inte till svwp och där det kopplade Wikidataobjektet har samma värde på Geonames-ID (P1566) som ett annat Wikidataobjekt som är kopplat till en svwp-artikel.
-- Larske (diskussion) 1 mars 2024 kl. 19.14 (CET)[svara]
Jag tänkte iofs på andra svWP-artiklar som källhänvisar till samma Geonames-ID, men den här listan är också användbar. Många av posterna har uppkommit för att WD-objektet för enheten A var taggat med Geonames-ID för dess huvudort B (vad "huvudort" betyder i just det här sammanhanget är irrelevant). Eftersom enheten A nästan alltid hade en svWP-artikel redan har Lsjbot omdirigerat alla tänkbara alternativa namn på B till A istf att skapa en artikel om B. Därför behövs följande åtgärder:
  1. Ta bort felaktigt Geonames-ID från WD-objektet för A
  2. Identifiera namn på B bland omdirigeringarna och grensidorna som hänvisar till A och radera dem
  3. Identifiera Lsjbots namn på A bland omdirigeringarna till A och därmed hitta artikeln om A på cebWP
  4. Slå ihop WD-objektet för cebWP-artikeln om A (inkl korrekt Geonames-ID) med det allmänna WD-objektet för A, om det inte redan har gjorts
Jag har börjat beta av dem men det kommer att ta ett tag. //Essin (diskussion) 1 mars 2024 kl. 22.18 (CET)[svara]
I Sandlådan finns nu en tabell med en delmängd av "de 411" cebwp-artiklarna som har minst en iw-länk, men inte till svwp, där det finns sidor i svwp som har en referens till samma geonamespost som cebwp-artikeln. Det är totalt 94 sidor varav 17 artiklar och resten "dubblettsidor" under Ljsbot:s användarsida.
Här krävs möjligen lite extra analys för att det ska bli rätt i och med att det ibland är många språkversioner som är kopplade till samma objekt. Se till exempel de två objekten
  • d:Q11151015 (med Geonames 1809104)
  • d:Q393454 (med Geonames 1809103, men där den till detta objekt kopplade svwp-artikeln har en referens till 1809104)
Eftersom cebwp, enwp och zhwp har separata artiklar för de två objekten kan man inte bara slå ihop objekten.
-- Larske (diskussion) 2 mars 2024 kl. 12.43 (CET)[svara]
Tack, det var tyvärr inte mycket "lågt hängande frukt" där...
I just fallet du tar upp är det möjligt att Haidian (häradshuvudort i Kina, Beijing Shi, lat 39,99, long 116,29) har blivit felaktigt infogad eftersom enheter på två nivåer har samma namn, men eftersom jag inte kan kinesiska kan jag inte vara säker och Geonames verkar inte riktigt heller veta vad skillnaden är. Även andra fall där båda WD-objekten har en zhWP-länk skulle behöva kinesiskkunskaper. I de fall där båda objekten har arzWP-länkar tror jag att Wikimedia-dubblett (Q17362920) är rätt lösning. Lsjbot-dubbletterna ser i många fall ut att vara symtom på samma problem som ovan med Geonames-ID på fel objekt, så jag kan använda dem för att spåra felaktiga omdirigeringar men jag låter dem ligga kvar i användarnamnrymden – den som vill ta på sig att städa upp dem kan flytta dem. //Essin (diskussion) 2 mars 2024 kl. 16.01 (CET)[svara]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Jag har gått igenom "de 72" och åtgärdat fallen som berodde på felaktigt Geonames-ID på WD, oftast enheter på häradsnivå som nu i högre grad har ett ADM-Geonames-ID på WD, till glädje för Maundwiki antar jag. De svårare fallen, som i hög grad överlappar med "de 94", har jag lämnat åt sidan.

Jag har också återvänt till "de 146" och fixat de uppenbara fallen där artikelnamnet utan särskiljning var olika på svWP och cebWP. De ser ut att ha berott på att två Geonames-poster A och B fick separata artiklar på svWP men av någon för mig obegriplig anledning omdirigerades B till A av Lsjbot på cebWP, därefter skapade Emausbot ett WD-objekt med cebWP:s artikel A och svWP:s artikel B, i fortsättningen kallat "A/B-objekt". Dessa objekt har sedan fyllts på med en röra av uttalanden från respektive håll – ofta är objekten till och med i olika provinser! Även många av fallen med samma osärskiljda namn ser ut att ha samma problem, men här tillkommer svårigheten att en del av dem är "nästan-dubbletter" pga att distinktionen mellan PPL och ADM i Kina i praktiken inte är väldefinierad. En hel del av A/B-objekten har också fått ytterligare iw-länkar, ofta till zhWP, där det krävs närmare studier, förmodligen av någon kinesiskkunnig, för att avgöra om de övriga iw-länkarna handlar om A eller B (eller kanske båda, pga dubblett eller nästan-dubblett på Geonames). Det finns dock en grupp som borde gå att hantera automatiskt med QuickStatements, nämligen de A/B-objekt som endast iw-länkar till ceb och sv. De är för närvarande 88 stycken. Det som behöver göras först är att identifiera svWP-artiklarna med Geonames-ID från mängden av A, och vilka WD-objekt som är kopplade till dem, dvs "A-objekt". En del av dessa objekt är antagligen redan matchade till zhWP men det kan i så fall bara vara baserat på en matchning zh–sv och bör inte orsaka problem.

Sedan behöver följande saker flyttas från A/B-objektet till A-objektet:

Dessutom bör Geonames-ID (P1566) importerat från cebWP strykas och ersättas av Geonames-ID (P1566) enligt svWP, med "anges i GeoNames" som källhänvisning. Allt detta går förmodligen att göra med QuickStatements men jag vet inte hur utan att studera dokumentationen.

När A/B-objekten har renodlats till B-objekt med endast svWP-länkar går det ofta att identifiera mer utförliga B'-objekt om samma ämne med länkar till zhWP, men den identifieringen behöver antagligen göras för hand. //Essin (diskussion) 3 mars 2024 kl. 16.05 (CET)[svara]

Efter att ha kollat lite mer i QuickStatements-dokumentationen har jag fått intrycket att "flytta" inte finns inbyggt, utan att man i så fall behöver söka ut egenskaperna som ska flyttas till en separat fil innan de tas bort från A/B-objekten och läggs till A-objekten med QuickStatements. Det är med andra ord knöligare än jag trodde och jag skulle vara tacksam om någon som har mer koll på Wikidata tar hand om det. //Essin (diskussion) 3 mars 2024 kl. 17.55 (CET)[svara]
Nu har jag gjort detta för hand (A-objekten gick ofta att hitta med Länkar hit, annars med PrefixIndex). Jag har också identifierat några B'-objekt med hjälp av OSM. Det finns 3958 artiklar om administrativa enheter som är matchade till ceb men inget annat och där OSM-metoden också skulle kunna göra nytta, men det är ett mycket större jobb och man råkar ganska ofta ut för att enheten inte alls går att hitta på OSM, att WD- eller WP-länken inte är inlagd på OSM eller ort/kommun-problemet. Det är dock inte enbart en WD-fråga längre. //Essin (diskussion) 4 april 2024 kl. 09.27 (CEST)[svara]

Scott Baio[redigera | redigera wikitext]

Jag undrar varför Faktamall biografi WD i Scott Baio visar 1961 som födelseår, när 1960 finns på wikidata som det första alternativet för födelseår med två källor, jämför med 1961, som på wikidata är det andra alternativet med en källa? Lade märke till att alternativet 1960 på Wikidata är svagt tonat i rosa, betyder det något? Höstblomma (diskussion) 11 februari 2024 kl. 15.15 (CET)[svara]

Ja, den rosa tonen kommer sig av att någon har givit det uttalanden "Orekommenderad rang", se denna diff. Sådana värden ratas av mallen.
Du kan se vilken "rang" som ett uttalande har genom att titta på symbolen som finns alldeles till vänster om värdet. Symbolen består av tre delar, en triangel med en spets uppåt, en cirkel och en triangel med en spets nedåt. En av dessa tre delar är ifylld.
  • Om den översta delen är ifylld har uttalandet "Föredragen rang" ("Recommended rank" på engelska) och uttalande har även en ljusgrön bakgrundsfärg
  • Om den mittdelen är ifylld har uttalande "Normal rang" ("Normal rank")
  • Om den under delen är ifylld har uttalandet "Orekommenderad rang" ("Deprecated rank") och uttalandet har även en rosa bakgrundsfärg.
Du kan läsa mer om Rang på den här hjälpsidan.
-- Larske (diskussion) 11 februari 2024 kl. 15.29 (CET)[svara]
Tillägg: Det kan finnas många skäl till att ge ett uttalande i Wikidata "Orekommenderad rang" och när man gör det bör man också lägga till en bestämning, skäl för lägre rang (P2241) till varför man gör det, se till exempel här. Om man bara tar bort ett felaktigt uttalande finns det stor risk att det förr eller senare läggs in igen, speciellt om det finns källor som anger ett felaktigt värde.
--Larske (diskussion) 11 februari 2024 kl. 15.46 (CET)[svara]
Tillägg 2:Ovanstående beskriver hur man kan arbeta med "rang" i allmänhet. Att använda andra Wikimediaprojekt, till exempel enwp, som källa till påståenden i Wikidata är något som bör undvikas på samma sätt som att vi inte använder sådana källor i Wikipedia.
Att detta är en god regel framgår tydligt av detta exempel där den källa till födelsedatum för Scott Baio/Scott Baio (Q1276587) är just av typen importerat från Wikimediaprojekt (P143). Just nu är det tyskspråkiga Wikipedia som anges som källa, men det är lika illa vilken språkversion man än väljer. En möjlig anledning till nedvärderingen av uppgiften om 1960 som födelseår kan vara att Twitter (X) i regel inte anses vara en trovärdig källa.
För att undersöka hur födelsedatum har varierat i artikeln om denna person i engelskspråkiga Wikipedia har jag tittat på de 2 518 versionerna av en:Scott Biao. Av dessa versioner är det 247 som har ändrat i den text som står mellan "born" och "is an", alltså födelsetiden. Ett lågintensivt redigeringskrig med olika källor som stöd blandat med klotter och korrigeringar av typos har pågått under mer än 17 år. Datumet 22 september verkar stabilt med enstaka utflykter till 21 september eller 23 september och året har oftast varit 1960 eller 1961, men även 1970, 196i och 1962 har förekommit liksom enstaka "icke-numeriska värden" har förekommit. Om man då använder en version av en sådan "instabil" Wikipediasida som källa är risken mycket stor att uppgiften är felaktig (när man hämtar den) och blir kvar i Wikipediaobjektet även efter det att Wikipediasidan har rättats.
Jag har i Sandlådan sammanställt "födelsetidstexten" för de 247 enwp-versioner där denna har ändrats. I revisioner där det står "hittade inget" i den högra kolumnen betyder det att texten "born" eller "is a" inte står att finna, några gånger för att texten har dolts, i den revisionen. Notera att källor för födelsetiden började användas i oktober 2018.
--Larske (diskussion) 11 februari 2024 kl. 19.10 (CET)[svara]
Tack Larske för ett bra svar och ditt fantastiska arbete med historik-kontroll! En ny lärdom om wikidata för mig som definitivt var nyttig. Jag känner inte till den användare som rankat uppgifterna på Wikidata, men 1960 verkar för mig inte ha sämre källor än 1961 - så om min ändring i artikeln borde återställas är jag osäker på. Eftersom enwp har 1960 med källa på någon intervju och det står 1960 på imdb och på personens egna webbsida t.ex. så lämnar jag detta så tillsvidare. Mvh Höstblomma (diskussion) 18 februari 2024 kl. 08.47 (CET)[svara]

Salou[redigera | redigera wikitext]

Salou (Q662789) är det inte en sammanblandning mellan ort och kommun? Yger (diskussion) 18 februari 2024 kl. 19.26 (CET)[svara]

Hur menar du? På vilket sätt är det en sammanblandning? Det finns två objekt i Wikidata och två features i Geonames
Menar du att det är något uttalanden som finns i Wikidata för något av dessa två objekt som har hamnat i fel objekt? I så fall vilket uttalande?
För tillfället verkar det enbart vara en språkversion, cebwp, som har separata artiklar för dessa två objekt, se följande översikt.
Språkutgåvor
Wikidataobjekt Etikett # svwiki enwiki dewiki frwiki eswiki cebwiki
d:Q662789 Salou 55 Salou Salou Salou Salou Salou Salou (munisipyo)
d:Q24015200 Salou 1 - - - - - Salou (lungsod)
-- Larske (diskussion) 18 februari 2024 kl. 19.56 (CET)[svara]
<titt på de artiklar som länkas till wd-posten Yger (diskussion) 18 februari 2024 kl. 19.59 (CET)[svara]
Det finns 54 artiklar och jag har inte tittat i alla dessa. De sex som finns i tabellen ovan beskriver antingen kommunen eller kommunen med dess centralort.
Peka gärna lite närmare om det är någon speciell artikel av dessa 54 som du tycker är fel och som inte borde kopplas till kommunobjektet. Larske (diskussion) 18 februari 2024 kl. 20.07 (CET)[svara]
JAg tyckte tyska bara nämner kuststad? Yger (diskussion) 18 februari 2024 kl. 20.13 (CET)[svara]
Faktarutan i de:Salou avser kommunen (Gemeinde).
Av historiken i Wikidata och svwp verkar det som om Maundwiki och YesDi har olika uppfattningar om det ska vara två olika artiklar eller en gemensam artikel för kommun och kommunhuvudort här i svwp.
@Maundwiki, YesDi: för kännedom och en eventuell kommentar. Ni har kanske diskuterat detta på någon annan plats.
-- Larske (diskussion) 18 februari 2024 kl. 20.20 (CET)[svara]
Ja, städar i Spanien, efter att massa botskapad info massimporterats till användargenererade artiklar, vilket utan robot-varningsmallen högst upp presenterar läsaren med rent felaktig information. Datum för befolkning är till exempel det dagen uppgifterna lades in i GeoNames och inte när befolkningen faktiskt uppmättes osv. Åter till frågan, vi bör enligt min mening hålla oss till en artikel i regel om ort/kommun, vilket redan är praxis i större delen av vår artikelsamling om ort/kommun i Europa såsom Frankrike, Tyskland, Italien, Schweiz, Österrike m.fl. Det kan givetvis finnas undantag för detta. Sagunt är ett exempel på hur man kan presentera orters befolkning i kommunen. YesDi (diskussion) 18 februari 2024 kl. 20.43 (CET)[svara]
Det här har inget med lsj bot att göra även om artiklarna har felaktigt data. Rätta innehåll är en sak att slå ihop kommun och ort är något annat. För Spanien är spanska och de flesta andra språkversionerna länkade till ett wikidataobjekt som har P31 kommun någonting. Jag tror att lsj gjorde som det var diskuterat att det skulle vara olika artiklar för ort och kommun som vi gör för Sverige. Alla höll inte med men så blev det. Wikidataobjektet ort finns vanligen enbart för sv and ceb i Spanien. I detta fall, vilken källa anger att Salou är en stad utöver kommun? Datat i infoboxen kommer via "Mall:Stat/Spanien/Kommuner/Areal" etc så det har inget med wikidata att göra men gör det klart att artikeln främst handlar om kommunen.
Maundwiki (diskussion) 19 februari 2024 kl. 00.30 (CET)[svara]
Tänker att det är relativt givet utifrån om man tittar på en karta att Salou inte enbart är en kommun utan att det också finns en stad/tätort/småstad/samhälle/ort (kalla det vad man vill) som heter Salou. På kommunens webbplats talar man om "El municipi" och "La Ciutat" (eng "The Municipality" respektive "The City") exempelvis. YesDi (diskussion) 19 februari 2024 kl. 10.54 (CET)[svara]
Enligt min mening är det principiellt fel att ha samma artiklar för kommuner och centralorter oavsett vilket land det gäller. Jag vet dock att det i vissa fall är svårt att skilja dem åt på ett vettigt sätt, men då bör orten åtminstone ha en Wikidataomdirigering. Tostarpadius (diskussion) 20 februari 2024 kl. 09.50 (CET)[svara]
Att betrakta ort som något frikopplat från kommun kan vara praktiskt när man vill sätta ut namn på en karta, men för många länder, som inte har storkommuner eller tätortdefinitioner liknande den nordiska, blir det artificiellt i ett uppslagsverk som Wikipedia. Konsensus på Wikipediadiskussion:Projekt alla platser-städning är rätt tydlig: om vi ska följa vad för information som finns i detaljerade källor och undvika att tvinga in artiklar om platser utanför Sverige i ett Sverigespecifikt mönster ska vi i många länder ha artiklar som i första hand avgränsas av kommungränser, vilket också är det som de flesta andra WP-upplagor har. WD-objektet med de flesta iw-länkarna bör då ha ADM-Geonames-ID snarare än PPL-Geonames-ID, men detta var rörigt på WD redan innan Lsjbot och Geonames-ID för två objekt kan behöva byta plats, enklast med MoveClaim. //Essin (diskussion) 20 februari 2024 kl. 11.09 (CET)[svara]
Jag förstår fortfarande inte hur det går ihop med det globala perspektivet att inte behandla detta i princip likadant för alla länder inklusive Sverige. Att andra språkversioner gör på det viset är inget hållbart argument i sammanhanget. Tostarpadius (diskussion) 20 februari 2024 kl. 11.19 (CET)[svara]
Globalt perspektiv är i det här fallet att beskriva platser utifrån sina egna sammanhang, inte som platser i Sverige fast konstiga. Med andra ord: en plats, i Spanien, snarare än en plats i Sverige, fast i Spanien. Om alla andra språkversioner gör annorlunda än svWP och cebWP är det skäl att åtminstone titta närmare på varför de gör så. I många fall visar det sig att deras indelning är naturlig om man läser deras källor, som har högre detaljeringsgrad och tillförlitlighet än Geonames. I några fall har de blandat bort sig (jag har t ex sett det med centres urbains och landskommuner i Marocko) och då finns det skäl att upprätthålla skillnaden. //Essin (diskussion) 20 februari 2024 kl. 11.43 (CET)[svara]
Ja, jag har redan öppnat för att undantag måste kunna göras där det är olämpligt att ha två artiklar (vilket inte betyder att Wikidataobjekten bör vara de samma för orter och kommuner). Huvudsaken är att det görs åtskillnad på något sätt när det går, så att det inte råder total förvirring. Tostarpadius (diskussion) 20 februari 2024 kl. 11.54 (CET)[svara]

Hjälp behövs[redigera | redigera wikitext]

För någon dag sedan avkopplades ett antal artiklar i wikidata, fast de hade en exakt motsvarighet på ceb se här Jag tolkade det som vandalism och ogjorde, men det var troligtvis Roufu som gjord dessa oinloggad, för nu har han ogjort mina återställningar. Jag behöver hjälp hur detta bör vara, för just nu får jag en lång lista på artiklar i Wikipedia utan WD koppling som jag inte vet hur hantera Yger (diskussion) 19 februari 2024 kl. 21.13 (CET)[svara]

Antar att det har att göra med det som står under #Botkörning o dyl för sammanslagningar av objekt? ovan. Enligt den diskussionen finns det tokigheter vid hur lsjbot har hanterat härader och det är nog de som Roufu åtgärdat genom att göra omdirigeringar. Är inte tillräckligt insatt för att säga något om det är rätt metod eller inte. Gunnar Larsson (diskussion) 19 februari 2024 kl. 22.27 (CET)[svara]
Jag beklagar att jag redigerade oinloggad på Wikidata. Det hade att göra med att jag inte är hemmastadd där, och att jag har svårt att ta till mig nya ting pga min dåliga syn.
Det handlar om ett 30tal glömda botgenererade dubbletter om kinesiska administrativa enheter på häradsnivå, som Essin funnit, och som jag håller på att göra om till omdirigeringar till artiklar, som ursprungligen skrivits av Bothnia. Detta,innebärflyttning av viss information från bot.artiklarna till de manuellt skrivna samt avkoppling av de nya omdirigeringarna från Wikidata. Botartiklarna har endast interwiki till cebuano, medan målen för omdirigeringarna har interwiki till upp mot 20 språk.
Totala antalet häradsenheter uppges till 2850, och i princip skall alla ha artiklar på svenska. Kanske hälften har haft botgenererade dubbletter, som gjorts om till omdirigeringar, och de som är kvar är alltså en liten restgrupp. Roufu (diskussion) 19 februari 2024 kl. 23.13 (CET)[svara]
Det borde väl gå att göra om dem till omdirigeringar utan att koppla bort dem från Wikidata? Eller åtminstone göra omdirigeringen först. Boivie (diskussion) 20 februari 2024 kl. 07.27 (CET)[svara]
Handlar det om rena dubbletter bör vi inte ha Wikidataomdirigeringar. Däremot borde objekten där i sådana fall slås samman. Tostarpadius (diskussion) 20 februari 2024 kl. 09.45 (CET)[svara]
I många fall är de fortfarande dubbletter på cebuano och WD-objekten behöver då märkas med Wikimedia-dubblett (Q17362920). //Essin (diskussion) 20 februari 2024 kl. 11.11 (CET)[svara]
Ja, finns det två artiklar på cebuano förstår jag att det är enda möjligheten. Tostarpadius (diskussion) 20 februari 2024 kl. 11.56 (CET)[svara]
Jag har nu gått igenom och slagit ihop WD-objekten där det gick. //Essin (diskussion) 3 mars 2024 kl. 16.06 (CET)[svara]

Radera wp som källa?[redigera | redigera wikitext]

Hittar inte svaret på detta på WD, men om man källbelägger med en extern källa, visst måste det vara okej att ta bort "importerad från"-källorna från olika wp-versioner? Det blir lätt råddigt med två-tre referenser på ett simpelt påstående. jssfrk (d|b) 20 februari 2024 kl. 21.08 (CET)[svara]

Det gör jag utan att blinka. LittleGun (diskussion) 20 februari 2024 kl. 21.27 (CET)[svara]
Tack, jag har gjort det också, men blev plötsligt osäker. jssfrk (d|b) 20 februari 2024 kl. 22.39 (CET)[svara]
Gör jag med nu, när jag börjat kika där... ser tyvärr hur de importerat födelsedata från språk som sedan ändrat till rätt data men den gamla felaktiga finns kvar i WD. Adville (diskussion) 20 februari 2024 kl. 22.47 (CET)[svara]

Generaldirektör - var då nånstans?[redigera | redigera wikitext]

Jag har försökt uppdatera WD för Judith Melin och lägga in "Befattning" att hon varit generaldirektör först för Statens Kärnkraftsinspektion och sedan för Kustbevakningen. Men i WD-mallen visas bara "Generaldirektör" och de två tidsperioderna, skulle gärna velat ha med vilken myndighet det avser. Finns det någon smidig lösning på detta? Annars kanske jag tar bort infon, den finns ju redan i WP-artikeln. / ANHN ✎ 27 februari 2024 kl. 09.14 (CET)[svara]

Man måste använda av eller för (P642) och inte arbetsgivare (P108). /ℇsquilo 27 februari 2024 kl. 09.20 (CET)[svara]
För statliga myndigheter bör man skapa ett eget objekt för den posten som är en underklass till (P279) till generaldirektör. Det är det tydligaste sättet och gör det lätt sedan att fråga efter alla direktörer på en myndighet och skapa tidlinjer med mera. ♥Ainali diskussionbidrag 27 februari 2024 kl. 10.28 (CET)[svara]
Stort tack för klargörande svar - och att ni också gjorde jobbet att föra in rättelsen! Förhoppningsvis gör jag själv rätt nästa gång. / ANHN ✎ 27 februari 2024 kl. 10.43 (CET)[svara]

Käpplingeholmen 3/Teatergatan 3[redigera | redigera wikitext]

Hur ska Teatergatan 3 (Q124707713) och Käpplingeholmen 3 (Q10551740) sammanbindas? Inte sammanfogas. Jag tolkar artikeln Käpplingeholmen 3 som att den beskriver nuvarande byggnaden (fastighet) inte rättsliga termen fastighet. Teatergatan 3 beskriver även vad som tidigare fanns på tomten. Maundwiki (diskussion) 2 mars 2024 kl. 14.10 (CET)[svara]

Fastigheten (tomten) Käpplingeholmen 3 har adressen Nybrokajen 5 eller Teatergatan 1. Grannfastigheten (tomten) Käpplingeholmen 5 har adress Teatergatan 3. Artiklar om byggnader utan speciella namn (typ X:ska palatset, X-teatern, ...) kan namnges antingen enligt fastighetsbeteckningen eller adresen. I båda fallen kan nog fastighetens/adressens historia beskrivas inte bara nuvarande byggnaden. De två WD-objekten som du nämner kanske kan kopplas ihop som grannfastigheter på något sätt. F.d. 82.212.68.183 (diskussion) 2 mars 2024 kl. 14.31 (CET)[svara]
Jag ändrade instans av (P31) för Teatergatan 3 (Q124707713) från fastighet (Q684740) till gatuadress (Q24574749) och la till en beskrivning, se diff Larske (diskussion) 2 mars 2024 kl. 14.50 (CET)[svara]
@Maundwiki: Menar du verkligen Käpplingeholmen 3? Om det är Käpplingeholmen 5, som idag inte har något Wikidataobjekt, du menar, skulle en koppling till dess gatuadress kunna ske via gata/väg (P669) med bestämningen gatunummer (P670), alltså som jag la in här i Sandlådan. Det är en ganska lös koppling, men om samma egenskap med samma bestämning läggs in även i objektet Teatergatan 3 (Q124707713) skulle man kunna "matcha" de två objekten "Käpplingeholmen 5" (fastigheten) och "Teatergatan 3" (gatuadressen). Larske (diskussion) 2 mars 2024 kl. 15.15 (CET)[svara]
Så kan det gå när en 3 släses som 5. Sorry. Maundwiki (diskussion) 2 mars 2024 kl. 15.18 (CET)[svara]

Automatiskt skapade Wikidata-referenser[redigera | redigera wikitext]

Artikeln Guglielmo Ferrero dubblerar sina referensavsnitt. Jag har för mej att detta tidigare varit ett problem som sedan dess åtgärdats. Men det händer fortfarande här. Varför det? Sabelöga (diskussion) 3 mars 2024 kl. 22.37 (CET)[svara]

Det här påverkar användare av finessen "Lägg till Mall:Faktamall biografi WD i biografier om det inte redan finns någon infobox". Felet är att det bara finns en tom Referens-rubrik utan några referenser. Utan referenser finns det ingen referenslista som finessen kan hitta och placera WD-referenserna i, så den skapar en egen lista med rubrik. EnDumEn ✍ 4 mars 2024 kl. 21.13 (CET)[svara]
Ah, juste. Men det finns ju dock en referenslista dvs en <references/>-tagg. Registreras inte det av finessen? Sabelöga (diskussion) 5 mars 2024 kl. 00.15 (CET)[svara]
Finns det inga referenser i artikeln så skapar references-taggen ingen referenslista. I redigeringsläget kan man se att taggen finns i wikikoden, men i läslägets HTML-kod finns inget som visar att en referenslista ska placeras på en viss plats i artikeln. /EnDumEn ✍ 5 mars 2024 kl. 21.53 (CET)[svara]
Men då funkar ju inte finessen som den ska. Kan någon fixa detta eller kan jag anmäla detta till någon som kan? Sabelöga (diskussion) 5 mars 2024 kl. 22.24 (CET)[svara]
Jag la till en kontroll så att rubriken "Referenser" inte läggs till om den redan finns. Det kan ändå bli konstigt om det finns annat innehåll under den rubriken eller om det finns andra sorters källhänvisningar under någon annan rubrik. Det är nog vanligare än att ett tomt referensavsnitt lämnats kvar. Huvudpoängen med finessen är att visa WD-mallen för dem som gärna vill se data från WD. Att källrubrikerna inte blir helt perfekta borde inte vara ett stort problem.
Mest relevanta platsen att rapportera fel i finesser är finessernas diskussionssidor. Fast det är nog större chans att få hjälp på WP:Wikipediafrågor (eller här om finessen har att göra med Wikidata). /EnDumEn ✍ 6 mars 2024 kl. 21.25 (CET)[svara]

Datum för grundande eller skapande[redigera | redigera wikitext]

Jordbodalen med Ångtegelgropens naturreservat (Q112582557) har två instiftelsedatum, det tidigaste avser beslut i Kommunfullmäktige och det andra när beslutet trädde i kraft. Hur ska detta märkas upp korrekt? Spontant misstänker jag tagen i bruk (P729) eller att göra någon föredragen med något vettigt skäl (men vet inte vilket jag ska välja i så fall). /Autom (diskussion) 11 mars 2024 kl. 20.39 (CET)[svara]

Jag vet inte om det är gjort helt konsekvent för alla naturreservat i Sverige, men för Paubäckens naturreservat (Q89964718), som är det senaste som Yger har lagt in datum för grundande eller skapande (P571) i, är det inte "beslutsdatum" (2019-10-30) utan "gällandedatum" (2022-12-22) som har lagts in, se här.
Se även kolumnerna URSBESLDAT och URSGALLDAT i tabellen i den här tråden med data från Naturvårdsverkets register.
@Yger: för en eventuell kommentar. Larske (diskussion) 11 mars 2024 kl. 21.05 (CET)[svara]
Det är så att de botskapade WD posterna konsekvent använder gällande datum. I texten från länsstyrelserna används dock beslutande datum (och texten är "skyddat sedan" vilket ju gäller beslutande datum).Jag har i mina manuellt använt beslutande datum fram till 8 mars i år, därefter gällande datum. soppa? ja! Men det bör i löptexten och kategorin vara som i länsstyrelserna, belsutande datum, även om wd posten använder gällande datum Yger (diskussion) 11 mars 2024 kl. 21.09 (CET)[svara]
Jag ser nu att vi diskuterade just den här frågan för sex år sedan, se rubriken Inrättat datum i den här tråden Larske (diskussion) 11 mars 2024 kl. 21.23 (CET)[svara]

Vandalisering på WikiData[redigera | redigera wikitext]

Vet inte om detta är rätt plats, men vad är lämplig åtgärd för att komma till rätta med detta? undrar / ANHN ✎ 19 mars 2024 kl. 13.13 (CET)[svara]

Att backa den olämpliga redigeringen som du gjorde är den snabba och korrekta åtgärden. När det gäller klotter brukar jag lägga till redigeringskommentaren "reverting vandalism" där det är uppenbart klotter eller "reverting possible vandalism" om jag inte är 100 procent säker på att det är klotter. Det är lite knepigt med redigeringskommentarer i Wikidata. När man "gör ogjord" blir man promptad för att ge en kommentar, men det är ju inte alltid det går om det är flera redigeringar man vill backa och det ligger andra redigeringar senare i historiken. För vanliga redigeringar ges tyvärr inte samma möjlighet. För att ändå kunna ge en personlig redigeringskommentar har jag länkat in ett användarskript som heter "EditSum.js som någon tipsade mig om. Se rad 5 i min common.js på Wikidata.
Om klottraren upphör är det inte så mycket mer att göra, de flesta klottrare tröttnar när de blir återställda, men om samma användare återkommer med mer ihärdigt klottrande kan man begära en blockering, precis om på Wikipedia.
I detta fall handlar det om en IP-adress som antagligen drevs till Wikidata när hen blev blockerad ett dygn på svenskspråkiga Wikipedia.
Det går också, precis som på Wikipedia, att begära att objekt som används av ett stort antal sidor i olika Wikimedia-projekt och som ofta är utsatt för klotter halvlåses, vilket förhindrar oinloggade och nyskapade konton att redigera. I det aktuella fallet rör det sig knappast om ett "Highly used item". Jämför avsnittet "Sidskydd" för följande två objekt:
-- Larske (diskussion) 19 mars 2024 kl. 14.33 (CET)[svara]
 Man tackar / ANHN ✎ 20 mars 2024 kl. 05.49 (CET)[svara]
Anhn: Ser nu att det är alias och dessutom på engelska. Vi har inga verktyg för att upptäcka svenskspråkigt klotter i icke-svenska "fack". För beskrivningar på svenska har vi en mängd verktyg:
  1. MediaWiki:Gadget-EventStreams.js (kan kryssas i här) visar ändringar till svenskspråkiga beskrivningar (samt en mängd annan information som inte visas på Special:Senaste ändringar, som tack, patrulleringar och utlösning av filter) på Wikipedia:Senaste ändringar/EventStreams
  2. MediaWiki:Gadget-WikidataDescription.js (kan kryssas i här) gör att man kan se och redigera beskrivningar från en Wikipedia-artikel, utan att lämna sidan.
  3. [1] visar ändringar till svenskspråkiga beskrivningar gjorda med MediaWiki:Gadget-WikidataDescription.js
Nirmos (diskussion) 22 mars 2024 kl. 19.10 (CET)[svara]
 Man tackar - igen! / ANHN ✎ 22 mars 2024 kl. 23.04 (CET)[svara]

Kategori:Wikidataetiketter på främmande språk för egenskapen P123[redigera | redigera wikitext]

Fungerar den här kategorin som den ska? Så vitt jag kan se har exempelvis Bygg bilar med Mulle Meck och Astrid Silverlock inte ens någon sådan egenskap angiven på Wikidata! Jag ser nu att detta även gäller referenser.. Bör detta kanske framgå eller är det underförstått? Sabelöga (diskussion) 20 mars 2024 kl. 02.11 (CET)[svara]

Den underförstådda delen av kategorinamnet är "Artiklar som visar...".
Det stämmer att kategorin inkluderar artiklar som är kopplade till Wikidataobjekt där det saknas en svensk etikett för utgivare (P123), inte bara som en "huvudegenskap" för objektet utan även som en bestämning till andra egenskaper eller dess referenser i den mån dessa leder till att en icke-svenska etikett visas i artikelns faktaruta eller i dess tillhörande referenser.
Detta innebär att den saknade svenska etiketten ibland gäller något annat objekt än just det som är angivet som värde för en huvudegenskap för det objekt som svwp-artikeln är kopplat till . Se till exempel Abdallah ben Jasin som för tillfället ligger i såväl Kategori:Wikidataetiketter på främmande språk för egenskapen P39 som Kategori:Wikidataetiketter på främmande språk för egenskapen P123.
Ett sätt att enklare se exakt var det saknas en etikett på svenska kan vara att stoppa in följande tre rader i sin common.css;
.modulwikidata2_missingswedishlabel {
	background-color: pink;
}
Med denna stil blir de icke-svenska etiketterna markerade med en rosa bakgrundsfärg, färgen kan naturligtvis väljas efter eget tycke och smak.
I artikeln Abdallah ben Jasin är just nu såväl Imam i faktarutan som Da'wat al-Ḥaqq i punkt 1 i referenslistan markerade med denna stil.
--Larske (diskussion) 20 mars 2024 kl. 08.47 (CET)[svara]
Aha, så det är bara när strängar visar icke-svenskspråkig text från Wikidata i artiklar som kategorin triggas, oavsett om den kommer direkt eller indirekt från artikelns Wikidata-objekt. Det var bra att veta. Tack för förklaring! Man kanske ska ta och gå igenom dom där kategorierna någon dag. Sabelöga (diskussion) 23 mars 2024 kl. 21.05 (CET)[svara]
@Larske Apropå etiketter på Wikidata, finns det något sätt att få programvaran på Wikidata att på ett objekt inte bara visa Q-nummer om det sankas etikett på svenska eller engelska? I just ett fall jag stötte på just nu fanns det bara på tyska, och inte på varken svenska eller engelska varvid Q-numret visades. Sabelöga (diskussion) 23 mars 2024 kl. 21.11 (CET)[svara]
@Sabelöga:
  1. Vilket objekt talar du om?
  2. Var ser du Q-numret? I någon faktaruta i en svwp-artikel, vilken? eller i referenslistan?
  3. Vad vill du se istället?
Larske (diskussion) 23 mars 2024 kl. 21.43 (CET)[svara]
På Wikipedia verkar det inte vara ett problem. Där verkar programvaran på något sätt hämta någon av dom etiketter som finns. Men det är inte det som är problemet. Utan jag pratar nu om Wikidata. Den här gången så var jag på objektet Bummi (Q1004844) och där fanns det varken svensk eller engelsk etikett för objektet Buchverlag Junge Welt (Q999166) i egenskapen utgivare (P123) (jag har lagt till en svensk etikett nu). Då visades ingen etikett alls för mej, utan istället visades Q999166. Vilket ju inte säjer mej nånting, hade det funnits en engelska etikett hade ju den visats med engelska efter. Så hur får man programvaran att hämta etikett på samma sätt fast från tyska eller norska om det saknas etikett på svenska och engelska? Sabelöga (diskussion) 23 mars 2024 kl. 21.54 (CET)[svara]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Sabelöga: Ok, tack för förtydligandet. Här står det något om "Support for fallback in the Wikidata editing interface", men det verkar mest vara tankar om hur det skulle kunna vara, inte hur det är. Nån annanstans, som jag inte hittar nu, står det något om att man kan stoppa in "Babel-rutor" på sin användarsida, men jag vet inte om det påverkar översättningen från Q-nummer till etikett inne i specifika uttalanden. Det är nog till för att styra vilka språk som visas i den stora rutan upptill där etiketter, beskrivningar och alias visas på olika språk.

Problemet är troligen redan löst många gånger tidigare, men istället för att leta vidare tog jag fram ett användarskript som du kan testa om du vill. Ställ dig på en sida i Wikidata där det finns Q-nummer vars etiketter du vill se i klartext, till exempel Fernand David (Q3069115), där det visas Q-nummer för gravplats (P119), en av befattning (P39), samt för bestämningar parlamentsgrupp (P4100) för två av befattning (P39) och bestämningen av eller för (P642) för en av befattning (P39) som ordförande (Q140686), och gör så här:

  1. Öppna konsolen, i Firefox trycker man på F12
  2. Kopiera in kodraderna nedan in fliken Konsol
  3. Tryck på Kör

Det som händer är att skriptet letar rätt på alla Q-nummer, hämtar deras etiketter på alla de språk som de finns för och väljer det språk som står först i listan "mylangprefs". Den funna etiketten, samt dess språkkod inom parentes, stoppas in efter respektive Q-nummer. Du kan ändra ordningen på språken i "mylangprefs" och även lägga till andra språkkoder om du vill. Skriptet ändrar ingenting i databasen, om det ser konstigt ut är det bara att ladda om sidan i webbläsaren.

Det bästa är förstås att lägga in svenska etiketter där sådana saknas. --Larske (diskussion) 24 mars 2024 kl. 11.42 (CET)[svara]

Det du skrev om babelrutorna är helt korrekt, det löser bara vilka språk som visas i etikettrutan. Din lösning om etiketterna fungerar som den ska hos mej, lite synd bara att det skiljer sig från hur den ordinarie programvaran hanterar det. Går det skriva in det här i sin globala CSS på något sätt, eller följer koden jag nu skrev in i konsolen med till andra sidor? Sabelöga (diskussion) 25 mars 2024 kl. 00.00 (CET)[svara]
Koden i konsolen är knuten till den lokala webbläsarfliken, men den ligger kvar där och följer med när du surfar vidare till en annan sida i Wikidata ända tills du stänger den webbläsarfliken. Vill du ha den mer permanent, och även slippa att klicka på "Kör", kan du stoppa in koden, inbäddad med $(function() { och });, i din "common.js" på Wikidata. Detta alternativ kräver förstås att du är inloggad för att det ska fungera och vill du av någon anledning se hur sidan ser ut utan de tillagda etiketterna kan du alltid öppna sidan i ett privat fönster i webbläsaren eller som oinloggad.
Notera att koden ovan är begränsad till de 50 första Q-numren på en sida, vill man att alla Q-nummer utan etiketter på sidan ska hanteras får man lägga till lite kod. Har du stött på någon sida på Wikidata där det finns mer än 50 objekt (Q-nummer) som varken har en svensk eller engelsk etikett?
-- Larske (diskussion) 25 mars 2024 kl. 09.56 (CET)[svara]
Okej, jag har installerat koden i min .js. Tack! Och nej, jag kan inte komma på något objekt på rak arm som har fler än femtio Q-nummer där någon av dom saknar svenskspråkig etikett. Det kan finnas dock. Sabelöga (diskussion) 25 mars 2024 kl. 18.22 (CET)[svara]

"Källangivelsen på Wikidata använder egenskaper (properties) som inte känns igen av Modul:Cite"[redigera | redigera wikitext]

Upptäckte detta problem i den nyskapade artikeln Erriyon Knighton. Referensen går till World Athletics ID (P1146). Någon som har en lösning på detta? --Fredde✔ 30 mars 2024 kl. 10.49 (CET)[svara]

Felet verkar bero på att funktionen citeitem (som börjar på rad 430 i Modul:Cite) inte returnerar något. Provade temporärt att använda anges i + World Atheletics databas. Fick förvisso inget fel då, men inte heller någon länk will webbsidan där World Athletics har information. Gunnar Larsson (diskussion) 30 mars 2024 kl. 11.19 (CET)[svara]
@Gunnar Larsson: Tack ändå för försöket! Ser att referensen funkar på nowp samt ifall artikeln använt sig av {{Sportperson WD}} istället. Verkar som att {{Faktamall biografi WD}} inte klarar av propertys som referenser. --Fredde✔ 30 mars 2024 kl. 12.06 (CET)[svara]
Jodå, för alla referenser skapas med hjälp av egenskaper. Det är den här specifika egenskapen som fallerar. ♥Ainali diskussionbidrag 30 mars 2024 kl. 13.36 (CET)[svara]
Problemet verkade vara att bara World Athletics ID stod som referens, lade till fler properties och då verkar det fungera, Thoasp (diskussion) 30 mars 2024 kl. 16.18 (CET)[svara]
Hämtad från ”https://sv.wikipedia.org/w/index.php?title=Wikipedia:Wikidatafrågor&oldid=54639994”