Re: Bruk av Nikita for å tilgjengligjør archive data

[Thomas Sødring]

Hei,

Spennende tanker dere har med Noark 5 og innsyn.  I forhold til hva dere 
bør velge tenker jeg at prosjektet må ta stilling til hva slags 
innsynsløsning det skal være.  Jeg opplever tre scenarioer.:

1. Arkivverket drifter og utfører innsynsforespørsler

2. Arkivverket drifter, arkivskaper utfører innsyn

3. Arkivverket drifter, innbygger utfører innsyn

Jeg opplever at (1) er det arkivmiljøet jobber med i dag, men det er 
ønskelig å få på plass (2). Mange ønsker seg også (3) men da må man 
virkelig ha kontroll på dataene sine.

(C) vil nok fungere bra for (1) da det er den desidert enkleste å 
implementere og kan nok gjøres ut ifra et skript som parser gjennom 
arkivstruktur.xml. Så kommer en arkivskaper og efterspør noe. Hva er en 
DIP i (C)? Jeg vet at noen har holdningen at en DIP er hele uttrekket 
som ble avlevert, men en DIP burde kanskje være mer på saksnivå. Den 
type nivå kan man enkelt få til med tjenestegrensesnittet.

Dersom dere har en innsynsløsing på plass vil forventingene fort bli at 
arkivskaper selv ønsker å søke i avlevert materiale og minimere bruken 
av ressurser hos Arkivverket. Da trenger dere noe som ligner mer på (A) 
eller (B). Jeg hadde også ikke vært opptatt av nikita i denne fasen og 
heller fokusert på APIet. Hvordan skal APIet se ut? Kan prosjektet oppnå 
sine mål med Noark 5 tjenestegrensesnittet? Valget av API til løsningen 
er noe dere må leve med lenge og det å velge noe som er standardisert 
kan gjøre klient utvikling billigere på sikt. nikita er en 
implementasjon av Noark 5 tjenestegrensesnittet og er nyttig i den 
sammenhengen da du enkelt og raskt kan jobbe med klientperspektivet i 
prosjektet deres og lage gode løsninger for brukere.

Jeg tror dere skal jobbe med "mye" data så skalerbarhet vil være viktig. 
Nikita prosjektet har ikke kommunisert dette ut så mye men en av de 
siste større innsatsene mot nikita versjon 1.0 er fulltekstindeksering 
av dokumenter. Da vil vi ta i bruk ES eller lignende (det har visst vært 
noe styr med ES og Amazon som jeg må få kontroll på) og indeksere både 
dokumenter og Noark 5 metadata. En av use-casene vi har på søk er å 
tillate kombinasjonen av metadata og innholdssøk i dokumenter via 
tjenestegrensesnittet. Så feks dersom du ønsker å søke i dokumenter som 
inneholder begrepet "Avslag byggesøknad" vil du kunne filtrere søket med 
Noark 5 metadata. Et eksempel:

mappe?$filter=klasse/klasseID eq 'søknad tilbygg' and contains(tittel, 
'Oslo') and registrering/tittel ne 'Brev fra 
statsforvalter'&/*$search='*//*Avslag byggesøknad*//*'*/

Her kan du få til ganske avanserte søk gjennom uttrekkene. I 
utgangspunktet vil søkene også være avgrenset til organisasjon dersom 
det er implementert riktig. Jeg tror dette kan være vel så viktig som 
ren ES søk. Når man bruker ES søk så er man nødt til å vurdere relevans. 
Hva er relevans for en ES indeks av arkivstruktur.xml innhold? Det å ha 
søk er nyttig, men hvor nyttig er det når trefflisterekkefølge ikke har 
en tydelig relevans? Jeg tror at depot er avhengig av mer enn en ES instans.

Så kanskje et forslag til dere er hvordan dere kan løfte 
søkeperspektivet. Hva slags søk forventer dere / hva trenger dere? 
Dersom eksempelet over er relevant så er det noe dere kan få til via 
Noark 5 tjenestegrensesnitt. Det mangler en beskrivelse men dersom dere 
kan komme med en case så er det noe det bør være mulig å få til i 
tjenestegrensesnittet. Vi hjelper gjerne der.

En siste kommentar på bilde er at dersom det ikke er et særskilt behov 
for å skille data i forskjellige databaser, hadde jeg tatt alt inn i en 
database. nikita er en spring-boot app, så jeg tror det er mulig å få en 
instans til å jobbe opp mot flere databaser, men jeg synes det blir en 
kompliserende faktor i arkitekturen. Jeg mistenker at kanskje det er en 
behov for å skille databaser på Noark versjoner (5.0, 5.1, 5.2, 5.3) 
framfor på organisasjoner, men jeg ser at det kan være mange grunner at 
dere har et behov om å skille organisasjoner. Jeg tenker ofte en 
nikita-instans = en database, men mange organisasjoner kan være i den 
databasen.

  - Thomas


On 5/25/21 9:28 AM, Gareth Western wrote:
>
> Svarer direkte også
>
> *From: *<nikita-noark-bounces at nuug.no> on behalf of Thomas Sødring 
> <tsodring at oslomet.no>
> *Date: *Tuesday, 25 May 2021 at 07:25
> *To: *"nikita-noark at nuug.no" <nikita-noark at nuug.no>
> *Subject: *Re: Bruk av Nikita for å tilgjengligjør archive data
>
> Jeg mener du skal kunne gjøre det. På OsloMet så bruker jeg nikita på 
> en måte at hver student blir en organisasjon i nikita. og tilgang, søk 
> osv er adskilt. Du reiser et interessant spørsmål i forhold til 
> hvordan vi bør håndtere administrasjon av brukere og jeg er 
> interessert å se at nikita har bruksverdi i depot. En IKA har også 
> lekt litt med samme tanke som du har. Uansett gir det ingen mening å 
> ha en nikita instans per arkiv.
>
> Det som kan være interessant er å kunne tilby innsyn tilbake til 
> organisasjonen og da må vi løfte organisasjon litt mer i koden. Men 
> det er ikke noe stort arbeid.
>
> Et problem for øyeblikket er at jeg ikke vet hvor mye data vi 
> skaljobbe med. I utgangspunktet er det bare et enkelt arkiv fra en 
> enkelt organisasjon(men jeg har ikke mottatt det enda). Det vil være 
> flere arkiver i fremtiden, sannsynligvis fra flere organisasjoner, og 
> også sannsynligvis fra flere forskjellige forretningsdomener.
>
> Vedlagt er et bilde av noen få varianter for en grunnleggende 
> arkitektur jeg vurderer. Jeg tror enten B eller C er mest realistiske. 
> Men det vil også avhenge av hva brukerne faktisk ønsker å få fra 
> arkivene. Jeg har ikke hørt noe om det ennå heller. 😊
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.nuug.no/pipermail/nikita-noark/attachments/20210525/f403a8ed/attachment.htm