Informatie 2020

Inloggen
Engels | Nederlands | Frans

Containerformaten en het e-depot

Digitaal archiefmateriaal kan worden opgeslagen en gecomprimeerd in zogenaamde containerformaten. Voorbeelden hiervan zijn ZIP, WARC of TAR. Door verschillende archiefvormers én archiefinstellingen wordt aan het NA de vraag gesteld of het mogelijk is om een containerformaat als eenheid op te slaan in het e-depot (van het NA of elders) of dat dit eerst moet worden uitgepakt en de bestanden afzonderlijk moeten worden aangeleverd.

Containerbestanden zoals bijvoorbeeld ZIP of WARC zijn technisch gezien geen probleem voor (aanlevering aan) het e-depot. Daarbij komt dat diverse bestandsformaten die op de NA lijst van voorkeurs- en acceptabele formaten staan, gebruik maken van ZIP. Te denken valt aan Microsoft Open Office XML (.docx) en Open Office Document (.odf).

Een belangrijke vraag die archiefvormers én archiefinstellingen echter moeten beantwoorden is: wat is het te archiveren en later te gebruiken informatie-object? 

Worddocumenten of bijvoorbeeld PDF-documenten zijn meestal ook de te archiveren objecten. WARC-bestanden met gearchiveerde websites ook: hoewel ze vaak uit meerdere bestanden zijn samengesteld, is het geheel van de website meestal het te archiveren object. De compressie en/of het feit dat het een containerbestand betreft is integraal onderdeel van het object.

Waar gaat het bij de containerbestanden om? Vormt alles wat in bijvoorbeeld het zipbestand werd verpakt één logisch geheel dat samen met de nodige metadata in goede, geordende en toegankelijke staat (ggts) is? Of is er sprake van een losse verzameling objecten die toevallig zijn verpakt in een zip-container?

Vanuit het perspectief van de toekomstige gebruiker bekeken: wordt t.z.t. bijv. verwezen naar het geheel van het zipbestand, of wordt verwezen naar specifieke bestanden die in het zipbestand zitten? 

In het geval van een (logisch en als zodanig te gebruiken) geheel, kan er desgewenst met zipbestanden gewerkt worden. In andere gevallen adviseren wij de zipbestanden uit te pakken en in die uitgepakte vorm in ggts te brengen.

Mocht er voor containerbestanden gekozen worden,  maak ook dan s.v.p. geen gebruik van encryptie/wachtwoordbeveiliging, of bewaar de sleutel zorgvuldig zodat ook deze kan worden meegeleverd bij overdracht aan de archiefstelling.

Het moge duidelijk zijn, er is geen pasklaar antwoord mogelijk dat voor alle mogelijke situaties geldt. Graag vragen we daarom om feedback op dit blog. We nemen deze input graag mee in het verbreden van onze kennis over het omgaan met zipbestanden en andere containerformaten.

Reacties

