Uppdaterad dokumentation 20220914

[johantjader]

@Fredrik-Forsberg

Vi håller med och förösker vara trogen REST så långt som möjligt men valde att införliva detta avsteg efter input av myndigheter som vi haft dialog med.

Dokumentationen på Skatteverkets utvecklarportal för Mina ärenden är detsamma här på dataportal.se då det är exakt samma. Tänker att jag passar på att skriva några rader om Skatteverkets olika "hattar" på området då det finns en risk för att hopblandning (även internt ).

Skatteverket är byggblocksansvarig för Mina ärenden, d.v.s. leder arbetet med att ta fram en standard för ärendeåterkoppling. Standarden ska utgå från de behov och förutsättningar som finns ute hos samtliga aktuella producenter och konsumenter så det inte blir "Skatteverkifierad" lösning.

Skatteverket är också s.k. producent och håller nu på att ta fram ett kundhändelse-API i enlighet med den nationella standarden som planeras att lanseras v.44. Skatteverket kommer publicera tjänstebeskrivning och information om API:et och hur man ansluter till det på Skatteverkets Utvecklarportal. Jag tänker att vi (Mina ärenden) ser till att slänga upp ett nytt ämne om detta även i denna forumdel så snart det är klart.

I byggblocket Mina ärenden ser vi att det finns ett värde att ta fram en struktur för hur de olika producenterna beskriver sina datamängder - i detta fall kundhändelser och tillhörande producentprocesser. Därför har vi bett producenten Skatteverket att inledningsvis beskriva dessa i något vi kallar för "kundhändelsetypskatalog". Nu inititalt är det endast en enkel excelfil men på sikt ska det bli en maskinläsbar teknisk komponent som beskriver alla producenters kundhändelser och producentprocesser. Vi publicerade denna på dataportal.se i slutet på förra veckan. Där finns vilka kundhändelsetyper som Skatteverket kommer göra tillgängliga via kundhändelse-API:et.

För den intresserade så har vi kortfattat beskrivit behovet av vissa centraliserade förmågor, bl.a. kundhändelsetypskatalogen, inom Mina ärenden i den byggblocksbeskrivning som togs fram under våren 2022. Avsnitt 2.2 i byggblocksbeskrivningen som finns på www.skatteverket.se/minaarenden

Er input är oerhört värdefull, vi ska försöka involvera dig och andra programvaruleverantörer i takt med att vi får fler myndigheter och kommuner på tråden

[Nizo_Priskorn]

@johantjader Hej. Jag läste lite i begreppsmodellen. Det verkar vara en hel del där som är på svenska. Hur tänker ni kring språk?

Om vi lyfter blicken, skulle man då kunna tänka sig att andra EU-länder skulle ha nytta av att kunna förstå eran begreppsmodell och kopiera det som passar till sina system/byggblock?

Finns det någon tungtvägande skäl till att inte bara köra allt på engelska nu när i princip alla moderna programspråk och ramverk ändå i princip endast har dokumentation på engelska?

För mig personligen verkar det ganska främmande och onödigt inlåsande att välja svenska när jag skriver kod (jag jobbar internationellt i allt jag gör)

Skulle det inte vara kul om tex. Tjeckien börjar kopiera svenska statens högkvalitativa byggblock för att ni gjort så himla bra förarbete? Ni kanske även släpper era implementationer som öppen källkod så det enda de behöver göra är att översätta UI:n och sen kan de lansera till sina medborgare.

Min gissning är att tröskeln för spridning bliver onödigt stor om allt är inkodad i svenska. Ni riskerar att tappa värdefull input från andra aktörer (tex internationella företag).

(ni kan såklart publicera svenska översättningar på alla begrepp också alla vet vad som är vad och kan prata om det på svenska internt eller mellan myndigheterna)

[Fredrik Ferm]

@Dennis_Priskorn Hej Dennis och tack för din fråga.

Det finns en enkel och i vår mening tungt vägande anledning till att begreppen är på svenska och det är att verksamheten bedrivs på svenska inom i stort sett all offentlig förvaltning i Sverige. Mjukvarusystemen är primärt till för att stödja verksamheten och när den bedrivs på svenska bör även systemen använda svenska begrepp när man representerar saker ifrån verksamheten. Om vi istället skulle göra en översättning av verksamhetsbegrepp till engelska riskerar vi att olika översättningar på olika ställen (även utanför Mina ärenden) sker på olika sätt för samma begrepp.

Sedan har du helt rätt i att mjukvaruutveckling och kodande i sig självt är en verksamhet som oftast görs på engelska. Det är ofta ’kutym’ och kulturellt riktigt för utvecklare att använda engelska som språk när man kodar men risken för ihopblandning av begrepp är i vår mening ett större problem än den diskrepans som finns mellan språken vid utvecklingstillfället.

Mycket av arbetet som kommer att ske när man implementerar Mina ärenden hos olika offentliga producenter och olika konsumenter handlar om att förstå och beskriva de faktiska processer som sker inom olika myndigheter och andra offentliga förvaltningar. Sedan skall denna förståelse kodas in i system och kundhändelser skall skickas ut vid lämpliga tillfällen. Detta är specialiserat för den verksamhet som kundhändelserna handlar om. Då blir det ändå svårt att dela implementationen med andra länder och därför blir översättningsproblematiken vid en eventuell sådan delning mindre.

Men, allt handlar om avvägningar och kompromisser. Inom Mina ärenden har vi gjort bedömningen att direktmappning till verksamhetsbegrepp är viktigare än kodnings-kutym och eventuell delning av lösningar.

[En före detta användare]

@Magnus-Sälgö från tidigare inlägg

Exempel term P625 hur en kunskapsgraf "enkelt" stöder olika språk

P625 --> grekiska --> Property:P625?uselang=el
P625 --> engelska --> Property:P625?uselang=en
P625 --> kinesiska --> Property:P625?uselang=zh
P625 --> franska --> Property:P625?uselang=fr
P625 --> ryska --> Property:P625?uselang=ru

[Fredrik Ferm]

@Magnus-Sälgö Hej Magnus

Tack för inspel om Wikidata. Vi tar det med oss och funderar. Primärt just nu är syftet med begreppsmodellen att förklara vår dokumentation och därför är det för tillfället inte akut att göra någon ändring.