M701 Format valideres av Arkade

[sturtzel]

I Noark 5.5 heter det fortsatt "Faste verdier bestemmes senere". I Metadatakatalog objektsortert er det henvist til VE.DOKFORMAT, riktignok i parentes. I Noark 4 heter det at verdien skal være RA-TEKST, RA-PDF etc.

Arkade 5 forventer at feltet skal inneholde filtypen eksakt lik som i dokumentet. Filtypen er en del av M218 og er derfor et unødvendig felt. Skal det standardiseres bør det heller standardiseres som f.eks. MIME-type, noe som er nyttig på nettsider, i e-post m.m.

Inntil standardisering bør Arkade 5 akseptere hva som helst i feltet.

[petterreinholdtsen]

I følge https://github.com/arkivverket/schemas/issues/14 skal feltet, muligens kun i fremtiden, inneholde PRONOM-koder. Det bør skrives eksplisitt inn i standarden.

[erikaaberg]

Ja. RA-* formatene er på vei ut. Arkade vi l inntil videre fortsatt teste på filtype (en PDF skal hete .pdf). Men vi har en utredning på om Arkade kan bruke standard PRONOM/DROID programvare for å sjekke om noe som heter PDF faktisk er PDF (og hvilken av de 5-6 "lovlige" PDF varianter det er). Vi tror ikke vi skal bruke MIME. PRONOM er mer granulert og bedre til formålet.

[petterreinholdtsen]

[Erik Aaberg]

Ja. RA-* formatene er på vei ut.

Hvor har du det fra at RA-*-formatene har vært "inne"? Jeg har ikke funnet en eneste autorativ kilde fra Arkivverket for formatkoder, og finner det dermed urimelig at Arkade skal klage på verdier i dette feltet. Det eneste jeg har funnet er henvisning om at listen over formatverdier skal komme senere...

Arkade vi l inntil videre fortsatt teste på filtype (en PDF skal hete .pdf).

Hva er poenget med å blande format og filnavn? I et program jeg laget bruker jeg sjekksum som filnavn, og får automatisk deduplisering av innhold. Det synes jeg dermed bør være tillatt.

Men vi har en utredning på om Arkade kan bruke standard PRONOM/DROID programvare for å sjekke om noe som heter PDF faktisk er PDF (og hvilken av de 5-6 "lovlige" PDF varianter det er). Vi tror ikke vi skal burke MIME. PRONOM er mer granulert og bedre til formålet.

Høres lovende ut.

-- Vennlig hilsen Petter Reinholdtsen

[erikaaberg]

Fra en antikk spesifikasjon (Noark 4):Følgende faste verdier inngår som godkjente arkivformat ved utgivelsen av Noark-4:

---

• RA-TEKST - ISO 8859-1 • RA-TIFF6 - TIFF versjon 6. • RA-SGML - SGML med tilhørende DTD • RA-PDF - Portable document format I tillegg kan det legges inn egne verdier. Verdier som starter med RA- er reservert for fremtidig bruk av Riksarkivet.

---

Ikke enig at filendelse er irrelevant. Det er heldigvis en sterk korrelasjon mellom filendelse og filtype. Men enig at det ikke er nok. Sjekksum er en mulighet, og vi håper å få til en ekte DROID sjekk fra Arkade.

[sturtzel]

Filtypen (filnavnet) ligger i referanseDokumentfil. Kan derfor ikke se at filtypen i format legger til mer informasjon.

Jeg har ikke sett noe som underbygger behovet for Pronom utenfor arkivet / depotet. Derfor mener jeg at dette kan tas senere i prosessen. Depotet må uansett kunne konvertere til nye formater. For vanlig bruk holder det med filnavnet og der det er behov for mer er mimetypen mest vanlig (som e-post, HTML).

Om Arkade skal inn med tester her foreslår jeg at Arkade bygger tilleggsinformasjon som legges inn i SIP-en, evt. at det tas i AIP-en.

PS: M701 refererer til VE.DOKFORMAT som er Noark 4 der RA-xxx står. Siden har det ikke stått noe.

[sturtzel]

På bakgrunn av det Arkivverket går ut med at det skal bli færre krav og kanskje systemer som SharePoint skal kunne være godkjent ut av boksen, passer ikke et krav om Pronom inn. Dette er informasjon som det ikke kan forventes at vilkårlige fagsystemer kjenner til og dermed heller ikke støtter.

Pronom bør derfor tas av felles programvare som Arkade i forbindelse med pakking av uttrekk. Da behøver ikke e-postsystemer, samhandlingssystemer, diverse fagsystemer etc. å forholde seg til feltet som ikke gir de noe verdi.

Dokumentasjonen av Noark 5.5 bør oppdateres til å si at feltet format skal være lik filtype. Hvis ikke bør testen i Arkade fjernes.

[petterreinholdtsen]

Det er greit å ta med seg at filtyper antagelig er det som kommer etter siste punktum i filnavnet på noen plantformer, for eksempel de tre siste tegnene i filnavn på MS/DOS. Slike fil-endinger forteller desverre lite om hvilket format en gitt fil har, hvilket er nyttig når en skal vurdere hva som kan gjøres med filene. Et eksempel jeg kom borte i nylig var .eap, som https://fileinfo.com/extension/eap forteller er to ulike formater, et fra Adobe og et fra Sparx Systems (men ingen av dem ser ut til å være registrert i PRONOM). Et annet og mer nærliggende eksempel er .pdf, som jo ikke forteller om det er PDF/A eller noen av de andre variantene av PDF, der kun et fåtall av disse gir håp om å kunne leses som 500 år. .pdf ser ut til å ha 38 ulike PRONOM-koder i dag, i følge http://www.nationalarchives.gov.uk/PRONOM/Format/proFormatSearch.aspx?status=new .

Det gjør at fil-endinger ikke gir nyttig informasjon når en skal behandle informasjon om filer maskinelt i fremtiden.

[sturtzel]

Jeg protesterer ikke mot PRONOM som noe depotet trenger, men som noe alle Noark-systemer må kunne. Jeg ser som sagt ikke for meg at samhandlingsplattformer, fagsystemer, e-postsystemer+++ vil kunne sende inn eller nyttiggjøre seg disse kodene. Derfor mener jeg at dette er noe som kan tas ved deponering (som bør skje mye tidligere enn i dag) og ikke bør inn i den datamodellen som eksponeres for alle brukere av Noark. De klarer seg med filtype og mime som er det maksimale de kommer til å fore arkivkjernen med.

For å finne PRONOM-koden må filene gjennom en analyse og den bør belastes færrest mulig. Dette er også i tråd med de signalene som nå kommer fra Arkivverket om ytterligere forenkling (eller kanskje avvikling) av Noark. Tror vi at Microsoft m.fl. vil innføre PRONOM i sine plattformer? Skjer det skal jeg revurdere standpunktet mitt. En annen sak er om programvaren om 500 år virkelig vil ta hensyn til 38 eller flere ulike utvidelser/beskrankninger av PDF-formatet eller om PDF 1.7 vil anses å være godt nok som identifikator.

[erikaaberg]

Da er vi nok enige. Vi ser identifikasjon av PRONOM kode som noe Arkade kan gjøre - som opsjon (som oftest sentralt). Og lagre dette som tilleggs informasjon. Det vil være nyttig å vite. Det er stort sett samsvar mellom filendelse og (gruppe av) filtype. Men det kan A: være nyttig å sjekke og B: være nytitig å vite mer detaljer (f.x. hvilken PDF variant). NB: En PRONOM sjekk garanterer ikke full compliance med en standard. Til det må vi kjøre tilleggsprogrammer.

[petterreinholdtsen]

[Erik Aaberg]

Vi ser identifikasjon av PRONOM kode som noe Arkade kan gjøre - som opsjon (som oftest sentralt). Og lagre dette som tilleggs informasjon.

Foreslår du her at Arkade legger inn format-verdier i XML-en etter at den er trukket ut av arkivsystemet? Det vil vel gjøre sjekksum for arkivstruktur.xml i arkivuttrekk.xml ugyldig.

Forøvrig er jeg enig med @sturtzel at Arkade foreløbig ikke bør avvise verdier i format-feltet, da det ikke finnes en offisiell liste over formatkoder som skal brukes i dette feltet. Når slik liste er definert, så kan Arkade begynne å håndheve at listen er brukt.

Innspillet om hvorvidt fagsystemer, samhandlingsplatformer og andre trenger å forholde seg til PRONOM-koder virker å være på siden av problemstillingen om hva slags informasjon som tas vare på i arkivsystemet og som følger med i en XML-uttrekk som Arkade skal verifisere. Det holder jo at arkivsystemet eller programmet som lager uttrekks-XML forstår seg PRONOM-koder, og at disse blir korrekt satt i XML-en ved uttrekk. PRONOM-koder trenger jo ikke ha sin opprinnelse ved dokumentets kilde, så lenge det blir er satt når det lages et uttrekk.

-- Vennlig hilsen Petter Reinholdtsen

[erikaaberg]

Nei. Vi må ikke tukle med arkiv[struktur|uttrekk].xml. PRONOM informasjon blir en del av testrapporten. Apropos det - vi arbeider nå med en ny spec. for testrapport - som etter hvert vil produseres i HTML og XML (maskinlesbar) form - evt. også i en PDF variant. Maskinlesbar form er sentralt i forbindelse med automatisering og vårt prosjekt for langtids bevaring.

[erikaaberg]

Fixet. Ref PRONOM test og VeraPDF validering.