Prototyp avseende api länkade data för events

jonassodergren commented 2 years ago

Event 20220503: https://nosad.se/api/events/event-nosad-20220503/

Presentationer avseende event 20220503: https://nosad.se/api/events/event-nosad-20220503/presentation/1 https://nosad.se/api/events/event-nosad-20220503/presentation/2 https://nosad.se/api/events/event-nosad-20220503/presentation/3 https://nosad.se/api/events/event-nosad-20220503/presentation/4

Exempelvis presentation 2 har en länk till wikidata för den person som talade.

https://nosad.se/api/events/event-nosad-20220503/presentation/2

jonassodergren commented 2 years ago

Har medvetet inte följt någon standard för event ännu. Fokus är på att erbjuda direktlänkar till event, dess ingående presentationer och en extern länk till person om möjligt.

jonassodergren commented 2 years ago

Identifieraren https://nosad.se/api/events/event-nosad-20220503/ får rimligen betraktas som persistent. Med konventionen https://nosad.se/api/events/ + slug "event-{organisation}-{datum}" kan rimligen alla som vill skapa ett event. Mitt förslag att identifieraren ska ha en semantisk mening är säkert omtvistad. Men jag föreslår att sluggen inte är en UUID i detta fall.

salgo60 commented 2 years ago

Snyggt

Coolt vore att skala det för alla dokument, alla kommuner och myndigheter...

Även ha content negotiation vore snyggt...

jonassodergren commented 2 years ago

Tänker du på att serva json och ett format som fungerar bra i webbläsaren (html), eller tänker du på json och låt säga xml?

salgo60 commented 2 years ago

@jonassodergren Jag ser det här som den komponent jag saknar med anslagstavlor, DIGGs dokument, myndigheters författningar, NAD .... där ett av de lysande undantagen är Riksdagens Öppna data -->

ger oss maskinläsbar data
kan gissar jag användas för ämne, person, event, möte, protokoll, planerade utegym, färdiga utegym 😄 ......
- en utmaning är vad kan lagras om en person
  - att inte ha en identifierare för personer som Kungliga biblioteket med LIBRISXL valt många ggr där det bara står "en text sträng" är helt galet för då kan jag inte referera till att exempelvis en person skrev en bok eller ett NOSAD föredrag hölls av en person se Tim Berners Lee resonemang The Next web 5:10
kan koppla ihop dessa entiteter med varandra och som i dina exempel kopplar du det till externa entiteter dvs. 5 star data
även vara nyckel i att minska all denna länkröta som skapas idag dvs. samma problem jag identifierare med Nobelprize.org 2019 #13 länk dvs. samma problem DIGG har, Esam har med att referera författningar/dokument som inte "finns längre", Dataverkstaden pratar om planerade dataset i ett excel dokument identifierade med textsträngar
- lösa det "problem" Domstolsverket säger uppstår då myndigheter upphör med att författningar "försvinner"....
  - en vision kunde vara att se detta som ett nav i en mer kontrollerad dokumentprocess där Riksarkivet NAD är en del
  - idag så försvinner författningar om en myndighet upphört en "central" funktion som detta borde överleva så vi vet vilka dokument som skapats se Esam alla tomma referenser
idag med massa hittepå unika id:n ex. utegym har kommunkod nummer där kommunkoden inte är persistent är ett antipattern som vi måste bort från se diskussion DIGG forum NSÖD kommentar, diskussion om kommunkod / WD sökning där kommunkod ändrats

