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-chatt · Kontakt · Pressfrågor · Wikipedia i media · Wikiträffar

 Arkiv för denna sida     Genväg WP:WD
Bluegradient1.svg
Wikidatafrågor
Frågor om hur Wikidata fungerar
Wikidata-logo.svg
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.

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.

Ortsfakta WD för finska orterRedigera

Hej, jag ställde en fråga om Ortsfakta WD för finska orter på mallens diskussionssida. Kort sagt: Jag försökte använde Ortsfakta WD på Nagu, Finland, men ingenting syntes i förhandsgranskningen. Hur är det meningen att den ska användas? Måste den först anpassas för finska orter på något sätt - det verkar inte finnas en finsk variant på Ortsfakta WD?

Exakt, mallen behöver anpassas för att funka. Idag funkar den för svenska orter, norska kommuner o fylken, danska kommuner o regioner, färöiska kommuner, belgiska kommuner, arrondissement, provinser regioner och är under utveckling för grönländska kommuner och amerikanska städer. 62 osv (diskussion) 15 juli 2020 kl. 11.47 (CEST)

XiaolangdiRedigera

Xiaolangdi är en köping och enligt länkningen detsamma som Xiaolangdi Dam på en-wp. Jag har försökt kolla på övriga språk men blev inte så mycket klokare. Finns det nån annan som kan kika på detta? // Zquid (diskussion) 3 juni 2020 kl. 21.00 (CEST)

Felkopplat i WD. Jag kopplade om artiklarna i svwp och cebwp till orten i zhwp. d:Q10959512 Orten ligger ca 7 km söder om dammen. --北山 Kitayama (diskussion) 3 juni 2020 kl. 21.27 (CEST)
@Kitayama: Tack för hjälpen! // Zquid (diskussion) 4 juni 2020 kl. 16.31 (CEST)

Bildtext i faktamall biografi WDRedigera

 
Som det ska se ut
 
I KlasHass Firefox

Jag har i finesser angivit Lägg till Mall:Faktamall biografi WD i biografier om det inte redan finns någon infobox och nu ser jag att när samma bild som i WD redan finns på sidan så kommer första ordet i den ursprungliga bildtexten centrerad till höger om bilden i WD-boxen och resten under bilden. (Exempel Eivind Heiberg och Louis Étienne Watelet.) Vet inte om jag sett det förut. KlasHass (diskussion) 3 juni 2020 kl. 21.52 (CEST)

KlasHass: "första ordet i den ursprungliga bildtexten centrerad till höger om bilden i WD-boxen och resten under bilden" låter definitivt fel. Jag har lagt till en bild här till höger. Det är så jag ser artikeln Eivind Heiberg och det är så det ska se ut. Menar du att det inte ser likadant ut för dig? I så fall skulle jag helst vilja se en skärmdump från din sida. Jag skulle också behöva veta vilken webbläsare samt vilket skin du använder. Nirmos (diskussion) 3 juni 2020 kl. 23.35 (CEST)
Nirmos: Hej. Så här ser det ut på min laptop med Firefox. Testade just med MS Edge och där blev det som det skulle, så det är väl antingen webbläsaren eller någon inställning hos mig som ställer till det. Hälsningar - KlasHass (diskussion) 4 juni 2020 kl. 10.57 (CEST)
Uppdatering: Det är inte alltid bara det första ordet. På Johan I av Aragonien hamnar Johan I av i det övre läget. KlasHass (diskussion) 4 juni 2020 kl. 12.33 (CEST)
Funkar det bättre nu? Jag tror det saknades en div-tagg runt bildtexten, så att det inte automatiskt blev en radbrytning direkt efter bilden. Radbrytningen behövs om man har större textstorlek eftersom bildens storlek i px inte ändras medan faktamallens bredd i em blir större så att att både bild och en del av bildtexten får plats på samma rad. /EnDumEn 4 juni 2020 kl. 17.50 (CEST)
EnDumEn: Tack, nu funkar det! Hälsningar - KlasHass (diskussion) 4 juni 2020 kl. 18.08 (CEST)

Auktoritetsdata som inte syns på sv.wpRedigera

Jag upptäckte att i vår artikel om Hannah Gadsby så visas inte Auktoritetsdatamallen trots att den är inlagd och trots att det finns identifierare inlagda i wikidataobjektet. På engelskspråkiga Wikipedia visas auktoritetsdata för Gadsby. Vad kan vara orsak till detta mysterium? //Vätte (diskussion) 13 juni 2020 kl. 16.15 (CEST)

Den enda identifieraren för henne på Wikidata som är med i den svenska mallen är MusicBrainz, men det krävs att personen har vissa sysselsättningar (se Mall:auktoritetsdata). Hennes sysselsättning är komiker som inte är någon av dessa sysselsättningar, därför kommer den inte med. Thoasp (diskussion) 13 juni 2020 kl. 16.26 (CEST)
Tack för svar! Vet du varför vi inte visar samma saker i mallen som andra språkversioner? Fick för mig att förra sommarens diskussion hamnade i att vi borde visa allt? Tänker även på WP:GLOBAL. //Vätte (diskussion) 15 juni 2020 kl. 12.41 (CEST)
--Larske (diskussion) 15 juni 2020 kl. 15.12 (CEST)

Kan plötsligt inte redigera WDRedigera

Idag kan jag plötsligt inte redigera Wikidata. Har fler råkat ut för samma sak eller är det någon som kan förklara vad som hänt? /Ascilto (diskussion) 16 juni 2020 kl. 13.04 (CEST)

Om du inte var inloggad och sidan du försökte redigera var halvlåst kan detta vara skälet till att redigeringen inte lyckades.
  1. Vilken sida försökte du redigera? Och när?
  2. Var du inloggad i Wikidata?
  3. Vad händer när du försöker? Får du något felmeddelande?
--Larske (diskussion) 16 juni 2020 kl. 13.19 (CEST)
Sidan jag försökte redigera var Finn Poulsen (Q26994717). Jag var inloggad och det som hände var att inget hände när jag klickade på lägg till uttalande eller redigera. Mn nu funkar det lika plötsligt igen. /Ascilto (diskussion) 16 juni 2020 kl. 14.09 (CEST)
@Ascilto: Så bra, då var det nog bara något tillfälligt problem. När det gäller dödsort (P20) ser jag att det i såväl artikeln som i Wikidata är angivet som en tätort, Uppsala respektive Uppsala (Q25286), men för personer i Sverige brukar vi väl för födelseplats (P19) och dödsort (P20) ange församling (om det är 2015 eller tidigare) eller distrikt (om det är 2016 eller senare).
Församlingarnas och distriktens gränser är ju lite mera fasta, medan gränserna för tätorterna justeras lite då och då beroende på hur bebyggelsen förtätas eller SCB ändrar sina regler för att avgränsa tätorterna. Vi har ju en komplett uppsättning av svwp-artiklar och Wikidataobjekt om såväl församlingar som distrikt i Sverige att tillgå.
För personen ovan var han enligt ratsit.se folkbokförd på Eva Lagerwalls väg 2 som ligger i Gottsunda distrikt (Gottsunda distrikt (Q21684606)). Vad tror du om att ändra till det i artikeln respektive i Wikidata?
Jag noterar också att ratsit.se anger 25 juni 1943 som födelsedatum, medan svwp-artikeln med hänvisning till "Sveriges befolkning 1990" anger 26 juni 1943. Har du möjlighet att dubbelkolla det?
--Larske (diskussion) 16 juni 2020 kl. 15.21 (CEST)
Att ange distrikt är självklart att föredra framför att ange en tätort. Jag hade lite bråttom. /Ascilto (diskussion) 16 juni 2020 kl. 19.39 (CEST)

Svenska Fotbollförbundet ID (P1238)Redigera

Svenska Fotbollförbundet ID funkar inte längre utan endast en hash av ID'et funkar (se t.ex.: Alexander Zetterström (Q16945544)). Det står att Properyn har en 'formatbegränsning' om någon Wikidata-kunnig kan åtgärda. Går det att få fram en lista på artiklar som använder sig av den tidigare ID varianten hade det också varit tacksamt. --Fredde 23 juni 2020 kl. 16.29 (CEST)

Av de 1 879 objekt i Wikidata som har egenskapen Svenska Fotbollförbundet ID (P1238) är det 1 840 som använder det gamla formatet och 39 som använder det nya, se följande lista:
--Larske (diskussion) 23 juni 2020 kl. 16.46 (CEST)
Jag emailade dom och fick svar att de inte vill hjälpa ....
Vi har gått bort från att använda spelarnas spelar-ID i vår databas till att scrambla fram ett ID utåt publikt pga GDPR. Därför funkar inte längre de gamla länkarna.
Vår IT-avdelning skriver att vi inte kan erbjuda redirect eftersom det gör det möjligt (som tidigare) att läsa ut hela vår spelardatabas. & att API:er för allmänheten saknas.
Svaret är, som dom ser det, att leta rätt på motsvarande sida på nya sajten och länka om till den.
kanske spelarstatistik är hårdvaluta men känns lite naivt att införa "säkerhet" med krångliga URL:ar - Salgo60 (diskussion) 26 juni 2020 kl. 19.57 (CEST)
Att de inte vill erbjuda en redirect kan man möjligen förstå, men vill de verkligen inte ha någon trafik till sajten från Wikipedia som resulterar i något annat än "Not Found"?
De 2 635 artiklarna i Kategori:Svenska fotbollsspelare har hittills i år mer än 3,1 miljoner visningar, mer än 17 400 per dag, se denna massvisningsanalys. (Med underkategorierna inkluderade blir det 3 915 artiklar med mer nästan 3,8 miljoner visningar hittills i år, mer än 21 200 per dag, se denna massvisningsanalys). Mycket märkligt att svenskfotboll.se inte vill hjälpa till att få fungerande länkar till sin sajt från alla dessa Wikipedia-artiklar.
De tänker väl inte generera nya hashar/ID-URL:er varje månad eller så. Och då är det bara en tidsfråga, men en massa onödigt arbete, tills alla Svenska Fotbollförbundet ID (P1238) är uppdaterade i Wikidata och sen kan "hela deras databas" läsas ut igen, fast via Wikidata. Finns man på Internet så finns man på Internet.
Jag har nu skrapat ihop 2 519, varav 1 577 unika, "nya ID" från svenskfotboll.se, genom att "titta" på sidorna för LANDSLAG och SERIER&CUPER. Se den här sidan i Sandlådan.
Genom att jämföra "Namn" i tabellen med "namn" i resultatet från den här frågan kan man få hjälp att uppdatera Svenska Fotbollförbundet ID (P1238) i Wikidata. Ungefär 400 av de omkring 1 800 Wikidataobjekten med gamla ID ser ut att kunna täckas på detta sätt, men det är alltid osäkert att bara jämföra namn då det kan finnas flera personer med samma namn. Så är fallet för åtminstone följande personer:
  • adam-larsson, alexander-johansson, alexander-nilsson, anton-nilsson, carl-johansson, daniel-svensson, dennis-olsson, elin-nilsson, gustav-berggren, jonna-andersson, moa-ohman, per-karlsson och pontus-jonsson.
Det skulle därför underlätta mycket om vi kunde få en korsreferenslista med gammalt och nytt ID, alternativt att svenskfotboll.se själva uppdaterade Svenska Fotbollförbundet ID (P1238) från gammalt till nytt ID i Wikidata, men det är nog att hoppas för mycket.
--Larske (diskussion) 27 juni 2020 kl. 03.52 (CEST)
Snyggt det är lite min tanke att det är naivt att tro att krångliga URL:ar skall skydda deras "data". Vad körde du jag testade snabbt Beautifulsoup men fick en refuse... kan vara den user_agent jag hade...
Jag skickade svars tack och pekade på vår statistik så att dom förstår vilken trafik det kan vara
Tackar för snabbt svar
Vårt problem är att vi har > 5000 externa egenskaper att ”leta reda på” där ni är en....bara svenskfotboll länkar vi över 2,848 ggr på svenska Wikipedia. Bara artikeln om Zlatan finns på 86 språk se mer nedan
-----
Ps. finns 5 157 sidor om svensk fotboll på sv:WIkipedia med 9.9 miljoner sidvisningar 2019
.....
<bild >
....
* en:Wikipedia har 406 externa länkar till er
* en:Wikipedia hade 42 miljoner sidvisningar 2019 på gruppen artiklar om Svensk fotboll = 5733 sidor
<bild>
* Bara Zlatan finns på 86 språk med 10,4 miljoner sidvisningar 2019
- 27 juni 2020 kl. 07.16 (CEST)
Jag skickade ett till email och pekade på den här diskussionen med hopp att vi skulle kunna göra mer ihop.... i ena hörnet svenska fotbollsförbundet som hoppas alla surfar dit... i andra Google som visar online live scores i mobilen - Salgo60 (diskussion) 27 juni 2020 kl. 10.18 (CEST)

