Ettepanekute esitamiseks

Rahvusarhiivi failivormingute juhis Tööversioon 0.1, saadetud esmasele tutvumisringile 27.06.19. Tagasiside, kommentaarid ja täiendusettepanekud on oodatud kuni 04.09.19 aadressile [email protected] Sisukord TOC \h \u \z Sisukord PAGEREF _Toc11318341 \h 1 Taust PAGEREF _Toc11318342 \h 2 Digitaalsete arhivaalide loomise failivormingud PAGEREF _Toc11318343 \h 4 Tekstidokumentide vormingud PAGEREF _Toc11318344 \h 4 Tabelvormingud PAGEREF _Toc11318345 \h 6 Esitlusvormingud PAGEREF _Toc11318346 \h 7 E-kirjade vormingud PAGEREF _Toc11318347 \h 7 Üksikkirjade soovitused PAGEREF _Toc11318348 \h 7 E-kirja kogumite soovitused PAGEREF _Toc11318349 \h 8 XML vormingud PAGEREF _Toc11318350 \h 8 Pildifailid - Rastervormingud PAGEREF _Toc11318351 \h 8 Pildifailid - Vektorgraafika ja CAD vormingud PAGEREF _Toc11318352 \h 9 Filmi- ja videovormingud PAGEREF _Toc11318353 \h 9 Digitaalsete videodokumentide vormingud PAGEREF _Toc11318354 \h 9 Professionaalne digitaalne film (Digital cinema) PAGEREF _Toc11318355 \h 10 Filmide ja videote kasutuskoopiad PAGEREF _Toc11318356 \h 11 Helivormingud PAGEREF _Toc11318357 \h 12 Üldsoovitused - digiallkirjastamine, pakkimine ja kaustad PAGEREF _Toc11318358 \h 12 Uute andmebaaside arendus PAGEREF _Toc11318359 \h 15 Binaarfailid andmebaasis PAGEREF _Toc11318360 \h 15 Andmebaasi dokumenteerimine PAGEREF _Toc11318361 \h 16 Andmemudeli soovitused PAGEREF _Toc11318362 \h 16 Vormingud arhivaalide üleandmisel avalikku arhiivi PAGEREF _Toc11318363 \h 16 Andmebaaside üleandmine avalikku arhiivi PAGEREF _Toc11318364 \h 17 Taust Käesolev juhis on rakendatav eelkõige arhivaalidele ega puuduta arhiiviväärtuseta dokumente. Juhis ei kata veebi ega sotsiaalmeedia arhiveerimise vorminguid, nende osas palume pöörduda Rahvusraamatukogu poole. Teiste, siin juhises kirjeldamata vorminguliikide osas on rahvusarhiiv valmis tegema asutustega koostööd, et välja selgitada parim võimalik lahendus. Dokumente arhiveeritakse selleks, et oleks tagatud nende kasutamine tulevikus. Kuna tehnoloogia ja ühiskonna arengut võime ainult aimata, ei saa me tegelikult kunagi kindlad olla, kas hetkel kasutuses oleva tar k varaga loodud failid on ka tulevikus avatavad ja kasutatavad. Digitaalarhiivindus on riskihaldus - rahvusarhiiv püüab maandada riski, et mõni digiarhivaal võib muutuda ühel hetkel kasutuskõlbmatuks, puudub faili avav tarkvara või ei leidu inimest, kes sobivat tarkvara kasutada oskaks. Selle riski maandamise üheks võimaluseks on kitsendada rahvusarhiivis säilitatavate failivormingute hulka, mis hõlmaks ainult elujõulisemaid vorminguid ja lükkaks vormingu aegumist võimalikult kaugele tulevikku. Pikaajaliseks säilitamiseks eelistame säilitustehnilisi- ja kasutuskriteeriumeid kaalutledes selliseid vorminguid, mis on võimalikult: Kasutajate jaoks olulisi dokumendi omadusi (näiteid leiab allpool) säilitavad; Lihtsad, robustsed, et: kasutustarkvara kirjutamisega saaks eriolukorras hakkama ka rahvusarhiiv; eri tarkvaratootjad tõlgendaksid vormingu aluseks olevat spetsifikatsiooni ühtviisi; fail oleks veakindel, taluks bitiriknemisi ; faili manusfailid ( embedded ) või seosed väliste failidega oleksid hõlpsasti kontrollitavad ja säilitatavad; spetsifikatsiooni versioon oleks stabiilne, väljakujunenud, elujõuline ka lähitulevikus, võimalusel ka tagasiühilduv vanemate versioonide arvestamiseks. Tehniliselt krüpteerimata, pakkimata, DRM-kaitseta ( Digital Rights Management ). Matemaatiliselt (või vähemalt inimtajutavalt ) ilma kadudeta. Avatud spetsifikatsiooniga, et vormingu kirjeldus oleks avalik, litsentsi- ja kommertspiiranguteta ning eriolukorras õnnestuks spetsifikatsiooni abil faili lugeda või kasutustarkvara kirjutada. Laia tarkvara toega soovitavalt avatud lähtekoodiga ja/või vabavaralise tarkvara toega; kui on palju kasutustarkvarasid juba praegu olemas, siis tõenäolisemalt mõni eksisteerib ka kaugemas tulevikus; lisaks kasutustarkvaradele on oluline ka metaandmete ja vormingu tuvastamise, kvaliteedikontrolli, spetsifikatsioonile vastavuse kontrolli ja migreerimise tarkvarade tugi. Laia/mitmekesise kasutajate ringiga ja kasutajate teadmusbaasiga: kasutajakogukondade mitmekesisus nii lõppkasutajate, digitaalarhiivide kui ka tarkvaratootjate poolelt; aktiivsete kasutajate rohkus, kes on huvitatud tarkvaratoe olemasolust, tagab olukorra, kus vajadusel luuakse kasutustarkvara ühiste jõududega või rahastatakse selle loomist ja arendamist; sel põhjusel ei saa uusimaid vormingustandardeid automaatselt eelistada. Soodsate säilitamiskuludega: failid on mahult väikesed; säilitusel kasutatavad tarkvarad on eelistatult vabavaralised; säilitusprotsess on lihtne. Olulistest omadustest Dokumentide olulised omadused on sellised dokumendi aspektid, mis peavad ajas säilima, et dokument oleks kasutatav ja mõttekas (väärtuslik) ka tulevikus. Olulised omadused sõltuvad täpsemalt dokumendiliigist , aga üldisemalt on need järgmised: autentsus, usaldusväärsus (ehtsus, algupärasus. Selle omaduse säilumist saab tagada tehniliselt [digiallkiri, digitempel, kontrollsumma], metaandmetega [logid, Exif], protseduuriliselt [reeglid, dokumendihalduse või digisäilituse menetlusprotsess, dokumenteeritus ja auditid]...) sisu, terviklus, kvaliteet (Informatsiooni mitte-kadumine ega -moondumine dokumendi elutsükli käigus, vähemalt sellisel määral, mis ei takista dokumendi sisu tajumist samal viisil nagu autor kavandas. Eristada tuleb visuaalselt mittemärgatavaid ja rangemalt tehnilisi kadusid; lihtsam ja objektiivsem on kontrollida tehnilisi kadusid näiteks kontrollsummadega. Siia kuulub ka IT-tehniline bitisäilitus varundamise ja taaste mõistes. Sisulise väärtuse säilitamiseks võib olla vajalik vormilist poolt värskendada - tehniliselt faili konverteerida vananevast vormingust uuemasse. Antud omadus nõuab näiteks kaalutlust, kas foto kvaliteet säilub failivormingu muutmisel.) kasutatavus, dokumendi käitumine, kujundus (Kasutusliigid - näiteks kas dokument peab olema ainult visuaalselt loetav (PDF/A) või ka taaskasutatav uute dokumentide loomiseks (ODT). Kasutustarkvara - kas dokument peab olema kasutatav mitmete laialt levinud vabavaraliste tarkvaradega või piisab raskesti leitavast kommertstarkvarast. Kas näiteks tekstidokumendi kasutatavus sõltub teksti visuaalsest kujundusest või mitte.) kontekst, sisemine ja välimine struktuur (Dokumendi seos selle loonud asutuse, funktsioonide, tegevuste, toimingute, dokumendisüsteemi ja teiste dokumentidega. Selle omaduse säilimist tagatakse peamiselt metaandmete ja identifikaatorite [sh failinimede] dokumenteerimise ja säilitamisega. Kui dokument sisaldab alamdokumente [embedded files], siis on oluline ka sisemist struktuuri säilitada) väärtus (Dokumendi tähtsus erinevatele inimrühmadele ja asutustele ühiskonna toimimise kajastamiseks, üksikute toimingute ja tehingute tõestamiseks või uurimishuvi rahuldamiseks. Praktiline väärtus seisneb dokumendi loomise tinginud tegevuse edasises tagamises. See on olulisim, juuromadus, mis moodustub teiste loetletud omaduste summana.) Olulisi omadusi saab liigitada ka muudel viisidel , kuid see ei muuda selle mõiste sisu. Näiteks InSPECT projektis liigitati selliselt: sisu, kontekst, esitus, käitumine ja struktuur. Eksisteerib ka juhtumeid, kus erinevate oluliste omaduste säilitamiseks on vaja luua dokumendist mitu eri vormingut. Sellistel puhkudel tuleks võimalusel luua dokument ühes vormingus, millest muud vormingud saab luua üleandmise järgselt rahvusarhiiv ise. Digitaalsete arhivaalide loomise failivormingud Uute dokumendifailide loomisel soovitame kasutada arhiivieeskirja lisas loetletud arhiivivorminguid. Arhiivivormingud on valitud selliselt, et oleks lihtsam tagada dokumentide oluliste omaduste säilimist pikaajalisel arhiveerimisel. Dokumendi loomise ja dokumendihaldusesse hõlmamise etapist hiljem on raskem tagada, et teisendustel dokumentide olulised omadused ei kahjustuks. Käesoleva peatüki alapunktides allpool on kirjeldatud põhjalikumalt arhiivivormingute kasutusalasid ja muid soovitusi failide loomisega seoses. Üldine soovitus on kasutada võimalusel kõikjal UTF-8 ( Unicode, ISO 10646) kodeeringut selle universaalse arusaadavuse ja tulevase elujõulisuse tõttu. Siin dokumendis on eeldatud, et soovitused kehtivad ka on-line keskkondades (näiteks GoogleDocs, Prezi) loodud dokumentidele, kuna dokumendi elutsüklis vormistamise ja arhiveerimise jaoks tuleb need siiski failina alla laadida. Samuti tuleb arhiveeritavad failid luua pakkimata või kadudeta pakitud ja krüpteerimata kujul. NB! Siin ei ole kajastatud analoogdokumentide digiteerimisel loodavaid failivorminguid. Selle kohta koostab Rahvusarhiiv eraldi juhendi, mis kirjeldab põhjalikumalt ka muid digiteerimissoovitusi. Tekstidokumentide vormingud Lihtsaim tekstivorming on Plain TXT , mis on eelistatuim juhul kui ei ole vaja säilitada teksti kujundust ja struktuuri. Selle vormingu eelis seisneb lihtsuses, avatuses, laias tarkvaratoes ka tulevikus. Kujundusega tekstifailid on soovitav luua kas ODT (Open Document Format Text, mida saab luua näiteks OpenOffice, LibreOffice, StarOffice või uuemate MS Office/365 tarkvaradega) või DOCX (MS Office Open Format XML Document) vormingus. DOCX on mõistlik valik, kui dokumentide loomiseks kasutatakse MS Office Word tarkvara (on tekkinud ka teisi tarkvarasid DOCX toega, aga seal loodud failid ei pruugi teistes tarkvarades avaneda samamoodi nagu originaalis). PDF/A-vormingutest sobib alamvorming PDF/A-2u (toetab PDF/A standardi miinimumnõudeid, lihtsaim tagada nõuetele vastavus, sobilik näiteks digiteerimisel vms juhtudel, kus teksti struktuur on lihtsam) või PDF/A-2a (toetab PDF/A maksimumvõimalusi ja tagab parima kasutatavuse, aga raskem kontrollida arhiivi-sobilikkust, sobilik ainult digisündinud dokumentide puhul). Need PDF-vormingud sobivad ainult juhul, kui sellises vormingus faili saab luua dokumendi autor. Kuna PDF/A ei ole enamasti originaalvorming, siis dokumendi autor peaks veenduma, et originaalfailist PDF/A loomisel ei ole dokumendi olulisi omadusi kahjustatud. Vormingute ODT/DOCX eelis on faili taaskasutamise võimalus tulevikus loodavate uute failide tegemiseks; vormingu PDF/A eelis on dokumendi loomise-aegse trükikujunduse fikseerimine ja laiem kuvamistarkvarade tugi. Lisasoovitused: Kasutatud tekstifondid tuleb integreerida faili (või vältida vähelevinud fonte), vastasel juhul võib fail osutuda loetamatuks. ODT ja DOCX puhul peaks seda jälgima dokumendi looja, PDF/A puhul toimub nõuetele vastavuse kontroll enamasti originaalfailist PDFiks genereerimise tarkvara abil automaatselt, siiski on PDF/A kasutamisel omad riskid: Failis sisalduvad fotod võivad PDFiks konverteerimise korral kasvatada faili mahu ootamatult suureks. (Selle probleemi vastu aitab PDF/A-2 toetatud JPEG2000 kompresseerimine.) PDFiks ei pruugi konverteeruda jooniste läbipaistvad taustad (tulemuseks on kogu joonise asemel must ristkülik, see risk esineb PDF/A-1 puhul, mitte PDF/A-2). Pealkirjade, sisukorra jms kujundus võib PDFiks teisendamisel muutuda Tuleb arvestada, et dokumendis kasutatud väliseid viiteid ei ole enamasti võimalik arhiveerida. Lõika-ja-kleebi teel veebilehitsejast ODT faili lisatud pildid näiteks võivad olla ODT failis lingina originaalile, mitte originaalist sõltumatu ODT-elemendina. Tekstidokumendis kasutatud mittetekstilised elemendid ( embedded pildid, helid, videod) peaksid omakorda olema arhiivivormingus, vastasel korral võivad need osutuda tulevikus loetamatuks. Näiteks joonised on soovitav luua pildifaili arhiivivormingus (vt ptk Pildivormingud). Dokumendi lisad on soovitav luua eraldi failidena. Dokumendi sees sisalduvad teised dokumendid-lisad ei ole arhiveeritavad (DOCXi sisse lisatud teised DOCX või XLSX failid). Vältida raskesti renderdatavaid omadusi (näiteks tekstidokumenti lisatud piltide läbipaistev taust). Dokumendi sisu ei tohi olla krüpteeritud. Dokumendis sisalduvad makrod ei ole arhiveeritavad. Rahvusarhiiv ei soovita dokumentide loomisel kasutada vorminguid RTF (Rich Text Format), DOC (MS Word Document binary) ega PDF üldvormingut riski tõttu, et pikaajaliselt ei pruugi info olla kuvatav originaalis olnud ja autori poolt mõeldud kujul. Eelloetletud teised vormingud on pikaajalise säilitamise jaoks sobilikumad, kuna põhinevad XMLil (mitte binaar-vormingul) ja avatud spetsifikatsioonidel. PDF, PDF/A-1, PDF/A-2, a, u, b PDF või PDF/A . Tava-PDF on väga väheste piirangutega ja seetõttu võib sisaldada ka raskesti säilitatavaid elemente, mis võivad tulevikus loetamatuks osutuda. PDF/A on spetsiaalselt arhiivinduse vajadustele vastavalt spetsifitseeritud PDF-standardi alamosa. PDF ega PDF/A ei ole reeglina dokumentide loomise originaalvorming ja sellesse konverteerimine piirab kasutatavust ainult väljatrükiks/vaatamiseks. Samuti tuleb lähtevormingust PDF versiooni loomisel veenduda, et teisendus toimuks vigadeta. Arhiivis seda masstöötlusena tagada näiteks Archivematica ei ole suutnud . Arhiiviväärtusega dokumentide puhul tuleb tagada, et kogu sisu, eriti pildid, fondid ja värviruumid, oleksid kaasatud. Piirata on vaja problemaatilisi funktsioone, nagu JavaScript, integreeritud failid, heli- või video ( ). PDF/A loomine on riskivabam, kui seda tehakse kohe loomise järel originaaltarkvaras (näiteks kasutades MS Wordis pluginat Adobe PDF Maker) juba dokumendi autori poolt. Ainult nii on realistlik kontrollida, et ’PDF-trükiversioon’ kajastab originaaldokumenti adekvaatselt , . Valiku PDF/A-1 või PDF/A-2 puhul on eelistatud uuemal standardil (PDF/A-1=PDF standard ver 1.4, PDF/A-2=PDF standard ver 1.7) põhinev PDF/A-2 , kuna edaspidised ümberkonverteeerimised ühest PDF alavormingust teise ei pruugi õnnestuda . Muud PDF alaliigid PDF/A-3 , PDF/A-4 , PDF/UA on vähelevinud ja pole näha, et need muutuks arhiivides de-facto standardiks. Põhjalikuma PDF alaliikide ülevaate leiab näiteks DPC raportist . PDF/A-2 täiendused võrreldes PDF/A-1’ga : PDF/A-2 lubab JPEG2000 kompressiooni, mis võimaldab paremat pildikvaliteeti sama failimahu juures. PDF/A-2 lubab läbipaistvust, PDF/A-1 mitte. Seetõttu lubab PDF/A-2 ka vesimärgistamist. PDF/A-2 lubab embed’ ida teisi faile, mis on vastavuses standardiga PDF/A-1 või 2 PDF/A-2 lubab suuremaid faili mahtusid (ka üle 10GB, PDF/A-1 mitte) PDF/A-2 lubab võimalust kihte („ optional content “) näidata/peita, nagu CAD-failides Valik a, b või u: b (PDF/A -1b / -2b / -3b): ainult PDF/A baasfunktsioonid lubatud (b= ’basic’ ); “ ainult visuaal/väljatrükk ”; sobilik analoog-dokumentide digiteerimisel, aga ei võimalda OCR teksti lisamist. u (PDF/A -2u / -3u): nagu -2b/-3b, kuid lisaks mäpitakse kogu tekst Unicode'i nii, et seda saab indekseerida, otsida ja muuta. PDF/A-1 seda alaliiki ei võimalda. (u= ’unicode ’); “ otsitav ”; sobilik digiteeritud dokumentide puhul, võimaldades ka OCR teksti otsingut, samuti on sobilik juhul kui digisündinud dokumendi muid omadusi (linke, interaktiivset sisukorda jms funktsioone) ei ole vajadust säilitada. a (PDF/A -1a / -2a / -3a): täielik vastavus PDF/A standardile (a=’ Accessible’ , ‘all PDF/A functions ’, nõuab unicode-mäppingut (nagu u) ja lisaks kõigi elementide semantilist märgendamist); “tavaline digisündinud”; Tabelvormingud Kui tabeli kujul andmetele on lisaks oluline säilitada ka funktsionaalsust, valemeid, kommentaare, kujundust ja/või arvutuslikke välju, siis on soovitatavateks vorminguteks ODS (Open Document Format Spreadsheet, mida saab luua näiteks OpenOffice, LibreOffice, StarOffice või uuemate MS Office/365 tarkvaradega) või XLSX (MS Office Open Format XML Spreadsheet) vormingus. XLSX on mõistlik valik, kui dokumentide loomiseks kasutatakse MS Office Excel tarkvara. Siin kehtivad samad lisasoovitused, mis tekstidokumentide puhul, eriti juhul kui tabelivormingut kasutatakse just teksti haldamise ja kujundamise, mitte andmetabeli eesmärgil ja kui kujundusest loobumisega on oht ilma jääda olulisest infost. Kui tabel-andmete puhul puudub vajadus säilitada andmetele lisaks funktsionaalsust, valemeid või kujundust ning tabeli struktuur on lihtne, siis eelistatuim vorming on CSV (tekstifail, veergude eraldajaks semikoolon). Vastasel juhul on töövorminguks parem relatsiooniline andmebaas ja arhiveerimise vorminguks SIARD, vt ptk “Andmebaaside arhiveerimine”. Lisasoovitused: Tekstiväljad piiritletud jutumärkidega. Väljade arv kõigil ridadel ühesugune. Veerunimed asuvad esimesel real. Mittesoovitav on ORACLE SQL Loaderiga faili algusesse lisatav CSV faili päis (domeeni nimi, domeeni formaat, font jne..) Tabelandmete failivorminguks ei ole soovitatavad PDF ega mingid selle alaliigid, kuna kaob andmete taaskasutatavuse võimalus. Kui tabelvorming on kasutusel ainult teksti kujundamise-korrastamise eesmärgil, siis võib ka PDF/A-2u või PDF/A-2a sobida, sarnaselt tekstidokumentidele kehtivatele soovitustele. Samuti on võimalikud probleemid PDFiks konverteerimistega. Praegu on veel originaalvormingud ODS või XLSX (isegi XLS) kasutatavad konverteerimisvajaduseta . Uute tabelfailide loomisel ei ole soovitav kasutada XLS (Microsoft Excel binary) vormingut. Eelloetletud ODS ja XLSX vormingud on pikaajalise säilitamise jaoks sobilikumad, kuna põhinevad avalikul, XMLil baseeruval spetsifikatsioonil, mitte binaar-vormingul. Esitlusvormingud Siin kehtivad sarnased üldised soovitused, mis tekstivormingute peatükis. Uute failide loomisel on soovitav kasutada ODP (Open Document Format Presentation), PPTX (MS Office Open Format XML Presentation) või PDF/A-2u või PDF/A-2a . Siin kehtivad samad lisasoovitused, mis tekstidokumentide puhul (riskid linkide, embedded elementide jms osas). Lisasoovitused: PDF/A-ks teisendamisel ei säilu animatsioonid, mitmekihilised elemendid Kasutatud tekstifondid tuleb integreerida faili (või mitte kasutada vähelevinud fonte), vastasel juhul võib fail osutuda loetamatuks. ODP ja PPTX puhul peaks seda jälgima dokumendi looja, PDF/A puhul toimub nõuetele vastavuse kontroll enamasti originaalfailist PDFiks genereerimise tarkvara abil automaatselt. Tuleb arvestada, et dokumendis kasutatud väliseid viiteid ei ole enamasti võimalik arhiveerida. Lõika-ja-kleebi teel veebilehitsejast ODP faili lisatud pildid näiteks võivad olla ODP failis lingina originaalile, mitte originaalist sõltumatu ODP-elemendina. Dokumendis kasutatud mittetekstilised elemendid ( embedded pildid, helid, videod) peaksid omakorda olema arhiivivormingus, vastasel korral võivad osutuda tulevikus loetamatuks. Näiteks joonised on soovitav luua pildifaili arhiivivormingus (vt ptk Pildivormingud). Dokumendi sees sisalduvad teised dokumendid ei ole arhiveeritavad (PPTX sisse lisatud teised DOCX või XSLX failid). Vältida raskesti renderdatavaid omadusi (näiteks lisatud piltide läbipaistev taust). Dokumendi sisu ei tohi olla krüpteeritud. Dokumendis sisalduvad makrod ei ole arhiveeritavad. E-kirjade vormingud Üksikkirjade soovitused E-kirjade osas kehtivad sarnased soovitused nagu tekstiliste dokumendifailide puhul. Soovitav on EDHSi hõlmatav (või muul viisil arhiveeritav) fail luua kohe arhiivivormingus EML (üksik kiri), MBOX (kaust). Need vormingud on avatud standardiga, tekstipõhised ja seetõttu on neil hea veakindlus ja tarkvaratugi eeldatavasti ka tulevikus. EML failina on võimalik üksikuid e-kirju salvestada näiteks levinud meiliprogrammidega MozillaThunderbird ja MS Outlook. MBOX perekonna alamvormingut MBOXrd võimaldab luua MozillaThunderbird. Siin kehtivad tekstidokumentidega sarnased lisasoovitused: Kirjamanused on soovitav luua samuti arhiivivormingus Linkide puhul arvestada nende aegumist jms (vt eespool tekstidokumentide soovitusi) Kirjamanuste puhul arvestage ka peatükki “Digiallkirjastamine, pakkimine ja kaustastruktuur” Sobilik on ka, kui tööprotsessis on kavandatud e-kirjade konverteerimine PDF/A-2u vormingusse, aga sel juhul tuleb veenduda, et kirja manuste hulgas ei oleks tabelfaile, digiallkirjastatud faile vms, mille olulised omadused PDF koosseisus kaduma võivad minna (vt vormingusoovitusi vastavate dokumendiliikide juurest). E-kirjade dokumendihaldusesse hõlmamise/arhiveerimise puhul soovitame mõelda ka kureerimisele ja hindamisele: delikaatsete andmete juurdepääsu korrektne reguleerimine, kontonumbrite jms tundlike andmete automaatne tuvastamine; samuti arhiveeritavast ainesest valiku tegemine, mitte automaatselt 100% kõige arhiveerimine. E-kirja kogumite soovitused Ka E-kirja kogumite puhul ei ole soovitav kasutada dokumendihaldusesse registreerimiseks ja arhiveerimiseks muid vorminguid peale eelpool loetletute. Näiteks ei ole soovitavad Microsofti MSG, PST, kuna praegu teadaolevalt ei ole neist vormingutest arhiivivormingusse konverteerimine veavaba. Mass-arhiveerimisel on PST asemel eelistatud arhiveerida otse meiliserverist üksik-e-kirjade arhiivivormingusse (näiteks tarkvara Mozilla Thunderbird abil MBOX). XML vormingud Dokumendivahetuskihi DHX (endine DVK) kaudu vahetatavatele XML ( Extensible Markup Language ) vormingus dokumentidele on kehtestatud nõuded Riigikantselei, MKM ja RIA poolt. Lisasoovitused: XML fail peab olema reeglipärasel kujul ( well-formed ) vastavalt XML 1.0 spetsifikatsioonile ; seotult ning valideeruvalt sobiva XML skeemiga ( XML Schema ); XML dokumendi kujunduse säilitamiseks tuleb tagada seos ka XML laadileh(ted)ega, mis on valiidne W3C soovituse mõttes ( W3C Extensible Stylesheet Language XSL 1.1 ); XML sisse või kõrvale manustatud failidele kehtivad vastava ainese liigi soovitused (vt eraldi peatükkidest tekstid, pildid, tabelid,...). Pildifailid - Rastervormingud Digitaalselt sündivate rasterpildifailide ja fotode jaoks soovitame vorminguid: TIFF ( Tagged Image File Format ver 6; pakkimata [ uncompressed ]), PNG ( Portable Network Graphics ver 1.2); JP2 (JPEG2000 standardi osa 1 , kadudeta pakkimine); DNG ( Adobe Digital Negative ver 1.4.0.0). Infokvaliteedi pikaajalise säilimise osas on tugevamad JP2 ja TIFF. Fotode puhul annab paremaid pakkimistulemusi JP2. Jooniste jaoks on optimaalne PNG. Digifotode toorvorminguna on soovitav DNG (see tagab EXIFiga võrreldes detailsemate fotoparameetrite salvestumise metaandmetena, samas fotokaamera tootja-spetsiifiliste RAW-vormingutega võrreldes on DNG toetatud rohkemate rasterpildi kasutustarkvarade poolt). DNG kõrval võib sobida ka JP2 (väiksem maht). RAW failide puhul on risk, et fotode arhiivile üleandmise hetkeks ei ole vorming enam avatav. RAW failide konverteerimisel DNG-sse tuleb säilitada fotode metainfo. RAW on soovitav vorming juhul, kui on vaja tagada rangemalt tõestusväärust, autentsust või kui DNG üldovrmingu metaandmed ei kajasta kõiki olulisi (RAW tootjaspetsiifilisi) metaandmeid. Rahvusarhiiv ei soovita luua faile levinud vormingus JPG, kuna selle veakindlus on halvem kui TIFF ja JP2 vormingutel ja kuna JPG vorminguga kaasneb suurem infokadu pakkimisalgoritmi tõttu. Kui failid on juba loodud JPG vormingus, siis rahvusarhiiv ei soovita selliseid faile konverteerida JP2 vormingusse, kuna sellega mahu kokkuhoidu ei lisandu. Samuti ei ole soovitav kadudega pakitud JP2, kuna on keerulisem tagada, et infokadu ei vähendaks sisulist väärtust . GIFist on parem PNG, kaasaegsema efektiivsema pakkimise tõttu (PNGd peetakse GIF järeltulijaks-asendajaks). Pildifailid - Vektorgraafika ja CAD vormingud Vektorgraafika ja CAD vormingutena soovitame: SVG ( Scalable vector graphics ver 1.1, keelatud on Java binding ja Javascript kood) DWG ( AutoCAD Drawing ) DXF ( AutoCAD Drawing Interchange Format ) Lihtsamate jooniste puhul on piisav SVG vorming, keerukamate (mõõdistuste, plaanide ja arhitektuurijooniste) puhul on soovitav kasutada AutoCAD vorminguid (DXF on avatud vorming ASCII-teksti kujul sisuga, aga DWG on laialt levinud [ de-facto CAD standardvorming] suletud binaarvorming, mahult on DWG kompaktsem kui DXF. Mõlemaid vorgminguid toetab ka Eestis levinud CAD tarkvara MicroStation ). SVG sobib ka veebis kuvamiseks, aga vältida tuleb vaikimisi toetatud javat ja javascripti turvariskide tõttu . Erijuhtudel PDF/A-2a võib sobida trükivaate säilitamiseks , aga taaskasutuseks on see piiratum kui SVG või DWG. Filmi- ja videovormingud Filmide ja videote loomiseks soovitab rahvusarhiiv avatud, litsentsipiiranguteta, krüpteerimata, eelistatult kompresseerimata vorminguid, vabavaralise kasutustarkvaraga, mis võimaldavad tulevikus andmete kadudeta migreerimist uutesse vormingutesse. Digitaalsete videodokumentide vormingud AVI ( Audio Video Interleaved Format ) koodek: kompresseerimata 4:2:2 MOV ( QuickTime File Format ) koodek: pakkimata 4:2:2, ProRes vähemalt 422HQ profiiliga või DNxHD vähemalt 8bit 4:2:2 profiiliga MP4 (MPEG-4) koodek: H.264 MXF ( Material Exchange Format ) koodek: MPEG-2, JPEG2000 (kadudeta pakkimine) või DNxHD vähemalt 8bit 4:2:2 profiiliga Professionaalne digitaalne film (Digital cinema) Arhivaali tüüp Arhiivivorming Soovitused Filmi pildimaster (pildikaadrite jada) TIFF (Tagged Image File Format) sequence , pakkimata; DPX (Digital Picture Exchange) sequence, pakkimata; JPEG2000 , kadudeta pakitud Pildikaadrite lineaarne bitisügavus 16, 12 või 10 bitti; pikslite proportsioon 1:1 (square pixels) ; resolutsioon vastavalt DCI standardile; esimene pildikaader peab olema esimene „aktiivne“ kaader, rakordkaadrid puuduvad. Värvusruumi standard (neli varianti): rec.709 inRGB full-range, optimized for display gamma of 2.4; 1931 CIE inXYZ, optimized for a display gamma of 2.6; DCI P3 inRGB, optimized for a display gamma of 2.6; sRGB, optimized for a display gamma of 2.2 Filmi helimaster WAV ( Waveform Audio File Format ); BWF ( Broadcast Wave Format ) LPCM ( Linear Pulse Code Modulation ); resolutsioon 24 bit; diskreetimissagedus ( sample rate ) 48 kHz või 96 kHZ; eraldi mono heli igas helikanalis; heli peab olema pildiga sünkroniseeritud Filmi subtiitrid SRT ( SubRip Subtitle Text Format ); SUB ( Subtitle Text Format ); XML ( Extensible Markup Language ) Subtiitrifailid peavad olema pildi ja heliga sünkroniseeritud Subtiitrite standard (variandid): CineCanvas rev C ; SMPTE 428-7 ; Kinolevikoopia DCP ( Digital Cinema Package , kinode projektorite jaoks); IMF ( Interoperable Master Format , VOD platvormide jaoks), koodek h.264 DCP loodud vastavalt Digital Cinema Initiatives (DCI) versioon 1.2. standardile krüpteerimata Subtiitrite standard: CineCanvas rev C või SMPTE 428-7 Filmide ja videote kasutuskoopiad Kui filmide ja videote masteri kõrval on kasutuseks otstarbekas luua eraldi failiversioonid, siis rahvusarhiiv soovitab selleks järgmisi vorminguid: Arhiivivorming Soovitused AVI ( Audio Video Interleaved Format ) koodek: Uncompressed 4:2:2 MOV ( QuickTime File Format ) koodek: ProRes MP4 (MPEG-4) koodek: H.264 MXF ( Material Exchange Format ) koodek: MPEG-2 või J2K kadudeta kompresseeritud profiil 422P@ML ( main profile at main level ); video bitikiirus ( bitrate ) 50 Mbit/sec (CBR, constant bitrate ); kaadrisagedus 25 kaadrit/sekundis; Helivormingud Heliteoste ja -dokumentide loomiseks soovitab rahvusarhiiv vorminguid: Arhiivivorming Soovitused WAV (Wave Waveform Audio, koodek: Linear Pulse Code Modulated Audio (LPCM)) BWF (Broadcast Wave ver 0, 1 &amp; 2; koodek: Linear Pulse Code Modulated Audio (LPCM)) FLAC (Free Lossless Audio Codec ver 1.21) AIFF ( Audio Interchange File Format ) resolutsioon minimaalselt 16 bit; diskreetimissagedus minimaalselt 48 kHz. Vorming MP3 ei ole helifailide loomiseks soovitav, kuna salvestamine toimub kadudega. Üldsoovitused - digiallkirjastamine, pakkimine ja kaustad Siin peatükis on rõhk arhivaalide digiallkirja ja -templi soovitatud failivormingutel ja failistruktuuril; digiallkirja kasutamise üldiste nõuete ja dokumendihalduse parimate tavade osas tuleb lähtuda RIA, MKM ja Riigikantselei juhistest ja normdokumentidest. Uute digiallkirjafailide loomisel on soovitatavad BDOC (hetkel kehtiv uusim alaversioon) või ASICE, ajatembeldamisel ASICS. Eesti-spetsiifiline . BDOC allkirjafail on DigiDoc tarkvaras vaikimisi valitud vorminguks. Vormingus . ASICE allkirjafail on parima rahvusvahelise ühilduvusega. Nende kahe vormingu vahel valiku saab teha DigiDoc tarkvara seadetes. Ajatembeldamise rakendus TeRa loob vanadest DDOC-failidest .ASICS faile. Ei ole soovitav kasutada vorminguid .DDOC, .BDOC1.0 ja .CDOC . Vorming . DDOC oli kasutusel 2014. aastani ja selles vormingus uusi dokumente ei soovitata luua alates 2015. aastast, mil kasutusse võeti turvalisemad .BDOC ja .ASICE. Vorming . CDOC ehk dokumendi krüpteerimine ei ole arhivaalide puhul lubatud. Tõestusväärtusega dokumentide puhul on oluline tagada autentsuse säilimine. See ei tähenda tingimata digiallkirjastamist (vt allpool Autentsuse tagamise viisid ). Lisasoovitused. Digiallkirjastatud fail võib sisaldada teisi digiallkirjastatud faile. Tulevase arhiivikasutaja seisukohast on lihtsam ja mugavam, kui selline dokumendi sisemine failihierarhia oleks võimalikult lihtne. Samas peab menetluste ja üleandmise käigus säiluma dokumendi ajalugu – failide seos allkirjade/kooskõlastajatega. Digiallkirjastatud dokumentide sisuks olevat faili/kaustastruktuuri ei ole üleandmise käigus realistlik enam üle korrastada ja uuesti allkirjastada. Seetõttu saame anda soovitusi ainult uute EDHS siseste või väliste kooskõlastamisprotsesside arenduse osas: EDHS sisesed kooskõlastamised on soovitav luua toimingute metainfona (tegevuste logina), mitte allkirjastamisena, kui just seadusaktides ei nõuta allkirjastamist. Soovitav on vältida ebavajalikke pakkimisi (näiteks saab korraga allkirjastada ka mitut faili ilma eelnevalt üheks ZIP-failiks tegemata. Erandiks on kaustadesse jagatud failid, sest DigiDoc ei toeta kaustade allkirjastamist). Kui dokumendi kooskõlastajaid on mitu ja iga järgnev kooskõlastaja võib lisada kogumisse faile juurde, siis eri kooskõlastused/allkirjad kehtivad eri failide kohta. Oluline on selgelt eristada, milliste failide kohta millised allkirjad käivad ja milline on allkirjastamiste hierarhia. Eraldi alam-allkirjafailid ühises ülem-allkirjafailis jne võib teha selliste kogumite mõistmise lihtsamaks. Kui kooskõlastatakse sama dokumenti järjest eri isikute poolt, siis on soovitav iga uus allkiri lisada olemasolevasse allkirjafaili esimese allkirja juurde, mitte luua uue allkirja lisamiseks uut digiallkirja faili (eelistatud on kõrvuti allkirjastajad samal tasemel, mitte “digiallkirjafail digiallkirjafaili sees”, kui see ei ole just hädavajalik nagu eelmisel kirjeldatud juhtumil). Juba allkirjastatud dokumendile saab allkirja lisada ainult olemasoleva allkirjaga samas vormingus (ASICE või BDOC). Kui kaustastruktuur on vajalik dokumentide loomise etapis, aga hiljem enam mitte, siis EDHSi registreerimise ja/või digiallkirjastamise hetkeks on soovitav korrastada failid kaustadest välja, et ei tekiks olukordi “1 fail 1 kaustas, mis on omakorda ZIPitud”. Kui kooskõlastamised/digiallkirjastamised toimuvad EDHS-väliselt, siis EDHSi hõlmamise hetkel ei ole enam reaalne digiallkirjafailis olevat failistruktuuri korrastada. Küll saab vältida järgnevas EDHS-siseses menetluses liigsete kaustade/ZIPide/digiallkirjafailide loomist. Enne 2014 digiallkirjastatud DDOC ja BDOC1.0 vormingus digiallkirjastatud dokumendid on soovitav esimesel võimalusel uuesti digiallkirjastada, -tembeldada või ajatembeldada. Lihtsaim on seda teha spetsiaalse rakendusega TeRa, mis otsib ise arvutist kõik vananevas allkirjavormingus failid ja ajatembeldab need krüptograafiliselt murdmiskindlamasse vormingusse ASIC-S. Originaalfailid jäävad samuti alles. Valiku, kas ja milliseid dokumente on vajalik üle tembeldada, saab teha dokumendi kasutusaja, õigustoimingute aegumistähtaegade ja arhiiviväärtuse järgi. Autentsuse tagamise viisid Dokumendi üks olulisi omadusi on autentsus, tõestusväärtus, ehtsus, usaldatavus - tõendatus dokumendi päritolu, loomise aja ja dokumendi loomise järgse muutumatuse, terviklikkuse säilimise kohta. ISKE definitsioon : Andmete terviklus on andmete õigsuse, täielikkuse ja ajakohasuse tagatus ning päritolu autentsus ja volitamatute muutuste puudumine. Autentsust saab tagada ja säilitada mitmel viisil ja sõltuvalt olukorrast saab neid ka omavahel kombineerida, vt loetelu allpool. Loetletud viisidest kvaliteetseimalt tagab autentsuse digiallkirjastamine + tembeldamine + protseduuride + transpordikihi kaitsmine kvalifitseeritud usaldusteenuse sertifikaatidega. Konkreetsel juhul rakendatavad meetodid tuleks valida lähtuvalt rakenduvast infoturbe süsteemist (ISKE: Nõutav turvatase määratakse vastavalt infoturbe eesmärkidele tervikluse, konfidentsiaalsuse ja käideldavuse parameetrite kaudu). Loomulikult tuleb arvestada nii üldiseid (AvTS, IKS,...) seaduseid kui valdkonda, andmekogu ja dokumenteerimist puudutavaid muid seadusakte (vt põhjalikumalt RIA juhisest ). Analoogkandjal dokumendi puhul asutuse templi ja/või isiku omakäelise allkirjaga. Digiallkirjastamine/tembeldamine kvalifitseeritud usaldusteenuse osutaja vahendusel . Dokumendi sisu fikseerimiseks allkirjastamise hetkel arvutatakse faili sisu põhjal kontrollsumma (räsi, hash ) ja lisatakse see allkirjafaili. Lisaks lisatakse sinna usaldusteenuste abil täiendavad andmed isiku ja aja kohta ning registreeritakse usaldusteenuse pakkuja andmebaasis allkirjastatud dok u mendi kontrollsumma. Kehtivuskinnitusteenus lisab .BDOC digitaalallkirjale automaatselt elektroonilise märke, mis määratleb allkirja andmise aja ja näitab, et allkirja andmiseks kasutatud isikut või asutust identifitseeriv sertifikaat sel hetkel kehtis. .ASiC-E allkirjade puhul kasutatakse täiendavalt ka ajatemplit ajatempliteenusest . Väljastatud sertifikaatide kehtivuskinnitusi säilitatakse turvalises andmebaasis, mis võimaldab neid vajadusel tõestamiseks kontrollida. Kehtivuskinnituses olev dokumendi sõnumilühend (kontrollsumma ehk räsi, hash ) ei sisalda infot allkirjastatud dokumendi sisu kohta. Antud lahenduse puhul on mitmeid alaliike, mida saab rakendada kas eraldiseisvalt, omavahel kombineerituna või ajaliselt dokumendi elutsükli eri etappides erinevaid: Isiku digiallkiri ehk e-allkiri tõendab, et dokument pärineb selle saatnud isikult ja dokumenti ei ole allkirjastamise järgselt muudetud. Asutuse digitempel ehk e-tempel tõendab, et dokument pärineb selle saatnud asutusest ja dokumenti ei ole vahepeal muudetud. E-Templit saab kasutada nii koos digitaalallkirjaga kui ka ilma. Ajatempel tõendab, et teatud andmed eksisteerisid vastaval ajahetkel. Vana DDOC faili üle ajatembeldades (vt eespool TeRa) kindlustatakse tehniliselt nõrgaks jääma hakkava vorminguga digiallkirja kehtimise jätkumist tehniliselt uuema vormingu ja selles kasutatava tugevama kontrollsumma algoritmi abil. Vormingu lahtimuukimiskindlus on seotud tõenäosusega, et ei eksisteeri arvutit, mis suudaks luua originaalfailiga samasuguse kontrollsummaga aga teistsuguse sisuga faili ja selline kontrollsummade juhusliku kollisiooni tõenäosus on väga väike. Eri vormingud kasutavad erinevat kontrollsumma algoritmi. Seoses arvutusvõimsuste arenguga on DDOC-failides kasutatava SHA-1 kontrollsumma lahtimuukimise tõenäosus viimastel aastatel märgatavalt kasvanud. Kui X-päeval leiab kinnitust DDOC lahtimuugitavus ja selle väärkasutus, on hilja hakata selliste failide autentsust pikendama. Põhjalikumalt sel teemal on soovitav lugeda RIA ajaveebist. Isikutuvastuse vahendist sõltub digiallkirja kvaliteeditase . ID-kaardi , Mobiil-ID või Digi-ID (digitaalse isikutunnistuse) abil loodud allkirja loetakse võrdseks omakäelise allkirjaga, aga Smart-ID allkirja mitte. Infosüsteemi/andmevahetuskanali turbe (ISKE) meetmetega : protseduuriliste reeglitega (näiteks saab piirata süsteemselt volitusi, et dokumendi/info loomise järel ei ole see enam muudetav järgmistes menetlusetappides) toimingute metainfo logimisega (automaatse, kasutajast sõltumatu logimisega saab tagada toimingute läbipaistvuse, auditeeritavuse) süsteemile ligipääsevate isikute autentimisega . Isikud, kes dokumenti menetlevad, saab automaatselt logida või isiku protseduurilisi volitusi süsteemis reguleerida. Selleks tuleb isik tuvastada, rangeim viis on isikutuvastusvahendi (ID-kaart, Mobiil-ID, Digi-ID, Smart-ID) ja kvalifitseeritud usaldusteenuse osutaja ( isikutuvastussertifikaadi kehtivuskinnitusteenuse) abil, lihtsaim, aga nõrgim viis on kasutajatunnuse ja parooli abil. andmevahetuskanalite tehniliste turvaprotokollide kasutamisega (andmevahetuse rangemaks turvamiseks saab kasutada info saaja ja vastuvõtja autentimise sertifikaate ). Autentsuse tagamise meetmed dokumendisuhtluses välisriikidega (E-)Apostillimine . Notari väljastatava tunnistuse abil dokumendi allkirjastaja pädevuse tõendamine Dokumendi legaliseerimine välisministeeriumi väljastatava tunnistuse abil dokumendi allkirjastaja pädevuse tõendamine Uute andmebaaside arendus Käesolevas peatükis on soovitused asutustele juba andmebaaside arenduse etapis arhiveerimise vajadustega paremini arvestamise jaoks. Binaarfailid andmebaasis Väikesemahuliste binaarfailide seos andmebaasikirjetega on kõige paremini tagatud faile otse andmebaasis hoides. Suuremahulisemate failide otse andmebaasis hoidmine mõjuks halvasti andmebaasi kasutusjõudlusele. Parem on hoida selliseid binaarfaile väljaspool ja andmebaasi panna ainult path ja failinimi, mis näitavad faili asukoha failisüsteemis. Path 'i konstrueerimisel on eelistatud suhteline viitamine (viitamine kõigile binaarfailidele ühisest juurkataloogist alates), mitte absoluutne viitamine (kus viida sees on ka failisüsteemi üldine juurtase). Absoluutse viida puhul on hiljem (pärast arhiveerimist) raskem taasluua failikaustastruktuuri selliselt, et viitamine terveks jääks. Andmebaasi dokumenteerimine Andmebaasi arendades tekkiv dokumentatsioon on kasulik luua, koguda ja säilitada selliselt, et see oleks kasutatav ka tulevikus arhiveeritud andmete tõlgendamiseks. Selliste dokumentide hulka kuuluvad: Andmebaasi skeem (ERD – Entity-Relationship Diagram) SQL-skriptid andmebaasi tabelite, seoste, primaarvõtmete, võõrvõtmete loomiseks Andmesõnastik andmebaasi tabelite ja veergude puhul kasutatud mittetriviaalsete mõistete definitsioonidega, klassifikaatorite selgitustega Ärireeglite kirjeldused, kui need on vajalikud andmetest aru saamiseks. Andmemudeli soovitused Tabeli ja veerunimed võiksid olla võimalikult isekirjeldavad, selged, läbivalt ühes keeles Mittetriviaalsed veerud varustada andmebaasis kommentaaridega Vormingud arhivaalide üleandmisel avalikku arhiivi Rahvusarhiiv on suunaks võtnud, et vastuvõtul on võimalikult vähe toiminguid ( 'minimal effort ingest' ). Järjest enam oleme kogenud, et mõistlik on võtta failid üle selliselt, nagu need on asutuses tekkinud ja seda ka juhul, kui need failide ei ole hetkel kehtivas arhiivivormingus. Erandiks on andmebaaside ja e-kirja-kogumite arhiveerimine. NB! Minimal ingest'i otstarbekus võib sõltuda lähteallikast, millest ainest üle antakse (näiteks failisüsteemist samaliigilisi (nt pildi)faile üle andes on reaalne teha nendega üleandmise eel massteisendusi-kontrolle, aga EDHSist digiallkirjastatud ainest üle andes mitte). Rahvusarhiivi soovitusi digiallkirja faili struktuuri korrastamiseks ja failivormingute valikuks saab anda ainult uute tekkivate dokumentide osas. Ei ole realistlik arhiivile üleandmise hetkel faile-vorminguid-stuktuure korrastada ja uuesti digiallkirjastada. Eelistatud on luua dokument arhiivivormingus või teisendada EDHSi registreerimise hetkel arhiivivormingusse (vt ArhE §5 lg 2). Erijuhtudel, näiteks väga spetsiifiliste failivormingute puhul, mille töötlemiseks on vaja eritarkvara või mille teisendamisel arhiivivormingusse on RAs raskem veenduda, et dokumentide olulised omadused säiliksid, otsustatakse konverteerimine arhiivivormingusse koostöös arhiiviga enne üleandmist. Igal juhul tuleb arhiivile üle anda originaalvormingus fail (asutuses konverteerimise korral tuleb üle anda ka arhiivivormingus fail). Andmebaaside üleandmine avalikku arhiivi Kuna andmebaaside arhiveerimisel on palju juhtumipõhiseid otsustuskohti, siis soovitame selles osas kontakteeruda rahvusarhiiviga. Andmebaaside üleandmiseks üldiselt soovitatav vorming on SIARD (uusim ametlik versioon, hetkel ver 2.1). Kui andmestruktuur on lihtne ja ei vaja lisaselgitusi, siis piisab ka tabelvormingust CSV . SIARD (Software Independent Archiving of Relational Databases) on andmebaaside tarkvara tootjatest sõltumatu vorming, mis on tehniliselt zip fail xml failide struktuurist. Suures plaanis jaguneb vorming kaheks: andmebaasi kirjeldav osa ( header ) ning andmebaasi sisuline osa ( content ). Kirjeldav osa sisaldab metaandmeid mitmetele andmebaasi elementidele: skeemid, tabelid, vaated, veerud, päringud, protseduurid, funktsioonid, kitsendused ( constraints ), päästikud ( triggers ). Sisuline osa sisaldab xml faili iga andmebaasi tabeli ja vaate kohta, kus paiknevad andmebaasi tabelist/vaatest päritud read. Ridadel paiknevad binaarsed failid (BLOB, CLOB, jne) või ridadelt viidatud failisüsteemis asuvad failid paigutatakse eraldi kataloogi vastava tabeli xml faili kõrvale. Lisasoovitused: Andmebaasis sisalduvad suured binaarobjektid (BLOB) tuleb samuti arhiveerida arhiivipüsivasse vormingusse, veel parem oleks juba luua arhiivivormingus. Andmebaasis sisalduvad GIS objektid arhiveeritakse nii üksikobjektina (1 GML fail = 1 objekt) kui kihina (1 GML fail = 1 nähtusteklass), kuna ainult ühega neist kahest variandist piirdudes oleks tulevane võimalik kasutus väga piiratud. GIS arhiveerimisvormingutena soovitame: Vektorandmete puhul SHP (ESRI Shapefile ver: 1997 või uuem) + SIARD või GML (Geographic Markup Language ver 2.0...3.2) + SIARD. Võivad kehtida ka samad vormingud, mis relatsioonilise andmebaasi puhul (kui on liht-geomeetria WKT atribuudina). SIARD ei ole siin vajalik, kui andmed ei tule relatsioonilisest andmebaasist. Rasterandmete puhul GeoTIFF ver 1.8.2 (TIFF+EWF.XML) SIARD fail ei ole tavaliselt piisavalt ise-dokumenteeriv, et tagada arhiveeritavate andmete tõlgendatavus. Seetõttu tuleb arhiveerida lisaks SIARDile ka lähtesüsteemi dokumentatsioon ja andmemudel. Igal juhtumil tuleb otsustada, mida dokumenteerida. Dokumentatsioon võib sisaldada näiteks: graafiline andmemudel (olemi-seose diagramm/ entity relationship diagram , ERD) andmekirjeldused, klassifikaatorid, andmesõnastik infosüsteemi spetsifikatsioon, kirjeldus kasutusjuhend, kehtinud reeglid-seadusaktid, koolitusmaterjalid, ekraanipildid, video kasutamisest. Lingitud avaandmete ja muude NoSQL andmekogude jaoks saab soovitada RDF/XML vormingut, koos andmestruktuuri kirjeldava XSD failiga. Asutusespetsiifiliste XML-kujul andmete, teadusandmete, NoSQL andmebaaside jms erijuhtude osas saab otsustada täpsema üleandmise vormingu asutuse ja arhiivi koostöös. Dokumentatsiooni soovitused kehtivad ka neil juhtumitel. SIARD 2.1 SIARD failivorming on üldstruktuurilt ZIP-fail, milles sisalduvad alamfailid: andmekogu metaandmed ja sisuandmed XML failidena ja andmekogus sisaldunud failid (BLOB ja CLOB objektid) eraldi failidena . Olemasolevate andmekogude konverteerimiseks SIARD vormingusse on võimalik kasutada tööriistu DBPTK (RDBMS→SIARD ja XML kujul dokumentatsioon) või KOST poolt soovitatavat konverterit (CSV→SIARD). Saatja: Gerli Vetema-Rungi </o=Eesti KV/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=64e6e160422d45239108734bf48b47b9-Gerli Vetema-Ru> Saaja: Elle Vahur, Eret Bekman, Tony Kikkas, Anneli Liister Teema: RE: Arhiivivormingud Teie: 28.06.2019 Meie: 13.08.2019 Riigi Kaitseinvesteeringute Keskus on tutvunud Rahvusarhiivi koostatud arhiivivormingute muutmisega seotud dokumentide kavanditega – ettepanekud ja kommentaarid dokumentidele puuduvad. Parimate soovidega Gerli Vetema-Rungi Riigi Kaitseinvesteeringute Keskus direktori abi 717 0400 From: Va.dokumendihaldurid <[email protected]> On Behalf Of [email protected] Sent: Friday, June 28, 2019 12:30 PM To: [email protected] Subject: [Va.dokumendihaldurid] FW: Arhiivivormingud Tere! Edastan Rahvusarhiivi koostatud arhiivivormingute muutmisega seotud dokumentide kavandid. Palume saata oma ettepanekud ja kommentaarid DHOle 26.08.2019. Parimate soovidega Elle Vahur DHO asjaajamise nõunik juhataja ülesannetes From: Pille Noodapera <[email protected] <mailto:[email protected]> > Sent: Thursday, June 27, 2019 4:19 PM To: [email protected] <mailto:[email protected]> Subject: Arhiivivormingud Head kolleegid Rahvusarhiivi digitaalarhiiv ootab teie arvamust ja ettepanekuid kahele manuses olevale dokumendi kavandile – uuele arhiivisobilike failivormingute loetelule ja juhisele nende rakendamiseks. Täpsemad selgitused leiate digitaalarhiivi direktori kirjast (vt allpool). Lugupidamisega Pille Noodapera arhiivi- ja dokumendihalduse nõunik Rahvusarhiiv Tere, head dokumendihaldusnõukogu liikmed Rahvusarhiivi digitaalarhiiv on koostanud arhiivieeskirja (valitsuse määrus 2011.a) lisas olevate 1) arhiivisobilike failivormingute loetelu muutmise ettepaneku ning 2) failivormingute teemat käsitleva juhise esimese versiooni. Arhiivivormingute muutmise ettepanekuga laiendatakse arhiivisobilike failivormingute loetelu kontoritarkvara osas DOCX-grupile ja ODT-grupile, lisatakse tabelite, esitluste, e-kirjade, vektorpiltide, andmebaaside ja GIS vormingud ning täpsustatakse videode, filmide ja helide vorminguid. Rahvusarhiivi failivormingute juhis selgitab arhiivivormingute valiku põhimõtteid, annab soovitusi ja praktilisi nõuandeid erinevateks olukordadeks. Saadame käesolevaga mõlemad dokumendid avaliku sektori asutuste dokumendihalduse, arhiivinduse ja infotehnoloogia spetsialistidele tutvumisringile. Ootame tagasisidet ja vajadusel muudatusettepanekuid 4. septembriks 2019 e-kirjaga aadressile [email protected] <mailto:[email protected]> . Palun saatke see kiri oma haldusalas edasi ka teistele teemast huvituda võivatele kolleegidele! Lugupidamisega Lauri Leht Rahvusarhiivi digitaalarhiivi direktor 7387535 5035789 [email protected] <mailto:[email protected]> Teema: FW: arhiivivormingute nimekirja muutmine ja juhis arvamusringile From: Tony Kikkas <[email protected]> Sent: Friday, June 28, 2019 9:21 AM To: Eret Bekman <[email protected]>; Gerli Vetema-Rungi <[email protected]> Cc: Anneli Liister <[email protected]> Subject: FW: arhiivivormingute nimekirja muutmine ja juhis arvamusringile From: Lauri Leht <[email protected] <mailto:[email protected]> > Sent: Thursday, June 27, 2019 2:25 PM To: 'MKM IT juhid' <[email protected] <mailto:[email protected]> > Subject: arhiivivormingute nimekirja muutmine ja juhis arvamusringile Tere, head IT-juhid Rahvusarhiivi digitaalarhiiv on koostanud arhiivieeskirja (valitsuse määrus 2011.a) lisas olevate 1) arhiivisobilike failivormingute loetelu muutmise ettepaneku ning 2) failivormingute teemat käsitleva juhise esimese versiooni. Arhiivivormingute muutmise ettepanekuga laiendatakse arhiivisobilike failivormingute loetelu kontoritarkvara osas DOCX-grupile ja ODT-grupile, lisatakse tabelite, esitluste, e-kirjade, vektorpiltide, andmebaaside ja GIS vormingud ning täpsustatakse videode, filmide ja helide vorminguid. Rahvusarhiivi failivormingute juhis selgitab arhiivivormingute valiku põhimõtteid, annab soovitusi ja praktilisi nõuandeid erinevateks olukordadeks. Saadame käesolevaga mõlemad dokumendid avaliku sektori asutuste dokumendihalduse, arhiivinduse ja infotehnoloogia spetsialistidele tutvumisringile. Ootame tagasisidet ja vajadusel muudatusettepanekuid 4. septembriks 2019 e-kirjaga aadressile [email protected] <mailto:[email protected]> . Palun saatke see kiri oma majas edasi ka teistele teemast huvituda võivatele kolleegidele! Lugupidamisega Lauri Leht Rahvusarhiivi digitaalarhiivi direktor 7387535 5035789 [email protected] <mailto:[email protected]> Rahvusarhiiv teeb ettepaneku kehtestada Vabariigi Valitsuse 22.1 2 .2011 määruse nr 181 „Arhiivieeskiri“ lisa nr 1 „Arhiivivormingud“ uues sõnastuses allpool esitatud kujul. Saadame käesolevaga avaliku sektori asutuste dokumendihalduse, arhiivinduse ja infotehnoloogia spetsialis tidele arhiivivormingute uuendamise ettepaneku tutvumiseks ja arvamuse avaldamiseks. Koos a rhiivieeskirja muutmise ettepanekuga saadame tutvumisringile ka Rahvusarhiivi failivormingute juhise esimese versiooni, mis laiendab ja selgitab arhiivivormingute tabelis kirjas olevat. Tagasisidet ootame hiljemalt 4. septembriks 2019 e-postiga aadressile [email protected] . Arhiivieeskiri tervikuna on leitav siin: https://www.riigiteataja.ee/akt/131052017011 Arhiivieeskirja praegu kehtiv lisa 1 „Arhiivivormingud“ on leitav siin: https://www.riigiteataja.ee/aktilisa/1310/5201/7011/VV_181m_lisa1.pdf# Saadetud tutvumisringile 27.06.2019. Projekt: a rh iivieeskirja l isa nr 1 arhiivivormingud Kontoritarkvara vormingud Arhiveeritavad failid tuleb luua pakkimata või kadudeta pakitud ja krüpteerimata kujul. Arhivaali tüüp Arhiivivorming Soovitused Tekstidokumendid TXT ( Plain Text Format ) ODT ( Open Document Format Text ) DOCX ( Office Open MS Word Document ) PDF ver /A-2a või /A-2u ( Portable Document Format ) Üldine soovitus on kasutada võimalusel kõikjal UTF-8 ( Unicode, ISO 10646) kodeeringut. tekstifondid integreeritud faili. ODT faili veebist lingitud pildid võivad kaduma minna (lisada, mitte linkida dokumenti). mittetekstilised elemendid ( embedded pildid, helid, videod) peaksid omakorda olema arhiivivormingus Dokumendi lisad on eraldi failidena, mitte dokumendi sees sisalduvad teised dokumendid. Vältida raskesti renderdatavaid omadusi (näiteks lisatud jooniste läbipaistev taust). Dokumendi sisu ei tohi olla krüpteeritud. Dokumendis sisalduvad makrod ei ole arhiveeritavad. Tabelid ( spreadsheet ) CSV ( Comma Separated Format ) ODS ( Open Document Format Spreadsheet ) XLSX ( Office Open MS Excel Spreadsheet ) Samad lisasoovitused, mis tekstidokumentidel. CSV lisasoovitused: Tekstiväljad piiritletud jutumärkidega. Väljade arv kõigil ridadel ühesugune. Veerunimed esimesel real. Mittesoovitav on ORACLE SQL Loaderiga faili algusesse lisatav CSV faili päis Esitlused ODP (Open Document Format Presentation) PPTX (Office Open Presentation) PDF ver /A-2a või /A-2u (Portable Document Format) Samad lisasoovitused, mis tekstidokumentidel, lisaks: PDF/A-ks teisendamisel ei säilu animatsioonid, mitmekihilised elemendid E-kirjad EML (üksikkiri) MBOX (kirjad kaustade kaupa) Samad lisasoovitused, mis tekstidokumentidel. XML dokumendid XML (Extensible Markup Language) XML fail peab olema reeglipärasel kujul ( well-formed ) vastavalt XML 1.0 spetsifikatsioonile; seotult ning valideeruvalt sobiva XML skeemiga ( XML Schema ); soovitavalt seotult XML laadileh(ted)ega, mis on valiidne W3C soovituse mõttes ( W3C Extensible Stylesheet Language XSL 1.1 ). XML sisse kapseldatud sisufailidele kehtivad vastava aineseliigi soovitused (vt eraldi peatükkidest tekstid, pildid, tabelid,...) Rasterpildid, fotod TIFF (Tagged Image File Format ver 6, pakkimata) PNG (Portable Network Graphics ver 1.2) JP2 (JPEG2000 Part 1, kadudeta pakkimine) DNG (Adobe Digital Negative ver 1.4.0.0) Vektorpildid, CAD SVG (Scalable vector graphics ver 1.1) DWG (AutoCAD Drawing) DXF (AutoCAD Drawing Interchange Format) STL (3D Print Stereolithography Format) SVG failides on keelatud Java binding ja Javascript kood Helisalvestised WAV (Wave Waveform Audio, koodek: Linear Pulse Code Modulated Audio (LPCM)) BWF (Broadcast Wave ver. 0, 1 &amp; 2; koodek : Linear Pulse Code Modulated Audio (LPCM)) FLAC (Free Lossless Audio Codec ver 1.21) AIFF (Audio Interchange File Format) resolutsioon minimaalselt 16 bit; diskreetimissagedus minimaalselt 48 kHz Digitaalsete videodokumentide vormingud AVI (Audio Video Interleaved Format) koodek: Uncompressed 4:2:2; MOV (QuickTime File Format) koodek: pakkimata 4:2:2, ProRes vähemalt 422HQ profiiliga või DNxHD vähemalt 8bit 4:2:2 profiiliga; MP4 (MPEG-4) koodek: H.264; MXF (Material Exchange Format) koodek: MPEG-2, JPEG2000 (kadudeta pakitud) või DNxHD vähemalt 8 bit 4:2:2 profiiliga profiil 422P@ML ( main profile at main level ); video bitikiirus (bitrate) 50 Mbit/sec (CBR, constant bitrate ); kaadrisagedus 25 kaadrit/sekundis; Professionaalne digitaalne film ( Digital cinema ) Arhiveeritavad failid tuleb luua krüpteerimata kujul. Arhivaali tüüp Arhiivivorming Soovitused Filmi pildimaster (pildikaadrite jada) TIFF (Tagged Image File Format) sequence, pakkimata; DPX (Digital Picture Exchange) sequence, pakkimata; JPEG2000, kadudeta pakitud pildikaadrite lineaarne bitisügavus 16, 12 või 10 bitti; pikslite proportsioon 1:1 (square pixels) ; resolutsioon vastavalt DCI standardile; esimene pildikaader peab olema esimene „aktiivne“ kaader, rakordkaadrid puuduvad. Värvusruumi standard (neli varianti): rec.709 inRGB full-range, optimized for display gamma of 2.4 ; 1931 CIE inXYZ, optimized for a display gamma of 2.6 ; DCI P3 inRGB, optimized for a display gamma of 2.6 ; sRGB, optimized for a display gamma of 2.2 Filmi helimaster WAV ( Waveform Audio File Format ); BWF ( Broadcast Wave Format ) LPCM ( Linear Pulse Code Modulation ); resolutsioon 24 bit; diskreetimissagedus ( sample rate ) 48 kHz või 96 kHZ; eraldi mono heli igas helikanalis; heli peab olema pildiga sünkroniseeritud Filmi subtiitrid SRT ( SubRip Subtitle Text Format ); SUB ( Subtitle Text Format ) XML ( Extensible Markup Language ) Subtiitrifailid peavad olema pildi ja heliga sünkroniseeritud Subtiitrite standard (variandid): CineCanvas rev C; SMPTE 428-7; Kinolevikoopia DCP ( Digital Cinema Package , kinoprojektorite jaoks) IMF ( Interoperable Master Format , VOD [ video-on-demand ] platvormide jaoks), koodek h.264 DCP loodud vastavalt DCI versioon 1.2. standardile krüpteerimata Subtiitrite standard: CineCanvas rev C või SMPTE 428-7 Kasutuskoopia AVI ( Audio Video Interleaved Format ) koodek: pakkimata 4:2:2 MOV ( QuickTime File Format ) koodek: ProRes MP4 (MPEG-4) koodek: H.264 MXF ( Material Exchange Format ) koodek: MPEG-2 või J2K kadudeta pakitud profiil 422P@ML ( main profile at main level ); video bitikiirus ( bitrate ) 50 Mbit/sec (CBR, constant bitrate ); kaadrisagedus 25 kaadrit/sekundis; Andmebaasid Andmebaaside osas ei saa soovitada arhiivivorminguid loomise etapiks, küll aga avalikku arhiivi üleandmise etapiks. Lisaks üleantavatele andmefailidele on oluline ka andmebaasi kirjeldav dokumentatsioon. Arhivaali tüüp Arhiivivorming Soovitused Relatsioonilised andmebaasid SIARD ver. 2.1 või uuem; CSV Samad lisasoovitused, mis tabel-failide puhul NoSQL andmebaasid, avaandmed RDF/XML + XSD; Voming täpsustatakse koostöös arhiiviga GIS vektorandmed SHP ( ESRI Shapefile ver 1997 või uuem) + SIARD; GML ( Geographic Markup Language ver 2.0...3.2) + SIARD Võivad kehtida ka samad vormingud, mis relatsioonilise andmebaasi puhul (kui on liht-geomeetria WKT atribuudina). SIARD ei ole siin vajalik, kui andmed ei tule relatsioonilisest andmebaasist GIS rasterandmed GeoTIFF ver 1.8.2 (TIFF+EWF.XML) Saatja: Va.dokumendihaldurid <[email protected]> Saaja: [email protected] Teema: [Va.dokumendihaldurid] FW: Arhiivivormingud Tere! Edastan Rahvusarhiivi koostatud arhiivivormingute muutmisega seotud dokumentide kavandid. Palume saata oma ettepanekud ja kommentaarid DHOle 26.08.2019. Parimate soovidega Elle Vahur DHO asjaajamise nõunik juhataja ülesannetes From: Pille Noodapera <[email protected]> Sent: Thursday, June 27, 2019 4:19 PM To: [email protected] Subject: Arhiivivormingud Head kolleegid Rahvusarhiivi digitaalarhiiv ootab teie arvamust ja ettepanekuid kahele manuses olevale dokumendi kavandile – uuele arhiivisobilike failivormingute loetelule ja juhisele nende rakendamiseks. Täpsemad selgitused leiate digitaalarhiivi direktori kirjast (vt allpool). Lugupidamisega Pille Noodapera arhiivi- ja dokumendihalduse nõunik Rahvusarhiiv Tere, head dokumendihaldusnõukogu liikmed Rahvusarhiivi digitaalarhiiv on koostanud arhiivieeskirja (valitsuse määrus 2011.a) lisas olevate 1) arhiivisobilike failivormingute loetelu muutmise ettepaneku ning 2) failivormingute teemat käsitleva juhise esimese versiooni. Arhiivivormingute muutmise ettepanekuga laiendatakse arhiivisobilike failivormingute loetelu kontoritarkvara osas DOCX-grupile ja ODT-grupile, lisatakse tabelite, esitluste, e-kirjade, vektorpiltide, andmebaaside ja GIS vormingud ning täpsustatakse videode, filmide ja helide vorminguid. Rahvusarhiivi failivormingute juhis selgitab arhiivivormingute valiku põhimõtteid, annab soovitusi ja praktilisi nõuandeid erinevateks olukordadeks. Saadame käesolevaga mõlemad dokumendid avaliku sektori asutuste dokumendihalduse, arhiivinduse ja infotehnoloogia spetsialistidele tutvumisringile. Ootame tagasisidet ja vajadusel muudatusettepanekuid 4. septembriks 2019 e-kirjaga aadressile [email protected] <mailto:[email protected]> . Palun saatke see kiri oma haldusalas edasi ka teistele teemast huvituda võivatele kolleegidele! Lugupidamisega Lauri Leht Rahvusarhiivi digitaalarhiivi direktor 7387535 5035789 [email protected] <mailto:[email protected]>