1) content negotiation 1-1) en webläsare som anropar nosad.se/api/events/event-nosad-20220503/presentation/1 kommer till websidan som är landningssidan för eventets presentation 1 jmf.... jmf Nobelprize.org https://www.nobelprize.org/laureate/6 landar på Marie Currie där båda hennes pris finns samma med årets 743 --> landningssidan https://www.nobelprize.org/laureate/743) 1-2) ett anrop med "application/json" --> ger json 2) bra med stöd för extension 2-1) Exempel iNaturalist Skata = taxa/891696 = P3151:891696--> 2-1-1) websida https://www.inaturalist.se/taxa/891696-Pica-pica 2-1-1) json https://www.inaturalist.se/taxa/891696-Pica-pica.json 2-2) August Strindberg = tr574vdc33gk2cc = P5587:tr574vdc33gk2cc 2-2-1) websida https://libris.kb.se/tr574vdc33gk2cc 2-2-2) json-ld https://libris.kb.se/tr574vdc33gk2cc/data.jsonld
2-2-3) turtle https://libris.kb.se/tr574vdc33gk2cc/data.ttl 2-2-4) RDF/XML https://libris.kb.se/tr574vdc33gk2cc/data.rdf

jonassodergren commented 2 years ago

Både webapp och api borde kunna ha samma URI-struktur. Åtminstone borde även webbplatser ha en känd URI-struktur och inte "länkröta". Detta vore ett väldigt snyggt mönster för e-tjänster generellt. För just nosad.se vill jag undvika att underhålla två sidor utan försöka ha en master. Vet ej hur jag ska åstadkomma detta just nu. =) Detta mönster kommer dock kräva lite mer data-driven design vs dagens mjukvarudrivna-design.

                                                 https://en.wikipedia.org/wiki/Dependency_inversion_principle
                                                              |
                                                              |
+---------+                                                   |
|         |                                                   |
|         |                                                   |
|  UI     |                                                   v
|         |                            +--------+   +--------+  +---------+
+----+----+                            |        |   |        |  |         |
     |                                 | UI     +-->|        |<-+         |
     |                                 |        |   |  API   |  | Storage |
+----v----+                            |        |   |        |  |         |
|         |                            +----+---+   +----+---+  +-----+---+
|   API   |    -------------------->        |            |            |
|         |                                 |            |            |
|         |                                 |            |            |
+----+----+                                 |            |            |
     |                                      |      +-----v----+       |
     |                                      +----->|          |       |
+----v----+                                        |          |<------+
|         |                                        | Data     |
|         |                           UI och api   |          |
| Databas |                                        |          |
|         |                                        +----------+
+---------+                         1. Persistenta identifierare

                                    2. Känd URI struktur för api och UI

salgo60 commented 2 years ago

@jonassodergren Det mönster jag gillar i Wikipedia är att det alltid finns ett meny val Wikidata --> att man kan komma åt det maskinläsbara data.... tycker att det persistenta id:t borde finnas lika enkelt på alla kommuners och myndigheters sidor och även på DIGG och Anslagstavlor (user case E) video tankar

gjonor commented 2 years ago

Fortsätter här från påbörjad diskussion i ärende om synk i presentationslistor.

Det låter väl som ett rimligt steg att webbsidan baseras på datalistor med presentationer, evenemang och media. Nu ser det ut som innehållet ligger i en wiki på GitLab, och på något sätt hamnar på webbplatsen, jag vet inte hur det fungerar?

https://gitlab.com/open-data-knowledge-sharing/wiki/-/blob/master/www.md https://gitlab.com/open-data-knowledge-sharing/wiki/-/wikis/Digital-Workshopserie

Hur är det tänkt med API-prototypen var data ska lagras och hämtas?

API:et presenterar data som finns någonstans, men som ett första steg skulle det ju fungera att lägga CSV-filen med presentationer i NOSADs kodförvar och använda den som underlag för sidorna och som gemensam aktuell datakälla.

Datan kunde kompletteras med URI:er för händelser och media enligt föreslaget mönster tidigare i ärendet.

salgo60 commented 2 years ago

@gjonor Det jag saknar är att det pratas om en dokumentcykel dvs. att följa information från det föds till det arkiveras... se https://github.com/Riksarkivet/dataplattform/issues/9

Naturligt vore om DIGG hade en vision, idag känns det som DIGG mer är upphov till mer problem länk, ingen verkar skrika till att dom måste skärpa till sig... känns precis som Europeana och 3500 tysta museer som inte reagerar på 10 år...