Volgorde van reacties: Aantal: Automatisch laden:
    • Axel Booltink
      Axel Booltink 113 dagen geleden

      Ik stem André Plat toe dat vooral de vraag naar het waarom van een containerformaat gesteld moet worden.

      Gaat het om het comprimeren van grote bestanden? Dit lijkt mij overbodig want enerzijds zijn de meeste grote bestanden (MPG, TIFF, JPG, PDF, ...) sowieso al gecomprimeerd en kunnen door een ZIP niet wezenlijk verder gecomprimeerd worden, anderzijds biedt moderne archiefopslag meestal zelf al een compressiefunctie. Verder is digitale opslag intussen zo goedkoop en met de komst van de Silent Cubes ook zo energiezuinig dat grote bestanden geen probleem meer zijn.

      Gaat het om het verkleinen van het aantal opgeslagen bestanden zoals bij de De Digitale Stad? Ook hiervoor is een containerformaat niet nodig. Wij hebben sinds meer dan vijf jaar een Silent Cube WORM systeem draaiend met inmiddels bijna 400 miljoen losse bestanden die niet in containers zitten.

      Gaat het om het samenvatten van bestanden die bij elkaar horen? Dan vormen deze inderdaad een logisch object en het zou zinvol kunnen zijn deze bestanden in een container samen te vatten en de metadata aan de container te geven. Maar samenvatten kan natuurlijk ook in gewoon map-structuren en hoeft niet perse in een ZIP-bestand. De "gecomprimeerde mappen" op Windows-besturingssystemen zijn trouwens niets anders dan ZIP-bestanden - alleen merk je het als gebruiker niet omdat het besturingssysteem de bestanden (incl. eventuele metadata) in de achtergrond uit de container haalt.

      Naar mijn mening zijn containers inmiddels alleen nog zinvol om een logische structuur af te beelden.

      Groeten,
      Axel Booltink (Comex - storage and archiving)

      • Pepijn Lucker
        Pepijn Lucker 114 dagen geleden

        Veel dank voor alle reacties tot nu toe. Leuk om te zien dat dit vraagstuk blijkbaar leeft en dat er vanuit heel verschillende invalshoeken (handleiding, metadata, hybride archieven, opslag) naar kan worden gekeken.  En ook heel leerzaam en 'food for thought'.

        Nogmaals dank dus.

        • André Plat KING
          André Plat KING 114 dagen geleden

          De waarom vraag lijkt mij nog onvoldoende gesteld. Comprimeren lijkt nuttig/noodzakelijk bij heel grote bestanden en/of om ruimte te besparen. Technische Universiteiten hebben hier ervaring mee, ga daar te rade. Bijvoorbeeld bij Lucht en Ruimtevaart en ook Bio-Science zit die ervaring.

          Gaat het om gecomprimeerde ontvangen bestanden, wil je zelf comprimeren dan is duurzaamheid over pakweg 200 jaar lijkt mij wel een issue.

          Hoe verhoudt zich comprimeren tot open overheid en linked open data, kijk dan eens naar http://lod-cloud.net/versions/2017-02-20/lod.svg en kijk dan niet alleen naar 'government' - het gele - spectrum, want ook uit andere domeinen zullen bestanden in de e-depots belanden. Hoe de zichtbaarheid, bruikbaarheid en duurzaamheid van deze hoeveelheid te realiseren.

          Blijf zoveel mogelijk uitgaan van originele bestanden en regel daar wat te doen staat...efficiënter opslag is eigenlijk 'hannessen' met bestanden: niet doen.

          • Erwin Verbruggen
            Erwin Verbruggen 122 dagen geleden

            Ha Pepijn, precies 'n topic waar ik op dit moment ook mee worstel! => Ingest (en afhankelijkheden) van hybride digitale collecties

            Voor De Digitale Stad hebben we richting de 9 miljoen bestanden bijeen verzameld in de loop der jaren, dus naar verwachting zullen we daar één of meerdere containerformaten voor moeten inzetten. Op welk niveau dat dan moet en kan gebeuren is een onderwerp waar we naarstig voorbeelden van zoeken. Ik hou dan ook oplettend deze post in de gaten met oog op kruisbestuiving!

            Groet, Erwin

            • Anje van der Lek
              Anje van der Lek 124 dagen geleden

              Ik denk dat het gebruik van containerformaten in de meeste gevallen onwenselijk is. Zoals je al stelt, bevat een containerbestand als ZIP of WARC meestal verschillende digitale bestanden. Zelfs als die samen één logisch object vormen (bijvoorbeeld een document met bijlagen), zullen volgens de huidige aanlevervoorwaarden (ik ga nu even uit van doc Voorwaarden export v1.3 van het NA,  feb 2017) op alle aggregatieniveaus bepaalde metadata aangeleverd moeten worden, in een voorgeschreven "sidecar-"" mappenstructuur. Het laagste niveau waar metadata toegevoegd moeten worden, is het niveau van het bestand (file), dit gaat vooral om de technische metadata (TMLO 21, formaat).

              Dit niveau zit dan "ingepakt" in het containerformaat. Hoe kun je dan de metadata in de sidecar-structuur op bestandsniveau bijvoegen? En hoe kun je dan (in de toekomst) op bestandsniveau beheeracties doen (bijvoorbeeld monitoren of file formats obsolete zijn, conversie naar nieuw bestandsformaat)

              Wat betreft webarchieven... dat vind ik lastig. WARC is daarvoor denk ik wel het aangewezen formaat (Open, interenationale en wijd geaccepteerde standaard). Maar je moet je dus wel bedenken dat ingesloten bestanden in een website, zoals bijv multimedia bestanden, dan dus eigenlijk niet duurzaam bewaard worden, maar dat je feitelijk de structuur van de website bewaard.

              In het kader van ons project Videotulen kwam ook de vraag voorbij, of we niet konden volstaan met het maken van een webarchief van de website van de gemeenteraad. Wij kwamen tot de conclusie dat dat niet het geval was, omdat de metadata dan dus niet op het juiste niveau wordt toegekend.

              Anje vd Lek (Regionaal archief Alkmaar)

              • Marc van den Hoogen
                Marc van den Hoogen 124 dagen geleden

                T.a.v. gevraagde feedback: ik sluit me erbij aan dat aan te leveren bestanden soms in een container zitten en dat dat wenselijk kan zijn (zie ook voorbeelden op de lijst voorkeursformaten). Is het een interessant idee dat de informatie over de gewenste wijze van aanleveren van (container)bestanden aan één (centrale) online handleiding/online documentatie van het e-Depot van het Nationaal Archief toegevoegd wordt? Informatie over de wijze van aanleveren, publiceren, preserveren, hergebruik enz... staat nu soms her en der verspreid op Internet. Het zou m.i. een mooie volgende stap zijn als die op een (één) logische plek bij elkaar komt te staan, zodat (nieuwe) mensen die zich moeten inwerken op het gebruik van het e-Depot van het Nationaal Archief, overzichtelijk toegang krijgen tot alle laatste informatie/instructies rondom het gebruik ervan. Een complete handleiding "in ontwikkeling" als het ware. Ook kun je dan in de loop van de tijd altijd zien wat de laatste versie is van de instructies/adviezen rondom aanleveren.

              Reageren is alleen mogelijk voor aangemelde gebruikers