Code Monkey home page Code Monkey logo

dataplattform's People

Contributors

arnjoed avatar dependabot[bot] avatar marrosj avatar nilsw-ra avatar ra-magnus-welander avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar

dataplattform's Issues

Exempel på maskinläsbara kopplingar mellan NAD och leverantör av data

Önskan en dokumenthanteringsprocess som är maskinläsbar där även NAD har koppling till dokumentflödet innan dokumentet arkiveras?

Statens framtida ansvar för att göra lagar och förordningar elektroniskt tillgängliga på ett överskådligt sätt bör därför inte upphöra endast därför att författningen i fråga upphävs, om den upphävda författningen fortfarande kan vara av betydelse. Att med hjälp av SFS konstruera en databas där varje grundförfattning finns i konsoliderad form i samtliga olika lydelser författningen har haft genom hela historien

Jag tycker mig sakna idag en maskinläsbar dokumenthanteringsprocess där det som levereras till NAD kopplas ihop med "leverantörens" maskinläsbaradata och allt producerat har persistenta identifierare som kan användas över tid dvs. hela informationens livscykel...

Fråga: Finns det bra exempel på hur NAD kopplar levererande myndighet/kommun/museum som kan inspirera andra eller finns det planer/visioner?

Status idag som jag ser det verkar vara att myndigheter som upphör så "försvinner" deras författningar se svar Domstolsverket och Esam som publicerar dokument som refererar författningar som inte hittas via dagens lagrummet.se...

I ett sund dokumenthanteringsflöde borde

  • bör dokumentcykeln vara tydligt identifierad

  • skall finnas maskinläsbar data för hela dokumentetslivcykel även då dokumenten har arkiverats och/eller en myndighet upphört

    • datat som finns maskinläsbart hos en myndighet som upphör även det arkiveras hos NAD och vara åtkomligt via ett API (gärna samma anrop)

  • att persistenta identifierare för dokument hos respektive myndighet/kommun/??? finns som nyckel hos NAD

    Fråga 2: Vad står vi idag med en kontrollerad/tydlig dokumentprocess? Äger någon problemet och finns det en konkret plan/ publik backlog? dvs. typ det som sas i Ds 1998:10 sidan 55

    Statens framtida ansvar för att göra lagar och förordningar elektroniskt tillgängliga på ett överskådligt sätt bör därför inte upphöra endast därför att författningen i fråga upphävs, om den upphävda författningen fortfarande kan vara av betydelse. Att med hjälp av SFS konstruera en databas där varje grundförfattning finns i konsoliderad form i samtliga olika lydelser författningen har haft genom hela historien

där jag ser NAD som en naturlig del i detta flöde eller kanske tom navet dvs. att redan innan ett dokument arkiveras hos NAD så skall NAD ha metadatat

Vore bra med lite exempel så man kommer igång snabbare...

Önskan 1 Vore bra med mer Python/Notebook exempel för Arkiv

Skriver nu en notebook som hämtar Stockholms stads skolregister och sedan kollar agent id hos Riksarkivet....

  • körde webscraping först
  • såg sedan att ni har ett API med XML men gav upp.... tror många med mig gillar JSON api:er mer än XML

Fråga 2: finns enkelt sätt att få ut alla arkiv om skolor med metadata? se GITHUB issue 1 att ha Svenska skolor över tid som metadataset i Bildhistoria

Exempel data Stockholms Stads skolregister hos Stadsarkivet har för

Folkskola, Försöksskola, Inbyggd realskola 1955-1961, Enhetsskola 1959-1962 med åk 7-9, Grundskola åk 1-9 1962-1975, åk F-6 from ht 1975.

image

känns logiskt att det borde gå att söka ut allt data som kommer från kommuners olika skolregister hos er....

I wikidata har vi idag samma struktur som Skolverket/SCB(om jag fattat rätt) dvs

image

Önskan 3 vore smidigt om även Riksarkivet hade koppling till SCB/Skolverkets Skolenhetsregister

Wikidata

Riksarkivet - web arkiv?