Jag jobbar just nu med att manuellt ändra länkarna i egenskapen Svenska Fotbollförbundet ID (P1238), vilket kan ta ett tag! Positivt är att över 100 artiklar nu fått objektet tillagt. En undran, Fogis ID (P5038) är just nu totalt meningslös och bör tas bort då fogis och svenskfotboll slagits ihop. Vad är enklaste sättet för borttagning av egenskaper på Wikidata? --Fredde 4 juli 2020 kl. 18.09 (CEST)

Ta bort en WD egenskapRedigera

@Fredde 99: jag har försökt ta bort men tvekar om det blir bra.... och är värt mödan...

  • Nobelpris-ID (P3188) se Wikidata:Properties_for_deletion#Nobelpris-ID_(P3188). Lesson learned det kan finnas använt någonstans och i fallet med Nobelpris-ID (P3188) när typ Albert Einstein (Q937) finns på 208 språk uppfattar jag det idag helt omöjligt att kommunicera med alla, plus att det som jag och Nobeldata uppfattar självklart som en bättre länkmodell inte är så lätt att övertyga alla WIkipedianer att så är fallet
  • Riksdagen person guid (P8388) så hade jag möte med Riksdagens IT 2019 okt dom sa till mig att dom byter id från Riksdagens person-id (P1214) till guid så jag gick "hem" och sa att nu byter vi... efter oändliga diskussioner blev det istället 2 olika vilket jag nu när jag tittat i lite gamla dokument från Riksdagen känns som ett bra val eftersom dom äldre dokumenten verkar ha kvar det gamla id:et. Riksdagen känns som dom har lite rörig onormaliserad datamodell...

- Salgo60 (diskussion) 11 juli 2020 kl. 11.22 (CEST)

Byta officiell webbplatsRedigera

Jag ville byta webbplats för Alice Sara Ott (Q76387) då jag får ett varningsmeddelande från Firefox när jag försöker besöka den. Jag får dock inte lov att göra det. Någon annan som vill prova? Den jag ville lägga in var https://www.alicesaraott.com. KlasHass (diskussion) 27 juni 2020 kl. 10.32 (CEST)

När jag försökte ändra officiell webbplats (P856) för Alice Sara Ott (Q76387) gick det bra.
--Larske (diskussion) 27 juni 2020 kl. 10.44 (CEST)
Tack Larske. När jag prövade så ville den att den gamla skulle vara kvar med slutdatum eller nåt sånt. Orka! -- KlasHass (diskussion) 27 juni 2020 kl. 10.55 (CEST)
Det är väl vettigt att ha kvar den gamla med slutdatum. Då går det att hitta gamla versioner via archive.org, det går att koppla gamla webbadresser till personen, och det går att se hur personen (och med lite datamining hur folk i allmänhet) bytt mellan olika domännamn. Wikipedia skall ju inte bara berätta hur saker förhåller sig nu utan också hur de varit historiskt, och Wikidata skall väl rimligtvis stöda också den uppgiften. --LPfi (diskussion) 27 juni 2020 kl. 13.11 (CEST)
Den där varningen om att webbplatsen kunde vara skadlig gjorde att jag inte ville fördjupa mig i ämnet. --KlasHass (diskussion) 27 juni 2020 kl. 13.42 (CEST)

Genväg för den lateRedigera

Jag fruktar att svaret är nej, men finns de något sätt att skapa ett nytt objekt på Wikidata genom Copy/Paste. Jag tänker mig ett upplägg om 2002 års upplaga av The International Who's Who of Women 2006 (Q88012245)? Jag kan ju inte vara 100% säker på att den person jag vill referera finns även i den senare upplagan, även om det är troligt. --Caztorp (diskussion) 5 juli 2020 kl. 13.15 (CEST)

Magnus Manske har ett tillägg "Duplicate this item" som du lägger in i din commons.js.
importScript( 'User:Magnus_Manske/duplicate_item.js' );
Jag skapar massa objekt för Öppna data portaler och då spar man en hel del tid - Salgo60 (diskussion) 9 juli 2020 kl. 00.14 (CEST)
Tack, mycket användbart. Det gäller bara att hålla tungan rätt i mun och redigera rätt objekt, kopian inte originalet.--Caztorp (diskussion) 9 juli 2020 kl. 09.11 (CEST)
Ja, ju kraftfullare verktyg man använder desto viktigare är det att man inte slarvar och lägger lite av den "sparade tiden" till att granska resultatet. För objekt med många egenskaper som dupliceras är det lätt att missa att ändra på några värden som behöver ändras. Det är lite synd att man inte på något sätt aktivt behöver ange, per egenskap, om den bara ska kopieras eller också behöver ändras efter kopieringen.
Ett exempel på när det blev tokigt vid användningen av nämnda verktyg är "dupliceringen" av objektet för Johan Olof Hålén (Q89005211) till objektet för hans maka Theresia Charlotta Lönnerberg (Q89006806) som gjordes den 30 mars 2020. Objektet hade ett dussintal egenskaper där flertalet behövde ändras eftersom de ska ha andra värden för makan än för maken.
Många av de nödvändiga uppdateringarna av egenskaperna med värden för makan och med källor etcetera gjordes i det nya objektet under den första halvtimmen efter dupliceringen, men för några egenskaper dröjde det tyvärr mycket längre:
Theresia Charlotta Lönnerberg (Q89006806) var alltså en man (Q6581097) i Wikidata under 80 dagar!
Exakt samma slarvfel med "oändring" av den kopierade egenskapen kön (P21) gjordes
--Larske (diskussion) 9 juli 2020 kl. 14.15 (CEST)
Tack för varningen, Larske. Ja, jag tyckte det var nervöst, trots att jag kopierade ett såpass simpelt objekt.Caztorp (diskussion) 9 juli 2020 kl. 14.41 (CEST)
@Larske: fyi en aktivitet för bättre Wikidata kvalitet är att Ainali verkar kunna dra ihop en online ShEx workshop, vi har haft bra fart i Telegramgruppen Wikidata Sverige och det görs en hel del med Riksdagsledamöter över tid, HD domar målnummer i Högsta domstolen i Sverige (P8407), Medlemmar av Svenska akademin och deras koppling till sin stol ex. stol nummer 11 i Svenska Akademien (Q96600367) , tankar finns med Riksdagsdokument , jag håller på med portal för öppna data (P8402). Tanken med ShEx online workshopen är att Andra Waagmeester och Jose Emilio Labra Gayo (University of Oviedo) är med och visar vad man kan göra se exempel video 2019 - Salgo60 (diskussion) 11 juli 2020 kl. 06.48 (CEST)

Slutdatum småorterRedigera

Är det någon som vet varför slutdatum (P582) för Q14839548 (småort i Sverige) i exempelvis Q2639696 (Lösen) har satts till 30 december istället för den 31:a? ✍️(skrivet av:) GeMet(användare:) 💬  den 8 juli 2020 kl. 02.10 (CEST)

@YesDi: som gjort det. GeMet (diskussion) 8 juli 2020 kl. 02.13 (CEST)
Det här var ett tag sedan så att jag kommer faktiskt inte riktigt ihåg. Jag misstänker att jag följde efter hur andra hade gjort före mig, se till exempel Q2671780 (Albano). YesDi (diskussion) 8 juli 2020 kl. 10.50 (CEST)
Jag tror att @Sextvåetc: är den som bäst kan svara på varför det är 30 december som har angivits som slutdatum (P582) för småorterna då dessa började formas i Wikidata för omkring fyra år sedan. Min gissning är att det beror på att startdatum (P580) för det som objektet övergick till att vara, till exempel en tätort, är satt till 31 december och att man har velat undvika att ett objekt har varit både småort och tätort samma dag, den 31 december. Då blir den naturliga följdfrågan varför inte startdatum (P580) är satt till 1 januari och min gissning här är att egenskaperna folkmängd (P1082) och area (P2046) av SCB anges per den 31 december, även för nya orter, och det kanske skulle verka konstigt om det, för en små/tätort, redovisades dessa data för en tidpunkt (P585) innan ortens startdatum (P580).
Det ser ut som om det är konsekvent genomfört, precis som YesDi påpekade.
--Larske (diskussion) 8 juli 2020 kl. 12.04 (CEST)
Avstämningsdatumet för småorter är 31 december. (Tätorter ibland 1 november.) Lösen var alltså småort fram till avstämningen den 31 december 2015 (men inte till och med 31 dec). För att Lösen inte ska komma med i en (automagiskt framtagen) lista som beskriver alla småorter per 31 december 2015 har jag valt 30 december som slutdatum. Rent filosofiskt kan man tänka sig andra lösningar. Statistiken togs ju inte fram förrän någon gång 2016, så man kan motivera att Lösen var småort fram tills dess. Man kan också argumentera att Karlskrona och Lösen växte samman vid någon (okänd) tidpunkt mellan 2010 och 2015. Datumet borde kanske därför vara tidigare. Jag är öppen för förslag. 62 osv (diskussion) 8 juli 2020 kl. 12.19 (CEST)
Det är lurigt med "fram till" och "till och med". En automagiskt framtagen lista kan i och för sig exkludera orter som har ett slutdatum (P582) som är mindre än eller lika med 31 december. Men så länge vi är konsekventa och använder samma datum för alla orter som slutade att vara småorter i slutet av ett visst år så spelar det mindre roll om det är 30 december eller 31 december. Någon tidigare (okänd) tidpunkt bör vi däremot inte stoppa in.
--Larske (diskussion) 8 juli 2020 kl. 12.32 (CEST)
Samma typ av frågeställningar möts man av när man ska beskriva sammanslagningar av kommuner, vilket jag jobbat med i Norge ett tag. Upphörde/slogs kommunerna samman 31 december 2019 eller 1 januari 2020? Det vanligaste är att en kommun "upphör" 31 december och att den "ersätts" 1 januari, men det finns undantag. 62 osv (diskussion) 8 juli 2020 kl. 12.37 (CEST)

Om jag har förstått det korrekt så spelar det inte så stor roll om det är den 30:e eller 31:a? Anger vi samma slut/startdatum i alla objekt eller är det en blandning av datum? Bör vi använda oss av någon slags kommentar på WD så man i framtiden förstår varför vi gjort som vi gjort? Med syntaxförklaring (P2916) (med hjälp av bot)? ✍️(skrivet av:) GeMet(användare:) 💬  den 8 juli 2020 kl. 14.35 (CEST)

När tätortsavstämningarna gjorts den 1 november (istället för 31 december) så har slutdatumet angivits 31 oktober. Så principen vi följt är att vi skrivit in datumet en dag före den avstämning där orten inte är tätort/småort längre. 62 osv (diskussion) 8 juli 2020 kl. 14.42 (CEST)

JordenRedigera

I faktamallen i artikeln om Jorden står det just nu "uppkallad efter jord och dirt". Det finns inte i wikikoden i artikeln, så jag gissar att det har med Wikidata att göra? Hur kan man få bort "dirt" eller i alla fall översätta det, se frågan på Diskussion:Jorden#Uppkallad efter jord och dirt ???. Vore tacksam för hjälp, för jag vet inte. Höstblomma (diskussion) 11 juli 2020 kl. 19.26 (CEST)

