Community på Sveriges dataportal

@Sylvia Tack för informationen, nu är sidan uppdaterad.

Intressant Pierre! Jag ska skicka den här tråden till mina AI-kollegor som pratar en hel del om generativ AI:)

Mina ärendens standard för digital ärendehantering har uppdaterats. Bakgrunden till versionsuppdateringen är att Mina ärenden förbereder dokumentationen inför lanseringen av den nya vidareförmedlingstjänsten som ska sänka trösklarna för anslutning.

Utöver denna ändring i Tjänstebeskrivning har dokumentet Det här är Mina ärenden fått ett nytt stycke om den kommande vidareförmedlingstjänsten. Dessutom har vi gjort ytterligare redaktionella ändringar och lagt till ett förtydligande om hur man med hjälp av standarden kan ge användaren rätt förväntningar om handläggningstid, eller servicelöfte som vi kallar det.

I samband med uppdateringen har Mina ärenden även flyttat från sin gamla plats på Sveriges dataportal under Data och API:er. Från och med nu ligger senaste versionen under Specifikationer.

Gå till senaste versionen av Mina ärenden på Sveriges dataportal

Vi som jobbar med Mina ärenden är tacksamma för all sorts feedback. Du som har läst får mer än gärna lämna synpunkter, antingen här i Dataportalens community eller via mejl Minaarenden@skatteverket.se

Hej, korta svar på detta, ska beakta dina andra inputs inför arbete med ny version.

@ChristerOlsson sa i Vägledning för att publicera data om grillplatser:

Började dåligt med att jag skulle titta på specifikationen och länken är bruten. https://dataportal.se/specifications/grillplatser/1.0 resulterar i en 404.

Verkar vara pågående störning, arbete pågår.

Stabila URLer är också ett starkt önskemål. Jag har känslan av att när någon publicerar en ny version av en csv på dataportalen så blir det en ny URL. Kan någon bekräfta eller dementera? Kanske inte en del av standarden men något som ändå bör poängteras.

Det är en handhavandefråga - man kan sätta ett alias på ex.vis ett autogemererat API, då behålls det namnet. Nog inte många som gör. Lägger man till en ny fil och tar bort den gamla = namnen bryts. Byter man ut en redan publicerad fil = identifieraren behålls. Jag har testat lite olika varianter. Misstänker att en vägledning kring detta vore önskvärt. Naturligtvis är persistent identiferare a och o.

Det bör skapas en validator någonstans där man kan skicka in en endpoint och validera om man följer specifikationen. Om ingen annan vill så kan jag skapa en sådan för geojson.

Ja det tror jag hade varit mycket bra, som validerar mot schemat. Jag tänker mig att en sådan validerare skulle kunna byggas on the fly, alltså suga i sig ett schema och kunna matcha mot vilka datamängder som helst. Det här skulle ju vara en fin feature i dataportal.se som hjälper till vid publicering "app app app din uppladdade källa värderar inte sant på alla attribut, här är fellistan: " osv.

Här kommer novembers nyhetsbrev.

@Matself Jag håller helt med. Geopackage stöds nu tex av JOSM som används inom OpenStreetMap så det går lika bra som GeoJSON.

För mig som datakonsument är huvudsaken att val av koordinatsystem tydligt specificeras. Jag vill inte ha GeoJSON som inte följer standard.

@elias Vi tror ju att det ev kan komma nåt uppdrag till Digg kring öppen källkod kopplat till den kommande interoperabilitetsförordningen, men som vanligt väntar vi med att ropa hej till vi verkligen ser att det blir nåt:)
Digg egen policy för öppen källkod håller också på att uppdateras nu, men jag vet inte när den kommer. Den nuvarande finns ju här: https://www.digg.se/analys-och-uppfoljning/publikationer/publikationer/2022-09-27-anskaffning-utveckling-och-publicering-av-oppen-programvara-policy-och-riktlinjer

Re: Interoperable Europe Act

I en pressrelese från 4 mars 2024 går att läsa att Europeiska rådet nu antagit förordningen och att denna nu kommer att publiceras i EU:s officiella tidning inom de kommande veckorna. Förordningen kommer att träda i kraft 20 dagar efter detta.

https://www.consilium.europa.eu/en/press/press-releases/2024/03/04/interoperable-europe-act-council-adopts-new-law-for-more-efficient-digital-public-services-across-the-eu/

Vad står då i denna förordning?
Bland annat markerar förordningen markerar en tydlig inriktning mot öppen källkod och open source-lösningar, vilket är ett betydande steg framåt för att främja öppenhet och samarbete inom Eus förvaltningar.

Nedan paragrafer kommer från i EU:s Interoperabilitetsförordning.

laying down measures for a high level of public sector interoperability across the Union (Interoperable Europe Act)
(21) The Interoperable Europe portal should make publicly available solutions that follow the EIF principles of openness, technical neutrality and security. As open source enables users to actively assess and inspect the interoperability and security of the solutions, it is important that open source supports the implementation of interoperability solutions. In this context, the use of open source licences should be promoted to enhance legal clarity and mutual recognition of licences in the Member States.

