Statistikk FDK - ustabile tall datasett, begrep, informasjonsmodeller, api

[Te-Bert]

Det skjer fortløpende endringer i tallene som inngår i grafene for rapportsiden til FDK - https://data.norge.no/reports med tilbakevirkende kraft.

Dvs at selv om det er normale endringer fra dag til dag blir også tidligere tall endret. I går 14. mars viste kurven for datasett at det ved årsskiftet (1.1.2022) var registrert 1573 datasett.

I dag, 15. mars viser tallet for 1.1.2022 1572 datasett.

Fortløpende endringer får altså tilbakevirkende kraft og tallene for en bestemt tidligere dato kan bli endret flere ganger i løpet av året. Det skaper problemer for årsrapportene fra Digdir (manglende konsistens over tid)

Det er veldig viktig at vi kan forholde oss til stabile tall og at andre brukere i Digdir finner de samme tallene som ble brukt i rapportene året før når det skal gjøres sammenligninger fra år til år. (Ved slutten av hver måned bør alle tall være "låst")

• [ ] #896

[tenstad]

• Bruker dcat:CatalogRecord grafen til å lagre metadata til bruk for statistikk. Der kan vi legge på nye properties om det er nødvendig.
• Høsteren setter arkivert timestamp(s) i dcat:CatalogRecord.
• Regner ut en boolsk publisert property, og lagrer denne.
• Kardinaliteten til issued (https://data.norge.no/specification/dcat-ap-no/#Katalogpost-utgivelsesdato) må endres til 0..n.
• Kan bruke schema:startDate og schema:endDate fra https://www.w3.org/TR/vocab-adms/#schema-startdate.
• Etablerer en egen datastore for historiske data, som har alle versjoner av datasett (hele eller deltas).
• Reports/stats henter data fra ny historisk store.
• Må regne ut state for gitt dato, og så telle, for å få datapunkt / graf.
• Kan bruke generisk cache for å unngå å regne masse diffs hver gang.
• Premiss: endringen kan ikke tilbakedatares.

ETL:

• Har kanskje tilstrekkelig data til å regne ut noe historikk i dag.

[tenstad]

Research:

• https://www.w3.org/DesignIssues/Diff
• https://www.w3.org/2009/12/rdf-ws/papers/ws07#semversion
• https://rdfostrich.github.io/article-versioned-reasoning/
• https://rdfostrich.github.io/article-jws2018-ostrich/

RDF storage solutions:

• https://github.com/AKSW/QuitStore
• https://github.com/rdfostrich/cobra
• https://github.com/rdfostrich/ostrich/

[tenstad]

Solution: https://github.com/Informasjonsforvaltning/rdf-diff-store

[NilsOveTen]

@Te-Bert Vi har nå prodsatt den oppdaterte grafen for datasett. Den er noe forskjellig fra det som var og sikkert ikke helt reell i forhold til det det faktisk var. Men grafen vil fra nå være stabil og tallene som blir produsert fremover vil være reelle.

Skal vi holde på dette issuet frem til alle grafene baserer seg på dette løpet? Er som sagt bare datasett som er oppdatert, grafene til begrep, datatjenester og informasjonsmodeller vil fortsatt være problematiske. Eller skal vi heller opprette egne issue for de 3 andre?

[Te-Bert]

Det er nok det samme behovet for alle katalogene fordi vi rapporterer utviklingen (innholdet i form av antall) i hver av dem årlig/tertialvis (og det kan kanskje skape enda mer forvirring hvis det er ustabilitet i noen kataloger, mens andre har en stabil utvikling). Antar likevel at det er mest bevegelse i Datasett, APIer og Begreper da det er her vi også høster mest fra andre. Noe av problemet skyldes jo at det i eksterne kilder har blitt oppdatert/fjernet innhold i løpet av året (ikke tatt vare på "historikken"). Da får vi et høstegrunnlag som ikke gjenspeiler realiteten fordi noe av det som har blitt fjernet kan ha blitt lagt til for lenge siden og påvirker derfor grafene/tallene som allerede har blitt rapportert flere år tilbake (selv om de faktisk var en del av innholdet på den tiden)

[NilsOveTen]

Så vi beholder dette issuet til alle grafene er oppdatert?

[Te-Bert]

Ja, jeg ville foretrekke det. @KjerstiSteien bør også være kjent med hvordan vi håndterer dette videre

[KjerstiSteien]

Jeg synes vi skal ha egne issues for de ulike katalogene. Det kan være ulik prioritet mellom dem. Dette er tidkrevende arbeid, og da synes jeg det er mer riktig å dele det opp i spiselige bolker.

[KjerstiSteien]

@NilsOveTen har vi laget nye saker for de grafene som ikke er oppdatert? Kan vi lukke denne?

[NilsOveTen]

Hvis jeg forstod @Te-Bert korrekt så ville han helst ha denne som en slags epic til det var løst for alle 4 grafene. Det er snakk om disse 4 issuene:

• https://github.com/Informasjonsforvaltning/fdk-reports-bff/issues/110
• https://github.com/Informasjonsforvaltning/fdk-reports-bff/issues/115
• https://github.com/Informasjonsforvaltning/fdk-reports-bff/issues/116
• https://github.com/Informasjonsforvaltning/fdk-reports-bff/issues/117

[KjerstiSteien]

Endret tittel så den gjenspeiler omfanget av saken.

[KjerstiSteien]

Flytter denne til backlog frem til vi har prioritert opp og løst informasjonsmodeller