En diskusjon om bruk av UUID (Universally Unique Identifier) som arkividentifikator iNikita Noark5 Coreversjon 0.9kan ta utgangspunkt i både tekniske og arkivfaglige vurderinger. Her er en strukturert gjennomgang av fordeler, ulemper og relevante hensyn:
🎯 Hva er en UUID? En UUID (f.eks.550e8400-e29b-41d4-a716-446655440000) er en 128-bit identifikator som er praktisk talt garantert å være unik, selv på tvers av systemer.
✅ Fordeler med UUID i Noark 5 Core 1.Global unikhet
* Sikrer at identifikatorer ikke kolliderer ved systemintegrasjon eller migrering.
* Gjør det mulig å referere til objekter på tvers av systemer og tid (f.eks. mellom organer, eksport/import). 2.Dekobling fra databaseimplementasjon
* UUID-er er uavhengige av interne sekvenser (f.eks. auto-increment id-er).
* Gir større fleksibilitet ved migrasjon, kopiering og distribuert utvikling. 3.Robusthet for asynkron behandling
* Ved f.eks. mottak av metadata eller filer i meldingskøer kan UUID-en genereres på forhånd og brukes som "anker". 4.Forberedt for skylagring og mikrotjenester
* I en mikrotjenestearkitektur eller skybasert løsning der flere komponenter opererer selvstendig, gjør UUID det enkelt å holde orden på entiteter.
⚠️ Ulemper og utfordringer 1.Lite menneskelesbart
* En UUID gir ingen informasjon om innhold, avsender eller rekkefølge.
* Kan gjøre manuell feilsøking og arkivfaglig tilsyn vanskeligere. 2.Større lagrings- og indekseringskostnader
* Sammenlignet med heltall (f.eks. 4 byte), bruker UUID mer plass og kan være tregere å indeksere i enkelte databaser. 3.Bryter med tradisjonelle arkivnøkler
* Tradisjonell arkivstruktur (arkiv, arkivdel, klasse, mappe, journalpost etc.) baserer seg på sekvensielle og hierarkiske nøkler. UUID bryter med dette. 4.Kompatibilitet med arkivplan og bevaringsstrategier
* Arkivfaglige krav fra Arkivverket og Riksarkivet fordrer ofte lesbare identifikatorer for langtidsbevaring og publisering.
🔄 Mulige kompromisser 🔹 Hybridmodell:
* Bruke UUID somintern primærnøkkeli databasen, men ha enmenneskelesbar arkivnøkkelsom sekundær identifikator (f.eks.2025/00023-J).
* UUID er med i REST-API og internt, men arkivnøkkel vises i brukergrensesnitt og eksport. 🔹 Mapping-tabeller:
* Lag separate tabeller som knytter UUID til arkivstruktur, for lettere søk og arkivfaglig behandling.
📚 Relevante referanser
* Noark 5-standardenbeskriver ikke eksplisitt UUID som krav, men åpner for fleksibilitet i implementasjoner.
* Arkivverketer opptatt av langtidsbevaring og lesbarhet, noe som taler for å ikke eksponere UUID direkte til arkivarer eller offentligheten.
🧩 Konklusjon Bruk av UUID som arkividentifikator i Nikita Noark5 Core er fornuftigteknisk sett, men kreverarkivfaglig bevissthet. En god løsning er åskille mellom teknisk identifikator (UUID)ogfaglig arkivnøkkel, og sikre at eksport og langtidslagring bevarer struktur og lesbarhet i tråd med arkivlovgivning.
Valget av filnavn i formatetarkiv-$TALL.xmli lokalarkivkatalogenhttp://www.aamot.io/software/arkiv/arkiv.htmler bevisst gjort for å forene både tekniske og arkivfaglige hensyn i et system som er kompatibelt med Noark 5-prinsipper og åpen informasjonsforvaltning: 📁 Begrunnelse for filnavn:arkiv-$TALL.xml 1.Lesbarhet og enkel gjenfinning Et enkelt tallformat somarkiv-1.xml,arkiv-2.xmlosv., gjør det lett å navigere manuelt i filsystemet. Dette er nyttig for både arkivarer og utviklere som ønsker oversikt eller sammenligne ulike arkivfiler uten å måtte åpne dem. 2.Sekvensielt og deterministisk Ved å bruke et tall i stedet for UUID, følger filnavnene en naturlig, kronologisk rekkefølge. Dette kan være nyttig for:
* Versjonskontroll (f.eks. første uttrekk, andre uttrekk)
* Manuell kvalitetssikring
* Reproduksjon av testdata i forskning eller utvikling 3.Uavhengig av innhold Filnavnet sier ikke noe om metadataene i selve arkivet, men refererer bare til rekkefølgen filene er generert i. Dette gjør det enklere å lage skript som automatisk behandler eller publiserer nye arkivfiler, uten å måtte analysere innholdet først. 4.Unngår kompleksitet og kollisjoner Ved å bruke et løpenummer unngås problemstillinger knyttet til lange UUID-er eller semantiske navnekonflikter. Det gir stabilitet ved overføring mellom systemer som ikke nødvendigvis håndterer lange eller spesialtegn i filnavn på en pålitelig måte (f.eks. eldre systemer, arkivmedia eller e-postvedlegg).
🧩 I kontekst av Noark 5 og åpen kildekode Ettersomhttp://www.aamot.io/software/arkiv/arkiv.htmlinngår i dokumentasjon og eksempeldata for fri programvare og arkivstandarder, er enkel struktur viktig for forståelse, deling og videreutvikling. Navngivningen gjenspeiler også prinsippene i REST-arkitektur og statiske nettarkiv, der adresser er enkle, konsistente og varige.
Mvh, Ole Aamot
On Friday, 2 May 2025 at 01:14:09 +02:00, Ole Aamot ole@aamot.software wrote:
En diskusjon om bruk av UUID (Universally Unique Identifier) som arkividentifikator iNikita Noark5 Coreversjon 0.9kan ta utgangspunkt i både tekniske og arkivfaglige vurderinger. Her er en strukturert gjennomgang av fordeler, ulemper og relevante hensyn:
🎯 Hva er en UUID? En UUID (f.eks.550e8400-e29b-41d4-a716-446655440000) er en 128-bit identifikator som er praktisk talt garantert å være unik, selv på tvers av systemer.
✅ Fordeler med UUID i Noark 5 Core 1.Global unikhet
Sikrer at identifikatorer ikke kolliderer ved systemintegrasjon eller migrering.
Gjør det mulig å referere til objekter på tvers av systemer og tid (f.eks. mellom organer, eksport/import). 2.Dekobling fra databaseimplementasjon
UUID-er er uavhengige av interne sekvenser (f.eks. auto-increment id-er).
Gir større fleksibilitet ved migrasjon, kopiering og distribuert utvikling. 3.Robusthet for asynkron behandling
Ved f.eks. mottak av metadata eller filer i meldingskøer kan UUID-en genereres på forhånd og brukes som "anker". 4.Forberedt for skylagring og mikrotjenester
I en mikrotjenestearkitektur eller skybasert løsning der flere komponenter opererer selvstendig, gjør UUID det enkelt å holde orden på entiteter.
⚠️ Ulemper og utfordringer 1.Lite menneskelesbart
En UUID gir ingen informasjon om innhold, avsender eller rekkefølge.
Kan gjøre manuell feilsøking og arkivfaglig tilsyn vanskeligere. 2.Større lagrings- og indekseringskostnader
Sammenlignet med heltall (f.eks. 4 byte), bruker UUID mer plass og kan være tregere å indeksere i enkelte databaser. 3.Bryter med tradisjonelle arkivnøkler
Tradisjonell arkivstruktur (arkiv, arkivdel, klasse, mappe, journalpost etc.) baserer seg på sekvensielle og hierarkiske nøkler. UUID bryter med dette. 4.Kompatibilitet med arkivplan og bevaringsstrategier
Arkivfaglige krav fra Arkivverket og Riksarkivet fordrer ofte lesbare identifikatorer for langtidsbevaring og publisering.
🔄 Mulige kompromisser 🔹 Hybridmodell:
Bruke UUID somintern primærnøkkeli databasen, men ha enmenneskelesbar arkivnøkkelsom sekundær identifikator (f.eks.2025/00023-J).
UUID er med i REST-API og internt, men arkivnøkkel vises i brukergrensesnitt og eksport. 🔹 Mapping-tabeller:
Lag separate tabeller som knytter UUID til arkivstruktur, for lettere søk og arkivfaglig behandling.
📚 Relevante referanser
Noark 5-standardenbeskriver ikke eksplisitt UUID som krav, men åpner for fleksibilitet i implementasjoner.
Arkivverketer opptatt av langtidsbevaring og lesbarhet, noe som taler for å ikke eksponere UUID direkte til arkivarer eller offentligheten.
🧩 Konklusjon Bruk av UUID som arkividentifikator i Nikita Noark5 Core er fornuftigteknisk sett, men kreverarkivfaglig bevissthet. En god løsning er åskille mellom teknisk identifikator (UUID)ogfaglig arkivnøkkel, og sikre at eksport og langtidslagring bevarer struktur og lesbarhet i tråd med arkivlovgivning.