@salgo60 Jag instämmer faktiskt i att Sverige börjar närma sig en ohållbar situation vad gäller oförmågan att nå resultat inom digitaliseringen. OK att citera mig, statstjänsteman på Arbetsförmedlingen. Bristen på insyn i utvecklingsprocesser gör det oftast omöjligt att bidra eller att tycka. All källkod bör oavkortat göras öppen om den är finansierad med offentliga medel. Öppna ärendesystem typ gitlab issues eller liknande är nog framtidens motor för att samskapa.

@stefan-wallin högst relevant fråga. Har du läst https://www.regeringskansliet.se/regeringsuppdrag/2020/09/uppdrag-att-mojliggora-losningar-for-individen-till-kontroll-och-insyn-av-data-om-individen/?

Syftet är just att skapa förutsättningar för att individen ska kunna "äga sin egen data".

@salgo60 Driftsäkerhet är en viktig fråga när öppna data tillhandahålls via API:er. Min poäng är i mångt och mycket att api-nycklar inte bidrar till den frågan nämnvärt/enbart. Rate limit är ett mycket bra förslag. Behöver en aktör en väldigt hög tillgänglighet eller prestanda är det inte orimligt att man kontaktar berörd myndighet.

Istället för att enbart reglera tillgänglighet i avtal såsom SLA försöker arbetsförmedlingen också vara öppen med vilken tillgänglighet vi faktiskt har. På det sättet kan konsumenten fatta ett eget beslut om det går att lita på myndighetens API.

Kolla in våran tillgänglighet:
https://statping.jobtechdev.se/

//Jonas

@dennis_priskorn Verkligen kul! Bra att Försäkringskassans och DIGGS:s policies för öppen källkod återanvänds.

Återanvänd gärna arbetsförmedlingens lösning för Platsbanken (eller vår kompetens runt sök/filtrering). Dagligen hanteras ca 60 000 annonser och görs sökbara ur en mängd olika perspektiv. Ni hittar lösningen på github https://github.com/JobtechSwe/sokannonser-api och det är enkelt att komma igång med sökmotorer såsom elastic. (Lämpar sig väl för sök/filtrering)

@salgo60-ej-aktiv Om jag får kosta på mig att vara lite rolig, jo alla språkkoder finns i vårt API. https://taxonomy.api.jobtechdev.se/v1/taxonomy/main/concepts?type=language

@kristine_ WOW! Har kollat på dataset, verkligen föredömligt att öppna upp leverantörsfakturor. Lite förvånad att det inte har fått mer uppmärksamhet, finns en stor potential om svensk statsförvaltning följer i DIGG:s fotspår. @jonor antar att UTF-8 är ett rimligt val för encoding.

@dennis_priskorn @salgo60-ej-aktiv Finns mer information. https://www.regeringen.se/regeringens-politik/regeringens-strategiska-samverkansprogram/samverkansprogrammet-kompetensforsorjning-och-livslangt-larande/. Detta är såklart ett svårt projekt där flertalet organisationer ska samverka. Förutom kvalitén i utbildningsdatan, som produceras av flertalet, där komvux etc idag inte finns i Skolverkets API idag, bör datan i slutändan hänga ihop (länkad data).

@salgo60 Håller med dig i mycket Magnus. En sak som Arbetsförmedlingen och DIGG konkret har utvecklat är en mjukvara för att underlätta/automatisera publiceringen av API:er på dataportalen.se. Källkod och issues kommer öppnas så att alla kan bidra.

Arbetsförmedlingens lista över sin öppna data uttryckt enligt dcat är skapad med denna mjukvaran. https://data.jobtechdev.se/dcat/

Kunskapsgrafer är bra och kan såklart tillämpas när det är lämpligt. Jag personligen tycker dock att CSV och enkla APi:er är underskattade. En gammal hederlig fil med bestående identifierare för informationsobjekten och ett känd metod för att hämta ytterligare information från andra API:er kommer man långt med.

@salgo60 Några saker Arbetsförmedlingen/JobTech arbetar på vad gäller AI.

Tolka innebörden (kompetenser som efterfrågas) i en annons (löpande text), svår fråga där vi har en lösning -> https://github.com/Jobtechdev-content/JobAdEnrichments-content/blob/master/GettingstartedJobAdEnrichmentsSE.md

Minska uppgiftslämnandet för individen, automatiskt kunna klassificera löpande annonstext, https://gitlab.com/arbetsformedlingen/joblinks/text-2-ssyk (Arbetsgivaren behöver inte mata in koder som kan vara svåra att förstå)