Article 8 Interoperable Europe portal
2 (c) use a licence that allows at least for the reuse by other public sector bodies or institutions, bodies or agencies of the Union or be issued as open source. An open source licence means a licence whereby the reuse of the software is permitted for all specified uses in a unilateral declaration by the right holder, and where the source codes of the software are made available for users;

3 When a public sector body or an institution, body or agency of the Union provides a portal, catalogue or repository with similar functions, it shall take the necessary measures to ensure interoperability with the Interoperable Europe portal. Where such portals collect open source solutions, they shall allow for the use of the European Union Public Licence.

Artikel 15 Interoperable Europe Board
4. (p) propose measures to collaborate with international bodies that could contribute to the development of the cross-border interoperability, especially international communities on open source solutions, open standards or specifications and other platforms without legal effects;
Artikel 20 Monitoring and evaluation
(c) the development of open source solutions for the public services, public sector innovation and the cooperation with GovTech actors in the field of crossborder interoperable public services to be delivered or managed electronically in the Union.

@Maria_Dalhage Dokumentation från eventet finns nu under Kompetensförsörjning och livslångt lärande i kategorin Data https://community.dataportal.se/topic/978/datadriven-samverkan-för-planering-och-dimensionering-av-utbildning

Här kan du som deltagare i utbildningen Dataambassadörsprogrammet som Digg tillhandahåller knyta kontakter, samverka och samarbeta med andra deltagare. Läs mer om Dataambassadörsprogrammet på den här sidan Utbildningar om datadelning (dataportal.se).

Välkommen att skapa och delta i dialoger!

@SKV-RaC sa i Skatteverkets API Rättsliga regler och regelfilskonceptet i sin helhet:

Om du har exempel på tänkt användning där Skatteverkets utbud idag inte motsvarar behovet får du gärna utveckla detta.

Jag föreställer mig att ett relevant användningsfall är att någon vill skapa ett program (mjukvara) som visar skatteregler och hur reglerna ändrats över tid.

Det verkar som om Skatteverket har tänkt att denna "någon" som vill skapa ett sådant program, alltid är ett företag eller en formell organisation (formellt registrerad organisation så att den har ett org-nummer tror jag ni menar).

Men det behöver inte alls vara ett företag eller den typ av organisation ni tänkt, det kan vara en privatperson som vill göra ett eget program, eller det kan vara någon mindre formell organisation som inte kan eller vill teckna avtal.

Om vi tar privatpersonen som exempel, det skulle kunna vara jag själv som privatperson, jag kanske är intresserad av någon viss skatteregel (kanske i samband med att jag ska lämna in min deklaration) och jag vill skriva ett script som via ert API plockar fram de olika versioner som funnits av den skatteregeln. Jag kanske använder Debian, kanske gillar jag bash och curl och jag skulle ganska enkelt kunna skriva ett litet bash-script som tog fram informationen jag ville ha, om jag hade tillgång till ert API. Inget företag är inblandat, det är bara jag som privatperson som kommunicerar med Skatteverket.

Kanske är ert svar till mig då att jag istället ska köpa en produkt utvecklad av ett företag som har avtal med er, så att det företagets produkt kan hämta informationen åt mig. Men jag vill inte köpa någon produkt från något företag, det är både snabbare och enklare för mig att skriva mitt eget script.

Ett annat exempel är att någon organisation kanske driver ett öppen-källkod-projekt där de tar fram programvara som kan visa saker som t.ex. era skatteregler. Det är då fri och öppen programvara som vem som helst kan köra på sin egen dator, men för att köra den kommer man behöva tillgång till ert API. Om det t.ex. krävs en API-token för tillgång så skulle varje användare behöva konfigurera programmet med en sån API-token, i princip skulle varje användare kunna ansöka hos er om access, men det går ju inte om inte privatpersoner kan få access.

Förstår ni vad jag menar med de här exemplen?

@ChristerOlsson Hej! Github är inte riktigt vår backlogg, den är tyvärr inte öppen för allmänheten, men du kan rapportera in detta som ett fel i Github om du vill. Vi har redan den här frågan i våran interna backlogg på Digg, eller önskelista kan man också kalla det för. Den är inte utredd ännu, så det jag menar med när jag säger att jag gör en mental note för detta, så menar jag att jag ska se om vi kan börja titta på detta efter årsskiftet, alltså se om det är nåt vi skulle kunna prioritera upp. Det skulle kräva en utvecklingsinsats, så det behöver vägas mot andra saker vi behöver göra och budget, som alltid:) Vad jag förstår så är en komplexitet iaf att kunna skilja på nypublicering av en datamängd, och på uppdateringar av datamängder som redan finns på dataportalen.
Men jag håller med om att det vore bra att få till detta.