43 argumentene mot Noark i menon rapporten

[Thomas Sødring]

On 2/21/22 12:37, Thomas Gramstad wrote:
> Det er spesielt to ting jeg reagerer på:
>
> For det første det om "nye teknologier som NOARK ikke passer
> for". Hvilke nye teknologier? Microsoft Teams ble nevnt minst
> én gang. Jeg sitter med følelsen av mer eller mindre skjult
> Microsoft-promotering.

Ja, det oppleves litt sånn. Når det er sagt så mener jeg vi i dag kunne 
importert MS Teams tråder inn i nikita / Noark. Akkurat den kritikken 
viser at det er mange som ikke forstår hva Noark er. Tidligere har jeg 
hatt et arbeid der vi importerte Facebook grupper og SMS. Det var lite i 
veien med Noark for det. Jeg tror litt av misforståelsen rundt Noark er 
at noen ser på det som en absolutt teknisk firkantet standard. Dersom du 
ser på Noark med dette som utgangspunkt vil det absolutt oppleves 
problematisk. Dersom du ser på Noark som et utgangspunkt for god 
arkivering og en slags minimums best-practice tilnærming vil du oppleve 
det som et fantastisk utgangspunkt.

>
> For det andre de voldsomme og gjentatte angrepene på
> bakoverkompatibilitet. Men bakoverkompatibilitet er jo og
> må være en grunnleggende verdi i all arkivering og bevaring.
> Å være anti-bakoverkompatibilitet er å være en fiende av
> arkivering og bevaring.

Bakoverkompatibilitet er vanskelig i denne sfæren. I utgangspunktet vil 
jeg si at bakoverkompatibilitet er et viktig element å få til, men jeg 
er usikker hvor nyttig det er fra Noark 4 til Noark 5. Det er nyttig, 
men utfordringen med Noark 4 standarden var at det var egentlig bare en 
relasjonsdatabasemodell  med litt forklaring om bruk. Å sikre 
bakoverkompatibiliet med dette gjorde at man ikke klarte å løsrive seg 
fra den databasemodellen. Forvaltningens arbeidsmåter og lovverket 
gjorde at funksjonalitet som journalføring ble godt ivaretatt mellom 
standardene og her var det nok veldig lurt å sikre bakoverkompatibiliet. 
Noark 5 indre og ytre lag var en god skille fra Noark 4 (selv med 
kompatibiliteten) mens Noark 5 ytre lag opplevdes mer som Noark 4. Det 
er nok der (Noark 5 komplett) kritikken kan være relevant. Jeg så en 
leverandør presentasjon en gang der leverandør flirte litt da de 
forklarte at overgangen fra Noark 4 til Noark 5 for de var egentlig bare 
å "hacke" inn småtteri her og der men fortsette som før. Samtidig som 
leverandør kritiserte Noark for å være en hemsko for viderearbeid med 
gode bruks opplevelser for arkivering. Her fungerte ikke 
bakoverkompatibilitet særlig godt. Det jeg tror som skjedde da var at 
leverandører kunne tilby kundene sine Noark 5 løsninger uten at kunden 
måtte gjøre noe. De slapp å gå i gang med en kravspec prosjekt. Det tror 
jeg mange forvaltningsorganer hadde "glede" av.

Helt fra jeg begynte med dots og så nikita, var det aldri en tanke å 
utvikle mer enn en Noark kjerne. Det som er på utsiden 
(klientperspektivet) ville alltid måtte forbli en annen prosjekt. Men 
jeg synes det var viktig å få på plass en Noark 5 kjerne. En god 
dokumentasjonsforvaltnings kjerne som fri programvare. Dette kunne 
brukes for å verifisere Noark standarden, kunne fungere som 
referanseimplementasjon, være gjenstand for forskning og brukt i 
undervisning.

>
> For å avslutte med et konstruktivt forslag, hadde det vært mulig
> å invitere denne studenten til Nikita-noark og prøve å få
> konkrete forslag til forbedringer?

Dette er en del av et arbeid der studenten ser på de forskjellige 
strategiene som arkivsektoren jobber med. Vedkommende skal ikke ta 
stilling til forbedringer. Jeg har begynt et prosjekt som heter greqAPI 
som tar utgangspunkt i de svakhetene vi ser i Noark og hvordan Noark kan 
forbedres. Men dette prosjektet tar utgangspunkt i 
dokumentasjonsforvaltning og hva som trengs for privatarkivering (altså 
din dokumentasjon) men også en organisasjon som et AS eller en 
forvaltningsorganisasjon. Vi arver all den gode kompetansen i Noark og 
videreutvikler med andre perspektiver. Det vil være mer fokus på 
metadata, søk, skjerming og tilgangskontroll. Da det er disse tingene 
jeg synes Noark ikke har sett på nok.

Dette arbeidet kan sees litt som feks hvordan https://fomantic-ui.com/ 
er en fork av https://semantic-ui.com/ . Her har folk sett seg lei av 
utviklingen til semantic-ui og laget sin egen community for 
videreutvikling. greqAPI skal være på engelsk, løsrive seg fra Noark og 
fokusere på de tingene jeg nevner over. Utfordringen er at det er et 
veldig *stort* arbeid. Noark på github viser lite engasjement fra 
brukere, men det er også begrenset hvor mye arkivverket legger av tid og 
ressurser på community arbeid. greqAPI vil nok ta steget med å løsrive 
seg fra Noark 4 trådene som henger i Noark 5.

Men det betyr ikke at jeg ikke tror på Noark eller nikita. Noark er en 
fantastisk standard som er misforstått og det er frustrerende å se 
uvitenheten som spres om standarden. For meg er det ikke  "... a hill I 
want to die on". Det er for mye å ta tak i og debatten er 
multidimensjonal   og vanskelig. greqAPI kunne vært et utgangspunkt til 
en senere versjon av Noark dersom det var ønskelig. Men jeg mistenker at 
AS Norge ønsker helt å selge seg til Google og MS. Det er mye enklere 
enn å måtte løse problemer selv ...

  - Thomas