Legg ved valgfri sjekksummer i konverteringsinformasjonen

[petterreinholdtsen]

Med dagens beskrivelse av konverteringsinformasjon er det ikke mulig verifisere konverteringskjeder. Hvis flere konverteringskjeder er oppgitt, så vil det ikke være mulig å vite hvilken kjende en gitt konvertering tilhører.

Et eksempel er et innkommet ODT-dokument, som konverteres til DOCX, så til PDF og så til PDF/A. Hvis en så oppdager at DOCX til PDF-konverteringen feilet og gjør en ny konvertering, så er det kun tidsstemplet som kan brukes til å forsøke å gjenskape konverteringskjeden.

Ved å ta med sjekksum (M705) til fra- og til-fil i konverteringsoppføringen, så blir det mulig å identifisere hvilke deler av kjeden som hører sammen ved å se hvilken fra-fil i en konvertering som har samme sjekksum som til-fil i en annen konvertering. Dette vil også kunne brukes til å oppdage brutte kjeder, hvis en fil har vært endret på disk mellom to konverteringer.

Da konvertering vil ha to sjekksumverdier (det vil si M705 sjekksum), så må disse feltene gis to ulike navn. Verdiene konvertertFraSjekksum og konvertertTilSjekksum er altså ment å være to instanser av metadatakatalogoppføring M705, ikke to nye typer.

Hvis kjeden skal kunne følges må en sjekksum påføres ved konvertering og ikke ved avlevering. Beskrivelsen av M705 er justert for å ta høyde for dette.

[petterreinholdtsen]

Se også https://github.com/arkivverket/schemas/issues/17 som diskuterer konvertering.

[hanber]

Tidligere praksis er å opprette ett metadata-element for hvert element av samme type, som M712 KonvertertFraFormat og M713 konvertertTilFormat, selv om begge er av typen Format. Kommentarene til disse sier "Bruker samme verdier som M701 format". Ett unntak er systemID, som vi har lagt inn som egen datatype for referanse-metadataene. Vi kunne gjort det samme for eksempelet over, og skrevet at datatypen for disse er "format".

Jeg synes uansett vi skal opprette konvertertFraSjekksum og konvertertTilSjekksum som egne metadata-elementer i metadatakatalogen. Inntil vi får tid til en bredere gjennomgang, synes jeg også vi skal legge inn i kommentarene at de "Bruker samme verdier som M705 sjekksum"

[petterreinholdtsen]

Jeg har oppdatert forslaget og introdusert nye M717 og M718 slik du ba om, samt valgt kravnummer et nummer større enn siste i 2.7.x-serien. Ser det bedre ut?

[hanber]

Jeg har sett litt nærmere på dokumentasjon av konvertering, og kommet fram til at dette bør løses ved å opprette et nytt dokumentobjekt for hver konvertering og ta vare på dokumentobjektet som refererer til dokumentfilen det konverteres fra.

Dagens modell innebærer at filen det konverteres fra ikke tas vare på, siden ett dokumentobjekt er knyttet til flere konverteringer, og det ikke finnes noen referanse til dokumentfilen det er konvertert fra. Jeg oppfatter konvertering-objektene som er gruppert inn i samme dokumentobjekt, som sekvensen av konverteringer som førte til gjeldende dokumentobjekt og dokumentfil.

Slik jeg oppfatter det, er tanken at en dokumentbeskrivelse vil inneholde flere dokumentobjekter der hvor et dokument er satt sammen av flere filer, og eventuelt versjoner og varianter av disse.

Siden dokumentobjekt har metadataene versjonsnummer og variantformat, oppfatter jeg det slik at en dokumentversjon kan ha flere varianter (f.eks. sladdet og usladdet). Det er antakelig ikke nødvendig med varianter av annet enn den siste, ferdigstilte versjonen. Uansett kan det til én dokumentbeskrivelse være knyttet dokumentobjekter med ulike versjoner og varianter.

I dagens modell er så vidt jeg kan forstå konvertertTilFormat unødvendig, da det vil være det samme som format i dokumentobjektet konverteringen er gruppert inn i. Det er heller ikke behov for det foreslåtte metadataelementet konvertertTilSjekksum, siden denne sjekksummen er den samme som sjekksum i dokumentobjektet konverteringen er gruppert inn i.