Om jag fattat @dpriskorn rätt har EU skapat ett web arkiv med hjälp av Internet archive borde inte vi ha det i Sverige och är inte Riksarkivet en bra kandidat för detta?

image

EU Web arkiv

Problem vi ser idag med myndigheter och kommuners dokument

image

Även att myndigheter/kommuner i sitt metadata skall peka på detta arkiv dvs. motsvarande Wikidata Property Property:P1065

Riksarkivets visioner 2018

Status: öppen och fri digital arkivinformation i två steg

Ni skrev 2017

Riksarkivet planerar att genomföra förändringen mot öppen och fri digital arkivinformation i två steg. Först tas abonnemangsavgiften till den digitala forskarsalen bort. I ett andra steg görs informationen tillgänglig som öppen, länkbar och maskinläsbar data.

  • Den blir då en del av den växande mängden öppna data från offentlig sektor. Min förhoppning är att innovatörer tar chansen och skapar bra produkter för medborgarna, säger Karin Åström Iko

Även denna tweet apr 9 2021 ger intryck av att planer finns

image

Detta kom upp för att vi på Wikidata funderare över att skilja dödsplats och var en person är skriven från varandra - idag geggar vi ihop det på wikidata. Min tro är att skulle Riksarkivet ha varje kyrkbok som öppen länkad data med ett API som har metadata

  • persistent identifierare - borde fungera bra med NAD plus bokens Bokstav och nummer
  • tidsperiod
  • församling
  • typ av kyrkbok: dödbok, födelsebok, vigselbok, husförslängd....
  • NAD
  • antal bildsidor
  • url
    • iiif
  • digitaliserad - boolean
    • datum digitaliserad
  • Tora identifierare

så kan det vara källa till dödsorten och vi kan ur källorna se var personen var skriven på ett tydligare sätt.... Idag kanske vi kan från den textsträng vi har se NAD och BILD id rel enkelt men länkade data är att föredra alla dagar i veckan - se nedan

Status idag:

image

image

Exempel wd:Q6229552 A. A. Waldenström har som källa Storkyrkoförsamlingens kyrkoarkiv, Död- och begravningsböcker, huvudserie, SE/SSA/0016/F I a/9 (1875-1894), bildid: 00007276_00277, sida 275 -->

image

  • Församlingarna uppfattar jag har persistenta identifierare med NAD (eller Tora identifierare)
  • men vi saknar idag API till detta data?!?!? och API där vi kan hämta bildid: 00007276 och få koppling till NAD/församling

Vem har kopplingar till en viss kyrkobok och sida

När RAÄ anordnade en workshop om IIIF pratade jag med Riksarkivets Olof Karsvall om en tanke att man skulle kunna se på en kyrkbok vilka externa som länkar en viss sida dvs. ungefär det som Wikidata gör med Scholia och citation graphs , anledning att citation graphs fungerar är just användandet av persistenta identifierare som DOI och ORCID dvs, samma tänk bör finnas med kyrkböcker och min tro är att dom stora vinnare då skulle förutom släktforskare även vara kriminaltekniker se "SILOS -> Kunskapsdatabaser för släktforskning ett hjälpmedel för att matcha DNA segment med person" (ett mycket starkare argument en den bandtyp som lyftes fram i en DN debatt artikel om varför kulturarvet skall ha pengar 2021 jan 4)

Där kunde oskyldigt utpekade personer rentvås tack vare att ett ålderstiget VHS-material fortfarande var spelbart och öppnade för en ny utredning

Huvudfrågan förtydligad

men svara gärna på mina andra spekulationer/funderingar

Riksarkivets dataplattform är det en del av öppen fri arkivinformation där öppen, länkbar och maskinläsbar data levereras för kyrkböckerna. Om ja finns detta levererat om ej levererat vad skall levereras och när? Har ni diskuterat detta med några andra externa som tänker sig implementera att koppla sig till kyrkböckerna som länkade data och har ni en dialog med Arkiv Digital som också levererar scannade kyrkböcker?

OT: Jag tror att skall forskarna börja jobba med kunskapsgrafer se "Sveriges Riksdag 1867–2022: Ett ekosystem av länkad öppen data" så skall även kopplingen till kyrkböcker vara länkade data. Har ni en dialog med dom eller andra?

OT2: era kyrkböcker finns idag på en IIIF plattform har jag förstått finns det några exempel hur det används? EN tanke jag hade var att ha transkriberingen av en del av kyrkboken i Wikidata och sedan kunna visa upp det som en IIIF annotering se tweet 2019

image

OT 3: Jag gjorde ett gigg 2018 med Arkiv DIgital och kyrkböcker - T199907 / FB så dom har använt Wikidata för att placera kyrkböckerna på en karta "Ett helt nytt satt att navigera i arkivdigital"

Beskriver Riksarkivet sitt data

På Open science i Stockholm pratar man om att data måste beskrivas bland annat Michael Arentoft Head of Unit, Open Science, DG R&I, European Commission och han pekade även på att kunskapsgrafer tas fram se openaire

  • i WIkidata testar vi nu ShEx se #129 - se fråga #144 Umeå Familia
    • datat sig själv är ofta Things not strings där Things i sin tur beskrivs i en eller flera Wikipedia artiklar... ibland lite spretigt men det arbetas hela tiden med kvaliten...

Finns Riksarkivevts dokumentation samlade om ert data? och hur beskrivs datat idag och vad är framtidsplaner som att ha 5 star data

Folkräkningar (Sveriges befolkning) 1930 - forskningskvalitet på metadata?

se welfare-state-analytics/riksdagen-corpus/issues/243#issuecomment-1495777133

Fråga:

  1. Finns API till detta data - jag såg att trackuback använder Riksarkivet kyrkböcker via API var är bästa dokumentationen
    1. exempel kod?
    2. finns reconciliation stöd direkt från Open Refine
  2. Finns kvaliten/värdemängder dokumenterade på exempelvis förmögenhet och skolutbildning
  3. Är detta bästa platsen för att kommunicera med er om detta för projekt welfare-state-analytics/riksdagen-corpus?

Maskinläsbardata önskas så vi kan för ett visst datum veta om dödboken i församlingen finns släppt

User case 1: Jag som släktforskare vill komplettera med referens till dödboken

  • när en dödbok finns släppt så skall denna uppgift komma upp på min att göra lista

Gränssnitt önskas:

  • SPARQL med federation Wikidata att föredra
  • annars Notebook och json API

User case 2: Vi letar dödsorsaker för svenska Riksdagsmän #126, dödsorsaken finns ofta i kyrkboken --> praktiskt att kunna lista dom kyrkböcker som finns släppta och digitaliserade idag där vi saknar dödsorsak för svenska Riksdagsmän

IIIF Manifest har olika etiketter på olika platser i RDF-grafen

Nedan finns ett exempel på hur Collection nivån skiljer sig ifrån manifest nivån men problemet är systematiskt.

https://lbiiif.riksarkivet.se/collection/arkiv/TJkFcljeTasiqC1rTgCU30

<https://lbiiif.riksarkivet.se/arkis!K0024239/manifest>
  a <http://iiif.io/api/presentation/3#Manifest> ;
  rdfs:label "0001 1. [Stockholm.]"@sv .

https://lbiiif.riksarkivet.se/arkis!K0024239/manifest

<https://lbiiif.riksarkivet.se/arkis!K0024239/manifest>
  a <http://iiif.io/api/presentation/3#Manifest> ;
  rdfs:label "Handritade Kartverk, Band 11: Svenska planteboken (Örnehufvud) , SE/KrA/0414/0011/0001 (162-?-163-?)"@sv .

Problem kan sedan uppstå när man indexerar dessa tillsammans och får två rdfs:label utan vidare kontext. Det är också lite konstigt i vissa IIIF gränssnitt där etiketter används och kan skilja sig åt på olika ställen i gränssnittet.

Wikidata <-> Riksarkivet <-> Wikidata Riksdagens corpus

Nu när API är på G borde vi kunna koppla ihop oss mer effektivt.... gissar att saker som ni tittar på med LLM etc... skapar möjliheter jag har svårt att inse... vilka skall ni koppla ihop er med? är Riksdagen Corpus en kandidat....

Förslag: Kanske vi skall träffas efter sommaren och snacka hur denna matchning skall ske på bästa sett.... det är en stort jobb men kan nog göras mer eller mindre effektivt plus att det är bra att veta vilka ambitions nivåer som finns - min lekstuga med Riksdagsmön och NAD #104 / svenska församlingar 2018

Alternativt: att ni samlar fler aktörer - vi får se om DIGG får fart och kan leverera något bra med persistenta identifierare... så borde dom gubbarna vara naturliga partners... känns som persistenta identifierare utan Riksarkivet by definition är fel tänkt...

Tankar:

  1. Kandidat Riksdagens Corpus som idag "bygger sitt data" på Wikidata men förhoppningsvis kommer att fixa bättre data
    • deras planer med egen persistent identifierar #269
    • lesson learned 2023 är att detta projekt idag jobbar perfekt med GITHUB Issues, PR men lite geggigt med csv filer där posterna inte har identifierare --> halvt omöjligt att referera eller spåra...
  2. Riksarkivet SBL måste ni tvingas in i detta det är galet att Riksdagens corpus inte hämtar sitt data från SBL utan leker med en hobby site som Wikidata - jag ställde frågan till SBL tidigare och helt galet svar - vi har inte resurser - att skapa en datafil med koppling SBL nummer - Arkiv id tar 0 sekunder gissar att dom springer runt en hel del i arkiven.... varför inte dokumentera det som Öppen data och inte interna post-it lappar.... nu körs projektet Riksdagens Corpus med > 5 miljoner i budget... som i en perfekt värld inte hade behövts om SBL, KB, Riksdagens Öppna data hade levererat data som data - RAW Datat now
  3. Ni borde skapa en task i en publik backlog "Hur skall Riksarkivet skapa externa kopplingar....processen.... och vem som skall vara med
    1. Lesson learned är att kvaliten ökar på datat med mera kopplingar mellan varandra.... idag tycket jag vi fastnat i en galen tunna som heter Wikidata där 12000 foliehattar alla har sin egen agenda och inte producerar data som duger till forskningsdata eller verksamhetsdata... MEN känns ofta som det är den bästa datan...

Arkiv / Släktforsknings user case

delar min vaga vision här apropå DIGG diskussions forum om URI:er

Min tro är att skall vi peka på vilket arkiv en person finns i så skall det vara enkelt att hitta dom personer som finns i samma fysiska arkiv

  • I Wikidata har vi idag följande egenskaper kopplade till Riksarkivet

User case A: Som släktforskare vill jag enkelt kunna hitta saker relaterade till den aktivitet jag gör så man kan "skörda fler frukter....

Den släktforskning jag tror mig se med ny teknik är att man "jobbar ihop mer" och försöker lösa flera utmaningar när man är i ett arkiv,,,, och kanske kan få ledtrådar av vad andra gjort....

image

Vad behövs enkelt kunna se vart fysiska arkiv finns så man kan besöka ett arkiv och ha med sig 20 kandidater för att leta i detta arkiv,....

User Case B: att det finns semantiska kopplingar mellan plats i kyrkböcker och geografisk plats dvs. det skall kunna gå att hämta ut alla personer med ett "nära avstånd" mellan 2 släktträd där exempelvis 2 personer har DNA testat sig och enligt DNA testerna har ett släktskap men vi behöver "ledtrådar var i släktträdena det kan finnas en koppling" se blogpost där dagens DNA forskning har nära avstånd men inte old school släktforskning (Youtube verkar tyvärr ta bort DNA videos eftersom dom tror det är rasism....)

