Legg til M016 eksterntSystemNavn og M016 eksterntSystemNoekkel i arkivdel, mappe og registrering i 120-vedlegg_2_metadatakatalog_objektsortert.rst

[hanber]

No description provided.

[petterreinholdtsen]

[Hans Fredrik Berg]

@hanber requested your review on: arkivverket/noark5-standard#133 Legg til M016 eksterntSystemNavn og M016 eksterntSystemNoekkel i arkivdel, mappe og registrering i 120-vedlegg_2_metadatakatalog_objektsortert.rst.

Hvis jeg forstår forslaget riktig, så er tanken at XML-en blir noe ala dette: <mappe> ... <eksterntSystemNavn>Særløsning</eksterntSystemNavn> <eksterntSystemNoekkel>12345</eksterntSystemNoekkel> ... </mappe> Har du vurdert å gruppere det som en ny sekundærentitet med multiplisitet 0-M, ala dette <mappe> ... <eksterntSystem> <eksterntSystemNavn>Særløsning 1</eksterntSystemNavn> <eksterntSystemNoekkel>12345</eksterntSystemNoekkel> </eksterntSystem> <eksterntSystem> <eksterntSystemNavn>Særløsning 2</eksterntSystemNavn> <eksterntSystemNoekkel>54321</eksterntSystemNoekkel> </eksterntSystem> ... </mappe> Det vil åpne for å flere eksterne systemer å kunne legge inn nøkkel hvis en mappe deles mellom flere ekstene systemer.

…

-- Vennlig hilsen Petter Reinholdtsen

[hanber]

Det er riktig. Jeg har ikke vurdert det. Geointegrasjon har 0..1. @sturtzel, har du noen synspunkter på det?

[sturtzel]

Bruken i både N4WS og GI (samt i Fiks Arkiv) er 0..1. Behovet er for entydig identifisering fra fagsystemets side basert på nøkkel i fagsystemet.

Jeg kan ikke erindre at det noen gang har vært nevnt behov om 0..n. Men det er neppe noe problem sett fra fagsystemets side om det åpnes for flere referanser. Ulempen er da at sekundære referanser fort blir tilleggsinformasjon som ikke er entydig, noe som kan gi feilsituasjoner der arkivkjernen validerer nøklene for å sikre at de er entydige. De skal jo brukes for oppslag.

Så jeg foreslår 0..1.

[petterreinholdtsen]

[Ragnar Sturtzel]

Bruken i både N4WS og GI (samt i Fiks Arkiv) er 0..1. Behovet er for entydig identifisering fra fagsystemets side basert på nøkkel i fagsystemet.

Hvert enkelt fagsystem vil nok kun trenge 0-1. Behovet for 0-M oppstår jo hvis det er flere fagsystemer som ønsker å legge inn egen nøkkel til samme arkivenhet.

Jeg kan ikke erindre at det noen gang har vært nevnt behov om 0..n. Men det er neppe noe problem sett fra fagsystemets side om det åpnes for flere referanser. Ulempen er da at sekundære referanser fort blir tilleggsinformasjon som ikke er entydig, noe som kan gi feilsituasjoner der arkivkjernen validerer nøklene for å sikre at de er entydige. De skal jo brukes for oppslag.

Hvordan ser du for deg at denne feilsituasjonen skal oppstå? Jeg mistenker det kan løses ved å spesifisere at hver eksterntSystemNavn kun kan registrere et eksterntSystemNoekkel, slik at dette ikke er tillatt: <mappe> ... <eksterntSystem> <eksterntSystemNavn>Fagsystem 1</eksterntSystemNavn> <eksterntSystemNoekkel>12345</eksterntSystemNoekkel> </eksterntSystem> <eksterntSystem> <eksterntSystemNavn>Fagsystem 1</eksterntSystemNavn> <eksterntSystemNoekkel>54321</eksterntSystemNoekkel> </eksterntSystem> ... </mappe> Jeg tror det uansett vil være et hensiktsmessig krav for å enkelt og effektivt kunne finne nøkkelen som hører til et gitt fagsystem.

Så jeg foreslår 0..1.

Ulempen med dette er at det kun vil tillate kobling til et fagsystem per arkivenhet.

…

-- Vennlig hilsen Petter Reinholdtsen

[sturtzel]

