Open sturtzel opened 4 years ago
Det finnes i standarden begrepet arkivenhet, som "skal kunne identifiseres entydig innenfor det arkivskapende organet". Til den grad at om den dupliseres, skal det være ny id. Hvis man implementerte en abstrakt arkivenhet i datamodellen, ville man laget en kompleks type som kun inneholdt systemID. Eksempelvis
<xs:complexType name="arkivenhet">
<xs:sequence>
<xs:element name="systemID" type="n5mdk:systemID"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="registrering">
<xs:complexContent>
<xs:extension base="arkivenhet">
<xs:sequence>
<xs:element name="opprettetDato" type="n5mdk:opprettetDato"/>
<xs:element name="opprettetAv" type="n5mdk:opprettetAv"/>
<xs:element name="arkivertDato" type="n5mdk:arkivertDato"/>
<xs:element name="arkivertAv" type="n5mdk:arkivertAv"/>
...
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="journalpost">
<xs:complexContent>
<xs:extension base="registrering">
<xs:sequence>
<xs:element name="journalaar" type="n5mdk:journalaar"/>
...
Så kan man også vurdere om det eksisterer andre generelle egenskaper man kan knytte til alle arkivenheter, som opprettetDato, kassasjon eller virksomhetsspesifikkeMetadata.
Idag lages det nye id-er basert på hvilke forelder-objekter en arkivenhet er tilknyttet, eller hvilken rekkefølge den står i. Hva ville være enkleste måten å gjenkjenne identiske enheter? Hashing av en egenskaper og verdier til egenskaper?
Jeg har fundert en del over forslaget til Jørgen. På en måte er Noark5 strukturert slik. Men jeg ser ikke at forslaget løser problemstillingen med at objekter som brukes flere steder i strukturen (det kan være klasser, det kan være dokumenter fra tidligere saker, f.eks. et presedensvedtak, som legges ved en ny sak til info). I dag forlanger Noark (Arkade 5) at disse dupliseres bl.a. slik at det fremstår som at klassifikasjonen i periode 1 er en helt annen enn klassifikasjonen i periode 2.
Problemet her er at unikheten til det dokumentet ikke bare belager seg på systemID, men faktiske plasseringen. Selv når dokumentet ikke har noe rekkefølgenummer, skal det være nok at den tilhører en bestemt journalpost som vedlegg nummer 2 [logisk plassert].
Hva med en løsning lignende det som er diskutert for klassifikasjonssystem, hvor den settes på et overordnet nivå [arkiv]. Men man ville også delt opp struktur i struktur og dokument (Digresjon: Begynner å ligne på Noark-3).
Av nødvendighet ville det blitt en ny gruppe elementer som koblet disse sammen, noe lignende %Klasse og %Dokumentbeskrivelse. Men siden referanseTilKlasse brukes til kryssreferanser, kan referanse% være et dårlig valg.
Dokumentbeskrivelsene må ligge i registreringene siden de hører hjemme der. Men dokumentobjektet kan (bør kunne) forefinnes i flere registreringer fordi man ønsker å legge de ved i en ny forsendelse og ikke kun referere de (som hadde vært nok for interne formål).
Det er dokumentbeskrivelse som er koblet til flere registreringer flere ganger, et dokumentobjekt kan bare være koblet til en dokumentbeskrivelse. Snublet der selv. Ville ha det delt opp i "tagger", "struktur" og "filer". Men utfordringen rundt klassifikasjonssystem var mange-til-mange forholdet, og gjenbruk av samme arkivenhet flere steder. Det samme gjelder for dokumentbeskrivelse.
Man ville beholdt koblingen, men gjort den til referanse i stedet for selve objektet:
I vanlig bruk ønskes det neppe kobling. Dokumentet skal vises på korrekt plass i oversikter inkl. i eInnsyn. Med referanse blir det fort feil.
Noark systemid må kunne bruke som en unik system identifikator for objekter i arkivstrukturen. En systemid skal ikke dupliseres - dette er en selvmotsigelse.
Arkivverkets begrunnelse for å tildele et objekt nye id'er ved duplisering har vært at en avleveringpakke skal ha en hierarkisk struktur som etterligner strukturen i et papirarkiv hvor saksmapper var ordnet etter arkivnøkkelen. Etter min mening bør varsel klokkene begynne å kime på dette stadiet.
I Noark-5 versjon 3.1 står det følgende "Dokumentobjektet har ingen systemID. Et dokumentobjekt vil bli duplisert dersom samme dokumentfil er knyttet til flere forskjellige registreringer, og en systemidentifikasjon for dokumentobjektet ville da ikke lenger være unikt i uttrekket".
I Noark 5 versjon 4 er dette endret til "Dokumentobjektet har ingen systemID. Et dokumentobjekt vil bli duplisert dersom samme dokumentfil er knyttet til flere forskjellige registreringer, og en systemidentifikasjon for dokumentobjektet ville da ikke lenger være unikt i uttrekket."
I Noark 5 versjon 5 er blir det endret til : "Ved deponering/avlevering skal imidlertid metadata både for dokumentbeskrivelse og dokumentobjekt dupliseres for hver gang det samme dokumentet er knyttet til forskjellige registreringer. I tillegg skal dokumentobjektet ha informasjon om når dokumentet ble knyttet til registreringen, hvilken "rolle" dokumentet har i forhold til registreringen (hoveddokument eller vedlegg), rekkefølgenummer osv. Dette vil være unik informasjon for hver tilknytning (i Noark-4 ble attributtene for dette beskrevet i en tabell kalt Dokumentlink). Hver dokumentbeskrivelse skal derfor ha en unik systemID."
Dette er en grunnleggende feilslutning som ikke er i samsvar med krav 2.7.8 Noark 5 versjon 5 "Ved tilknytning av et dokument til en registrering, skal det kunne angis om det er et hoveddokument eller et vedlegg (tilknyttetRegistreringSom)". Med andre ord: Det er en Dokumentbeskrivelse inkludert tilhørende dokumentobjekter som kan ha relasjon til flere registreringer.
For å rette opp i dette forholdet må vi se på arkivverkets reelle begrunnelsen for å IKKE tildele objekter en -1- unik systemid: Jeg vil derfor foreslå at vi ser på strukturen i avleveringen. Kan en like godt avlevere objekt for objekt med angivelse av relasjoner?
Vi ønsker at dere tar bort teksten i felt / kursiv. Dette for at det er mulig å se at hvilke relasjoner en -1- arkivenhet har til andre arkivenheter i arkivstrukturen. Det gjelder ikke minst i forhold til endringsloggen som skal inneholde referanse til en arkivenhet med en gitt system id.
NOARK 5 Krav 2.2.1 En arkivenhet skal kunne identifiseres entydig innenfor det arkivskapende organet. I et arkivuttrekk skal denne identifikasjonen hete systemID, og være entydig på tvers av alle uttrekk som organet produserer, dermed også på tvers av alle systemer organet benytter. Også arkivenheter som dupliseres i et arkivuttrekk, skal identifiseres entydig, slik at identiske arkivenheter har ulik systemID.
Kravet / hensikten med entydige systemID-er må være å entydig kunne identifisere objekter på tvers av alle avleveringer. Da må samme objekt avlevert i flere uttrekk være det samme.
Hvis Klassifikasjonssystem og Klasse skal være noe annet enn Mappe (i så tilfelle er det et unødvendig element da mappe i mappe støttes), bør klassifikasjonssystem som K-kode og klasser som K-kodene ha identisk systemID på tvers av alle brukere av disse kodene. I det minste må det aksepteres at de har samme systemID innenfor et arkiv. En sak får ikke ny klassifikasjon ved at den flyttes automatisk til arvtagende arkivdel i en overlappingsperiode. Arkivdeler med samme klassifikasjon har ikke hver sine unike klasser.
Tilsvarende gjelder for Dokumentbeskrivelse og Dokumentobjekt. Hvis et dokument som er produsert i sak A legges ved som vedlegg til en journalpost i sak B er det historisk korrekt at dette ivaretas ved at dette blir en referanse og at systemID fra sak A beholdes. Hvis ikke kan det stilles spørsmål ved om dette faktisk er det dokumentet det gir seg ut for og ikke er et nytt dokument produsert for å gi seg ut for det opprinnelige.
Et objekt må derfor beholde sin systemID selv om det inngår i flere arkivdeler, journalposter etc.