Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Låt oss göra en communityinsats!
Vi listar öppna programvaruprojekt som används inom offentlig sektor i Sverige. Vår ambition är att möjliggöra för myndigheter som står inför en upphandling eller anskaffning av ett nytt system att utvärdera befintliga öppna programvaruprojekt i relation till deras kravlista.
En utvärdering av motsvarande öppna programvaruprojekt kan även ses som ett sätt utveckla den egna kravhanteringen och som en del i informationsinsamlingsarbetet. Detta kan sedan ligga till grund för uppföljande RFI:er och upphandlingen i sig.
Gå in på https://gitlab.com/open-data-knowledge-sharing/wiki/-/wikis/Katalog-över-öppen-programvara-inom-offentlig-sektor
För mer information gå in på http://nosad.se
Jobtech Development på Arbetsförmedlingen jobbar med länkade data i form av annonslänkar. 25% av annonserna i Platsbanken visas upp som annonslänkar och leder tillbaka trafiken enligt principen "back-to-site" (länkade data) https://arbetsformedlingen.se/platsbanken/annonser?s=2 Det blir lite krångligt att få fram metadata som gör url:erna sökbara. Det löser vi i vår pipeline för annonslänkar. 35 repon är kopplade dit. https://gitlab.com/arbetsformedlingen/joblinks
@salgo60 vad tycks?
@dennis_priskorn I nätverket NOSAD hostar och ansvarar olika myndigheter och organisationer för olika delar av infrastrukturen. Arbetsförmedlingen ansvarar för https://nosad.se och det vi lägger upp på wikin. Vi ansvarar också för tidigare diskussionsforum som vi på Jobtech (Arbetsförmedlingen) använder. DIGG ansvarar för innehållet för detta forum och Internetstiftelsen bidrar genom att bl.a. arrangera själva videomötena.
Internetstiftelsen använder sig av Zoom. Det vi får via Internetstiftelsen är stöd vid bokning, utskick, kalendarium. Dessutom redigering av videeoinspelningar samt coachning och teknisk moderering under alla våra workshops. Detta är mycket värt och mer än bara en annan lösning som vi sätter upp själva. Jobtechdev kör internt Jitsi, men vi får prestandaproblem redan vid 30-40 användare, samt att flera organisationer inte kan använda jitsi. Just ur ett tillgänglighetsperspektiv har Zoom fungerat mycket bra. Men frågan om videoverktyg bör gå till Internetstiftelsen. Vi har redan uppmärksammat osäkerhet kring Zoom och har en dialog kring verktyg men i närtid kommer vi att fortsätta med befintlig lösning.
Nu har videoinspelningen kommit! Gå in på https://youtu.be/UvtX4e_qRWY Inspelningen ligger också på nosad.se
@dennis_priskorn bra kommentarer. Funkar det bra för Wikimedia borde det vara gångbart även för oss.
Arbetsförmedlingens Jobtech Development har en Communitylog. Där finns "issues" som vi identifierat som viktigt, men som vi själva inte hinner med eller inte bör prioritera.
Ordet Communitylog är att jämföras med en backlog, men med syftet att kunna kommunicera om projektet och få externa bidrag. Jobtech Development utforskar vad som är möjligt att göra i community-form och välkomnar dialog och samarbeten med myndigheter, privata aktörer, civilsamhället och akademin.
Vi licensierar vår kod som öppen. Våra API:er är öppna i Arbetsförmedlingens jobtechsatsning och vi har jobbat på att bygga en miljö som underlättar för att få externa bidrag. I dagsläget får vi contribution från SCB och Stockholms universitet.
Kika gärna på vår Community Log redan idag!
https://gitlab.com/arbetsformedlingen/joblinks/processing/-/wikis/Community-Log
Nu finns inspelningen också upplagd: https://youtu.be/sfWWPpTysjk
@jonass Precis, när vi började lansera våra API:er och även lanserade betaAPI:er var den vanligaste frågan. "Kan man lite på beständigheten". Ingen vill riska tid och därmed pengar på att utveckla mot något som kan tas bort eller ändras markant på kort tid eller är för instabilt.
Nu finns inspelningen: https://youtu.be/fkgKoN0NkeM
Ni vet väl att alla tidigare inspelningar / workshops finns på https://nosad.se
(from Tim Berners-Lee's Design Issues)
Arbetsförmedlingen (Jobtech Development) använder Jupyter för historiska annonser. https://github.com/simonbe/afhistorik/blob/master/notebooks/API_description.ipynb
Vidare används Jupyter i följande projekt: Create a daily labor demand index based on job ads to calculate total available jobs in Sweden for a given day between 2006-2020¶ https://github.com/kevindeeboman/masters_project/blob/main/masters_project.ipynb
Frågor kopplade till NOSAD-eventet 15 juni:
Är det önskvärt att allmänna handlingar, tvättad från känsliga personuppgifter, automatiskt delas som offentlig handling eller öppna data?
Hur skulle myndigheter kunna arbeta mer proaktivt med allmänna handlingar?
@uljerry Odoo finns på AF i stort och i en "renare" mindre komplex implementation på Jobbtech. Beroende på vad du vill fråga omså kan vi skaka fram svar och personer som kan ge dig vettig dialog.
2 juni kl 10 börjar ett NOSAD-event om Öppen källkod som bas för den digitala allemansrätten.
Bör myndigheternas öppen källkod göras tillgänglig för alla? Gå in på https://nosad.se och rösta!
@salgo60 Ser klart fram emot att diskutera Naturligtvis kan man ifrågasätta Tillhandahållandet av maskinläsbar information om ett ting när dess URI anropas, men syftet är att tillgängliggöra och synliggöra. för att skapa mervärde.
@peter_bengtsson sa i API-licenser eller användarvillkor för API-användning?:
Den uppenbara lösningen är kringgå problemen genom att koppla (eventuellt anonyma) nycklar till API:et, antingen för att exempelvis tekniskt begränsa antalet anrop per sekund eller för att kräva godkännande av användningsvillkor innan nyckeln lämnas ut (då har man en teknisk mekanism som man kan knyta till användarvillkoren).
Gillar din liknelse med telefonkiosken Peter!
Ditt och även Öppnaskolplattformens förslag med att koppla användarvillkor till nyckelhantering är ju hur det till stor del regleras idag, men hur ska man formulera sig om man inte vill ha nycklar på öppna API:er?
Vi har tidigare på forumet diskuterat om det alltid behövs nycklar till ett öppet API och om nyckelhantering leder till begränsningar.
I fallet öppet API, med öppna data har vi inte alltid behov av begränsa anrop eller hur innehållet används. Vi vill också i större utsträckning länka till varandras data, och då kan nycklar eventuellt försvåra som jag tolkat det. Så hur kan vi myndigheter signalera till en presumtiv användare att API:et är öppet och fritt tillgängligt? Naturligtvis i dokumentationen, men kan vi komma till en standardforumlering, eller liknande som är begripligt på många språk? Det som har varit bra med vägledningen från DIGG och PRV gällande öppna data licenser är att det rekommenderas att sätta CCO för att tydliggöra fritt användande av data även i de fall då upphovsrätt inte är tillämpligt. Bättre en tydlig signal som säger varsågod än att det blir superkorrekt ur alla avseenden.
Jag har en fundering kopplat till ”API-licenser” som jag vill dryfta:
Öppna data har vi lärt oss att licensiera enligt Creative Commons, Exempelvis CC0. I ett Källkod licensierar vi enligt källkodslicenser: (EUPL, Appache 2.0, GPL m.fl)
Men det finns fall då man vill reglera själva API-användningen, d.v.s. anrop mot gränssnittet. (Varken källkoden eller datan) hur hanterar vi detta?
Fall 1: Det kan röra sig om att begränsa antalet anrop. 20 om dagen kanske är ok, men inte 1000 per sekund. Datan är forfarande öppen enligt CC0 och källkoden är fortfarande öppen. Dock ligger begränsningen på API:et. Fall 2: Datan är inte öppen, utan det kan röra sig om individdata, men man får i tjänsten bara åtkomst till den data men har rätt att se. Det rör sig alltså om ett öppet API men innehållet är inte öppna data? Fall 3: (jmf Stockholm Stads skolplattform). Att anropa gränssnittet går att göra, men ägaren i detta fall en myndighet vill inte få anrop till sitt gränsnitt (API). Dock går det. Praxis är att går det så är det öppet. Annars får man hantera tillgång med nycklar och användaravtal. I fallet Stockholmstad är det ju inte aktuellt med användaravtal eftersom de inte vill se externa användare på API:et.
Så till min huvudfråga: Hur reglerar man användningen av själva API:et? Själva tjänsten/ gränsnittet (API) och inte innehållet (data) eller koden?
@stefan-wallin tolkar tråden och ditt inlägg som om flera i forumet är inne på rate-limiting i kombination med en uppskalad tjänst där någon nivå av identifiering förekommer. Tanken med att koppla till Diggs Community är att låta myndigheter lita på varandra och på sina invånare. Säger någon att de är från Jordbruksverket eller IDG så kan vi välja att lita på detta, även om vi inte har krav på eID-lösning. Det är ju fortfarande API:er för öppna data lösningen bygger på. Inte data där vi förväntar oss eller har rätt att ens förvänta oss motprestationer. Däremot har olika API:er i alla fall hos oss olika kapacitet. Lösningen borde då bli att:
