Automatisering av uttrekk fra bevarte databaser Arne-Kristian Groven, Fagdag om Noark5 og RDF, Riksarkivet, Oslo, 17.06 2014
Om meg Har 20 års bakgrunn innen IT-forskning Snart 3 år i Riksarkivet Arbeider med: Innhenting av bevaringsverdig arkivmateriale (uttrekk/sip generering) Innovasjoner/FoU/nye metoder og verktøy
Databasebevaring vs. uttrekk Det meste av det digitale materialet vi ønsker å bevare har en databasekomponent i seg 90 % av lagrede arkivpakker, AIPer, i det danske Rigsarkivets (nye) depotsystem er bevarte databaser I Norge har vi lang tradisjon for å transformere deler av databasene til standardiserte uttrekksformat: Noark-3, Noark-4 og Noark-5 Pluss å spesiallage uttrekk fra spesifikke fagsystem
Noark-uttrekket Blir gjennomført av konsulenter Basert på manuelt arbeid i databasene, ofte klipp og lim Tidkrevende Dyrt Varierende kvalitet Har vi tillit til materialet som mottas?! Hvordan skal materialet tilgjengeliggjøres/vises?
Dagens situasjon i Norge Det flommer over av systemer der ute Mye bevaringsverdig digitalt skapt arkivmateriale forsvinner fordi systemer dør Dette gjelder både Noark-godkjente system og fagsystem: Register, støttesystem... VI TRENGER (SNAREST) METODER OG VERKTØY SOM KAN BEVARE OG TILGJENGELIGGJØRE: Effektivt, repeterbart og med høy kvalitet! Slik at tillit til materialet kan bevares inn i framtida!
Hvordan komme videre?... Mot målet: Effektiv, repeterbar, høykvalitets bevaring og tilgjengeliggjøring! Mitt forslag: 1. Speil databaser over i et velegnet bevaringsformat 2. Fyll opp med relevant tilleggsinformasjon 3. Lag transformasjoner (uttrekk) fra bevarte databaser til velegnede visnings- og gjenfinningsformat (eksempelvis RDF vokabular og ontologier)
Hvordan komme videre? Jeg vil i det følgende se litt på disse tre stegene: 1. Ved å presentere verktøyet og formatet SIARD, for databasebevaring 2. Ved å illustrere med et tilfeldig eksempel jeg fant på nettet, fra et web-basert fagsystem 3. Ved å diskutere mulighetene for automatiserte uttrekk fra Noark-4 godkjente system
Databasebevaring med SIARD Illustrasjon: Save Your Databases! Urs Meyer, SFA ECA 2010, April 2010
SIARD oppsummert Veldefinert bevaringsformat, SIARD-formatet Veldefinerte transformasjoner Normalisering fra ulike databaseplattformer (Oracle, MS SQL Server, MySQL, MS Access, DB/2) til bevaringsformatet, SIARD formatet Fra SIARD-formatet til ulike databaseplattformer (på SQL:1999 formatet) Velfungerende verktøystøtte, Siard Suite SiardFromDB, SiardToDB, SiardEdit (GUI)
Eksempel: Transformasjoner fra MySQL datatyper til SIARD datatyper
Om SIARD-formatet En SIARD fil er en ZIP fil, på samme måte som DOCX og ODT filer er ZIP filer 64-bit på grunn av databasenes størrelse Bestående av XML filer Muligens også tekst og binærfiler, store objekter UTF-8 tegnsett på tekstfiler og XML filer Innholdet i SIARD-filen i henhold til SQL:1999 standarden Ikke bare syntaktisk, men også I henhold til SQL:1999 sine konsistensregler
SIARD Formatet: Filenes struktur header metadata.xsd metadata.xml content schema1 table1 table2 table2.xsd table2.xml schema2 File and folder names short, plain ASCII strings. table1.xsd table1.xml lob1 record1.txt / record1.bin lob2 record2.txt / record2.bin
Dette tas vare på av SIARD Database Schemas, Users, Roles Schemas Tables, Views, Routines Tables Columns, Rows, Keys (Primary, Foreign, Candidate) Constraints Rows data records containing primary data Views Users, Roles
Metadata som tas vare på av SIARD Schema level name folder description tables views routines Table level name folder description columns primarykey foreignkeys checkconstraints Column level name folder description type typeoriginal defaultvalue nullable Other Metadata View level Routine level User level Role level Privilege level
Erfaringer med SIARD Enkelt å generere SIARD-filene Oppgir databasens adresse og en databasebruker/passord (leseaksess) Databasepersonell hos arkivskapere kan gjøre jobben SIARD Suites GUI muliggjør rask inspeksjon/analyse av data Automatisert, veldokumentert transformasjon gir økt tillit
MEN: SIARD-filen er bare en del i arkivpakken
SIARD og arkivaren SIARD (Suite) gjør ikke arkivarens jobb Arkivarens jobb starter når SIARD har gjort sin, eller aller helst lenge før Arkivfaglige beskrivelser kan inkluderes på ulike nivå i SIARD-filen Datakataloger og annen dokumentasjon bør vedlegges SIARD-filen.
Dokumentasjon av databaser Så over til dokumentasjon av databaser: Dokumentasjon burde være påkrevd for alle databaser med bevaringsverdig innhold! Hva slags informasjon bør være tilgjengelig?!...
Dokumentasjon av databaser Jeg fant et illustrerende eksempel på nettet, for et system som heter Vigo Opplæring: http://www.vigoiks.no/systeminformasjon/informasj on-vigoopplaering/dokumentbase/databasedokumentasjon
Dokumentasjon av databaser Hver eneste tabell var i Vigo Opplæring dokumentert og publisert På følgende form:
SIARD anvendt på Noark-4 databaser Vi har det siste halve året ved hjelp av SIARD hentet inn databasene til ulike Noark-4 godkjente system Fire databaser tilknyttet en type system og fem databaser tilknyttet en annen type For en type system har vi funnet spørringer i views som tilsvarer Noark-4 DTDene
Automatisert transformasjon (uttrekk) fra Noark-4 databaser til Noark-5 RDF Funnet av Noark-viewene formet ideene om å generere mest mulig automatiserte uttrekk fra Noark-4 databasene over i en eller flere formalismer For eksempel RDF som målformalisme Hva gjelder Noark-4 godkjente systemer så er det fem ulike typer systemer fra fire(?) forskjellige leverandører Etter å ha kikket ned i databasene til to av disse er det helt klare likheter innenfor hver type, noe som gir grunn til optimisme
Automatisert transformasjon (uttrekk) fra Noark-4 databaser til Noark-5 RDF Optimisme, men arbeidsmengden som må til for å være i stand til å mappe databasefelter over i et uttrekksformat vil være helt avhengig av: Tilgang på databasedokumentasjon Om det allerede finnes spørringer i databasene
Fagsystem vs. Noark-godkjente system Vi har i dag et klart skille mellom håndtering av bevaringsverdig informasjon fra fagsystem og Noark-godkjente system Det første tilfellet (alle mulige typer fagsystem) er som regel underspesifisert hva gjelder bevaringsformat Noark-uttrekket er på sin side strengt spesifisert
Semantiske teknologier/rdf og Noark 5 Det kan selvsagt utvikles en eller flere Noark-5 vokabularer/ontologier Jeg vet at det finnes flere initiativer og håper disse vil konvergere
Semantiske teknologier/rdf og Noark 5 Men, semantiske teknologier/rdf med dets mange etablerte vokabularer og ontologier kan også bidra til å finne ut om deler av Noark-5 kan uttrykkes i noe som allerede er veletablert! Dessuten, kanskje det kan bygges bro mellom bevaringsverdig informasjon fra fagsystem og Noark-godkjente system?! Dette er i mitt håp!
Hvorfor ta vare på databasen og deretter lage uttrekk? I dag har vi Noark-3 uttrekk, Noark-4 uttrekk og snart Noark-5 uttrekk Ved å ta vare på databaser og databasedokumentasjon vil man være på tryggere grunn hva gjelder autentisitet Ved å ta vare på databasene vil man til en hver tid inn i framtida kunne generere uttrekk tilpasset den til en hver tid gjeldende visningsomgivelsen En vil også sannsynligvis kunne få en mer ensartet håndtering av bevaringsverdig materiale fra både fagsystem og Noark-godkjente system