-<p>Spørringen over vil hente en liste av alle dine journalposter der
-tittelen til journalposten inneholder ordet 'nabovarsel'. Alle
-leverandører som implementerer tjenestegrensesnittet vil måtte tilby
-dette. Det betyr at hvis du lærer dette språket for et system, vil det
-være gjeldende for alle. Dette er egentlig en ny måte å søke i
-arkivdatabasen på og vil være svært nyttig, for eksempel kan søk i
-tjenestegrensesnittet antagelig brukes til å hente ut offentlig
-postjournal. I arkivverden pleier vi å like teknologier som er
-menneskelesbart, da vet vi det er enkelt og nyttig! OData er også
-viktig fordi det kan bli en ny måte å svare innsynsforespørsler på i
-tråd med offentlighetsloven § 9, der retten til å kreve innsyn i
-sammenstilling fra databaser er nedfelt. I dag ser vi
-forvaltningsorganer som avviser slike krav fordi det «ikke kan gjøres
-med enkle framgangsmåter». Bruken av OData i tjenestegrensesnittet,
-sammen med maskinlesbar markeringsformater kan være et viktig bidrag
-til å åpne arkivene i tråd med prinsippene om en åpen og transparent
-forvaltning.</p>
-
-<p>Standardisering er viktig fordi det <em>kan</em> sikre samvirke.
-Men den effekten kommer kun hvis standardiseringen sikrer at alle
-forstår standarden på samme måte, dvs. at den er entydig og klar. En
-god måte å sikre en entydig og klar spesifikasjon er ved å kreve at
-det finnes minst to ulike implementasjoner som følger spesifikasjonen
-og som kan snakke sammen, det vil si at de snakker samme språk, slik
-IETF krever for alle sine standarder, før spesifikasjonen anses å være
-ferdig. Tilbakemelding fra miljøet forteller at både leverandører og
-kunder har et avslappet forhold til Noark 5 Tjenestegrensesnitt og det
-er så langt kun Evry som har visst offentlig at de har en
-implementasjon av tjenestegrensesnittet. Evry, HK Data og Fredrikstad
-kommune er igang med et pilotprosjekt på Noark 5
-Tjenestegrensesnitt. For å redusere kostnadene for samvirkende
-datasystemer betraktelig, er det veldig viktig at vi kommer i en
-situasjon der alle leverandører har sine egne implementasjoner av
-tjenestegrensesnittet, og at disse oppfører seg likt og i tråd med det
-som er beskrevet i spesifikasjonen.</p>
-
-<p>Det er her fri programvare spiller en viktig rolle. Med en uklar
-standard blir det som en polsk riksdag, der ingenting fungerer. Nikita
-er en fri programvareimplementasjon av tjenestegrensesnitt og kan
-fungere som teknisk referanse slik at leverandører enklere kan se og
-forstå hvordan standarden skal tolkes. Vi har i Nikitaprosjektet
-erfart å ende opp med vidt forskjellige tolkninger når
-prosjektmedlemmene leser spesifikasjonsteksten, en effekt av en uklar
-spesifikasjon. Men Nikitaprosjektet har også utviklet et test-program
-som sjekker om et tjenestegrensesnitt er i samsvar med standarden, og
-prosjektet bruker det hele tiden for å sikre at endringer og
-forbedringer fungerer. Egenerklæringsskjemaenes dager kan være talte!
-Snart vil du selv kunne teste hver oppdatering av arkivsystemet med en
-uavhengig sjekk.</p>
-
-<p>Fri programvare representerer en demokratisering av kunnskap der
-tolkning- og innlåsingsmakt flyttes fra leverandør til allmenheten.
-Med fri programvare har du en litt annerledes verdikjede, der selve
-produktet ikke holdes hemmelig for å tjene penger, slik en gjør med
-ufri programvare og skytjenester som ikke bruker fri programvare, men
-du kan tjene penger på andre deler av verdikjeden. Med fri programvare
-kan samfunnet betale for å videreutvikle nyttig
-fellesfunksjonalitet.</p>
-
-<p>Nikita er en fri programvareimplementasjon av tjenestegrensesnittet og
-kan fungere som en referanseimplementasjon dersom det er ønskelig.
-Alle har lik tilgang til koden og det koster ingenting å ta den i bruk
-og utforske det. Nikitaprosjektet ønsker tjenestegrensesnittet
-velkommen og stiller veldig gjerne opp i diskusjoner om tolkning av
-tjenestegrensesnittet. Nikita er bygget på moderne
-programmeringsrammeverk og utviklet i full åpenhet. Men Nikita er ikke
-noe du kan kjøpe. Nikita er først og fremst et verktøy for forsking og
-utvikling laget for å fremme forskning på arkivfeltet. Systemer som
-virker sammen har alltid vært hovedfokus og vil være det fremover.
-Det brukes som undervisningsverktøy der studentene ved OsloMet lærer
-om administrativt oppsett, saksbehandling, uttrekk og samvirkende
-datasystemer. Det brukes også som forskningsobjekt der vi ser på
-import av dokumentsamlinger, bruk av blokkjede og andre nyskapende
-måter å tenke arkiv på. Det er dog helt greit om andre tar Nikita og
-pakker det for å selge det som produkt. Forvaltningsorganer med
-sterke drift- og utviklingsmiljøer kan også se på Nikita og utforske
-hva som er mulig. Dette kan de gjøre uten å måtte betale for
-bruksrettigheter eller tilgang til konsulenter. Men arkivering blir
-ikke gratis på grunn av Nikita. Det trengs fortsatt folk med
-kompetanse og tid til å ta i bruk Nikita.</p>
-
-<p>Nikita har nylig kommet med en ny utgave, den sjette i rekken.
-Systemet er ikke ferdig, mest på grunn av at API-spesifikasjonen for
-Noark 5 Tjenestegrensesnitt ikke er ferdig, men allerede i dag kan en
-bruke Nikita som arkiv. Vi har laget eksempelsystem for å importere
-data fra deponi-XML og slik gjøre eksisterende arkivdata tilgjengelig
-via et API. Vi har også laget en testklient som importerer epost inn
-i arkivet med vedlegg der epostenes trådinformasjon brukes til å legge
-eposttråder i samme arkivmappe, og en annen testklient som henter
-epost ut av en arkivmappe på mbox-format slik at en vanlig epostklient
-kan brukes til å lese igjennom og svare på epostene i en
-arkivmappe. De som vil ta en titt på Nikita kan besøke
-<a href="https://nikita.oslomet.no">https://nikita.oslomet.no</a> og
-logge inn med brukernavn «admin@example.com» og passord «password».
-Dette gir tilgang til det forenklede brukergrensesnittet som brukes
-til undervisning. De som heller vil ta en titt under panseret kan
-besøke
-<a href="https://nikita.oslomet.no/browse.html">https://nikita.oslomet.no/browse.html</a>
-og der se hvordan API-et fungerer mer i detalj. Innloggingsdetaljer
-her er det samme som for brukergrensesnittet.</p>
-
-<p>Fremover er fokuset på forbedring av spesifikasjonen Noark 5
-Tjenestegrensesnitt. De som skrev tjenestegrensesnittet gjorde et
-interessant og framtidsrettet grep, de skilte sak fra arkiv.
-Tjenestegrensesnittet består av flere "pakker", der noen er
-grunnleggende mens andre bygger på de grunnleggende pakkene. Pakkene
-som er beskrevet så langt heter «arkivstruktur», «sakarkiv»,
-«administrasjon», «loggogsporing» og «moeter» (dessverre
-<a href="https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/pull/120">planlagt
-fjernet</a> i første utgave). Etter hvert håper vi å utforske
-prosses- og metadatabeskrivelser til flere fagområder og bidra til at
-tjenestegrensesnittet kan legge til flere pakker som «byggarkiv»,
-«barnevern», «personal», «barnehage», der arkivfaglig metadata- og
-dokumentasjonsbehov er kartlagt og standardisert.</p>
-
-<p>Nikita utvikles av en liten prosjektgruppe, og vi er alltid
-interessert å bli flere. Hvis en åpen, fri og standardisert tilnærming
-til arkivering høres interessant ut, bli med oss på veien videre. Vi
-er tilstede på IRC-kanalen #nikita hos FreeNode (tilgjengelig via
-nettleser på
-<a href="https://webchat.freenode.net?channels=#nikita">https://webchat.freenode.net?channels=#nikita</a>),
-og har en e-postliste nikita-noark@nuug.no hos NUUG (tilgjengelig for
-påmelding og arkiv på
-<a href="https://lists.nuug.no/mailman/listinfo/nikita-noark">https://lists.nuug.no/mailman/listinfo/nikita-noark</a>)
-der en kan følge med eller være med oss på den spennende veien videre.
-Spesifikasjonen for Noark 5 Tjenestegrensesnitt vedlikeholdes på
-github,
-<a href="https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/">https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/</a>.</p>
+ <li>Updated to Noark 5 versjon 5.0 API specification.
+ <ul>
+ <li>Changed formatting of _links from [] to {} to match IETF draft
+ on JSON HAL.</li>
+ <li>Merged Registrering og Basisregistrering in version 4 to
+ combined Registrering.</li>
+ <li>DokumentObjekt is now subtype of ArkivEnhet.</li>
+ <li>Introducing new entity Arkivnotat.</li>
+ <li>Changed all relation keys to use /v5/ instead of /v4/.</li>
+ <li>Corrected to use new official relation keys when possible.</li>
+ <li>Renamed Sakspart to Part and connect it to Mappe, Registrering
+ and Dokumentbeskrivelse instead of only Saksmappe.</li>
+ <li>Moved Korrespondansepart connection from Journalpost to
+ Registrering.</li>
+ <li>Moved Part and Korrespondansepart from package sakarkiv to
+ arkivstruktur.</li>
+ <li>Renamed presedensstatus to presedensStatus.</li>
+ <li>Use new JSON content-type "application/vnd.noark5+json".</li>
+ <li>Updated prepopulated format list to use PRONOM codes.</li>
+ <li>Implemented endpoint for system information.</li>
+ <li>Implemented national identifiers for both file and record.</li>
+ <li>Implemented comments.</li>
+ <li>implemented sign off.</li>
+ <li>implemented conversion.</li>
+ </ul></li>
+ <li>Improved/implemented OData search and paging support for more entities.</li>
+ <li>No longer exposes attribute Dokumentobjekt.referanseDokumentfil,
+ one should use the relation in _links instead.</li>
+ <li>Corrected relation keys under
+ https://rel.arkivverket.no/noark5/v5/api/administrasjon/, replacing
+ 'administrasjon' with 'admin'.</li>
+ <li>Fixed several security and stability issues discovered by Coverity.</li>
+ <li>Corrected handling ETag errors, now return code 409.</li>
+ <li>Improved handling of Kryssreferanse.</li>
+ <li>Changed internal database model to use UUID/SystemID as primary keys
+ in tables.</li>
+ <li>Changed internal database table names to use package prefix.</li>
+ <li>Changed time zone handling for date and datetime attributes, to be
+ more according to the new definition in the API specification.</li>
+ <li>Change revoke-token to only drop token on POST requests, not GET.</li>
+ <li>Updated to newer Spring version.</li>
+ <li>Changed primary key and URL component for metadata code lists to
+ use the 'kode' value instead of a SystemID.</li>
+ <li>Corrected implementation of Part and Sakspart.</li>
+ <li>Changed instance lists with subtypes (like .../registrering/ and
+ .../mappe/) to include the attributes and _links entries for the
+ subtype in the supertype lists.</li>
+ <li>Adjusted _links relations to make it possible to figure out the
+ entity of an instance using the self->href->relation key lookup
+ method.</li>
+ <li>Fixed several end points to make sure GET, PUT, POST and DELETE
+ match each other.</li>
+ <li>Updated DELETE endpoints to work with UUID based entity
+ identifiers.</li>
+ <li>Restructured code to use more common URL related constants in entry
+ point values and replace @RequestMapping with method specific
+ annotations.</li>
+ <li>Added first unit test code.</li>
+ <li>Updated web GUI to work with the updated API.</li>
+ <li>Changed integer fields, enforce them as numeric.</li>
+ <li>Rewrote and simplify metadata handling to use common service and
+ controller code instead of duplicating for each type.</li>
+ <li>Implemented the remaining metadata types.</li>
+ <li>Changed Country list source from Wikipedia to Debian iso-codes and
+ updated the list of Countries.</li>
+ <li>Many many corrections and improvements.</li>
projects / homepage.git / blobdiff