Ved konvertering av dokumentfilen (identifisert ved referanseDokumentfil) fra ett filformat til at annet må det opprettes en ny fil med resultatet av konverteringen, referanseDokumentfil må oppdateres til å referere denne nye filen, og den gamle tas ikke vare på. For integritetssikringen er jeg helt enig i at også filen det ble konvertert fra burde bevares, i alle fall for integritetskontroll fram til overføring til depot, men helst også i depot.

Dette kan oppnås med dagens modell dersom det opprettes et nytt dokumentobjekt ved hver konvertering. Det vil også gjøre mange av metadataene i konvertering unødvendig. Det må innføres et nytt metadataelement konvertertFra som er systemID i dokumentobjektet med referanse til filen det er konvertert fra.

konvertertDato og konvertertAv i konvertering vil være det samme som opprettetDato og opprettetAv i dokumentobjektet konvertering er gruppert inn i.

konvertertFraFormat i konvertering er det samme som format i dokumentobjektet med systemID lik konvertertFra i konvertering.

Multiplisiteten til konvertering vil dermed også bli 0..1, slik at hvert dokumentobjekt bare er relatert til dokumentobjektet det er konvertert fra. Jeg synes da at vi like gjerne kan kvitte oss med konvertering som en egen objekttype, og legge de gjenværende metadataene inn i dokumentobjekt.

Jeg foreslår denne løsningen. Synspunkter mottas med takk.

[petterreinholdtsen]

[Hans Fredrik Berg]

Jeg foreslår denne løsningen. Synspunkter mottas med takk.

Dette kommer i konflikt med krav 6.4.40 (Hvert dokumentobjekt i arkivstruktur.xml skal ha en referanse til en dokumentfil i avleveringspakken), så den må endres hvis dette skal gjøres. Tror også mangelmelding #98 og endringsforslag #99 om å ta vare på originalfilene bør ses i denne sammenheng.

Når det er sagt, så synes jeg ideen er god. Hvis jeg forstår forslaget riktig, så blir det seende omtrent slik ut:

uuid1 sha-verdi1 DOKUMENT/fil1 ... uuid2 sha-verdi2 DOKUMENT/fil2 uuid1 ... Dette fjerner behovet for å notere sjekksummer separat, slik jeg forstår det. Slik jeg forstår dagens modell må det slik du skriver, alltid opprettes en dokumentobjekt som holder resultatet av konverteringen, og det er dårlig beskrevet hvorvidt "konvertering"-blokken skal legges på kilde-dokumentobjekt, mål-dokumentobjekt, eller begge, jamfør mangelmelding #50. Jeg ønsker at konverteringsinformasjon kan brukes til å dokumentere hele kjeden av konverteringer fra originaldokument til arkivformat, i tilfelle det har hatt flere steg. Hvis noen lager en database, som gjøres om til CSV, deretter et regneark og til slutt en PDF, så bør det fremgå av arkivet hvor lang kjeden i hviskeleken har vært, og en bør kunne sjekke at resultatet fra et steg ble brukt som inndata i neste steg. Det en mister med dette forslaget er informasjon om hvilket verktøy som ble brukt til konverteringen, og eventuell kommentar til konverteringen. Det kan være uheldig å ikke kunne spore opp alle filer konvertert med et defekt verktøy, slik at det virker uheldig å miste den muligheten. Kanskje det i tillegg til konvertertFra bør være noen flere felt? Hvis en trenger tre felt, så er det kanske like greit å beholde med multiplisitet 0-1 i dokumentobjekt, der en dropper konvertertDato, konvertertAv, konvertertFraFormat og konvertertTilFormat men legger inn konvertertFra som inneholder til dokumentobjekt.systemID. -- Vennlig hilsen Petter Reinholdtsen

[hanber]

Det er helt riktig at dette er i konflikt med krav 6.4.40, så det må eventuelt endres. Når det er sagt, er det en stadig mer utbredt oppfatning i Arkivverket om at komplette databaser bør avleveres, og sett i lys av dette ville det ikke være urimelig å kreve avlevering av produksjonsformat og alle konverterte filer på veien mot arkivformat. Dette er eventuelt en beslutning som må tas på et høyere nivå.

XML-snutten er akkurat slik jeg mener det.

Mitt forslag innebærer at konverteringsinformasjonen legges på mål-dokumentobjektet. Dette gjelder også metadataene konverteringsverktoey og konverteringskommentar.

Jeg har ingen sterke synspunkter på om konvertering bør være en egen objekttype eller ikke.