salgo60 commented 2 years ago

Refererade denna post på sv:Wikipedia Wikidatafrågor

Bubble chart antal externa identifierar i Wikidata per land

tweet Ontologies are expensive - property creation in Wikidata is a major bottleneck

gjonor commented 1 year ago

Hej, finns strukturerad data för NOSAD events/workshops/föreläsningar? Hur får jag enklast tillgång till en komplett lista, gärna med datum, agenda, titel/ämnen, organisation och eventuella länkar till video eller andra resurser.

jonassodergren commented 1 year ago

Hej gjonor, Den primära källan är ostrukturerad data, https://nosad.se/workshops. Sen diskuterar vi i denna tråd hur vi bäst skapar strukturerad data också. Det är såklart "enkelt" att skapa strukturerad data, men designmålet är att det ska vara enkelt att underhålla och inte innefatta ytterligare driftkostnader i formen av team som behöver förvaltningsansvar för en databas etc, eller nyttja molntjänster som har oklara driftavtal angående personuppgifter.

gjonor commented 1 year ago

Vad sägs om att lägga evenemang och föreläsningar i en eller flera tabeller i CSV-textformat liknande den @salgo60 skapade? Nya workshops läggs in i tabellen som kan vara underlag för listan på webbplatsen och samtidigt är maskinläsbar.

salgo60 commented 1 year ago

En variant är att skriva direkt i Wikibase.cloud och testa om det funkar

Ser hur snabbt det går att jobba med Wikidata och hur kvaliten är 1000 ggr bättre än dataportalen...

Finns säkert utmaningar men tror det är nyttigt att testa och lära sig vad 5-star data i praktiken innebär... vi ser alltför mycket att den erfarenheten saknas....

Jag är ute i skärgården åter tisdag...

jonassodergren commented 1 year ago

Exakt! Håller på att utvärdera https://www.gnu.org/software/recutils/manual/ som alternativ till CSV också. En databas som består av en fil som är människoläsbar och maskinläsbar. Filen borde vara enkel att editera av flera och kan hanteras på GIT.

jonassodergren commented 1 year ago

Jag är ute i skärgården åter tisdag...

Låter kallt Magnus. =)

salgo60 commented 1 year ago

Seglarhotellet Sandhamn har värme.... var lite kallt vid bastuflotten men vi överlever...

gjonor commented 1 year ago

Jag kan hålla med @salgo60 att det är att gå över ån efter vatten att inte lägga in informationen i Wikibase direkt, där finns också ett redigeringsgränssnitt som är enkelt att använda. Wikibase.cloud hostas väl av Wikimedia Deutschland. Så för den som ska modellera och hålla informationen uppdaterad är nog Wikibase en bra lösning.

NOSAD använder redan en wiki som är hostad av GitLab, så steget är kanske inte så stort egentligen då Wikibase.cloud också är en hostad wiki-programvara?

GNU Recutils ser intressant ut, har inte hört talas om det tidigare. Jag vet inte hur ekosystemet ser ut men i Wikibase.cloud finns ju CMS, API och SPARQL endpoint inbyggt så att säga.

jonassodergren commented 1 year ago

Absolut, wikibase.cloud är intressant att utvärdera och prova. Men det är väl en stängd beta etc.

salgo60 commented 1 year ago

Ni kan köra i dom vi har satt upp annars går det nog att fixa

Som sagt tror det är viktigt att börja testa vad 5 stardata innebär.... man lär sig mycket att göra det @gjonor gjorde med reconciliation etc... tycker vi inte laddat i hur Nosad data skall se ut med avseende nyckelord etc.... vore intressant att hitta en kedja mellan målet av vad NOSAD skall leverera och inom vilka områden presentationer levereras... vilka organisationer som engageras för att leverera presentationer osv. detta borde kopplas ihop med

verktyg för vetenskapliga publikationer https://scholia.toolforge.org/
Riksdagens motioner som kategoriseras i Wikidata https://github.com/salgo60/NOSAD-POC-Wikidata/Kopplingssprint%202022.md

gjonor commented 1 year ago

Verkar inte vara något problem att ansöka om early access och få ett konto. https://www.wikibase.cloud/

Annars prova gärna att uppdatera informationen på oswald-instansen så kan vi skapa frågor som hämtar aktuell data för presentation på webbplatsen, och arbeta vidare med datamodellen enligt schema-förslag. https://oswald.wikibase.cloud/wiki/Special:WhatLinksHere/Property:P20

salgo60 commented 1 year ago

Exempel på utmaningar som kommer med 5-star data som vi inte ser ens diskuteras på dataportalen vilket jag tolkar att man inte ens förstår problemet/utmaningen

Riksdagens Öppna data måste kopplas ihop med Kungliga Bibliotekets data
Uppsala University Welfare Analytics riksdagen-corpus- Stable URI for protocols and protocol pages #208

Riksdagens historiska data har gjorts om till TEI och same as Wikidata se länk

nu vill man uppnå att ha persistenta URIer finns hos KB
Riksdagens Öppna data är idag bra data men saknar externa identifierare
- skall vi nu undvika nya Silos och göra detta riktigt skall inte en hobby site som Wikidata vara den som kopplar ihop saker utan det skall finnas kopplingar mellan Kungliga biblioteket och Riksdagens öppna data
- idag uppfattar jag både KB och Riksdagens öppna data som princip Silos och ovana att ha en öppen spårbar dialog mellan varandra....

Tycker dialogen jag ser om hur uppladdat data till Digg skall bli bättre som helt galen där ett bättre UI tror man skall lösa bristen på 5-star data....

Lösningen jag ser är att börja jobba med och använda datat och involvera personer kunniga på området

salgo60 commented 1 year ago

Verkar inte vara något problem att ansöka om early access och få ett konto. https://www.wikibase.cloud/

Lydia product owner pekar i Telegram Wikibase.Cloud / WBStack på https://lime.wikimedia.de/index.php/717538

gjonor commented 1 year ago

Jag har tittat lite på innehållet på nosad.se workshops och organisationer, men det verkar för oregelbundet för att sammanställa om webbsidorna är källdatan i nuläget. Innehållet måste på något vis redigeras primärt i en strukturerad databas för att kunna presenteras på ett effektivt sätt eller arbetas vidare med.

salgo60 commented 1 year ago

Jag har tittat lite på innehållet på nosad.se workshops och organisationer, men det verkar för oregelbundet för att sammanställa om webbsidorna är källdatan i nuläget. Innehållet måste på något vis redigeras primärt i en strukturerad databas för att kunna presenteras på ett effektivt sätt eller arbetas vidare med.

Håller med men någon gång måste DIGG/NOSAD ta klivet är min tro... känns helt fel att bygga om dataportalen, skapa pdf med vaga råd och inte själv producera 5-star data, persistenta identifierare, SPARQL... trovärdigheten blir låg och kvaliten säkert ännu sämre, känns som DIGG fastnat som forum poliser men inte orkar göra skitjobbet att producera bra data... satt igår på båten från Sandhamn och prata om detta att i bankvärlden är det självklart att system A kan skicka data till system B medans data staten/kommuner producerar till stor del verkar inte ens ha en vision att det skall hänga ihop... känns som dom bott under en sten och saknar visioner mer än att få likes på Linked in....

se #85

samma känsla när man läser motiveringen varför ingen styr upp Anslagstavlorna #15

data.europa.eu/en/academy

Har massa saker för att komma igång snabbare

SPARQL

Searching data with SPARQL

Data citation

Data citation: a guide to best practice (data citation, citation, interoperability)

Publications Office of the European Union, Jessop, P., Data citation : a guide to best practice, Publications Office of the European Union, 2022, https://data.europa.eu/doi/10.2830/59387

salgo60 / NOSAD-POC-Wikidata