...fick hjälp på tre röda, löst nu, tack till Plumbum208. Höstblomma (diskussion) 11 juli 2020 kl. 19.31 (CEST)
Det stämmer att "dirt" hämtas från Wikidata. Det beror på att någon har lagt in värdet dirt (Q21152267) för egenskapen uppkallad efter (P138) i Wikidataobjektet Jorden (Q2). Objektet dirt (Q21152267) saknar i skrivande stund en svensk etikett och det är därför som den engelska etiketten, dirt, används. Om man vill ge detta objekt en svensk etikett görs det här. Om man inte tycker att dirt (Q21152267) ska vara ett värde på uppkallad efter (P138) för objektet Jorden (Q2), kan man redigera bort det här.
Eller så kan man välja att ignorera Wikidata för denna egenskap i faktaboxen i artikeln Jorden, vilket Plumbum208 gjorde. Det sistnämnda påverkar dock endast svwp och lämnar resten av världen med denna "dirt".
--Larske (diskussion) 11 juli 2020 kl. 19.43 (CEST)
Just "uppkallad efter" kan vara lite knepig. En diskussion som dök upp tidigt var hur man skulle använda denna property för tex Kvicksilver, som är uppkallad efter olika saker på olika språk. Jag vet inte hur det föll ut, men detta är ett typexempel på en property som ofta måste skrivas över lokalt. 62 osv (diskussion) 11 juli 2020 kl. 19.54 (CEST)

(Redigeringskonflikt)

Parametern uppkallad i {{Faktamall himlakropp}} är inte tillämplig på alla himlakroppar, se Malldiskussion:Faktamall himlakropp#Uppkallad efter. Det är, förmodligen i de flesta språk, snarare namnets etymologi som behöver beskrivas i artikeltexten och etymologi är något annat än uppkallad efter. Jag kan inte avgöra om det är lämpligt att ta bort egenskapen named after från jordens och månens WD-objekt. Hämtning från Wikidata kan, som sagt, undvikas med att sätta parametern till noWikidata. Plumbum208 (diskussion) 11 juli 2020 kl. 20.00 (CEST)
Ja, när jag nu jobbat med en WD-mall för amerikanska städer, så har jag valt att ha kvar parametern "etymologi". Men den förklarande texten (labeln) ser olika ut beroende på om uppgiften är lokal eller om den är från Wikidata. 62 osv (diskussion) 11 juli 2020 kl. 20.12 (CEST)
Istället för att ta bort egenskapen "uppkallad efter" kan man ange språk som bestämningsord om de är olika. Och man skulle kunna göra mallen så att den prioriterar de med svenska. Ainali diskussionbidrag 11 juli 2020 kl. 23.07 (CEST)

Wikipedia-referenserRedigera

För uppgifter med Wikipedia som källa, anges faktiskt bara språkversion? Objektet Terijokiregeringen anges ha haft Helsingfors som huvudstad med engelskspråkiga Wikipedia som källa. Jag tycker källhänvisningen borde följas av en permanent länk till artikeln ifråga, men nej. Är det meningen att sådana uppgifter skall vara omöjliga att spåra eller är det meningen att man skall lusläsa historiken till alla artiklar som kunde vara relaterade till påståendet? I det här fallet anger den nuvarande faktarutan i Finnish Democratic Republic att Helsingfors var "claimed capital" medan Terijoki var "factual capital" (utan källangivelse). I Wikidata anges endast Helsingfors utan någon bestämning annat än tidsintervallet, vilket ger intryck av att Helsingfors varit ockuperat.

Vilken bestämning skall man tillföra huvudstadsegenskapen? Har importen sköts enligt normal eller bästa praxis (för de fall källan som används på Wikipedia inte spårats)? --LPfi (diskussion) 14 juli 2020 kl. 12.24 (CEST)

Har inte tillgång till datorn nu, men ofta har man "skördat" data med automatiska verktyg som inte haft förmåga att tolka sådana finesser som "hävdad" och "praktisk" huvudstad. Idag finns det propertys som tillåter permlänkar. Det fanns inte från början. 62 osv (diskussion) 14 juli 2020 kl. 13.24 (CEST)
Oavsett det så borde permanent länk vara självklar. Har det inte varit uppe för diskussion?--LittleGun (diskussion) 15 juli 2020 kl. 15.48 (CEST)
@LittleGun: Wikimedia import URL (P4656) har funnits i ett par år, medan importerat från Wikimediaprojekt (P143) är över sju år gammal. Under de här fem åren har det tillkommit många påståenden utan permlänk. Det bästa är om ni ersätter det här med riktiga källor istället för Wikipedia. 62 osv (diskussion) 15 juli 2020 kl. 16.10 (CEST)
De källorna skulle förstås vara lättare att hitta med hjälp av permalänkarna eller ens länkar till rätt artikel – om vi antar att material på Wikipedia varit källbelagt. Om det är en viktig uppgift om ett viktigt ämne kan man väl anta att det går att hitta källor, t.ex. i samband med att man inför uppgiften i en Wikipedia-artikel – men hur gör man om man tvivlar på uppgiftens sanningshalt såsom i det här fallet.
Det är tänkbart att Terijoki-regeringen deklarerat Helsingfors som sin huvudstad, men uppgiften kan också vara hämtad från planer som aldrig förverkligades. Skall man helt enkelt ta bort allt man inte lätt hittar källa till? Hur mycket skall man söka efter källor till en uppgift som kan vara tagen ur luften men också kan finnas belagd i dammiga ryska arkiv, eller på Internet men på ryska? Det är svårt att söka då man inte vet hur uppgiften var formulerad i den ursprungliga källan.
--LPfi (diskussion) 15 juli 2020 kl. 16.28 (CEST)
källäge (P1480) öppnar för en del möjligheter. 62 osv (diskussion) 15 juli 2020 kl. 16.44 (CEST)
Det är ju viktigt för Wikidatas skull att permlänk används.--LittleGun (diskussion) 15 juli 2020 kl. 21.24 (CEST)
Jag tror problemet har i mycket varit att det är mycket enklare att skapa ett verktyg som lägger in samma källa (xxwp) i hundratals artiklar, än ett som lägger in olika (url=xxx) i varje artikel. Attityden bland många användare har varit, och kanske fortfarande är, att det är viktigare att vi har statements i artiklarna än att vi har ingenting alls. Om sedan dessa statements är korrekta eller inte har varit sekundärt. 62 osv (diskussion) 17 juli 2020 kl. 10.52 (CEST)
OK, men går det att påtala på något vis? Det borde väl finnas tillräckligt med folk på Wikidata som tycker det är självklart att använda perma-länk? Eller ska man bara resignera?--LittleGun (diskussion) 17 juli 2020 kl. 11.13 (CEST)
(Redigeringskonflikt) @LittleGun: Det är ingen som argumenterar emot dig om att det vore bra med permanentlänkar. Vi förklarar bara att det idag inte finns krav på sådana på Wikidata. Personligen tror jag att Wikidata är ganska långt ifrån att anta att en sådan regel, främst baserat på att det isåfall på grund av någon slags konskevensargument att de då först måste börja ställa krav på att alla påståenden måste ha en källa. Men det går ju alltid att väcka frågan på Project chat. Ainali diskussionbidrag 17 juli 2020 kl. 11.21 (CEST)
Jag har aldrig trott att någon argumenterar mot mig. Jag har bara undrat om det har diskuterats, och om det finns såna krav på Wikidata eller inte. Att det inte finns har inte framgått förrän i ditt svar. Och jag ville veta om det finns konsensus för att strunta i det eller om det finns någonstans att "kravställa" det. Jag känner mig väldigt osäker på hur jag ska formulera det på Wikidatas Bybrunn. Det finns inte chans att jag skulle kunna använda rätt vokabulär. "Statements" till exempel. Jag trodde det var statements som källbeläggs med Wikipedia som källa ibland.--LittleGun (diskussion) 17 juli 2020 kl. 11.34 (CEST)

(Redigeringskonflikt)I det arbeta jag bedrivit (med andra) för att förstärka Wikipedia med Wikidatakopplingar så har jag funnit att källreferenser i Wikidata är den svagaste punkten. Det går ju lägga dit men i praktiken har det bara blivit ordning när en bot från en "riktig källa" laddat data i wikidata och då också lagt in kompletta källreferenser. Detta är inte bara ett "tekniskt" svår grej, utan även filosofiskt. När fakta i Wikipediaartikeln är korrekt källbelagd, hur göra? Ladda upp källor parallellt och oberoende hur det ser ut i Wikipediaartiklen, eller automagiskt ladda Wikidata med referenserna som finns i Wikipediaartikeln? Det liknar dilemmat med översatta artiklar men är än knepigare. Att ladda Wikidata med oprecisa, sladdriga referenser (som använts i Wikipediaartikeln) kan göra stor skada brett och nästan bättre att då inte ha något alls, som indikerar det är en "brist".Yger (diskussion) 17 juli 2020 kl. 11.44 (CEST)