AI-tjänst för arbetskraftstillväxt (gissa vilka företag som behöver anställa) -> AI-tjänst baserat på data från Arbetsförmedlingen, Bolagsverket, Skatteverket, SCB.

Forskningsprojekt för att se om jobbrekommendationer (https://www.ifau.se/Forskning/Pa-gang/Arbetsmarknadspolitik/kan-elektroniska-platsforslag-leda-till-battre-matchning-mellan-sokande-och-jobb/) leder snabbare till jobb än om användaren söker bland annonser. Baserat på anonym klickdata i Platsbanken.

@nilsw-ra Hej, Alla offentliga organisationer gör tyvärr lite olika idag, vilket är olyckligt. Mitt bästa tips är att särskilja på villkor för API:ets data och användningsvillkoren/SLA för nyttjandet av tjänsten. DIGG har nämligen en väldigt bra rekommendation för val av licens för data, läs mer https://www.digg.se/utveckling-av-digital-forvaltning/oppna-och-delade-data/offentliga-aktorer/oppna-licenser-och-immaterialratt. Arbetsförmedlingen/JobTech försöker att inte reglera/lova för mycket i SLA:ar. Men däremot försöker vi vara öppna med vilken faktiskt tillgänglighet våra API:er haft historiskt så användaren kan göra ett välinformerat beslut om vårt API håller måttet. Se vår tillgänglighet: https://statping.jobtechdev.se/

@salgo60-ej-aktiv Det är inte uppenbart hur mappningen bör göras. Ser att https://www.wikidata.org/wiki/Property:P8654 någon har laddat upp själva yrkesklassificeringen. Hur skapas identifieraren för en ny "item" på WD? Oavsett så kan det vara lite vanskligt att underhålla en mappning över tid om vi inte tänker till.

@salgo60-ej-aktiv Om jag får kosta på mig att vara lite rolig, jo alla språkkoder finns i vårt API. https://taxonomy.api.jobtechdev.se/v1/taxonomy/main/concepts?type=language

@salgo60-ej-aktiv Jobtech arbetar som sagt för fullt med att relevanta begrepp och information för matchningen ska hänga ihop enligt grafteorier.

Ett enkelt exempel skulle kunna vara vårt fråge-API:
https://taxonomy.api.jobtechdev.se/v1/taxonomy/graphiql

Prova att köra frågan:

query MyQuery {
concepts(type: "ssyk-level-4") {
id
preferred_label
type
ssyk_code_2012
narrower(type: "occupation-name") {
id
preferred_label
type
}
}
}

I detta fall plockas alla relationer ut som finns under en officiell yrkesnod.

@dennis_priskorn @salgo60-ej-aktiv Finns mer information. https://www.regeringen.se/regeringens-politik/regeringens-strategiska-samverkansprogram/samverkansprogrammet-kompetensforsorjning-och-livslangt-larande/. Detta är såklart ett svårt projekt där flertalet organisationer ska samverka. Förutom kvalitén i utbildningsdatan, som produceras av flertalet, där komvux etc idag inte finns i Skolverkets API idag, bör datan i slutändan hänga ihop (länkad data).

@salgo60-ej-aktiv tack för info, mycket intressant. Tror vi/af behöver hitta smarta sätt att nyckla/översätta kompetenser/yrken mot fler domäner än de vi traditionellt arbetar emot SSYK/ISCO/etc. Säg till om du har tid för möte någon dag, för att diskutera mappningar mot wikidata.

@ainali lovvärt initiativ! Funderar på om individen alltid vet vilken offentlig organisation den vill komma i kontakt med. Att gruppera organisationer utifrån behov/livshändelser/scenarior kanske kan vara nyttigt på sikt.

@salgo60-ej-aktiv Med öppen backlog menar du typ såhär?https://gitlab.com/groups/arbetsformedlingen/taxonomy-dev/-/issues

@salgo60-ej-aktiv DOI var ett riktigt intressant förslag. Jag/AF har mest tänkt UUID för identifierare. Tror du det finns något bra exempel på ett API som använder DOI?

@kristine_ WOW! Har kollat på dataset, verkligen föredömligt att öppna upp leverantörsfakturor. Lite förvånad att det inte har fått mer uppmärksamhet, finns en stor potential om svensk statsförvaltning följer i DIGG:s fotspår. @jonor antar att UTF-8 är ett rimligt val för encoding.