Samarbeidsprosjektet TEAM – Tilgjengeliggjøring av edb-basert arkivmateriale (full tittel i norsk variant) – ble startet av de fem nordiske riksarkivene i 1991. Arbeidet ble delt opp i fire delprosjekter, organisert  og delfinansiert på nasjonal basis av hvert av riksarkivene, og sluttført i 1993 – 1995 med finansiell støtte fra Nordisk Ministerråd og NORDINFO (nordisk samarbeidsorgan for vitenskapelig informasjon). Delprosjektene var:

  • TEAM-1 (Norge): Overføre filer fra en struktur med flate filer til relasjonsdatabaseformat
  • TEAM-1B (Danmark): Aksess til elektroniske journaler som er overført til arkivdepot
  • TEAM-2 (Sverige): Lagringsmedier for langtidsbevaring
  • TEAM-3: (Finland og Island): Kostnader for langtidsbevaring ved alternative rammeverk.

Hovedprosjektet TEAM-1 startet som et norsk NAVF-støttet prosjekt i 1991 for å utvikle brukertjenester på Riksarkivets edb-lagrede arkivmateriale. Det ble videreført som en del av det nordiske prosjektet høsten 1992, og utvidet med en nordisk referansegruppe. Høsten 1993 forelå en ferdig prototyp-versjon av et system for å tilgjengeliggjøre avleverte elektroniske arkiver. TEAM-rapporten fra 1996 beskriver datamodellen som lå til grunn for dette systemet. I rapportens Bilag A beskrives også programvaren som ble utviklet av TEAM-1.

TEAM-rapporten er skannet, og distribueres av praktiske grunner i tre deler:

Basis for TEAM: ”Den skandinaviske bevaringsmodellen”

Det nye med TEAM-1 var spesifiseringen av en generell metode for å generere bruksversjoner av avleverte datauttrekk (tabelluttrekk) fra databaser. Men TEAM-rapporten presenterer også premissdelen for dette utviklingsarbeidet ved å beskrive de nordiske riksarkivenes modell for avlevering og langtidsbevaring av informasjon fra databaser. Rapporten sammenfatter metodikken for bevaring slik den har vært praktisert fra tidlig på 1980-tallet, og slik den fortsatt i all hovedsak nedfeller seg i gjeldende statlige og kommunale avleveringsbestemmelser. TEAM beskriver denne bevaringsmetodikken mer prinsipielt enn normativt regelverk kan gjøre, og det har vært sparsomt med lignende beskrivelser i publisert form i tiden etter TEAM. 

TEAM-rapporten tar utgangspunkt i det den kaller en felles skandinavisk modell for bevaring av edb-arkiver i register- eller databaseformat (data med en fast struktur i poster og felter):
1)  Systemer (applikasjonsprogrammer) kan ikke bevares, bare data fra dem.
2)  Data hentes ut av systemene i et systemuavhengig, standardisert format (tradisjonelt som ”flate filer”, dvs. som rene tekstfiler i standardisert tegnsett).
3)  Databasetabeller tas ut som separate filer. Data fra eldre typer databaser forutsettes normalisert til en relasjonell struktur hvor hver posttype er én enkelt sekvensiell fil.
4)  Det må følge med dokumentasjon av teknisk systemstruktur: oversikt over alle tabeller med deres relasjoner og en strukturbeskrivelse for hver enkelt tabell (post- og feltbeskrivelser, forklaring av brukte koder mv.)
5)  Det må følge med dokumentasjon om administrativ kontekst som viser hvordan vedkommende system er blitt anvendt av arkivskaperen. 

Modellen forutsetter vanligvis at statlige arkivskapere selv fremstiller arkivversjoner i formatet for langtidsbevaring. Det hører også med å kjøre tester ved mottak i arkivdepot for å kontrollere at materialet er lesbart og i tråd med den medfølgende dokumentasjonen.

Tradisjonelle testprogrammer muliggjør enkle oppslag i data, typisk i enkelttabeller, men programmene er ikke tilrettelagt for brukertjenester. Bevaringsversjoner bestående av en samling flate filer er ikke lenger søkbare databaser. De er som organismer uten nervesystem, muskler og sener. Den tradisjonelle modellen for å langtidsbevare informasjon fra databaser begrenser seg altså til å opprettholde potensialet for senere bruk. Erkjennelsen av at dette – om enn så krevende i seg selv – ikke er tilstrekkelig for å ivareta riksarkivenes samfunnsfunksjoner, var utgangspunktet for TEAM-1. 

TEAM-modellen for tilgjengeliggjøring

