1. No category

Noark 5 kjerne
Status og planer
Thomas Sødring
[email protected]
P-R428
22452610
1
Noark5
Noark 5 kjerne
Tjeneste/Grensesnitt laget
(service layer)
Virksomhetslogikk laget
(Business Logic Layer)
Lagrings laget
WSDL
Noark kjernen implementert
med business logic og object
relational mapping
(Persistence Layer ORM)
Relasjonsdatabase
2
n5c status
●
●
Vi har en kodebase fra Dublin som
implementerer en Noark 5 indre kjerne
●
Den har ingen brukergrensesnitt
●
Har hatt noen implementasjons problemer
Er i en prosess der vi bygger bruker grensesnitt
samtidig som vi sjekker logikken
●
●
●
Uavhengig testing (Unit tests)
Kan demonstrere kjerne med følgende
arkivstruktur
●
Arkiv, arkivdel, mappe og registrering
●
http://ark1.hio.no:9090/n5c
Vi vil snart ta igjen friark på funksjonalitet
3
Utvikling og Distribusjon
●
Plattform uavhengig for utvikling
●
●
●
Eclipse, jboss, mysql, java, graniteDS, flex
kompilator* finnes alle på win/lin/mac
Brukergrensesnittet er avhengig av adobe flash :o(
Kjernen kan kompileres og distribueres som en
jar (kun kjerne) eller ear (applikasjon)
●
JAR (Java ARchive)
●
WAR (Web ARchive)
●
EAR (Enterprise ARchive)
4
Noark5 kjerne
AdobeFlex
Brukergrensesnitt
Noark 5 kjerne
GraniteDS (AMF)
Tjeneste/Grensesnitt laget
(service layer)
Virksomhetslogikk laget
(Business Logic Layer)
Lagrings laget
WSDL/RemoteObjects
Noark kjernen implementert
med business logic og object
relational mapping
(Persistence Layer ORM)
Relasjonsdatabase
5
Demo
●
●
●
●
JBOSS AS
●
Tom database
●
Databasestruktur blir opprettet
Eclipse
●
Noark5CoreService.java
●
Noark5CoreServiceBean.java
●
Arkiv.java
●
ArkivSeeker.java
Flex
●
GraniteDS som lager actionsript filer
●
NoarkCoreApplication.mxml
Hvordan bygge og deploye prosjektet
6
Kommunikasjon
●
Brukergrensesnitt til kjerne kommunikasjon
●
Webservices/SOAP
–
–
●
SOAPUI
Mange muligheter
RemoteObject
–
–
En Flex/Actionscript optimalisering
Data utveksling i en binær standard som heter AMF
(Action Message Format)
●
–
–
Mye mer effektiv enn XML
Slipper marshalling (koding / dekoding) av objekter som
XML
Type mapping skjer uten problemer
●
java.util.Date til actionscript Date?
7
Hvorfor denne arkitekturen
●
Utviklingsperspektiv som kommer fra midten
●
Positive
–
–
–
●
Lettere å videreutvikle og jobbe med
Kostnadene kraftig redusert for videreutvikling
Gjenbruk som kommunal felleskomponent
Negative
–
–
Databasen er ikke optimalisert
Er det riktig teknologi?
●
●
.net/silverlight, ruby on rails, groovy on grail
Kjernen er en 'ren' kjerne
●
Autentisering / Autorisering er ikke direkte i kjerne men
håndteres av JAAS (Java Authentication Authorization Service)
–
–
●
@SecurityDomain("noark5_policy")
@RolesAllowed({"admin"})
Ikke implementert enda
8
Skalerbarhet
●
Skalerbarhet er viktig.
●
●
JBOSS kan konfigureres for å kjøre i en cluster
●
●
Per i dag vet vi ikke hvor mange som kan bruke
kjernen samtidig
Men det kan være en flaskehals i lagringslaget
(Object Relational Mapping)
Vi har lab på HiO, så vi kan lett teste opp mot
hundre brukere samtidig for å se hvordan
kjernen skaleres
9
Lisens kompatibilitet
Liten / Ingen Beskyttelse
Svak Beskyttelse
Sterk Beskyttelse
Offentlig
domene
LGPLv2.1
GPLv2
MIT/X11
LGPLv2.1+
GPLv2+
BSD (ny)
LGPLv3/v3+
GPLv3/v3+
Apache 2.0
MPL 1.1
Nettverk Beskyttelse
AGPLv3
Kjernen skal være LGPL, alt annet skal
være BSD.
Fra/til. Programvare som kombinerer kode fra
2 lisenser må leve med at programmet har til
lisensen
Utviklet fra http://www.dwheeler.com/essays/floss-license-slide.html
10
Framover
●
●
Indre kjerne med brukergrensesnitt ferdig mot
slutten av juni
Ytre kjerne utover høsten
●
Pappaperm og andre hensyn
11
Spørsmål til KAI miljøet
●
●
Hva slags interesse har dere for en slik kjerne?
Har dere kompetanse til å drifte/videreutvikle
den?
●
●
●
JAVA, System Administrator
Urealistisk å tro at vi vil utvikle en fullverdig
saksbehandlingsløsning
●
Men vi skal prøve!
●
Student prosjekt
Nærmer seg slutten av det som kan gjøres
innenfor en FoU ramme
12
Pågående prosjekter
●
Integrasjon med Facebook
●
●
●
●
Windows basert applikasjon
Integrasjon med Android mobil
Integrasjon med Fedora Commons for sikker
overføring fra Noark kjerne til depot
1. juni starter 1 student 3 måneders masters
prosjekt for å utvikle en datakvalitet plugin for
kjernen
●
Ønsker at den skal være implementasjon
uavhengig (med tanke på friark)
13
Neste runde med prosjekter
●
●
●
●
Innsynforespørselløsning for KAI miljøet
●
Foreslått av IKA Kongsberg og Trøndelag
●
Ikke mye som skal til
Kjernen i nettskyen
●
Arkivloven §12.b står for fall!!!
●
Kanskje få leverandørene til å åpne øynene
Konvertering fra produksjon format til
arkivformat med garantier
Slutt på at noen leverandører prøver å selge
one-size-fits-all løsninger
14
Undervisningsverktøy
●
Uansett om kjernen brukes eksternt eller ikke
så vil det være en undervisningsressurs
●
På alt fra
–
–
–
●
●
Årsstudium
Bachelors
Masters
Ønsker å se nærmere om Noark Arkivråd har bruk
for den
Kompetanseheving med tanke på
Riksrevisjonensrapport
15
Forskningsverktøy
●
Snart kan vi vise hvordan:
●
●
●
Integrere kjernen mot utradisjonelle arkivdannings
kilder
Sikker overføring fra kjernen til depot (begrenset i
størrelse)
Men vi ønsker å bruke kjernen til å se nærmere
på:
●
Semantikk
●
Datakvalitet
●
Infrastruktur
●
InterPares4
16
NFR søknad
●
Jobber med en søknad for en forskerprosjekt
●
●
3-4 Ph.D stillinger med prosjekter som bygger på
kjernen
Må ha utviklingskompetanse
17
Semantikk og arkivdanning
kilde1
kilde3
arkiv
sak1
arkivdel
sak
mappe
JP1
sak2
er part i
kilde2
Hans
hansen
JP2
arkivstruktur
innhold
saksgang
18
Trenger vi semantikk i arkiv?
●
Er arkivdanning styrt etter depotets behov?
●
NOARK kjerne, hva er det egentlig?
●
God arkivdanning
●
Dokumentasjon på forvaltningens vedtak
●
Informasjon som skal avleveres til depot
<arkiv>
<arkivdel>
<saksmappe>
<journalpost>
</journalpost>
</saksmappe>
</arkivdel>
</arkiv>
●
Er dette et systemsentrisk syn?
●
Hva ellers skulle det være?
19
Trenger vi semantikk i arkiv?
●
"Når vi bruker semantisk teknologi så
abstraherer vi oss vekk fra syntaks og opp mot
budskapet innholdet representerer"
●
●
Arkivstrukturen som er realisert utifra
Metadatakatalogen er en type abstraksjon av
arkivdanningen som har skjedd ved en viss
tidspunkt
I dette tilfellet er semantikk et langtidslagrings
spørsmål
20
Trenger vi semantikk i arkiv?
●
Semantikk kan brukes i 3 forskjellig områder
●
Arkivdanning
●
●
Arkivstruktur
●
Innhold
●
Saksgang
Depot
●
Depot kan arve semantikken fra semantiskbevist
arkivdanningsystemer
–
●
hvis det fantes
Depot kan prosessere avlevert materiale slik at det
blir semantisk
21
Semantikk og Arkivstruktur
arkiv
(KommuneA)
har
arkivdel
(barnehagesøknad)
har
mappe
har
(søknad om plass)
journalpost
(1)
ha
r
journalpost
(2)
<arkiv beskrivelse="KommuneA">
<arkivdel beskrivelse="barnehagesøknad">
<saksmappe tittel="søknad om plass">
<journalpost> 1 </journalpost>
<journalpost> 2 </journalpost>
</saksmappe>
</arkivdel>
</arkiv>
22
Semantikk og Arkivstruktur
●
Hva får vi fra dette?
●
Ikke så mye som vi ikke har før
●
Det åpner opp for bruken av semantiske verktøy
●
Det kan danne grunnlaget for bruken av statistikk
informasjon om organet
–
–
–
●
Hvor mange saker de behandler
Hvor lang tid de bruker til å behandle søknader
Hvilken type søknader de behandler
For depot vil dette være langt mer nyttig enn
ved danning
●
Dette er noe som kan automatiseres
23
<rdf:RDF
xmlns:n5="http://www.arkivlab.no/n5"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
<n5:arkiv rdf:nodeID="arkiv_1">
<n5:systemID>1</n5:systemID>
<n5:beskrivelse>Oslo Kommune</n5:beskrivelse>
<n5:erRelatert rdf:nodeID="arkivdel_1"/>
</n5:arkiv>
<n5:arkivdel rdf:nodeID="arkivdel_1">
<n5:systemID>2</n5:systemID>
<n5:beskrivelse>Barnehage søknader</n5:beskrivelse>
<n5:erRelatert rdf:nodeID="mappe_1"/>
</n5:arkivdel>
<n5:mappe rdf:nodeID="mappe_1">
<n5:tittel>Mappe for Hans Hansen</n5:tittel>
<n5:systemID>3</n5:systemID>
<n5:erRelatert rdf:nodeID="journalpost_1"/>
<n5:erRelatert rdf:nodeID="journalpost_2"/>
</n5:mappe>
<n5:journalpost rdf:nodeID="journalpost_1">
<n5:systemID>4</n5:systemID>
</n5:journalpost>
<n5:journalpost rdf:nodeID="journalpost_2">
<n5:systemID>5</n5:systemID>
</n5:journalpost>
</rdf:RDF>
RDF
<arkiv>
<systemID>1<systemID>
<beskrivelse>Oslo Kommune</beskrivelse>
<arkivdel>
<systemID>2</systemID>
<beskrivelse>Barnehage søknader<beskrivelse>
<mappe>
<systemID>3</systemID>
<tittel>Mappe for Hans Hansen</tittel>
<journalpost>
<systemID>4<systemID>
</journalpost>
<journalpost>
<systemID>5</systemID>
<journalpost>
</mappe>
<arkivdel>
</arkiv>
XML
24
Oslo
Kommune
Semantikk og Innhold
Presedens
Sak
ansvarlig for
Byrådsavdeling
for kultur og
utdanning
ans
va
rlig
for
r
ha
fra
s
en
d
se
e
r
p
Barnehage
søknad
er
s
is
t
r
pa
r
e
Hans Hansen
ak
ak
sb
eh
an
dle
r
Maria Hansen
25
Semantikk og Innhold
●
●
●
Med bruken av semantikk her så går vi bort fra
et systemsentrisk forståelse av arkivdanning til
et objektsentrisk forståelse av arkivdanning
Ja, det er egentlig det samme underliggende
data, men det er
●
måten vi bruker det
●
måten vi søker gjennom det som blir anderledes
Datamaskiner kan forstå og prosessere det
26
<rdf:RDF
xmlns:innhold="http://www.arkivlab.no/innhold"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
<innhold:sak rdf:nodeID="presedens_sak_1">
<innhold:sak_id>12334</innhold:sak_id>
</innhold:sak>
<innhold:person rdf:nodeID="hanshansen">
<innhold:person_navn>Hans Hansen</innhold:person_navn>
<innhold:person_personnummer>1408197512345</innhold:person_personnummer>
</innhold:person>
<innhold:person rdf:nodeID="karlkarlsen">
<innhold:person_navn>Karl Karlsen</innhold:person_navn>
<innhold:rolle>saksbehandler</innhold:rolle>
</innhold:person>
<innhold:sak>
<innhold:part_i_sak rdf:nodeID="hanshansen"/>
<innhold:saksbehandler rdf:nodeID="karlkarlsen"/>
<innhold:presedens rdf:nodeID="presedens_sak_1"/>
</innhold:sak>
</rdf:RDF>
27
Datakvalitet
●
Datakvalitet for kommunene
●
●
Hva er det?
Completeness, accuracy, timeliness,
correctness
●
Datakvalitet som en del av integritet
●
Datakvalitet opp mot TRAC standarden
●
Både ved danning og bevaring
28
Infrastruktur
●
Stipendiat prosjektet blir bred og kan utvikles
på mange måter
●
Inkluderer brukeren (saksbehandleren)
●
Sikre tillit (chain-of-custody) fra danning til bevaring
●
Nettskyen
29
InterPares 4
●
Det jobbes med en ny runde av InterPares
prosjektet
●
●
Så vidt jeg vet er det ingen norske deltakere
"The need to be remembered, the right to be
forgotten"
●
30
VERDIKT fagsøyler
31
EU Prosjekt (depot og datakvalitet)
●
EU innenfor 7. rammeverk har en arkiv relatert
utlysning med frist April 2011
●
Sikker overføring til depot med datakvalitet
●
Mulig konsortiet*
–
–
–
–
●
●
HiO arkivdanning/semantikk (forsker)
DCU/DnV datakvalitet (forsker)
ESSolutions (ESSARCH) (kommersialisering)
KDRS/ En eller flere IKA institusjoner (bruker)
Grovt sett prosjekt budsjett 7 millioner per år over 3 år
–
●
*NB, dette er første gange
sammensetting av konsortiet
er luftet offentlig. Ingen av de
nevnte selskapene har sagt
ja til å være med
Bruker partner kanskje 750 000,- til 1 000 000 per år men må
egen finansiere 50%
Ønsker å finne ut hvem kunne tenke seg å være
med i konsortiet, ikke svar idag
Vi må begynne nå hvis vi ønsker et prosjekt
32
EU Prosjekt (depot og datakvalitet)
●
●
Mulig kombinasjon av TRAC standarden og
Noark 5 kjerne og ESSARCH
●
Naturlig neste steg etter DIAS?
●
Fokus på kommunene ikke statlig forvaltning
Krav fra TRAC Standarden:
●
Overtagelse av innhold ved Mottak
–
●
Generering av arkiv pakke (AIP)
–
●
B1.1 til B1.8
B2.2, B2.4 til B2.6, B2.8 til B2.13
Kanskje søke Kulturråd midler for å skrive
søknaden
33
TRAC B1.1 til B1.4
●
●
●
●
(B1.1) Depot må identifisere egenskapene til
digitale objekter de ønsker å bevare
(B1.2) Depot angir klare definisjoner om
informasjonen som inngår i en avlevering (dvs.,
SIP)
(B1.3) Depot har mekanismer som kan
identifisere og autentisere kilden til alt materialer
(B1.4) Depotets mottaksprosess sjekker hvert
mottatt objekt (SIP) for fullstendighet og
korrekthet
34
TRAC B1.5 til B1.8
●
●
●
●
(B1.5) Depot har tilstrekkelig fysisk kontroll over
de digitale objektene for å bevare dem
(B1.6) Depot gir arkivskapere passende svar på
forhåndsdefinerte punkter i løpet av mottaks
prosessen
(B1.7) Depot kan vise når bevarings ansvaret er
formelt godkjent for en avlevering (dvs. SIP)
(B1.8) Depot må samtidig registrere handlinger
og administrative prosesser som er relevante for
bevaring
35
B2.2, B2.4 til B2.6
●
●
●
●
(B2.2) Depot har en identifiserbar, spesifisert definisjon for hver
AIP eller klasse av informasjon som depot bevarer
(B2.4) Depot kan dokumentere at alle mottatte objekter (dvs.
SIP) enten aksepteres i sin helhet eller som deler av en
eventuell arkivpakke (dvs. AIP), eller hvis der er forkastet så er
det journalført
(B2.5) Depot har og bruker en navngivingsprosess som
genererer synlige, varige og unike identifikatorer for alle
arkiverte objekter (AIPer)
(B2.6) Hvis unike identifikatorer er forbundet med en SIP før
mottak, skal depot bevare denne identifikatoren på en måte
som opprettholder en vedvarende assosiasjon med den
arkiverte objekten (f.eks AIP)
36
B2.8 til B2.13
●
●
●
●
●
●
(B2.8) Depot registrerer representasjoninformasjon (inkludert
formater) ved mottak
(B2.9) Depot tilegner seg bevaringsmetadata (dvs. BBI) for
tilhørende innholdsinformasjon
(B2.10) Depot har en dokumentert prosess for testing av
forståelighet av innholdsinformasjon og kan utvikle dette til
et avtalt nivå på forståelighet
(B2.11) Depot verifiserer hver AIP for fullstendighet når de er
generert
(B2.12) Depot har en uavhengig mekanisme for å verifisere
integriteten av samlinger / innhold
(B2.13) Depot har samtidige registreringer av handlinger og
administrative prosesser som er relevante for bevaring
(generering av AIP )
37
EU søknad skriving
●
Må bli enig om budsjett tidlig
●
Unngå kostnadseksplosjon siste uken
●
Deadlines er viktige
●
Viktig at alle er samstemt
●
Unngå at konsortiet kollapser den siste uken
●
En redaktør som ser helheten
●
Partner roller må være klare:
●
●
Forskning, Kommersiselsering, Bruker
Geografisk fordeling også viktig:
●
Norge, Sverige, Irland
●
Usikker om vi må ha en til
38