Community på Sveriges dataportal

När jag får en timme över så snickrar jag på https://offentligkod.se. En plats för att synliggöra vilka öppna programvaror som offentliga organisationer använder och eventuellt vilken källkod som en organisation delar.

Idén verkar flyga och en återkoppling jag fått är att flera myndigheter har blivit kontaktade för rådgivning vid införande av olika verktyg. Därav är det läge att snygga till och underlätta så att flera ska kunna använda katalogen enkelt.

Förslag på arkitektur som är enkel att underhålla:
e-Tjänst: https://offentligkod.se/test.html
api: https://api.offentligkod.se/feed.json
data:https://gitlab.com/open-data-knowledge-sharing/publiccode.yml/

Vad tycker ni är bästa sätt att forma en öppen backlog för nästa generations offentligkod.se. Är gitlab issues något som inkluderar alla? Ett öppet dokument som flera kan editera?

@dennis_priskorn https://data.arbetsformedlingen.se/annonser/historiska här kan annonser för åren 2006-2021 laddas ner.

@salgo60-ej-aktiv För en handling, ett dokument, eller en forskningsartikel känns det naturligt att ha en unik global identifierare. Spontant tänker jag dock att ett DOI/sameAs attribut som i googles exempel gäller hela datasetet (en samling dokument, handlingar, forskningsartiklar), och kanske är en mer fråga för https://docs.dataportal.se/dcat/sv/. Dvs att objektet "datamängd" borde ha en identifierare. Hoppas att en expert på DCAT-AP-Se läser och tycker till.

Exempel från arbetsmarknaden när det är svårt att få dataproducenter att tagga sitt innehåll med en unik identifierare (jobbannonser förekommer ofta på många sajter).

Dubbletthantering: https://gitlab.com/arbetsformedlingen/joblinks/job_ad_hash/-/tree/develop

Tjänst: https://arbetsformedlingen.se/platsbanken/annonser?s=2

https://en.wikipedia.org/wiki/Jaccard_index och https://en.wikipedia.org/wiki/MinHash används för att identifiera informationsmängder som har stort överlapp.

Konsekvensen av att inte använda bra identifierare blir ju precis som du säger att det är svårt att i efterhand sortera upp informationen rätt.

@salgo60-ej-aktiv Tyck till om denna artikel https://dev.dataportal.se/sv/api-playbook/audit-trail/. Den föreslår att det bör finnas ett unikt id vid loggning som du föreslår.

@jonor Håller nog med dig Jonor om att ett exempel vore på sin plats. Tanken är att profilen inte ska begränsa i de fall det finns domänspecifika händelser, dock borde nog de allra flesta API:er bara använda de typer som är listade ovan på länken som du angav.

@salgo60-ej-aktiv Jag tror att en dokumenterad profil faktiskt behövs för att kunna fungera som en rekommendation. Nästa steg är att ta in återkoppling om själva profilen (den här tråden etc). Med det sagt så behövs en referensimplementation och/eller några exempel så fort som möjligt. Tror dock det är orimligt att DIGG ska tillhandahålla alla dessa exempel. Det är inte klart, men bättre vore om flera förvaltningsmyndigheter kan implementera profilen för några öppna API:er.

Ett uppenbart dataset att dela från Arbetsförmedlingen är arbetsmarknadsutbildningar. Det finns idag som webbtjänst https://arbetsformedlingen.se/for-arbetssokande/extra-stod/stod-a-o/arbetsmarknadsutbildning/hitta-arbetsmarknadsutbildning/yrkesomraden tillgängligt för alla. Att dela de utbildningarna som öppna data snart vore en bra signal. Vad är kravet för att det ska fungera med Skolverket/SUSA förutom kanske emil-standarden?

@jonor HATEOAS finns omnämnt i den svenska nationella API-profilen som DIGG arbetar med i byggblocket API-hantering, publiceras snart. Svårt att rekommendera det som ett skall-krav för API:er dock, att gå från inget API till HATEOAS på första försöket för en organisation är en utmaning. Även om jag personligen gillar idén har jag svårt att hitta bra exempel på dynamiska klienter som faktiskt nyttjar styrkan med HATEOAS. Ge gärna bra exempel om du har.

@salgo60-ej-aktiv Finns inte stöd för att länka till andra språk/översättningar idag. Vår värld utgår ifrån taxonomy/id ovan som identifierare, men för vissa dataset finns det säkert översättningar om ett wikidata-id kunde användas som en "foreign key". Ska dubbelkolla med taxonomy-teamet om det finns några tankar/planer.

@kristine_ Till synes en enkel funktion. Men en långsiktig effekt borde bli att alla organisationer inte behöver sätta upp en egen infrastruktur (dokumentationssajt) för att tillhandahålla API:er bland annat. Små saker som kan göra stor skillnad känns som framtidens melodi.

Ett förbättringsförslag är stöd för "deep linking", länk till Sveriges kommuner:
https://taxonomy.api.jobtechdev.se/v1/taxonomy/swagger-ui/index.html#/Specific Types/get_v1_taxonomy_specific_concepts_municipality

På dataportalen https://www.dataportal.se/sv/datasets/180_3963/taxonomi-api/apiexplore/3962#/ går det inte länka till specifika endpoints idag.

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

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

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