Slik jeg oppfatter det, inngår i dagens modell konvertering i en komposisjon til dokumentobjekt, altså konvertering-objektet slettes dersom dokumentobjektet slettes og konvertering-objektet har ingen identifikator. Dersom vi skal beholde modellen som den er, og likevel beholde informasjonen om mellomkonverteringer, må den gjøres om til en aggregering, og konvertering-objektet kan leve videre selv om dokumentobjektet slettes. For å kunne spore konverteringskjeden må konverteringsinformasjonen for alle de slettede dokumentobjektene tas vare på ved å knyttes til dokumentobjektet som skal bevares. I så fall vil det være aktuelt å ha med alle de eksisterende metadataene i konvertering i tillegg til konvertertFraSjekksum og konvertertTilSjekksum samt sjekksumalgoritmeFra og sjekksumalgoritmeTil.

[petterreinholdtsen]

[Hans Fredrik Berg]

Det er helt riktig at dette er i konflikt med krav 6.4.40, så det må eventuelt endres.

Da har jeg forstått deg riktig.

Når det er sagt, er det en stadig mer utbredt oppfatning i Arkivverket om at komplette databaser bør avleveres, og sett i lys av dette ville det ikke være urimelig å kreve avlevering av produksjonsformat og alle konverterte filer på veien mot arkivformat. Dette er eventuelt en beslutning som må tas på et høyere nivå.

Antar den diskusjonen kan fortsette i #98. Jeg foreslår der å fjerne formuleringer som indikerer forbud mot å ta vare på originaler, ikke krav om å gjøre det.

XML-snutten er akkurat slik jeg mener det.

Mitt forslag innebærer at konverteringsinformasjonen legges på mål-dokumentobjektet. Dette gjelder også metadataene konverteringsverktoey og konverteringskommentar.

Aha.

Jeg har ingen sterke synspunkter på om konvertering bør være en egen objekttype eller ikke.

Slik jeg oppfatter det, inngår i dagens modell konvertering i en komposisjon til dokumentobjekt, altså konvertering-objektet slettes dersom dokumentobjektet slettes og konvertering-objektet har ingen identifikator. Dersom vi skal beholde modellen som den er, og likevel beholde informasjonen om mellomkonverteringer, må den gjøres om til en aggregering, og konvertering-objektet kan leve videre selv om dokumentobjektet slettes.

Tror ikke det trengs gjøres om til aggregering, se under.

For å kunne spore konverteringskjeden må konverteringsinformasjonen for alle de slettede dokumentobjektene tas vare på ved å knyttes til dokumentobjektet som skal bevares. I så fall vil det være aktuelt å ha med alle de eksisterende metadataene i konvertering i tillegg til konvertertFraSjekksum og konvertertTilSjekksum samt sjekksumalgoritmeFra og sjekksumalgoritmeTil.

Det var mitt opprinnelige forslag, ja.

Slik jeg etter hvert forstår dagens modell, der dokumentobjekt kan ha 0-M konvertering, bør en kopiere konvertering-informasjon fra kildefilens konveteringsliste til målfilens konverteringsliste ved konvertering for å sikre at den blir tatt vare på hvis kildefilen og tilhørende dokumentobjekt slettes. Dvs noe ala dette:

uuid1 sha-verdi1 format1 DOKUMENT/original ... uuid2 sha-verdi2 format2 DOKUMENT/konvertert-fra-original ... ... ... format1 format2 Fint konverteringsverktøy Ignorerte alle feilmeldinger ... uuid3 sha-verdi3 format3 DOKUMENT/dobbelkonvertering ... ... ... format2 format3 Fint konverteringsverktøy Ignorerte alle feilmeldinger ... ... format1 format2 Fint konverteringsverktøy Ignorerte alle feilmeldinger ... Men det står ingen steder i Noark 5 klart at det er slik det skal gjøres, dvs. at konvertering kopieres fra kildens dokumentobjekt, som jeg kjenner til. Ved å kopiere dem på dette måten sikrer en at kjeden tas vare på. men mister muligheten til å identifisere hvilken fil som ble brukt i konverteringen. Det er der jeg så behov for sjekksum, slik at en kanidentifisere hvilke filer som ble brukt som inn- og ut-data i konverteringsprosessen, men også finne eventuelle duplikater. -- Vennlig hilsen Petter Reinholdtsen

[hanber]

Dette er helt klart en måte å gjøre det på, som ikke gjør noen strukturelle endringer i dagens modell. Jeg er enig i at vi da bør ha med konvertertFraSjekksum og konvertertTilSjekksum, slik at vi i det minste kan verifisere at konvertertFraSjekksum i en konvertering er den samme som konvertertTilSjekksum i den forrige. Men det beste ville vært å ta vare på dokumentobjektene.

[petterreinholdtsen]

[Hans Fredrik Berg]

Dette er helt klart en måte å gjøre det på, som ikke gjør noen strukturelle endringer i dagens modell. Jeg er enig i at vi da bør ha med konvertertFraSjekksum og konvertertTilSjekksum, slik at vi i det minste kan verifisere at konvertertFraSjekksum i en konvertering er den samme som konvertertTilSjekksum i den forrige. Men det beste ville vært å ta vare på dokumentobjektene.

Hva er en god vei videre her? Lage et konkurrerende endringsforslag som dropper og introduserer ekstra felter i og fjerner krav om at alle skal være koblet til en fil? Eller det bedre å velge tilnærming først, og så lage endringsforslaget. Uansett, hva er beslutningsprosessen i så tilfelle for å velge hvilken tilnæring som skal brukes? Virker som det er litt i det blå hvordan konkludere når det finnes flere utmerkede tilnærminger. -- Vennlig hilsen Petter Reinholdtsen

[hanber]

Jeg tror det lureste er å foreslå, som du allerede har gjort, at vi oppretter metadataelementene konvertertFraSjekksum og konvertertTilSjekksum eller bare sjekksumFra og sjekksumTil i konvertering-objektet, siden det ikke krever andre endringer.

[petterreinholdtsen]

Godt. 21 dager senere lurer jeg dermed på hva jeg kan gjøre for å få en avgjørelse på om denne endringen tas inn i spesifikasjonen eller ikke?

[hanber]

Før merge, et par oppklaringskommentarer.

I nytt linjenr 683: Er det hensiktsmessig å kreve at det brukes samme sjekksumalgoritme som i dokumentobjekt både for fra-filen og til-filen? Låser vi oss ikke da til at samme algoritme må benyttes for alle sjekksummer i konverteringskjeden? Det er kanskje ikke noe problematisk krav, og i motsatt fall må vi vel også ha med sjekksumFraAlgoritme og sjekksumTilAlgoritme i konvertering-objektet.

Kommentarene til M717 og M718 skal være "Bruker samme verdier som M705 sjekksum."

[petterreinholdtsen]

[Hans Fredrik Berg]

Før merge, et par oppklaringskommentarer.

I nytt linjenr 683: Er det hensiktsmessig å kreve at det brukes samme sjekksumalgoritme som i dokumentobjekt både for fra-filen og til-filen? Låser vi oss ikke da til at samme algoritme må benyttes for alle sjekksummer i konverteringskjeden? Det er kanskje ikke noe problematisk krav, og i motsatt fall må vi vel også ha med sjekksumFraAlgoritme og sjekksumTilAlgoritme i konvertering-objektet.

Forslaget er basert på at det i dag kun er en sjekksumalgoritme definert. Hvis det kommer flere, så bør det kunne spesifiseres både fra og til. Konverteringen dokumenterer jo forholdet mellom to dokumentobjekt, så en vil jo måtte begrense seg til algoritmer som er akseptable i dokumentobjekt. Kan godt dele feltet i to, for å beholde fleksibiliteten, og for å unngå å måtte endre attributtlisten hvis flere algoritmer aksepteres. Skal jeg gjøre det?

Kommentarene til M717 og M718 skal være "Bruker samme verdier som M705 sjekksum."

Ah, bra du oppdaget det. Fikset.

-- Vennlig hilsen Petter Reinholdtsen

[hanber]

Ja, legg inn algoritme for fra- og til-sjekksummene også, så har vi full fleksibilitet.

[petterreinholdtsen]

[Hans Fredrik Berg]

Ja, legg inn algoritme for fra- og til-sjekksummene også, så har vi full fleksibilitet.

Det er nå gjort. Endret metadatanummerering til

• M717 konvertertFraSjekksum
• M718 konvertertFraSjekksumAlgoritme
• M719 konvertertTilSjekksum
• M720 konvertertTilSjekksumAlgoritme

-- Vennlig hilsen Petter Reinholdtsen