Att använda permalänk eller åtminstone inkludera artikelnamnet är väl oproblematiskt, men att plocka den källa från Wikipedia som verkar stöda utsagan är vanskligt. Det är tillräckligt svårt att för hand avgöra vilken källa som stöder en viss uppgift – ofta kommer källangivelsen efter flera meningar varav kanske bara den sista stöds, och stycket kan ha redigerats så att inte ens den stöds av källan (om källan överhuvudtaget använts rätt). Det är rimligt att endast hänvisa till Wikipedia-artikeln (om möjligt med permalänk). Men om inställningen varit "Om sedan dessa statements är korrekta eller inte har varit sekundärt." så är det klart att vi inte kan använda dem. Förhoppningsvis har inställningen varit en annan när mer specifika källor angivits. Jag antar att problemet i de fallen rör specifika källor, såsom geonames hos oss. --LPfi (diskussion) 17 juli 2020 kl. 12.47 (CEST)
Den inställningen/uppfattningen får stå för 62, och inte som en sanning. Jag delar den inte och skulle näst intill påstå att det är smutskastningsförsök. Det är oproblematiskt att använda permalänk, det är ingen som hindrar dig från att göra det. Om det var det som är frågan så är den löst. Men om du vill tvinga alla att använda den så är det en annan femma, och då hjälper det inte ens om vi kommer till konsensus här. Policy för respektive projekt diskuteras bäst med den gemenskapen i deras forum. Ainali diskussionbidrag 17 juli 2020 kl. 13.00 (CEST)
Ja, jag tycker det borde vara tvingande. Jag är engagerad på svenskspråkiga Wikipedia. Det är via det som jag "drabbas" av Wikidata. Eftersom jag inte är så engagerad i Wikidatagemenskapen är det bökigt att veta ens om det har diskuterats. Då tycker jag det är rimligt att börja här och se vad de som är engagerade i båda projekten menar, och kanske få en aning om ifall det diskuterats. Jag tog upp frågan även på den bybrunnen. Det verkar inte vara någon som tycker det är viktigt. Någon sorts missuppfattning blev det, men också en vinkning om att det går att spåra via respektive historik. Vilket jag tycker haltar. Synd, jag tycker verkiligen perma-länk borde används.--LittleGun (diskussion) 17 juli 2020 kl. 17.45 (CEST)
Det vore rimligt att rekommendera permalänkar och se till att allmän infrastruktur (botkod) stöder dem. Däremot är ett krav besvärligt, eftersom uppgifter importeras också från källor som inte stöder sådana. MediaWiki är en av få system som tillhandahåller dem konsekvent. Permalänken behövs inte heller för att se huruvida uppgiften stöds av nuvarande artikelversion. Om artikeln skrivits om så att källan eller uppgiften försvunnit (annat än tillfälligt) ligger det nära till hands att anta att uppgiften var felaktig, kontroversiell eller mindre relevant. Med en permalänk är det lättare att se att uppgiften aldrig fanns i artikeln eller att eventuell källa använts fel, men om uppgiften finns kvar är den och dess källa inte svårare att hitta i den senaste versionen. --LPfi (diskussion) 17 juli 2020 kl. 19.23 (CEST)
@LittleGun: Så du tycker att det är högre krav på källbeläggning på Wikidata än på Wikipedia? Vi ställer ju inget krav på att okontroversiella uppgifter ska vara källbelagda (som till exempel att någon är människa, vilket kön eller medborgarskap de har). Men vi drabbas inte heller. Vi har ju redan för alla mallar (så vitt jag vet) sagt att uppgifter som bara är källbelagda som importerad från en Wikipediaversion inte ska visas alls. Och då spelar det ju ingen roll om det finns permalänk. Eller menar du att permalänken skulle göra det okej att visa sådana uppgifter i mallarna?
@LPfi: Det är nog bara att sätta igång och förbättra botkoder. Jag har svårt att tänka mig att någon bot-förare på Wikidata motsätter sig det här, det är ju något som verkligen höjer kvaliteten. Ainali diskussionbidrag 17 juli 2020 kl. 21.12 (CEST)
På Wikidata talar man inte bara om att källbelägga saker, utan också att göra det spårbart. Därför källbeläggs också trivialiteter. 62 osv (diskussion) 17 juli 2020 kl. 21.23 (CEST)
Och innan ni tar upp att vi har historiken att leta i, så bevaras inte den på samma sätt på Wikidata. 62 osv (diskussion) 17 juli 2020 kl. 21.45 (CEST)
Ainali: Vad får du den tanken ifrån? Med tanke på att diskussionen gäller hur Wikidata bör göra när Wikipedia anges som källa, så skulle jag säga att standarden redan från förutsättningarna är satt lägre än den är här. Och de gånger vi anger en Wikipedia-artikel (vid översättning och infogning), så är det väl självklart att man anger en permanentlänk?
andejons (diskussion) 17 juli 2020 kl. 23.31 (CEST)
@andejons: 1) Vilken tanke? Det är för många olika inlägg nu för att jag ska förstå vad du syftar på. 2) Själv föredrar jag att alla källorna i en artikel som översätts kontrolleras självständigt och läggs in om man kan se att de ger stöd för det man skriver. Så när man anger permalänk där (och i infogning) så används inte ursprungsartikeln som källa, hänvisningen är enbart en attribuering för att uppfylla licensen. Ainali diskussionbidrag 18 juli 2020 kl. 00.19 (CEST)
Ainali, din fråga ovan (som också andejons svarade på):
"Så du tycker att det är högre krav på källbeläggning på Wikidata än på Wikipedia?"
Nej, jag har inte högre krav på källbeläggning på Wikidats än på Wikipedia. Men, när nu Wikidata använder Wikipedia som källa tycker jag det ska vara tvingande att använda permalänk från *till* Wikipedia-artikeln.
Så tvärtom, snarare. Jag har förstått att Wikpedia används som källa på Wikidata, vilket jag inte köper på Wikipedia annars. Vid översättning anger jag alltid permlänk, inte som källa utan för att visa varifrån jag översatt.--LittleGun (diskussion) 18 juli 2020 kl. 05.59 (CEST).
@LittleGun: Du menar till Wikipedia-artikeln, eller hur?
OK. Det kanske är rättare.--LittleGun (diskussion) 18 juli 2020 kl. 09.15 (CEST)
Aha, nu förstår jag hur ni menar. Och där har ni en poäng. Men det finns också en annan vinkel på det hela. För nu hamnar ju dessa på saker som inte normalt källbeläggs på Wikipedia. Till exempel behöver man inte källbelägga att Stefan Löfven är svensk. Men det är en typisk sak som får en sådan här källa på Wikidata (eftersom att sådana här importer baserar sig på kategorier). Så egentligen skulle det kunna vara utan en källa på Wikidata också, men nu får man i alla fall en pyttelite högre proviniens på påståendet. Men det finns ju såklart andra saker som är källbelagda på Wikipedia som gör att de också hamnar i en kategori (och sedan importeras till Wikidata). Så jag ser det som en gråskala, snarare än något som helt tvärsäkert kan svaras binärt på. Ainali diskussionbidrag 18 juli 2020 kl. 10.12 (CEST)
Även om det finns gradskillnader så är väl perma-länk alltid att föredra (om Wikipedia används spm källa på Wikidata)? Så på såvis finns ingen gråskala, även om det kan vara mindre viktigt. Jag tog upp det på Wikidatas bybrunn. Inget intresse, vilket förvånar.--LittleGun (diskussion) 18 juli 2020 kl. 10.18 (CEST)
Ja, det är alltid att föredra ur ett kvalitetsperspektiv. Men eftersom att det inte finns en regel om att påståenden måste ha källor så riskerar det att bli så att vertyggskapare som inte vet hur man skulle göra för att ange permalänk helt enkelt struntar i att ange källa alls. Och det måste väl ändå vara sämre än att ändå tala om från vilket projekt den är hämtad från? Ainali diskussionbidrag 18 juli 2020 kl. 10.30 (CEST)
Fast varför inte vara tvingande. Tvinga verktygsskaparna att ange källa, och använder de Wikipedia så ska de tvingas att använda permalänk. Men även Wikidata visar ointresse på sin bybrunn. "Bättre att använda 'riktiga källor'".--LittleGun (diskussion) 18 juli 2020 kl. 11.27 (CEST)
Ja, då är du tillbaka på högre krav på Wikidata än på Wikipedia. Själv tycker jag att okontroversiella uppgifter, på samma sätt som här, inte behöver källa på Wikidata, och att någon källa är bättre än ingen källa. Ainali diskussionbidrag 18 juli 2020 kl. 11.46 (CEST)
Nej, det är jag inte. Jag skulle aldrig ens använda Wikipedia som källa. Behövs ingen källa till en uppgift på Wikidata, men man väljer att sätta dit en ändå och väljer då Wikipedia. Då tycker jag att permalänk ska användas. För att det kostar inget och blir konsekvent. Nu används Wikipedia, utan att göra permalänk, även till icke-okontroversiella/självklara uppgifter. Med svagt intresse att agera om man ser på engagemnaget på bybrunnen där.--LittleGun (diskussion) 18 juli 2020 kl. 12.33 (CEST)
Ah, men jo det kostar. Om det vore trivialt att programmera, så skulle någon redan ha gjort det. Därför kan vi vara säkra på att utvecklingsinsatsen för att anpassa verktygen till detta inte är försumbar. Och skulle man då börja kräva detta så "kostar" det i form av uteblivna redigeringar på Wikidata. Och jag anser att vinsten av att ställa det kravet är för lågt i förhållande till risken att inflödet av användbart data skulle minska. Men att starkt uppmuntra permalänkar, och kanske skriva dokumentation om hur ett "best-practice" ser ut, det tycker jag att man kan göra, ens utan att diskutera mera. Ainali diskussionbidrag 18 juli 2020 kl. 13.32 (CEST)
Jag svarade på Wikidata men skulle man kunna stycka upp Wikipedia artiklar i fakta som lagras i Wikidata med ref till var i Wikipedia artikeln det sägs så när mer trovärdiga källor dyker upp och kopplas till Wikidata så skulle det vara enormt enkelt att med en SPARQL fråga och se i vilka Wikipedia språk vi har fakta som är motstridiga med det vi hittat i en mer trovärdig källa, idag är detta princip omöjligt..... - Salgo60 (diskussion) 18 juli 2020 kl. 12.20 (CEST)
Det verkar vara en helt annan fråga.--LittleGun (diskussion) 18 juli 2020 kl. 13.04 (CEST)
  • kan vi ha länkar från Wikidata till den exakta platsen i Wikipedia artikeln där detta sägs --> så öppnas nya möjligheter upp
    • vi kan splittra upp Wikipedia artiklar i fakta som läggs ned i Wikidata för alla Wikipedia språk så när vi hittar bättre källor i Wikidata -->
      • vi kan skriva en enkel SPARQL och hitta i vilka Wikipedia artiklar vi har troligen fel idag skalar detta inte bra om vi inte har infoboxar i artikeln...
dvs. bra länkar från Wikidata till platsen i Wikipedia artikeln öppnar upp nya möjligheter....
- Salgo60 (diskussion) 19 juli 2020 kl. 10.30 (CEST)
Jaha. Det är en helt annan fråga.--LittleGun (diskussion) 19 juli 2020 kl. 11.18 (CEST)
Den ursprungliga frågan gällde delvis vad man skall göra på Wikidata när man stöter på uppgifter som verkar kunna vara felaktiga och som har "Wikipedia" som källa. Kan sådana uppgifter strykas utan vidare om man inte lätt hittar dem (med källa) på Wikipedia, också om de kan vara sanna? Utan permalänk kan man inte utesluta att de var belagda i någon version av artikeln, med bara "Wikipedia" vet man inte ens i vilken artikel. --LPfi (diskussion) 18 juli 2020 kl. 08.29 (CEST)
Testa! Om du vet hur. Det borde vara självklart att kunna stryka uppgifter utan tydlig källa med den motiveringen.--LittleGun (diskussion) 18 juli 2020 kl. 08.54 (CEST)
Jag har tagit bort, eller rättare ersatt, hundratals wp-källor utan protester på wd. Idag gör jag nog oftare så att jag ger sådan data lägre rank. Ett påstående med lägsta möjliga rank tar sig inte hit om man inte explicit begär det. 62 osv (diskussion) 18 juli 2020 kl. 09.03 (CEST)
Vad som är lämpligast åtgärd kan nog variera beroende på vad som ligger bakom det som LPfi skriver som "verkar kunna vara felaktiga". Tyvärr erbjuder redigering av ett Wikidataobjekt (via den vanliga Wikidatasidan för objektet) inte någon möjlighet att ge en redigeringskommentar, men precis som i Wikipedia kan man (i många fall) ogöra en redigering och då finns möjligheten att också ge en kommentar till varför man ogör. Precis som i Wikipedia kan det vara bra att titta på vem som lagt in ett uttalande för att avgöra vilket som är lämpligaste sätt att kommunicera. Är det den enda redigeringen av en oinloggad användare kanske det kan vara ett klotter. Är det en redigering av någon som i övrigt verkar veta vad vederbörande håller på med, kanske det kan vara befogat med ett inlägg på vederbörandes användardiskussion och så vidare. Är det en redigering i en hel svärm av likadana redigeringar av en bot, kanske det finns andra objekt som drabbats av samma fel trots att det ännu inte märkts i någon svwp-artikel. Och så vidare...
Det sätt som Sextvåetc tar upp, att ge det "felaktiga" uttalandet en Orekommenderad rang, kan ofta vara effektivt för att stoppa återinläggning av uppgiften av någon robot, speciellt om det finns konstaterat felaktiga källor oavsett om de är Wikimedia-interna eller externa. När man gör det har man också möjlighet att komplettera uttalandet med ett bestämningsord, skäl för lägre rang (P2241), som talar om varför man anser att uppgiften inte bör användas.
Det finns ett stort antal Wikidataobjekt som är Wikidata-skäl för nedvärdering (Q27949697) och som används i olika utsträckning, se följande frågor:
Som framgår av den första listan finns det en hel del luckor vad gäller etiketter och beskrivningar på svenska. Men luckor brukar ju kunna fyllas...
--Larske (diskussion) 18 juli 2020 kl. 10.19 (CEST)
(Redigeringskonflikt)Om påståenden verkar osannolika och den angivna källan vid rimlig efterforskning inte stödjer dem kan de utan omsvep tas bort. Det kan ju helt enkelt ha stått fel någonstans just när importen gjordes och sedan har det rättats på Wikipedia. Men om de verkar stämma så tycker jag att du gör alla en otjänst (och riskerar förmodligen att bli blockerad) om du systematiskt raderar påståenden som är importerade från wikipedia. Ainali diskussionbidrag 18 juli 2020 kl. 10.20 (CEST)
Om man bara tar bort en uppgift, och det är den enda i sin property, så är risken stor att robotar lägger tillbaka den igen. Det blir ett redigeringskrig som är omöjligt att vinna. Det spelar då ingen större roll om du har rätt i sak eller inte. 62 osv (diskussion) 18 juli 2020 kl. 10.52 (CEST)
Det är sant. En hel del av importerna är dock engångsjobb, och boten återvänder inte till samma uppgift igen. Men ja, tar man bort något kan det vara värt att antingen hålla koll i Wikipediaartikeln för att se om uppgiften dyker upp igen i en Wikidatastödd infobox eller sätta objektet på sin bevakningslista. Eller använda något av tipsen om rankning. Ainali diskussionbidrag 18 juli 2020 kl. 10.58 (CEST)
Exemplet som LPfi tar upp med den kommunistiska finska staten återkommer nog inte samma robot till särskilt ofta. Det finns dock många robotar, och flera användare får ofta samma idéer. Vissa uppgifter är binära till sin natur. Om jag hittar att en svensk tätort har en vänort angiven, så räcker det aldrig att bara ta bort påståendet från tätorten. Man måste OCKSÅ ta bort motsvarande påstående från själva vänorten, eller ännu hellre rikta om det till kommunen istället och då gärna med en god källa. (Vilket inte är lätt.) 62 osv (diskussion) 18 juli 2020 kl. 11.06 (CEST)

