Tanker om
HF-infrastruktur
Hva er problemet med Marcus?
Vi er kjent med datamodellering med RDF
Videreutvikles ikke!
Brukere må ha desktop-app!
Ikke validering
Full av bugs
UX kan ikke enkelt tilpasses
Umulig gjøre til et avansert arbeidverktøy
Bruker sparql
Videreutvikles ikke!
Laget av én chilener
Bruker en forferdelig template-engine
Bygger ikke på moderne web-app-prinsipp
Ineffektiviteter overalt
Dårlig skalering
Kjapt søk
Tungvidt utviklingsprosess
Har ikke fått til hierarkiske data eller relasjoner
Driftes av UB
Frontend ikke basert på et solid rammeverk
Ikke langt unna IIIF
Egenutviklet modell
Ikke IIIF
Ikke API
Ikke fulltekstsøk
MAM
Noen penger inn
Ikke vedlikeholdt
Hjemmesnekret PHP-serversideskript foretar validering og epost
Integrerer med Redmine Plugin ingen andre ved UiB bruker
Manuelt arbeid
Utvalg(?) av dokumenter i Oria
Hvor mye er det brukt?
Hvordan skal vi videreutvikle integrasjonen?
Lite er testbart
Forsøk på å lage et utviklingsmiljø med frontend og backend inkluderer ikke alle komponentene og har ikke vært enkelt å jobbe med
UB må ha en plan
Prinsipp
- Pragmatikk over evangelisme
- UX/brukeropplevelse over (elegant) datamodel
- Konsum av tjenester før drift av tjenester
- Svak integrasjon over sterk integrasjon
Hva skal lages?
UB må vurdere hvor man skal sette inn innsatsen på HF-infrastruktur. Hva skal UB som produsent lage? Hva skal man eie?
Drift av løsninger (OSS eller egen utvikling) forplikter UB i mange år. Man må ta en seriøs utredning på hva UB eller HF trenger og hvordan man kommer dit raskest.
Dette bør gjøres før man rekrutterer nye ansatt.
Frontend
CMS
Hvilke komponenter?
En HF-infrastruktur vil trenger flere tunge komponenter og utstrakt støtte.
- MAM
- Konstant frontend-utvikling
- CMS, som må kunne tilpasses raskt
- Visualisering av forskningsresultat
- ...
Frontend
CMS
Viz
MAM
Hvordan?
Alt skal i skyen. Skyen er vanskelig. Vi kan betale andre til å gjøre det enklere for oss.
Vi kan gå rett på Now, Netlify.
Eller bestille tilsvarende løsning fra ITA på AWS (kan de levere?). For UB må løsningen være så smertefri å bruke som mulig.
Det betyr at produkt som UB lager må ha eget budsjett. Man må kunne betale for effektive løsninger.
Frontend
CMS
SaaS
Viz
Analyse
MAM
Kan UB levere?
I min mening, absolutt ikke uten partnere.
Vi trenger partnere eller nasjonale aktører som leverer de tyngste komponentene. UB og UiB har ikke kapasitet til dette.
Det man har kapasitet til er å bygge tilpassede løsninger på toppen av en nasjonal eller kommersiell
infrastruktur. En infrastruktur som ikke krever "koordinering"
Frontend
CMS
SaaS
Viz
Analyse
MAM
ITA
UB/HF
Utviklingsstrategi
- Prioriter Javascript
- Lag -pakker
- Skriv -funksjoner
- Øk samarbeidet med sektoren
- Hjelp andre i bruken av serverless-tjenester
- "hjelp til selvhjelp"
La oss si, vi SKAL lage "Marcus v6"
- Vi har en plan
- Godkjent av eksterne konsulenter blant flere alternative løsninger
- Vi har en styringsgruppe, alle avklaringer på plass
Kan det se slik ut?
?
Manifest
Metadata til manifest?
Annoteringer?
Deler av objekt?
Eksempel på hva som må avklares
IIIF integrasjon
CMS
Kan det se slik ut? 2
{dev}
Inspirasjon - NB API (iiif.io)
Inspirasjon - Sanity + NB
Fremtidige prosjekt og konstnader
Hvordan håndtere forskningsprosjekt
UB
UB
Klargjorte pakker m/støtte
Ferdig resultat/datasett
Kostnadsstyring
UB
{
}
Prosjekt/forsker/partner eier S3 bucket, abonnement, devopsmiljø, AI/ML
UB yter support og utvikler, men betaler ikke kostnadene på vegne av prosjekt/forsker/partner.
Ved prosjektslutt kan resultat flyttes til UBs bucket og kostnader kalkuleres.
Styring
DigHumLab-leder
UiB koordinatorer/styringsgruppe
Web/editor
Semantikk
Diging
Datasett
Verdistrøm – Digital humaniora
Skyinfrastruktur
Lab
DigHumLab-leder
UiB koordinatorer/styringsgruppe
Web
API
Redaksjon
Analyse
Verdistrøm – Språksamlingane
Skyinfrastruktur
Stadnamn
Tanker om infrastruktur
By Tarje Lavik
Tanker om infrastruktur
- 112