Valmyndighetens valinfo 2018 skall vi ha det i WIkidata om ja isåfall hur[redigera | redigera wikitext]
I Wikidata har vi idag en koppling till riksdagensdatabas över ledamöter Wikidata egenskap Riksdagens person-id (P1214)
Jag gjorde en aktivitet att stämma av dom personer vi har i Wikidata med de som Valmyndigheten sagt blivit valda i Riksdagsvalet 2018
. Nu skulle vi kunna lägga till lite extra information från valmyndigheten i Wikidata. Synpunkter?
Varför: Jag pratade med en datajournalist på SVT och han hade använt riksdagens öppna data och såg gärna att kopplingen Riksdagsledamot <–> Valmyndigheten fanns dvs. Riksdagens person-id (P1214) till Kandidatnummer – unikt nummer på kandidaten vid detta valtillfälle
Min tro är att skall vi få fart på Wikidata i Sverige måste vi hitta andra aktörer än bibliotek och museer för där finns väldigt lite incitament att leverera plus omställningen till ny teknik känns halvt omöjlig... jag gjorde 2018 en test med en kommersiell aktör, en ej kommersiell organisation och en myndighet (Riksarkivet) och det tog bara timmar för de 2 första att vara konkreta och leverera medans Riksarkivet gav tomma löften men inget hände....
Jag tror att data som ovan kan öppna ögonen för nya målgrupper att Wikidata/Wikipedia kan göra skillnad... och det händer lite mera... jag träffade i veckan i Stockholm han som kör FactGrid projektet om frimurarorden och Sverigekistan som han gör med Wikibase ( dvs, egen variant av Wikidata). Han har byggt upp en #Wikibase och förra veckan fick han spontant hjälp av en av hjärnorna bakom Cambridge Analytica skandalen Paul-Olivier Dehaye att
visualisera brev som skicka mha datat i Wikibase och komponenten Kepler.gl... min tro är att hittar vi rätt personer så blir det mer fart... bra politisk data kan vara det där Wikidata är perfekt att koppla ihop två icke kopplade domäner som Riksdagen och Valmyndigheten
Jag tror inte att inventarienummer (P217) ska användas på det sättet, det är till för något helt annat. Sen är jag tveksam till att alla val automatiskt är en betydande händelse i alla personers liv. Om de inte stod på valbar plats och inte kom in ska det nog hoppas över. ♥Ainalidiskussionbidrag21 oktober 2019 kl. 00.30 (CEST)[svara]
Tackar för feedback
jag har idag bara kopplat dom 349 personer som kommit in i riksdagen...
håller med att inventarienummer (P217) inte är optimalt men känns som det funkar "identifier for a physical object or a set of physical objects in a collection" ;–) det finns ju inget som hindrar att om bättre kandidater dyker upp att man flyttar kandidatvärdet till den egenskapen... när det föreslogs var det begränsat till bara museer
har möte med riksdagsförvaltningen nästa vecka vore lite kul att visa denna möjlighet se T235527
Nu blir det till och med en varning på inventarienumret. Att kalla en kandidatur för ett fysiskt objekt är konstigt. Lägg inte till nya betydelser av egenskaper på objekt som test utan att först föreslå det på diskussionssidan för egenskapen (och få konsensus för det), du smutsar ner datat och kan ge andra konstiga resultat i deras queries. ♥Ainalidiskussionbidrag21 oktober 2019 kl. 09.14 (CEST)[svara]
Wikidatas modell tenderar att bli lite "fragmenterad". Folk kan bara byta parti en gång, och då bara till partilös. Men de kan ändå byta partigrupp, och det är en egen property vi sällan använder för svenska förhållanden. Sedan kan tjänstledighet ge flera claims för en enda mandatperiod. Det här är inte lätt för en mall att tolka vettigt, även om modellen är vattentät. IP 62.20.170.74 (diskussion) 21 oktober 2019 kl. 09.58 (CEST)[svara]
Jag tänkte snarare på mandatperioderna. Det krävs två claims för de fall där folk hoppar av ett parti. Ett där de "representerar:SD" och ett där de "representerar:Partilös". Sedan ytterligare ett när de börjar samarbeta med ett nytt parti. Där de fortfarande "representerar:Partilös" men "partigrupp:SVP". Hur får man en mall att fatta att det rör sig om en och samma mandatperiod? Samma problem återkommer när någon är tjänstledig. IP 62.20.170.74 (diskussion) 21 oktober 2019 kl. 17.46 (CEST)[svara]
Nu tappade jag dig.... Jag har inte kollat runt vad andra gör men det finns > 2000 val personer i WIkidata är kopplade till lista det kan ju vara steg 1 att se vad andra gjort och fundera vad man själv vill.
Patrick Reslow (Q6068516) har ju varit "bångstyrig" och bytt parti förra perioden men sitter kvar i riksdagen.
Re Datum det intressanta är väl att datumen föds från två olika håll.
Valmyndigheten definierar det 2018 som "Tillträdesdatum – Om ledamoten utsågs direkt vid valet så anges valdagen som tillträdesdatum. Annars anges det datum då länsstyrelsen utsåg ledamoten vid efterträdarval."
Jag förstod det men eftersom jag inte vet kvaliten på datat kan jag bara säga att de du säger låter logiskt men jag är inte 100 på att det är samma datum - Salgo60 (diskussion) 22 oktober 2019 kl. 00.40 (CEST)[svara]
Andra länder har ofta befattningar av typen "ledamot av Långtbortistans 123:e kongress". Det gör det lättare att "hålla ihop" mandatperioderna. Vi brukar inte numrera våra, men det borde funka att ange "ledamot av Riksdagen 2014-2018" istället. IP 62.20.170.74 (diskussion) 22 oktober 2019 kl. 09.25 (CEST)[svara]
CEST)
vi har lite diskussioner på en ny Telegram grupp ”Wikidata Sverige”. Min magkänsla att Riksdagensdata är icke komplett och det krävs lite analys vad man kan få ut av den. Jag har ett möte med deras IT gubbar 29 oktober T235527 bra vore att ha en tanke tills dess hur det skall se ut i Wikidata. Finns intresse att hänga på hör av er 0705937579 – 79.136.51.5323 oktober 2019 kl. 00.06 (CEST)[svara]
Gillar ni koppla ihop saker och se lite länkningar så finns det lite kul aktiviteter hos Uppsala Universitet. Jag var där igår och tyvärr visste dom inte vad Wikidata var... däremot ser jag hur perfekt Wikidata passar in med allt data om socknar/församlingar/kyrkböcker/Bygdeband/SOFI
Ordet neologi och motsvarande har på många språk med neologismer att göra. På andra språk är det en teologisk inriktning, som brukar betraktas som en variant av deism. På många språk finns förmodligen båda betydelserna men vi har att ta ställning till de artiklar som f.a. finns. Det är oreda i iw-länkarna. Jag har gjort en inledande fundering på Diskussion:Neologi.
Jag har lärt mig någon gång hur wikidata funkar men hinner glömma mellan varje gång. Det vore väldigt fint om någon annan kände för att sortera olika sorters neologier i högar. --Hjordmån (diskussion) 27 oktober 2019 kl. 09.01 (CET)[svara]
Jag tror inte det tekniskt sett är fel, men i andra objekt som anges vara "Constituent college" finns påståenden som "moderorganisation:Londons universitet", se School of Oriental and African Studies (Q220144) för exempel. Faran med "del av" är att det är en lite väl generell property. "M6 mutter är del av Volvo BM" "Volvo BM är del av Volvo AB" "Volvo AB är del av:Stockholmsbörsen" därav följer att: "Stockholmsbörsen består av M6-muttrar". Lite överdrivet kanske, men det finns nackdelar med generella properties. Och det kan vara ett bra tips att kolla hur andra gjort. Ofta har de gjort väldigt olika. 62 osv (diskussion) 7 november 2019 kl. 20.35 (CET)[svara]
Den svenskspråkiga artikeln om maträtten timbal är kopplad till Timbau på andra språk ([1]) - jag tycker timbau känns lite väl hårdsmält och inte alls den mjuka mat som beskrivs på sv-wp. ;-) Tyvärr kan jag ännu inte länka om sånt som är fel ihopkopplat på wikidata och undrar nu om nån kan hjälpa? // Zquid (diskussion) 13 november 2019 kl. 15.59 (CET)[svara]
Nu har jag klantat mig på wikidata, och vet inte hur jag ska trassla mig ur det. Det rör sig om Q8079574. Jag avsåg att koppla ihop isländska Þórsnes med svenska Þórsnes och trodde, eftersom de hade olika Q-nummer, att det var Lsj-bot som hade skapat en dubblett. I efterhand har jag förstått att det var den isländska artikeln som var felkopplad. Så nu har jag lyckats att göra allt till grensidor på wikidata. Kan någon hjälpa mig att reda ut den här röran? Þórsnes på svenska, isländska och cebuano ska alltså ha samma Q-nummer. Men engelska Þórsnes hör inte hit; den är en grensida och ska kopplas till sv., ceb. och no. Torsnes. Jag ber om ursäkt för den här röran. Dagsuddare (diskussion) 19 november 2019 kl. 10.26 (CET)[svara]
Jag fixar inte att reda ut päls (Q197204) och päls (Q197195). Artiklarna kopplade till respektive objekt verkar förväxlade. Behåring och biologi kopplas till den förra, se bilden med hårväxt hos människans båda kön exempelvis. Artiklarna kopplade till den senare handlar om modeprodukten och handelsvaran. Är det bara den svenska etiketten som ska skiftas mellan de två? Det blir svårt när man inte behärskar alla berörda språk.--Caztorp (diskussion) 29 november 2019 kl. 17.28 (CET)[svara]
Här är en översikt vilka artiklar för ett urval språk som är kopplade till respektive objekt från Wikidatas perspektiv.
Sen kan det förekomma "interwikiextra-länkar" som är enkelriktade från en wiki till en annan wiki och det kan ibland förvirra lite. Är det någon sådan du stött på?
Vad är de för artiklar om "behåring och biologi" som du refererar till?
sh:Krzno kopplad till pälsverk är väl däggdjursrelaterat och passar bättre ihop med päls exempelvis. Sen ser jag att da:Pels handlar om båda så det är nog svårutrett. Men beskrivningen "soft, thick, hairy coat of a mammal" hör bättre ihop med päls (Q197195) än päls (Q197204), och tvärtom för "clothing made of furry animal hides".--Caztorp (diskussion) 29 november 2019 kl. 18.37 (CET)[svara]
Är det så att svwp egentligen saknar en egen artikel om "pälsen när den sitter kvar på djuret"?
Artikeln Pälsverk handlar ju om ett material "från djur" som kan användas för att göra kläder.
Jag tror att det är Päls (kroppsbehåring) som bör kopplas till d:Q197204. Det går att göra om man tillfälligt tar bort omdirigeringen medan man gör kopplingen till Wikidataobjektet.
Jag gjorde så. Nu hänger Pälsverk i luften, men det kanske finns något objekt att koppla den artikeln till.
En bot har på Wikidata med undermålig källa förminskat den framstående väg- och vattenbyggnadsingenjören Pehr Laurell till "skribent", vilket på grund av WD-mallen även visas i artikeln. Hur skall denna typ av problem hanteras? /Annika (diskussion) 1 december 2019 kl. 11.47 (CET)[svara]
Laurell skrev ett antal tekniska redogörelser över järnvägsbyggnader, sjösänkningar etc. Jag uppfattar detta som ett normalt inslag i hans verksamhet som väg- och vattenbyggnadsingenjör, så kan kan inte se någon anledning till varför man även skall kalla honom skribent. /Annika (diskussion) 1 december 2019 kl. 12.29 (CET)[svara]
När jag jobbat med att P31-a Lsjbot-artiklar upplever jag det som att det är lite si och så med överenstämmelsen mellan vad vi anser orden betyder och hur de används, såväl av Goenames och av de som namngett platserna i fråga. 62 osv (diskussion) 2 december 2019 kl. 10.13 (CET)[svara]
Tabellen ovan kan kompletteras med golf (Q1322134) (som inte har någon svwp-artikel).
Det har uppstått en del märkliga objekt när en, uppenbarligen ogranskad, sammanslagning skett mellan objekt som varit kopplade till Lsjbot-skapade artiklar på cebwp (och svwp) med andra objekt som avser samma plats med som klassificerats annorlunda.
Namnändelser på öar fördelade efter öarnas storlek.
Nu när skillnaden mellan vikar och bukter är utredd tar jag upp nästa boll. Idag är alla vattenomflutna landområden som Lsjbot har skapat artiklar om klassade som öar (d:Q23442), men jag tycker att det känns fel att småpluttar som Mor Annas grundet klassas som "ö". Man kan hävda att så små öar borde raderas som irrelevanta, men jag tycker nog att exempelvis Notgrund, Åbo är relevant. Så jag skulle gärna klassa mindre öar som holmar (d:Q207524), skär (d:Q216851) eller kobbar (d:Q10546851), men gränsdragningen är svår. Namnet ger förstås en god vägledning, men alla namn slutar inte på -ön, -skäret eller -holmen. Storleken är en bättre vägledning, men det finns öar som är väldigt små (Krokön, 0,65 ha) och skär som är väldigt stora (Bredskäret, Korsnäs, 10 km²). Fördelningen namnefterled efter storlek visar dock att öar typiskt är 0,5 km² eller större. Mindre än 0,1 km² dominerar holmar och skär och mindre än 0,01 km² är kobbar, bådor och grund vanligast. Dessutom verkar skär bara förekomma i skärgrådsmiljö, i insjöar finns bara holmar. Så, är det någon idé att kategorisera mindre öar som något annat än just ö? /ℇsquilo9 december 2019 kl. 10.42 (CET)[svara]
Ursäkta en kronisk landbo, men är inte avsaknad eller låg förekomst av växtlighet (istället för storlek) ett kännetecken på "skär". Det kanske inte stämmer idag, men åtminstone när den namngavs? 62 osv (diskussion) 9 december 2019 kl. 10.52 (CET)[svara]
Jo, så är det nog. Det är nog därför väldigt små öar i insjöar som inte utsätts för vind, vågor och varierande vattenstånd kan utveckla vegetation och därmed bli holmar i stället. /ℇsquilo9 december 2019 kl. 11.25 (CET)[svara]
Kobbe, kobb, klobb och kläpp är variationer på samma ord och vad jag har förstått så är haror, häror och bådor ungefär samma sak som kobbe också. Mitt intryck är att kobbar är vanligare i Sverige medan klobbar och bådor är vanligare i Finland. /ℇsquilo9 december 2019 kl. 17.36 (CET)[svara]
Efter vad jag förstått så finns det i internationell rätt en skillnad mellan olika "typer" av öar. Beroende på storlek och utseende kan de påverka ett lands territorialvattengräns i olika utsträckning. Som jag förstått det tillhör tex Haslewood Rock den mindre obetydligare kategorin. Exakt var gränsen går, vet jag inte exakt. Vad jag minns av Youtube-filmer jag sett är att de ska vara stora (och platta) nog för att rymma ett bostadshus. Så istället för att fylla Wikidata med klassifikationer som kanske bara är tillämpliga i svenskspråkiga sammanhang, kanske en mer internationell klassifikation är användbarare ur Wikidata-perspektiv. Och självklart ett stort [källa behövs] på allt det jag skrivit i detta inlägg. 62 osv (diskussion) 9 december 2019 kl. 17.52 (CET)[svara]
I det fallet är det öns placering, inte storlek, som är avgörande. Förenta nationernas havsrättskonvention artikel 6 säger: "The drawing of straight baselines must not depart to any appreciable extent from the general direction of the coast, and the sea areas lying within the lines must be sufficiently closely linked to the land domain to be subject to the regime of internal waters." För länder med skärgård längst kusten tillämpas principen med "rak baslinje" mellan punkter "which are permanently above sea level". /ℇsquilo9 december 2019 kl. 20.44 (CET)[svara]
Artikeln behöver en "nulledit" eller på annat sätt rensa cachen för att länken till Wikidata ska dyka upp om man inte vill vänta på att detta sker i bakgrunden. Nu finns den där. --Larske (diskussion) 14 december 2019 kl. 13.20 (CET)[svara]
Sedan i går uppdateras inte Wikidata när jag tar bort artiklar eller flyttar artiklar på svwp. Ytterst irriterande. 10.22 raderade jag sidan som hörde till [2]. Inget händer. Samma sak vid flyttar. Samtidigt verkar det fungera för andra användare? --北山 Kitayama (diskussion) 14 december 2019 kl. 10.48 (CET)[svara]
Jag har mycket av detta. Ibland går det "omedelbart", ibland efter någon minut och ibland längre och jag behöver gå in manuellt. Detta har gällt en längre tid inte bara just nu.Yger (diskussion) 14 december 2019 kl. 11.25 (CET)[svara]
^ [ab] In Memoriam Otakar Sadovsky, Kakteen und andere Sukkulenten (på tyska), 6-1990, s. 115.[källa från Wikidata]
^ [ab] Evidence zájmových osob StB, läs online.[källa från Wikidata]
^Tjeckiska nationalbibliotekets databas, läst: 23 november 2019.[källa från Wikidata]
I fallet Otakar Sadovsky tror jag det skulle räcka om du bytte plats på "Tjeckoslovakien" och "Österrike-Ungern" på WD. Eftersom Tjeckoslovaken är skrivet före Ö-U, så är det nog vad Mall:Wikidatadatumgräns letar efter. Och då det inte finns där, så väljer den att ange 1918 som den tidpunkt då kalender byttes i landet ifråga. 62 osv (diskussion) 18 december 2019 kl. 18.49 (CET)[svara]
Går det att hitta Wikidata-objekt där den svenskspråkiga beskrivningen är skiftlägesokänsligt lika med den svenskspråkiga etiketten (eller kopplad svwiki-artikel)? Nirmos (diskussion) 21 december 2019 kl. 13.31 (CET)[svara]
Ja, det går att hitta något sådant objekt, SPARQL-frågan nedan, men om du menar om det går att hitta alla sådana objekt så tror jag att det är svårt att göra med SPARQL (Wikidata Query Service). Antalet objekt i Wikidata är nu större än 71 miljoner, av vilka mer än hälften representerar mer än hälften objekt som är instans av (P31)vetenskaplig artikel (Q13442814), så det är lite mycket att söka igenom på de 60 sekunder som står till förfogande.
Länk till fråga som hittar ett objekt som är länkat till svwp och som har en svensk etikett som är samma (skiftlägesokänsligt) som den svenska beskrivningen. Denna sökningen är alltså begränsad till objekt som har en artikel i svwp.
Om man begränsar sökningen till objekt som har någon speciell egenskap, till exempel land (P17) lika med Sverige (Q34) räcker tiden till för att hitta alla förekomster, se den här frågan som just nu hittade 11 objekt (på cirka 20 sekunder) trots att begränsningen till objekt som har svwp-artikel är borttagen.
Lägga till data-attribut i Mall:Citation/core som exponerar den information som finns tillgänglig och är intressant (författare, titel etc) på ett strukturerat sätt i sidans HTML-kod
Lägga till span-taggar med en klass i Mall:ISBN så att mallen kan – ursäkta svengelskan – targetas på ett tillförlitligt sätt
Skriva ett JavaScript som
I artiklar
Itererar över alla cite-element
Kontrollerar att cite-elementet innehåller exakt en ISBN-mall
Om det gör det, kopierar data-attributen från cite-elementet till URL-parametrar på ISBN-länkens href-attribut
Wikimedia Sverige får massa pengar från LIBRIS. Kolla med Alicia om detta kan göras under detta paraply. Hon har lagt in alla Projekt Runebergsböcker i WD så om hon tror på iden... OT jag kommer att i veckan lägga in Litteraturbankens scannade böcker (se T238932) och kör då Quickstatements men som sagt det är inte det du ville ha - Salgo60 (diskussion) 25 december 2019 kl. 14.06 (CET)[svara]
Jag har två frågor rörande Wikidata som har förbryllat mig länge. 1. Har inte användare på engelska Wikipedia något som helst ansvar att länka "sina" artiklar till andra språkversioner? 2. Hur kommer det sig att så fort en artikel på engelska Wikipedia skapas så skapas det ett objekt på Wikidata automatiskt medan när man själv "hinner" före engelska Wikipedia så skapas det inte något objekt om artikeln. Är objektskapande botar på Wikidata idag exklusiva för engelska Wikipedia? Ett prima exempel är J.C. Beaudin som jag skapade den 24 oktober men ingen bot verkade veta om att artikeln ens existerade och inte skapade något objekt. Den 12 november skapades J.C. Beaudin på engelska Wikipedia och då blev det full fart och ett objekt skapades omgående. Men boten kopplade inte samman de två artiklarna med identiska namn och utan ens några särskiljningar. När ska ÖVRIGA Wikipedia börja kräva att de engelskspråkiga måste ta större ansvar för att koppla samman artiklar och objekt som de INTE gör idag. De artiklar jag skapar så är det jag som kopplar artiklarna med varandra till 99,9%, trots att det händer att jag "hinner" före engelska språkversionen. Detta börjar snart nå till en gräns där jag kommer helt enkelt skippa att skapa några interwikilänkar alls eftersom gör inte alla det så varför bry sig? DIEXEL (diskussion) 14 november 2019 kl. 15.15 (CET)[svara]
Den bot, Pi bot, som skapade WD-objektet i ditt exempel har bara de tre språkversionerna 'en', 'de' och 'fr' som sitt "upptagningsområde" och arbetar bara med artiklar om människor på dessa språkversionen om jag läser koden rätt. Boten är flitig och körs varje hel timme och kontrollerar då om det finns något Wikidataobjekt att koppla de nyskapade biografiartiklarna till. Den jämför namn och födelseår i artikeln med vad som finns i objektet och om det stämmer anses det vara "rätt objekt". Om den inte hittar något objekt skapar den ett nytt objekt och fyller i lite basfakta som den hittar i artikeln, främst via dess kategorisering. Jag förmodar att det betyder att om du hade skapat ett Wikidataobjekt den 24 oktober, stoppat in födelsedatum (P569) och kopplat det till den svenska artikeln så hade roboten hittat det när den letade efter objekt att koppla den nyskrivna enwp-artikeln till, vilket innebär att enwp-artikeln hade dykt som språklänk i svwp-artikeln utan att du eller någon annan hade behövt skapa någon iw-länk till enwp.
Det finns eller har funnits andra robotar som bara skapar Wikidataobjekt utan att fylla i några grunddata som instans av (P31), kön (P21) och liknande. Sådana "tomma objekt" är lite problematiska då de kan locka andra robotar eller kolbaserade användare som att felaktigt koppla ihop artiklar på olika språkversioner som bara har namnet gemensamt trots att de beskriver helt olika typer av företeelser som ska ha olika objekt i Wikidata. Det kan vara olika personer med samma namn eller naturreservat som har samma namn som ett berg eller liknande. Det förekommer också att Wikidataobjekt "matchas" med diverse externa kataloger. Ju mer data det finns i Wikidataobjektet desto mindre risk är det för felaktiga matchningar.
Tack mycket lärorikt det du skriver. Jag har bara haft en "känsla" det är bra fylla på en del data för att undvika data blir korrupt, men du ger ju en tekniks förklaring (och till det är de kolbaserade användaren som amatörmässigt tror sig se likheter)Yger (diskussion) 14 november 2019 kl. 17.45 (CET)[svara]
Tillägg/Förtydligande till mitt förra inlägg: Den som är först att skriva en artikel om en person behöver alltså inte vänta på att artiklar ska dyka upp på andra språk och då göra iw-kopplingar. Men den som är först med Wikipediaartikeln är också den som, med eller utan robothjälp, bör skapa Wikidataobjektet och koppla det till "sin" artikel. Sen är det upp till alla andra som, kanske långt senare, skapar artiklar på andra språkversioner att koppla "sina" artiklar till samma objekt, med eller utan robothjälp. Och för att underlätta för dem är det bra om objektet har så mycket data så att det inte är någon tvekan om vad det avser. Förutom en svensk beskrivning kan det därför underlätta om det också finns en beskrivning på engelska som många förstår.
Larske: Det förklarar fortfarande inte varför de användare på engelska Wikipedia är undantagna från att länka till andra språkversioner eftersom detta beteende har varit sen jag kom hit och började bidra 2007, vilket var innan Wikidata introducerades. Jag tycker det är rätt så anmärkningsvärt att inga har stått på sig och begärt att även de ska göra det, för att det är alltid "vi andra" som får göra det åt dem. DIEXEL (diskussion) 14 november 2019 kl. 18.26 (CET)[svara]
(Redigeringskonflikt)Alla robotar har sina hussar och mattar och dessa hussar och mattar har sina preferenser. Många robotägare har preferensen att de kan engelska och kan hantera det språket. Det finns mycket färre robotägare som hanterar svenska. Och de som gör det, prioriterar andra saker. På den gamla goda tiden före Wikidata fanns det bara en enda svensk robotägare som intresserade sig för interwiki och det var jag. Och min robot tog bara bort länkar. Den lade aldrig till några länkar.
Jag kan väl säga att robotar och användare som sysselsätter sig med att matcha namnen på artiklar och kopplar ihop dessa ganska ofta orsakar en hel del röra genom att koppla samman fel saker. Jag ser hellre att vi har tio artiklar med för lite interwiki än att vi har en med felaktig interwiki. 62 osv (diskussion) 14 november 2019 kl. 18.40 (CET)[svara]
Jag kan inte erbjuda en bot som skapar Wikidata-objekt. Det jag kan erbjuda är en finess som gör "något" när:
Användaren skapar en ny sida, och
sidan inte är kopplad till Wikidata, och
sidan är i en namnrymd där vi vill att sidor ska vara kopplade till Wikidata
visa en ruta i övre högra hörnet som påminner användaren om att koppla sidan till Wikidata. Det skulle vara en likadan ruta som när man sparar eller återställer en sida. Det här är obetydligt lite jobb. Eller:
Hej! Här nämns i slutet på diskussionstråden ett potentiellt problem med {{Ortsfakta WD}}. Vi är i alla fall två (jag och Yger) som tycker det är olämpligt att en WD-baserad faktamall kan lista artikeln i en åtgärdskategori, utan att det förklaras för skribenten vad det är som pågår. I den här åtgärdskategorin förklaras inte i kategorihuvudet att även {{Ortsfakta WD}} kan vara orsak till mallningen.
Vi har numera möjlighet att lägga till anmärkningsinfo i {{Illustrationsbehov}}, vilket hjälper oss att förstå vad som saknas. Kanske kan den här mallen införa något liknande? Alternativt kan man se till så kategoriseringen av artikeln skickas till en egen kategori, åtskild från normala illustrationsbehovskategorier och med ett självförklarande namn, så att man förstår att det är "den där faktamallen" som är orsaken till problemet.
På Bybrunnen menas det (@Larske:) att faktamallen är den naturliga platsen att lägga in den första bilden i en artikel. Det kan så vara, men alla vill inte eller har inte lärt sig lägga in bilder i Wikipedias artiklar via Wikidata. Om den här mallen ska läggas in i våra artiklar, är mitt förslag att användbara parametrar samtidigt läggs in. Då kan man låta folk välja hur och var bilden läggs in, baserat på skribentens egen kunskap om Wikipedia och Wikidata. Och det borde vara att bättre utnyttja folks vilja att hjälpa Wikipedias artiklar att bli bättre illustrerade. Mina två ören.--Paracel63 (diskussion) 30 december 2019 kl. 02.10 (CET)[svara]
Jag gillar inte åtgärdsmallen {{illustrationsbehov}} alls, den läggs in slarvigt på objekt där illustration är irrelevant och ofullständigt. Jag anser datorfnul är bättre om man vill hitta tex behov i geografiska närhet. Att då även skapa den automatiskt via mall och utan att någon skapare explicit tyckt det är en bra sak kan jag inte gilla. Teoretiskt kunde i dessa fall en alternativ kategori skapas, men datorfnul i Wikidata är ju än enklare. Och som ett litet sidospår har jag svårt se vitsen med denna mall om geografisk koordinat saknas, och i min insats runt kopplingen Wikidata-Wikipedia har jag också mer och mer fokus på vikten att koordinater skall finnas på objekt där detta är relevant. Jag skulle därför mer välkomna botinsatser etc runt saknade koordinater, inklusive, om bra, åtgärdsmallar för saknad koordinatinfo.Yger (diskussion) 30 december 2019 kl. 07.36 (CET)[svara]
NB! Det är bara i Sverige, som den här mallen ger den här kategoriseringen. Och så vitt jag vet så finns den här funktionen även hos motsvarande Sverige-mallar som inte har WD-stöd. 62 osv (diskussion) 30 december 2019 kl. 08.24 (CET)[svara]
@Sextvåetc: Här är en fråga som listar invånarnamn (P1549) på svenska med olika berörd del (P518). Det är en liten utmaning att presentera egenskapen invånarnamn som medborgarskap. Tidigare presenterades den som nationalitet har jag för mig.
Vi bör återgå till nationalitet. Ändringen av nationalitet till medborgarskap var oöverlagd och gjordes utan föregående diskussion. Medborgarskap är en historisk företeelse, nationalitet täcker även in tiden innan nationalstaternas tillkomst. /Ascilto (diskussion) 5 januari 2020 kl. 17.57 (CET)[svara]
Engelska artikeln en:Cringle har fel interwiki. Den beskriver specialfallet "revlöddra" av öljett. Revlöddra beskrivs i vår artikel revning. Men en:Cringe har interwiki med kaus. Engelska verkar inte ha en egen artikel om kaus (thimble på engelska), bara som ett omnämnade i vajer, och då som ett stålvajerbeslag,[3], men benämningen används och härstammar från kausar för vanliga rep.
Kort sagt: Jag tror att ett nytt objekt för revlöddra ska skapas, med enda interwiki en:Cringle, svensk label "revlöddra" och att objektet som har kaus ska den engelska tas bort ifrån, och få den engelska labeln "thimble". Se även diskussion på diskussion:kaus.
Jag noterade att thimble är fingerborg också, alternativnamn för kaus verkar vara rope thimble, och wire thimble då. Har inga källor men här är produktkatalog för kaus respektive thimble: [4], [5].
Har inga bra källor för påståendet "cringle=revlöddra" heller. Men detta i varje fall: [6]. Här gör de en löddra med hjälp av en "rundkaus" som jag lärt mig finns idag, och två öljetter. Jag är ganska säker på att hade de bara satt en öljett och struntat i rundkausen så hade det gått för revlöddra, och att engelska artikeln valt att illustrera med en sån modernare variant (som inte kunde göras tillräckligt starka föränn seglen blev syntetiska?).--LittleGun (diskussion) 5 januari 2020 kl. 15.07 (CET)[svara]
Jag har mekat lite med de två objekten kaus (Q8955276) och revlöddra (Q3928602) utgående från hur jag tolkar ovanstående inlägg, se tabell nedan. Komplettera gärna de två objekten med beskrivningar på svenska (och andra kända språk).
Objektet revlöddra (Q3928602) fanns redan, men med den italienska artikeln som enda länk. Den artikeln flyttade jag till kaus (Q8955276). Hoppas att det blev rätt.
Tack så mycket! Jag tycker det ser jättebra ut. Engelskspråkiga arttikeln "cringle" handlar helt klart om revlöddra, och illustreras av en öljett (möjligen med en på något konstigt sätt ditsatt rundkaus) med den funktionen. Avsnittet thimble i engelska artikeln en:wire rope beskriver helt klart en "kaus". Så enligt mig ska alla kausar plockas bort från commons-kategorin commons:Category:Cringles. Det är jättekonstigt att den sammanblandningen är så genomgående. Möjligen har jag missat något, men den enda förklaringen jag har är att det går att använda kaus, både rund och droppformad, för att skapa en revlöddra. Men, eftersom jag tycker det är så jättekonstigt trots att ingen annan reagerat tyder ju faktiskt på att jag missat något. Men jag fattar inte vad. Visst finns det likheter mellan "rundkaus" och öljett, den här bilden kan faktist alltså vara en rundkaus som använder (deWP påstår ringkaus), men det borde väl vara en öljett,[7]? Normalt när kausar används som revlöddra brukar de splitsas in i seglets lik:[8]. Det är själva poängen med en kaus, att sko en splitsad repögla.--LittleGun (diskussion) 5 januari 2020 kl. 18.14 (CET)[svara]
Att sammanblandningen förts över mellan olika projekt är inte så konstigt. Både på Commons och Wikidata finns många användare som arbetar med språk som de inte har som modersmål och därför ibland gör misstag. På Wikidata finns robotar som sprider sådana misstag från olika projekt och mellan olika objekt.
Commonskategorier ska ha engelska namn, så en tyskspråkig användare kanske kollade språklänkarna för att se vad tyska "Kausch" heter på engelska och hittade det felaktiga namnet "cringle".
Wikidataobjektet (Q8955276) skapades med (antar jag) riktig etikett och beskrivning på ryska. Den ryskspråkiga användaren gjorde nog en koll av språklänkarna eftersom den engelska fick ligga kvar i ett annat objekt (Q1979635).
Av någon anledning (kanske språklänkarna i Commonskategorin) flyttade en annan användare den felaktiga engelska länken till fel objekt.[9][10]
Baserat på den felaktiga ändringen slogs objekten ihop av en robot [11].
Jag har försökt ändra på commons och wiktionary, och motsvarande ändringar på wikidata. Jag hoppas det räcker för "Kaus" åtminstone. Cringle/revlöddra är också lite sammanblandad med öljett. Jag vet inte om tex "zeilring" är öljett i allmän bemärkning eller revlöddra eller om det holländska ordet för öljett tagits från revlöddra. Det är väldigt rörigt, bland annat för att revlöddra egentligen är en funktion, att på nåt sätt kunna fästa "snören" öglor/hål i seglet så det kan sträckas och sättas fast i mast och bom. Sen har olika koponenter använts till det, komponeter som kaus som även använts till andra splisade öglor ombord och sedan lämnat segelfartygen och hamnat i stålwire-, bobryggar- och antennbyggarbranschen blnad annat och också.--LittleGun (diskussion) 6 januari 2020 kl. 09.07 (CET)[svara]
Normalt brukar vi radera innehåll på diskussionsidor som inte diskuterar arikeln. Och det gör inte diskussionssidan Diskussion:Lista över violinister, borsett från mallen om radering. På diskussionsidan finns en bot-skapad lista över alla violinister som har en post på Wikidata. Listan på diskussionsidan uppges i SFFR:en,[13], vara inlagd som inspiration till att skapa artiklar. Jag tycker den är alldeles för oregerlig för att uppfylla den funktionen (. Artikeln är borttagen eftersom den inte fungerade något bra som lista, avgränsning till exempel. Artikeln omdirigerar nu till kategorin Kategori:Violinister. Så några frågor:
1. Fungerar den verkligen som inspiration?
2. Jag har aldrig sett en omdirigering till kategori förut, det nämns inte heller i sffr:en. Är det brukligt?
Personligen tycker jag listan kan tas bort, den visar bara att även önskelistor bör vara avgränsade för att fungera. Jag förstår alltså inte poängen med att lagra Wikidata både på Wikidata och på Wikipedia. Men det kanske är något annat som åstadkoms med den.--LittleGun (diskussion) 19 januari 2020 kl. 12.46 (CET)[svara]
Omdirigeringar mellan namnrymder är inte brukligt, nej. Från användar- eller projektnamnrymden, inga problem. Men från huvudnamnrymden och kategorinamnrymden är mindre lämpligt. 62 osv (diskussion) 19 januari 2020 kl. 13.12 (CET)[svara]
Denna typ av frågeskapad lista bör/skall ha en intressent som aktivt är intresserad av resultatet (vilket inte är fallet här). För att visa upp information till läsare har vi Wikipediaartiklar med stabilt innehåll och användningar av med information från Wikidata via en infobox. Denna bör bara raderas.Yger (diskussion) 19 januari 2020 kl. 13.29 (CET)[svara]
Som "önskelista" betraktad håller jag helt med Ainali om att den kan placeras på ett bättre ställe. Listan kan dock även ses som en kandidat till "listartikel", men svwp har ännu väldigt få "Listerior" i artikelnamnrymden och när den skapades fanns det redan en lista där, den som var föremål för SFFR.
Hur "bra" listan fungerar som önskelista kan man också fundera på. Sedan den skapades på Lucia 2017, för cirka 18 400 timmar sedan har det skapats 54 nya svwp-artiklar om violinister, se Petscan-fråga. De allra flesta av dessa har förmodligen skapats av någon annan inspiration än denna lista, men det räcker väl att en enda artikel kommit till som en följd av listan för att den ska kunna motiveras.
Omdirigeringen till kategori är nog mindre lämplig. Den kanske kan ersättas med en "Se även-länk". Det kanske behövs ett standardiserat sätt att i listartiklar som bedöms som "kunna ersättas av en kategori" i stället för att radera artikeln stoppa in en hänvisning/länk till "rätt kategori" i den mån en sådan går att hitta.
Jag har inget emot listartiklar per se, och ser gärna en lösning som involverar Wikidata. Men, om det här är en kandidat till hur listartiklar skulle kunna se ut så tycker jag den missar fullständigt. Den är, enligt min mening, värdelös som listartikel. Den saknar fullständigt avgränsning och syftet och sammanhanget är helt oförklarat. Och det var länge sen, om det ens någonsin förut hänt, att en artikel på Wikipedia laggar ner min webbläsare och tar lång tid innan den kan läsas.
Är det verkligen en fungerande önskelista borde den fungera ännu bättre om den också hanteras så. Alltså att det förklaras, och kanske att den ligger där önskelistor borde ligga. Möjligen är diskussionssidan bästa platsen, men det har inte varit brukligt hittills.
Listartiklar som gör sig bättre att "ersättas av kategori" har alltså, om jag förstår rätt, inte förut medfört länkning till kategorin och det har inte diskuterats förut. Jag ser inte riktigt det behovet. Behovet borde dessutom vara mindre med Wikidata.
Listan skapades som en del av ett diskussionsinlägg och hade, vad mig anbelangar, kunnat raderas i samband med avslutningen av SFFR:en. Jag kunde lika gärna ha lagt den i Wikipedia:Sandlådan som jag gjort i några andra fall.
Jag gjorde alltså listan bara som ett enkelt exempel på vilka typer av data för violinister som skulle kunna listas med hjälp av Wikidata, inte som en komplett listartikel med beskrivande text och så vidare. Min poäng var att visa något som inte kan "ersättas med en kategori", ett alltför vanligt argument i "SFFR-jakten" på dåliga (inaktuella, ofullständiga,...) listartiklar.
Avgränsningar är lite knepigt när det gäller listor på personer med olika yrken eller annat som inte i verkligheten är klart avgränsade. I artiklar brukar vi skriva "(urval)" för att slippa diskussionen om listan är komplett eller ej. Om det är önskvärt med en kortare lista finns det många sätt att begränsa urvalet, ett kan var att endast lista personer som har en artikel i minst 10 (eller nåt) olika Wikipediaversioner, eller i svwp. För en "önskelista" ska naturligtvis inte de som har svwp-artikel vara med.
Av de nästan 5 500 Wikidataobjekten för violinister är det nästan hälften, cirka 2 600, som endast har en artikel i en enda Wikipediaversion. Av dessa är det 200 som bara finns i svwp. Om urvalet begränsas till personer med artiklar i minst 10 Wikipediaspråkversioner eller i svwp blir det mindre än 800 poster i listan varav knappt hälften finns i svwp.
Det är ett vanligt argument att använda Wikipedias omfattning som avgränsing för innehåll i listor och liknande. Jag tycker det är olyckligt, ett sorts cirkelresonemang. Jag menar att allt inte lämpar sig som listartiklar, bland annat på grund av avgränsningsproblem. Eller att Wikipedia inte är ett yrkestregister, precis som det inte är ett produkt- eller företagsregister. Jag tycker inte det är någon förlust att en sådan artikel raderas eller inte skapas. Som önskelista skulle kanske "finns på mer än 10 språkversioner, men inte på svWP" fungera som avgränsning för att få en mer hanterbar lista.--LittleGun (diskussion) 19 januari 2020 kl. 15.53 (CET)[svara]
Ja, lite cirkelresonemang är det, men inte värre än att det som finns i kategorierna, som vissa tycker kan ersätta listartiklar, också är helt definierat av vilka artiklar som finns och i det fallet är det bara en språkversion som står för urvalet. Om den globala Wikidatagemenskapen har skapat en artikel i mer än 10 olika språkversioner, var och en med sina relevansbedömningar, kan man förmoda att den också skulle kunna passera en relevansgranskning i svwp.
När det gäller önskelista finns det nu ett exempel, till och med med en beskrivande rubrik och lite brödtext, i Sandlådan.
Här ser vi exempel på att det finns violinister som har artiklar i upp till 27 olika Wikipediaspråkversioner, men som saknar artikel i svwp. Om man är lite elak skulle man nog kunna sätta mallen {{Global}} på kategorisidan Kategori:Violinister. Det finns gott om lokala (svenska) violinister, världsberömda i hela Knäckebröhult, som har artiklar i svwp, men inte i en enda annan språkversion. För den som genom att läsa svwp vill skaffa sig en bild av "världens violinister" är urvalet mycket skevt.
Detta är dock en naturlig följd av hur skribenter i olika språkversioner görs sina val. Se gärna den artikel som Paracel63 länkade till i den här tråden.
En listartikel byggd på Wikidata skulle kunna ge en mindre skev bild av ämnesområdet även om vi inte från dag 1 har kompletta artiklar i svwp om alla violinister i en sådan lista.
Ja, visst. Jag tycker det är varken wikipedianskt eller encyklpodiskt med såna artiklar, och just den här blev ju raderad på grund av problematiken. Men, till slut kanske vi vill vara ett register över vissa yrken, något jag tycker verkar vara bättre på Wikidata och passar dess funktion.--LittleGun (diskussion) 19 januari 2020 kl. 19.01 (CET)[svara]
Om relevans mäts i antal artiklar på olika språk och med tanke på hur "sysselsättning" mäts på Wikidata, så kan det lätt bli så att den mest "relevanta" svenska violonisten blir någon som Zlatan. Dvs någon som skaffat sig många artiklar på något annat sätt än genom att ha vilolinerande som sin främst sysselsättning. 62 osv (diskussion) 19 januari 2020 kl. 19.11 (CET)[svara]
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Listningen kan vara intressant och inspirerande. Men av två skäl bör den raderas, och Listeriabot bör bli informerad om skälen:
Listan ligger på fel ställe. Förslagsvis kan den flyttas till och fortsatt uppdateras till på en undersida till wp:Projekt musik (där det måste finnas en länk till listan).
Det är inte Listeriabot som har beordrat listan att skrivas ut och inte heller valt platsen där den skrivs. Det gjordes av Larske för ett par år sedan. Det är bara att ta bort hela listan! Vill vi ha den någon annanstans, så är det bara att gå in i historiken och fiska upp den. 62 osv (diskussion) 20 januari 2020 kl. 07.33 (CET)[svara]
Fixat Listan är nu borttagen. Diskussionen om Avlidna 2018 gällde något annat, där handlade det om att själva artikelsidan, som är helt manuellt skapad, innehöll för mycket mallkod för alla referenser, vilket gjorde att den behövde delas upp.
På engelska är beskrivningen: "this item is said to be the same as that item, but the statement is disputed" så egentligen är det nog helt korrekt att inte slå ihop förrän man har klargjort att de verkligen är samma genom att ta bort P460. ♥Ainalidiskussionbidrag8 februari 2020 kl. 18.55 (CET)[svara]
Ja, det förstnämnda är ett exempel på en så kallad "Extern identifikator" som är en sorts "index/nyckel" i en annan databas/webbplats, i detta fall till webbplatsen för Öppet arkiv (Q20746676). Med denna nyckel och egenskapen URL-format (P1630) kan man bilda en komplett URL till aktuell post på webbplatsen.
Det var jag som föreslog att vi skall ha SVT Öppet Arkiv i Wikidata se T225394. Den är långt från perfekt eftersom vi aldrig har pratat direkt med SVT.
saker jag skulle vilja ändra på
SVT skapar kategorier som blir lite yxiga att länka till
SVT verkar vara på väg till samma teknik som Wikidata vilket skulle kunna vara ett lyft om allt det dom har är objekt vi kan koppla till
jag skulle vilja se att de TV program som behandlar begrepp/händelser i Wikipedia/Wikidata blir egenskaper hos SVT
jag skulle vilja se att även vanliga SVT program kan länkas till, finska YLE har testat det lite. Ett scenario jag ser är att vid ett möte i oktober med Riksdagen T235527 prata dom om att deras dokument/motioner.. skulle taggas med en standard thesaurus EuroVoc (Q1370467) då skulle man kunna tagga TV-program, debatter med samma thesaurus... dvs. då kan man från Wikidata hitta senaste motioner/dokument för ett ämne i Riksdagen men även senaste TV debatterna...
positivt är
att kvaliten hos SVT verkar vara rätt bra
att SVT Wikipedia Wikidata är en perfekt match där vi har artiklar om de flesta skådespelarna etc. vilket SVT borde utnyttja...
Snyggast vore om WHO rapporten kan innehålla alla officiella data och det är det Wikidata bygger sitt data på (tweet). Jag har för mig att under Ebola utbrottet användes Wikidata en hel del för att förstå utbredningen och bland annat för att det är snabbt/enkelt och snyggt kan presentera datat på flera språk - Salgo60 (diskussion) 31 januari 2020 kl. 18.40 (CET)[svara]
Länk till fråga som ger en karta med länderna färgade i olika rödtoner efter det rapporterade antalet smittade. Klicka på ett land för att se landets namn och antalet smittade.
Tack för "lite mera hide", jag kom inte på vilken syntax det skulle vara och orkade inte leta... Har filat vidare med utfyllnadsnollor i datumet och ändrat en gräns (>=1 är ju samma som >0 så jag ändrade >=1 till >=2). Tog bort länken till Wikidataobjektet som jag inte ser något behov av. Ny variant.
Vet du om data per region finns inlagda i Wikidata? I så fall skulle man kunna visa en karta som den nedan (där jag "fuskat" genom att lägga in data i frågan).
SPARQL-fråga som ger en karta med Kinas regioner färgade efter antalet smittade 1 februari 2020. Klicka på länken "Testa" längst ned i rutan.
@Larske: Trevligt. Jag lade in gårdagens rapport från WHO (Q84164126) per land men rapporten har provinser, jag har inte sett något annat i WD
Mina funderingar/gissningar:
WHO rapporterna har provinser i Kina. WHO verkar bara leverera data i PDF
Johns Hopkins University har snygg dashboard, data i Google chart, avancerad modellering (finns nog ett mörkertal) plus att WHO verkade sakna bra underlag tidigare i år
BNO news har bra uppdatering och snygg "dagboksanteckning" av vad som händer löpande
min lekmanna tro är att datamodellen utvecklas det jag ser är parametrar som ålder på smittad, antal tillfrisknande, antal kritiska fall..., hur personen smittades vill man ha in
Wikidata "standarden" med att att man ändrar rank på senaste värdet känns lite "hemmabygge" för att det skall vara enkelt att fråga men gör det onödigt struligt att mata in nya värden är min reflektion och WD lösa det på annat sätt typ wdl WikidataLatest value ?!?!?! jag bollar den iden på Telegram Wikidata
OT: hur snyggt någon i Singapore gjort en portal som grupperar ihop smittbärare på olika parametrar etc. tweet dvs. det finns enorma möjligheter med mera datadrivna informationsmängder jag ser i förlängningen hur Wikidata kan vara till hjälp att föra in fler parametrar som antal sjukhus som finns i landet, befolkning i städerna, BNP, klassificera platser/städer där det utbryter.... - Salgo60 (diskussion) 4 mars 2020 kl. 11.11 (CET)[svara]
Användningen av WD verkar vara dokumenterad i Infobox TV-program inte i Infobox TV-program WD. Skapade Infobox TV-program WD/dok genom klipp och klistra. Maundwiki (diskussion) 9 mars 2020 kl. 13.30 (CET)[svara]
Wikidata, jag kollar så att det artikelnamnet utan särskiljning. Tills för några dagar sedan visades alla etiketter utan att göra en klick på "redigera". Maundwiki (diskussion) 17 mars 2020 kl. 12.55 (CET)[svara]
Hm. Under etikettrutan har jag en länk där det står "Alla inmatade språk". Det finns ju också en finess som heter labelLister (femte från toppen) som kan vara användbar. ♥Ainalidiskussionbidrag17 mars 2020 kl. 16.56 (CET)[svara]
Wikidata:Q373501 var UEFA Euro 2020 fram tills den 13 mars, men är nu UEFA Euro 2021. Är mästerskapet som ordnas nästa år det samma som det som inte ordnades i år? Jag antar att en del av de ID:n som beskrivs av WD-objektet inte gäller både mästerskapet 2020 och det 2021.
Hur hanteras sådana här metamorfoser på Wikidata? Hur mycket skall ett objekt ändra sig för att en ny Q-kod skall tas i bruk? Jag antar att motsvarande problem gäller för organisationer och eventuellt andra kategorier av företeelser.
Man kan diskutera vilka artiklar som ska vara i vilket objekt, men slås ihop ska de inte. Ur ett Wikidata-perspektiv är en lista över personer inte samma sak som ett efternamn. Jag har istället med {{Interwiki extra}} fixat så interwikin nu hämtas från båda objekten. 62 osv (diskussion) 28 mars 2020 kl. 07.24 (CET)[svara]
Jag håller med om att objekten inte bör slås ihop av ovan angivet skäl. Var dock uppmärksam på svagheten hos "Interwiki extra" som är "enkelriktad". Mallen gör visserligen att man inte bara hittar till de finska, ryska och ukrainska artiklarna från den svenska utan även till de engelska, tyska och kinesiska artiklarna, men från dessa finns ingen länk till svenska Wikipedia.
Att rätta wikidatalänkar efter felaktigheter i artiklar låter inte optimalt. Dessvärre finns mycket att önska när det kommer till litteraturartiklar på sv.wp (en av orsakerna till att WP:KVH startades). Se t.ex. diskussionssidan för den artikel du hänvisar till. //Vätte (diskussion) 30 mars 2020 kl. 21.45 (CEST)[svara]
Som framgår av följande översikt har itwp olika artiklar länkade till inre monolog (Q466163) och (Q3709942) så de kan inte bara slås ihop utan att även slå ihop de två italienska artiklarna (eller länka en av dem till något helt annat objekt)
Vad är det som har gjort det möjligt att under dagen kunna koppla artiklar till nya objekt på Wikidata fast att de redan är kopplade? Har fått flera notiser idag, bland annat att Robinson 2020 har blivit kopplad till Robinson 2020 (Q89651381). Jag gick in och kollade på Wikidata där det ser ut som att artikeln både är kopplad till det nya (Robinson 2020 (Q89651381)) och det gamla objektet (Robinson 2020 (Q86999331). När jag själv testade att koppla artikeln till ytterligare ett objekt fick jag direkt ett meddelande om att det inte gick. /Spisen (diskussion) 7 april 2020 kl. 15.35 (CEST)[svara]
Jag slog ihop ditt nyskapade d:Lexeme:L295082 men det tidigare skapade d:Lexeme:L32292. För att ihopslagningen skulle accepteras var jag först tvungen att ändra Lemma från "Stol" till "stol". Hoppas det blev rätt.
Tack så mycket. Och det det ska vara liten inledande bokstav. Och innehållet borde ha varit identiskt. Går det inte att radera objekt på Wikidata, eller var det en behörighetsfråga?--LittleGun (diskussion) 14 april 2020 kl. 16.46 (CEST)[svara]
Det går att radera objekt om man har rätt behörighet. Det finns en sida där man kan begära radering, se d:Wikidata:Request for deletion, men det verkar mest inriktad på objekt (Qnnnn). Vet inte om man kan begära radering av lexem (Lnnnn) där också eller om det finns någon annan sida för det. Det går alltid att fråga på d:Wikidata:Administrators'_noticeboard.
I Q54556 pekade P417 (skyddshelgon) på Q3947458 en förgrening. Inlagt av en bot 2013 tror jag. Den andra jag har råkat se för P417. Finns det botar som tar bort detta? P417 skulle troligen aldrig länka till en förgrening, går det att sätta ett värde i P417 som omöjliggör detta? Maundwiki (diskussion) 13 april 2020 kl. 22.33 (CEST)[svara]
Vanligaste egenskaperLänk till fråga som ger en lista över egenskaper som är vanligast att de har ett värde som är instans av (P31)Wikimedia-förgreningssida (Q4167410) (eller underklass till (P279) därtill). Listan är sorterad efter antalet objekt. För fem av de sex vanligaste egenskaperna är det antagligen ok, men för de flesta övriga, med huvudtema (P921) i topp (med just nu 3 631 objekt), är det antingen fel objekt som har angivits som värde för egenskapen eller så har det angivna objektet fått ett felaktigt värde på instans av (P31).
De flesta P417 listan är troligen samma bot 2013 men i t.ex. Q34579 ändrades Q3627394 (värde för P417) från lista(?) till förgrening efter att boten kördes. Indikeras den typen av ändring i dag? Ska fixa de 80. Maundwiki (diskussion) 14 april 2020 kl. 13.53 (CEST)[svara]
Fixade P417 som berörde italienska kommuner. Mycket var fel i itwp artiklar som boten troligen kopierade. Skulle det gå att filtrera detta i mallar/moduler som hämtar data från wikidata. I så fall skulle vi inte visa det som behöver städas för läsare av wikipediaartiklar. För de som vill städa får det tas fram sökmallar. Maundwiki (diskussion) 14 april 2020 kl. 19.59 (CEST)[svara]
Ja det är ett sätt och kan användas men kan även filtrera mer än vad som behövs. I detta fall skulle det kunna vara "om Qxxx för P417 är instans of Q4167410 använd ej". Bättre skulle vara "om Qxxx föf P417 har har "värdetyprestriktion" (om det går att koda för)". Exempel Q2609240 som har Q1017367 en stad men skulle troligen vara Q167477 ett helgon. Maundwiki (diskussion) 21 april 2020 kl. 20.51 (CEST)[svara]
Komikern Joe Lycett använde under en kort tid en skämtsam namnteckning. Den ligger med tidsbegränsning i Wikidata. Den ekas då ut i mallen som enda namnteckning, eftersom komikerns riktiga namnteckning inte finns upplagd. I artikeln om Joe Lycett ligger namnteckningen som en bild, i samband med att anledningen till den förklaras. Men, den hamnar i faktamallen också, och det är dels oförklarat och inte helt korrekt och dels tårta på tårta. Genom att bypassa WD-mallen med fältet "namnteckning = - ", så försvann den ur mallen, så det verkar fungera. Men det finns säkert ett rätt sätt att göra det på också.--LittleGun (diskussion) 23 april 2020 kl. 07.12 (CEST)[svara]
Man skulle kunna välja att i mallen vägra ta in "namnteckningar" som har ett slutdatum. Om du lägger in "avoidqualifier=P582" i mallen, så ska det ge den effekten. 62 osv (diskussion) 23 april 2020 kl. 07.56 (CEST)[svara]
Namnteckningsbilden försvann, men ersattes av en "länk till en obefintlig bild" och raden med etiketten Namnteckning försvann inte. Titta noga här.
Nu har jag infört möjligheten att med | namnteckning = noWikidata se till att ingenting visas.
Tack. Det är synd med overrides, men ibland är det tvunget. Fascinerande att det är så svårt att beskriva världen binärt, att till och med något som en namnteckning kan behöva nyanseras. Normalt är det annars vettigt att ha start- och slutdatum för namnunderskrifter, men kanske bara aktuellt om det finns fler. För konstnärer är det definitivt relevant att ha olika underskrifter för olika epoker. Här finns en sida som är specialiserad på det: [14].--LittleGun (diskussion) 23 april 2020 kl. 08.31 (CEST)[svara]
Det finns ytterligare ett tjugotal objekt med mer än ett värde för signatur (P109), men då har ett av värdena fått Föredragen rang, men de allra flesta har alltså bara ett värde.
Det finns också en egenskapsbegränsning för denna egenskap i Wikidata som heter single value vilket gör att man får ett larm (en cirkel med ett utropstecken) när man lägger in mer än ett värde och svwp-mallen hämtar endast ett värde för signatur (P109) även om det skulle finnas fler i Wikidataobjektet.
OK, jag vill påstå att det är en avsaknad av information på commons att det inte finns fler signaturer för respektive konstnär. Jag skulle tippa att för de 6446 namnkunnigaste konstnärerna borde det finnas minst fem signaturer.--LittleGun (diskussion) 23 april 2020 kl. 09.57 (CEST)[svara]
Spontant känns det som det borde finnas en hel hög människor där ute som bytt namn och därmed signatur, och att Wikidata borde kunna hantera detta.
Korrigering: De 6 446 objekt som jag nämnde ovan är objekt som är kopplade till en artikel i svwp. Totalt sett finns det 17 308 objekt som har ett värde för egenskapen signatur (P109), 28 objekt som har två värden och 1 objekt, (Q65591795), som har tre värden. Allt gäller "best rank", det vill säga bara uttalanden med "Föredragen rang" eller "Normal rang" (om inget uttalande med "Föredragen rang" finns).
Det har att göra med tidpunkten för införandet av den gregorianska kalendern i olika länder och att datum i Wikidata ofta är angivna med felaktig kalender. Anledningen i detta fall var att värdet för medborgare i (P27) för Hermann Wilker (Q77792) är Tyska riket (Q1206012) och Tyska riket (Q1206012) fanns inte med i listan över länder med speciella datum efter vilka datum ska visas kompletta. Se {{Wikidatadatum}} för en förklaring.
Nu har jag lagt till "Tyska riket" i samma lista som "Tyskland" så datum för personer med detta medborgare i (P27) kommer att visas som långa datum från år 1700. Om du laddar om artikeln ska det visas ett komplett födelsedatum (P569) i infoboxen för Hermann Wilker.
Om mallen ändras till geobox presenteras koordinater i inline och title. (fick inte till det för platser utanför Sverige läge W (USA)). Det blir skillnad i layout för annat, officellt och tidigare namn. Maundwiki (diskussion) 30 mars 2020 kl. 18.20 (CEST)[svara]
@Maundwiki: Det går att få även en mall som bygger på Faktamall att presentera koordinater både "inline" och i "title". Men eftersom det inte var så från början i {{Faktamall begravningsplats}} har en del artiklar som använder den mallen även försetts med mallen {{coord}}, placerad utanför anropet av {{Faktamall biografi WD}}. Om faktamallen helt plötsligt börja producera koordinater för "title" blir det en konflikt genom att två mallar (som inte har någon kännedom om varandra) båda försöker stoppa in en koordinat i "title", det vill säga en primär koordinat.
När mallen {{coord}} har tagits bort från alla artiklar som använder mallen {{Faktamall begravningsplats}} kan den senare ändras så att den producerar koordinat för såväl "title" som för "inline" utan risk för felmeddelande.
Utfört Detta är nu utfört.
Samma konflikt blir det om man stoppar in två mallar som skapar koordinater i "title" i en och samma artikel. Problemet kan undvikas om man förser mallen med en parameter med vilken man kan säga åt mallen att inte lägga in någon koordinat i "title" utan bara "inline". Denna möjlighet används då för alla utom ett av mallanropen på sidan. I Geobox heter parametern coordinates_no_title. En sådan möjlighet finns också i mallen {{Faktamall församling WD}} och där heter parametern notitlecoord. Du kan se ett exempel på detta i artikeln Södertälje församling som använder två faktarutor på samma sida utan att det blir något felmeddelande om att "coordinates kan inte ha mer än en primär tagg per sida". Men den lösningen kanske kan vänta i {{Faktamall begravningsplats}} tills det finns ett reellt behov av att använda mer än en sådan faktaruta i samma artikel. För att det ska vara meningsfullt med mer än en faktaruta måste mallen också kompletteras med en parameter item som anger vilket objekt faktarutan avser när det inte är artikelobjektet.
Tack, jag testade en mall baserad på geobox (eftersom det är en plats) med kod för lat/long från Ortsfakta Sverige WD, anpassat med Wikidata2. Den fungerade för kyrkogårdar i Sverige men inte Arlington. Ska se om hur du gjorde kanske kan få den att fungera globalt. Maundwiki (diskussion) 31 mars 2020 kl. 13.43 (CEST)[svara]
Det som krävs är att det finns en länk från ett OSM-objekt till Wikidata. Sen kan man i Wikipedia med hjälp av "Kartographer" rita kartor. Det tycks krävas att det är ett objekt av typen "relation" i OSM, objekt av typerna "node" eller "way" har jag inte fått att fungera med Kartographer i Wikipedia.
Till höger är ett exempel på ett OSM-objekt av typen "relation" som är kopplat till Gamla stan (Q579854) och därför kan visas i en karta i svwp med hjälp av Kartographer.
De exempelobjekt Salgo60 tar upp ovan är av typen "way". Någon annan kanske vet om objekt av typen "way" också kan fås att fungera med Kartographer.
@Ainali: Kan du se varför inte "geoline" för Gamla kyrkogården (22634163 i OSM) inte visas på samma sätt som Adelsgatan i Visby trots att den är kopplad till Gamla kyrkogården (Q26257009) i Wikidata? Och något felmeddelande får man inte heller, bara en kraftigt inzoomad karta över lat/lon = 0/0 (i Atlanten väster om Afrika alltså). Är det existensen av egenskapen OpenStreetMap relations-ID (P402) i Wikidataobjektet som ställer till med problem för Kartographer? Det pekar ju på en "relation" trots att OSM-objektet är en "way".
Aha! Och hur ser man i OSM om en "way" kan tolkas som en geoline eller som en geoshape? Borde inte en enkel geoshape, som bara består av ett område (en sluten kurva), kunna tolkas av Kartographer även om man har angivit "service": "geoline"?
Finns det något sätt att "testa/smaka på" ett OSM-objekt för att få reda på om det är en "geoshape" eller en "geoline"?
Det hade varit käckt om Kartographer hade spottat ur sig ett begripligt felmeddelande om det OSM-objekt man pekar på är av fel form istället för att bara ge upp och visa kartan över Atlanten? Kartographer kanske har någon "debug-parameter" som jag inte har upptäckt...
Om det finns mer än en punkt så är det ganska enkelt att göra en liten snurra som givet tex ett antal OSM-objekt bygger ett konvext hölje och spottar ut en polygon i lämpligt format man exempelvis lägger in som Data i Commons. Skulle det vara intressant? Karl Wettin (WMSE) (diskussion) 21 april 2020 kl. 21.01 (CEST)[svara]
@Karl Wettin (WMSE): Nej, jag tycker inte att det är intressant, om du inte gör snurran för alla polygoner med Wikidataobjekt, samt uppdaterar när det tillkommer nya eller förändras. Det intressanta i mitt tycke är en "live" koppling till OpenStreetmap.
@Larske: Det vore finemang om vi kunde göra en mall/modul där inparametern bara är en (eller flera) wikidataobjekt, så att användaren inte behöver veta hur det ser ut på OpenStreetMap, och resultatet blir en karta med objekten på. Jag vet dock inte hur vägen dit ser ut. ♥Ainalidiskussionbidrag27 april 2020 kl. 09.43 (CEST)[svara]
I faktamallen i artikeln James Watson förekommer länken James D. Watson Biography 19 gånger som källa till olika små fakta. Problemet är att den inte visas så utan den visas som "P.A.M.Dirac Biography". Om man nu skulle vilja rätta detta och klickar på Redigera Wikidata så kommer man till ett användargränssnitt där man måste leta upp minst 19 olika förekomster av referensen och sedan i var och en av dem ändra till korrekt titel. Nu lärde jag mig här att alla likalydande referenser i Wikidata kopplas ihop med en hash som faktamallen använder. Därför undrar jag om det finns något smartare sätt att rätta felet. Plumbum208 (diskussion) 27 april 2020 kl. 19.47 (CEST)[svara]
Det finns en finess på Wikidata för att kopiera en referens från ett påstående till ett annat. Det blir ju en hel del mindre klickande (men javisst, ändå en ansenlig del). ♥Ainalidiskussionbidrag27 april 2020 kl. 21.37 (CEST)[svara]
Men visst borde norra stjärnhimlen på svenska och luxemburgiska hänga ihop med de övriga norra stjärnhimlarna? Finns det i så fall nån som på ett enkelt sätt kan förklara hur jag ändrar? // Zquid (diskussion) 24 april 2020 kl. 13.55 (CEST)[svara]
Här är en översikt över språkkopplingar till fyra olika objekt i Wikidata. norra stjärnhimlen (Q10294637) och norra stjärnhimlen (Q1998069) kan nog slås ihop. Båda dessa objekt saknar beskrivning och är väldigt "magra" vad gäller egenskaper.
@Zquid, Larske:Tack för påpekandet - och klarläggandet. Nu är de båda wikidata-objekten sammanslagna. Naturligtvis ska inte holländskan och svenskan segla för sig själva. Däremot visar det sig att dessa båda språk var först med WD-objektet. Deryni (diskussion) 24 april 2020 kl. 19.18 (CEST)[svara]
@Larske, Deryni: Tack för hjälpen! Vi får se om jag kan hitta källor till artikeln, annars får det räcka med de rymdrelaterade artiklar som redan är inlagda i tävlingens tipshörna. Norra stjärnhimlen finns (förhoppningsvis) kvar ett tag till... // Zquid (diskussion) 26 april 2020 kl. 12.51 (CEST)[svara]
Hej! Jag skulle vilja flagga för denna diskussion, där vi just nu har problem med att en mängd decennier för över 2000 år sedan markeras som instans av "uttalande med gregorianskt datum före 1584", med en visning via f.v.t (och inte som f.Kr. som alla decennierna noteras som i etiketten). Vet ni var skon klämmer och håller ni med om problembeskrivningen? Tack på förhand. --Paracel63 (diskussion) 6 maj 2020 kl. 22.49 (CEST)[svara]
Bestämningsordet "uttalande med gregorianskt datum före 1584" har lagts till för att den som har angett 130 f.v.t. påstår att det är enligt den gregorianska kalendern, vilket ju inte borde ha gjorts. Det är alltså en hjälp för att upptäcka felaktigt angivna datum. Den som vet rätt datum i den då gällande kalendern uppmuntras att rätta felaktigheten. ♥Ainalidiskussionbidrag7 maj 2020 kl. 00.12 (CEST)[svara]
Jag vet inte om ni talar förbi varandra, det är väl två olika problem i mallen för Venus de Milo:
1: att det står (stod?) "gregoriansk kalender", vilket inte per definition är ett problem. Till exempel om det är gregoriansk tidräkning.
2: att mallen ger "f.v.t" istället för f.Kr., (och jag menar det finns konsensus för att använda f.Kr. på svenskspåkiga Wikipedia även om det finns flera användare som tycker det är mycket stötande.) Det blir ännu sämre när mallen ger f.v.t och i artikeln står f.Kr, eftersom vi brukar vilja ha samma skrivsätt i samma artiklar som minimikrav.
Instämmer - diskussionen innehåller två åtskilda problem. Jag ändrade WD-objektet till Julian och tog bort "uttalande med gregorianskt datum före 1584" (vilket måste göras manuellt). Men det har inget med problem 2 att göra - och det lyckas jag inte lösa. Det ligger nog i en översättningstabell någonstans. Men var? --北山 Kitayama (diskussion) 7 maj 2020 kl. 07.32 (CEST)[svara]
Det är inte konstigt om någon gjort "fel", för 130 f.Kr. fanns inte någon juliansk kalender heller.
Men det ska översättas konsekvent även i Translatewiki. Se mina exempel längre ned. Det finns ingen rimlig orsak till att sekel och decennium har olika översättningar av samma begrepp. --北山 Kitayama (diskussion) 7 maj 2020 kl. 10.50 (CEST)[svara]
Frågan är "Decennier f.Kr. som visas som f.v.t" och den är helt frikopplad från vilken kalender som används. Frågeställaren drog en felaktig slutsats att kalendern var inblandad. Sånt händer. Det är inte i Wikidata problemet ligger. Lösningen på frågeställarens problem är att ändra en översättning. @Ainali: Du har väl behörighet/erfarenhet av översättningar? Jag ser att BCE ibland översätts som f.kr., ibland som f.v.t. Vi borde vara konsekventa. --北山 Kitayama (diskussion) 7 maj 2020 kl. 09.44 (CEST)[svara]
@Kitayama:Paracel63 talar i första tråden om "uttalande med gregorianskt datum före 1584". Som jag beskriver ovan är det inte självklart att uttalanden med gregorianskt datum före 1584 är "fel". Och jag skulle säga att en rak översättning av BCE/CE görs bäst till fvt/vt. fKr och eKr må (ännu) vara lite mer spritt i svenska språket, men det är ingen rak översättning. 62 osv (diskussion) 7 maj 2020 kl. 09.57 (CEST)[svara]
Wikidata använder alltid BCE. Det är en del av datatypen för tid. Hur den ska presenteras på ett visst språk avgörs vad jag förstår i translatewiki.net. (Alltså utanför Wikidata) Där översätts den för år till f.kr. och för decennium till f.v.t. Alltså olika beroende på hur exakt tidsperioden är. Vilken översättning vi ska ha kan diskuteras, men vi ska alltid ha samma. --北山 Kitayama (diskussion) 7 maj 2020 kl. 10.15 (CEST)[svara]
Om Wikidata genomgående använder BCE/CE tycker jag absolut vi ska översätta det med f.Kr./e.Kr. (bortsett från århundrade då, det måste vara ett misstag att det hanteras annorlunda?), "någon" kan säkert bypassa så att det går manuellt att ändra till f.v.t/e.v.t mallar om det finns undantag.--LittleGun (diskussion) 7 maj 2020 kl. 10.39 (CEST)[svara]
Det mer korrekta svaret är: Wikipedia använder varken eller. Där lagras endast årtalet, -130, och en precision som anger ”decennium”. Tolkningen av dessa båda sker utanför Wikidata. Det är en översättning per precision. --北山 Kitayama (diskussion) 7 maj 2020 kl. 10.44 (CEST)[svara]
Jaha, rörigt. Den inkosekventa översättningen bör fixas på translate-wiki. Men, det måste väl reda finnas något ord på translate wiki typ MediaWiki:Wikibase-time-precision-AD-10annum/sv som har översättningen e.Kr., eller? Gör inte det tycker jag inte att BCE ska översättas rakt, utan till f.Kr. För det är svenska för BCE (ännu).--LittleGun (diskussion) 7 maj 2020 kl. 11.11 (CEST)[svara]
Här är en lista på översättningar av "fraser" i som har med "Wikibase-time-precision" att göra. Eftersom de har namn som börjar med Wikibase och Wikibase har mer med Wikidata än med Wikipedia att göra, tror jag Ainali har rätt "i princip". Men i praktiken är det nog här som de flesta som har åsikter i frågan finns.
Jag ändrade århundrade till "f.v.t", så att det är konsekvent översättning i varje fall. Det verkar inte finnas någon med AD, typ en sån: MediaWiki:Wikibase-time-precision-AD-10annum/sv?--LittleGun (diskussion) 7 maj 2020 kl. 11.45 (CEST)[svara]
@LittleGun: Det är ett falskt påstående att det finns konsensus för att alltid skriva "f.Kr" på svenska Wikipedia. Senaste gången "f.v.t." diskuterades grundligt blev utslaget att konsensus inte kunde uppnås och därmed gäller att aldrig ändra för ändrandets skull samtidigt som det är upp till var och en att välja uttryck. Så sammanfattade jag diskussionen och mot det har ingen haft några invändningar. Vissa förespråkare för "f.Kr." tackade mig t.o.m. för sammanfattningen. Diskussionen finns här: Diskussion:Vår tideräkning#Före Kristus – kontroversiellt?. /Ascilto (diskussion) 7 maj 2020 kl. 12.08 (CEST)[svara]
Ja, okej. Det är ju bra att inte ändra för ändringens skull. Jag håller inte med och tror att det berodde på diskussionströtthet, men det var ju bra att du fick tack. Hoppas du fick det från mig med, och det är nog en kompromiss som vi måste ha. Men, i t ex artikeln Venus från Milo så används f.Kr genomgående i brödtexten. Men, mallen från Wikidata kom in senare och bryter mot den kompromissen. Då ska mallen fixas så att det står f.Kr, men att det ska var möjligt att skriva f.v.t., vid behov i en sån artikel.--LittleGun (diskussion) 7 maj 2020 kl. 12.45 (CEST)[svara]
Även jag minns diskussionen som nämns ovan som att konsensus saknas för endera hållet att helt förbjuda eller enbart använda det ena av uttrycken. Däremot anser jag att vi kan behöva vara förberedda på att f.Kr faktiskt är på väg ut och f.v.t. är på väg in, även om jag tror att det kan dröja lång tid innan f.v.t. uppfyller POMMF för alla. //Vätte (diskussion) 8 maj 2020 kl. 15.05 (CEST)[svara]
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
Möjligen är e/f.v.t på väg in. Men just nu är e/f.Kr vanligast. Då tycker jag mallen ska ge resultatet f.Kr. som default, men med möjlighet att ändra detta till f.v.t. Är det överhuvudtaget möjligt?--LittleGun (diskussion) 8 maj 2020 kl. 15.22 (CEST)[svara]
Mallen skulle kunna skriva ut både e/f.Kr. och e/f.v.t. efter varandra i faktarutan och där respektive fras är försedd med en egen css-klass. Den förstnämnda är synlig och den sistnämnda görs osynlig, med display:none; i de gemensamma css-inställningarna i svwp, men för den som föredrar det andra skrivsättet går det bra att i sin personliga css-inställning göra den förstnämnda osynlig och den sistnämnda synlig.
Det kanske uppskattas av någon. Men, Wikipedia ska ju funka som tänkt även utan personliga inställningar, och de allra, allra flesta som kommer in på en artikel har inga personliga inställningar. Och som tänkt är att det inte ska vara blandat f.v.t/f.Kr. i samma artikel. Om det alltid blir det ena kommer ju en del att bli just blandade. Är det här bara ett svenskspråkigt problem?---LittleGun (diskussion) 8 maj 2020 kl. 18.02 (CEST)[svara]
Ytterst tveksamt om en sådan inställning skulle fungera, eftersom de ställen f/e.Kr blir mest tokiga beror mer på ämnets sammanhang än på läsarens preferenser. 62 osv (diskussion) 8 maj 2020 kl. 18.15 (CEST)[svara]
Vilken inställning menar du med "sådan"? Personlig inställning? Är det en default inställning (tex f.v.t) så blir det ju det överallt. När man lägger in mallen och ser att artikeln genomgående använder f.Kr. så får man ställa om mallen. Det har ju inte med läsarens preferener att göra, utan artikelns. Är detta bara ett problem för svWP, och svenskan?--LittleGun (diskussion) 8 maj 2020 kl. 18.46 (CEST)[svara]
En sådan lösning som Larske föreslog ovan. Och jag ger dig rätt i att det beror på artikeln om fKr eller fvt är det bästa alternativet. Jag är inte bekant med särskilt många språk. Det är bara i engelska jag vet att båda alternativen används, men det är bara i svenska jag sett det bli en diskussion runt det. Och det är bara på Wikipedia jag sett att man (ofta) aktivt föredrar fKr framför fvt på svenska. 62 osv (diskussion) 8 maj 2020 kl. 19.26 (CEST)[svara]
@Sextvåetc: Den css-lösning jag skissade på kan naturligtvis inte göra något åt om själva årtalet som är lagrat i Wikidata är fel på något sätt. Det löser inget som har med kalenderstrul eller hur man ska tolka när ett sekel börjar och slutar. Det gör bara så att den som tycker att f.Kr. alltid bör skrivas f.v.t blir nöjd.
För att det ska bli konsekvent i hela artikeln behöver man också använda en mall {{personligt tideräkningsformat}} med parameter eKr, fKr, fvt eller evt på alla ställen i artikeln där det står f.Kr., e.Kr. ,f.v.t. respektive e.v.t. i artikeln och den mallen lägger ut samma kod som databox-mallen.
Tillägg: Det skulle räcka med två mallar, {{fkr}} och {{ekr}} men för husfridens skull med omdirigeringar från {{fvt}} och {{evt}}.
@LittleGun: Att det ska fungera utan personliga inställningar och samtidigt tillfredsställa såväl de som vill se f.Kr. som de som vill se f.v.t. har jag svårt att se.
Det svåra är när det är olika uppfattning om vilket format som andra ska få se.
Och vilket format som ska visas för alla som inte har några personliga inställningar måste fortfarande beslutas genom konsensus i gemenskapen, så ingen behöver vara orolig för att den evighetsdiskussionen dör ut. Om en sådan konsensus någon gång ändå skulle uppstå, kan man med den skissade lösningen med en redigering på ett enda ställe byta mellan vilket av de två skrivsätten som ska gälla för oinloggade och de som inte har gjort något aktivt val.
Jag hade aldrig sett f.v.t förrän jag blev aktiv i Wikipedia och har fortfarande inte det någon annanstans. Nåväl, borde det inte vara artikelförfattaren som bestämmer på samma sätt som denne bestämmer vad som ska stå i löptexten. Går det då inte att ha en parameter i mallen "visakr" som om den är = Ja så byts att f.v.t i Wikidatasvaret ut till f.kr? Personligt format tror jag inte på. --北山 Kitayama (diskussion) 8 maj 2020 kl. 19.41 (CEST)[svara]
Larske: Jag fattar inte. Pratar vi förbi varandra. Jag menar att med en parameter ska man kunna styra vilkrt format mallen ska visa visa, x.v.t eller x.Kr. För alla. Den ska då man lägger in den ställas om till det format som artikeln redan har. Eller om man missar det får någon annan göra det. Att "lösa" det med personlig inställning är ingen lösning.--LittleGun (diskussion) 8 maj 2020 kl. 20.33 (CEST)[svara]
@Larske: fvt och fKr är två sätt att benämna samma kalender. Sedan har jag här på Wikipedia fått lära mig att fvt kan tolkas på mer än ett sätt, men det skiljer ändå inte mellan dem. 62 osv (diskussion) 8 maj 2020 kl. 20.39 (CEST)[svara]
@Sextvåetc: Ja, om det finns något tidsvärde (årtal) i Wikidata som är rätt om man skriver f.Kr. efter det, men inte är rätt om man skriver f.v.t. efter det, på grund av att f.v.t. har mer än en tolkning så går det ju inte att "översätta rakt av". Men då går det inte heller att använda f.v.t. i artikeltexten (för sådana årtal) utan att också skriva vilken tolkning som ska göras. Har du något exempel på sådana årtal?
Skillnaden är vilket ord v:et ska uttolkas som. Oavsett om det är vår, västerländsk, vanlig så syftar det på samma tideräkning som f.Kr. 90.227.175.2448 maj 2020 kl. 21.29 (CEST)[svara]
Jag skulle säga att nästan vad som helst man säger om vad som hände under det första århundradet och århundradet före det, blir fel med f/e.Kr eftersom ingen med säkerhet vet när Kr föddes. Jag kan också tycka att det blir konstigt med Kr när man talar om Kinas eller Judendomens historia. Tolkningen "vår" i (f)vt anser jag och flera med mig är POV-ig. Jag föredrar "vanlig". 62 osv (diskussion) 8 maj 2020 kl. 21.33 (CEST)[svara]
Jag tolkar svaren som att "år X f.Kr." är alltid, utan undantag, samma som "år X f.v.t." och att man utan problem kan skifta mellan de två skrivsätten utan att ändra på "X". Vad sedan bokstaven "v" ska utläsas som och att det för en given händelse kan vara svårt att ange vad "X" är kan så vara. Men det är något helt annat än frågan om vilket av de två skrivsätten "f.Kr." och "f.v.t." som ska stå efter detta "X" i en artikel i svwp. Att ingen med säkerhet vet när någon föddes gör inte ett smack så länge man är överens om hur många "solsnurr" till exempel år 42 f.Kr. (eller f.v.t.) är från till exempel idag.
Jag har aldrig hört annat än att just att "år X f.Kr." alltid, utan undantag, är samma som "år X f.v.t." och att man utan problem kan skifta mellan de två skrivsätten utan att ändra på "X". Oavsett gamla stilen och nya stilen t ex.--LittleGun (diskussion) 9 maj 2020 kl. 05.00 (CEST)[svara]
Jag har inte sett någon här påstå någonting annat än att det ska vara exakt samma siffra oavsett vilket skrivsätt som används. Problemet uppstår när det som i den här artikeln skrivs att personen föddes mellan 7 f.Kr och 4 f.Kr. Det blir inte så lite märkligt eftersom hela tideräkningen utger sig för att bygga på när samma person föddes. Skrivsättet fvt bortser från när han föddes, och följer bara en gängse tagen regel utan hänsyn till vad den bygger på. 62 osv (diskussion) 9 maj 2020 kl. 08.52 (CEST)[svara]
62 osv: Jag trodde Larske hade uppfattat det så. Det kanske var fel. Jag antar att du alltid anger temperatur till Kelvin. Nej, visst ja, han angav ju nollpunkten i Fahrenheit. (Förlåt).--LittleGun (diskussion) 9 maj 2020 kl. 09.12 (CEST)[svara]
@LittleGun: Jag anger temperaturer i Kelvin när det är relevant att göra så. Jag använder Celsius när det är relevant att göra så. Det beror på målgrupp och sammanhang. För vattens fryspunkt använder jag Kelvin och för min kroppstemperatur använder jag Celsius. När det kommer till tideräkning gör jag samma sak. Ibland är B.P. mycket mer relevant än både fvt och fKr och då är det exakt det jag använder. Inom astronomi skriver jag -129, inte 130 fKr eller 130 fvt. 62 osv (diskussion) 9 maj 2020 kl. 09.28 (CEST)[svara]
Tack för förklaring till B.P.. Men blir det aldrig märkligt för dig att använda Celsius? Han satte ju noll grader till vattnets kokpunkt, och 100 grader till dess fryspunkt. Det vi kallar Celsiusskalan är ju helt upp och ner.--LittleGun (diskussion) 9 maj 2020 kl. 09.35 (CEST)[svara]
Som sagt, sammanhang och konvention. Vissa här säger att de aldrig stött på fvt innan de kom till Wikipedia. Jag har läst det i texter översatta från engelska i decennier. Dessa texter undviker f/e.Kr just för att författarna inte vill att deras uttalanden ska tolkas som att de "vet" när "Kr" föddes eller inte vill använda Kr som referens. Här i Sverige fortsatte vi använda den julianska kalendern längre än i en del andra länder. Vi är olika snabba med att ta till oss olika saker och jag var snabb att ta till mig skrivsättet fvt/vt. Jag tillhör å andra sidan inte dem som snabbt tagit till mig "hen". 62 osv (diskussion) 9 maj 2020 kl. 10.33 (CEST)[svara]
Då förstår jag. Då beror det på ovana att använda f.Kr./e.Kr helt enkelt. Att nollan ligger fel i förhållande till Jesus eventuella födelsedag är alltså ovidkommande. Jag trodde det var där skon klämde, eftersom du skrev att det är "inte så lite märkligt" för ett par timmar sedan bara:[15]. Och det kan man ju tycka, men såna diskrepanser är så vanliga att jag har vant mig och ser det som kuriosa.--LittleGun (diskussion) 9 maj 2020 kl. 11.16 (CEST)[svara]
Jag har väl också kommit att ogilla f/eKr, men det är ingen tvekan om att det avser samma sak. Vad gäller år 0, så vet du nog att det inte finns, men det gäller inte i astronomiska sammanhang. Där finns år 0. År 130 fKr/fvt motsvarar därför det astronomiska året -129. 62 osv (diskussion)
Jo, jag känner till det med år 0. Det förenklar inte direkt diskussionerna i Sverige anno 2020. Jag tänker år noll som en punkt, nollan. Vet inte varför däremot, men jag har förstått att födelsedagar har funkat och funkar lite olika. I sydkorea kan man bli två år på ett par minuter. Man fyller 1 när man föds och sedan varje nyårsdag, har jag hört.--LittleGun (diskussion) 9 maj 2020 kl. 12.26 (CEST)[svara]
@LittleGun: Det är nog jag som tänkte lite snett när jag försökte lösa ett annat problem än det som tråden handlar om. Om det är ok att olika artiklar har olika visningsformat så fungerar det såklart att låta mallen visa olika format i olika artiklar. Det jag skissade på var en lösning på problemet att olika användare vill se olika visningsformat men varje användare vill se samma visningsformat överallt. Jag vet inte hur det är i till exempel NE, men de kanske också använder olika skrivsätt för f.Kr./f.v.t. i olika artiklar beroende av vem som är författare. Jag tycker att det är lite trist att det är så i svwp.
Sökning i NE.se ger bara träffar för "f.v.t." i en handfull artiklar om tideräkning. "f.Kr" används för årtalsangivelser i tusentals artiklar. 90.227.175.2448 maj 2020 kl. 21.29 (CEST)[svara]
Naturligtvis kan allmänt språkbruk vara skilt från NPOV. Det är ju ganska besvärligt, och möts ofta av misstänksamhet, att påvisa t ex en negativ värdering i ett ord som är allmänt språkbruk. (Ascilto vet såklart det bättre än de flesta, med tanke på .Kr/.vt., även om jag hävdar att .Kr är NPOV till skillnad från .vt., oberoende av att jag dessutom menar att .Kr är POMMF)--LittleGun (diskussion) 12 maj 2020 kl. 12.48 (CEST)[svara]
Ascilto: Inga skäl alls. Och, det finns ingen sarkasm i inlägget överhuvudtaget. Tvärtom. Parentesen var att jag menade att jag lade mig i och försvarade din rätt att tycka .Kr är POV, trots att jag egentligen inte behöver och oavsett om det är allmänt språkbruk eller inte och trots att jag inte håller med. Ingen sarkasm. Ledsen att du läste det så.--LittleGun (diskussion) 12 maj 2020 kl. 16.13 (CEST)[svara]
Jag förtydligar: Att hålla sig till det allmänna språkbruket kan inte anses vara att driva POV, däremot kan det allmänna språkbruket givetvis uttrycka en viss åsikt om ett sakförhållande. Men då samtalar man om det, man frångår det inte på eget bevåg. Tostarpadius (diskussion) 12 maj 2020 kl. 13.05 (CEST)[svara]
Snälla, snälla, snälla. Undvik själva debatten här. Gärna någon annanstans, men den här tråden har ju blivit bänglig ändå. Här handlar samtalet inte om att det vore bättre om vi kunde använda den den enda sanna, rent opartiskt, vetenskapligt, o-poviga och icke-missvisande varianten. Och köra över de som har så fullständigt fel.
Larske: Det är inte bara OK att olika artiklar har olika visningsformat, f.v.t/e.v.t eller f.Kr/e.Kr, det är tvunget på svWP. Jag tycker också det är trist, men annars kan vi inte använda WD-mallar.
Jättebra att det går att fixa så att det går att ställa visningsläge för mallar. Det är helt klart tvunget att göra på det viset, så att varje artikel blir konsekvent åtminstone. Det är bara att implementera. Och det ska implemeteras för alla WD-mallar. Då har vi löst problemet för Wikipedia.
Längre svar: Det beror på hur man hämtar data. Som någon tidigare påpekat är tidsvärden lagrade utan något "tideräkningsformat" i Wikidata. Detta format läggs alltså till någonstans på vägen och det finns olika vägar.
Det som finns i denna datastruktur kan man med Lua-kod formatera precis hur man vill, men det är som synes lite meckigt och därför försöker man arbeta på en något högre abstraktionsnivå och använda hjälpfunktioner.
Om man, som modulen Databox gör, använder funktionen formatStatements som finns i ett bibliotek som heter mw.wikibase för att formatera datavärdet kommer ett format att läggas till och resultatet blir i detta exempel 130-talet f.v.t..
Detta värde, med "f.v.t.", formateras just nu ovillkorligen om till "f.Kr." av modulen och det som behöver läggas till är ett villkor att omformateringen endast görs där den med en mallparameter är begärd eller, om man så önskar, alltid görs utom där den med en mallparameter är undertryckt. Då kan man få olika format i olika artiklar.
Tack för svar! Jag kopierar det till malldiskussionen, malldiskussion:Databox. Jag anser att frågorna i den här tråden är avslutade. Så vill ni nu förklara det obegripliga i varför vår, vanlig, och västerländsk inte är mycket, mycket mer kulturimperialistisk än att använda det där namnet som nollan faktiskt bygger på. Det vill säga dagen som den där munken "felaktigt" valde som födelsedag för byggnadsarbetare Jesus Josefsson, populärt kallad Kristus. Så att det är öppet och tydligt var nollan kommer ifrån, och det är naturligtvis inte mer ovetenskapligt än att "felaktigt" uppkalla vår, vanliga, vackra temperaturskala efter Celisus, trots att han satte vattnets kokpunkt till noll och dess fryspunkt till plus hundra. Och inte mer konfessionellt än benämningarna onsdagen efter Oden, månaden mars efter Mars, Anno Mundi efter bibelns skapelseberättelse eller Anno Hegirae efter Mohammeds flytt från Mekka till Medina. Varsågoda!--LittleGun (diskussion) 9 maj 2020 kl. 08.55 (CEST)[svara]
Nyss uppfattade jag det som att du bad om att diskussionen om vilket uttryck som skall föredras skulle föras någon annan stans. Fine with me. Nu ser det ut som om du själv ger dig in i den diskussionen. På ett raljant vis. Ganska motsägelsefullt, måste jag säga. /Ascilto (diskussion) 9 maj 2020 kl. 11.34 (CEST)[svara]
Jamen, det var för att inte störa trådfrågan, som blivit rörig. Nu är trådfrågan är utredd. Då tycker jag det är fritt fram. Jag försökte förklara min åsikt lite putslustigt och lättsamt, det kanske uppfattas raljant. Men, min skyttegrav är djup här. Det är så vansinnigt konstigt att f.Kr/e.Kr uppfattas som pådyvlande ett kulturarv, när det bara ger nollan kontext. Medan "vår", "vanlig" och "västerländsk" är ett så uppenbart flagrant pådyvlande av just kulturarv.--LittleGun (diskussion) 9 maj 2020 kl. 11.48 (CEST)[svara]
Exempelvis mall:faktamall biografi WD och mall:publikation, liksom andra mallar som är baserade på modul:Wikidata2, verkar dölja år innan 1 eller visar ett felaktigt felmeddelande: "Fel: #tid stödjer enbart år från 0.". År 0 finns ju inte men årtal lagras på wikidata som astronomiskt år, där 0 representerar år 1 f.kr. Mall:Wikidata Infobox (som är mycket vanlig på commons) visr "f.kr." om man väljer svenska som språk. Databox visar nu generellt f.kr. En era-parameter för att välja mellan f.v.t. och f.kr. är i dagsläget lättare att åstadskomma i andra wikidatamallar än i mall:databox, eftersom de har komplex formateringskod, och vissa andra mallar bara behöver funka på svwiki, så det är rimligt att börja där om detta nu verkligen är viktigt.
Mer viktigt: F.kr. är väl rätt ovanligt inom arkeologi och naturvetenskap, om tider före antiken? Vi behöver därför kunna konvertera till t.ex. år B.P., "X år sedan" eller "Megaannum". Generellt kan vi behöva kunna konvertera från wikidatas enheter till andra enheter i våra mallar. Med modul:complex_date kan man visa bp genom att sätta era=bp. Man ska också kunna konvertera från en era till ett annan men jag lyckas inte med det just nu. Complex_date skulle vara en internationellt snygg lösning, eftersom den är gjord för att visa vanliga tidsformuleringar på alla möjliga språk. Den fixar muslimska kalendern, med flera kalendrar. Dock: Om man sätter era=bce visar den "f.kr." på svenska, och den har inget stöd för "year ago", "Megaannum" och liknande. Tomastvivlaren (diskussion) 9 maj 2020 kl. 12.11 (CEST)[svara]
Det är absolut bra om Wikidatamallar kan hantera flera sorters kalendrar och tidsangivelser. Men, samma regel tycker jag ska gälla: Mallen ska följa brödtexten i första hand och mallinsättaren i andra hand. Rent allmänt, och oberoende av Wikidata: Var också försiktig med alltför mycket specialintressekunskaper. Även om det i ett fält är vanligt att använda astronomiskt år är det inte säkert att det är vettigt att använda i ett konversationslexikon, en tradition som jag menar Wikipedia verkar i. Såna gränsdragningar får vi ta vartefter, det gäller icke-Wikidata mallar också, men där kan i stort sett alla användare putsa till det vid behov.--LittleGun (diskussion) 9 maj 2020 kl. 12.58 (CEST)[svara]
Användare:LittleGun: Ja, en mallparameter motsvarande parametern era i complex_date skulle lösa det du beskriver. Med den kan man välja mellan hur negativa årtal i en faktaruta ska visas. Mna kan välja mellan BC (vilket på svenska blir f.Kr.), BCE (för f.v.t.), B.P., year ago (dvs år sedan), kya, kA, mya, MA, osv, beroende på ämnesområde. Notera dock att på andra språk har dom struntat i att låta folk välja mellan BCE och BC. Mindre valmöjligheter leder till mer standardisering och konsekvens. Tomastvivlaren (diskussion) 9 maj 2020 kl. 13.24 (CEST)[svara]
Ja, mindre valmöjligheter leder till mer standardisering. I det här fallet finns dessvärre inte konsensus för annat än att båda ska få finnas men inte i samtidigt i samma artikel. Och, flera med mig tycker f.v.t/e.v.t kontra f.Kr/e.Kr är en tillräcklig viktig fråga för att det ska bevaras så. Då måste vi ha valmöjligheterna. Jag ifrågasätter då hellre specialintressevalmöjligheternas existen, som B.P och astromiskt år i en faktamall. Såna årsangivelser måste ju ändå förklaras i de flesta artiklar de används.--LittleGun (diskussion) 9 maj 2020 kl. 14.52 (CEST)[svara]
Astronomiska år så långt tillbaka är sällsynta i våra artiklar. Det är bara Halleys komets framträdande en gång före "år 0" jag stött på där.
Finns det tekniskt stöd för BP i Wikidata? Det är inget enkelt linjärt samband mellan julianska/gregorianska kalendrarna och de versioner av BP som finns, så jag skulle vara ytterst försiktig med att automagiskt "översätta" mellan dem. 62 osv (diskussion) 9 maj 2020 kl. 15.09 (CEST)[svara]
Du har rätt i att vill man visa b.p. eller b.p.cal. eller megaannum så bör man lägga in det på wikidata och inte konvertera i efterhand. Konvertering kan nämligen ge konstiga avrundningsfel när man tar hänsyn till wikidatas inställning för precision (sekel, millenium, osv), och konvertering till och från b.p. kräver kol-14-mätskala. Lösningen är att använda egenskap daterad ålder (P7584) (datatyp kvantitet), men många använder tyvärr istället datum för grundande eller skapande (P571) eller startdatum (P580) (datatyp tidpunkt) för astronomiska objekt, meteoritnedslag, förhistoriska arter och språk, mm. Den datatypen verkar inte tillåta andra tidsskalor än gregoriansk och juliansk tid. Enligt wikidata är jorden således "skapad" (ställningstagande för kreationism?) "4540 miljoner år f.v.t." (ställningstagande för sekularism?).
Nu kan man med mall:databox lägga in parametern era=sedan för att ersätta "f.v.t." med "år sedan". Ingen omräkning sker då, men vid stora årtal och låg precision gör det inget. Se t.ex. Homo antecessor, där åldern är angiven med P570. Märkligt att åldern i det fallet blir "1200000 år sedan", istället för "1 miljon 200 tusen år sedan", eller "1 200 000 år sedan". Lösningen skulle återigen vara att använda P7584. Databox är tänkt att ha enkel kod. Den har ingen egen avancerad formateringskod, som t.ex. modul:wikidata2 har, utan använder enbart wikidata-api:ets standardfunktion formatStatement(), kombinerat med efterhandsredigering med lua-funktionen gsub.Tomastvivlaren (diskussion) 11 maj 2020 kl. 15.55 (CEST)[svara]
Propertisen "använder (P2283)", hur ska den användas? I t ex hund (Q144) finns den, då med värdet(?) hundkorg och inga andra värden. Ska man där verkligen lista grejor som är förknippade med hundar: Hundskål, koppel, snusnäsduk, tuggben, grisöra, hundkex, hundgodis, hundflytväst, dragsele, hundgård etc? Jag tycker det verkar konstigt, men det kanske beror på vad parametern är tänkt att användas till.--LittleGun (diskussion) 11 maj 2020 kl. 03.29 (CEST)[svara]
På Proppens sida, har du en länk till "diskussion där egenskapen föreslogs". Där ser man hur man resonerade när proppen skapades. Det kan också finnas diskussioner på Proppdiskussionen och ibland på särskilda projektforum. Inte alla Proppar som finns är särskilt användbara. Det här ser ut som en av dem... 62 osv (diskussion) 11 maj 2020 kl. 08.30 (CEST)[svara]
Ok. Om jag fattade rätt, så ska man lista allt man kan tänka sig används av hundar. Vinge var exempel för fågel, så då ska till och med nos, tass och svans anges, vilket jag tycker haltar. Annars finns det poänger: Sotarens verktyg, superhjältens prylar, hockeyspelarens utrustning etc. Däremot tycker jag inte det ska användas per definition i en faktamall. Då måste avgränsningen vara skarpare. Hundar är en sån.--LittleGun (diskussion) 11 maj 2020 kl. 08.54 (CEST)[svara]
Okej, fast det här med kroppsdelarna är från diskussionen och exempel på dokumentationssidan. Så det är inte bara att någon gjort "fel", i så fall har det också tillåtits dokumenteras fel.--LittleGun (diskussion) 11 maj 2020 kl. 14.59 (CEST)[svara]
Vill minnas att det finns någon mer property som kan användas för kroppsdelar så det är lite därför jag är tveksam. En jakthund använder tveklöst luktsinne, syn och ben kanske, men jag vet inte... 62 osv (diskussion) 11 maj 2020 kl. 15.03 (CEST)[svara]
Sotaren använder tummen för att lägga in sin snus, men det är inte riktigt det som kännetecknar sotare. På samma sätt kännetecknar det fåglar att de (flesta) flyger med sina vingar och jakthundar att de utför sitt yrke med luktsinnet. Ja, det är som sagt inte alla proppar som är särskilt genomtänkta... 62 osv (diskussion) 12 maj 2020 kl. 18.37 (CEST)[svara]
Ja, och det gäller ju hela den här sidan. Jag gick till den dokumentation jag hittade, efter första tipset att det var bättre att gå till Wikidata, och tycker det finns poänger med propertyn; att lista alla attiraljer, men tycker det är för brett i en faktamall på Wikipedia. Jag har inget egentligt intresse att förändra propertyn. Det finns andra sammanhang, även på Wikipedia, en sån property skulle kunna funka. I andra typer av mallar till exempel. Jag tycker iofs det verkar fel att ha med kroppsdelar för t ex hund och flygfä (särskilt om det finns en sån property). Men låt gå, så länge man inte listar det för sotaren eller travhästen också. I det faktiska fallet hund var det uppenbart att den är lite använd. Endast hundkorg fanns med. Så det finns en del mognadsproblem också.--LittleGun (diskussion) 13 maj 2020 kl. 07.05 (CEST)[svara]
Nja, jag tycker att sidan fyller en klar funktion för att ställa en enkel fråga och få ett snabbt svar. Men om det inte finns ett klart svar, och frågan gäller mer än bara svenskspråkiga Wikipedias användning av Wikidata, då har denna sida inte rätt gemenskap för att skapa konsensus kring vad svaret borde bli. ♥Ainalidiskussionbidrag13 maj 2020 kl. 18.35 (CEST)[svara]
Ett problem här är att bilden kan vara viktig för artikeln och kan bytas bort på Wikidata. Om man tar bort bilden från resten av artikeln bör den i så fall låsas i mallen och bildtext och eventuell hänvisning till den i brödtexten kontrolleras. Ibland är det bättre att låta bilden finnas kvar och byta bild i mallen. --LPfi (diskussion) 14 maj 2020 kl. 10.57 (CEST)[svara]
Jag ser inte vad koden gör, men vad jag menade var ungefär som i den diff Salgo60 länkade ovan: "låsa bilden i mallen"/"hårdkoda in bilden" (hm, är det hårdkodning?), alltså lägga in bild och bildtext som parametrar i mallen. Däremot förenklades bildtexten i detta exempel, och det tycker jag inte man skall göra utan att verkligen överväga vilken bildtext som är bättre. --LPfi (diskussion) 14 maj 2020 kl. 15.46 (CEST)[svara]
med hårdkodning menar jag att det står i Wikimallen vilken bild som används och inte att det är dynamiskt från Wikidata
bildtexten korrigerade som jag hade tänkt mig se diff
LPfi: Det Nirmos kod gör, är att den kollar om bilden som hämtas från Wikidata är samma som en bild i artikeln. Är den det, gör koden så att bilden syns i Wikidataboxen bara. Den "deduplicerar", ett fantastiskt ord.--LittleGun (diskussion) 15 maj 2020 kl. 06.19 (CEST)[svara]
Så mycket förstod jag :-) Men jag förstår inte koden, så jag ser inte var och hur den gör det, och därmed inte heller vad som görs åt bildtexten. Jag har inte använt vare sig javascript eller mediawiki-apit, så det är naturligt att det är svårt. --LPfi (diskussion) 15 maj 2020 kl. 10.34 (CEST)[svara]
Koden letar upp första bilden i infoboxen, jämför URL:en med tumnagelbilder, och lägger till HTML-klassen "gadget-faktamallbiografiwd-hidden" på upprepade bilder. Sedan döljer MediaWiki:Gadget-FaktamallBiografiWD.css element med den klassen. Du kan se hur det här fungerar i t.ex Amber Rose (ingen bildtext) och Leila Aboulela (med bildtext).
Tyvärr skulle inte det här fungera som jag tänkte. I Djuröns naturreservat kommer även bildtexten från Wikidata, vilket är nytt för mig. Skriptet flyttar bara eventuell bildtext som redan finns i artikeln (på den upprepade bilden) till direkt efter bilden från Wikidata i infoboxen. Jag har inte skrivit någon kod för att upptäcka redan befintlig bildtext från Wikidata. För jag öht ska kunna göra det skulle de enskilda mallarna (t.ex Mall:Faktamall naturreservat WD) behöva lägga till användbar markup som kan identifieras av JavaScript på ett tillförlitligt sätt. Nirmos (diskussion) 16 maj 2020 kl. 12.16 (CEST)[svara]
@Nirmos: Nu lägger de mallar som använder modulen Wikidata2/Aux för att hämta bildtext från Wikidata till <span class="Wikidata_P18_P2096">...</span> runt den hämtade bildtexten. Är det något som du kan använda i finessen?
Jag tycker att i princip samma källa visas 2 ggr och inte är klickbar känns också fel
Skyddade områden, naturreservat, 18 december 2015, läst: 20 januari 2017, licens: CC0, (Källa från Wikidata)
Skyddade områden, naturreservat, 25 februari 2020, läst: 25 februari 2020, licens: CC0, (Källa från Wikidata)
som borde vara en och samma med en bra länk (verkar sakna bra länk för faktat dvs. man borde prata med Naturvårdsverket att fixa det)... kanske som detta
Skyddade områden, naturreservat, 25 februari 2020, läst: 25 februari 2020, licens: CC0, Källa Namn: Djurön NVR-id: 2001725
är nog bug i mallen och lite städjobb i Wikidata som behövs plus dialog med Natuvårdsverket
off topic jag har haft kort dialog 12 maj med Ulrika Domellöf Mattsson och Oskar Jonsson och det kommer en ny web med målgrupp skumma individer som oss "data för utvecklare" citat Ulrika
Vi kommer att testa en sida ”data för utvecklare” där vi ska försöka beskriva vår data och våra tjänster bättre och då är den här typen av återkoppling jätteviktig!
I Wikidatamallar, mallar som hämtar information från Wikidata, kan man "manuellt" bypassa värden genom att skriva parameternamn och värde i mallen. Man måste då veta parameternamnet. I rekommendationen för Wikidatamallar står att alla parameternamn ska skrivas ut. Då borde det vara OK att alla artiklar med Wikidatamall uppdateras med bot, så att alla parametrar skrivs ut i redigeringsläge. Eller så är det rekommendationen som ska ändras. Diskussion pågår på Malldiskussion:Faktamall biografi WD, håll den där. Det här är bara en blänkare.--LittleGun (diskussion) 15 maj 2020 kl. 05.58 (CEST)[svara]
Jag förstår problemet men tycker man borde funderar en runda till på denna rekommendation eftersom det är galet många parametrar... tror det var Tostarpadius som var en förespråkare för alla fält i mallen, kanske mall hjälpen skall kunna hittas enklare, där bör det finnas enkla exempel... - Salgo60 (diskussion) 15 maj 2020 kl. 08.08 (CEST)[svara]
Jag stödjer LittleGun i denna fråga. Det måste vara undandtagsvis man inte kan lösa problemet på Wikidata, och då borde man få anstränga sig lite och leta fram parameternamnet. Däremot behöver malldokumentationen i fler fall visa vilken parameter som motsvaras av vilken egenskap, exempelvis genom att förse dokumentationen med mall:Använder Wikidata.
I exemplet mall:Publikation är det särskilt viktigt att mallen som standard är tom, därför att där skrivs wikidatavärdena över även när paremetern sätts till en tom sträng. "Förlag = " gör alltså så att wikidatavärdet för förlaget döljs.Tomastvivlaren (diskussion) 15 maj 2020 kl. 17.28 (CEST)[svara]
Borde det inte ske enbart med noWikidata? Tom sträng är inget så hämta från wikidata. Men det är samma med geonames i infobox så det är hur det kodades. Maundwiki (diskussion) 21 maj 2020 kl. 14.19 (CEST)[svara]
Det här är väl en icke-fråga egentligen? Även för vanliga mallar (dvs sådana som inte använder sig av Wikidata) måste man veta namnet på parametern som man vill lägga till värdet för (det är lite enklare i Visual Editor). Och där kräver vi inte att alla parameternamn ska skrivas ut. Varför ska det vara olika regler? ♥Ainalidiskussionbidrag21 maj 2020 kl. 15.27 (CEST)[svara]
Funderade på att rulla tillbaka onödig off-topic trams. Men, du kanske är seriös och en tråd kan väl lika gärna göras här. Den funkar riktigt bra nu. Det som är synd är att den inte funkar på diskussioner och att det finns två sätt att redigera. Sen funkar den ofta dåligt med mallar, mycket oförklarat även där. Oftast är det mallens fel, men det är oftast bättre förklarat och exemplifierat på mall-sidan.
Men för att skriva en artikel är den riktigt bra, framförallt på att skapa källor. Och man slipper jobbig ref-kod, som kan göra texten närmast oläslig, i redigeringsläge. Fortfarande lägger jag oftast in bilder och kategorier med wiki-text, men det är bara en ovana. Det funkar bra med visual-editor också. Många skulle säga bättre.
Jag kan hålla med om att den sjösattes för tidigt, men det är nu många år sedan. Du borde ge den en chans innan du uttalar dig oresonligt. Du har en vana att ändra dig då.--LittleGun (diskussion) 22 maj 2020 kl. 08.04 (CEST)[svara]
"Den är ett otyg " jo men löser den detta problem så kan du väl använda den för det enbart. Känns som en enklare lösning än att ha massa botar som uppdaterar alla sidor utan parameternamnet du letar efter.... - Salgo60 (diskussion) 22 maj 2020 kl. 09.41 (CEST)[svara]
Tack, LittleGun! Jag skall sluta klaga på VisualEditor, även om jag nog aldrig kommer att kunna tänka om. Ett av de stora nöjena med att redigera här är just arbetet med koden. Vad gäller Ditt förslag, Salgo60, skall jag fundera på saken! Tostarpadius (diskussion) 22 maj 2020 kl. 10.30 (CEST)[svara]
Här krävs nog språkkunniga litteraturvetare för att reda ut begreppen. Den svenska artikeln ser ut att vara begränsad dels till filmvärlden och dels till en av de tre huvudpunkter som tas upp i den engelska artikeln som tar upp ett vidare perspektiv som en "litterär genre". Om de engelska, franska och spanska artiklarna beskriver samma sak får någon mer insatt bedöma.
Tack känns lätt att saker som detta som hamnar i gränslandet mellan Wikipedia/Wikidata ramlar mellan stolarna... jag har inte riktigt blivit trygg i detta med instans av (P31) vs. underklass till (P279) även fast du om jag minns rätt hade en liknelse med bilar för något år sedan...
det tröstlösa i denna ekvation är att vi måste börja ha dessa dialoger med andra vi kopplar wikidata till om det skall bli någon fart på länkade data, jag har gjort några försök utan framgång
om Wikipedias August Strindberg är samma August Strindberg som Kungliga Biblioteket har länk känns som det mest tragiska försöket...
Någon som funderat skapa, några som skulle behövas finnas, behövs dom på svenska, pushar WIkimedia Sverige detta till deras sammarbetspartners Naturvårdsverket, Bibliotek, museer?
På något sätt anges sagokung vara människa på Wikidata, (kanske denna: sagokung (Q6949213)). Jag vet inte hur, tror det är via någon sorts hierarkisk koppling. Det syns i mallen {{databox}}, till exempel här, i mallens första underrubirk: [16].--LittleGun (diskussion) 24 maj 2020 kl. 09.44 (CEST)[svara]
Enligt artikeln sagokung är det en person där det saknas samtida bevis på att han har funnits. Betydelsen av "saga" är inte att det är påhittat. Så kategoriseringen som människa blir då korrekt. Thoasp (diskussion) 24 maj 2020 kl. 09.54 (CEST)[svara]
Jag tror inte att man ska tolka saga i sagokung som sagan om Pippi Långstrump(s pappa) utan som en historieskildring.
Jag hade lite otur närjag tänkte. Även en fiktiv och mytologisk person kan såklart vara människa. I förhållande till jätte, alv, sjöjungfru eller cyklop. Så visst är Kapten Långstrump människa.
Brasklappen i Sagokung#Ordets_betydelse haltar betänkligt, och liknar egen forskning, från någon som vill att det ska finnas mer än spår av "Sanning" om sagokungarna (källan är SAOB, som inte nämner sagokungar, bara saga). "Saga" i det här fallet är naturligtvis Ynglingasagan och Eddan och dom. Ett bättre ord än saga kanske skulle vara "tradition". Per inledning: "är en påstådd forntida härskare, som endast är känd från relativt sena, ofta litterära källor." Men visst, vem är jag att säga emot Wikipedia, särskilt utan andra källor. Jag noterar att Erik Anundsson inte är ketgoriserad som man. Jag gissar att det beror på samma tankevurpa som jag gjorde. För visst kan även fiktiva figurer ha kön.--LittleGun (diskussion) 24 maj 2020 kl. 10.21 (CEST)[svara]
För det sistnämnda har vi kategoriträdet Kategori:Fiktiva figurer efter kön. Notera dock att vi inte har Kategori:Fiktiva män och Kategori:Fiktiva kvinnor som underkategori till Kategori:Män respektive Kategori:Kvinnor, antagligen för att vi inte har några underkategorier alls till dessa två kategorier. Det står även "Observera att artiklar om fiktiva personer inte skall läggas i dessa kategorier" på dessa kategorisidor.
Enligt Dick Harrison existerade sannolikt de vikingatida kungarna, men sagalitteraturens uppgifter om dem innehåller övernaturliga inslag, och är motstridig gällande ordningsföljden de regegerade, deras familjeförhållanden, mm. (Hittar inte källan där han skrev det.) "Fiktiv person" är därför inte ett helt korrekt namn om vikingakungarna, utan de står i en mellanställning mellan uppdiktad person och person verifierad i samtida källor. Kungar innan vikingatid är enligt honom mer tveksamma, inte minst deras släktskap tillbaka till de nordiska gudarna. Wikidata kallar sagokungarna "semi-legendary" king/person, vilket är ett bra begrepp. Sagalitteraturen skrevs ju ned efter flera hundra år. Några vikingakungar som har bekräftats av nästan samtida tyska munkar har också kommit att betecknas som sagokungor i wikidata. De motsvarar kungar som beskrivs i sagalitteraturen, men kan ha lite andra namn och andra uppgifter om dem, så en mappning till kungalängden kräver en viss tolkning.Tomastvivlaren (diskussion) 24 maj 2020 kl. 11.19 (CEST)[svara]
Ja, jag känner igen allt ovan svagt från gamla diskussioner. För mig är det inga konstigheter att en fiktiv figur kan vara både man och människa, men har förstått att det sticker i ögonen på en del. Men det kanske blir knas vid kategoriseringar och databashantering. Vad vet jag. Det är fortfarande lika fascinerande hur stökigt även synbarliga självklarheter blir när det handlar om detta. Jag är bortkollrad. Går det att lösa? Finns ens något att lösa?--LittleGun (diskussion) 24 maj 2020 kl. 11.24 (CEST)[svara]
Bakgrund till denna diskussion är att biografimallarna inte brukar accepteras i artiklar om sagokungar och gudar. Jag har nu istället lagt in mall:Databox för något hundratal sagokungar (främst vikingatida) och gudar, eftersom den mallen indikerar personernas status som sagokung eller mytologisk, vilket inte biografimallarna gör. Var det okej? Se t.ex. Ragnar Lodbrok och Oden. Om ni tycker det är en bra idé får ni gärna lägga in mallen i fler liknande artiklar. Man bör isåfall kontrollera att faktarutan säger samma som vår artikel - det skiljer ibland.Tomastvivlaren (diskussion) 24 maj 2020 kl. 11.40 (CEST)[svara]
Jag kom hit via en tråd på Bybrunnen som är ganska skeptisk tillmallarna:[17]. Det blir en del knepiga fakta: Ragnar Lodbrok, sysselsättning "lantarbetare". Han hade säkert en enorm egendom; men både jordägare och storbonde ses nog som anakronisitiskt även om det stämmer bättre.--LittleGun (diskussion) 24 maj 2020 kl. 11.50 (CEST)[svara]
Anledningen till att biografimallarna inte accepteras är att de är tämligen poänglösa. Vi vet t.ex. inte när personerna skall ha levat, detaljer kan motsäga varandra i källor o.s.v. vilket gör att det blir relativt få uppgifter som kan läggs i mallarna. Liknande gäller gudar. Mallar är bra på att presentera entydiga uppgifter, men när det finns osäkerheter, motsägelser eller olika tolkningar blir deras inlåsning ganska begränsande. Till detta kommer att uppgifterna ur Wikidata ofta blir förvrängda när samma egenskap skall kopplas till olika objekt och dessutom översättas. Det syns direkt att det inte är en människa som formulerat vad som står i dem.
Databox visar släktskap vilket inte är poänglöst och stämmer oftast med wikidataartikelns text. Ingen databoxmall anger när en gud skulle ha levat. Exakta årtal bör döljas från sagokungarnas faktarutor i de få fall de förekommer, men sekel borde kunna behållas. En uppgift bör raderas eller döljas från wikidata om artikeln säger att det finns motstridiga uppgifter på området. I vissa fall (när en mall innehåller flera tveksamma uppgifter, t.ex för att olika wikidataversioner säger emot varandra) bör man ta bort mallen, åtminstone tills det har redits ut. Du Andejons har gjort en bra faktacheck av när jag har lagt in databox, och backat tillbaka ett par gånger när jag inte har upptäckt att wikidata säger annat än artikeln. Tack! Har du tid att kontrollera fler fall? Skälet till att biografimallarna inte får användas för sagokungar är väl främst att de inte indikerar att en person är mytologisk utan kan ge intryck av att det är en verklig person. Tomastvivlaren (diskussion) 24 maj 2020 kl. 14.33 (CEST)[svara]
Du borde kunna se över själv. Det är tämligen uppenbart att Olof Björnsson (sagokung) inte hade något "medborgarskap", att delar av innehållet inte är översatt, att det inte är mycket poäng i att skriva ut språk, "människa", eller kön, att "sagokkung" upprepas, att "sysselsättning" och "befattning" är redundanta. Mer subtilt är att han egentligen inte hade något efternamn, men även den parametern och "förnamn" borde vara uppenbart att de är utfyllnad. "Familj" och "ätt" är olika saker. Att födelseorten är rent påhitt, och årtalen ren gissning, kan väl inte lika enkelt ses, men det finns problem nog i mallen ändå.
Och, nej, det går inte heller alltid att skriva ut familj. Olof (sveakung 852) förekommer bara i Ansgarsvitan. Det finns ingenting där som säger någonting om vem han skall ha varit släkt med. I princip allt vi vet om honom står redan i brödtexten, det som står i mallen var antingen fel eller poänglöst.
För den uppgiften angav wikidata bestämningen "Uttalandets natur" -> "Hypotes", dock utan källa. I dagsläget kan inte våra mallar visa sådana bestämningar. Jag sänkte rangen på det uttalandet, och det var bra att du tog bort mallen.Tomastvivlaren (diskussion) 25 maj 2020 kl. 13.10 (CEST)[svara]
"Hypotes" är ett för starkt ord. "Gissning" vore mer korrekt. Man kan lika gärna gissa att de var släkt på helt annat sätt, eller inte alls.
Det här är väl ett exempel på att vi inte måste ha bråttom? Att det är bättre att det blir rätt än att det går snabbt. Det finns inget egenvärde i att ha faktamallar i artiklar om fakta i mallen/boxen är missvisande eller felaktig, då klarar sig artikeln bättre utan mall/box, tills dess att en bättre mall kan läggas in (eller att tid läggs på att korrigera fakta, men då är det bättre att göra det på en gång istället för att lämna det felaktiga och hoppas på att Någon städar). //Vätte (diskussion) 25 maj 2020 kl. 01.12 (CEST)[svara]
Ja, det är lite min poäng med försiktighet. Samtidigt så är det när mallen används som den får uppmärksamhet, diskussioner startar och ändringar sker. Så någon sorts gyllene medelväg vore bra, och att den som lägger in mallen är beredd på att det kommer bli ändringar. Mycket av felaktighterna är egentligen Wikidatas, så det skulle kunna vara ett effektivt sätt att hitta och korrigera felaktigheter där. Men även för det behövs stöd, det är inte säkert att de som har koll på vad som borde stå, fixar eller har lust att hantera Wikidata. Och då blir frågan, hur mycket felaktigheter vill vi se på Wikipedia, bara för att Wikidata innehåller tveksamheter och felaktigheter innan de rättas och är det egentligen Wikipedias uppdrag?. Till en viss del tycker jag det är bra med korsbefruktningen, men risken är stor att många Wikipedia-användare, undertecknad inräknad, fjärmar sig från Wikidata. Notera att detta diskuteras lite på Wikipedia:Bybrunnen#Databoxar just nu också.--LittleGun (diskussion) 25 maj 2020 kl. 05.04 (CEST)[svara]
Innan jag la in databoxmallen i artiklar om specifika epidemier, pandemier, endemier och krig skapade jag först en wikidatalista på dessa ämnesartiklars diskussionsida, på engelska och/eller svenska, i något fall i artikelrymden. Jag m.fl. la därmed ned mycket tid på att först se över över wikidatainnehållet, och jag försökte harmonisera det med "statiska" listartiklar. Där uppstod det ingen kritik mot mallen, men wikidatalistan i artikelrymden var inte så omtyckt utan "frystes" så att den nu måste uppdateras manuellt. Detta kan vara ett bra arbetssätt i framtiden, innan vi lägger in wikidatamallar i en ny typ av artiklar. Jag borde ha gjort så även med asagudar och sagokungar.Tomastvivlaren (diskussion) 25 maj 2020 kl. 13.10 (CEST)[svara]
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)[svara]
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)[svara]
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)[svara]
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)[svara]
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)[svara]
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)[svara]
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)[svara]
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)[svara]
Vilken diskussion tänker du på som "hamnande i någon slutsats att vi ska visa allt"? I den diskussion om vilka av alla då nästan 4 000, idag mer än 5 100, Externa Identifierare som ska kunna dyka upp i Auktoritetsdata-rutan och om rutan alls ska finnas eller om den har överlevt sig själv, a.k.a. bananlådediskussionen, som var i juni 2019, nämndes visserligen MusicBrainz artist-ID (P434) i förbigående, men utan någon konklusion om att filtret för den identifieraren skulle ändras.
@Ascilto: Så bra, då var det nog bara något tillfälligt problem. När det gäller dödsplats (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ödsplats (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?
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)[svara]
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)[svara]
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).
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)[svara]
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.
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)[svara]
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)? ✍️GeMet 💬 den8 juli 2020 kl. 14.35 (CEST)[svara]
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)[svara]
Av de 1 879 objekt i Wikidata som har egenskapen Svenska Fotbollförbundet spelar-ID (P1238) är det 1 840 som använder det gamla formatet och 39 som använder det nya, se följande lista:
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.
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 spelar-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 spelar-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:
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 spelar-ID (P1238) från gammalt till nytt ID i Wikidata, men det är nog att hoppas för mycket.
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
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 spelar-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)[svara]
@Fredde 99: jag har försökt ta bort men tvekar om det blir bra.... och är värt mödan...
(P3188) se Wikidata:Properties_for_deletion#Nobelpris-ID_(P3188). Lesson learned det kan finnas använt någonstans och i fallet med (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
Riksdagens 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...
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 (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)[svara]
Magnus Manske har ett tillägg "Duplicate this item" som du lägger in i din commons.js.
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:
Det stämmer att "dirt" hämtas från Wikidata. Det beror på att någon har lagt in värdet jord (Q21152267) för egenskapen uppkallad efter (P138) i Wikidataobjektet jorden (Q2). Objektet jord (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 jord (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".
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)[svara]
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)[svara]
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)[svara]
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. ♥Ainalidiskussionbidrag11 juli 2020 kl. 23.07 (CEST)[svara]
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)[svara]
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)[svara]
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)[svara]
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.
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)[svara]
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)[svara]
(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. ♥Ainalidiskussionbidrag17 juli 2020 kl. 11.21 (CEST)[svara]
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)[svara]
(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)[svara]
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)[svara]
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. ♥Ainalidiskussionbidrag17 juli 2020 kl. 13.00 (CEST)[svara]
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)[svara]
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)[svara]
@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. ♥Ainalidiskussionbidrag17 juli 2020 kl. 21.12 (CEST)[svara]
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: 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. ♥Ainalidiskussionbidrag18 juli 2020 kl. 00.19 (CEST)[svara]
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).[svara]
@LittleGun: Du menar till Wikipedia-artikeln, eller hur?
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å. ♥Ainalidiskussionbidrag18 juli 2020 kl. 10.12 (CEST)[svara]
Ä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)[svara]
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? ♥Ainalidiskussionbidrag18 juli 2020 kl. 10.30 (CEST)[svara]
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)[svara]
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. ♥Ainalidiskussionbidrag18 juli 2020 kl. 11.46 (CEST)[svara]
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)[svara]
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. ♥Ainalidiskussionbidrag18 juli 2020 kl. 13.32 (CEST)[svara]
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)[svara]
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....
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)[svara]
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)[svara]
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.
(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. ♥Ainalidiskussionbidrag18 juli 2020 kl. 10.20 (CEST)[svara]
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)[svara]
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. ♥Ainalidiskussionbidrag18 juli 2020 kl. 10.58 (CEST)[svara]
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)[svara]
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)[svara]
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 (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.
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.
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)[svara]
@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)[svara]
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. ♥Ainalidiskussionbidrag25 juli 2020 kl. 09.45 (CEST)[svara]
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)[svara]
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. ♥Ainalidiskussionbidrag25 juli 2020 kl. 10.03 (CEST)[svara]
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.
@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.
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)[svara]
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. ♥Ainalidiskussionbidrag25 juli 2020 kl. 12.07 (CEST)[svara]
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)[svara]
Kategorierna Wikidatamallar och Mallar som använder data från Wikidata[redigera | redigera wikitext]
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. ♥Ainalidiskussionbidrag24 juli 2020 kl. 21.43 (CEST)[svara]
Nationell Arkivdatabas Referenskod (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 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 Arkivdatabas Referenskod (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...
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)[svara]
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.
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)[svara]
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)[svara]
@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).
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.
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)[svara]
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)[svara]
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.
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åetctog bort det.
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)[svara]
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)[svara]
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)[svara]
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)[svara]
det finns tankar att i Wikisource peka på WD objekt som är spännande länk så vi borde peka till Wikisource och gärna del av texten... jag har sett att Google numera i sitt sökresultat om man har Chrome läsare länkar in i texten och kör gul markering på det som är svar på frågan se video exempel länk som funkar i Google chrome - Salgo60 (diskussion) 11 augusti 2020 kl. 08.13 (CEST)[svara]
@Larske: Efter att ha mediterat lite över den här frågan så kommer jag till slutsatsen att det här är något som man skulle kunna justera i funktionen gettitle i Modul:Cite. mw:Extension:Wikibase_Client/Lua nämner en funktion som heter mw.wikibase.getSitelink som tillåter att man hämtar sitelink för en annan wiki. Frågan är bara vad den andra parametern ska vara? svwikisource? 62 osv (diskussion) 11 augusti 2020 kl. 21.29 (CEST)[svara]
Ja, nästan. Det ska vara en sträng, alltså 'svwikisource'. Du kan använda funktionen mw.wikibase.getGlobalSiteId() i en testmodul på svenskspråkiga Wikisource för att få fram id för det projektet. Jag använde modulen Hej världen som används i en tråd på en arkiverad Mötesplatsen-sida för att inte behöva spara någon redigering, bara förhandsgranska.
Funktionen mw.wikibase.getSitelink ger dock bara det som är efter sista / i länken. För att kunna göra en klickbar länk behöver du komplettera med https://sv.wikisource.org/wiki/. De borde väl finnas nåt "prefix" man kan använda, men jag hittar inget för svwikisource på sidan en:Help:Interwiki_linking#Prefix_codes_for_linking_to_Wikimedia_sister_projects.
Prfixet för interwiki till Wikisource är vanligen s:, men pga S:t Petersburg mfl är det src: istället från svenska Wikipedia. Går det att få fram vilka projekt som det är vanligast med källhänvisning till Wikisource enligt modellen p248:objekt med wikisourcelänk. (Wikisource ska normalt vara ensamma i sitt objekt.) 62 osv (diskussion) 12 augusti 2020 kl. 08.08 (CEST)[svara]
OK, jag testade med "src" i mitt inlägg ovan och det gick ju bra. Det skulle behövas en översättning av Helpsidan om interwiki linking till svenska. Fast informationen finns på Wikipedia:Interwikilänkar#Länkar_till_systerprojekt som jag hittade via interwiki från den engelska hjälpsidan via den danska sidan. Lite rörigt med interwikilänkarna mellan dessa sidor.
@Sextvåetc: Hm, att Wikisource normal ska vara ensamma i sitt objekt verkar inte efterlevas helt. Värst är Bibeln (Q1845) där det finns 300 andra projekt som är länkade till samma objekt som de 37 Wikisource-projekten.
Länk till fråga som ger en lista på (just nu 261) Wikidataobjekt med koppling till Wikisource och samtidigt koppling till minst ett annat projekt.
I frågan ovan har jag ändå exkluderat alla sidor med ":" i namnet som till exempel mallar och kategorier där den regel du beskriver kanske inte gäller.
Att bibeln är värst, är nog helt i sin ordning. Regeln på Wikidata är att sidor som anses vara Wikisource-grensidor (särskild sorts grensidor som bara finns på Wikisource) kan och bör länkas till Wikipedia. Bland dessa återfinner du säkert just bibeln. 62 osv (diskussion) 12 augusti 2020 kl. 09.29 (CEST)[svara]
Tackar. Jag har ett litet Wikidata "projekt" att koppla ihop inträdestalen i Svenska Akademin med person och övertyga Litteraturbanken/Svenska akademin att börja fundera över länkade data exempel SPARQL fråga och där visar det sig att Wikisource är en bra källa - Salgo60 (diskussion) 12 augusti 2020 kl. 12.42 (CEST)[svara]
Finns nu en Chrome browser plug-in version Beta d:Wikidata:Entity Explosion/ GITHUB som gör att man kan visa "allt" från Wikidata även från många externa websidor/källor, se exempel Bygdeband Wikidata P6192. Kanske ett sätt att locka in folk till sv:Wikipedia?
Larske gjorde en snygg variant att istället för dagens mall:Auktoritetsdata visa extra allt se test (ru:Wikipedia kör liknande variant se Carl Larsson), vi har Mall:Taxonbar som visar mycket från Wikidata om växter djur, vi har haft oändliga diskussioner om auktoritetsdata där ena ståndpunkten är "varför har vi den" och den andra ser den som en kvarleva då folk visste bara att information fanns på bibliotek. Wikimedia Sverige Joppe pratade på ett årsmöte om Wiki världen som ett informationsnav kanske detta är ett steg i denna riktning där Wikidata visas i webläsaren ... Som sagt version 0.1 men utvecklaren verkar vara pigg. Vi har även några raketforskare som lyfter in Riksdagens SFS:er motioner etc. i Wikidata och där skulle man kunna tänka sig att Wikidata ger svar på vilka motioner som skrivits i ämnet se exempel tweet hur vi med d:Wikidata:Entity Explosion redan mha Wikidata kopplar ihop twitter och Riksdagen, hur vi redan idag kan skapa SPARQL frågor vilka Riksdagsmän som skrivit motioner ihop 2018 länk - Salgo60 (diskussion) 15 augusti 2020 kl. 11.35 (CEST)[svara]
Jag lade till {{Faktamall biografi WD}} i artikeln om Rolf Alsing. Han var far till Adam Alsing som gick bort i våras. I mallen står "Barn: Adam Alsing (f. 1968)", det borde vara "Barn: Adam Alsing (f. 1968 - d. 2020), eller finns det någon anledning att bara ange födelseår som jag missar? Jag kollade Lill-Babs, Anki Liden och Arne Weise, som alla har manuella faktarutor och wikipediarelevanta barn. Där anges inte födelseåren för barnen alls. Kanske är det så vi ska göra med WD-mallen? Personligen tycker jag levnadsdata är att föredra, men då ska den vara komplett.--LittleGun (diskussion) 17 augusti 2020 kl. 12.39 (CEST)[svara]
Föräldrar är (vanligen) med när barnen föds. De är (inte alltid) med när de avlider. Därför ser jag inte riktigt poängen med att generellt ha med dödsåret för barnen i en faktamall för föräldern. 62 osv (diskussion) 17 augusti 2020 kl. 12.43 (CEST)[svara]
Det tycker jag var en konstig motivering. Och konstig kodifiering. Det är väl inte därför födeseår är med, det är väl för att förtydliga vem, som en särskiljnjng? Det ser fel ut när bara födelseåret är med på en avliden. Sen var det inte vanligt i Sverige att fadern var med vid förlossningen på 60-talet. Det var möjligen vanligare när det sköttes på gården. Beror det på en sådan kodifiering tycker jag absolut att all levnadsdata för barn/släktingar ska bort ur mallen.--LittleGun (diskussion)
Det skulle jag aldrig ha gissat, och det skulle verkligen förvåna mig. Det här är ett typiskt sätt att särskilja: Per Persson (f. 1968), Per Persson (f. 1902, d. 1998), Per Persson (1902- 1998). Som händelse beträffat är väl att förlora ett barn otroligt starkt, och borde i så fall verkligen inte uteslutas för att båda föräldrarna förmodligen var frånvarande vid tillfället. Då tycker jag absolut att levnadsdata ska vara med igen.--LittleGun (diskussion) 17 augusti 2020 kl. 13.22 (CEST)[svara]
Vi brukar väl aldrig någonsin skriva ut särskiljningar i artiklar? Gör vi ens det när vi har två barn med samma förnamn? (Jag har två morbröder med exakt samma namn. Ja, de har exakt samma föräldrar.)
En mall konstruerad som denna klarar inte att avgöra om Rolf var vid liv när Adam avled. Det är inte omöjligt att skapa en mall som klarar detta, men inte såsom mallen är konstruerad nu. Det kräver något mer likt {{Ortsfakta WD}}, där mallen sätts ihop i LUA, istället för i wikikod. 62 osv (diskussion) 17 augusti 2020 kl. 13.50 (CEST)[svara]
Om det stod ÅÅÅÅ– i stället för f. ÅÅÅÅ skulle det vara klart missvisande för avlidna personer, men f. ÅÅÅÅ tycker jag flyger.
Det kan nog finnas flera syften till att skriva ut födelseår och möjligen även dödsår för barnen. Normalt är dock dessa uppgifter bara ett klick bort.
Önskemålet om både födelse- och dödsår har framförts tidigare och jag påbörjade för något år sedan en lösning till det som jag dock inte har sjösatt än. Tror inte att den ännu fungerar för mer än ett barn. Så här skulle det se ut på raden Barn i faktarutan i artikeln om Rolf Alsing:
För många personer, många har längre namn än Adam Alsing, skulle det innebära att det skulle krävas två rader per barn, även om dödsdatum är förkortat till bara år, vilket gör infoxen längre, speciellt för personer med många barn. Vi har artiklar där denna mall används och där den biograferade personen har 10 barn.
Ni får diskutera vidare vad som är lämpligt. Att inkludera dödsår eller ej. En variant är förstås att inkludera dödsåret för barn som avlidit medan den biograferade person levde, men det skulle nog se lite konstigt ut om dödsår fanns angivet för något men inte för alla barn som avlidit.
För mig är det solklart: Antingen både födelseår och avliden år, eller inget. Inget verkar ha varit brukligt vid manuell mall. (Se Lill-Babs, Anki Liden, Jeanette Bonnier och Arne Weise). Eftersom inget verkar lättast, kör på det, så kan vi införa det på bästa sätt senare. Just nu ser det bara fel och förvirrande ut i Rolf Alsing artikeln. Kodifieringen som beskrivs ovan köper jag inte som självklar.---LittleGun (diskussion)
Förslag på förändringar av mallen {{Faktamall biografi WD}} tas lämpligen upp på malldiskussionssidan som förmodligen bevakas av andra som har åsikter om hur faktarutan som den mallen skapar bör se ut.
Det stämmer att det inte är så vanligt att levnadsperiod anges för barn i mallen {{Faktamall biografi}}, men det förekommer:
Länk till fråga som listar några artiklar som använder "icke-WD-mallen" {{Faktamall biografi}} och som har födelsedatum i angivet för barn.
Tack för sökning! Vid manuellt tillagda med fördelseår så står genomgående även avliden år om det är tillämpligt, vilket märks tydligt i sökningen. Tydligast i Biden som har förlorat en son, medan de andra barnen lever. Jag lägger en blänkare på mallens diskussionssida och Bybrunnen.--LittleGun (diskussion) 17 augusti 2020 kl. 14.57 (CEST)[svara]
Och sökningen visar att avliden år läggs in även om barnet gått bort flera år efter föräldern. Vilket också är klokt, även om det verkligen innebär att föräldern inte var med.--LittleGun (diskussion) 17 augusti 2020 kl. 14.59 (CEST)[svara]
Observera att sökningen inte är komplett, den ger bara några exempel. Notera att alla dessa exempel på barn förmodligen bryter mot den regel som finns på malldiskussionssidan om att namn på barn endast ska anges då dessa är relevanta för egna artiklar. Men som sökfrågan är formulerad letar den bara fram artiklar med olänkade, alltså vare sig rödlänkade eller blålänkade, barn. Kanske den regeln är lite för sträng om den medför att namnen på drottning Silvias syskon inte ska anges i artikeln om Walther Sommerlath.
Kompletterar med några exempel på artiklar med den manuella mallen och där det finns åtminstone ett (röd- eller blå-)länkat barn och där födelseår finns angivet.
Ingen funktion i objektet som det ser ut idag skulle kunna göra att Modul:Wikidata2 väljer ut specifikt den horisontala.
Det finns flera möjliga vägar att sortera fram önskvärda och sortera bort oönskade claims. Men det är ganska tomt på qualifiers i det här exemplet. Jag har själv uttryckt önskemål om att sortera fram/bort vapenflaggor på något sätt. Här ser det ut att vara ett liknande problem.
När det gäller tyska kommuner finns det ett antal som har både 2 och 3 värden på egenskapen bild av flagga (P41). I en del fall har något av dessa givits Rekommenderad rang, som till exempel Wolfsburg, medan det i andra fall blir mer än ett "napp", som till exempel Seesen.
Länk till fråga som ger en lista över (just nu 137) objekt som är instans av (P31)kommun i Tyskland (Q262166) (eller undergrupp därtill) som har mer än ett värde på egenskapen bild av flagga (P41) med "bästa rang" och som alltså kan ställa till problem om man bara vill ha en flagga och inte nöjer sig med den första som Wikidata returnerar.
Tro mig, jag har sett långt galnare förslag än så i diskussioner på WD. Jag försöker lista vilka värden "användning" som "qualifier till P41" kan tänkas ha. Det hade varit praktiskt om det hade varit möjligt att ur filnamnet extrahera storleken på filen och lägga in vilkor som "if höjden > 2x bredden then skip". 62 osv (diskussion) 17 augusti 2020 kl. 20.50 (CEST)[svara]
Kanske "Hissflagga" eller "Vertikal hissflagga" i P366? Jag frågade den som gör flaggorna på commons men fick svar från någon annan att ta upp det på wikidata. Beskrivning i mediabeskrivning (P2096)? Men vad som kan anges för att skilja olika typer av flaggor bör troligen komma från ett begränsat antal (fördefinierade?) benämningar. Filnamnet på Vertikal hissflagga är Banner... se Banner (Fahne). Kanske titta på namnet men det kan vara osäkert om inte namngivningen alltid följer samma mönster. Maundwiki (diskussion) 18 augusti 2020 kl. 15.40 (CEST)[svara]
Efter att ha sett @Larske:s lista över hur "användning" används, (mest örlogsflagga) så är jag optimistisk att den property går att använda. Ange användning:banner (fahne) som qualifier, så lägger vi in ett undvikande av sådana i vårt 9anrop härifrån. 62 osv (diskussion) 19 augusti 2020 kl. 08.16 (CEST)[svara]
För att göra detta behöver vi väl införa parametern avoidqualifiervalue (som komplement till avoidqualifier), vi vill väl inte undvika alla bild av flagga (P41) som har något värde för egenskapen användning (P366), men den parametern kan nog komma till pass även i andra fall.
Exakt vilket objekt menar du med "banner (fahne)"? Jag antar att det är vapenflagga (Q806865).
@Maundwiki: Den bugg jag försökt fixa är att om man försökte konvertera enhetslösa siffror till något med enhet, så kom det inget felmeddelande. Det som hände i Tyskland var ett missförstånd av vilka delar av koden som gjorde vad. Jag vet ännu inte om jag lyckats lösa hela den buggen, men vi är på väg... 62 osv (diskussion) 28 augusti 2020 kl. 20.08 (CEST)[svara]
@Maundwiki: Det var mallen {{Ortsfakta Tyskland}} som inte klarade av att maska ut population_note korrekt. När värdet för folkmängd (P1082) var (till exempel) 0 blev det fel. Nu har jag gjort så att det felet inte längre uppstår. Hojta till om du ser någon annan oönskad bieffekt.
En helt annan bugg relaterad till Ortsfakta Tyskalnd är att om du hämtar ytan från Wikidata, så har du fortfarande möjligheten att själv välja vilken enhet du får ut. Det som hämtas från Wikidata är alltid km2, men du kan välja att manuellt skriva m2 och få en faktor 1000000 fel. 62 osv (diskussion) 29 augusti 2020 kl. 09.13 (CEST)[svara]
I Mall:Publikation i artikeln Kunstkritikk fick jag just uppräkningen "Norska, Danska, Svenska och Engelska" av Wikidata, för tillfället manuellt korrigerat till "Norska, danska, svenska och engelska". Eftersom andra uppräkningar, t.ex. sysselsättning, bara har versal på första ordet så gissar jag att detta är engelskinfluerat och att det borde vara lättåtgärdat. Gäller det bara den mallen eller kan det behöva rättas till på andra ställen? Förbätterlig (diskussion) 5 september 2020 kl. 13.40 (CEST)[svara]
Fixat Mallen är ändrat så att endast det första av flera värden på egenskapen språk får versal begynnelsebokstav. Tack för påpekandet.
Jag känner mig ganska vilsen på det här med Wikidata och behöver lite hjälp. Jag har skapat sidan Bandcamp och tänkte så klart interwiki-länka den. Men om jag använder mig av verktyget så nekas jag med denna motivering:
You do not have the permissions needed to carry out this action.
Den här sidan har skrivskyddats för att förhindra redigering eller andra åtgärder.
När jag försökte koppla Bandcamp (Q545966) till svwp-artikeln Bandcamp gick det bra. Det är riktigt att objektet har ett skrivskydd, men det ska bara gälla oinloggade och nya användare.
Jag dubbelkollade tre gånger att jag var inloggad även på Wikidata och testade att logga ut och in. Mycket märkligt. Jag får väl återkomma om problemet uppstår igen. Tack för din hjälp! -Blåmes[d]6 september 2020 kl. 07.30 (CEST)[svara]
Tack, nu ser jag att för att bli en "Autoconfirmed user" behöver man ha haft en användare i över fyra dagar och gjort fler än 50 Wikidata-redigeringar. Det verkar som jag gjort färre än 50 (trots att gjorde min första Wikidata-redigering 2015) och därför kan jag inte redigera semi-protected articles. Kan ju tycka att det är lite märkligt att man som Wikipedia-användare inte kan lägga till interwiki-länkar utan att ha gjort så många redigeringar på Wikidata. Jag vet visserligen inte hur vanligt det är med skyddade artiklar. -Blåmes[d]6 september 2020 kl. 10.32 (CEST)[svara]
Då söker jag lite Wikidata-hjälp igen. Jag hoppas att ni står ut, och förstår att det är mycket att lära sig. Den här gången handlar det om kategorier. Jag har nu skapat en hel del underkategorier till Kategori:Orter i Delstaten Mexiko för att göra det lite mer översiktligt och fler skall det bli. De skulle dock behöva Wikidataobjekt. Men hur bär jag mig åt för att skapa sådana, och vilka "properties" skall jag använda mig av? Känn dig er fria att demonstrera på en av kategorierna så kan jag följa ert exempel och själv göra kvarvarande kategorier efter det. Stort tack på förhand ifall någon orkar hjälpa till!
Rent tekniskt betyder nog objekt om kategorier inte mycket för Wikidata som projekt. Men lägg gärna in åtminstone någon etikett på ett större språk om du kan. Engelska eller spanska är nog de bästa här. –62 osv (diskussion) 11 september 2020 kl. 18.24 (CEST)[svara]
@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?
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)[svara]
Vad ser du för användningsfall för dessa kategorier?
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)[svara]
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)[svara]
Import av källor (vetenskapliga artiklar) som är egna objekt på Wikidata[redigera | redigera wikitext]
Wikidata innehåller objekt för många vetenskapliga artiklar som importerats från Pubmed och andra liknande databaser. Bland dessa finns även dödsrunor som är tacksamma att använda som källa för biografisk information. Det är enkelt att referera till dem på Wikidata genom att ange t.ex. anges i (P248) -> (Q47617705). Majoriteten saknar dock etikett på svenska, vilket verkar leda till problem när källan importeras till svenska Wikipedia, se t.ex. Bo Vahlquist, då ingen titel alls visas. Skulle det gå att fixa? Det känns onödigt att behöva manuellt lägga till titel på alla referensnoder. Belteshassar (diskussion) 17 september 2020 kl. 22.04 (CEST)[svara]
Jag ser den engelska etiketten för artikeln i referensen med nummer 4. Var är det du menar att "ingen titel alls visas"?
Tillägg: Om du menar att den vetenskapliga artikeln inte visas som källa för födelsedatum (P569) (och dödsdatum (P570)) där den är inlagd som anges i (P248) så beror det på att det finns ett annat uttalande för födelsedatum (P569) som någon har givit en Föredragen rank (Preferred Rank). Det beror antagligen på att datumet endast är angivet som årtal där man anger (Q47617705) som källa, medan de anges som kompletta datum i det uttalande som har givits föredragen rang och som har en annan källa. Mallen är konstruerad så att den normalt endast redovisar uppgifter som har "best rank" så i detta fall redovisas bara de data som har Föredragen rang.
Jag drog lite för snabb slutsats ser jag nu. Det var referens nummer 3 som jag reagerade på, men det är ju inte artikeln, utan inlägget i pubmed så det har nog ingen titel. Däremot borde kanske inte den visas i källförteckningen alls eftersom den bara är källa till metadata om källan? Belteshassar (diskussion) 17 september 2020 kl. 22.56 (CEST)[svara]
Min fundering är att vi kan skriva Ulf Örnkloo och få en röd länk men borde vi inte när vi vet att ett Wikidata objekt finns Ulf Örnkloo (Q47508101) kunna spara denna info i mallen ex.
Tanken är då en artikel skapas så skall det gå enklare att hitta dessa referenser plus att vi har mer info i vår Wiki och inte behöver starta från 0 och leta kopplingar...
Lite jobbigare variant på detta är att vi skapar objekt för varje artikel i SBL i Wikidata och där har kopplingen till den WIkidata författare som finns -->
skapa WD objekt för alla artiklar
göra om WD mallar så dom klarar av detta
Syntax typ
{{SBL|Q445566]}}
där Q445566 skulle vara SBL artikeln som motsvara 11824
@Salgo60: Att göra WD-objekt av alla artiklar i SKBL är naturligtvis möjligt, men frågan är om en sådan artikel är "notabel" annat än genom sitt artikelsubjekt. Men som ett "referensobjekt" skulle det kunna vara befogat. Jag lämnar dock den varianten tills vidare.
Att få rödlänkar till författare som ännu ej har någon svwp-artikel att ändå leda till WD-objektet för författaren skulle kunna göras med en liten utökning av mallen {{ILL}}. Jag har gjort en testmall som fungerar som ILL, men där man kan ange wd som värde för parametern för språkversion. Så länge författaren inte har någon svwp-artikel är länken röd och man blir hänvisad till (wd) som länkar till WD-objektet. När författaren senare kanske har en svwp-artikel blir länken blå och (wd) försvinner.
Snyggt det var ju ännu tydligare.... och snyggt att mer info finns jag har sista veckan givit lite mer omsorg till SKBL och där är författarna välmeriterade men få har egen Wiki artikel och SKBL är lite dåliga på att koppla dom till Auktoritetsdata....
"notabel" allt kan ju diskuteras men tycker mig se mer och mer fördelar med enskilda objekt för artiklar, kopplade till författare... tendensen just nu är att Högsta domstolsdomar, motioner, SOU.... flyger in och verktyg som Scholia fungerar bäst med författare och artikel separerade exempel Anna Lind och vilka motioner hon skrev - Salgo60 (diskussion) 26 augusti 2020 kl. 14.06 (CEST)[svara]
Jag kör en liten test med SKBL och synkar Wikidata med deras data. Gissar att detta är som mycket annat ett projekt som klingar av om inte nya pengar kommer in men det intressanta är hur snabbt/enkelt det är att synka digitala källor... om dom vi pratar med gör rätt....
denna månad har dom producerat 50 nya artiklar
målet är att dom snart har Wikidata Q nummer i sitt data --> Wikidata blir en referenspunkt att vi "pratar" om samma saker och då skall inte bara kvinsen matchas utan även deras organisationer och andra kopplingar....
Fråga förhoppningsvis inspierarar detta även andra att bli mer digitala och leverera 5 star data dvs. Länkade data borde vi inte fundera över att ha en plattform/ramverk för saker som detta? Gissar att Riksdagens motioner och Högsta domstolens domar kommer att fortsätta att produceras och även dom behöver flyttas in i Wikidata och kanske dyka upp i Wikipedia artiklar på ett lite mer kontrollerat sätt...
ser vi på SKBL där idag vi det skapas 60 biografier per månad och snart förhoppningsvis skall börja synka "same as" organisationer/föreningar/arkiv så blir detta en större utmaning...
a) vi har idag rel "enkla" egenskaper som Riksdagens motioner där vi vet att objektet föds hos Riksdagen och kan köras rakt in i Wikidata eftersom kopplingen till Riksdagsperson även finns i Wikidata och inte behöver handpåläggning
b) vi har SKBL som säger att dom skall göra jobbet och ha Wikidata Qnummer hos sig --> också rel enkelt om objektet redan finns
b-1) får vi inte objekten med Q nummer behövs matchning eller skapa nya objekt plus vi måste ta ställning till om alla objekt som skapas hos extern källa är relevanta i Wikidata
Min tanke med "ramverk" är att vi istället för att uppfinna hjulet varje gång vi vill göra lite mera avancerad ihopkopplingar så bör vi ha något som Mix-and-Match där externa kopplingar
i) slussas in med förslag på match eller helt manuell ihopkoppling/nyskapande avobjekt....
ii) att vi gör detta på liknande sätt för olika egenskap och att lösningen inte blir helt personberoende utan vi försöker bygga upp ett ramverk som fungerar på samma sätt för alla egenskaper
där Aner som är en Riksdagskvinna enklare kopplas in medans Backström kanske behäver lite omsorg även fast objekt är skapat i Wikidata så finns det en stor "mismatch" mellan den JSON SKBL levererar och vilka "awards" som finns i Wikidata. Är hennes utbildning "Fackskolan för huslig ekonomi" samma som Fackskolan för huslig ekonomi (Q10493499)
min lite ostrukturerade tanke är att med ett ramverk så kan vi skapa att "göra listor" på ett mera strukturerat sätt och se vilken backlog som finns att ta ställning till för skapa nya priser / skolor / eller koppla ihop 2 domäner ....
Skulle de gå att göra en mall för att hämta kordinaterna från wikidata och presentera "display=title"? Om inget finns i wikidata prsentera inget men mall ska kunna finnas i artiklen. Skulle P17 kunna fylla i "region:P17_type:landmark". Möjligheten ha annat än landmark som en parameter. Användning skulle vara t.ex. i Hokvinden. Maundwiki (diskussion) 23 september 2020 kl. 21.34 (CEST)[svara]
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)[svara]
@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)[svara]
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)[svara]
@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.
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 ' i stället för Officiell webbplats' och Tillkomst 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.
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.
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
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)[svara]
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.
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)?
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)[svara]
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: 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)[svara]
@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 har del(ar) (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 har del(ar) (P527), som i exemplet ovan, eller på något annat sätt?
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)[svara]
I väntan på en sådan supermall kan man ju alltid fuska, så här.
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)[svara]
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.
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)[svara]
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)[svara]
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.
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.
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.
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)[svara]
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.
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)[svara]
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)[svara]
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)[svara]
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)[svara]
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)[svara]
Gatuadress är i stort sett alltid viktig om objektet har en gatuadress (huvudadress). Att visa adressen på alla språk är dumt, den ska bara visas på svenska. Då går det att få att fungera: Huvudadress ska finnas, finns det ska den finnas på svenska, då ska den skrivas ut. Normalt sett är huvudadress den adress som existera (det finns mer eller mindre krystade undantag, och går det inte att få fram en huvudadress, ja då finns det ingen adress på svenska. Finns det adresser på olika språk går det alltid att få fram en vettig svensk adress. Vissa länder har flera adresser på olika språk. Dåkan vis kriva en av dessa på svenska eller båda om det är vettigt. Det finns säkert undantag. Då hanterar vi dom som undantag.) Per diskussion ovan är det tekniskt/politiskt hopplöst. LittleGun (diskussion) 24 september 2020 kl. 18.41 (CEST)[svara]
Håller icke med gatuadress känns ointressant jag är mer intresserad av deras sociala kontaktytor som twitter/Facebook. Koordinat med infälld karta räcker. Jag har sett att vissa språk har en expanderar knapp i sina mallar det kanske kan vara ett sätt att gömma viss info men att den ändå finns nära...
Jag skapade artikeln Pseudolån. Sedan skapade jag Q100154404 och anslöt artikeln till Q100154404.
Nu ser jag att jag skulle ha kunnat använda och utveckla Q670161 i stället. Jag såg inte Q670161, för det skapades utifrån den tyska artikeln Pseudoentlehnung.
@Jan Arvid Götesson:Fixat Man slår ihop objekt på Wikidata, man raderar de inte (så länge de inte är rena okynnesobjekt såklart). Om du går in på Inställningar → Finesser så kan du slå på verktyget Merge. Då kan du göra detta själv i framtiden. Tänk dock på att ett nyare objekt i regel oftast skall slås ihop med ett äldre och att verktyget bara skall användas i solklara fall. EstrellaSueciadiskussion, 7 oktober 2020 kl. 23.56 (CEST)[svara]
I artikeln om Ruth B. är födelseorten Edmonton skriven med främmande tecken, inte det latinska alfabetet, i faktamallen. Hur kan jag åtgärda det? /Ariam (diskussion)
Fixat Det var en felaktig kod för att undvika anakronismer som spelade ett spratt. Objektet Edmonton (Q2096) har egenskapen namn (P2561) på språket cree som slank igenom filtret eftersom det namnet gällde vid födelsedatum (P569) för Ruth B (Q22056665). Nu har jag ändrat koden så att endast namn (P2561) på språk med någon av koderna 'sv' (svenska), 'en' (engelska) eller 'mul' (flera språk), tillåts att visas i faktarutan och, som tidigare, enbart om det inte har något startdatum (P580) som är senare, eller slutdatum (P582) som är tidigare, än den aktuella jämförelsetidpunkten som i till exemplet är personens födelsedatum (P569).
Fixat Hittar du något annat på Wikidata som ser lika matnyttigt ut, är det nu bara att slå ihop dem. 62 osv (diskussion) 13 november 2019 kl. 16.08 (CET)
Deryni (diskussion) 24 april 2020 kl. 19.19 (CEST)
--Paracel63 (diskussion) 6 maj 2020 kl. 22.49 (CEST)
Sotaren använder tummen för att lägga in sin snus, men det är inte riktigt det som kännetecknar sotare. På samma sätt kännetecknar det fåglar att de (flesta) flyger med sina vingar och jakthundar att de utför sitt yrke med luktsinnet. Ja, det är som sagt inte alla proppar som är särskilt genomtänkta... 62 osv (diskussion) 12 maj 2020 kl. 18.37 (CEST)
![[7]](https://en.wikipedia.org/wiki/Cringle#/media/File:Hals_(Gennaker).jpg){kind=link}