Wikidata referenser/källor visionerRedigera

jag är naivt troende att trovärdighet kommer från trovärdiga källor och ställde frågan till en av hjärnorna bakom Wikidata Denny Vrandečić och fick ett fantastiskt intressant svar se video dvs. vi har enormt mycket att göra. Jag tycker mig mer och mer se att Google sökningar ger länkar om man kör webläsaren Chrome som hoppar till den del i texten som besvara det jag frågar med texten highlightad dvs. Wikidata borde kunna stödja att läsaren kan se vilken del av en referens som bekräftar det som sägs... och är det länkar till en Wiki artikel så borde vi kunna se hur texten såg ut i den version som var aktuell då referensen akapades - Salgo60 (diskussion) 18 juli 2020 kl. 11.56 (CEST)

Sjabblat?Redigera

Jag lade till {{databox}} i artikeln What3words. Då stod det "Gatuadress föråldrad" på gatuadressen. Så jag gick in i wikidataobjektet what3words (Q20489028), bytte gatuadress (föråldrad) (P969) mot gatuadress (P6375) eftersom det verkade vara instruktionen. Nu syns ingen gatuadress alls i databoxen för What3words. Gjorde jag rätt och det är bara cacheproblematik eller har jag sjabblat?--LittleGun (diskussion) 21 juli 2020 kl. 18.16 (CEST)

Du gav ingen källa för din version, och på Wikipedia ignorerar (alla?) WD-mallarna uppgifter utan källangivelse. --LPfi (diskussion) 21 juli 2020 kl. 19.50 (CEST)
Jag trodde först också att det kunde bero på att du inte hade lagt dit någon källa för uttalandet om gatuadress (P6375), men det var inte skälet här. Anledningen är att Databox, på rad 541 i koden, "dissar" en property om den är av typen "Enspråkig text" (monolingual text), vilket gatuadress (P6375) är till skillnad från gatuadress (föråldrad) (P969) som är av typen "Sträng" (string). Detta dissande av gatuadress (P6375) kan överridas genom att lägga till P6375 till "vitlistan" (på rad 124 i koden) av properties som ändå ska visas.
@LittleGun: Men lägg gärna in en referens ändå till gatuadressen i Wikidata.
--Larske (diskussion) 21 juli 2020 kl. 20.18 (CEST)
Tillägg: Det finns för närvarande 50 properties i Wikidata som är av typen "Enspråkig text".
  • Länk till fråga som ger en lista över properties, med engelsk och svensk etikett, som är av typen "Enspråkig text".
Ingen av dessa finns idag med på vitlistan och kommer därför aldrig att visas i faktarutor som skapas av {{Databox}}.
--Larske (diskussion) 21 juli 2020 kl. 20.38 (CEST)
Jag lade till officiellt namn (P1448) och gatuadress (P6375) i databoxmodulen. Vad händer om ett objekt har två gatuadresser, t ex i Helsingfors eller Brussels? Används språkordning eller visas bägge?--北山 Kitayama (diskussion) 21 juli 2020 kl. 20.58 (CEST)
Inte svar på fråga, men vad gäller officiellt namn (P1448), skulle jag råda till yttersta försiktighet. Det är ett typexempel på en property som används lite som man känner för. 62 osv (diskussion) 21 juli 2020 kl. 21.01 (CEST)
Då tar jag bort den igen. För gatuadress (P6375) gäller att bägge adresserna visas och hänsyn tas inte till språk. --北山 Kitayama (diskussion) 21 juli 2020 kl. 21.03 (CEST)
Jag gissar att det är för att modulen inte innehåller någon hantering/val av språk som properties med typen "Enspråkig text" inte visas.
--Larske (diskussion) 21 juli 2020 kl. 21.07 (CEST)
Gymnasiet Kallion lukio (Q5401711)/gatuadress (P6375) → Porthaninkatu 15, Porthaninkatu 15, 00530 Helsinki, Porthansgatan 15, 00530 Helsingfors, Porthaninkatu 15, 00530 Helsinki, Porthaninkatu
Som framgår av databoxen till höger, som alltså visar tre värden på finska, ett på svenska och ett på engelska, fast i en salig blandning, är det nog inte så lämpligt att {{Databox}} visar gatuadress (P6375) utan ytterligare filtrering på språk. Jag är därför tveksam till om gatuadress (P6375) bör finnas med på vitlistan.
--Larske (diskussion) 21 juli 2020 kl. 21.33 (CEST)
Problemet med de här propertysarna, är att de tas som en inbjudan att översätta det till vad för språk som helst. Att Norge har ett officiellt namn på kvänska är väl ok. Men att det har ett officiellt namn på tyska och gudvetvad, känns som högst märkligt. Vad gäller bildtext är det relevant att stoppa in vad för för språk som helst, men inte många andra ställen. 62 osv (diskussion) 21 juli 2020 kl. 21.51 (CEST)
@Sextvåetc: Har du några exempel på när P1448 används på andra sätt än föra att just ange officiellt namn? Ainali diskussionbidrag 24 juli 2020 kl. 21.47 (CEST)
@Ainali: Tja, varför har d:Q34 ett "officiellt namn" på tjeckiska, franska och estniska? Konungariket Sverige Uppgiften på franska har till och med en källa angiven. Men tittar man i den så styrker den snarare att Sverige bara har ett officiellt namn på svenska och inget annat. 62 osv (diskussion) 25 juli 2020 kl. 07.42 (CEST)
Oh, intressant exempel, tack! Men jag läser källan för franska som att Commission nationale de toponymies officiella namn för Sverige på franska är "le Royaume de Suède" och att Sveriges officiella namn på svenska är "Konungariket Sverige". Så det är inte "fel" att påstå att någon har det som ett officiellt namn. Däremot är det fel att ange dem på objektet med hjälp av egenskapen eftersom den bara ska ha objektets språks officiella namn. Så i det här fallet är det lätt, de som har lagt på namnet har missförstått egenskapen, och jag har tagit bort tjeckiska franska och estniska då de bryter mot egenskapens syfte. Ainali diskussionbidrag 25 juli 2020 kl. 09.45 (CEST)
Ja, det är exakt det jag menar. Egenskaper där syftet missförståtts i stor grad, får sitt värde devalverat. Samma sak kan sägas om egenskaper där man lagt in en massa data utan att tänka igenom hur det beskrivs bäst. Tidszoner är en sådan egenskap. Vänorter är också ett exempel på där man lagt in massor av data, utan vettiga källor och utan att kontrollera om det blev rätt. Där vill jag tom säga att modellen har sina svagheter, då den inte tar några hänsyn alls till vilket typ av samarbete vänortskapet innebär. 62 osv (diskussion) 25 juli 2020 kl. 09.54 (CEST)
Jag har en inte fullt så uppgiven inställning. Ser vi fel rättar vi dem, ser vi användare som gör upprepade fel diskuterar vi med dem. Med många små ändringar kan alla egenskaper göras användbara. Ainali diskussionbidrag 25 juli 2020 kl. 10.03 (CEST)
Att språk för officiellt namn (P1448) endast bör användas för sådana språk som är ett officiellt språk (P37) för objektet är ju helt i linje med egenskapens definition, även om detta har diskuteras på d:Property Talk:P1448. Mot denna regel, som låter mycket rimlig, finns det dock en hel del avvikelser, se följande fråga:
Objekt som helt saknar officiellt språk (P37) är exkluderade och värden på officiellt namn (P1448) som har värdena med språk lika med mul (multiple) eller und (undefined) är också exkluderade. För att inte få timeout på frågan har jag också exkluderat officiellt namn (P1448) på språket de-ch som det finns ett stort antal av för objekt som har de som officiellt språk (P37). Genom att invertera det sista filtret i frågan kommer listan att istället innehålla just dessa, de är ungefär lika många.
Det finns som synes en hel del att städa. Värst i klassen ser Ecuador (Q736) och Sydafrika (Q258) ut att vara, det sistnämnda objektet har, trots elva olika officiellt språk (P37), sex värden på officiellt namn (P1448), varav två på franska, på andra språk än de 11 officiella.
@Ainali: När du städade i Sverige (Q34), övervägde du då möjligheten att istället för att ta bort påståendet, ge det en Orekommenderad rang med något lämpligt värde för bestämningsordet skäl för lägre rang (P2241) som talar om att språket inte är ett officiellt språk (P37) i Sverige (Q34)? Risken är väl annars rätt stor att namnformen dyker upp igen.
--Larske (diskussion) 25 juli 2020 kl. 11.39 (CEST)
Rent tekniskt är inte svenska officiellt språk i Sverige, vilket rör till det för användare som gärna vill tolka reglerna per bokstav. Men det bör åtminstone finnas någon vettig koppling mellan vilka språk som är lämpliga i P1448 och objektet. (Exempelvis tjeckiska och Sverige saknar sådan koppling.) Sedan har vi de fall där man importerat data från en parameter i en mall någonstans. Det gör att det finns många fall av "Average" där det egentligen borde vara "City of Average" eller liknande som officiellt namn. 62 osv (diskussion) 25 juli 2020 kl. 11.57 (CEST)
Tack för bra städqueries! Det var ju inte så många att städa. Nej, jag övervägde inte att använda rang eftersom att det var en uppenbar felanvändning av egenskapen snarare än ett värde som möjligtvis kunde varit korrekt. Lite som att ange Carl XVI som regeringschef (P6) för Sverige. Visserligen kung, men det är inte det egenskapen ska användas till, inte ens med orekommenderad rang. Ainali diskussionbidrag 25 juli 2020 kl. 12.07 (CEST)
Jag skulle verkligen välja att de dem deprecated rank då. (Även Calle 16 som regeringschef.) Det ger för det första möjligheten att motivera varför man tagit bort dem, och för det andra blir det uppenbart att påståendet inte bara är borttaget för att man är i raderingssugen. I synnerhet det franska påståendet som var källbelagt hade jag låtit ligga kvar som deprecated. 62 osv (diskussion) 25 juli 2020 kl. 17.24 (CEST)

Kategorierna Wikidatamallar och Mallar som använder data från WikidataRedigera

Borde inte dessa slås ihop? Så att samtliga mallar i dessa båda ligger under Kategori:Mallar som använder data från Wikidata och Kategori:Wikidatamallar omdirigerar dit?--LittleGun (diskussion) 21 juli 2020 kl. 19.21 (CEST)

Mallar kan ha att göra med Wikidata utan att använda data därifrån. T.ex. Mall:Wikidataikon eller Mall:Wdpen. F.d. 82.212.68.183 (diskussion) 21 juli 2020 kl. 19.38 (CEST)
Fast är det en wikidatamall då? Är de som ligger i Kategori:Wikidatamallar rätt i så fall?--LittleGun (diskussion) 21 juli 2020 kl. 21.10 (CEST)
Allt kanske inte ligger rätt, och namnet är kanske dåligt, men det vore bra att skilja på mallar som bara är Wikidatarelaterade och sådana som hämtar data också. Kanske en överkategori som heter just så "Wikidatarelaterade mallar" som "Mallar som använder data från Wikidata" ligger i? Om vi bestämmer hur vi vill att strukturen ska se ut blir det inte så krångligt att omkategorisera sen. Ainali diskussionbidrag 24 juli 2020 kl. 21.43 (CEST)

