Community på Sveriges dataportal

@johantjader Jag skulle nog ändå råda er att se över om det verkligen är nödvändigt att använda HTTP POST för läsoperationer. Tänker att HTTPS är grunden för en säker kommunikation och det viktigaste, och sedan går det alltid går att undvika att logga hela förfrågnings-URL. Sen finns det andra småtips som "Referrer hiding" etc. Kan säkert finnas fog för valet. Men att bryta mot grundläggande principer om hur internet är uppbyggt bör noga övervägas, små beslut tenderar till att leda till problem med interoperatbilitet om flera gör olika i dessa frågor.

@Jonas-Nordqvist sa i Anteckningar efter möte med Magnus kring framgångsrecept för öppna data:

Vi tror att denna communityn har förutsättningar att skapa dataspecifikationer samt även förvalta/äga specifikationer till nytta både för dataproducenter och datakonsumenter. Självklart i samverkan med DIGG, Dataverkstaden, Lantmäteriet och andra parter.

Låter ju som ett genombrott i svensk digitalisering om vi kan börja samskapa på det sättet i communityn.

@Magnus-Sälgö @Nina_Berlin Fast egentligen trollar jag ju din tråd. 43 kommentarer om dataportalen i stängd tråd som handlar om utegym... =). Vi låter iden om att varje api/dataset skulle kunna skattas(https://5stardata.info/en/) utifrån fem nivåer sjunka in lite. Bra om flera tycker till.

@Peter_Bengtsson Bra poäng att REST-API-Profilen kan (kanske bör) användas för interna api:er också. Borde gå att hitta en formulering så att "kravet" inte medför ett extraarbete om informationen inte är relevant.

@mattias Tack Mattias! Viktigt arbete du gör på fritiden. Extra kul att du är så tydlig med vilka roller du har och att du vågar agera på flera sätt i forumet. Föredömligt. En av anledningarna till att så få personer från offentlig sektor vågar skriva är nog en osäkerhet rörande om man får representera sin myndighet i alla frågor, kan man ibland skriva som privatperson, ibland som statstjänsteman etc. Fast egentligen är det tydligt att det bästa är att yttra sig om det finns något att säga: https://www.skatteverket.se/omoss/varverksamhet/styrningochuppfoljning/attvarastatsanstalld.4.361dc8c15312eff6fd11b12.html.

Ser att fler föreningar försöker belysa och lyfta digitaliseringsfrågor till våra politiker. Exempelvis @mattias https://okfn.se/2022/, bra! Vi kanske ska bjuda in några partier till forumet? (Hur man nu gör det)

@Nina_Berlin Med ett krav i REST-API-Profilen att alla API:er ska innehålla ett datum går det att "enkelt" sammanställa en nationell överblick över kommande servicefönster eller brytande förändringar på ett ställe.

@Stefan-Wallin I arbetet med REST API-profilen (https://dev.dataportal.se/rest-api-profil) pågår en diskussion om att organisationen som tillhandahåller ett API på ett standardiserat sätt ska kunna annonsera ett servicedatum enligt en RFC. Det skulle kunna vara en möjliggörare till funktionen Stefan är inne på.

Kandidat för "servicedatum":
https://webconcepts.info/concepts/http-header/Sunset

Vad tror ni om sunset ovan för API:er? (komplement till Stefans idé)

@PerAnd Ja, det finns en förvaltning för respektive dataset som analyserar driftmiljön kontinuerligt.

Svår fråga angående dimensionering. Inget api har krav på identifiering/"api-nyckel", vilket gör att det teoretiskt är svårt att förutse förändringar i last.

Idén är att öka kapaciteten vid behov genom att noga följa antal anrop och olika tröskelvärden för svarstider etc. För mycket överkapacitet är kostsamt. Det har i praktiken fungerar mycket väl pga driftmiljön är en flexibel openshift-uppsättning där mer minne, cpu etc är "en knapptryckning" bort (något förenklat).

Servicefönster utannonseras i vårt forum i god tid: https://forum.jobtechdev.se/. Större förändringar av ett API är svårkommunicerade när man inte vet vilka användarna är. Därför är forum som dataportal.se och forum.jobtechdev.se så viktiga för att kunna föra ut budskap.

@PerAnd Bra fundering. För AF:s öppna api:er (utvecklarplattformen benämns jobtechdev) så är den faktiska tillgängligheten etc högre än vad som kan utlovas i en SLA. Så vi tänker att potentiella användare får vår data om api:er för att själv avgöra om det går att "lita på informationsförsörjningen".

API:ernas faktiska tillgänglighet:
https://statping-ng.jobtechdev.se/

KPI rapport:
https://handlingar.se/sv/request/1332/response/2345/attach/3/2022 05 18 JobtechDevelopment KPI.pdf?cookie_passthrough=1

Hur snabbt agerar vi vid en incident? Går faktiskt att följa när en myndighet har en öppen backlog:
https://gitlab.com/groups/arbetsformedlingen/-/issues

@Stefan-Wallin Arbetsförmedlingens öppna projekt (https://gitlab.com/arbetsformedlingen/) använder mestadels Apache 2.0. Vi har resonerat utifrån att den licensen verkligen underlättar att källkoden kommer i användning. En uppenbar risk är såklart att det inte går att garantera fortsatt öppenhet. Finns även de som tycker LGPL är bra för bibliotek.

@Ingegerd Bra rapport, men jag kanske är lite partisk. (från arbetsförmedlingen). Rapporten finns under nosad.se/tips och en direktlänk är https://gitlab.com/open-data-knowledge-sharing/wiki/-/wikis/uploads/c7d94fc0e6bdea26df7182e54b6e6683/Rapport_långsiktig_informationshantering_E-arkiv.pdf

Tack för alla svar! Sätter ihop ett förslag med en smakfull länk längre ner på sidan. Ni får granska sen. Använder nog en inforuta https://designsystem.arbetsformedlingen.se/komponenter/digi-info-card/oversikt. Kan förövrigt tipsa om vårt designsystem som jag hoppas fler tar till sig och anpassar till sin egna verksamhet. https://gitlab.com/arbetsformedlingen/designsystem/digi

Utvecklar en ny tjänst åt Arbetsförmedlingen (lanseras senare i höst): https://nystartsjobb-sjalvtest.arbetsformedlingen.se/

Tanken är att individer själv ska kunna se vilka möjligheter som finns (vi börjar med subventionen nystartsjobb). Kan idag vara svårt för en individ att veta om villkoren är uppfyllda utan att rådfråga en expert på regelverket (handläggaren): https://www.riksdagen.se/sv/dokument-lagar/dokument/svensk-forfattningssamling/forordning-201843-om-stod-for-nystartsjobb_sfs-2018-43

Skulle vilja bygga in en koppling till källkoden för att öka insynen ytterligare. Men inser också att det är orealistiskt att skicka alla Sveriges arbetsgivare och jobbsökare till källkodshanteraren. Tycker ni att det går att tipsa om vart källkoden ligger för en slutkonsument/individ? Och i sådana fall, hur ska ett sådant tips/länk till individer utformas tycker ni?

Källkoden:
https://gitlab.com/arbetsformedlingen/www/nystartsjobb-test/-/tree/master/public

@Magnus-Sälgö Tveklöst så kommer det mesta innehållet i API:er från offentliga organisationer vara på svenska. Sen tror jag inte att det offentliga ska försöka sig på att värdera hur bra språk en individ behöver för att förstå. Mer binärt konstatera vilket språk något är utryckt i. Men just API:er tycker jag är svårt, vacklar själv i denna fråga. Är nog bra att vi resonerar om det här.

@nilsw-ra I REST-API-Profilen så är frågan om språk inte fullt hanterad. Läs gärna det som finns om språk, https://dev.dataportal.se/rest-api-profil/dokumentation avser att dokumentation bör vara på två språk. Helt sanslöst vad svårt det är att bestämma en så enkel sak som språk (jag deltar i det arbetet). Bra om dokumentation är på engelska, vissa URI:er/namn kommer bli "fåniga" om de översätts till engelska. Sen finns det osäkerhet runt språklagen generellt, är OK att undvika svenska helt för en myndighet. Dina förslag känns förövrigt väldigt bra http://data.riksarkivet.se/concept/{ID} tycker jag! Tänk om flera hade så naturliga URI:er.

@Stefan-Wallin @Stefan-Wallin Absolut datafirst/API är alltid att föredra. Magnus poäng är väl dock att satsningar på API/"öppna data" tar för många år att implementera utan resultat. Så alla konstruktiva/enkla sätt att exponera data mer strukturerat är inte fel tänker jag. Att webbredaktörer lär sig nya sätt att tagga information som inte kräver stora IT-investeringar tror jag är ett bra mönster (men inte det enda).

API:er är bra! Men tror också att ett enkelt sätt att komma igång skulle kunna vara att kommunerna taggar sin HTML. Ett exempel från schema.org för att annotera HTML:en.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SpecialAnnouncement",
  "name": "New Paycheck Protection Program for small business",
  "text": "Example Administration announces a new loan that helps small businesses keep their workforce employed during the Coronavirus (COVID-19) crisis.",
  "datePosted": "2020-03-30T08:00",
  "expires": "2020-04-24T23:59",
  "category": "https://www.wikidata.org/wiki/Q81068910",
  "spatialCoverage":
      {
        "type": "Country",
        "name": "US"
      },
  "governmentBenefitsInfo": {
    "@type": "GovernmentService",
    "name": "Paycheck Protection Program",
    "url":  "https://www.sba.gov/funding-programs/loans/coronavirus-relief-options/paycheck-protection-program-ppp",
    "provider": {
      "@type": "GovernmentOrganization",
      "name": "US Small Business Administration"
     },
    "serviceType": "https://schema.org/BusinessSupport",
    "audience": {
      "@type": "Audience",
      "name": "Small businesses"
     }
   }
}
</script>

@Magnus-Sälgö Se där, du har ju samlat alla ingångssidor iaf! Blir faktiskt lite förvånad att det är så stor skillnad på hur HTML:en ser ut med tanke på att konceptet/lagen "Anslagstavla" är så tydlig. Borde faktiskt inte vara möjligt att implementera på så många olika sätt. Finns det något lämpligt schema på schema.org som skulle kunna passa här? Har inte kollar än själv.