Data och API:er
-
Jag kommer från en lång diskussion om hur data, datamängder, metadataspecar och API:er hänger ihop. För mig bildar det här en helhet, men eftersom jag varken är dataspecialist eller arkitekt lyckas jag inte förklara mitt resonemang på ett tillräckligt tydligt och korrekt sätt, så det logiskt går att följa i alla nödvändiga detaljer.
@Kristine_ , @jonass, @Maria_Dalhage, ni har lärt mig mycket. Kan ni hjälpa oss att reda ut även den här frågan? @tove, du får också gärna haka på, jag är nyfiken på hur du ser på det här.
@Jonas-NordqvistCSN
-
@Nina_Berlin Vet inte om jag förstår frågan.
Men exempelvis för Platsbanken så adderas många nya annonser varje minut. Våra användare (5 miljoner anrop) varje dag vill verkligen ta del av de senaste publicerade annonserna. I detta scenario med en datakälla som är i ständig förändring är API ett av de mest effektiva sätten att förmedla datan.
Sedan är det bra (krav kanske) att datat som levereras via API:et har ett öppet format så att inte API-integrationer medför inlåsningar till en leverantör etc. Ett viktigt steg för att kunna nå interoperabilitet tror jag är öppna format.
Men ett API är ju en form av mjukvara som kräver en it-avdelning som tillhandahåller och kanske utvecklar API:et för att datat ska kunna delas. Så i de fallen där datan är statisk och kanske oföränderlig (typ en rapport etc) kanske det finns enklare sätt att dela data, dvs utan att utveckla ny mjukvara. Så det gäller att passa sig så att inte API:et i sig blir en inlåsning.
-
@Nina_Berlin För mig är data bara data. En datamängd är uppsättning av data som tillsammans har nåt sorts mervärde. Metadataspecifikationen är information om vilken data datamängden innehåller och hur den är strukturerad etc. API är ett (av flera) sätt att få åtkomst till data i datamängden.
Eller?
/Jonas Nordqvist
Storsthlm -
@Jonas-Nordqvist Bra om du kan berätta för @jonass hur du ser på API:er vs data så han kan berätta hur han resonerar. Om jag tolkar dig rätt @Jonas-Nordqvist så tycker du att API:er inte hör hemma i en datasök, eftersom det bara är data man är ute efter när man söker där och inte API:er.
-
@Jonas-Nordqvist @jonass Jag hittade den här konceptuella skissen i specen för Byggblock API-hantering, det är kanske den jag skulle vilja höra er resonera kring tillsammans.
Hur hänger data och API:er ihop? Är API:er egentligen irrelevant när man är ute efter att hitta data?
Dokumentet finns längst ner på den här sidan: https://www.digg.se/ledning-och-samordning/ena---sveriges-digitala-infrastruktur/byggblock
CSN
-
@Nina_Berlin I första hand är konsumenten ute efter data som de kan vidareutnyttja. Graden av möjlighet till vidareutnyttjande kan skilja sig från datamängd till datamängd beroende på distribution. Att kunna söka på distributionssätt är självfallet bra, men jag tror inte att konsumenterna i första hand ute efter att få vilken information som helst bara det är ett bra API. Det är alltid i kombination med en datamängd.
Så jag förordar att de som förvaltar dataportalen i första hand ska göra det enkelt för konsumenten att hitta datamängder. Att i sökrutan skriva att man kan söka efter "Sök data & API:er" är lite konstigt då man egentligen söker efter en datamängd. Vill man enbart få resultat med API så finns ju en kryssruta vid sidan om märkt API.
Det står på https://docs.dataportal.se/ att du här kan söka efter "datamängder, specifikationer och begrepp". Det står inget om att man ska kunna söka efter API. Därför anser jag att det inte ska stå i sökrutan "Sök data & API".
I bilden på konceptuell arkitektur framgår enbart en process för att söka efter datamängder. Inget om direkt sökning på API:er. Dessutom säger processen att det är "datamängder" dataportalen medger sökning för. Inte "data". Så istället för "Sök data & API:er" kanske det bör stå "Sök datamängd".
/Jonas Nordqvist
Storsthlm -
@jonass och @Jonas-Nordqvist håller helt med om er syn på data och API:er.
Jag tolkar det som att dina @Jonas-Nordqvist synpunkter ligger på Dataportalens sök- och filtreringsfunktion?
När jag ser på dataportalen SÖK tänker jag att vi borde se över vad vi filtrerar på samt skapar fler metadatataggar för att hitta rätt.
Data och API bör vara samma. Däremot ska man kunna sortera bort specifikationer och begrepp från själva datamängderna.
Finns det fler som har synpunkter? Passa på
Community Manager NOSAD - Network Open source and data
-
@Maria_Dalhage Jag har en synpunkt som främst riktar sig till dataproducenterna. 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? -
@Nina_Berlin Tänker att det är viktigt att kunna filtrera ut API:er. Men hur det benämns i sökrutan ser jag mer som en UX-fråga, har ingen speciell synpunkt på benämning.
En sökfunktion som enbart opererar på datasetets eller API:et namn blir i sin natur ganska begränsad.
Varje dataset på dataportalen kan taggas med metadata ("nyckelord"). Att på ett systematiskt sätt tagga dataseten (@Magnus-Sälgö har snokat fram en standard) tror jag skulle ge mest effekt i sökningar.
-
@jonass Behöver vi göra en förändring i DCAT-AP-SE-specen för att åstadkomma det här? Eller kan vi lösa det med ren UX?
CSN
-
@Nina_Berlin Redan nu kommer ju nyckelorden med i "skördningsfilen" (a la dcat-ap-se) till dataportalen. Jag gjorde ett testskott och sökte på ett nyckelord från en av Umeås datamängden. Ett nyckelord som inte fanns med i namnet på datamängden. Den datamängd jag var ute efter dyker upp i sökresultatet
Min uppfattning är att sökfunktionen funkar bra redan idag. -
@Jonas-Nordqvist sa i Data och API:er:
Sök datamängd
Ingen som har några synpunkter på mitt förslag på att byta namn från "Sök data & API" till "Sök datamängd"?
/Jonas Nordqvist
Storsthlm -
@Jonas-Nordqvist Har som sagt ingen stark åsikt. Men tycker nog dagens formulering fungerar bra.
-
@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.
/Jonas Nordqvist
Storsthlm -
@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.
Community Manager NOSAD - Network Open source and data
-
@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
Storsthlm -
@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?
/Jonas Nordqvist
Storsthlm -
@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
Community Manager NOSAD - Network Open source and data
-
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.
-
@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.