Vad jag tror behövs Kunna skicka in Kyrkboksreferensen ex. Bygdeå kyrkoarkiv, Lysnings- och vigselböcker, SE/HLA/1010025/E I/1 (1865-1894), bildid: F0010296_00129 - är WD Q5819424#P570
* vi har idag med Arkiv DIgital 2018 kopplat NAD till Wikidata post se T199907 för församlingen där koordinat finns för kyrkan
* tror samma bör göras med Riksarkivet PLUS skapa ett närhetsvärde som antal sidor mellan personer i samma kyrkbok, distans mellan församlingarnas kyrkor, finns man i en husförhörsbok X så borde man kunna via Linked data kunna hämta ut att man har en ättling som finns i ena släktträdet med en källa i en bok i samma församling och 10 år senare finns i det andra släktträdet en källa till en person i släktträd 2.... blir någon typ av "triangulering" i oldschool släktforskning där DNA släktforskningens väldigt strukturerade data får lite mer hjälp av traditionell kyrkoboksforskning eller åtminstone kanske en "breadcrumb"

FAIRDATA ex. Namninsamlingar för kvinnlig rösträtt

för att data skall gå att användas enkelt har FAIRDATA tagits fram jag önskar mer att Riksarkivets data är tydliga med om en datamängd uppfyller FAIRDATA eller ej se kommentar på twitter om att projektet "Namninsamlingar för kvinnlig rösträtt" borde ha Persistenta identifierare dvs. A1: (Meta)data are retrievable by their identifier using a standardised communication protocol för varje namn så att det går att referera

Misc

image

Beskriv gärna begrepp som "arkivenhet" för oss dödliga

såg på Exempel
persistent id för arkivenheten (arkiv, serie, volym etc)

Tycker rättsinformationssystemet hade trevligt sätt att dokumentera begrepp etc... plus som DIGGs projekt Beständiga identifierare poängterar uttrycker sig "så vi kan formulera oss enhetligt och kommunicera tydligt" idag gissar vi när vi skapar egenskaper som P5324 / P9713 här vore det snyggaste om vi kunde länka tillbaka till er definition som skulle finnas på engelska och svenska...

Bäst vore om DIGG hade en central termkatalog/ att "samma termer" "återanvändes"... att saker som begrepp fanns som länkad data... och grafer typ nedan kunde skapas.... gissar att röra sig från digitala silos till en länkad miljö kräver samma begrepp och mycket kommunikation...

image

Riksarkivet: Hantera Persistenta Identifierare i arkiverat material via API:er vad är status?

Riksarkivet har haft ett regeringsuppdrag att arbetat med att förvalta och vidareutveckla och främja myndigheternas arbete med data för vidareutnyttjande - en del i detta är persistenta identifierare

Riksarkivet har bl.a. producerat nedanstående dokument men jag ser inte att någonstans beskrivs Persistenta Identifierare i arkiverat material

2023 startar DIGG med att hanterar en rekommendation kring beständiga identifierare där att hantera dessa i arkiverat material måste beaktas i exempelvis "Best practices" till alla aktörer

Fråga A: Kan man via Riksarkivets API:er eller annat sätt hämta arkiverade dokument/resurser med deras PID:ar
Fråga B: Vem äger detta problem att Persistenta Identifierare skall vara persistenta även vid arkivering? Riksarkivet/Arkiverande myndighet/???
Fråga C: Skall detta fungera behövs GUPRI med API. Vem äger denna fråga hos Riksarkivet och var finns det beskrivet hur detta fungerar med arkiverat material?
Fråga D: Har ni kommunicerat era krav till DIGG? Var förs dialogen?

Exempel hur saker idag är ett mindre kaos

  • Domstolsverket jobbar 26 år med att skapa interoperabilitet mellan 100 myndigheter och status 2023 är att dom inte ens kan peka på författningar från myndigheter som upphört dvs. dagens aktörer klarar inte av sin uppgift trots att dom har haft 26 år på sig att leverera och bygga upp kompetens - Domstolsverket analys av läget
  • #87 Dokument "försvinner" vid regeringsskiften...
  • Vi behöver best practices som stödjer hela dokumenthanteringsprocesen även vid arkivering och då en myndighet upphört.... det lilla jag ser så verkar det inte tagits höjd för att vara Digitala utan det är mer hantering av flyttkartonger som flyttas till en arkivhylla....
    • API:er SPARQL etc. måste stödja detta
    • EN GUPRI-hub för statens alla dokument/resurser/dataset/aktörer... skulle spara enormt med tid och pengar

