Community på Sveriges dataportal
Data och API:er
-
@Nina_Berlin @Kristine_ @Maria_Dalhage https://data.norge.no/specification/dcat-ap-no#Krav-til-kontrollerte-vokabularer i Norge verkar det vara mer strikt hur ord rapporteras. Tips från @Magnus-Sälgö som verkar intressant att följa upp.
-
@Jonas-Nordqvist jag tolkade fel i mitt sökresultat och du har rätt. API-boxen exkluderar övriga dataformat. Naturligtvis blir det missvisade.
-
@jonass sa i Data och API:er:
https://data.norge.no/specification/dcat-ap-no#Krav-til-kontrollerte-vokabularer i Norge verkar det vara mer strikt hur ord rapporteras
Vad jag kan se är det samma kontrollerade vokabulärer som dataportalen använder och som bygger på EU:s rekommendationer: https://docs.dataportal.se/dcat/sv/ , se till vänster längst ned ser du de vokabulärer. Men kanske har de gjort någon utvidgning som inte jag ser på rak arm. Det är en viktig och aktuell fråga om ytterligare kontrollerade vokabulärer ska tas in, men det är en avvägning om och isåfall hur långt den nationella anpassningen ska avvika från den europeiska. Vi har resonerat hittills att vi så långt det är möjligt göra en nära anpassning, så att Sverige inte börjar divergera från resten av EU.
För att tillgängliggöra stabila vokabulärer på ett maskinläsbart sätt så erbjuds "Begreppstjänsten" på dataportalen. Idag ligger många centrala begreppslistor i PDF:er eller i inlåsta system tyvärr och det hindrar möjligheterna att de nyttjas i ekosystemet bland dataanvändare och dataproducenter. Begrepptjänsten på dataportalen erbjuder stöd för att tillgängliggörande och återanvändning av dessa begrepp. Läs gärna mer om begreppstjänsten och varför det är viktigt för datadelning och interoperabilitet här. Där kan ni även läsa om hur central terminologihantering på Sveriges dataportal öppnar upp för ett mer komplett sök och navigeringsstöd för datamängder.
-
@Jonas-Nordqvist sa i Data och API:er:
@jonass Så är fallet, men det var inte så det var tänkt. Och i dagsläget är det ju inga problem att hitta. Problemet är snarare att det finns för lite att söka efter. Den stora diskussionen på forumet är ju att det saknas datamängder och inte brister i att hitta dom. Men man kanske borde ta tag i själva portalen så att den blir lite användarvänligare idet fallet fler datamängder tillkommer. Just nu är det lite latjolajban.
Jag skulle säga att det största problemet inte har att göra med att dela data utan att kvaliteten när datan väl delas är så låg att det knappt är värd min tid och möda och att utsikterna till dialog med de som underhåller och utvecklar datamängder hos myndigheterna är icke-existerande i dagsläget
️Jag tar hellre lite bra data än mycket värdelösa datasilon på nivå1-3 som kastas upp likt kräk och sen inte går att begripa sig på, inte går att läsa med maskin och inte går att lita på att någon faktiskt äger och bryr sig om.
-
@Dennis_Priskorn
Kunde inte uttryckt det bättre. Tycker även Fia Ewald talar klarspråk.
Öppna data idag är mycket publicering för publiceringens skull, mäts efter antal datamängder, antal deltagare i workshops mm.
-
@mistral Tack för länken! Digitaliseringsstrategin som länkas i artikeln gav 404 hos regeringen. Det i sig säger väldigt mycket om hur det går med samordningen och kvaliteten i arbetet kanske?
Här finns den arkiverat: https://web.archive.org/web/20220728071334/https://www.regeringen.se/49adea/contentassets/5429e024be6847fc907b786ab954228f/digitaliseringsstrategin_slutlig_170518-2.pdf (i juli i år, dvs länken dog därefter)
-
@Nina_Berlin jag håller på att göra visualiseringar som jag tänkte lägga i en artikel. Då jag tycker jag ofta får denna (och liknande) frågor och jag upplever att vi ofta pratar om varandra beroende på vilken relation man haft till data. Sen blir det ju inte lättare att vi använder data både som objekt och subjekt.
@Nina_Berlin sa i Data och API:er:
API:er inte hör hemma i en datasök
Detta blir knöligt när det är de som tänker på datamängd/api utifrån ett systemutvecklingsperspektiv och de som tänker utifrån perspektivet produkt/tjänst/service. Så detta blir långt för jag ville exemplifiera så vi pratar om samma sak.
Jag tycker utifrån perspektivet användare på dataportalen absolut att API:er hänger ihop med datasök för det handlar om hur det är möjligt att tillgodogöra sig datamängden och ofta säger det lite om hur api:et (och datamängden) underhålls.
Om man på dataportalens sida vet att alla datamängder i portalen tillhandahålls med api så kanske det räcker att det förtydligas i en text och man behöver inte ha det på "sökknappen", men som jag tror någon nämnde är det nog bra SEO att ha det på flera ställen.
För mig som systemägare/datakonsument är det en skillnad om någon tillhandahåller ett api till en datamängd. Det blir det ju en typ av tjänst i förhållande till dataproducenten både i förhållande till tillgängligheten och tillförlitligheten. Men också att jag kanske kan förvänta mig annan kommunikation och transparens i hur datamängden underhålls och om förändringar i schemat/specifikationen sker, så är det bra om man kan få en notis om det. Det kan vara open source och att specifikationen anger att dataproducenten enbart säkerställer tillgängligheten men inte tillförlitligheten för att alla inkl jag själv bidrar till data i datamängden (exempelvis har EU:s dataportal formulär och jag la in förslag på en Browser i deras datamängd om Browsers, igår).
Om det enbart är datamängder som tillhandahålls så ser jag det mer som en engångs nedladdning eller att man kan ta del av datamängden och använda i sin egen databas men då är det ju upp till mig om jag behöver lägga till någon tabell eller göra underhåll på datan.
@Nina_Berlin sa i Data och API:er:
Hur hänger data och API:er ihop? Är API:er egentligen irrelevant när man är ute efter att hitta data?
Se ovan om hur det hänger ihop och se om du tycker det är klart. Och andra får gärna rätta mig om ni tycker jag gör det krångligare än det är.
Exempel på praktisk skillnad på att använda datamängd eller api:
Vi behöver adresser till alla som är här i community för att det har beslutats att alla ska få en rubics kub i julklapp. Eftersom vi vill göra ett exempel av det så beslutar vi att adressen ska visas i vår kontovy.Vi behöver då hitta en eller flera datamängder som har en specifikation som visar att de har tabeller som kan knytas till användarna här. Låt oss för exemplet bortse från problem med personuppgifter som data och säga att vi alla vid registrering i community skulle uppgett personnummer, eftersom frågan om identifier inte är relevant för exempelet
Vi hittar en datamängd från folkbokföringen som enligt specifikationen har både adress och personnummer i samma datamängd och det anger att postadress, postnummer och ort ligger i olika tabeller. Det finns även en tabell för e-postadress man uppgav vid senaste adressändringen i datamängden.
Om vi hämtar datamängden
Vi hämtar datamängden och skapar tabeller för den data vi inte haft sedan tidigare t.ex. postort. Vi använder personnummret för att rätt rad ska knytas till rätt konto. Däremot har vi ju redan en datatabell för e-post som måste hanteras. Vi beslutar att kassera den tabellen eftersom användarna uppenbarligen valt en e-post för denna tjänst, den behöver ju inte vara samma.Ni skriver till alla användare att adresser finns i profilen. När användare X går in och kollar på sin profil ser hen att adressen är till sina föräldar och inte där hen bor i andra hand (och inte kan skriva sig). Användare X vill ju gärna ha julklappen och frågar om hen kan ändra sin adress. I detta fall kan beslutas att användarna kan ha annan adress eftersom det är ett sparat system.
Nu har det gått ett år och eftersom rubiks kub var så lyckat beslutas att skicka ut ett pussel som julklapp. Nu är frågan hur ni ska säkerställa att adresserna fortfarande stämmer. Ska ni be användarna gå in och dubbelkolla eller hämta data igen från folkbokföringen som postadress. De flesta skulle nog föredra det senare men Användare X adress skrivs då över.
Om vi använder api till datamängden
Vi bygger hur vi ska ta emot data och specificerar då att vi inte vill ta emot e-post (den behöver aldrig kasseras därmed). Om detta glöms och missas kan det innebära att e-post skrivs över och att personer inte kommer in på sina konton längre eftersom de inte uppger e-post som ni har i databasen (om ni använder annan). Vi hämtar datatabellerna kopplat till adress från datamängden. Vi använder personnummret för att rätt rad ska knytas till rätt konto. Ni specificerar hur ofta ni vill att api ska hämta data och sätter fältet till read only för profilen.Ni skriver till alla användare att adresser finns i profilen. Om ni möjliggör ändring av adress kommer Användare X:s adress till andrahandsboendet skrivas över vid en hämtning. Det finns möjliga lösingar att separera folkbokföringsadress och postadress. Där användaren kan ändra postadress men default är folkbokföringsadressen. Men det blir mycket kod/funktion för kanske väldigt litet behov så det beslutas att Användare X mailar sin adress och den hanteras separat.
Nu har det gått ett år och eftersom api:et hämtar data med satt intervall från folkbokföringen kan ni skriva till alla användare att om de inte flyttat sedan XX (sista hämtningen och beakta folkbokföringens administration) så kommer har ni rätt adress. Om man vill ha skickat till en annan adress, och inte har eftersändning, så får man maila.
Detta exempel går ju att ta mer tekniskt och i all oändlighet. Vad det innebär för datakonsumenten om api är inbyggt i system och dataproducenten gör förändringar utan att meddela. Exempelvis byter benämning på datatabellen "postadress" till "gatuadress" eller format på datatabellen "personnummer" från "ÅÅMMDD-nnnn" till "XXÅÅMMDDnnnn" och hur man kan ha en "landing"-databas för redundans för att sådant inte ska innebära driftstörning eller om det ska hämtas av webbplats för att utvecklarna ska kunna modulera data och bygga självständigt så det blir en stabil webbplats, men utan att va tvungna att bygga externa api.
-
@Dennis_Priskorn sa i Data och API:er:
största problemet inte har att göra med att dela data utan att kvaliteten när datan väl delas
Håller med till viss del. Data governance eller arbetssätten för att jobba med både data och kod som data är ett stort problem. Men jag tycker inte dålig kvalitét är anledning till att inte dela data, så länge man är transparent om det.
Men jag kan tänka mig hellre öppna datamängder utan säkerställd kvalitet delas öppet om man är transparent och hellst kan bidra till kvalitén som datakonsument dvs en öppen governance form.
Tar hellre öppen data utan säkerställd kvalitét än bakom betalvägg och bli besviken på tillgängligheten, specifikationen eller formen och möjligheten att påverka detta. Säg att det är svinbra kvalitét (uppdaterad) på data från producent X men de följer inte standarder från EU:s öppna data set så du måste alltid göra en workaround för att få de att lira. Då betalar du för datamängden och betalar i tid att dina utvecklare alltid måste hantera problemet.
Och i vissa fall är data utan kvalitét det viktigaste test och de som exprimenterar om metoder och arbetssätt kräver sällan kvalitétsstämplad data. Exempelvis har api för testpersonnummer underlättat arbetet med testmiljöer extremt. Önskar att det skulle funnits när jag jobbade med webb. Ska kolla om samma datamängder finns för dummy användare.
-
@tove sa i Data och API:er:
Detta exempel går ju att ta mer tekniskt och i all oändlighet. Vad det innebär för datakonsumenten om api är inbyggt i system och dataproducenten gör förändringar utan att meddela. Exempelvis byter benämning på datatabellen "postadress" till "gatuadress" eller format på datatabellen "personnummer" från "ÅÅMMDD-nnnn" till "XXÅÅMMDDnnnn" och hur man kan ha en "landing"-databas för redundans för att sådant inte ska innebära driftstörning eller om det ska hämtas av webbplats för att utvecklarna ska kunna modulera data och bygga självständigt så det blir en stabil webbplats, men utan att va tvungna att bygga externa api.
Det här går att lösa med versionering. Jag versionerar API:n jag skriver just nu. Datamängder kan också versioneras så att man enkelt kan peka på just den version som laddats ner.
@Magnus-Sälgö och jag vill ha ändringsström också och det har jag då aldrig sett någon offentlig myndighet erbjuda.
-
@Dennis_Priskorn Ändringsström avseende data: https://data.arbetsformedlingen.se/rss/datajobtechdevse.xml i beta version.
-
@jonass sa i Data och API:er:
@Dennis_Priskorn Ändringsström avseende data: https://data.arbetsformedlingen.se/rss/datajobtechdevse.xml i beta version.
Hallå! Jobtechdev håller kvar ledartröjan ser jag
Jag har bara jobbat med Wikimedias ditto som är baserat på en ström från Kafka. -
@tove Tack för ditt svar!
Mycket välformulerat och relevant. Jag tolkar det som att det ligger i linje med min känsla av att vi får nytta av data när vi kan förstå datat så det kan bilda information, och det kan man göra på olika sätt, bland annat genom att använda API:er. Det som är mest praktiskt beror troligen på vad datamängden kan bilda för information.Jag pratade vidare om frågan internt på DIGG med bl a @Kristine_ och insåg efter det samtalet att visst data är svårt att ta till sig utan API:er. Om man vill använda realtidsdata från t ex IoT-givare är det mer praktiskt att ha tillgång till det via ett API, eftersom datat uppdateras hela tiden. Det är fortfarande datat man är ute efter, nyttan med API:et ligger ju i vilket data man når med det.
-
@tove Jag tycker att det att man delar sitt data är första stegen på vägen till att höja kvaliteten på det. Hur ska man annars förstå vad man behöver ändra på? Vi behöver alla feedback.
-
@Dennis_Priskorn sa i Data och API:er:
Det här går att lösa med versionering. Jag versionerar API:n jag skriver just nu. Datamängder kan också versioneras så att man enkelt kan peka på just den version som laddats ner.
Absolut, jag lyfte det mer för att påtala att det inte är löst bara för att man har ett api utan transparensen och kommunikationen kring specifikation och förändringar behövs ändå. Att om API versioneringen slår till blir det ett "tillbud" istället för en olycka. Men API versionering bör ju inte vara ända åtgärden.
Och sedan är väl versionering en utvecklingsåtgärd i antingen lifecycel eller ad hoc behov, om det inte ska vara en allt för bred tratt initialt?
Tänker att om du versionerar api utan att veta vad du garderar för så bör du öka din attackyta för i vart fall vissa API attacker och även kanske för DDoS som inriktar sig mot endpoints? Men nu spekulerar jag utifrån konceptet. Jag är ju inte teknisk i grunden och API versionering är inte det område jag är starkast på.
-
@Nina_Berlin sa i Data och API:er:
realtidsdata från t ex IoT-givare är det mer praktiskt att ha tillgång till det via ett API, eftersom datat uppdateras hela tiden
Absolut! Och i sådana fall kan ett öppet test-api vara värt också eftersom det kan vara svårt att bygga och testa mot en statisk testdatabas.
-
@Nina_Berlin precis, men sen ser jag absolut att ett det behöver finnas fungerande effektiva feedbacklooper här för att inte några få ska drunkna, och i värsta fall de som också utvecklar.
Exempelvis kan första steget vara en feedback där man finner dataset till en mail eller ticketsystem av formulär som är utformat utefter dataspecifikationen och exempelvis har alternativen
Vad är ditt ärenden?
- Föreslå ändring av data / rapportera fel
- Bidra med ny data
- Förfrågan om ytterligare data i datamängen
Det är ju främst 1 och 2 som behöver ha särskilda formulär för effektivitet. Exempelvis ser man i det jag lämnade in igår att de bara har en "your proposal". Om jag minns rätt förifyllde de dock de tre översta utefter vilken sida och browserinställning gissar jag.
De skulle ju kunna haft de tre eller fyra olika tabellerna som input-fält så skulle jag kunna lagt till förslag direkt i dom, anpassat utefter specifikationen. Eller om jag anger att det är ändring av data så dropdown på vilken tabell och vilken datarad. Så behöver bara ändringen va fritext.
(De efterfrågar även namn och e-post men jag klippte bort det här)
