Vi sitter med samme opplevelse som det Rolf beskriver, en kombinasjon av eksterne metadata (koblinger), interne metadata (programvare/verktøy) og embedded (f.eks XMP).
Jeg vet dette er en mulig digresjon, men en tanke jeg har hatt lenge rundt denne problemstillingen, er hvordan vi kan gjøre dette mer tilgjengelig for endemottaker. Hvordan kan vi samtidig effektivisere behandling og ordning? SIARD består av uspesifiserte binærfiler med referanser i XML, sammen med evt. tabelldata. Det er en kjennsgjerning at denne modellen tar mye tid og krever veldig mye maskinvarekraft (ikke minst minne) for å jobbe med, enkeltprosesser i produksjonslinjen kan ta flere dager, noen ganger flere uker. XML kan være rask når det først er lastet i minnet, men når vi nå begynner å se arkivpakker som nærmer seg maksgrensen på 1TB (§5-29 andre ledd) så kan dette ta flere dager å laste inn om man i det hele tatt har maskinvare som kan håndtere det. Dette gjelder for metadata, men også for selve grunnlaget. Prosessen med formatanalyse er også ganske tidkrevende, og i mange tilfeller veldig unødvendig, siden denne informasjonen som regel ligger i databasen ved siden av kolonnen med blobben.
Vi ser på muligheten for å konvertere METS og SIARD til sqlite for å omgå disse problemene. Vi bruker fortsatt DIAS som referansestruktur, men har valgt å lagre metadata og logger i /packageinfo.sqlite med egne tabeller for forskjellige typer arkivspesifikke metadata og aktiviteter. Så lagres tabelldata i content/database.sqlite med filreferanser og metadatareferanser i /content/metadata.sqlite. Utvunnede dokumenter i lagres så i /content/documents.
Dette gjelder nok ikke i alle tilfeller, og jeg vil tro det er mange meninger om gyldigheten ved det jeg sier, men vi har i allefall merket en markant (og ganske drastisk) nedgang i behandlingstid når vi jobber med sqlite på disk fremfor minne, ikke fordi selve prosessen er raskere, men fordi aksess og søk er ufattelig mye raskere og bekvemmelig.