Varför Persistenta Identifierare är viktiga

Se FAIRDATA F1

image

Arkivbildare upphov

image

Tittar jag på dom "skolarkiv" jag matchat med en skola på WD så tycker jag det saknas Arkivbildare/upphov men i exempelvis Stockholms Stadsarkivets Skolregister kan en skola peka på flera arkiv ex. Kungsholms lägre elementarläroverk / WD Q112030273 / Riksarkivet SE/SSA/0148 , SE/SSA/0316

image

  • spontant så känns det som det skulle vara snyggare i Wikidata att vi för en skola kan peka på motsvarande objekt hos NAD för skolan och sedan under Property:P9493 "Arkiverad hos" peka på ert arkiv
    • hur skolor skall se ut i WD är inte 100 bestämt men tittar vi på SCB så delar dom upp i skolenheter som vi i WD sedan kopplar till skolor
      a single school can be made up of on or more school units

Fråga är det en slump att det är olika eller hur tänker ni och hur är er målbild?

Collection manifests do not include a v3 @context

While the top-level manifest contains a @context element, the leaf-node collection manifests (which list item manifests) and branch-level collection manifests are missing a @context element.

Leaf node example

URI: https://lbiiif.riksarkivet.se/collection/arkiv/lZkyF37hGIL2wcbGB1Vju6

Contents

{
  "id": "https://lbiiif.riksarkivet.se/collection/arkiv/lZkyF37hGIL2wcbGB1Vju6",
  "type": "Collection",
  "label": {"sv":["D VII Utvandrarrulla"]},
  "summary": {
    "sv": [
      "Referenskod: SE/SSA/0021/01/D VII",
      "Arkivinstitution: ",
      "Datering: "
    ]
  },
  "items": [
    {
      "id": "https://lbiiif.riksarkivet.se/arkis!A0069178/manifest",
      "type": "Manifest",
      "label": {"sv":["1 (1869-1886) - A0069178"]}
    },
    {
      "id": "https://lbiiif.riksarkivet.se/arkis!A0069179/manifest",
      "type": "Manifest",
      "label": {"sv":["2 (1886-1888) - A0069179"]}
    },
    {
      "id": "https://lbiiif.riksarkivet.se/arkis!A0069180/manifest",
      "type": "Manifest",
      "label": {"sv":["3 (1888-1904) - A0069180 - Bunt."]}
    }
  ]
}

Branch level example

URI: https://lbiiif.riksarkivet.se/collection/tid
Contents (abbreviated):

{
  "id": "https://lbiiif.riksarkivet.se/collection/tid",
  "type": "Collection",
  "label": {
    "sv": [
      "Tid"
    ],
    "en": [
      "Time"
    ]
  },
  "summary": {
    "sv": [
      "Arkiv sorterade efter tid"
    ],
    "en": [
      "Archives ordered by date"
    ]
  },
  "items": [
    {
      "id": "https://lbiiif.riksarkivet.se/collection/tid/1200-1299",
      "type": "Collection",
      "label": {
        "sv": [
          "1200-tal"
        ],
        "en": [
          "13th century"
        ]
      }
    },
    {
      "id": "https://lbiiif.riksarkivet.se/collection/tid/1300-1399",
      "type": "Collection",
      "label": {
        "sv": [
          "1300-tal"
        ],
        "en": [
          "14th century"
        ]
      }
    },
    {
      "id": "https://lbiiif.riksarkivet.se/collection/tid/1400-1499",
      "type": "Collection",
      "label": {
        "sv": [
          "1400-tal"
        ],
        "en": [
          "15th century"
        ]
      }
    },
...
  ]
}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.