-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tillat mappe og registrering på samme nivå #142
base: master
Are you sure you want to change the base?
Tillat mappe og registrering på samme nivå #142
Conversation
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.
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. |
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. |
[Ø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
|
Øivind, kan du forklare hva du mener her?
…--
Vennlig hilsen
Petter Reinholdtsen
|
@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. |
@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. |
[Ø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
|
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. |
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. |
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.