Data och API:er

jonass

@Jonas-Nordqvist Har som sagt ingen stark åsikt. Men tycker nog dagens formulering fungerar bra.

Jonas Nordqvist

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

Maria_Dalhage

@Jonas-Nordqvist Jag begriper sök datamängd, men när jag söker på ngt så kommer även begrepp och specifikationer upp i mina träffar. Genom att klicka i API:er slipper jag det som inte är data. I övrigt har jag inga synpunkter.

Jonas Nordqvist

@Maria_Dalhage Inte så bra att begrepp och specifikationer kommer med när du söker efter datamängd. Och workarounden att klicka i API gör väl att du även filtrerar bort datamängder som som inte har API.

Jonas Nordqvist

@Jonas-Nordqvist Men söker du på "utegym" så kommer bara datamängder upp. Inga specifikationer. Så jag förstår inte riktigt hur du söker.

Sen när man klickar i API så försvinner 6 st av utegymsträffarna. Bland annat Stockholms stads "Utegym ur Hitta Service API)". Och även Lommas som har JSON, men det kanske inte är det som triggar vad som är API eller inte?

Maria_Dalhage

@Jonas-Nordqvist jag tror att det kan finnas ett behov att se över ux-upplevelsen tillsammans med dataanvändare och dataproducenter. Dataportalen har funnits ett par år nu så det är väl dags att fånga in feedback och göra relevanta justeringar. Så toppen att du tycker till. I samband med att Dataportalen från ett nytt utseende och expanderas nästa vecka så är timing för feedback klockren, eller hur @Nina_Berlin

Kristine_

Jag ser att det kommit bra synpunkter och förbättringsförslag, så väljer att passa på att informera lite om det som ligger "under huven" och det som ni som dataproducent ansvarar för som påverkar möjligheterna att söka och hitta resurser.

Dataportalen visar upp data som är beskriven och tillgängliggjord enligt de tekniska krav som är specificerad under https://docs.dataportal.se/dcat/ . Dessa beskrivningar kallas metadata och följer en gemensam metadataspecifikation, så att de är enhetliga och kan hanteras automatiskt och maskinellt för dataportalen. Både datamängder och API:er kan beskrivas med metadata. Ibland kan man få åtkomst till en datamängd på flera olika sätt, t.ex genom flera filer i olika format och ett gränssnitt/tjänst/API. Dessa kallas distributioner. För fördjupning om distributioner, API:er m.m. kopplat till metadatabeskrivningarna läs här och här.

Ibland krävs det eftertanke hur man beskriver just sin datamängd, tidsserie, API, m.m. på bästa sätt. Data i dess olika former, tillämpningsområden och sektorer är ibland komplexa ting och behoven om hur och vad som ska kunna beskrivas kan variera. Därför lutar vi oss på EU:s rekommendationer som i sin tur bygger på W3C.

@Jonas-Nordqvist sa i Data och API:er:

Sen när man klickar i API så försvinner 6 st av utegymsträffarna. Bland annat Stockholms stads "Utegym ur Hitta Service API)". Och även Lommas som har JSON, men det kanske inte är det som triggar vad som är API eller inte?

I det fallet har ni sannolikt inte märkt upp i metadata att det är ett API. Vissa systemstöd för datapublicering har ännu inte implementerat stöd för API-beskrivningar, vilket också kan förklara varför API:erna "försvinner".

@Nina_Berlin sa i Data och API:er:

Det är bra om man döper sin datamängd, begreppsmängd, terminologi eller specifikation till något bra så träfflistan för våra tre sök blir lätt att tolka vid första ögonkastet.
Sedan har jag en synpunkt till oss själva och det är att vi kanske behöver se över våra riktlinjer till producenterna vad beträffar den här namnsättningen?

Här är de rekommendationer som vi hittills har tagit fram gällande namnsättningar och för användning av tema och nyckelord . Man ska dessutom översätta fritextfält som titel och beskrivning till åtminstone engelska, och komma ihåg att märka upp med språkangivelse pga webbtillgänglighet.

Nina_Berlin

@Maria_Dalhage Japp, vi borde göra en guide för datakonsumenterna. Hittills har vi av naturliga skäl främst fokuserat på dataproducenterna, eftersom vi behöver få in datamängder till konsumenterna.

jonass

@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

@jonass Och dom har även förstått vad jag menar angående separation av datamängder och API...

Maria_Dalhage

@Jonas-Nordqvist jag tolkade fel i mitt sökresultat och du har rätt. API-boxen exkluderar övriga dataformat. Naturligtvis blir det missvisade.

Kristine_

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

Dennis_Priskorn

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

Dennis_Priskorn

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

tove

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

tove

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

Dennis_Priskorn

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

jonass

@Dennis_Priskorn Ändringsström avseende data: https://data.arbetsformedlingen.se/rss/datajobtechdevse.xml i beta version.

Dennis_Priskorn

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