Een automatiseerder biedt een gemeente aan om op de server grote bestanden minder ruimte (tot zo’n 80%) te laten innemen door datacompressie toe te passen.

Redenen om datacompressie toe te passen zijn:

  • De lange openingstijden van grote bestanden terug te brengen

  • De mogelijkheid te bieden om kleinere bestanden te kunnen versturen en dat per e-mail te kunnen realiseren (en niet altijd via WeTransfer)

Dit is voor de betreffende gemeente aantrekkelijk, want dit bespaart kosten voor opslag en levert tijdwinst op.
In de Archiefregeling staat in artikel 26 lid 3 dat gebruik van compressietechniek slechts is toegestaan voor zover daarbij niet zodanig verlies van informatie optreedt, dat niet langer aan de bij deze regeling gestelde eisten ten aanzien van de toegankelijke en geordende staat van digitale archiefbescheiden kan worden voldaan.
Op dit forum wordt over de gevolgen van compressie van documenten gesproken in het kader van Vervanging, maar de meeste documenten zijn digital born.

Mijn vragen zijn dan ook:
- Heeft compressie van digital born documenten dezelfde impact als die van gedigitaliseerde documenten (in het kader van Vervanging)
- Gezien het gegeven dat niet alle documenten in informatiesystemen in aanmerking komen voor langdurige bewaring al dan niet in een edepotvoorziening, kun je dan stellen dat als compressie niet wenselijk is, je dit absoluut niet moet toepassen of alleen voor bepaalde categorieën (maar dan is de vraag hoe je dat moet doen binnen het informatiesysteem).

Weergaven: 719

Hierop reageren

Berichten in deze discussie

Goede vraag! Ik heb even gegoogled en deze Wikipedia-pagina leek mij wel relevant: https://en.wikipedia.org/wiki/Lossless_compression. Op de NEderlandse Wikipedia wordt het onderwerp ook aangestipt, maar is de tekst wel heel erg beknopt: https://nl.wikipedia.org/wiki/Datacompressie.

Van Ingmar Koch kreeg ik via-via deze reactie:

Kortweg is het antwoord: het maakt natuurlijk niets uit of het om digital born of digital reborn-bestanden gaat. Compressie (of eigenlijk de decompressie) vormt altijd een extra stap bij het raadplegen van een bestand. In de meeste gevallen merk je dat als gewone gebruiker niet, bijvoorbeeld als het gaat om jpg-compressie, of zelfs bij zip-files is het bijna transparant, maar er vindt dus wel decompressie plaats. En bij digitale archivering levert iedere extra stap ook weer extra risico’s op.

Daarnaast geldt:

  • bij lossy compressie gaat informatie en kwaliteit verloren. Voor audio-visuele archiefdocumenten wordt het kwaliteitsverlies, de ruis en/of de vervormingen gemakkelijk auditief of visueel waarneembaar wanneer verschillende opeenvolgende compressie-algoritmes worden toegepast
  • het verwerken van gecomprimeerde bitstreams is complexer
  • gecomprimeerde digitale documenten zijn kwetsbaarder dan ongecomprimeerde documenten. Een fout in een gecomprimeerd bestand leidt sneller tot onherstelbaar verlies

Dus als compressie onvermijdelijk is, kies dan voor een lossless compressiemethode (zonder informatieverlies) en kies een compressie met een open, gedocumenteerd en gestandaardiseerd decompressie-algoritme.

Uiteraard kun je altijd een risico-afweging maken: hoe langer een bestand toegankelijk moet blijven, hoe groter de risico’s.

Tenslotte is de opmerking van Jean-Luc over open standaard grotendeels flauwekul. Docx (of eigenlijk Office Open XML) is een open standaard, dus iedere overheid die Microsoft Office 2007 of recenter gebruikt voldoet in principe aan de wet."

De wetgever geeft je ruimte om zelf te kiezen. En dan kun je inderdaad kiezen om compressie voor bepaalde bestanden toe te staan en voor andere (liever) niet.

Als je compressie toepast zul je moeten onderzoeken of inschatten wat de gevolgen hiervan zijn. Vragen aan de leverancier is een optie en uitleggen van het waarom; leren ze ook weer wat van.

Misschien help ook dit nog, uit http://www.edavid.be/davidproject/teksten/Richtlijn4.pdf

"Parameters en opties
Bij de meeste bestandsformaten kunnen verschillende parameters en opties worden ingesteld. Vanuit archiveringsperspectief is het belangrijk om de nodige aandacht te besteden aan deze parameters en opties. Het technisch profiel en de mate waarin de digitale objecten geschikt zijn voor langetermijnarchivering worden immers sterk bepaald door de gehanteerde instellingen bij opslag. Volgende uitgangspunten zijn hierbij belangrijk en keren terug bij de meeste archiveringsformaten:
 hanteer de Unicode (evt. ASCII) tekenset bij het inbedden van metadata
 zorg ervoor dat de digitale objecten zo zelfvoorziening mogelijk zijn en zo weinig mogelijk afhankelijk van externe bronnen: alle elementen die nodig zijn voor een getrouwe reconstructie van het documenten worden maximaal aan de digitale objecten toegevoegd
 kies een ASCII-opslagmethode waar mogelijk: dit maakt uitwisseling tussen meerdere applicaties doorgaans gemakkelijker