TEAM-modellen gjør avleverte tabelluttrekk søkbare i en relasjonsdatabase (prosjektet brukte betegnelsen standardisert SQL-database). Databasen genereres på grunnlag av den medfølgende tekniske arkitekttegningen – dvs. dokumentasjonen av systemstruktur – som følgelig må være korrekt og komplett. Data fra de avleverte datafilene kan deretter overføres til den regenererte databasen. Denne siste del av prosessen kan beskrives som å fylle et definert innhold i riktig oppsatte støpeformer. 

Det som TEAM regenererer, er ikke den opprinnelige fysiske databasen, men dens opprinnelige logiske tabellstruktur. Det er heller ikke nødvendigvis en komplett database som logisk gjenskapes. Det kan dreie seg om bevaringsverdige deler av den, og i så fall vil også datauttrekkets tekniske dokumentasjon være begrenset til dette. Det er viktig å presisere at den gjenskapte og søkbare databasen er en brukskopi. Arkiveksemplaret vil alltid være de flate filene som ble avlevert av arkivskaperen.

Prosessen i TEAM er følgende:

1)  Strukturbeskrivelsen for de avleverte flate filene leses inn i en metadatabase. Dette skjer ved import eller manuell registrering når dokumentasjonen bare foreligger i papirform. Strukturbeskrivelsen suppleres eventuelt med tilleggsdokumentasjon for gjenfinning og administrasjon.
2)  Egen programvare utviklet av TEAM leser strukturbeskrivelsen fra metadatabasen, og genererer samsvarende tabeller og indekser i en SQL-database (Oracle 6 ble brukt i TEAM-prosjektet).
3)  Data i avlevert flatfil-format importeres til SQL-databasens tabeller. 

Metadatabasen i TEAM krever spesiell omtale. Den har for det første funksjon som en applikasjonsgenerator ved å beskrive teknisk struktur for tabelluttrekk som skal overføres til SQL-database, og ved deretter å levere dette som ”input” til et overføringsprogram. I tillegg er metadatabasen et arkivstyringssystem med en arkivbeskrivelse for hvert avlevert el-arkiv (dokumentasjonen om administrativ kontekst) og med oversikt over data og lagringsmedier som basis for vedlikehold av den elektroniske arkivbestanden. Funksjonene for arkivstyring må forstås på bakgrunn av at dette var i de tidligste fasene av Asta-utviklingen. De første versjonene av Asta kom heller ikke til å omfatte elektronisk arkivmateriale.

TEAM-1 utviklet programvare for å generere SQL-databaser iht. avleveringenes strukturbeskrivelser og for å importere data, jf. nærmere beskrivelse i TEAM-rapportens bilag A, men denne programvaren var en prototyp-versjon basert på en forenklet datamodell. En mer fullstendig og kompleks modell ble imidlertid beskrevet i TEAM-rapporten. Rapporten planla også å utvikle en neste versjon av programvaren med funksjonalitet som manglet i prototyp-versjonen: en ny metadatabase basert på TEAM-rapportens mer komplekse datamodell, tilpasning for nyere lagringsmedier (enn tradisjonelt ”open reel” magnetbånd) og tilpasning for nyere utviklingsverktøy.

Oppfølgingen av TEAM

TEAM er ikke blitt fulgt opp som planlagt i rapporten. Det fremgår av Riksarkivets årsmeldinger at løsningsmodellen tidlig ble regnet som foreldet på viktige punkter. Dette var også konklusjonen på de nordiske riksarkivenes IT-kontaktmøte i Reykjavik i desember 1998. Nye lagringsmedier for langtidsbevaring (CD-R) var da tatt i bruk, og web-teknologi ga bedre muligheter for enkel distribusjon av registerinformasjon. Viktigst var likevel innføringen av XML som beskrivelsesspråk for å dokumentere tabelluttrekk.

I 1998/99 utarbeidet Riksarkivet den XML-baserte standardmalen ADDML for å beskrive alle elementer og datastrukturer som forekommer i avleveringsuttrekk fra registre og databaser (unntatt Noark-systemer). Bruk av ADDML gjorde el-arkiver selvdokumenterende ved avlevering og langtidslagring. Til støtte for arkivskapere ble det utviklet verktøy (Arkadukt) for å generere dokumentasjon i ADDML-format. Dette effektiviserte samtidig Riksarkivets testing av datauttrekk mot den tilhørende dokumentasjonen. I tillegg startet utviklingen av verktøyet Arkade, Riksarkivets ”Swiss knife” for testing og konvertering (struktur- og formatnormalisering) av databaseuttrekk.

