(Etablering og oppdatering av notatet. Siste: 26.6.2024)
(er under justering)
INNHOLD
Bygdebase
1. Innledning.
2 Bygdebase sammenlignet med bygdebok
3. Bygdebasemodeller
3.1 Lokhis-modellen
3.2 HBR-modellen
En bygdebase kan defineres som en digital løsning som forvalter datagrunnlaget og gir tilgang til gårds- og slektshistorie via nettet. Bygdebase er dermed et alternativ til trykte bygdebøker. Hoveddelen av dette notatet er en vurdering av fordeler og ulemper med bygdebase sammenlignet med bygdbok.
Jeg har etablert og drifter en kompett bygdebase for Loen kirkesogn. Det er benyttet betegnelsen Lokhis for denne bygdebasen (forkortelse for Lokalhistorisk informasjonssystem). Det er også skissert en løsning basert på arkivverkets datasystemer. Denne er døpt HBR-modllen (forkortelse for Historisk befolkningsregister som utgjørd slektsdelen). Det er gitt en meget kortfattet presentasjon av disse modellene i dette notatet, men det er lenke til oppslag i den historieke delen av disse databasene og lenke til mer detaljerte modellbeskrivelser.
Løpende tilgang til ny informasjon.
I et bygdebokprosjekt er det boken som er brukergrensesnittet. Dersom brukeren skal få tilgang til ny informasjon, må det trykkes en ny bok. Trykking av ny bok representerer gjerne alene en større kostander enn det å saffe data fra en ny kilde i datagrunnlaget.
Ved oppdatering av data fra en ny kilde i en bygdebase, er det nok å legge data fra den nye arkivkilden inn i bygdebasens kildemodul. Informasjonen blir da automatisk tilgjengelig i brukergrensesnittet uten ekstra tiltak og kostnader.
Et eksempel. Da foketellingen for 1920 ble frigitt, ble data fra denne lagt inn i kildebasen for Loen bygdebase. Folketellingen for 1920 ble definert som en egen kilde. Tellingen for hvert bruk/bosted ble registrert som kildehendelse og hver person ble registrert som kildeperson. De fleste personer som inngikk i tellingen, var allerede registrert i personemodulen (bl..a. fra kirkebøker), og bruk/bosteder var tidligere registrert i modulen "bruk" Det eneste som måtte gjøres i tillegg til å registrere enhetene, var å knytte ID til bruk/bosteder og kildepersoner. Alle data fra folketetllingen i 1920 ble dermed automatisk tilgjengelig via eksisterende brukergrensesnitt.
Den teknologiske utviklingen
Problemet med en Bygdebase vil være at den hele tiden må tilpasses til den teknologiske utviklingen. Selv om man kan være tilfreds med en løsning, er det min erfaring at man etter 10 år må skifte til nye systemløsninger fordi de gamle ikke lenger støttes av nye operativsystemer/utviklingsverktøy. Bygdebaser må derfor ha en forankring i en varig organisasjon uavhengig av enkeltpersoner.
En bygdebok er et statisk produkt. Den er basert på informasjon som var tilgjengelig på utgivelsestidspunktet og den endres ikke. Boken kan imidlertid ha evig liv så lenge skrifttyper og språk består. For et bygdbokprosjekt er det tilfresstillende om IKT-kompetanse og kompetanse i historegransking er til stede for gjennomføringen av bokprosjektet. Det er ikke noe problem om denne kompetansen ikke er varig i det aktulle historielaget og blir borte i ettertid.
Mengden av informasjon
En bok har en begrenset størrelse. Om man skal ta med all informasjon med eksempler vil det sprenge alle rammer for presentasjon i en bok.
I en Bygdebase kan man starte med oversikter og så kan brukeren gå i dyden hvor det er av interesse. Derfor kan man ta med mye mer kildeinformsjon, eksempler, bilder og lenker til annen informasjon.Utbredelse av slekter
Grender, gårder og delvis bruk er stedfestede enheter. For hver forekomst av disse enhetene kan det være naturlig å gi en samlet historisk fremstilling i bokform. Personer er ikke knyttet til samme stedfestede enhet gjennom hele livsløpet. Om man for et bruk/bosted skulle omtale hele slekten for inngiftede personer og etterslekten for utflyttede personer ville det sprenge alle rammer for en bok. Dessuten ville mange personer i deler av livsløpet kunne ha tilknytnnge til flere bruk og fullstednig slektsinformasjon for hvert bruk ville da bli dobbeltregistrering.
Historisk var det vanlig å finne ektefeller i lokalområdet. Mye av slekten ville man da finne innen området for en bygdebok. Likevel blir det springende å følge slekten i en bok. Selv om en person gifter seg til et annet bruk i området som dekkes av boken, må man bla til et annet stred i boken for å følge slekten. Enda vere blir det om en person har slektsopphav eller har flyttert til et annet område. Da vil man i boken bare kunne legge inn en fotnote, og leseren må slå opp i en anne bok om vedkommende i beste fall har boken tilgjengelig.
I en bygdebase kan man med enkle tastetrykk følge slekten innen hele området som dekkes av boken. For en landsdekkende bygdebase vil dette gjelde hele landet. For Loen bygdebase kan man egentlig si at den er verdensomspennede for egen slekt. Dette begrunnes med at aner og etterslekt er registrert komplett for egen slekt. I familens slektstre kan man med enkle tastetrykk følge slekten til Amerika og få full oversikt over alle etterkommere som har etablert seg der. I en database kan det også legges lenke til tekst som omtaler gårder og bruk/bosteder.
Sperrefrister for arkivdata
For offentlige arkivdata er det sperrefrister for innsyn. For noen arkivkilder er dette av omsyn til personvernet og for statistisk materiale blir innsyn sperret i 100 år for å sikre korrekte oppgaver til statistikken.
Bygdebøker har den fordelen at det kan publiseres informasjon om alle nålevende personer uten restriksjoner i forhold til personvernet. Det forutsetter at informasjonen samles inn fra den det gjelder og godkjennes av denne for publisering i bok. Jeg antar at data innsamlet til dette formålet, ikke uten videre kan inngå i en bygdebase som gjøres fritt tilgjengelig på nettet?. En ny bygdebok vil derfor være mer ajour enn en bygdebase på samme tidspunkt. Det kan imidlertid ikke trykkes ny bygdebok hvert år. For Stryn kommune trykkes det nå oppdaterete bygdebøker. Forrige versjon av bygdebøker ble publisert for ca 50 år siden. Bygdebøker må derfor også oppfattes å ha etterslep i tid. I et historisk perspektiv er det bortkastet å samle inn persondata lokalt fordi den samme informasjonen etableres i arkivene i digital form og frigis automatisk etter hvert som tiden går og sperrefristene flyttes. (eksempel: Folkereigsteret med sin historikk)Brukervennlighet
I min ungdom hadde jeg en visjon som jeg kalte "Home system". Når jeg omtalte dette for andre, ristet de på hodet og bemerket at for en gammel bestefar ville det nok uansett være enklest å bla i bøker.
Nå er "home system" en realitet hos meg. Jeg "gamle bestefar" kan nå sitte i godstolen på datarommet og foran meg har jeg familiens storskjerm (stor dataskjerm). Her har jeg tilgang til alle TV-programmer som inngår i vårt abonnement, og for hovekanalene er det tilgang til programmer fra tidligere på dagen. Her har jeg oversikt over hele vår slekt både her i landet og i Amerika og oversikt over alle slekter i Loen sokn. Hele bildearkivet er også tilgjengelig med søkeord for hendelser og knyttet til personer i slektsbasen. Etter hvert som hukommelsen blir dårligere, blir det økende behov for å gjøre oppslag. I bokhyllene står alle versjoner av bygdebøker for kommunen, men disse får stå og støve ned. Gamle bestefar slår opp på dataskjermen
Konklusjon. Konseptet bygdebase er en kombinansjon av gårds- og brukshistorie kombinert med slektshistorie. Historien for gårder med sine bruk er det naturlig å publisere som tekst med illlustrasjoner. Dette kan gjøres i bokform. Slektshistorien hører derimot naturlig hjemme i den digtale verden og forvaltes best i databaser. Man kan ikke sitte og lese i en bok og bare klikke på en side i boken og gå over til den digitale verden. I den digtale verden kan også tekst gjøres tilgjengelig. Mens man blar i en slekt på dataskjermen kan man bare klikke på en person og automatisk gå inn i historiebeskrivelsen for gården som vedkommende kommer fra. For konseptet gårds- og slektshistorie er mitt valg Bygdebase.
Dette notatet har med omtale av 2 modeller for bygdebase. Det er Lokhis-modellen (Lokalhistorisk informasjonssystem) som er lagt til grunn for min private bygdebase for Loen sogn, og en modell som jeg har kalt "Tekst + HBR" eller bare HBR-modedllen. (HBR = Historisk befolkningsregister).
Min omtale/utredning om HBR-modellen er tatt med bare for å antyde at det kan finnes et alternativ for bygdebase basert på arkivverkets egen dataforvaltning og bukergrensesnitt. Om noen med utgangspunkt i dette finne er slik løsning interessant, anbefales det å kontaket nøkkelpersoner knyttet til arbeidet med HBR, Histreg eller prosjektet Historiske reigistre.
Personlig vil jeg benytte Lokhis som min bygdebase og mitt slektsprogram for reste av min tid. Den private delen av Lokhis (nålevende personer) har etter hvert blitt minst like viktig for meg som den historiske delen som var utgangspunktet. Jeg vil trolig fortsette å benytte HBR for oppslag.Min kildebase har komlett kopi av kildedata bare for Loen sokn. For historiske personer utenfor Loen med slektstilknytninga til Loen, kan det ha interesse for meg å gjøre oppsalg for kildehendelser i HBR.
Lokhis ble valgt som arbeidstittel for et samarbeidsprosjekt mellom meg og min sønn Olav. (LokHis = LokalHistorisk Informasjonssystem). Dette prosjektet ble etablert i forbindelse med at utskrifter på papir fra mine data ble erstattet med direkte oppslag mot datagrunnlaget. Det er opplegget for dette prosjektet som har fått betegnelsen "Lokhis-modellen".
Med basis i Lokhis-modellen har det blitt etablert en komplett bygdebase for Loen kirkesogn. Den fullstendige databasen er nå en privat bygdebase uten tilgang for andre. Det er lagt ut en forenklet versjon på nettet med betegnelsen Loktest. I denne nettversjone er det ikke med detaljopplysninger om personer født etter 1920. I tillegg til å gi informasjon om historiske personer er det meningen at Loktest skal gi muligheter for å bli kjent med lokhis-modellen. Det er tilgang til Loktest på mitt nettsted hvor det er lenke til "Lokhis"
Det er også laget en modell-beskrivelse for Lokhis-modellen . Når det gjelder detaljer, vises det til denne modellbeskrivelsen.
Det er valgt en løsning som tilsvarer gards- og slektshistorie i bygdebøkene. Dette har gitt rammen for hvilke data som må inngå i løsningen og hvilke skjermbilde som må utvikles.
Datagrunnlaget er strukturert slik at det kan programmeres et brukergrensesnitt som gir alle aktuelle skjermbilder på direkten eller at det etableres et komplett sett med skjermbilder ved satsvis gjennomkjøring. Bygdebasen for Loen har satsvis generering av skjermbildene. En slik generering kjøres etter hver oppdatering og tar ca 40 sekunder. Oppslag mot ferdige skjermbilder tar nesten ikke tid. Hvis det skullle etableres en landsdekkende løsning basert på denne modellen, måtte det velges en løsning med generering av skjermbilder enkeltvis på direkten.
Datagrunnlaget består av separate moduler som etableres fra diverse offentlige arkiv. Alle modulene er tilordnet en overordnet datamodell basert på prinsippene for relasjonsdatabaser. Det er etablert alle relasjonstabeller som trengs for å kunne generere alle aktuelle skjermbilder automatisk. Dette omfatter også relasjoner mellom gård, bruk og person på den ene siden og på den andre siden lenker til tekst, bilder og kart i arkiver utenfor databasen.
Familebildet er formulert som slekstre. Visulet gir dette et godt grunnlag for å bla i slekten i alle retninger. Slektsrelasjoner er basert på at alle personer har en far og en mor. Når dette er ukjent, stopper sletslenken. I tilfeller med særkullsbarn gir denne modellen grunnlag for å vise hvilke barn som har de ulike personene i et parforholdet som foreldre.
Når det gjelder en modul kalt "bruk" er denne basert på bygdeboken for Stryn fra 1970-tallet. Den etablerte modulen omfatter Loen sokn, alle gårdene i sognet, de gamle gårsbrukene på gårdene, nye boligeiendommer etablert før 1960 samt eiere og brukere (bygslere) knyttet til bruk/bolig. I forbindelse med bygdebokarbeidet ble det hentet ut en matrikkleutskrift som ble trykket opp. Denne utskriften er dateret 1968.
Man må innse at databasesystemer ikke kan forvente varig drift hos privatpersoner. Dataløsningene må derfor ha en organisasjonsmessig forankring. Med dette som bakgrunn har jeg forsøkt å markedsføre ideen om en landsdekkede bygdebase basert på lokhismodellen. Dette har vist seg å være urealistisk. Fra min side legges det nå opp til at forvaltningsdelen med oppdaterin av Lokhis for Loen avsluttes etter min tid. Genererte skjermbilder (se omtale ovenfor) er basert på html og vil kunne ha lenger levetid enn databasen som er benyttet, med da uten oppdatering.
HBR-modellen er en løsning som baseres på arkivverkets egen dataforvaltning og brukergrensesnitt. Det etableres nå et Historisk befolkningsregister (HBR) med familieside og livsløptabell på samme måten som i Lokhis (men ikke helt identisk utforming). Dette utgjør slektsdelen i HBR-modellen.
Når det gjelder de stedfestede enhetene (grend, gård, bruk) kan man tenke seg at dette etableres som teskt og at denne forvaltes av Nasjonalbiblioteket i Lokalhistoriewikki. I tekstdelen registreres personer som har vært eiere eller brukere (bygslere) på brukene i aktuelt område. For disse personen legges det lenkt til person i HBR. På denne måten får man en bygdebase som kombinerer gårds og slektshistorien. Denne modellen er kalt HBR-modellen (HBR= Historisk BefolkningsRegister).
Et bygdebaseprosjekt etter HBR-modellen er basert på følgede:
Historisk befolkningsregister (HBR) etableres av hensyn til forskning på befolkningsutvikling og andre formål. Dette skjer helt uvahengia av eventuell bruk av datagrunnlaget i bygdebaser. Etablering og drift av systemet skulle dermed være sikret uansett hva som skjer med "Bygdebase-sjangeren"
Det etbleres kildedata tilbake til ca. 1800 og eventuelt lenger bakover i de tilfellene hvor data digitaliseres og transkriberes for Digitalarkivet. Det legges opp til at registeret skal videreføres til det kobles til Folkeregisteret som ble etablert i 1964. Det vil da bygges opp ny slektsinformasjon automatisk som sikres for fremtiden og for forskningen, og vil bli tilgjengelig for vanlig oppslag etter hvert som sperregrensene flyttes.
Man kunne tenke seg at HBR kunne inngå i Lokhis-modellen med slektsdelen. Da er det imidlertig bedre å tenke seg en helt ny modell som baseres på bruk av bare offentlige data med offentlige brukergrensnitt. Det blir da ikke noe lokalt ansvar for etablering og drift av databaser og brukergrensesnitt.
HBR og Lokhis har samme logikken for etablerein av familieside og livsløptabell. Som standard inngår dette i opplegget for HBR uavhengig av behovet som kilde for gårds og slektshistorie. Produktene i HBR er imidlertid ikke helt identiske med tilsvarende i Lokhis-modellen.
Familiesiden i HBR er utformet som en liste som omfatter aktuell person samt foreldre, søsken, partner og barn. På sammen måten som for familiesiden i Lokhis, kan det klikkes på en person i familien og få opp ny familieside for denne.
Livsløptabellen for en person har med en rad for hver kildehendelsen der personen inngår. Ved å klikke på kildereferansen for kildepersonen får man opp et nytt skjermbilde som inneholder alle personene i kildehendelsen (eks. alle i familien om kilden er en folketelling).
Det har blitt etablert en mini bygdebaser for Sjurebruket i Loen (bruk 70/6 i Stryn kommune). Lenkingen av kildepersoner var ikke komplett i utgangspunktet. I Juni 2024 ble det som spesialoppdrag gjennomført lenking og kobling for alle kildepersoner som man fant for eiere og brukere på dette bruket. For sammneligning ble det tatt med lenke til persondelen både i Lokis og i HBR. Slektsdelen i HBR for Loenområdet omfatter personer som har hatt livløpet sitt (eller deler av det) i perioden ca 1750-1930.
På samme måten som for lokhismodellen er det laget en modell-beskrivelse også for HBR-modellen . Når det gjelder detaljer, vises det til denne modellbedkrivelsen
Som nevnt er det laget en liten mini bygdebase for Sjurebruket i Loen (70/6). Formålet med dette var å gi et bilde av hvordan en bygdebase basert på HBR-modellen kan se ut i praksie. Det må bemerkes at tekstdelen kan gis individuell utforming for eventuelle prosjekter som baseres på denne modellen.