Community på Sveriges dataportal

@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.

Hej Magnus

Som @johantjader nämner ovan är vår definition lite vag och detta är fullt medvetet. Vår förhoppning i just detta fall är att om vi inte detaljerar vad en kund är så låser vi inte in oss mot en specifik betydelse, eftersom Mina ärenden är tänkt att stödja många olika sorters offentlig förvaltning.

Om vi istället skulle behöva definiera begreppet hårdare så skulle vi utan tvekan hamna i den typ av diskussion som du nämner kring betalningar på bank.

Men, det kan säkert finnas fallgropar här. Jag har själv erfarenhet av att jobba med just kundbegreppet inom en stor bank. Det kan bli problematiskt när det handlar om stora företag/organisationer där intressanta kundhändelser endast rör en liten del av organisationen. Vår förhoppning är dock att andra urvalskriterier än kund, t ex process eller ärende (kommer snart ut i ny version av vår spec) kan hjälpa till att snäva in mot intressanta kundhändelser för stora organisationer.

@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.

@jonass Hej Jonas

Ja du har rätt, detta bryter mot grundläggande REST-principer, vilket i sig är ett problem.

Men att exponera personnummer är också ett problem som till en början kan tyckas vara lite banalt. Men vi vill att standarden för Mina ärenden skall kunna användas i många verksamheter och därför måste vi tänka lie kring de värsta fallen. I vissa fall av offentlig förvaltning bara vetskapen om att någon frågar om en viss person till en viss producent ett säkerhetshål. Till exempel kan man tänka sig att vetskapen om att många frågor ställs till en viss kommun om en person med skyddad identitet säger någonting om var denna person befinner sig. Eller att vetskapen om att frågor ställs om en viss person till en specifik vårdinrättning (cancerbehandling, könsbyte etc) exponerar information om personens medicinska hemligheter.

Så här behöver vi välja mellan två dåliga alternativ. Antingen bryta mot REST-principer och komplicera lösningen eller potentiellt exponera skyddsvärd information. I den sammanvägda bedömningen har vi landat i att skyddet är viktigare än principerna i detta fall och därför har vi ändrat till POST.