Arkade, som ble utviklet som en applikasjon i SAS (Institute), skulle også ha funksjonalitet for å generere bruksversjoner av avleverte datasett. Men Arkade-utviklingen ble stanset etter få års bruk av systemet fordi den ambisiøse applikasjonen aldri ble stabil. I stedet ble det utviklet en ny versjon av Arkade (i Java) med funksjonalitet avgrenset til Riksarkivets testing av datauttrekk.

For Noark-4-systemer har Riksarkivet fått utviklet et spesialisert verktøy: ArkN4. I utgangspunktet skulle dette være et kombinert verktøy for testing og tilgjengeliggjøring. Det skulle dermed realisere TEAM, om enn bare for Noark-4-avleveringer. ArkN4 importerer Noark-4-uttrekkenes tabellfiler til en MySQL-database. SQL-spørringer kan utføres mot databasen – om den er konsistent. Men avleverte Noark-4-tabeller har ofte vist seg å være inkonsistente. Hittil er ArkN4 derfor først og fremst brukt som verktøy for en inngående testing av uttrekkenes tabellfiler (inkludert deres relasjoner). Siste trinn i den opprinnelige planen for ArkN4 gjenstår fortsatt. Det omfatter utvikling av et ”øvre dekk”: et grensesnitt for brukertjenester med tilrettelagte søkefunksjoner.

Konsistensproblemer i de avleverte Noark-4-uttrekkene har hittil bidratt til å senke ambisjonene for ArkN4. Manglende referanseintegritet og andre konsistensbrister har bl.a. kunnet tilbakeføres til den konvertering fra systemenes originale (”native”) tabellstruktur til en standardisert Noark-4-struktur som foretas ved avlevering. Dette har ledet til et langdrygt utviklingsarbeid for å gjøre ArkN4 trinnvis mer feiltolerant ved import av datafiler for testing. Men bevaring av inkonsistente tabelluttrekk innebærer at det kreves en frisering av innhold for å kunne iverksette den referanseintegritet som gjør datasettene til kjørbare databaser og basis for brukersystemer. Et slikt inngrep for å korrigere innhold i en bruksversjon kan likevel være tillatelig, gitt at rettelsene er tydelig dokumentert, og gitt at kontroll mot en uendret bevart original er mulig. 

TEAM-prosjektet forutsatte at overføringen fra flate filer til en SQL-database ville være en enkel og standardisert operasjon. Erfaringene fra Noark-4-avleveringer bekrefter ikke denne optimismen. Men i dette tilfellet bygger altså avleveringen ikke på en original tabellstruktur, men en standardisert Noark-struktur som datainnholdet er konvertert til – med desto større muligheter for feil i konverterings- og uttrekksprogramvare. 

Status for oppfølgingen av TEAM kan på denne bakgrunn oppsummeres slik:

TEAM er aldri blitt fullt realisert. Prosjektets implementeringsmodell er foreldet, men ikke den logiske modellen – så langt teknisk definerte systemer er objektene for bevaring. Riksarkivets metodegrunnlag bygger fortsatt på at bevaringsobjektet vanligvis er et teknisk system med tilhørende informasjonsinnhold, og at innholdet gjøres tilgjengelig innenfor rammen av en gjenskapt teknisk struktur. Noark-5-systemer bygger på en annen modell. Kompleks teknisk tabellstruktur spesifiseres ikke, bare den logiske arkivstrukturen. Men det er fortsatt en systemstruktur som bevares – med mulighet for å gjenskapes. Ved gjenskaping vil den logiske arkivstrukturen i Noark-5 også praktisk kunne håndteres som en simulert teknisk (tabell)struktur i sterkt forenklet form.

Riksarkivet har i praksis fulgt opp TEAM-modellen for tilgjengeliggjøring ved å utvikle spesialiserte applikasjoner for Noark-avleveringer (versjon 3 og 4), men det har vist seg problematisk å nå målet om å gjenskape kjørbare relasjonsbaser på grunnlag av avleveringer i standardisert Noark-4-format. Oppfølgingen av TEAM som en generell modell for tilgjengeliggjøring av tabelluttrekk ble foreløpig stilt i bero med skrinleggingen av SAS-versjonen av Arkade i 2005. Et verktøy som tegner til å kunne realisere TEAM som en generell modell for tilgjengeliggjøring av tabelluttrekk med utgangspunkt i en metadatabase, er Frode Kirkholts URD – Universal Relational Database. 

15.11.2011. Trond Sirevåg