let op bij het toepassen van compressie: compressie kan resulteren in ongewenst gegevensverlies of tot softwareafhankelijkheid"

Zonder de bedoeling te hebben om de discussie complexer te maken wil ik toch graag het verschil in simpele bewoordingen proberen uit te leggen tussen compressie voor gedigitaliseerde analoge bestanden en voor digital born bestanden.

Bij compressie op gedigitaliseerde analoge bestanden (scans, video, audio) wordt compressie op bitniveau toegepast, in de praktijk komt dat er op neer om het simpel te stellen dat opvolgende bits met een licht afwijkende waarde gelijk getrokken worden, er wordt dus iets aan informatie weggehaald met de bedoeling dat dat "iets" net niet zichtbaar/hoorbaar is, dus voor onze ogen/oren met geen of minimaal kwaliteitsverlies.

Bij compressie op digital born documenten, wordt een ander soort compressie bedoeld, namelijk het in andere vorm wegschrijven van computerdata en het slimmer coderen van computerletters en cijfers. Dit soort compressie moet altijd verliesloos zijn want zou anders leiden tot het onleesbaar worden van lettercodes.

Ha Leo,

Net een ppt bijgewoond over het e-depot van Justid. Daar heb ik de vraag gesteld over compressie. Deze bestanden kunnen niet direct in het depot Justid worden opgenomen. Nu gaan alle bestanden niet naar een e-depot en kent Justid bredere uitgangspunten dan het e-depot van het NA, maar toch iets om rekening mee te houden lijkt me.

Collegiale groet,

Yvonne

waarom kunnen ze niet in het e-depot?

Dat kwam onvoldoende aan de orde wegens tijdgebrek. De werkwijze is dat de bestanden teruggaan naar de dienst en dan zonder compressie weer worden aangeleverd.

Het depot van Justid is meer dan een e-depot van statische bestanden zoals het Nationaal Archief. Feitelijk is vrijwel het gehele records management er in geregeld. Wat bij het NA speelt rondom uitplaatsing van semi-statische bestanden kennen zij niet. Justitiële diensten zijn gewoon aangesloten.

Yvonne,

Ik kan me nauwelijks voorstellen dat Justid gescande bestanden bestaande uit PDF/A bestanden met een jpeg compressie kunnen weigeren. Ik kan me wel voorstellen dat Justid gecomprimeerde digital born bestanden (bijvoorbeeld ZIP of RAR) zal weigeren. Heb je misschien een naam waar we verdere uitleg van Justid kunnen navragen?

Nee, ik kan je niet verwijzen, Leon en kan alleen maar mededelen wat ik nagevraagd heb.

Op de site van het Forum Standaardisatie is de lijst te vinden met open standaarden waaraan de Nederlandse overheidsinstanties zich zouden moeten houden. Dit geldt voor rijksoverheidsdiensten en voor regionale en lokale overheidsdiensten.

Voor de complete lijst klik hier https://www.forumstandaardisatie.nl/open-standaarden/lijst

Op deze lijst komt XML wel in voor en docx niet, echter docx is ook een xml vorm, dus dan zou het wel weer mogen omdat net zoals Ingmar zegt het docx een Office Open XML is.

MAAR:

Het docx formaat is een actief formaat en de weergave van een document in docx is afhankelijk van de instellingen van het programma waarmee je een dergelijk bestand opent. De bedoeling van XML: Met XML kunnen gestructureerde gegevens worden gerepresenteerd in de vorm van tekst, die zowel door mensen als machines leesbaar is. XML wordt gebruikt voor de ontwikkeling van domein- en toepassingsspecifieke markuptalen.

Bij het tot stand brengen van XML werd presentatie en structuur van een document losgekoppeld om het computers mogelijk te maken de xml informatie uniform qua inhoud te presenteren,  zoals bijvoorbeeld met HTML. Voor de representatie van het document wordt geleund op zogenaamde cascading stylesheets (css). 

Met CSS wordt het uiterlijk van de pagina weergegeven. CSS-code beschrijft hoe de kopteksten, alineateksten en
afbeeldingen worden opgemaakt. In CSS wordt aangegeven welk lettertype wordt gebruikt, welke lettergrootte, letterkleur, uitlijning, regelafstand, witruimte tot andere onderdelen en meer. Met CSS is ook de opmaak van de pagina in te stellen in kolommen, kop- en voetteksten en kaders. CSS heeft niets te maken met de inhoud van de pagina.
Dus hoewel XML fantastisch in gebruik is om "records" vast te leggen, is het in XML formaat opslaan van tekstdocumenten met als doel duurzame archivering mogelijk te maken in mijn ogen nogal risicovol. Je hebt geen garantie dat de weergave van het document altijd blijft zoals het ook in briefvorm naar de geadresseerde was, want je bent en blijft afhankelijk van hetgeen in een cascading stylesheet is vastgelegd en die is muteerbaar.

Voor een complete beschrijving van het werken met markuptalen (XML, HTML) zie deze link:

http://docplayer.nl/499012-Html5-deel-1-structuur-van-de-webpagina-...

Antwoorden op discussie

RSS

© 2024   Gemaakt door Marco Klerks.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden