Tillat mappe og registrering på samme nivå

[petterreinholdtsen]

En begresning i dagens Noark 5 som gjør import av endel datastrukturer litt utfordrende er at det er beskrevet en beskranking om at undermapper og registreringer ikke kan eksistere sammen i en mappe.

Foreslår å fjerne denne begresningen, og så vidt jeg kan se krever det en liten tekstlig endring samt en justering av en UML-diagram.

[tsodring]

Dette er faktisk en viktig endring å få inn i Noark for å hindre at dokumentasjon går tapt. Uten det er det ikke mulig å bevare mange samlinger av data som er ønskelig i arkivet. Bildesamlinger er en use-case jeg har jobbet med der bilder (dokument) er i samme mappe som en undermappe. På samme måte forhindrer dette import av dokumenter fra et filsystem.

Fra en annen siden er det viktig å ta innover seg at en slik endring gjør det mulig at en saksmappe skal ha en journalpost og under(saks)mappe på samme nivå. Dersom det er ønskelig så bør use-casen for dette beskrives. I nikita prosjektet har vi tolket at en saksmappe kan inneholde en under(saks)mappe fordi standarden ikke forhindrer det (så vidt jeg kan se).

Denne endringen vil få konsekvenser på XSD som må også oppdateres. Jeg har ikke satt meg inn i hvor vanskelig det vil være å endre XSD, men jeg tror det kan holde med å fjerne xs:choice. Det må vurderes litt.

[oivkru]

I et arkivdannings-/journalføringssystem som følger standarden bør dette ikke være tillatt, se blant annet MoReq2010 s. 78-81 som inneholder gode forklaringer på dette. Jeg er enig i at standarden ikke forhindrer at en saksmappe kan inneholde en under(saks)mappe (eller at en generell mappe kan inneholde en blanding av saksmapper, møtemapper og andre generelle mapper), men denne undermappen kan da ikke ha sideordnete journalposter/registreringer.

Noe annet er det å bruke Noark 5 sin arkivstruktur som uttrekksformat fra systemer som ikke følger standarden i utgangspunktet, som bildesamlinger, mv., som @tsodring peker på. Det kan være ønskelig å lage Noark 5-tilpassete arkivuttrekk fra system/løsninger som ikke var Noark 5-godkjent i utgangspunktet, og som dermed har større avvik fra standarden. Da er dette avvik vi må kunne håndtere når vi tester arkivuttrekket. Det viktigste da må være at vi får et arkivuttrekk som lar seg bevare og anvende, med de strukturer som faktisk var til stede da det ble skapt.

Usikker på hvordan to ulike tilnærminger til dette skal håndteres i standarden. Begrensningen må kunne håndteres i en godkjenningsprosess, samtidig som avvik fra slike krav til danning ikke skal føre til avvisning av arkivuttrekk.

[petterreinholdtsen]

[Øivind Kruse]

I et arkivdannings-/journalføringssystem som følger standarden bør dette ikke være tillatt, se blant annet MoReq2010 s. 78-81 som inneholder gode forklaringer på dette.

Jeg antar du snakker om <URL: https://moreq.info/files/moreq2010_vol1_v1_1_en.pdf > her. Jeg tok en titt, og ser ikke helt forklaringen på hvorfor. Den snakker om å skape en (kunstig) linær sekvens av arkivinnslag og unngå duplisering, men ser ikke hvorfor dette er uløselige problemer som krever at en unngår ulike typer oppføringer på samme nivå.

Jeg er enig i at standarden ikke forhindrer at en saksmappe kan inneholde en under(saks)mappe (eller at en generell mappe kan inneholde en blanding av saksmapper, møtemapper og andre generelle mapper),

Godt, ta tolker vi Noark 5 og XSD likt der.

men denne undermappen kan da ikke ha sideordnete journalposter/registreringer.

Usikker på hva du mener her. Hvilke hindre gjør at dette ikke kan gjøres? Er det dagens spesifikasjonstekst eller noe datateknisk eller noe annet?

-- Vennlig hilsen Petter Reinholdtsen

[petterreinholdtsen]

Øivind, kan du forklare hva du mener her?

-- Vennlig hilsen Petter Reinholdtsen

[petterreinholdtsen]

@oivkru Hvilken del av <URL: https://moreq.info/files/moreq2010_vol1_v1_1_en.pdf > side 78-81er det du mener som begrunner at mappe og registrering ikke kan være på samme nivå? Ved å tillate dem på samme nivå så vil en kunne lagre komplette katalogstrukturer og innhold i ZIP-filer direkte i Noark-struktur, så dette vil gjøre Noark 5 mer anvendelig og fleksibel.

[oivkru]

@petterreinholdtsen Begrunnelsen i Moreq er det som står på side 78, illustrert på side 79:

This arrangement preserves the integrity and separate identity of each level of aggregation; it allows consistent management policies to be uniformly applied to each level of aggregation and ensures that there is no ambiguity over where records should be created.

Begrunnelsen handler om hvor registreringer skal kunne dannes i et RM-system som er compliant med Moreq-standarden, som en beste-praksistilnærming for hvordan records blir skapt. Da vi opprinnelig skrev Noark 5-standarden var det et poeng at den skulle være compliant med Moreq, så regelen ble implementert der også, i tråd med det som da ble ansett som internasjonal beste-praksis.

Jeg tenker det er mest aktuelt å diskutere hvorvidt denne begrensningen skal videreføres i ny standardisering, jf. utkast til ny informasjonsmodell fra StandardLab: https://github.com/arkivverket/standardlab/blob/master/standarder/infomodell-mvp.md

Innenfor Noark 5 og godkjenning av nye arkivdanningssystem er det nok ikke aktuelt å åpne for dette nå, men et arkivuttrekk bør kunne aksepteres med slike "avvik" fra standarden.

[petterreinholdtsen]

[Øivind Kruse]

@petterreinholdtsen Begrunnelsen i Moreq er det som står på side 78, illustrert på side 79:

This arrangement preserves the integrity and separate identity of each level of aggregation; it allows consistent management policies to be uniformly applied to each level of aggregation and ensures that there is no ambiguity over where records should be created.

Begrunnelsen handler om hvor registreringer skal kunne dannes i et RM-system som er compliant med Moreq-standarden, som en beste-praksistilnærming for hvordan records blir skapt. Da vi opprinnelig skrev Noark 5-standarden var det et poeng at den skulle være compliant med Moreq, så regelen ble implementert der også, i tråd med det som da ble ansett som internasjonal beste-praksis.

Takk. Ser jeg hadde misforstått hvilken del av teksten du henviser til. Godt å få det klargjort. Hvis jeg forstår vokabularet korrekt, så er 'Aggregation' i MoReq et fellesnavn for arkiv, arkivdel, klassifikasjonssystem, klasse og mappe i Noark 5, og 'Record' MoReq det som tilsvarer registrering med til hørende dokumentbeskrivelse og dokumentobjekt i Noark 5.

Jeg forstår dog ikke hvordan dette 'allows consistent management policies to be uniformly applied to each level of aggregation', ei heller hvordan det 'ensures that there is no ambiguity over where records should be created' som er begrunnelsen for denne begresningen, men har ikke lest alle 525 sidene i Moreq 2010. For meg virker det som en vilkårlig begresning med like vilkårlig begrunnelse.

Gitt at 'Aggregation' skal gjøre det enklere og praktisk å arve metadate, regler og tilganger, så må en jo gå ut fra at eventuelle 'Record' som ligger på samme nivå som en 'Aggregation' begge arver det samme, og consistens blir like stor og liten som om to 'Aggregation' ligger på samme nivå under en foreldre-'Aggregation'. I en Noark 5-sammenheng kan det jo være lurt å ikke tillate registrering iblandet klasse i et klassifikasjonssystem, og det er ikke mitt forslag her. Jeg ønsker å kunne omforme en katalogstruktur eller innhold i en ZIP-fil til en Noark 5-deponifil for langtidsoppbevaring, uten kunstig endring av original struktur for å skjule at kataloger og filer kan eksistere side om side i dagens filsystemer og filbokser (zip, tar, lha, etc).

Jeg tenker det er mest aktuelt å diskutere hvorvidt denne begrensningen skal videreføres i ny standardisering, jf. utkast til ny informasjonsmodell fra StandardLab: https://github.com/arkivverket/standardlab/blob/master/standarder/infomodell-mvp.md

Det virker naturlig å diskutere i enhver standardisering rundt bevaring.

Innenfor Noark 5 og godkjenning av nye arkivdanningssystem er det nok ikke aktuelt å åpne for dette nå, men et arkivuttrekk bør kunne aksepteres med slike "avvik" fra standarden.

Gitt at arkivmateriale skal avleveres i Noark 5-format i mange år fremover, så tror jeg det er lurt å åpne også for dette her.

-- Vennlig hilsen Petter Reinholdtsen

[palm72]

I en Noark 5-sammenheng kan det jo være lurt å ikke tillate registrering iblandet klasse i et klassifikasjonssystem, og det er ikke mitt forslag her. Jeg ønsker å kunne omforme en katalogstruktur eller innhold i en ZIP-fil til en Noark 5-deponifil for langtidsoppbevaring, uten kunstig endring av original struktur for å skjule at kataloger og filer kan eksistere side om side i dagens filsystemer og filbokser (zip, tar, lha, etc).

Eksempelet ditt rundt klassering er nok dessverre ikke helt uaktuelt.

Om vi ikke tillater registreringer direkte under et klassifikasjonssystem, så har jeg i alle fall sett mapper registrert på samme nivå som klasser. Basert på at K-kodene er hierarkisk oppbygd er det alltids noen som klasserer saker på høyere nivå enn de burde. For å finne igjen papiret kan det da være viktig å beholde den opprinnelige klassen i stedet for å omklassere mappen i journaluttrekket.

[petterreinholdtsen]

Et viktig bruksområde for meg er muligheten til å omforme et eksisterende katalogtre med filer til et Noark 5-uttrekk for å kunne ta vare på både struktur og metadata (og kanskje også legge inn ekstra metadata), slik at eksisterende data får et format som er enklere å tolke i fremtiden. Formuleringen jeg foreslår fjernet er slik jeg ser det både overflødig og uønsket, og det er et (etter min mening utdatert) tolkningsspørsmål om det er i strid med Moreq. Men viktigere enn om det er i strid med Moreq eller ikke, er om det er lurt å kunne representere vanlige datastrukturer i Noark 5-form. Etter min mening er det både lurt og nødvendig, også for å muliggjøre innebygget arkivering i systemer utenfor den tradisjonelle Noark-sfæren.