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 somDOCX 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

table1.xsd

table1.xml

lob1

record1.txt / record1.bin

lob2

record2.txt / record2.bin

table2

table2.xsd

table2.xml

schema2 …

…

File and folder names short, plain ASCII strings.

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/informasjon-vigo-opplaering/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