Kravet til entydighet er at kombinasjonen av fagsystem og nøkkel kun kan eksistere for én arkivenhet. Så problemet er ikke 2x fagsystem 1, men at et fagsystem som legger ut flere nøkler kan ha en av de som en sekundærnøkkel som brukes mot flere enheter. Nøkkelen er til for at fagsystemet skal kunne hente frem igjen et objekt basert på nøkkelen, f.eks. en bestemt klientmappe, bestemt byggesak.

Ellers er jeg åpen for 0..m.

[hanber]

Sett fra depotets side, i de tilfellene det avleveres et Noark 5-uttrekk i tillegg til et uttrekk fra fagsystemet, er det like viktig at arkivenheten i Noark-uttrekket refererer til ett og bare ett objekt i fagsystemuttrekket.

[sturtzel]

All bruk via N4WS og GI har vært 1:1 der fagsystemet har arkivert noe og samtidig satt en fagnøkkel fagsystemet kunne bruke for å hente ut igjen samme sak eller journalpost (mappe eller registrering).

[petterreinholdtsen]

[Ragnar Sturtzel]

Kravet til entydighet er at kombinasjonen av fagsystem og nøkkel kun kan eksistere for én arkivenhet. Så problemet er ikke 2x fagsystem 1, men at et fagsystem som legger ut flere nøkler kan ha en av de som en sekundærnøkkel som brukes mot flere enheter. Nøkkelen er til for at fagsystemet skal kunne hente frem igjen et objekt basert på nøkkelen, f.eks. en bestemt klientmappe, bestemt byggesak.

Jeg mistenker jeg falt av her. Har du et XML-eksempel for demonstrerer problemet?

…

-- Vennlig hilsen Petter Reinholdtsen

[sturtzel]

Nei, dette kan ikke vises via en XML.

På samme måte som en klient kan hente opp et arkivobjekt gitt systemID skal en klient kunne hente opp et arkivobjekt gitt fagnøkkel (eksterntsystemNavn+eksterntSystemNoekkel). Vi snakker her om retrieve og ikke om søk.

Kombinasjonen må derfor være unik i arkivet. Dette er ikke referanser, men unik nøkkel.

[petterreinholdtsen]

Slik jeg forstår deg kan problemet uttrykkes med en datastruktur, så for å forsøke å finne ut hvor jeg har misforstått gjør jeg et forsøk på dette. Du ønsker slik jeg forstår det å unngå at en endre opp med en datastrukturskisse som ser slik ut: ... <mappe> ... <eksterntSystem> <eksterntSystemNavn>Fagsystem 1</eksterntSystemNavn> <eksterntSystemNoekkel>12345</eksterntSystemNoekkel> </eksterntSystem> ... </mappe> <mappe> <registrering> ... <eksterntSystem> <eksterntSystemNavn>Fagsystem 1</eksterntSystemNavn> <eksterntSystemNoekkel>12345</eksterntSystemNoekkel> </eksterntSystem> ... </registrering> ... </mappe> ... Her vil en, hvis en søker etter eksterntSystemNavn="Fagsystem 1" og eksterntSystemNoekkel="12345" så vil en her få treff på både en mappe og en registrering, hvilket kan være vanskelig hvis fagsystem 1 forventer å kun få ett treff. Slik jeg har beskrevet det over vil jo problemet oppstå både med multiplisitet 0-1 og 0-M, men kan vel løses ved å kreve at tuplen eksterntSystemNavn,eksterntSystemNoekkel er unik i hele arkivet, slik du nevnte. Hva har jeg misforstått?

…

-- Vennlig hilsen Petter Reinholdtsen

[sturtzel]

Her er det mappe og registrering med samme nøkkel. Det vil nok forekomme også i dag ved at fagsystemet bruker internt løpenummer som nøkkel. Hvis du tar vekk og lar eksternnøkkelen ligge direkte i begge mapper vil det ikke lenger være mulig å gjøre "retrieve mappe given nøkkel".

Ved 0:m er det et spørsmål hva et fagsystem vil bruke 2, 3, ... m til. To unike ID-er for samme objekt er uvanlig. Da blir det fort "sekundærklassering", hvilket vil bryte med forutsetningene om unike nøkler. Derfor trengs kun 0..1.

Sekundærklasseringer bør tas via referanser, eller om klasse flyttes inn i mappe, via klassifikasjon.