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