NAD Nationell Arkivdatabas P5324Redigera

Nationell Arkiv Databas (P5324) andvänds idag mest på kyrkarkiv lista och har nu kommit i ny design med persistent id tidigare var det ett namn som bestod av olika delar beroende på var arkivet fanns

Jag har felanmält NAD under åren för att det varit problem och hört att dom skulle göra om det och nu verkar det ha smugits in så

jag ringde Riksarkivet NAD och fick väl inte dom svar jag önskade om vad dom har för planer (jag tycker dom borde bygga en egen kunskapsgraf modell Wikidata och koppla samman arkiv/personer/kyrkböcker som vi gör i Wikidata), försökte förstå om det finns ett API etc.... men inget svar hon hänvisa att ringa senare pga semester...

Min fundering är

  • Fråga: eftersom Wikidata ser ut som det gör skall vi ha kvar Nationell Arkiv Databas (P5324) med det läsbara namnet och skaffa en ny Wikidata egenskap med ID som blir länken...
    • NAD numret i "klartext" är bra att ha då det används av släktforskare...
  • någon som har bra kontakter med Riksarkivet som kan kolla mer? min kontakt Olof är på semester och är lite svår pratad plus Riksarkivet saknar helpdesk diskussionsfunktion på nätet och knappt svarar på email...

Min vision har varit att Wikidata / Wikipedia skall ha alla arkiv kopplingar och att Wikipedia blir det naturliga stället man startar då man skall leta information. Jag hade 2019 i mars ett möte med NADs systemägare men det blev inget konkret...

Att göra ser vi konstigheter med dagens arkiv länkar så dela med er för det kan kanske bero på de ändringar de gör... - Salgo60 (diskussion) 24 juli 2020 kl. 19.52 (CEST)

Testar ny variant med Länk till posten i referens-url (P854) se Q6238716#P5324 känns dock fel att hitta på nya mönster bara för en WD egenskap lever sitt eget liv... - Salgo60 (diskussion) 25 juli 2020 kl. 16.06 (CEST)

"hämtat från: svenskspråkiga Wikipedia, (Källa från Wikidata)"Redigera

Hur undviker vi att få rundgång? Faktaboxen i Irma Christenson hämtar från Wikidata. Källan i Wikidata är "imported from Swedish Wikipedia" - det står inte ens vilken artikel det importerats från. Nu finns en riktig källa i löptexten, men... det ser inte bra ut. --北山 Kitayama (diskussion) 28 juli 2020 kl. 23.27 (CEST)

Referenser i Wikidata som är av typen importerat från Wikimediaprojekt (P143) är ett otyg. De bör alltid ersättas av "riktiga", Wikimediaexterna, referenser. Jag har gjort så nu för Irma Christenson (Q4942840), se d:Q4942840#P119.
--Larske (diskussion) 29 juli 2020 kl. 00.51 (CEST)
På Wikidata verkar det vara underförstått att det är hämtat från artikeln om objektet i fråga. Dvs. länken finns bland webbplatslänkarna. Ainali diskussionbidrag 29 juli 2020 kl. 11.12 (CEST)
Ja, för den som vill leta efter en "riktig" källa att lägga in i Wikidata är den länkade Wikipediartikeln en bra startpunkt. Jag tror att det i 99,9.. procent av fallen är just den till objektet länkade Wikipediaartikeln som är källan. Men det är inte alltid det finns någon "riktig" referens för uttalandet i den artikeln. Det kan lika gärna vara en källös kategorisering, i värsta fall resultatet av ett klotter, som ligger till grund för någon robot som lägger in uttalanden om till exempel födelseplats (P19) eller sysselsättning (P106). Tyvärr.
--Larske (diskussion) 29 juli 2020 kl. 11.25 (CEST)
Det finns tusentals påståenden om att X är vänort med Y med Italienskspråkiga Wikipedia som källa, men jag har hittills aldrig sett ett enda exempel på när itwp över huvud taget haft den uppgiften. 62 osv (diskussion) 29 juli 2020 kl. 11.30 (CEST)
Har du något exempel Sextvåetc? Utöver min egen nyfikenhet skulle jag vilja skicka vidare det till italienska Wikidataanvändare som kanske kan luska i det. Ainali diskussionbidrag 29 juli 2020 kl. 11.39 (CEST)
Jag och Yger har nog städat bort det mesta, men du kan leta i historiken i godtycklig svensk centralort, vars namn överensstämmer med kommunnamnet för att hitta sådana påståenden. Att centralorten fått påståendena istället för kommunen är ett vanligt misstag som alla gör, men var källan till påståendena står att finna, är höjt i dunkel. 62 osv (diskussion) 29 juli 2020 kl. 11.46 (CEST)
@Ainali: Här är en lista på 311 redigeringar jag gjorde den 22 juni för att städa bort felaktiga vänort (P190). Bland dessa kan du kanske hitta en del som har itwp som källa. På tätorter där jag tog bort en vänort (P190) la jag ibland in no value i en förhoppning att det skulle förhindra framtida återläggningar av felaktiga värden av robotar, men jag hittade även exempel på när det redan fanns no value vilket man struntat i, så jag har inte gjort någon systematisk inläggning av vänort (P190)=no value för alla tätort i Sverige (Q12813115).
--Larske (diskussion) 29 juli 2020 kl. 12.55 (CEST)
Jag tog en på slump, men den var inte importerad utan manuellt inlagd... Ainali diskussionbidrag 29 juli 2020 kl. 18.23 (CEST)
Om den är manuellt inlagd eller inlagd med bot spelar mindre roll, det är lika illa med importerat från Wikimediaprojekt (P143) oavsett vilket verktyg som har använts för att stoppa in det. Och i exemplet som du tittade på gavs ju ingen källa alls, så egentligen skulle den nog bara plockas bort i stället för att ändra till kommunen som jag gjorde.
Här är ett exempel på en vänort (P190) som är en tätort, inlagd med bot och med importerat från Wikimediaprojekt (P143) italienskspråkiga Wikipedia (Q11920) som källa.
--Larske (diskussion) 29 juli 2020 kl. 20.43 (CEST)
Tack! I den var det dock inget mysterium varför importen blev som den blev, det står ju så i artikeln. Fel visserligen, men uppgiften finns ju där. Ainali diskussionbidrag 29 juli 2020 kl. 23.22 (CEST)

Kategori:Mallar och moduler efter propertyanvändning på WikidataRedigera

Jag har just skapat Kategori:Mallar och moduler efter propertyanvändning på Wikidata. Fler projekt har motsvarande kategorier, men per artikel. Det har jag bedömt plottrigt och undvikit. Här är nu kategorin införd, men för mallar och moduler istället. Åsikter? Det är {{Propertyspårning}} som skapar kategoriseringen. (Det finns ingen teoretisk övre gräns för hur många parametrar den mallen kan ta emot.) 62 osv (diskussion) 3 augusti 2020 kl. 17.50 (CEST)

Naturligtvis fick jag en massa felstavningar nu, men det kanske någon admin kan hjälpa till med att flytta kategorierna? 62 osv (diskussion) 3 augusti 2020 kl. 17.54 (CEST) diff
Tror att alla ska vara flyttade nu! YesDi (diskussion) 3 augusti 2020 kl. 18.03 (CEST)
@Sextvåetc: Hur ska man komma ihåg, och orka med, att uppdatera anropen till mallen Propertyspårning? Och vad menas med att en modul "använder" en property? Den kanske använder properties via importerade delar eller anropar andra moduler som använder en massa properties, ska de propertisarna då vara med i dokumentationen av huvudmodulen?
--Larske (diskussion) 3 augusti 2020 kl. 18.50 (CEST)
Svarar kort pga åska och taskig anslutning nu. Tanken är varje undermodul ska ha sina egna kategorier, men jag äröppen för förslag. Lägga "anges i" i varje modul/mall är knappast användbart. 62 osv (diskussion) 3 augusti 2020 kl. 19.04 (CEST)
Vad ser du för användningsfall för dessa kategorier?
--Larske (diskussion) 3 augusti 2020 kl. 19.36 (CEST)
När vi stötte på problemet med dolda koordinater i en postkod, insåg jag att det hade varit bra med en dylik.
På Wikidata används de i diskussioner om ändring och radering av properties. Jag är inte så övertygad om att vi har den nyttan 7dag. →62 osv (diskussion) 3 augusti 2020 kl. 19.58 (CEST) (ursäkta redigerar mobilt)
Mallen {{Använder Wikidata}} är bara inlaggd på ett tiotal malldokumentationssidor, och kanske inte alltid underhålls så att den är aktuell. Skulle ditt arbete med Propertyspårning kunna kopplas ihop med den, eller på något annat vis leda till att dokumentation skapas mer eller mindre automatiskt? Tomastvivlaren (diskussion) 3 augusti 2020 kl. 20.03 (CEST)
Jag skulle kunna lägga in de här kategoriseringarna i den här modulen också. Automatisera dokumentation, vet jag itne hur det skulle gå till. 62 osv (diskussion) 4 augusti 2020 kl. 07.50 (CEST)
Jag har nu integrerat kategoriseringen med {{Använder Wikidata}} nu. 62 osv (diskussion) 4 augusti 2020 kl. 08.20 (CEST)
Vad gäller nyttan, så upptäckte jag nu att P794 raderats. 62 osv (diskussion) 5 augusti 2020 kl. 13.55 (CEST)

Wikidata behörighetRedigera

Jag undrar vem som får ansluta en artikel till Wikidata? Måste man t.ex. vara administratör för att kunna göra det? Hur ansluter man en artikel till Wikidata?--I naturen (diskussion) 5 augusti 2020 kl. 20.50 (CEST)

VAd olika användagrupper kan göra på Wikidata kan du läsa här. Och nej, man behöver inte vara administratör. Hur man gör, det har jag glömt. Jo, ärligt talat, jag vet inte längre hur Wikidata ser ut om du kommer dit som nybörjare. För du kan ändra så många inställningar, att du glömmer bort hur det är att vara nybörjare. 62 osv (diskussion) 5 augusti 2020 kl. 21.56 (CEST)
Video hur man gör
Koppla Wikipediaartikel till Wikidata
- Salgo60 (diskussion) 5 augusti 2020 kl. 22.43 (CEST)
Aha okej. Tack för svaret! Wikipedia och säkert Wikidata också har så många olika funktioner att jag också upplever att jag glömmer vissa av dem ibland--I naturen (diskussion) 6 augusti 2020 kl. 11.17 (CEST)

WD-mallar som inte visar uppgifter utan källaRedigera

Finns det nånstans dokumenterat eller diskuterat att WD-mallar inte visar uppgifter från Wikidata där källa saknas? Gäller det för alla WD-mallar? /Axel Pettersson (WMSE) (diskussion) 6 augusti 2020 kl. 15.58 (CEST)

Det finns kod i Modul:Wikidata som tillåter sådan sortering, men den har nog kommit att användas sparsamt. Men deT ska vara implementerad för "officiellt namn" i Modul:Ortsfakta USA WD. Anledningen är att den propertyn är uselt fylld med data på WD med hjälp av import från Wikipedia.
Det finns fler sorteringkriterier. Tex om uppgiften har en artikel på svwiki eller inte. 62 osv (diskussion) 6 augusti 2020 kl. 16.13 (CEST)

gatuadress (P6375)Redigera

What3words
Geokodningssystem och företag  
IT-bolag, geografiskt koordinatsystem  
Skapad2013  
GrundareJack Waley-Cohen, Chris Sheldrick  
Huvud­kon­torLondon  
Webbplatswhat3words.com  
Licensproprietär programvara, Programvarupatent  

