Moduldiskussion:Kommunfakta Norge WD

Sidans innehåll stöds inte på andra språk.
Från Wikipedia

P7903/P7904[redigera wikitext]

@Larske: Just hittat fick område från (P7903) och avyttrade område till (P7904). De används som qualifiers till betydande händelse (P793) med värde gränsjustering (Q28953942). Jag har gjort så att P7903/4 kan hämtas, men Modul:Wikidata2 behöver ett par justeringar till. För det första ska data bara hämtas om värdet av PXXX är ett specifikt eller en grupp av värden. För det andra behöver preferqualifier tillåta att man lägger in "P7903,P7904" som värde. Vi har redan en sådan funktion i preferqualifiervalue. Är det något du kan hjälpa till med? 62 osv (diskussion) 20 juli 2020 kl. 08.49 (CEST)[svara]

För min förståelse av problemet, kan du ge ett exempel på vilket "specifikt eller grupp av värden" som PXXX måste ha i ett konkret exempel. Och kanske också några exempel på värden som skulle kunna förekomma för PXXX som du inte vill hämta. Om ett fylke eller en kommun har en betydande händelse (P793) av typen gränsjustering (Q28953942), vill man då inte lista alla värden på fick område från (P7903) respektive fick område från (P7903) i faktarutan?
Är det värdet som du vill filtrera på eller är det värdets P31, det vill säga för ett fylke vill du bara lista fick område från (P7903) som också är ett fylke?
Preparera gärna en version av Wikipedia:Wikidata/Sandlåda för Wikidata (Q4115189) med exempel på betydande händelse (P793) som har fick område från (P7903) och/eller avyttrade område till (P7904) och tala om vilket resultat, vilken delmängd av värdena och vad som karaktäriserar den delmängden, du vill kunna få genom ett modulanrop till Wikidata2.
--Larske (diskussion) 20 juli 2020 kl. 09.27 (CEST)[svara]
Nja, det jag vill sortera bort är andra typer av betydande händelser än gränsjusteringar. Om vi tar Japan (Q17), så har den allt från Olympiska spelen till Fukishima-olyckan som betydande händelser. Jag är bara intresserad av "P793:gränsjusteringar". Sedan kan flera objekt ibland användas för samma sak, men med mindre betydelseskiftningar. Så om flera värden kan tillåtas vore det bra. Det går förstås att hämta alla värden och sortera dem här i Kommunfakta Norge. Men då måste jag ställa in så att källorna inte hämtas. Annars riskerar källor till data som inte används skrivas ut i sidan.
I Ørsta kommun (Q156453) vill jag ha ut datum (2020-01-01) och kommun (Volda) och att det är en förlust av territorium. Om Volda hade varit något annat än kommun, så hade det inte varit hela världen. Det kan ju i Nederländerna röra sig om torrläggning av havet. 62 osv (diskussion) 20 juli 2020 kl. 09.41 (CEST)[svara]
OK, tack för förtydligandet. Här är ett tillägg till mitt första inlägg som jag skrev innan jag läste ditt svar:
Tillägg:@Sextvåetc: Här är en lista på "verkliga värden" för objekt i Norge:
Det enda objekt som har mer än ett värde för bestämningen avyttrade område till (P7904) är Re kommun (Q499570) som har avyttrade område till (P7904) till två olika kommuner. Detta är dock bokfört som två separata betydande händelse (P793) med samma tidpunkt (P585). Är det verkligen rätt, eller borde det vara en och samma betydande händelse (P793) med två värden på avyttrade område till (P7904)?
En annan reflektion: Kan det verkligen vara rätt att betydande händelse (P793) med värdet lösning (kemisk process) (Q3133701) är giltigt för att få använda P7903/P7904 (se diskussionssidorna för dessa properties). Det är väl knappast så att en territoriell enhet som till exempel en kommun upplöses genom "en kemisk process". De närmaste skulle väl i så fall vara Arktis som upplöses genom smältning...
--Larske (diskussion) 20 juli 2020 kl. 10.01 (CEST)[svara]
Vi har redan särskilda properties för ersätter, utbruten ur och ersatt av, så jag ser inte hur det är relevant att ha dessa qualifier-värden för administrativa enheter. lösning (kemisk process) (Q3133701) verkar inte heller användas för annat än inom kemi. Jag har i vilket fall inte planerat att använda någon av dessa två. Det dröjer nog att det dyker upp synonymer till "gränsjusteringar" här, men att tillåta fler än ett värde för grundpropertyn kan vara nyttigt i vilket fall.
Att Re har samma datum i två olika claims, kanske har att göra med att varje påstående om P7903 ska motsvaras av exakt en P7904? 62 osv (diskussion) 20 juli 2020 kl. 10.30 (CEST)[svara]
"Sedan kan flera objekt ibland användas för samma sak, men med mindre betydelseskiftningar". Kan du konkretisera denna något svävande utsaga med något exempel.
Menar du att det finns risk att en norsk kommun har någon annan betydande händelse (P793) som inte är en gränsjustering (Q28953942) som använder kvalifikatorerna fick område från (P7903) eller avyttrade område till (P7904). Om inte så går det väl bra att använda parametern preferqualifier med värdet P7904 för att hämta hem rätt data för exemplet Ørsta kommun (Q156453) ovan.
Jag har på prov lagt in en av betydande händelse (P793) som finns i Japan (Q17) tillsammans med den betydande händelse (P793) som finns i Ørsta kommun (Q156453) i den här versionen av Wikipedia:Wikidata/Sandlåda för Wikidata (Q4115189) och i följande två exempelanrop av Wikidata2 kan du se att det går bra att filtrera bort den japanska händelsen med preferqualifier
{{#invoke:Wikidata2|formatStatements|entityId=Q4115189|property=P793}} → (alltså båda händelserna)
{{#invoke:Wikidata2|formatStatements|entityId=Q4115189|property=P793|preferqualifier=P7904}} → (alltså bara den önskade händelsen)
Om det skulle dyka upp "synonymer till gränsjustering (Q28953942) kommer det ändå att fungera så länge som de har kvalifikatorerna tidpunkt (P585) samt fick område från (P7903) och/eller avyttrade område till (P7904). Eller tänker jag helt fel?
I det tillägg du gjorde i Wikidata2-modulen, se diff, tror jag att det finns ett copy/paste-fel. På de nya raderna ska väl P518 vara P7903 respektive P7904.
--Larske (diskussion) 20 juli 2020 kl. 11.38 (CEST)[svara]
Till att börja med: Nej, jag tror inte någon norsk kommun kommer att använda något synonymt till Grensjustering i sina påståenden. Det tenderar dock att ständigt dyka upp nya synonymer till diverse begrepp, eftersom det mest diversa språket tenderar att styra. Det kan därför bara bra att vara förberedd.
Det finns amerikanska countyn som har "bildande" istället för "gränsjustering" med P7903/P7904 som qualifier. Dessa borde använda propertyn "ersätter" istället för betydande händelse. Men läggs de in, vill jag inte fånga dem. De går som sagt att sortera bort i databehandlingen senare, men då blir man sittande man med en referens för mycket.
Tidpunkt vill jag minnas är en obligatiorisk qualifier till betydande händelse. Men det kan ha ändrats. Utan det är datan värdelös. Det jag vill veta är vilken kommun/enhet området kommer till/från och vid vilken tidpunkt.
Copy-paste-buggen fixad.
Och vad gäller din andra fråga ovan, så har jag sett exempel (i USA) på när P7903/P7904 har flera enheter i samma claim. Så det vore bra om funktionen hämtar alla kommuner i varje claim. Det blir nog snyggare om flera kommuner ligger i samma claim, men det kan finnas invändningar jag inte sett. Exempelvis är det ju inte samma referens till de båda claimen i Re kommun. 62 osv (diskussion) 20 juli 2020 kl. 11.59 (CEST)[svara]
Jag har i min sandlåda gjort en testversion av en ny option, getonlyids, som kan anges i anropet av formatStatements. Genom att ge denna options ett antal Qid, görs en filtrering så att endast värden med något av de angivna Qid släpps fram för en egenskap. Ett testfall för att "gallra" bland alla betydande händelse (P793) för objektet Japan (Q17) finns på Användare:Larske/Testsida5#Test av option getonlyids.
--Larske (diskussion) 20 juli 2020 kl. 15.32 (CEST)[svara]
Det ser bra ut!!! Jag förstår inte vad övriga ändringar du gjort i koden betyder, men det kanske bara är test det också? 62 osv (diskussion) 20 juli 2020 kl. 16.00 (CEST)[svara]
@Larske: Du skulle inte kunna lägga in den här koden skarpt nu? 62 osv (diskussion) 21 juli 2020 kl. 10.46 (CEST)[svara]
Jo, det kan jag göra. Det andra tillägget du såg i koden gällde uppenbarligen ett försök att kunna ange värdet född_och_död till parametern getsimpleproperty, se Användare:Larske/Testsida18#Test av getsimpleproperty=född_och_död. Jag tror det var nån som undrade varför bara födelseåret fanns angivet för barn (P40), men den funktionen blev aldrig inlagd "skarpt" och jag kommer inte ihåg om den är färdigtestad, så jag avstår från att lägga in den nu.
--Larske (diskussion) 21 juli 2020 kl. 10.55 (CEST)[svara]
Ok, jag vet inte hur ofta det händer att föräldrar är direkt inblandade i sina barns död, så jag vet inte hur relevant det är. Men det är en helt annan diskussion... 62 osv (diskussion) 21 juli 2020 kl. 11.08 (CEST)[svara]
Får du lite snabbt fram någon kommun med både P7903 och P7904 att använda som testbänk? 62 osv (diskussion) 21 juli 2020 kl. 11.09 (CEST)[svara]
Som framgår av listan är det just nu bara en kommun, Hortens kommun, som har både P7903 och P7904. Det saknas dock många "symmetrier", alltså att båda objekten som är berörda av en gränsjustering (Q28953942) har uppgifter om denna händelse (Q1190554).
--Larske (diskussion) 21 juli 2020 kl. 13.41 (CEST)[svara]
Utmärkt exempel. Identifierade genast en bugg! 62 osv (diskussion) 21 juli 2020 kl. 13.51 (CEST)[svara]

Flyttar kod[redigera wikitext]

Flyttar kod till Modul:Ortsfakta/Aux, så samma kod inte behöver uppdateras på flera platser. Det här går säkert att göra med fler delar av koden, men vi tar det ett steg i taget. Förutsättningarna är ganska olika i olika delar av världen och i olika typer av objekt. 62 osv (diskussion) 21 juli 2020 kl. 20.35 (CEST)[svara]

Många kommuner saknar P2936[redigera wikitext]

@Sextvåetc: Jag ändrade i koden så att det inte blir skriptfel när egenskapen använt språk (P2936) saknas i objektet. Det drabbade ett trettiotal svwp-artiklar. Det finns totalt mer än 400 objekt som är instans av (P31) kommun i Norge (Q755707) som saknar använt språk (P2936), se frågorna nedan.

Det är alltså drygt hälften av de 863 kommunobjekten som saknar använt språk (P2936). Om det är så att alla objekt ska ha denna egenskap, borde kanske inläggningen i åtgärdskategorin Kategori:Underhållskategori för Ortsfakta WD göras även i dessa fall. Jag vet inte vad den kategorin är tänkt att användas till. Det är ju ingen mening med att lägga in norska kommunobjekt som saknar använt språk (P2936) i den kategorin om inte alla norska kommunobjekt på sikt ska ha den egenskapen. --Larske (diskussion) 2 augusti 2020 kl. 13.21 (CEST)[svara]

Får kika på det när jag är tillbaka till en "vanlig" dator. Nedlagda kommuner kan vara svåra attfå fram detta till, men de nya borde gå att hitta. 62 osv (diskussion) 2 augusti 2020 kl. 13.26 (CEST)[svara]
Bumpar den här tråden, då den annars riskerar drunkna i min bevakningslista just nu. (Ständigt dessa WD-botar.) 62 osv (diskussion) 2 augusti 2020 kl. 20.26 (CEST)[svara]
P2936 finns inte överallt, för vi har inte källor för det överallt. Det är inte säkert det ens är relevant om man går tillräckligt långt tillbaka i tiden.
Ambitionen är att så långt det är möjligt använda Wikidata. P2936 såg jag som en bra väg att identifiera var det är relevant att lägga in samiska och kvänska etiketter i mallarna, utan att lägga in dem manuellt, vilket vi gjort hittills.
Det går dock idag inte att hämta kvänska och lulesamiska etiketter från Wikidata. (Phabricator:T259340)
Det ger två alternativ, antingen låta parametern vara kvar i artikeln eller ta bort den och låta underhållskategorin vara en indikator på att något saknas, tills buggen är fixad. I Norge är det dock tveksamt om det senare är ett bra alternativ.
Frågan dök upp när jag började fundera på hur jag ska göra i Afghanistan, där dari, ett av de officiella språken i landet, inte stöds av Wikipedia. Jag är alldeles för ohändig med RTL-språk för att veta om jag fått med hela namnet när jag kopierar över text manuellt. Det är därför inte problem-fritt att lägga in text manuellt i sådana språk. 62 osv (diskussion) 3 augusti 2020 kl. 09.27 (CEST)[svara]
Hämtad från ”https://sv.wikipedia.org/w/index.php?title=Moduldiskussion:Kommunfakta_Norge_WD&oldid=48081267”