Data och 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.
-
@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.
-
@jonass Och dom har även förstått vad jag menar angående separation av datamängder och API...
-
@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.