Det här är lite fortsättning på tråden "Sjabblat" ovan. Om jag förstod rätt så skulle adressen visas om den lades in på svenska. Jag gjorde så, alltså jag skapade ett svenskt "adressfält" under det engelska i what3words (Q20489028). Sen kopierade jag in den engelska adressen (vi översätter ju inte adresser, "65 Alfred Road" heter "65 Alfred Road" även på svenska och inte "Alfredvägen 65"). Det funkade inte ändå, alltså adressen visas inte i Databox.

Så har jag missförstått något?

Det andra är, om jag inte missförstått, och för att slippa kopiera adressen till svenska:

Är det möjligt att låta mallen eka ut adressen om den finns i Wikidata ovsett språk och är skriven med latinska bokstäver? Finns det någon gång som det blir fel (bortsett från om det finns flera olika adresser, alltså en Stockholm och en i Madrid och man valt svenska för den ena och spanska för den andra eller något, men då borde inte det styras av språket utan någon annan flagga; "filial", "HK", etc) Och finns det någon hypotetisk gång det blir fel ska kanske det hanteras som ett undantag i sådana fall?--LittleGun (diskussion) 6 augusti 2020 kl. 16.42 (CEST)

@LPfi: Vill minnas att jag skickat saker till Finland, där det förekommit både en svensk och en finsk version av gatuadress och även av postadress. Vero/Skatt tex. 62 osv (diskussion) 6 augusti 2020 kl. 17.02 (CEST)
@LittleGun: Ett mer generellt svar är att i princip allt är tillgängligt, bara man konstruerar mallen efter det. Om det finns adresser på flera språk, ska man kunna skapa en lista över vilka språk man föredrar framför andra, enligt en prioriteringslista, och sedan hämta just den man föredrar enligt dessa kriterier. Så, det handlar nog bara om att få rätt folk att göra programmeringen. 62 osv (diskussion) 6 augusti 2020 kl. 17.13 (CEST)
Ja, i Finlands tvåspråkiga kommuner har alla gator och vägar namn på båda språken (ibland à la Sommarövägen/Sommarönkatu, men ändå), vilket ju i allmänhet gäller både besöks- och postadress (och eventuell PB/PL). Postorten kan också ha parallella namn. Institutioner har ofta namn på båda språken, ibland också på engelska. (Och i samernas hembygdsområde och för relaterade institutioner är det ju samiska som är parallellspråket – ofta uppfattat som ett språk fastän vi har tre.) --LPfi (diskussion) 6 augusti 2020 kl. 17.27 (CEST)
Den här då: Varför syns inte adressen i databoxen för what3words till höger?--LittleGun (diskussion) 6 augusti 2020 kl. 18.16 (CEST)
@LittleGun: Läs mina inlägg i tråden #Sjabblat?, speciellt de från 20.38 och 21.33. Egenskapen gatuadress (P6375) har datatypen "Enspråkig text" ("monolingual text"). Sådana egenskaper visas aldrig av Databox om de inte explicit listas i den vitlista som finns. Ett försök till att vitlista gatuadress (P6375) gjordes av Kitayama, men backades då resultatet inte blev bra eftersom Databox idag inte har någon hantering av värden på olika språk i sådana egenskaper.
--Larske (diskussion) 6 augusti 2020 kl. 18.17 (CEST)
Efter att ha kontrollerat koden, så kommer jag fram till samma sak. Men det är inte som att modulen helt saknar förmåga att hantera multilingual text. Den ser redan ut att fixa kort namn (P1813). 62 osv (diskussion) 6 augusti 2020 kl. 18.51 (CEST)
Modulen använder kort namn (P1813) för de egenskaper som den presenterar för ett objekt, detta för att egenskapens etikett inte ska ta för mycket plats i vänsterkolumnen, men inte generellt för att visa egenskapen kort namn (P1813) för objektet självt.
Således skrivs Webbplats i stället för Officiell webbplats och Skapad i stället för Datum för grundande eller skapande i exemplet ovan med what3words (Q20489028).
(Det fungerar så länge ingen lägger in mer än ett värde för kort namn (P1813) på svenska.)
Men några kort namn (P1813) för huvudobjektet, alltså artikelsubjektet, tror jag inte att vi kan skrämma fram med dagens Databox. Testa Databox i någon artikel för ett politiskt parti, till exempel Fremskrittspartiet så ser du att det inte dyker upp något FrP där. Och anledningen är som sagt att datatypen för d:Property:P1813 är Enspråkig text.
--Larske (diskussion) 6 augusti 2020 kl. 21.59 (CEST)
OK, jag missade att de aldrig visades. Jag trodde de aldrig visades om de stod på ett annat språk.
Det borde gå att fixa. Jag menar att mallen ska behandla adresser så här (jag förutsätter att det är samma adress, men på olika språk):
1. Finns adress på svenska, använd den.
2. Finns adress på annat språk med latinska bokstäver använd den.
3. Finns adress på flera språk med latinska bokstäver men inte svenska, använd någon (helst officiellt språk).
4. Finns adress på svenska som inte är lämplig för wikipedia, overrida den manuellt på Wikipedia.
Det betyder att i undantagsfallen a) när samma adress anges på olika språk så går det att styra vilket språk som är bäst/rimligast på svenska och b) när det finns ett svenskt namn men det kanske inte är rätt för Wikipedia så går det att overrida. T ex a) Schweiz på Wikidata, som möjligen har fyra namn på icke-svenska, då kopieras lämpligt språk till svenska, tex tyska i vissa delar, franska i andra. Och b) Råkar det ändå inte vara bäst för Wikipedia med ett svenskt val bör den kunna overridas. Tex vill vi kanske ha finskt namn på på en finsk adress på Wikipedia, trots att det finns ett svenskt.
Funkar lösningen? Är den möjlig/rimlig att implementera?--LittleGun (diskussion) 7 augusti 2020 kl. 07.28 (CEST)
Det mesta som går att beskriva går också att göra, men notera en viktig skillnad mellan Databox, som i princip är en hel "Resonator-sida" som detta exempel, som klämts in i en smal högerkolumn på artikelsidan, och andra mallar som hämtar data från Wikidata:
  • Databox är en generell mall som är tänkt att kunna användas för alla egenskaper i alla objekt och varje undantag och specialregel gör mallen mer komplex och tyngre. Det blir med nödvändighet mycket målning med en bred pensel.
Databox exkluderar, på grund av brist på en generell hantering av dessa, inte bara de 50 egenskaper som har datatypen "Enspråkig text" utan också, med ett fåtal undantag, alla egenskaper som har datatypen "Extern identifikator" (5 261 egenskaper), "CommonsMedia" (63 egenskaper) eller "Url" (67 egenskaper).
Allt som inte explicit exkluderas kommer med i faktarutan på ett "one size fits all"-sätt.
  • Specialmallar för ett specifikt sortiment, till exempel naturreservat, tingsrätter eller norska kommuner, har en väldefinierad delmängd av egenskaper som behöver kunna hanteras och där de ofta generella egenskapsetiketterna i Wikidata kan ersättas med sortimentspecifika rubriker och radetiketter. För de sortiment/mallar där gatuadress (P6375) är relevant kan den egenskapen hanteras på ett sätt som är lämpligt för just detta sortiment.
