Add GITHUB Topics dcat

[salgo60]

Would be nice to make this more findable and add topics

• Topic DCAT
  • same as Wikidata Q16892890
  • maybe also some others like for the organisation DIGG same as Wikidata Q56302089 and dcat-ap-se

More best practices see DIGG related

[jonassodergren]

Tack Magnus! Skulle du kunna bistå med länkningen från wikidata till detta repo? Eller tänker jag fel nu.

[jonassodergren]

Jag kan berätta vad Musk inte kommer köpa, min kod ;). Det viktigaste du tar upp (enligt mig) är behovet av bestående identifierare till ting/objekt. 1. Mitt förslag är att vi anordnar en workshop med DIGG/AF/NOSAD som enbart handlar om bestående identifierare under hösten. 2. https://sweopendata.wikibase.cloud/wiki/Main_Page är ju väldigt bra! Får jag skriva ett inlägg om din kurering på dataportal.se den behovslistan? Jag hade missat den sidan.

[jonassodergren]

Tror att det behövs en träff under hösten! Så jag går vidare med den bokningen iaf =). Beakta exempelvis https://taxonomy.api.jobtechdev.se/v1/taxonomy/main/concepts?id=XWKY_c49_5nv , tror att flertalet befintliga API:er med små medel kan uppnå beständiga identifierare. Rest-API-profilen tycker jag är ett bra exempel på initiativ som försöker ensa URI-strukturer. Ett naturligt nästa steg för API-Profilen är just att enas om ett ramverk för beständiga identifierare. Så det finns initiativ som pekar i rätt riktning!

[jonassodergren]

Actions:

1. @fredriknordlander add topic "DCAT" to this repo (i think repo-owner can click on settings an add a tag)
2. Implementation of persistent identifiers must be done by the producer of a data set. A validation in this software is not technically possible at this stage.

[jonassodergren]

Jag tror också på DOI men har inte implementerat en mekanism för det (ännu!). Framförallt för formella dokument och beslut som troligtvis behöver en egen infrastruktur för att möjliggöra en "resolv" (vad heter det på svenska?), som är separat från en mer temporal URI/URL -struktur. För ting som inte är lika formella såsom "årets yrken"/"bra badplatser" etc kanske det inte krävs en infrastruktur utan ramverk/konventioner för att bygga hållbara URI/URL -strukturer som kan fungera som identifierare.

[jonassodergren]

Mycket matnyttigt i denna tråd! =)

1. Vi är 100% överens om att det borde vara intuitivt. Tänk om det skulle vara intuitivt OCH utan belagt med byråkrati för att skapa en bestående identifierare. En sådan idé slår an på att lösningen från start bör vara distribuerad och inte låst till en organisation. Problemet med digitaliseringen är ju som oftast att effekten blir en centralisering. (har inte forskat på den slutsatsen).
2. Information bör rimligen inom det offentliga hanteras utifrån principen API-first. En tanke har slagit mig vid flertalet tillfällen, eftersom utvecklingen av tillgång till "öppna data" är kostsam och går för långsamt borde fler strategier sättas i bruk. Hur kan exempelvis en invånare utan att mata in ett lösenord få tillgång till så väldigt mycket information på alla offentlig organisationers hemsidor redan idag? Rimligen finns det tusentals API:er som förser dessa offentliga organisationers webbsidor med information som redan är öppet publicerade. Ställ krav på att dessa API:er ska synliggöras och kunna användas av alla. Över en natt skulle hundratals API:er vara tillgängliga för alla. Är det lika snyggt som det skulle kunna vara? Absolut inte. Men om värdet finns i att data blir tillgängligt så vore det kanske ett bra komplement. Roligt exempel på information som finns utan krav på lösenord. Om jag inte missminner mig brukar denna data och tjänst efterfrågas år efter år. https://minkarta.lantmateriet.se/api/searchservice/searchinput?searchtext=hälsingegatan%2045
3. DOI och liknande system är såklart lovande. Men jag tolkar det som att den publicerande organisationen i slutändan måste berätta (vilken URI/URL) konsumenten i slutändan når innehållet på. Tillbaka till ruta ett alltså, vi vet att CMS-system är kantade med problem och innehåll ändrar plats konstant. Information bör nog alltid exponeras via API:er för att uppnå en hållbarhet.
4. Sen gäller det också att hitta en domän eller ett användningsfall som skulle vinna extra mycket på bra hållbara identifierare. Ett lyckat exempel kanske kan vara på sin plats så de som vill kan kopiera lösningen.