<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Hei,<br>
    </p>
    <p>Spennende tanker dere har med Noark 5 og innsyn.&nbsp; I forhold til
      hva dere bør velge tenker jeg at prosjektet må ta stilling til hva
      slags innsynsløsning det skal være.&nbsp; Jeg opplever tre scenarioer.:<br>
    </p>
    <p>1. Arkivverket drifter og utfører innsynsforespørsler<br>
    </p>
    <p>2. Arkivverket drifter, arkivskaper utfører innsyn <br>
    </p>
    <p>3. Arkivverket drifter, innbygger utfører innsyn
    </p>
    <p>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.<br>
    </p>
    <p>(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.<br>
    </p>
    <p>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.<br>
    </p>
    <p>Jeg tror dere skal jobbe med &quot;mye&quot; 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
      &quot;Avslag byggesøknad&quot; vil du kunne filtrere søket med Noark 5
      metadata. Et eksempel:</p>
    <p>mappe?$filter=klasse/klasseID eq 'søknad tilbygg' and
      contains(tittel, 'Oslo') and registrering/tittel ne 'Brev fra
      statsforvalter'&amp;<i><b>$search='</b></i><i><b>Avslag
          byggesøknad</b></i><i><b>'</b></i><br>
    </p>
    <p>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.<br>
    </p>
    <p>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.<br>
    </p>
    <p>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.<br>
    </p>
    <p>&nbsp;- Thomas<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 5/25/21 9:28 AM, Gareth Western
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:74732945-8E93-42EF-BFAF-E12EAAB08DC3@arkivverket.no">
      
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style>
      <div class="WordSection1">
        <p class="MsoNormal"><span lang="NO-BOK">Svarer direkte også<o:p></o:p></span></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <div style="border:none;border-top:solid #B5C4DF
          1.0pt;padding:3.0pt 0cm 0cm 0cm">
          <p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black"><a class="moz-txt-link-rfc2396E" href="mailto:nikita-noark-bounces@nuug.no">&lt;nikita-noark-bounces@nuug.no&gt;</a>
              on behalf of Thomas Sødring <a class="moz-txt-link-rfc2396E" href="mailto:tsodring@oslomet.no">&lt;tsodring@oslomet.no&gt;</a><br>
              <b>Date: </b>Tuesday, 25 May 2021 at 07:25<br>
              <b>To: </b><a class="moz-txt-link-rfc2396E" href="mailto:nikita-noark@nuug.no">&quot;nikita-noark@nuug.no&quot;</a>
              <a class="moz-txt-link-rfc2396E" href="mailto:nikita-noark@nuug.no">&lt;nikita-noark@nuug.no&gt;</a><br>
              <b>Subject: </b>Re: Bruk av Nikita for å tilgjengligjør
              archive data</span><span style="font-size:12.0pt;color:black;mso-fareast-language:EN-GB"><o:p></o:p></span></p>
        </div>
        <div>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        </div>
        <p style="margin-left:36.0pt">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.
          <o:p></o:p></p>
        <p style="margin-left:36.0pt">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.<o:p></o:p></p>
        <p class="MsoNormal"><span style="mso-fareast-language:EN-GB">Et
            problem for øyeblikket er at jeg ikke vet hvor mye data
          </span><span style="mso-fareast-language:EN-GB" lang="NO-BOK">vi
            skal</span><span style="mso-fareast-language:EN-GB"> jobbe
            med. I utgangspunktet er det bare et enkelt arkiv fra en
            enkelt organisasjon</span><span style="mso-fareast-language:EN-GB" lang="NO-BOK"> (men jeg
            har ikke mottatt det enda). D</span><span style="mso-fareast-language:EN-GB">et vil være flere arkiver
            i fremtiden, sannsynligvis fra flere organisasjoner, og også
            sannsynligvis fra flere
          </span><span style="mso-fareast-language:EN-GB" lang="NO-BOK">forskjellige
          </span>
          <span style="mso-fareast-language:EN-GB">forretningsdomener.</span><span style="mso-fareast-language:EN-GB" lang="NO-BOK"><o:p></o:p></span></p>
        <p class="MsoNormal"><span style="mso-fareast-language:EN-GB" lang="NO-BOK"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="mso-fareast-language:EN-GB" lang="NO-BOK">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. </span><span style="font-family:&quot;Apple Color
            Emoji&quot;;mso-fareast-language:EN-GB" lang="NO-BOK">😊</span><span style="mso-fareast-language:EN-GB" lang="NO-BOK">
            <o:p></o:p></span></p>
      </div>
    </blockquote>
  </body>
</html>