Endast det som explicit inkluderas kommer med i faktarutan och på ett sortimentspecifikt sätt
Kan ditt förslag till "regelsamling" för gatuadress (P6375) tillämpas generellt för alla 50 egenskaper som är av typen "Enspråkig text", som till exempel smeknamn (P1449), motto (P1451), namn på modersmål (P1559), sista ord (P3909) och slogan (P6251)? För hela listan, se frågan i mitt ovan nämnda inlägg. Eller behövs det 50 olika regelsamlingar?
Hur vill du hantera fallet att det finns mer än en gatuadress (P6375) på svenska, se till exempel Yle Österbotten? Eller ingen på svenska men flera olika på något annat språk, se Alexandersgatan 4–10, Crimson Education och Werkbundsiedlung?
--Larske (diskussion) 7 augusti 2020 kl. 08.47 (CEST)
Det här exemplet illustrerar också ett annat problem med en generell mall. What3words beskrivs av Wikidata både som ett IT-bolag och som ett koordinatsystem. Har du en specifik anpassad mall för företag, kan du välja att sortera bort allt som inte är en underklass till bolag i P31 (instans av). Databoxen tillåter inte sådan bortsortering. 62 osv (diskussion) 7 augusti 2020 kl. 09.06 (CEST)
Larske. Då kanske Databox i allmänhet ska undivkas att användas? Särskilt om det är jag som ska ha koll på att den funkar i alla lägen... Eftersom vår värld inte är digital och kan färgläggas med bred pensel så blir det alltid undantag för varje tillämpning. Synd om den måste undvikas. En stor del av min förhoppning för Wikidata på Wikipedia var att det skulle vara en generell mall så man slappa alla specialmallar.
Jag tvivlar på att min regelsamling funkar på alla 50, men åtminstone för de 5 listade tycker jag att den funkar. Problemet är ju kureringen av innehållet när den läggs till (Jag tycker att den som adderar en box ska se till att den funkar då) och när Wikidata uppdateras efter att boxen finns (att det är bökigt att få reda på att innehållet i boxen ändrats i en artikel som man övervakar).
Finns fler än en adress för något, vilket jag tycker är konstigt, ja då finns de väl för att alla är relevanta. Så då får ju alla stå. Eller så är det fel att stoppa in fler än en adress i Wikidata. Så i exemplet Yle Österbotten, som jag antar är en är en regionalavdelning av finska tv-kanalen Yle, och att det är dess lokalavdelningar som är listade. Är det rätt sätt att beskriva adressen till Yle Österbotten, ja då är det rätt sätt och alla ska stå. Kanske till och med självklart eftersom ortsnamnen i adressen ger rätt lokalavdelning om det inte finns en central adress.
62 osv: Det var en poäng att använda databox, just för att Wikidata beskriver det både som företag och geokodningsystem. Även artikeln beskriver det så. Nu har jag fått reda på att objekte what3words är felaktig upplagd, och säkert kommer att splittas på två; ett objekt för företaget och ett för geokodningssystemet.
Att få ut en adress till Databox från Wikidata tycker jag borde vara självklart. Adressen är ju vital del för objekt som ar en adress.--LittleGun (diskussion) 7 augusti 2020 kl. 09.22 (CEST)
Ja precis, objektet är resultatet av en "merge" av två olika, men magert beskrivna objekt som råkade ha samma namn, som jag tycker att det är bra om man ifrågasätter. Det är ju lite som att slå ihop objektet Spotify (Q87067874) (som beskriver ett företag) med Spotify (Q689141) (som beskriver en tjänst)?
--Larske (diskussion) 7 augusti 2020 kl. 09.28 (CEST)
Ja, det är precis samma som att ha ett gemensamt objekt för företaget Spotify och tjänsten Spotify. Jag tycker det också skulle funka. Men, nu ser jag fram emot en WD-mall som kan hantera mer än ett objekt! Eller jag ser i varje fall ett behov. Fast jag förstår om vi avvaktar lite.--LittleGun (diskussion) 7 augusti 2020 kl. 09.43 (CEST)
För ett företag som bara har en produkt/tjänst kanske det fungerar med ett gemensamt objekt, men den dag företaget lanserar ytterligare en (notabel) produkt/tjänst får man lite problem. Då är det nog bättre att koppla ihop objekten med till exempel producerar (P1056) och utvecklare (P178).
--Larske (diskussion) 7 augusti 2020 kl. 10.13 (CEST)
Larske: Ja, det blir problem när det blir fel produkter. Oftast får de ett annat namn än företaget då, men det hjälper inte så mycket. Därför vore det fint med faktamall som kan hantera mer än ett objekt. Det kan ju vara vettgt att ha med kortfakta för ett par/några produkter i en faktamall på WP om ett företag, särskilt om produkterna inte har en egen artikel, men annars med.--LittleGun (diskussion) 7 augusti 2020 kl. 10.43 (CEST)
@LittleGun: Aha, nu fattar jag vad du menade med "hantera mer än ett objekt". I mallen Ortsfakta WD finns det funktioner för att hantera objekt som är instans av (P31) grupp av bebodda platser (Q25964111) och som är kopplade till fler, oftast två, andra objekt via egenskapen bestående av (P527). Se till exempel Träslövsläge. I andra fall är det löst genom att ha mer än en faktamall i en och samma artikel.
För att göra en generell mall som kan hantera flera objekt behöver man veta hur dessa objekt inbördes är relaterade. Är det via egenskapen bestående av (P527), som i exemplet ovan, eller på något annat sätt?
--Larske (diskussion) 7 augusti 2020 kl. 11.53 (CEST)
Det vet jag inte, men jag anar ett behov av att bygga såna faktamallar. Wikipedia kan ju välja att bara ha en artikel om ett företag och där beskriva produktfamiljen. Då kan det vara fiffigt att ha en faktamall som beskriver både företaget och ett par produkter också. Till exempel. Visste inte att såna lösningar var implementerade redan.--LittleGun (diskussion) 7 augusti 2020 kl. 11.59 (CEST)
I väntan på en sådan supermall kan man ju alltid fuska, så här.
--Larske (diskussion) 7 augusti 2020 kl. 12.06 (CEST)
Gällande konstigheter som har flera adresser, som till exempel Werkbundsiedlung, är inte det snarare felaktigt i Wikidata? Det lär väl finnas en huvudadress (huvudreception, huvudgrind etc.) De flesta platser har ju mer än en ingång, men bara en adress. Men är det så att alla adresser är lika relevanta då ska de stå med. Är det löjligt många och lika relevanta, ja då får man ta bort de helt enligt punkt 4.--LittleGun (diskussion) 7 augusti 2020 kl. 09.54 (CEST)
I många fall har man qualifiers som beskriver vad varje med värde har för syfte. Det borde man ha för adress också, tycker jag.
Har man sedan lite insikt i vilka värden som brukar vara qualifiers, så ska man sedan kunna sortera bland dem. 62 osv (diskussion) 7 augusti 2020 kl. 10.03 (CEST)
Bättre att ha ett nytt "fält" (property?), så det blir ett med huvudingång(ar) och ett med sidoingång(ar), det är ju så sånt som har adresser brukar se ut där huvudadressen är mest relevant i de flesta sammanhang. (Sen kan man såklart ha ytterligare qualifiers om det är till hjälp, också). För Yle verkar fortfarande gälla tre huvudingångar för Yle Österbotten. Men de andra exemplen tvivlar jag på att det är rätt i Wikidata, det borde finnas en huvudingång. I fallet Alexanderstrasse 4-10 verkar det vara avgränsningsadresser, eller så är det sidoingångar där med. Men som sagt, det kanske finns undantag med 75 huvudingångar. Då blir ingen relevant i en faktamall, men det tycker jag inte ska göra så att en så central uppgift som adress inte ska visas.--LittleGun (diskussion) 7 augusti 2020 kl. 10.38 (CEST)
För bostadsområden som Werkbundsiedlung (Wien) finns sällan någon huvudaddress. Varje hus har sina egna addresser. Men i det här fallet finns addresserna också i objekten för de enskilda husen. Så de borde inte behövas i bostadsområdet objekt, de kan kommas åt genom egenskapen bestående av (P527). F.d. 82.212.68.183 (diskussion) 7 augusti 2020 kl. 11.08 (CEST)
Nej, det verkar överbestämt att ha adresserna på två ställen. Jag fattade inte att det var ett bostadsområde, då är det ju som att lista alla adressena i en stad. men det finns säkert andra relevanta undantag. Men de får vi hantera manuellt om det är mer än ett par/några huvudadresser. Men visst kan bostadsområden ha en huvudadress, gated communities till exempel.--LittleGun (diskussion) 7 augusti 2020 kl. 11.22 (CEST)
Javisst, en egenskap (=property=fält=...) för "huvudinång" skulle kunna skapas, men det är alltid en avvägning av hur specifika egenskaper som det är vettigt att ha. Idag har Wikidata, såvitt jag kan se, inte ens ett objekt för "huvudingång". Om ett sådant objekt funnes skulle det kunna användas som värde på bestämningsordet berörd del (P518) till egenskapen gatuadress (P6375) och en mall kunde, när det finns flera olika värden, välja det värde som hade den bestämningen.
Men alla objekt som har en gatuadress (P6375) behöver inte ha någon "ingång", se till exempel den här kajmuren i Antwerpen som tydligen delas av 11 olika kajer som var och en, rätt eller fel, erbjuder sitt värde till egenskapen gatuadress (P6375). Och i en "all inclusive"-mall måste sånt man inte vill se, till exempel gatuadress (P6375) för något som är instans av (P31) kaj (Q828909) explicit väljas bort.
Wikidata erbjuder möjligheter att förse egenskaper med olika begränsningar, som till exempel att
  • single value, det bara får finnas ett värde på egenskapen för ett visst objekt (skulle passa för huvudingång)
  • unique value, ett värde på en egenskap måste vara unikt, det vill säga inget annat objekt får ha samma värde på egenskapen
  • med flera...
Dessa begränsningar är "mjuka", det vill säga man kan fortfarande bryta mot dem, men det finns stöd för att bli uppmärksammad på när man bryter mot dem, något som mindre nogräknade robotar högaktningsfullt sk-ter i.
För egenskapen gatuadress (P6375) finns det idag ingen begränsning till "single value" och inte heller något sådant förslag, se diskussionssidan för P6375.
Wikidata är lite fyrkantigt, eller åttkantigt, och det är både på gott och ont. Om man filar av alla "hörn" som finns i en struktur, finns det snart ingen struktur kvar.
För den intresserade finns mer information om egenskapsbegränsningar här.
--Larske (diskussion) 7 augusti 2020 kl. 11.27 (CEST)
Inte huvudingång då. Huvudadress. Och visst är det så, att vi ideligen hamnar i läget anpassa organiska former till kvadrater. Men just huvudadress och sidoadress är väldigt basala egenskaper för sånt som har adresser. Snarast konstigt att inte det skapats.--LittleGun (diskussion) 7 augusti 2020 kl. 11.54 (CEST)
För ett företag eller organisation förväntar jag nog att att hitta huvudkontorets besöksadress som preferred adress för exempevis Skatteverket. Det är inte självklart samma adress som dit jag skickar mina arbetsgivardeklarationer (Ja, jag skickar dem med brev av särskilda skäl.) och dit jag också går (gick, den funktionen har flyttat) för att hämta ut olika dokument.
Att sedan exempelvis finska skatteverket har (minst) två adresser, är lite av ett specialfall, då det där i princip rör sig om översättningar. 62 osv (diskussion) 7 augusti 2020 kl. 12.23 (CEST)
Finska skatteverkets adresser är väl inte "i princip" översättningar? Det är väl samma adress, men med två namn. Ett finskt namn och ett svenskt namn. Då blir det väl lätt för oss, vi tar besöksadressen på svenska enligt fall 1, ovan. Jag gissar att samma sak är vanlig i Schweiz men då finns inget svenskt namn, det är fall 3, ovan.--LittleGun (diskussion) 7 augusti 2020 kl. 13.55 (CEST)
Vad gäller länder som Schweiz, tror jag att vi i många år hanterat dem fel. Hela Schweiz är inte fyrspråkigt. När jag för ganska många år sedan städade bland schweiziska kommuner, hade alla kommuner tre eller fyra namn. Men så vitt jag tolkat det så är kantonen Genève enkelt franskspråkigt. Det finns egentligen inte mycket till anledning att ange tyska och italienska namn på platser i Geneve. Och idag ser det ut som kommunartiklarna städats igen och det bara finns franska kommunnamn i Genève-artiklarna. Artikeln om kantonen Genève har dock fortfarande fyra namn i toppen av mallen. 62 osv (diskussion) 7 augusti 2020 kl. 15.19 (CEST)
Ja, då är det inget problem per mina punkter. Antingen finns bara franska namn på adresser i Geneve och då används dessa (enligt punkt 2 ovan) annars punkt 3 ovan (genom att skriva fransk namnet på adressen som svensk).--LittleGun (diskussion) 7 augusti 2020 kl. 15.27 (CEST)
De tendenser jag sett på Wikidata är att man lägger in "officiellt namn" på språk som inte alls har med området att göra. Samma risk finns med gatuadress. Det har gjort att jag nu i Belgien, hårdkodat in i mallen att franska namn bara anges i Bryssel och Vallonien, undantaget nio kommuner som är tyska. Flandern och Bryssel har sedan nederländska namn. 62 osv (diskussion) 7 augusti 2020 kl. 16.01 (CEST)
OK. Det verkar inte kört om det bara är tendenser. Sen spelar det mindre roll för Databox, om svenskspråkiga communityn skriver under svenska adressnamnet så blir den som ekas ut, per punkt 1 ovan.--LittleGun (diskussion) 7 augusti 2020 kl. 17.42 (CEST)

Curt AngurRedigera

Efter denna sammanslagning verkar det finnas kvar 2 WD-objekt - ett kopplat till omdirigeringen från Curt Angur (friidrottare) och ett till Curt Angur. Är ovan vid WD och påtalar ist f att försöka fixa till det. / Allt gott önskar Anhn (diskussion) 7 augusti 2020 kl. 14.49 (CEST)

Mycket förvirrande. Är det en och samma person eller är det två olika personer som bara råkar vara födda på samma dag och ha samma namn? En och samma användare har för snart fyra år sedan lagt in två motstridiga uppgifter i objektet Curt Angur (Q5557228) angående dess relation till objektet Curt Angur (Q5557231) , se denna diff. Detta har legat kvar till nyss då Sextvåetc tog bort det.
--Larske (diskussion) 7 augusti 2020 kl. 14.57 (CEST)
Förutsatte att uppgiften från Anhn var rätta och plockade bort uppgifter som kunde omöjliggöra en sammanslagning. De är nu sammanslagna och ni får återställa mig om jag tog fel. Jura1 som lade till uppgiften, misstänker jag litade på att vi här hade koll, iom att vi hade två olika artiklar. 62 osv (diskussion) 7 augusti 2020 kl. 15.02 (CEST)
Snubblade över detta som hastigast, men jag menar att det är uppenbart att det är samma person som var framgångsrik idrottare i sin ungdom, och sedan på äldre dar blev politiker. / Anhn (diskussion) 7 augusti 2020 kl. 15.20 (CEST)

Wikisource som källa i Wikidata för faktaRedigera

David Runer artikeln har Mall:artikelursprung som pekar på en artikel i Wikisource som man kan nå genom att klicka på länken. Denna artikel är WD David Runer (Svenska industriens män) (Q19525488)

Jag testade några tafliga varianter men det blir inte klickbart och helst vill jag undvika en generell egenskap som referens-url (P854) eftersom WIkisource är inom "wiki familjen" och artikeln har ett eget WD objekt - Salgo60 (diskussion) 10 augusti 2020 kl. 12.44 (CEST)

d:Help:Sources har några tankar om saken.
Grejen är att undersidor på Wikisource inte alltid anses vara relevanta för Wikidata, så det är inte säkert att det går att få en wikilänk till exakt den sida du vill åt. Då blir du hänvisad till att använda referens-url i alla fall. Skapa en länk till sidan, när den finns på sv.Wikisource är förstås en möjlighet vi kan titta på. Det kräver nog lite tankearbete att få till. 62 osv (diskussion) 10 augusti 2020 kl. 15.21 (CEST)
Boken finns på Google Böcker det är kanske bättre att länka dit. Thoasp (diskussion) 10 augusti 2020 kl. 17.48 (CEST)
Absolut inte. Antalet visningar är begränsat, så om det uppstår polemik kring någon uppgift upphör sidan att vara tillgänglig på Google Books (så verkar det åtminstone, de flesta sådana källänkar jag försökt följa har varit dysfunktionella). Jag antar också att Google förbehåller sig rätten att registrera vilka böcker jag tittar på och kombinera det datat med andra uppgifter om mig. –LPfi (diskussion) 10 augusti 2020 kl. 18.21 (CEST)