Datasystemet skal fungere som eit sentralt arbeidsverktøy ved utarbeiding av busetnadshistoria for eit avgrensa, geografisk område. Busetnadshistorie (eller -soge) blir i det fylgjande nytta som samleomgrep for framstilling av opplysningar, historier, illustrasjonar osv knytt til bustader og bebuarar, sett i eit historisk tidsperspektiv, tilsvarande «gards- og ættesogedelen» i tradisjonelle bygdebøker. Men systemet skal òg kunne handtere data for større tettstader og t.d. bydelar – nemningane «bygdebøker» og «gardssoger» er derfor ikkje dekkande, og kan lett skape eit feil inntrykk av stofftilfanget i slike verk. Målgruppa for datasystemet blir primært forfattarar av busetnadshistorie som nemnt, eller uttrykt på anna vis: sogeskrivarar med bustad- og bebuarhistorie som arbeidsfelt.

Sjølve framstillinga har tradisjonelt skjedd ved trykking og utgjeving av bøker, og det vil nok hovudsakleg vera tilfelle også i næraste framtid. Det er likevel ikkje noko i vegen for at materialet kan presenterast med bruk av andre media, gjerne i form av webløysingar som det mest aktuelle. Dette er da sjølvsagt avhengig av korleis oppdragsgjevar ynskjer å nytte det ferdige materialet. For eit vanleg busetnadssogeprosjekt vil oppdragsgjevaren som oftast vera ein kommune, som da naturleg nok ynskjer å dekke inn att sine utgifter til prosjektet. Elles blir dette òg eit spørsmål om personvern, sidan opplysningar om nålevande personar neppe kan forsvarast å bli gjort tilgjengeleg i søkbar form over Internett. Ei ferdig busetnadshistorie må derfor avgrensast ved å fjerne eller skjerme alle opplysningar nyare enn t.d. 60 år, før ei slik løysing er aktuell.

Med utgangspunkt i tilgjengeleg kjeldemateriale skal systemet nyttast til å bygge opp person- og bustadregister, som i sin tur dannar grunnlaget for å produsere manusutkast til busetnadshistoria for området. Metoden som nyttast under sjølve arbeidet med å etablere personregisteret bygger på familierekonstitusjon slik den er beskrive m.a. i S. Dyrvik: «Historisk demografi», 1983. Metoden vil nødvendigvis bli noko modifisert og delvis utvida ved bruk av eit datasystem i staden for manuelle arbeidsoperasjonar. Systemet skal elles bygge vidare på erfaringar og delløysingar beskrive i hovudoppgåva L. Nygaard: «Fra historiske kilder til persondatabase», 1985. Det viktigaste grunnlaget for konkrete systemløysingar vil likevel vera erfaringane og systembeskrivinga som O. Tovmo / Dovre Data Arkiv har etter utvikling av dataprogrammet «FamRek». Det vidare arbeidet med standardisering og tilrettelegging for registrering av kjeldemateriale vil ta utgangspunkt i G. Thorvaldsen: «Håndbok i registrering og bruk av historiske persondata», 1996. Vidare vil konkrete systemløysingar måtte bygge på det som finnast av oppdatert litteratur innafor dei ulike emna (spesielt lenking, namnestandardisering osv).

Den vesentlegaste endringa i høve til tidlegare løysingar eller metodar, vil vera oppbygging av eit strukturert bustadregister for eit område, slik at kvar person kan koplast opp mot ein eller fleire bustader. Bustadregisteret skal fungere som disposisjon ved utlisting av alle person- og bustadopplysningar i det ferdige manusutkastet til busetnadshistoria. Tradisjonelt vil dette ofte medføre at bustadstrukturen må beskrivast hierarkisk med grender / namnegardar / einskildbustader. Ved ein sekvensiell gjennomgang, frå eine enden av bygda til den andre, får ein så lista ut «historie» for kvart område og kvar namnegard, og «historie» og «folk» for kvar av dei underliggande bustadene. Men systemet skal vera så generelt at heilt andre «bustadstrukturar» òg kan definerast, sjølv om ein går ut over det tydingsinnhaldet som ligg i ordet «bustad». Vidare har ein tradisjonelt at folket under kvar bustad blir lista ut sekvensielt i tidsavgrensa «grupper», som ofte tilsvarer det ein forstår med ein brukarfamilie eller eit hushald. Desse gruppene skal òg kunne definerast så generelt at personopplysningane kan listast ut på heilt anna vis enn dei vanlege «familieoppsetta».

I tillegg til å fungere som disposisjon ved utlisting av opplysningar, skal bustadregisteret òg danne grunnlag for å generere tilvisingar frå person til bustad i eit ferdig manusutkast. Dette gjer at kvar enkelt person kan følgjast frå bustad til bustad vha eintydige referansar, noko som vil vera nødvendig for t.d. å kunne følgje slektsliner utan alt for mykje «leiting». Oppretting av slike tilvisingar har tidlegare vore gjennomført manuelt under tekstbehandlinga av sjølve manuset, noko som medfører mykje tidsressursar for å sikre eit mest mogleg feilfritt resultat.

Systemet skal ferdig utvikla ha modular for gjennomføring av dei fleste arbeidsoperasjonane som er nødvendige på vegen frå kjeldemateriale fram til eit ferdig manusutkast. Dette vil i hovudsak medføre utvikling av modular for å:

· registrere kjeldemateriale og importere eksisterande datamateriale

· konvertere eller tolke datamaterialet til personhendingar

· lenke personhendingar saman til enkeltpersonar (personeiningar), dvs. bygge opp eit personregister

· kople personane i registeret saman vha personrelasjonar

· bygge opp eit bustadregister

· knytte personar og bustader saman vha persongrupper under kvar bustad

· liste ut alle relevante data i dei ferdig oppbygde registra

Dei ulike omgrepa er forklart nærare i 2.1–2.6. Alle modulane skal fungere fullt ut uavhengig av kvarandre, og det skal vera mogleg å arbeide berre med utval av datamaterialet i dei enkelte prosessane. Føresetnaden er sjølvsagt at arbeidsoperasjonane skjer i nødvendig rekkefølgje.

Dei ulike arbeidsstega skal altså kunne utførast berre for delar av materialet om gongen, noko som medfører at brukaren står friare ved val av overordna framgangsmåte. Det vil likevel vera eit krav at så mykje som mogleg av det aktuelle kjeldematerialet er registrert og konvertert til personhendingar i systemet før det vidare arbeidet startar. Det skal kunne leggast inn nye (tilleggs)kjelder undervegs, men sidan dei nye opplysningane kan medføre konflikt med alt oppbygde strukturar i datasystemet må ein unngå slike situasjonar. Vidare bør ein ha definert ein viss grunnstruktur når det gjeld bustadene som skal etablerast. Eit utgangspunkt kan vera å bygge opp ein «flat» struktur for heile området på bakgrunn av matriklar e.l., for så å modifisere denne etterkvart som behova oppstår. Den vidare arbeidsprosessen kan skisserast slik:

(a) identifikasjon av enkeltperson i kjeldematerialet, framsøking av det utvalet personhendingar som gjeld denne eine og same personen, oppretting av ny personeining P i registeret og lenking av dei valde hendingane til denne.

(b) tilbake til (a) ELLER identifikasjon av ev. fyrste eller neste partner (ektefelle, sambuar osv.) til personen P og lenking av denne i samsvar med (a).

(c) kopling av ein person P og ev. partner til ein partnerrelasjon R, kopling av kvar av partnerane til sine respektive foreldre og kopling til felles barn for P og partneren (føresetnaden er sjølvsagt at foreldra og barna alt er oppretta med personeiningar i registeret).

(d) tilbake til (b) ELLER knyte ein personrelasjon R til ei ny eller eksisterande persongruppe under ein etablert bustad i registeret.

(e) tilbake til (d)

Vi merker oss at personeininga P kan ha fleire partnerrelasjonar, som i sin tur skal knytast til ulike persongrupper under ulike bustader – utan at dei nødvendigvis er oppretta i registeret (sjå også 2.4.2). Det skal òg vera mogleg å gjennomføre arbeidsprosessen over punkt for punkt gjennom heile materialet, før ein går vidare til neste. Ut frå dette må det vera mogleg å nytte minst ein av strategiane nedafor:

· opprette partnerrelasjonar som ikkje er knytt til nokon persongruppe ennå, for seinare å søke dei fram att og knyte til aktuell gruppe på ein bestemt bustad.

· lenke, kople og utplassere på ein aktuell bustad personeininga P og ein av partnerane, dvs ein av partnerrelasjonane til P, utan omsyn til om P har fleire relasjonar eller ikkje. Dei andre partnerane må da handterast som ein ny person etter same prosess som nemnt over.

· søke fram andre, eksisterande eller opprette nye bustader, ev. mellombels, for tilknyting mellom partnerrelasjonane og aktuelle persongrupper etter kvart som behovet oppstår.

Enkelte av punkta i den skisserte arbeidsprosessen kunne i prinsippet vore gjennomført ved å nytte ev. kommersiell programvare som måtte høve til slike formål, fyrst og fremst gjennomføring av lenkeoperasjonen. Men ei løysing med bruk av anna programvare i tillegg vil truleg raskt fordre edb-kompetanse utover det ein kan krevje av den primære målgruppa for datasystemet. Det ville dessutan medføre ekstra innsats i å formalisere datautveksling mellom applikasjonane, og ikkje minst vil det vanskeleggjera ein fleksibel arbeidsmetode som nemnt over, der lenking, kopling og utplassering på bustad om ynskjeleg skal kunne gjennomførast om ein annan.

Det er den overordna framgangsmåten som avgjer kriteria for val av ein ny person å arbeide med i pkt (a) over. Det kan her tenkjast mange ulike metodar, etter brukarens eige ynskje. Det vil likevel vera slik at enkelte metodar gir sikrare resultat enn andre. Nokre døme:

· neste person blir vald ved ein sekvensiell gjennomgang av ei personliste basert på alle registrerte personhendingar, sortert alfabetisk på personnamnet. Dette tilsvarer i grove trekk den manuelle familierekonstitusjonen med bruk av person- og familiekort.

· neste person blir vald ved ein sekvensiell gjennomgang av ei personliste basert på alle registrerte personhendingar, sortert kronologisk etter tidspunkt for hendinga. Sidan seinare kjelder ofte har betre strukturerte / sikrare opplysningar enn eldre, bør gjennomgangen skje frå det nyaste materialet og bakover i tid.

· neste person blir vald ved ein sekvensiell gjennomgang av ei personliste basert på eit utval registrerte personhendingar og/eller andre eksterne kjelder, knytt til ein bestemt identifiserbar bustad, sortert kronologisk etter tidspunkt for hendinga (jf førre punktet). Prosessen må gjennomførast med oppbygging av ny personliste bustad for bustad gjennom heile området som skal beskrivast.

· neste person blir vald etter ein «hybrid» metode, der ein fyrst baserer seg på ein sekvensiell gjennomgang av ein eller fleire bestemte kjeldeseriar for heile eller deler av området som skal beskrivast, for så å nytte ein av dei andre metodane over på det resterande materialet. Eit konkret døme på dette vil vera å gå gjennom folketeljingane 1865, -75 og 1900 som utgangspunkt for eit «brukarskjelett» for bruk og plassar innan ein bestemt namnegard, for så å arbeide seg gjennom det resterande materialet i samsvar med førre punktet.

I tillegg til den skisserte verkemåten for systemet over kan det setjast opp nokre få generelle synspunkt kring interaksjonen med brukaren (grensesnittet). Systemet skal bygge på vanleg kjente prinsipp med bruk av vindu, menyar, dialogar osv i samsvar med standard løysingar for anna programvare. Det skal leggast vekt på å bygge opp enkle, mest mogleg sjølvforklarande skjermbilde. Systemet skal ta omsyn til uheldige ergonometriske verknader for brukaren. I praksis medfører dette at eit musestyrt system skal ha tastaturkommandoar som alternativ til mest mogleg av musebruken. Utforming og utprøving av det endelege grensesnittet vil fyrst kunne skje undervegs i arbeidet med utvikling av systemet.

2 Definisjonar og einingar

Tidsdata: det vil vera behov for å tidfeste alle hendingar i samband med personar og bustader. Generelt vil nøyaktigheita variere frå ein bestemt, kjent dato til ein gong innafor eit bestemt hundreår, eit vilkårleg tidspunkt før ein bestemt dato e.l. Eit tidspunkt skal derfor beskrivast med dato, år og ein spesifikasjon av nøyaktigheit. Nøyaktigheita kan t.d. representerast med eit intervall i tilknyting til årstalet, slik at alle tidspunkt innafor intervallet blir oppfatta som likeverdige. Ei tidsperiode vil vera samansett av to tidspunkt: fyrste og siste observasjon med sine tilhøyrande nøyaktigheiter eller intervall. Alle tidspunkt kan ev. ha ei tilhøyrande ledetekst som nyttast ved presentasjon av kompliserte tidfestingar som «i 1930- eller –40-åra».

	dato	årstal	intervall
14.08.1964	14/8	1964
1904		1904
1880/86		1880	+ 6
Kring 1865		1865	± 3
I 1750-åra		1755	± 5
Sist på 1600-talet		1675	± 25
Før 1657		1657	– 50

Eksempel: ulike tidspunkt og korleis dei kan spesifiserast.

2.1 Kjelder

Personhistorisk kjeldehending: ei hending («begivenhet») innført i ei primærkjelde, eksempelvis ein dåpsinnførsel i kyrkjeboka. Ei kjeldehending kan omhandle fleire, eller berre ein person.

Personhending: ei hending knytt til ein og berre ein bestemt identifiserbar person i ein kjeldeinnførsel, eksempelvis «far ved dåp», «mor ved dåp» eller «barn ved dåp». Ei personhistorisk kjeldehending kan dermed splittast opp i minst ein eller ofte fleire personhendingar.

Mange ulike historiske kjelder kan i utgangspunktet danne grunnlagsmaterialet som skal nyttast, men for at datasystemet skal kunne nyttiggjera seg innhaldet må innførslane knytast til enkeltmenneske, eitt eller fleire. Kjeldematerialet vil elles ha mykje varierande format, frå sterkt rubriserte (t.d. matrikkelen 1886) til meir eller mindre fritt format (t.d. tingbøker). Kompleksiteten vil òg variere mykje, frå enkle skattelister til dåpslister og folketeljingar.

Etter «oversetting», registrering og lagring i eit databasert system vil datamaterialet ha tilsvarande varierande format og kompleksitet, men det må vera eit krav at lagringsformatet er enkelt og kan kjennast att i eit vanleg databasesystem. Lagringsformatet må vera tabellarisk, slik at kvar rad (post) tilsvarer ein innførsel i ei kjelde, oppdelt i kolonnar (felt). Innhaldet i dei enkelte felta skal til saman danne eit strukturert bilde av den opphavlege historiske kjelda, så fullstendig og bokstavrett som mogleg. Datamaterialet må ha eintydig referanse bakover til dei tilsvarande opplysningane i det opphavlege kjeldematerialet. Lagringsformatet kan vera i samsvar med etablerte standardar som måtte finnast, men dette må ikkje vera noko absolutt krav.

Innførslane i dei enkelte kjeldene vil som nemnt vera knytt til minst ein namngjeve person (ofte fleire), altså ei personhistorisk kjeldehending. Dei personane som er knytt til kjeldehendinga skal kunne identifiserast. Datamaterialet må derfor lagrast i eit slik format at opplysningar om dei enkelte personane er utskilt i eigne felt. Saman med ein del andre sentrale opplysningar (t.d. type hending, tidspunkt m.m.) vil dette vera vesentleg informasjon som ein må ha direkte tilgang til i dei vidare arbeidsprosessane, eit slags sett med kjernedata. Resten av opplysningane som måtte finnast i dei enkelte innførslane skal kunne hentast inn som tilleggsinformasjon etter behov. Eksempel på dette kan vera registrerte fadrar, stad for kyrkjeleg handling o.l. Graden av strukturering her kan derfor i stor grad avgjerast av om datamaterialet skal nyttast til andre formål enn kva dette systemet tek sikte på.

Det er elles viktig å kunne handtere avvik og spesialtilhøve i dei enkelte kjeldene, på ein mest mogleg korrekt måte sett ut frå prinsippet om kjeldetruskap. Dette medfører at datamaterialet kan innehalde opplysningar som i kjelda er overstroke og retta, både den gamle og nye verdien. Verdiar eller opplysningar i kjelda som heilt klart er feil kan ha ein alternativ, meir korrekt verdi. Vidare skal det kunne knytast ein spesifikasjon av tryggingsgrad til dei enkelte opplysningane i kjelda. Det kan òg vera knytt merknader i fri tekst til innførslane, anten frå kjelda eller t.d. eigne merknader frå registrator.

2.2 Hendingar

Ei hending skal vera ei logisk eining med formål å representere ei personhending slik den er forklart framafor. Ei hending vil altså representere eitt enkelt menneske, nemnt med namn, knytt til ein innførsel i historisk kjeldemateriale.

Opplysningane i kvar enkelt tabell (datafil) i datamaterialet må tolkast som eller konverterast til hendingar. Dette kan gjerast på to måtar: anten må tabellane vera bygd opp slik at all nødvendig informasjon ligg i identifiserbare felt etter ein førehandsdefinert, eintydig standard, eller så må det setjast opp ein metatabell eller koplingstabell med informasjon om korleis dei ulike datatabellane skal tolkast eller omformast til hendingar. Metatabellen må definerast av brukaren i kvart enkelt høve, og vil representere ein metode for å hente ut data frå grunnlagsmaterialet og gjera dei tilgjengelege for resten av systemet.

Hendingane skal danne grunnlaget for oppretting av personar og relasjonane mellom dei. Kvar hending må innehalde data for hendingstype, tidspunkt og kjeldereferanse. Sentralt elles vil vera personnamn, kjønn, fødselstidspunkt, dødstidspunkt, føde- og dødsstad, bustadnamn osv. Ein del av opplysningane vil vera eksplisitt oppgjeve i kjelda (t.d. fødselsdato i ei dåpsliste), men svært ofte må ein indirekte finne verdiar (utrekna fødselstidspunkt på grunnlag av tidspunkt for hendinga og oppgjeve alder) eller ein må operere med omtrentlege verdiar (hendingstype jordfesting og tidspunkt for hendinga blir tolka som ein omtrentleg dødsdato).

Hendingane må vidare kunne innehalde data knytt til relasjonar mellom personar i kjeldematerialet, på ein eintydig måte. Dette gjeld fyrst og fremst biologiske relasjonar og ekteskapsrelasjonar, sjå nærare om dette seinare. Personrelasjonane kan beskrivast med absolutte referansar til andre personhendingar, saman med type relasjon etter eit førehandsdefinert sett. Mange av relasjonane vil vera implisitt gjeve i kjeldematerialet, t.d. rubrikkar for mor og far ved ein konfirmasjon. Det må elles vera mogleg å spesifisere fleire ulike relasjonar til andre personar i ei og same hending. Enkelte oppgjeve personrelasjonar i kjeldematerialet kan vera kompliserte, t.d. i folketeljingar, dødsbuskifte eller tingbøker («konens søsters dattersønn» o.l.). Men alle kompliserte relasjonar kan som regel brytast ned til kombinasjonar av dei enkle basisrelasjonane «mor–barn» og «far–barn» (ev. i tillegg til ein ekteskapsrelasjon). Problemet kan likevel vera at ein «manglar» opplysningar for ein eller fleire av personane (slektsledda), slik at referansar ikkje kan opprettast utan ein svært omfattande definisjon av relasjonstypar. I slike høve må relasjonane vera tilgjengelege for seinare kontroll av dei ferdig kopla personane i datasystemet.

I tillegg til spesialinformasjonen nemnt over, som må handterast i eigne felt i hendingsstrukturen, skal det for kvar hending vera mogleg å spesifisere eit vilkårleg utval frå resten av opplysningane i innførselen. Denne tilleggsinformasjonen skal kunne hentast inn etter behov i dei seinare arbeidsprosessane med datamaterialet.

2.3 Personar

Ein person (personeining) vil vera ei logisk eining med formål å representere eit menneske som kan påvisast gjennom personhendingar i kjeldematerialet, direkte eller indirekte. Personopplysningane skal dannast på grunnlag av data knytt til hendingar som gjeld personen. Prosessen med å knytte saman hendingar som gjeld ein og same person vil bli nemnt lenking. Det må elles vera mogleg å registrere ein person direkte i systemet utan lenking av eksisterande hendingar.

Ein person kan beskrivast vha sine karakteristiske data: namn, fødselstidspunkt, dødstidspunkt og kjønn. Desse kan i utgangspunktet reknast som statiske, livsvarige data for personen, sjølv om dødstidspunkt er udefinert for levande personar, og både namn og kjønn kan skiftast. Elles vil ein person i samband med fødsels- og dødstidspunktet òg vera knytt til ein fødestad og ein dødsstad. I tillegg kjem meir variable data som familie- og bustadtilknyting, samt personhistorie. Det kan vera nødvendig å konstruere personar som berre indirekte kan påvisast har levd ut frå kjeldematerialet (t.d. ut frå opplysningar om familietilhøve). Det må derfor vera mogleg å definere personar der alle statiske persondata er ukjente, men som har ein kjent relasjon til andre personar.

Eit fullt personnamn vil omfatte fornamn, mellomnamn (doble slektsnamn), patro- eller matronymikon (likestilling!) og slektsnamn. I tillegg kan ein person ha kallenamn (kjælenamn), tilnamn eller namnealias (t.d. «amerikansk» variant av skrivemåten for utvandrarar til USA). Identifikasjon av fornamn, mellomnamn og slektsnamn skal fylgje vanlege, norske namnereglar. Patro- eller matronymikonet (foreldretilnamnet) definerast ut frå fornamnet til ein av foreldra, med eit kjønnsavhengig suffiks som t.d. «son» eller «dotter», ev. forkortingar av desse. Foreldretilnamnet kan òg vera berre initialen i fornamnet til ein av foreldra. Foreldretilnamnet skal kunne vera dynamisk kopla, dvs. viss fornamnet på ein person endrast skal foreldretilnamnet på tilknytte barn ev. endrast automatisk i samsvar med dette. Kallenamn o.l. kan reknast som ein del av fornamn eller mellomnamn, og redigerast etter nærare bestemte reglar (t.d. ved bruk av parentes eller hermeteikn). Slektsnamnet vil i dei fleste tilfelle vera det namnet personen hadde før eit ev. ekteskap. Ved skifte av slektsnamn ut frå andre grunnar (har teke i bruk bustadnamn e.l.), kan det gamle namnet òg ev. reknast som ein del av slektsnamnet, ev. mellomnamnet, og redigerast etter nærare reglar (t.d. bruk av parentes). Forslag til fornamn, foreldretilnamn og slektsnamn skal ein få generert automatisk frå tilknytte hendingar og ev. reglar for namnestandardisering. Når det gjeld forslag til foreldretilnamn bør det vera mogleg å spesifisere eit tidspunkt for overgang frå fullt foreldretilnamn til bruk av initial. Det er elles verd å merke seg problemet med at patronymikon og slektsnamn kan vera like i forma (t.d. Hansen), men dette er fyrst og fremst eit tolkingsproblem knytt til kjelderegistreringa.

Fødsels- og dødstidspunkt skal definerast i samsvar med eit generelt tidspunkt framafor. Forslag til tidspunkta skal genererast frå tilknytte hendingar. Eit fødselstidspunkt må elles alltid vera påviseleg i kjeldematerialet, anten direkte (t.d. dåp) eller indirekte (aldersopplysning, t.d. ved folketeljing, vitne i rettssak e.l.). Eit indirekte fødselstidspunkt utrekna etter opplysning om alder skal spesifiserast som usikkert, t.d. ved å nytte prefikset «ca». Sjølv om fødselstidspunktet ikkje kan påvisast gjennom kjeldematerialet, kan det likevel vera nødvendig å rekne med eit sannsynleg intervall ut frå andre, sekundære opplysningar (alder på ungar, sysken e.l.). Dette vil vera tilfelle dersom ein t.d. ynskjer å sortere barna i ein familie etter fødselsår. Slike «fødselstidspunkt» utan direkte grunnlag i kjeldene skal handterast som eit separat tidspunkt berre for intern bruk i datasystemet.

Føde- og dødsstaden til ein person skal representerast berre gjennom namnet på staden. Opplysningane skal genererast frå tilknytte hendingar, ev. etter nærare definerte reglar for namnestandardisering. Det er elles svært viktig å merke seg at føde- og dødsstad ikkje treng vera nokon konkret, kjent bustad i samsvar med den definerte bustadstrukturen. Den fysiske fødestaden eller dødsstaden til ein person vil vera statiske data, ei nemning av den staden familien eller personen tilfeldigvis oppheldt seg da hendinga skjedde. Omgrepet fødestad til ein person har ut frå dette ingenting å gjera med det systemet for tilvisingar person–bustad som skal genererast.

Eit menneske vil alltid vera knytt til ein opphavsfamilie, ut frå biologiske relasjonar. I tillegg kan det vera knytt til eit variabelt tal andre familiar gjennom juridiske eller biologiske relasjonar (t.d. ekteskap, foreldre til barn, adoptivtilhøve osv). Personar i dataregisteret kan ikkje alltid knytast til nokon definert opphavsfamilie. Dette gjeld både dei som er «ukjente», dvs. som har eit fullstendig ukjent opphav, og dei som har opphavet sitt utanfor det området som skal beskrivast gjennom bustadstrukturen. Personar må kunne kategoriserast på type opphav, for å finne utval av «ukjente», «innflyttarar» osv.

Ein person vil gjennom sin opphavsfamilie vera knytt til ein opphavsstad eller foreldrebustad, definert som hovudbustaden til den eine av foreldra (eller båe viss dei hadde felles bustad). Viss denne opphavsstaden kan finnast mellom dei registrerte bustadene, skal det automatisk genererast ei tilvising som dannar grunnlaget for å rekke slektsliner bakover i tid (anelister), på tvers av bustadstrukturen. Sidan foreldra til ein person kan ha kvar sin hovudbustad, vil det vera nødvendig å eksplisitt knytte opphavsstaden til den eine av dei. Viss relasjonen til foreldra er usikker skal dette reflekterast i den genererte tilvisinga til opphavsstad. Det kan gjerast ved å gradere kor sannsynleg det er at relasjonen er korrekt, t.d. ved å nytte uttrykk som «truleg», «kanskje» e.l.

Eit spesialtilfelle av opphavsstad og –familie har vi når ein person er «innflyttar», men samstundes er knytt til ein opphavsfamilie der ein eller båe av foreldra har sin opphavsstad i den definerte bustadstrukturen, ev. at opphavsfamilien sjølv er knytt til ein definert bustad men personen er født etter dei flytte frå staden. I slike høve bør det vera mogleg å få generert indirekte tilvisingar, slik at slektslinene kan rekkjast.

Ein person kan som «hovudperson» vera knytt til ein eller fleire definerte bustader. Dei ulike bustadene dannar grunnlaget for automatisk generering av tilvising slik at slektsliner kan rekkjast framover i tid (etterkomarar), på tvers av bustadstrukturen. Personar i dataregisteret kan ikkje alltid knytast til nokon definert bustad. Dette gjeld t.d. barn som døydde før dei rakk å etablere eige hushald, utflyttarar, dei med ukjent livshistorie osv. Personar må kunne kategoriserast på type livsløp (eller bustadtilknyting), for å finne utval av «utflyttarar», «USA-emigrantar», «ukjente» o.l. Elles bør det som nemnt under opphavsstad framafor vera mogleg å generere indirekte tilvisingar, og usikre relasjonar må koma fram i tilvisinga.

Kvar person har si eiga historie, som fortel noko om livet til personen i eit tidsperspektiv. Alle hendingane som er knytt til personen dannar basis for dei strukturerte opplysningane nemnt over (persondata, familietilknyting, opphavsstad, bustader osv), og gjev grunnlaget for å produsere ei skjematisk livshistorie. Kor fullstendig denne blir avheng da av kjeldetilgangen, og kva som ev. er dataregistrert. Det vil derfor vera behov for kompletterande opplysningar i form av fri tekst, merknader, til ein person. Ei slik historie kan da nyttast for å skrive eit samandrag av livshistoria i meir «litterær» form. Dette vil spesielt vera viktig for alle som ikkje er knytt til ein eigen definert bustad («utvandrarar», utflytte barn o.l.), eller generelt dei personane det finst tilleggsopplysningar om utan at desse er registrert i systemet med hendingar.

I tillegg til personhistoria kan det vera behov for å knytte ein person til eksterne data eller kjelder utanom dei registrerte hendingane. Dette vil som oftast skje i form av referansar til anna stoff som omhandlar personen (artiklar, andre bygdebøker, biografiar o.l.), medrekna hyperkopling til e-postmeldingar eller andre tekstdokument. Det bør òg vera mogleg å referere til bilete, lyd (intervju med personen) m.m., gjerne i form av hyperkoplingar til andre databasar e.l.

2.4 Personrelasjonar

Familie: familien til ein person er tradisjonelt definert ut frå biologiske relasjonar, og eit institusjonalisert ekteskap (kjernefamilie). Opphavet til omgrepet familie er rett nok mykje meir omfattande, og tilsvarer omtrent det som i dag oppfattast med hushald. I denne samanhengen vil det likevel vera enklast å la familieomgrepet stå for følgjande tilhøve: einsleg mor med barn ; einsleg far med barn ; mann og kvinne i ekteskap med eller utan barn. For den vidare definisjonen av relasjonar mellom personar er ikkje familie som omgrep godt nok dekkande.

2.4.1 Biologiske relasjonar

Ein biologisk relasjon skal berre omfatte tilhøvet far–barn eller mor–barn. Det vil vera opp til den enkelte om adoptivtilhøve skal definerast som ein variant av biologiske relasjonar, men primært bør desse kanskje handterast på anna vis (i alle fall der det biologiske opphavet er kjent og oppgjeve i kjeldene).

Biologiske relasjonar må sjåast i samanheng med dei meir generelle partnerrelasjonane nedafor. Det vil vera eit absolutt krav at ein biologisk relasjon òg må ha ein tilsvarande partnerrelasjon mellom foreldra, uavhengig av juridiske tilhøve eller om dei hadde felles bustad. Til saman skal denne trekantstrukturen far–barn, mor–barn og far–mor danne eit konsistent sett med relasjonar mellom personane. Dette medfører at ein etablert relasjon far–mor ikkje kan brytast utan samstundes å kutte anten far–barn eller mor–barn relasjonen, for kvart av dei felles barna. På same viset vil oppretting av ein relasjon far–barn der barnet alt har etablert relasjon til mor, medføre at det må opprettast ein relasjon far–mor (og tilsvarande for mor–barn relasjon). Vi kan elles merke oss at desse tilhøva gjeld sjølv om «far», ev. «mor», er ukjente personar – dei vil likevel kunne representerast i systemet med ei «dummy» personeining – dvs utan at alle persondata som namn, fødselstidspunkt osv er kjent.

Prosessen med å opprette dei biologiske relasjonane til ein person (far, mor og eigne barn) vil bli nemnt kopling av personar. Denne prosessen omfattar òg partnerrelasjonar, sjå neste punkt. Kopling av personar skal kunne skje automatisk på grunnlag av dei tilknytte hendingane til personane. Det må vera mogleg å representere relasjonar med ulike grader av kor sikre dei er. Kvar oppretta relasjon bør ha ein spesifikasjon av kva grunnlag relasjonen er bygd på – eksplisitt gjevne personrelasjonar i materialet, indirekte opplysningar i sekundært kjeldemateriale, intuisjon frå brukaren o.l. Dette vil gje eit betre grunnlag for å etterprøve kvaliteten av dei etablerte strukturane. Dette vil òg gjelde partnerrelasjonar, sjå nedafor. Elles må det sjølvsagt vera mogleg å opprette koplingar mellom personar manuelt.

2.4.2 Partnerrelasjonar

Ein partnerrelasjon vil i vidaste forstand omfatte to personar som har eitt eller annan nærare definert tilhøve seg i mellom. Det vil likevel vera naturleg å avgrense ein partnerrelasjon til det å representere eit tilhøve mellom to «likeverdige» partnerar, dvs. primært ektefellar, sambuarar osv. Føresetnaden for å definere ein partnerrelasjon mellom to personar vil da bli at dei har eit formelt, juridisk tilhøve seg i mellom; at dei har eit direkte eller indirekte tilhøve ut frå kjente biologiske relasjonar; og/eller at dei i ein viss periode har delt felles bustad og kan beskrivast samla med meir eller mindre felles livshistorie.

Ein partnerrelasjon må ha referanse til ein eller to oppretta personar i systemet, med definert relasjonstype (t.d. ekteskap) og tilhøyrande starttidspunkt for relasjonen. Det er viktig å merke seg at ein partnerrelasjon kan ha referanse berre til ein person (sjølv om nemninga da blir noko misvisande). Dette vil vera tilfelle når biologiske relasjonar er kjent, men partneren ikkje er nemnt i kjeldene. Sidan partnerrelasjonane blir eitt av bindeleda mellom enkeltpersonar og bustader må det òg vera mogleg å handtere einslege i systemet.

For kvar av personane i partnerrelasjonen skal det vera mogleg å finne referanse til ev. førre og neste partnerrelasjon som personen er knytt til. På grunnlag av dette kan ein få generert tilvisingar på tvers av bustadstrukturen, t.d. der oppattgifting samstundes inneber at personen flytter bustad. Likeins må kvar av partnerane ha referanse til sin hovudbustad i samband med denne bestemte partnerrelasjonen. Dette vil danne basis for kvar dei fulle personopplysningane skal handsamast i samband med utskrifter og rapportar. Dei to personane i relasjonen kan ha kvar sin hovudbustad, dvs. dei har ikkje budd på same staden.

På same viset som dei biologiske relasjonane skal partnerrelasjonane dannast på grunnlag av tilknytte hendingar til personane (kopling), og usikre relasjonar må kunne spesifiserast. Grunnlaget for etablering av relasjonen bør kunne spesifiserast. Det vil vera nødvendig å opprette ein del partnerrelasjonar manuelt, spesielt frå nyare tid sidan formelle ekteskap ikkje lenger er einerådande.

Som ein ser vil partnerrelasjonane danne kjernen i den strukturen som skal byggast opp av tilhøve mellom enkeltpersonar. Ein partnerrelasjon kan ha tilhøyrande biologiske relasjonar, og dermed representere ein familie. Ser vi personrelasjonane i samanheng med bustadstrukturen får vi dermed følgjande kategoriar:

partnerrelasjon	bustadtilhøve	biologisk relasjon
einsleg person (ukjent partner)	kjent bustad	med eller utan barn
einsleg person (ukjent partner)	ukjent bustad	med barn
partnerar	same bustad	med eller utan felles barn
partnerar	ulik bustad	med eller utan felles barn

Merknad: det vil vera irrelevant å opprette ein partnerrelasjon for ein einsleg person utan barn og med ukjent bustad. Partnerar med ulik bustad omfattar tilfelle der den eine eller båe har ukjente bustader. Partnerar med ulik bustad og utan felles barn er eigentleg ulogisk, men i denne kategorien finn vi dei som er gift, men ikkje har budd saman i tilknyting til den etablerte bustadstrukturen (utflytte personar, emigrantar, dei med ukjent bustad osv).

2.5 Persongrupper

Ei persongruppe kan definerast som ei logisk eining med formål å samle partnerrelasjonar (som òg omfattar enkeltpersonar!) som naturleg høyrer saman. Dette vil primært dreie seg om personar som over ei viss periode har hatt same bustad og kan beskrivast med ei felles «historie». Dei fleste persongruppene kan dermed assosierast med ein «kjernefamilie» eller eit «hushald» på eit bestemt tidspunkt. Men persongruppene vil òg omfatte oppattgifting (fleire partnerrelasjonar), og vi finn grupper som kan bestå av t.d. fleire heimeverande sysken som driv ein husmannsplass saman, eller ei tenestjente i lag med den uekte sonen ho fekk. Persongruppene blir dermed ein måte å samle personar i systemet på slik at dei som har ein viss grad av felles livshistorier eller livsløp kan få felles omtale og presentasjon. Også meir spesielle tilhøve kan handterast, t.d. vil alle ukjente tenestdrengar nemnt i manntalet 1664 under ein namnegard kunne samlast i ei felles gruppe.

Persongruppene vil primært fungere som ei strukturering og sortering av personopplysningar i tidsperspektiv under kvar bustad. I samband med tilvisingar person–bustad må det vera mogleg å generere ei automatisk nummerering av gruppene under kvar bustad (eigentleg kvar bustaddel, sjå nærare om dette nedafor). Nummereringa skal i hovudsak gå fortløpande frå 1 og oppover etter rekkefylgja på gruppene, men med visse modifikasjonar. Persongruppene kan delast i primær- og sekundærgrupper. Sekundærgruppene vil bli nummerert som føregåande gruppe, men med bokstavtillegg «b», «c», «d» osv. Sekundær- eller tilleggsgruppene kan fyrst og fremst nyttast til å representere innerstfamiliar, tenestfolk, heimeverande sysken til brukaren med «eige hushald» o.l. Primærgruppene kan vidare spesifiserast som parallelle eller samtidige, når bustaden har to eller fleire primær- eller brukargrupper samstundes, t.d. to sysken med kvar sine hushald som for ei kortare periode driv kvar sin del av garden. Dei parallelle eller samtidige primærgruppene vil bli nummerert med bokstavtillegg på same viset som sekundærgruppene, bortsett frå det fyrste i ein serie av parallelle grupper som får auka nummeret med 1 i høve til førre gruppe, og med bokstavtillegget «a».

Kvar persongruppe skal knytast til ei tidsperiode i samsvar med definisjonen av tidsdata framafor, men tidsperioden kan vera udefinert (tom). I tilknyting til nummer og tidsperiode skal det vera mogleg å ha ei ledetekst eller forklarande tillegg, som nyttast ved utredigering av opplysningane om gruppa.

Til kvar persongruppe skal det vera mogleg å knytte eit vilkårleg tal partnerrelasjonar (som òg omfattar einslege personar!). Kvar partnerrelasjon må ha referansar til ev. førre og neste persongruppe denne bestemte relasjonen er knytt til, slik at eit meir eller mindre fullstendig flyttemønster på tvers av bustadstrukturen kan beskrivast med tilvisingar. Kvar partnerrelasjon vil i tillegg ha ei eigen historie, dvs. ei felles beskriving av tilhøve knytt til personane i relasjonen spesifikt for kvar enkelt persongruppe relasjonen er knytt til. På dette viset kan ein til kvar enkelt partnerrelasjon ha ei omfattande felles «familiehistorie» knytt til hovudbustaden for personane (dvs. der alle fulle personopplysningar blir utlista), medan dei andre stadene relasjonen er knytt til berre har kortfatta opplysningar på stikkordsform i tillegg til flytteinformasjonen.

nr	tidsperiode	ledetekst
1	Ca 1719 – ca 1748	Den gamle Nørdre nedre-garden
2a	Ca 1748 – 1772	Nørdre nedre
2b	1754 – 1772	Del av Nørdre nedre
…
4a	1808 – 1826/35	Nedre
4b	1793 – ca 1834	Midtre. Fleire brukarar
…
6	1841 – 1856	Del av Nedre
6b

Eksempel: nummerering, tilhøyrande tidsperiode og ledetekst for persongrupper under garden Nørdre Bjorlie i Lesja.

2.6 Bustader

Ein bustad vil i vidaste forstand vera ei logisk eining med formål å samle persongrupper som naturleg høyrer saman, anten gjennom same geografiske tilknyting eller med felles historie.

Ein bustad vil dermed som oftast vera eit hus som kan lokaliserast i terrenget, der det er eller har vore kjent busetting. Men ein bustad kan òg vera konstruert for å samle persongrupper (medrekna enkeltpersonar) som har eit historisk påviseleg eller logisk fellesskap, t.d. «Ukjente/uplasserte» under ein namnegard eller «Tenestfolk i Prestgarden». Ein bustad treng altså ikkje representere ein verkeleg, fysisk stad. Det vil heller ikkje vera slik at ein alltid kan påvise bustaden i terrenget, og det treng heller ikkje vera konkrete, kjente personar som kan knytast til bustaden.

Grunneigedom: matrikkelbruk, juridisk eining med eige blad i grunnboka. Identifiserast vha. eintydig gardsnr, bruksnr og festenr (ev. fylke- og kommunenr). Grunneigedomar som eksisterte i tida 1838–86 kan identifiserast vha. eit eintydig matrikkel- og løpenr innan kvart tinglag, prestegjeld, sokn osv. For tida før 1838 finst ikkje slik eintydig identifikasjon. Det vil til ein viss grad kunne nyttast eldre matrikkelnummer for identifisering, men i dei fleste høve må ein basere seg på gardsnamn og skyldstorleik.

Umatrikulert grunn: grunn nytta til nærare definert bruk, t.d. jord- og skogbruk, bustad, hytte osv, men som ikkje er skyldsett og matrikulert. Men det er ikkje noko i vegen for at umatrikulert grunn kan ha vore kjøpt til sjølveige. Ein søkjer her mindre grunnområde som kan oppfattast som ei historisk eining, men må ikkje blandast saman med eit geografisk område. Umatrikulert grunn kan identifiserast berre med meir eller mindre eintydige namn.

Eigareining: eigarsortert listing av grunneigedomar og ev. umatrikulert grunn, dvs. alle eigedomar som tilhøyrer ein og same eigar. Ein eigedom kan ha ein eller fleire eigarar på same tid, kvar med sin ideelle part.

Brukseigedom: eigareining som er nytta til nærare definert bruk og som kan reknast for ei sjølvstendig eining. Identifiserast med eit hovudnr som skal vera identisk med eigedomsnr til den grunneigedomen som historisk sett mest korrekt kan knytast til brukssenteret. Viss dette er uråd å finne må ein sekundært velja eigedomsnr tilhøyrande den største grunneigedomen, lågaste eigedomsnr e.l., etter nærare reglar (redigering av hovudnr). Ein brukseigedom vil vera samansett av ein eller fleire grunneigedomar. Elles må ein for tidlegare tider i stor grad sjå på brukareining i staden for brukseigedomar (pga. store godseigarar, kyrkjegods, krongods o.l.). Ei rein eigedomssamling er som regel ikkje interessant i denne samanhengen.

Brukareining: eining basert på nærare definert bruk der ev. jordleige er medrekna, også forpakting, felles bruk, bygsling o.l. Identifiserast med hovudnr på brukseigedomen der driftssenteret ligg, sekundært den med størst bruksareal, etter kva som er mest korrekt historisk sett. Ei brukareining kan omfatte ein eller fleire brukseigedomar, eller deler av desse, og/eller andre grunneigedomar. Ei brukareining kan også omfatte umatrikulert grunn, eller grunn som ikkje er i sjølveige. Dette medfører at t.d. leiglendingsbruk, bygslingsplassar, nyrydningar på stats-, ålmenning- eller sameigegrunn, husmannsplassar o.l. kan reknast til ei brukareining. Ei brukareining kan dermed godt vera basert på umatrikulert grunn (t.d. ein husmannsplass), men i tillegg omfatte skyldsette, sjølveigande brukseigedomar.

2.6.1 Eigedomar

Ein eigedom vil representere ei eining som samsvarer med definisjonen av grunneigedomar over: ein frådelt, matrikulert grunneigedom, punktfeste o.a., som det kan knytast ulike data til, t.d. gards-, bruks-, matrikkel-, løpenr, skyld, frådelings-, samanføyingsopplysningar osv. Ein eigedom vil dermed vera definert ut frå matriklane, grunnbok e.l., og vil representere den minste oppdelinga av ein matrikkelgard.

Ein eigedom kan vera knytt til andre eigedomar i samband med frådeling, oppdeling og samanslåing. Ein eigedom vil ha eit starttidspunkt definert t.d. ved frådeling eller skyldsetting, og ev. eit sluttidspunkt definert ved samanføying, oppdeling, sletting e.l. Eigedomen kan òg ha endra skyldtilhøve over tid i samband med påslag, avtak eller matrikkelrevisjonar.

Ein eigedom kan ut frå definisjonane over også vera umatrikulert grunn kjøpt til sjølveige. Men slike eigedomar er ikkje knytt til matrikkelsystemet på nokon måte (korkje nummer eller skyld). Desse bør derfor handterast på anna vis for ikkje å komplisere unødig (bør definerast som eit bruk).

Som nemnt tidlegare må ein eigedom identifiserast vha. eintydig nummer: gamalt gardsnr, matrikkelnr, løpenr, gardsnr, bruksnr, festenr osv. Det må i tillegg opnast for identifikasjon på fylkes- og kommunenivå, og ev. tilsvarande for amt, fogderi, tinglag, prestegjeld, sokn o.l. i eldre tid – i den grad det vil vera behov for å handsame materiale frå fleire område samstundes. Ein må elles merke seg at dei ulike numra knytt til ein eigedom ikkje treng vera konstante over tid. Dette gjeld m.a. løpenr som kan få ulike tillegg som «a», «b», «a1» osv ved frådelingar i perioden 1838–86. Vidare kan ein få endra nummersystem ved deling / samanslåing av herad m.m. Kvart av dei ulike nummersystema er elles avgrensa til bestemte tidsperiodar, i samband med matrikkelrevisjonane.

Matrikkeldata omfattar elles fyrst og fremst endringar i skyldtilhøva: skyldsetting, frådeling, samanføying, påslag og avtak i skyld osv. Ei skyldendring som t.d. frådeling vil eigentleg omfatte to eigedomar, som får same absolutte skyldendring men med motsett forteikn. Ved ei matrikkelendring som omfattar to eigedomar må det vera mogleg å opprette ein referanse frå den eine eigedomen til den andre. På same viset som med eigedomsnummer vil det elles eksistere ulike skyldsystem knytt til bestemte tidsperiodar.

Matrikkelendringar knytt til ein bestemt eigedom må oppsummerast på ein oversiktleg måte (matrikkelhistorie). Vidare må det vera mogleg å summere opp heile eller utdrag av matrikkelhistoriene for ei vilkårleg samling av eigedomar, sjå nærare om dette under bruk og område.

2.6.2 Bruk

Eit bruk vil representere ei eining som er samanfallande med definisjonen av både brukseigedom og brukareining over, avhengig av eigartilhøva m.m. Eit bruk må i denne samanhengen ikkje forståast som eit «gardsbruk» – sjølv om det òg kan vera nettopp det. Eit bruk vil som oftast beskrive ein kjent, fysisk bustad (bygard, einebustad, gardsbruk osv). Men eit bruk må òg nyttast for å handtere einingar som ein ynskjer å definere sjølvstendig utan at det er knytt busetnad til staden (eks. slåtteland, skogeigedomar, forretningsbygg o.l.).

Eit bruk kan omfatte ingen, ein eller fleire grunneigedomar, og skal vise oppsummerte matrikkeldata frå ev. tilknytte eigedomar. Heile eller delar av eit bruk vil òg kunne vera umatrikulert grunn. Eit bruk må vera knytt til (ligge under) eit geografisk område, sjå nedafor.

hending	skyld	nummer
Gammal skyld	4 alner vadmål
Pålagt 1684	1 ½ skinn
Revidert 1838	2 daler 3 ort 4 skilling	matr.nr 102, løpenr 195
Attåtlagt 1843 (frå Nordistugu)	1 daler 32 skilling	løpenr 194b
Attåtlagt 1861 (frå Nordistugu)	1 daler 2 ort 14 skilling	løpenr 194a
Revidert 1888	9 mark 53 øre	gardsnr 109 bruksnr 1

Eksempel: oppsummert matrikkelhistorie for Systugu Hattrem i Lesja, der grannebruket Nordistugu Hattrem vart slått saman med Systugu på 1800-talet.

hending	skyld	nummer
Skylddelt 1933 (frå Prestgarden)	6 øre	gardsnr 102 bruksnr 24
Attåtlagt 1954 (frå Tømmerbakken, Åsen)	8 øre	gardsnr 100 bruksnr 22
Attåtlagt 1960 (frå Prestgarden)	12 øre	gardsnr 102 bruksnr 36
Attåtlagt 1966 (frå Sørpå Tande)	3 øre	gardsnr 104 bruksnr 29
Attåtlagt 1971 (frå Randen, Tande)	1 øre	gardsnr 104 bruksnr 40

Eksempel: matrikkelhistorie for bureisingsbruket Åsheim i Lesja, som etter kvart omfattar mange eigedomar.

Det vil vera nødvendig å handtere omfattande, strukturerte namnedata (stadnamn). Eit bruk kan ev. ha fleire alternative, likeverdige «hovudnamn» eller bruksnamn. Det vil òg vera nødvendig med eigne namneformer som skal nyttast i samband med tilvisingar person–bustad. Tilvisingane skal knytast til bestemte tidsperiodar, for å handtere namneskifte – formelle (t.d. namneendring ved skyldsetting) eller uformelle (t.d. etter ei flytting av gardstun). Tidsperiodane kan ikkje overlappe kvarandre, og det må vera definert tilvisingsformer for heile den perioden bustaden har eksistert. Skal ein sikre seg at alle personar knytt til same persongruppe skal ha same tilvisinga, kan ikkje tidspunktet for namneskifte utan vidare setjast lik det reelle tidspunktet da namnebytet verkeleg skjedde. Ut frå bruksnamn og namn på det området bruket er tilknytt kan det genererast eit automatisk tilvisingsnamn, etter nærare bestemt format. I svært mange tilfelle må likevel namneformene for tilvising spesifiserast manuelt av brukaren, t.d. der områdenamnet inngår som eit element i bruksnamnet. Sortering alfabetisk på bruksnamn kan vera nødvendig i samband med presentasjon av registrert materiale. Det må derfor vera mogleg å registrere eigne sorteringsformer av namna, i tilfelle det er ynskjeleg at desse avvik frå normal skrivemåte (t.d. Søre Rolstad sortert som Rolstad, søre). Det skal òg vera mogleg å handtere andre strukturerte data i tilknyting til namna, t.d. matrikkelnamn (grunnboksnamn), uttaleformer, preposisjonsbruk, dativformer m.m.

For bruk med kjent busetting vil det vera aktuelt å spesifisere eigne bustaddelar – t.d. leilegheiter i eit større bygningskompleks, «kvistrom» i einebustad, eldhuset på ein gard osv. Persongrupper må knytast til kvar enkelt bustaddel. Bustaddelane skal i utgangspunktet ikkje ha eit eige namn tilsvarande bruksnamn e.l., men det skal nyttast enkle nemningar. Det vil elles vera aktuelt å nytte fleire bustaddelar berre der ein har behov for finare inndeling av enkelte bustader, utan at omfanget blir for stort.

Det skal vera mogleg å generere ei automatisk nummerering av bruk (bustader) i samband med tilvisingar person–bustad. Nummereringa skal skje fortløpande frå 1 og oppover etter rekkefylgja på dei bruka som er tilknytt eit bestemt område. Ved ei automatisk nummerering skal bustaddelane nummererast som underpunkt til kvart enkelt bustadnr, dvs. leilegheit nr 3 i bustad nr 5 under eit område skal ha ei tilvising som inneheld referansen 5.3. Nummereringa skal skje i høve til rekkefylgja på bustaddelane under det bestemte bruket.

bustad nr namn	bustaddel nr nemning	persongruppe nr	tilvising fyrste persongruppe
1 Hovudbruket (Nordistugu)		1, 2, … 19	Sili (1-1)
2 Silibakken		1, 1b, 2, … 10	Silibakken (2-1)
…
16 Blåbrakka	1 Søre leilegheit 2 Nørdre leilegheit	1, 2, 3, … 8 1, 2, … 4	Blåbrakka, Sili (16.1-1) Blåbrakka, Sili (16.2-1)
17 Karlstad	1 Søre leilegheit 2 Nørdre leilegheit	1, 2 1a, 1b, 2	Karlstad, Sili (17.1-1) Karlstad, Sili (17.2-1a)
…
29 Ukjente/uplasserte		1, 2, … 3c	Ukjente, Sili (29-1)

Eksempel: nummerering og tilvising til bustader med og utan fleire bustaddelar, under namnegarden Sili i Lesja.

Det kan vera behov for å strukturere andre hendingar enn dei formelle eigedomsopplysningane (matrikkeldata) knytt til eit bruk. Dette kan t.d. dreie seg om tidspunkt for rydding, busetting, kjøp til sjølveige osv. Det vil òg vera naturleg å knytte andre, eksterne data til eit bruk, t.d. brukshistorie (tekstdokument), kartdata, bilete, lyd (uttale av namn) m.m., gjerne i form av hyperkoplingar til andre databasar e.l.

2.6.3 Område

Eit område vil representere større geografiske (ev. logiske) einingar utover det ein forstår med eit bruk. Det kan vera alt frå kommunar, sokn, bygder, grender, ålmenningar osv ned til kvar einskild namnegard, bydel, gate e.l. I prinsippet kan òg t.d. kvart enkelt bind i ein bygdebokserie definerast som eit «område».

Eit område kan vera inndelt i (omfatte) andre område, og/eller bruk og eigedomar. Områda vil danne grunnlaget når ein skal bygge opp ein logisk bustadstruktur på fleire nivå. Ein djupne-fyrst gjennomgang av strukturen skal gje disposisjonen for utlisting av aktuelle data. Dette medfører at opplysningar knytt til eit element i strukturen skal handsamast ved fyrste «besøk» i gjennomgangen, før ein går vidare til ev. underliggande element. Nytta på figuren nedafor vil da utlistinga t.d. bli disponert slik: ..., Kyrkjebygde, Avdem, Stor-Avdem, Avdemshaugen, ..., Ukjente/uplasserte u. Avdem, Tynnøl, Lia, ..., Bøgrende, ...

Områda på lågaste nivå blir vanlegvis namnegardane, eller den eininga som skal tene som ei samling av bruk og eigedomar med felles historie. Den hierarkiske strukturen vil ofte kunne definerast slik at ein får namnegardane på same nivå gjennomgåande i det materialet som skal handsamast. Det vil likevel vera tilfelle der ein ynskjer ei finare inndeling på deler av materialet – t.d. der ein skal definere fleire større tettstader og spreidd busetnad i same strukturen. Ut frå dette må tilvisingssystemet person–bustad gjerast uavhengig av namnegardsnivået.

Illustrasjon: bustadstruktur for eit tradisjonelt bygdeområde, med grendenivå, namnegardsnivå og bruks/bustadnivå.

Det skal for eit område vera mogleg å summere opp eit utval av matrikkeldata frå ei vilkårleg samling av bruk og eigedomar. Dette vil vera aktuelt fyrst og fremst for «reine» namnegardar. Eksempelvis vil ein for ein namnegard ynskje å summere opp data knytt berre til matrikkelrevisjonane, ikkje oppdelingar og samanslåingar innan namnegarden. Det må òg vera mogleg å summere opp data knytt berre til ein bestemt namnegard, medan ev. sal og kjøp av eigedomar på bruksnivå mellom ulike namnegardar ikkje blir reflektert. I mange høve vil det òg vera ynskjeleg å registrere eigedomar berre av ein viss storleik eller type i samband med frådelingar etc., t.d. at ein ser bort frå mindre skogteigar, tomter m.m. Det vil òg oppstå situasjonar der bruka / eigedomane er logisk plassert under ein namnegard (område) i bustadstrukturen, medan dei fysisk er frådelt ein eller fleire andre namnegardar. Det vil derfor ikkje vera nokon automatikk i at matrikkelopplysningane skal summerast opp i samsvar med den oppbygde bustadstrukturen.

hending	skyld	nummer
Gammal skyld	5 huder 12 alner vadmål
Pålagt 1684	3 skinn
Revidert 1838	14 daler 14 skilling	matr.nr 102–103, løpenr 194–198
Revidert 1888	23 mark 19 øre	gardsnr 109 bruksnr 1–2, gardsnr 110 bruksnr 1–2

Eksempel: den oppsummerte matrikkelhistoria for namnegarden Hattrem i Lesja.

Eit område må ha strukturerte namnedata, sjølv om dei ikkje blir like omfattande som på bruksnivå. På same viset som for bruka vil det òg vera naturleg å knytte enkelte eksterne data til eit område – historie (tekst) osv.

3 Registrering av kjeldemateriale

3.1 Formål og verkemåte

Datasystemet skal innehalde ein modul for registrering av relevant kjeldemateriale, dvs. personhistoriske kjeldehendingar, jf 2.1. Prinsippet for registreringa blir å nytte elektroniske skjema tilpassa dei enkelte kjeldetypane. Eit skjema vil bestå av eitt eller fleire skjermbilete inndelt i felt for registrering av dei ulike opplysningane i ein innførsel. Sjølve registreringa skal skje etter nærare definerte krav, sjå nedafor.

Registrering av ein innførsel resulterer i ein tilsvarande datapost, som vil ha eit tabellarisk lagringsformat avhengig av kva slags databasesystem e.l. som nyttast. Det er verd å merke seg at den interne representasjonen av ein «datapost» ikkje nødvendigvis tilsvarer ei enkelt rad i ein bestemt tabell lagra i ei bestemt datafil, men heller består av ei logisk eining av enkeltpostar i fleire ulike tabellar, som til saman dannar eit heilskapleg bilete av den opphavlege innførselen i kjeldematerialet. Registreringsskjemaet vil dermed fungere som eit vindu (eller «view») mot datamaterialet, og dannar bindeleddet mellom kjeldematerialet og det elektroniske motstykket.

Modulen må innehalde funksjonar og kommandoar for val av skjematype, oppretting av nye eller opning av eksisterande tabellar («datafiler») knytt til dei enkelte skjema, og lagring av registrerte data. I tillegg til registreringsskjemaet skal modulen kunne presentere ei liste over postane (innhaldet) i kvar enkelt tabell, sortert etter ulike kriterium som dato, personnamn, bustadnamn osv. Brukaren skal kunne operere i skjema og lister med bruk av mus, piltastar og tastaturkommandoar, i samsvar med innarbeidde «standardar» eller praksis i vanlege dataprogram.

Nokre av kjeldetypane har så omfattande opplysningar at ein med fordel kan dele opp registreringsskjemaet i fleire skjermbilete, som «underskjema» eller dialogar. Dei ulike opplysningane bør da grupperast slik at dei som logisk høyrer saman blir samla i eitt underskjema, som hentast fram ved behov. Dei ulike skjema bør elles utformast slik at brukaren sjølv til ei kvar tid kan sperre eller frigjeva kvart enkelt felt for skriving (bortsett frå dei obligatoriske nøkkelfelta), slik at ein unngår å «trykke» seg gjennom ein lang serie med tomme felt. Dette vil spesielt vera ein fordel der ei kjelde varierer sterkt over tid med omsyn til kor omfattande opplysningane er, eller der ein vel å ikkje registrere enkelte opplysningar i det heile, som t.d. fadrar ved dåp.

Det kan elles setjast opp ein del generelle krav til registreringsmodulen, og dei enkelte skjematypane:

(a) kvar innførsel som blir registrert må ha eintydig referanse til det opphavlege kjeldematerialet.

(b) det må vera mogleg å registrere alle opplysningane i det opphavlege kjeldematerialet, og så mange som mogleg i eigne felt. Det må her vurderast kva som er praktisk mogleg, sjå nedafor.

(c) datamaterialet skal vera ei bokstavrett attgjeving av originalkjelda. Opplysningar gjeve i kjeldematerialet skal derfor ikkje standardiserast eller kodast under registreringa. Men dette hindrar ikkje at ein under registreringa samstundes kan foreta koding av opplysningar i eigne tilleggsfelt, ut frå praktiske omsyn.

(d) det må vera mogleg å registrere opplysningar som inneheld overstrykingar, som er usikre eller inneheld openberre feil. Det må vera mogleg å registrere både gamle og nye verdiar i kjelda, t.d. ved overstrykingar.

(e) merknader skal kunne registrerast etter behov, både merknader gjort i kjeldene og registratorens eigne kommentarar.

(f) det må vera mogleg å ta vare på eintydige relasjonar mellom personar som ikkje blir registrert i same datapost, eller personar i same post som har relasjonar utover dei som er eksplisitt gjeve.

Ut frå desse krava vil det vera naturleg at det aller meste av registreringsarbeidet baserast på prinsippa gjeve i standarden «Histform» for registrering og utveksling av data frå folketeljingane 1865 og framover (initiert av Landslaget for lokalhistorie), samt «Standard 4G» for dataregistrering av kyrkjebøker, utarbeidd av Samarbeidsrådet for historielaga i Oppland. Dette medfører t.d. at krav (d) i lista over blir tilfredsstilt ved å nytte spesialteikn som ??, !!, %%, @@ osv i dei enkelte datafelta, for å markere usikre, feilaktige eller manglande verdiar, overstrykingar, alternative verdiar osv, saman med bruk av merknadsfelt for å gje utfyllande kommentarar der det er nødvendig. Det er dessutan starta opp arbeid med å systematisere og detaljere kyrkjebøkene som kjelde, med tanke på ein tilsvarande standard som Histform (ref. G. Thorvaldsen, L. Nygaard mfl).

3.2 Registreringsmetodar

Krava (a–f) som er oppstilt ovanfor gjeld fyrst og fremst registrering av historiske primærkjelder, som kyrkjebøker, folketeljingar, skattelister osv. Det som kjenneteiknar dei fleste av desse, er at dei har ein «flat» struktur på personnivå, dvs. materialet er ikkje kopla. Ein finn rett nok delvis kopla materiale i t.d. folketeljingane og arveskifta – som har relativt omfattande personrelasjonar – men berre for personar innan kvar hovud- eller bustadpost. Det vil derfor vera nødvendig å registrere alle slike kjelder i eit «statisk» grunnlagsmateriale for vidare behandling i prosessane med lenking og kopling. Denne metoden vil i det vidare nemnast registrering på kjeldenivå.

Vi har òg ein del nyare kjeldemateriale med ein heilt annan struktur, spesielt bygdebøker, slektshefte av ymse slag og nyare person- og bustadskjema (sjå vidare om dette nedafor). Her finn vi dei aller fleste personrelasjonane gjennom eit ferdig kopla materiale, både i form av «familiar» på ein bestemt bustad, men òg vha. meir eller mindre nøyaktige tilvisingar til personar på andre bustader. Ein kan her tenkje seg at materialet blir registrert direkte inn i dei ferdige strukturane slik dei er beskrive i 2.3 til 2.6. På det viset får ein teke vare på alle personkoplingar og bustadtilknytingar i materialet utan nemnande etterbehandling. Ein unngår også registrering av kvar person meir enn ein gong, og sparer ein god del skrivearbeid. Denne siste metoden vil i det vidare nemnast registrering på personnivå. Krava framafor vil framleis gjera seg gjeldande, men ein kan fire noko på (b) og (c).

Metoden baserer seg på at for kvar ny innførsel i kjelda som skal registrerast må det gjerast eit i søk i personregisteret, i tilfelle dei aktuelle personane alt ligg inne i registeret. I så fall vil nye opplysningar kunne føyast til. Det må automatisk opprettast (kopierast ned) postar til ein eigen «kjeldetype» som tilsvarer dei opplysningane ein registrerer på personnivå. Ein vil da kunne handtere situasjonar der det t.d. blir gjeve motstridande opplysningar om same person, ved å legge til nye «kjeldepostar» etter behov. Ulempa kan vera vanskar med å identifisere rett personeining i databasen etterkvart som registreringa går framover, spesielt der tilvisingane er feilaktige/unøyaktige eller opplysningane kan vera noko sparsame (person- og bustadskjema). Det kan da oppstå behov for å flette saman fleire ulike postar i personregisteret til ei samla personeining på eit seinare stadium i arbeidet, etter at nye tilleggsopplysningar har kome til.

Det er elles verd å merke seg at registrering på personnivå med fordel kan nyttast på enkelte primærkjelder òg – i dei tilfella ein vel å ikkje registrere heile kjeldeserien i databasen. Eksempel på dette kan vera panteregister og arveskifte. Dei nemnte kjeldene vil da bli nytta manuelt ved sida av det maskinelle lenkings- og koplingsarbeidet, som ein «disposisjon» eller kontroll av opplysningar om bustad, persongrupper og -relasjonar. Ein del innførslar i kjeldematerialet vil ikkje kunne knytast til identifiserte personar i registeret. Desse «førebels ukjente» kan da registrerast på personnivå for seinare søking og etterbehandling i systemet.

Registrering på personnivå vil nok krevje noko meir kompetanse av registrator enn den fyrste metoden, sidan ein eigentleg foretar lenking og kopling av materialet samstundes med registreringa. Kva metode som skal nyttast må derfor vurderast i kvart enkelt høve – person- og bustadskjema vil t.d. ofte vera aktuelt å registrere lokalt i prosjektområdet, av folk utan spesiell kompetanse. I slike tilfelle bør som oftast den fyrste metoden over nyttast.

3.3 Kjeldetypar

Registreringsmodulen skal i utgangspunktet handtere alle slags kjelder som inneheld personhistoriske hendingar. Det vil vera umogleg på førehand å kartlegge alle kjelder som kan vera aktuelle, eller å utarbeide eigne registreringsskjema skreddarsydd for kvar einaste kjelde. Ein del av skjema må derfor byggast opp såpass generelt at dei kan famne om fleire ulike kjelder. På det viset skal alle kjelder kunne registrerast, sjølv om ikkje krav (b) over fullt ut kan tilfredsstillast.

Ved utarbeiding av skjematypar må ein ta utgangspunkt i dei kjeldene som utgjer hovudtyngda av materialet som skal nyttast. Dette vil for eit vanleg busetnadssogeprosjekt vera opplysningar frå kyrkjebøker. Basert på erfaringstal (frå ei mindre bygdekommune, Lom) vil data frå desse utgjera 40–50% av det totale materialet. I tillegg har vi data frå folketeljingar, og person/bustadopplysningar frå nyare tid, i form av spørjeskjema utsendt til kvar husstand. Kvar av desse kan utgjera kring 15–20% av materialet. Alle dei nemnte kjeldeseriane må sjølvsagt ha sine eigne, spesialtilpassa registreringsskjema.

For eit bestemt prosjekt vil det som regel i tillegg vera aktuelt å registrere i alle fall ein del av desse kjeldene: offentlege arveskifte (dødsbuskifte), skattelister, lensrekneskap, manntal, tingbøker, matriklar, panteregister, jordebøker, eldre bygdebøker osv. Mengda opplysningar vil oftast vera liten samanlikna med dei andre kjeldene nemnt over. Eksempelvis kan arveskifta og panteregistra kvar for seg utgjera 10–15%, medan summen av dei andre kjeldene står att med 5–10%.

I alle fall ein del av dei siste kjeldegruppene dekker tidsperiodar utanom dei store kjeldeseriane, eller gjev tilleggsinformasjon som er vesentleg i arbeidet med rekonstruksjon av busetnadshistoria. Verdien av dei enkelte opplysningane er derfor vel så stor, problemet er fyrst og fremst at kjeldene kan variere mykje med omsyn til geografi og tid. Det må derfor leggast vekt på å utarbeide nokre standardskjema (og lagringsformat) som skal kunne handtere det alt vesentlege av materialet på ein forsvarleg måte.

3.3.1 Kyrkjebøker og folketeljingar

Som tidlegare nemnt er det utarbeidd ein standard for registrering av kjelder som omhandlar kyrkjelege handlingar, «Standard 4G». Det blir vist til denne, som grunnlag for utarbeiding av registreringsskjema. Det vil vera behov for eigne skjema som dekkjer hendingane dåp, introduksjon, vaksinasjon, konfirmasjon, lysning, vigsel, gravlegging, daudfødsel, off. skrifte, fråflytting, tilflytting og fritekst.

I tillegg finn vi som nemnt standarden «Histform», som grunnlag for utarbeiding av nødvendige registreringsskjema. Folketeljingane er alt registrert elektronisk (dels Digitalarkivet (DA) dels Registreringssentral for historiske data (RHD)) for åra 1865 og 1900, for heile landet. Det er derfor unødvendig å utarbeide skjema for desse åra. Dei mest aktuelle i denne perioden er da for åra 1875 og 1891. Dei tidlegare teljingane er ikkje omfatta av Histform. Teljinga 1801 er alt registrert (DA), men for dei mellom 1801 og 1865 vil det vera aktuelt å utarbeide eitt standard registreringsskjema etter prinsippa i Histform, slik at kjerneopplysningane i dei ulike teljingane blir teke vare på i eigne felt.

Elles vil ingen av desse to kjeldetypane vera aktuelle for registrering på personnivå.

3.3.2 Person- og bustadskjema

Utforming, utsending og innsamling av spørjeskjema om bustad- og persontilhøve frå nyare tid vil vera ein omfattande del av dei fleste busetnadssogeprosjekta. Spesielt vil dette gjelde der ein har hatt framvekst av større tettstader i siste hundreåret. I slike tilfelle vil opplysningar frå denne kjelda utgjera ein vesentleg større prosentdel av det totale materialet, enn nemnt over.

Spørjeskjemaet vil som regel bli utsendt til kvar husstand i området. Eit typisk spørjeskjema vil vera delt i to hovudbolkar, ein som omhandlar bustaden til husstanden, og ein del som omfattar person- og familietilhøve. Ikkje så reint sjeldan vil den som svarer på skjemaet (hovudperson 1 i husstanden) ha familie som aldri har hatt noko med den aktuelle bustaden å gjera (skilt, enke/enkemann osv). Dei to hovudbolkane i skjemaet vil derfor ikkje nødvendigvis vera direkte samankopla.

For å få eit best mogleg grunnlag for rekonstruksjon av busetnadshistoria frå nyare tid bør ein vesentleg del av spørjeskjemaet gå med til å framskaffe flytteinformasjon. Dette vil gjelde opplysningar knytt til bustaden (kven har budd der tidlegare), husstanden (kvar hovudpersonane/familien har budd tidlegare) og ev. barn (bur kvar, flytte til). For å rekonstruere bebuarhistoria best mogleg vil det òg vera aktuelt med opplysningar om tidlegare familie- og sambuartilhøve for kvar av hovudpersonane, spesielt der ein finn særkullsbarn; foreldra og syskena til kvar av dei, ev. halvsysken osv. Føresetnaden er sjølvsagt at dei personane det gjeld anten er fødd innan prosjektområdet, eller har budd der (som barn, eller hovudperson i ein husstand).

Til saman gjev dette eit noko komplisert og omstendeleg spørjeskjema, i alle fall så lenge ein er bunde av papirformatet. Ved overføring til det elektroniske motstykket kan oppsettet forenklast ein del. Registreringsskjemaet må likevel òg delast i to hovuddelar, ein som gjeld bustaden og ein for personopplysningar. Hovudposten for bustadopplysningar kan t.d. omfatte kjeldereferanse, bustadtype, byggeår, bustadnamn, gateadresse, postnr og -stad, gards- og bruksnr osv. Til bustadposten skal det kunne knytast eit vilkårleg tal underpostar med informasjon om kven som bur/har budd der, dvs. persongrupper som nemnt i 2.5. Relevante opplysningar her er namn på personane og tidsperiode (busett frå år – til år).

Persondelen av registreringsskjemaet vil ha ein hovudpost som berre omfattar kjeldereferanse. Knytt til denne vil det vera eit vilkårleg tal underpostar med personopplysningar. Kvar personpost må omfatte relevante data som forklart i 2.3, saman med eigne felt for yrkesnemningar o.l. I tillegg må det for kvar enkelt personpost kunne spesifiserast ulike relasjonar til inntil to andre personpostar, jf 2.2 og 2.4. For partnerrelasjonar må start- og ev. sluttidspunkt for forholdet kunne registrerast. Kvar personpost må òg kunne koplast til eit vilkårleg tal postar med bustadopplysningar. Nødvendige data her kan vera bustadnamn, adresse ev. gards- og bruksnr, spesifikasjon av om staden ligg innan prosjektområdet, tidsperiode for busettinga osv. Fleire personpostar må kunne knytast til same bustadpost.

Det må leggast vekt på å utarbeide eit generelt registreringsskjema som vil samsvare med dei fleste «papirspørjeskjema» som kan tenkjast bli nytta i konkrete prosjekt. Sidan personrelasjonane i materialet stort sett er gjeve gjennom oppsett av kjernefamiliar, kan registreringsskjemaet truleg utformast slik at ein unngår manuell koding av relasjonane mellom dei ulike personpostane (dvs. ein skjemadel for «far», ein for «mor» og ein for «felles barn» osv). Elles er denne kjeldetypen svært aktuell for registrering på personnivå, sjå 3.2 over.

3.3.3 Andre familiekjelder

I denne gruppa finn vi som tidlegare nemnt eldre bygdebøker, ulike slektshefte o.l. Det vesentlege er at kjeldematerialet i seg sjølv er ferdig kopla, og registrering på personnivå kan nyttast. Elles blir vurderingane her omtrent dei same som i punktet over, og registreringsskjemaet kan truleg utformast omtrent identisk med det som nyttast for person- og bustadskjema.

3.3.4 Dødsbu- eller arveskifte

Denne kjeldegruppa kan vera relativt omfattande, og bør ha eit eige, spesialtilpassa registreringsskjema. Skjemaet må byggast opp med ein hovuddel som omfattar data knytt til sjølve skiftet: kjeldereferanse, tidspunkt, skiftestad osv, saman med opplysningar om formue, gjeld, innbu, lausøyre osv i skiftebuet. Sidan skiftebua ofte omfattar fast eigedom bør det kunne opprettast eit vilkårleg tal eigedomspostar tilknytt hovudposten. Eigedomspostane må innehalde data som eigedomsnamn, skyldstorleik, skyldtype (pantegods, gåvegods osv) og ev. nummer knytt til eigedomen. I mange skifte er det og gjeve ein del driftsopplysningar, sjå nærare om dette under 3.3.7 nedafor. Til hovudposten skal det knytast eit vilkårleg tal underpostar med opplysningar om personane nemnt i skiftet. Personpostane må innehalde relevante data i høve til 2.3. I tillegg må det for kvar personpost kunne spesifiserast inntil to relasjonar til andre personpostar (under same hovudpost), jf 2.2 og 2.4. Kvar post må òg kategoriserast på personen sin funksjon i skiftet, dvs. «arvlatar», «arving», «arvings ektefelle», «verje» osv.

Ved fullstendig registrering av heile kjeldeserien er det berre aktuelt å gjera det på kjeldenivå, men sjå elles 3.2.

3.3.5 Fritekstkjelder

Omgrepet dekker alle kjelder som ikkje utan vidare let seg passe inn i noko av dei andre kjeldetypane som har fått utarbeidd sine standardskjema. Dette gjeld da fyrst og fremst kjelder som ikkje kan rubriserast på nokon enkel måte, som t.d. gamle brev, dagbøker, avisartiklar osv. Men kravet er at ein i kjelda finn opplysningar som kan knytast til identifiserbare personar og/eller bustader (eigedomar). Utan slike data vil det vera irrelevant å registrere kjelda i systemet.

Registreringsskjemaet kan byggast opp med ein hovudpost som gjeld data knytt til sjølve kjelda: referanse, type, tidspunkt, emne osv, i tillegg til sjølve kjeldeinnførselen i full tekst, som eit samandrag, stikkord e.l. Til kvar hovudpost må det kunne knytast eit vilkårleg tal personpostar, med nødvendige opplysningar i samsvar med 2.3 framafor. Vidare må det kunne spesifiserast relasjonar mellom dei ulike personpostane, i samsvar med 2.2 og 2.4. I tilknyting til kvar hovudpost må ein òg kunne ha eit vilkårleg tal bustad- eller eigedomspostar, spesifisert fyrst og fremst med namn. Det er elles spesielt viktig med bruk av merknadsfelt i denne samanhengen. Det vil vera naturleg å knytte merknader til alle dei ulike posttypane, slik at ein hovudpost kan omfatte mange underpostar med kvar sine merknadsfelt.

3.3.6 Andre strukturerte personkjelder

Sidan talet på ulike kjeldetypar er stort må det utarbeidast nokre standard registreringsskjema som dekker det aller meste av variantane, sjølv om ein da ikkje fullt ut får tilfredsstilt kravet om å legge mest mogleg av opplysningane i eigne felt. For å fange opp dei fleste «spesialtilfella» i ulike kjelder vil det vera ein fordel å utforme relativt omfattande skjema, sjølv for dei enklaste kjeldetypane. I og med kravet om at brukaren skal kunne sperre / låse opp dei enkelte felta for skriving (sjå 3.1), vil det likevel vera mogleg å tilpasse funksjonaliteten i skjemaet til den aktuelle kjelda som skal registrerast. Det blir her berre sett opp ein kort oversikt over nokre viktige kjeldetypar. Den endelege utforminga og «standardiseringa» må skje ved å gå djupare inn i materialet. Fleire av dei nemnte skjematypane nedafor kan i prinsippet byggast opp over same lest, med enkelte variasjonar. Bruken av merknadsfelt blir i prinsippet som nemnt under 3.3.5, utan at dette er nærare drøfta for kvar enkelt kjelde.

Skattelister: spesielt viktige for den eldre tida (dvs. før kyrkjebøker og andre store kjeldeseriar startar), men det vil òg vera aktuelt å registrere enkelte seriar eller årgangar frå nyare tid, som eit supplement der ein t.d. vantar kyrkjebøker. Det er ein stor variasjon i skattetypar og -nemningar, frå eldre tid finn vi mellom dei mest vanlege: bygningsskatt, garnisonsskatt, kontribusjon, koppskatt, kvegskatt, landskatt, odelsskatt, rossteneste, unionsskatt, fôring, gjengjerd, tiend osv. Listene er i hovudsak enkelt oppbygde, men vil som oftast ha nokre få unntak. Det er noko problematisk at skattytinga kan vera knytt til brukseining, eigedom eller person, gjerne innan same lista. Det vil vera tenleg med ein hovudpost som omfattar opplysningar om kjeldereferanse, skattetype, tidspunkt, skatteeining (namn på bustaden eller brukseininga, ev. nummer, skatteklasse, legdnr osv) og ev. felt for samla skattebeløp og skyldtilhøve. Til hovudposten skal det kunne knytast eit vilkårleg tal personpostar, på same viset som under 3.3.5. Relasjonar må kunne spesifiserast til personpostar under ein annan hovudpost. I tillegg må det kunne registrerast yrkesnemning, sivilstatus, bustad der denne avvik frå skatteeininga osv. Det bør òg vera felt for skattebeløp i kvar personpost. Til kvar hovudpost må det vidare kunne knytast eit vilkårleg tal eigedomspostar, sidan ein god del av skattlegginga er knytt til eigedom (ulike former for odelsskatt). Eigedomspostane kan byggast opp på same viset som nemnt under 3.3.4 framafor. Det er elles spesielt viktig at den originale rekkefølgja av skatteeiningane i lista blir teke vare på i registreringa, sidan dette kan ha noko å seie for identifikasjon under lenkinga. Enkelte skattelister kan elles innehalde andre viktige opplysningar, sjå 3.3.7 nedafor.

Matriklar: matrikkelen 1886 er alt registrert elektronisk for heile landet, og matrikkelen 1838 er under arbeid (RHD for båe). Det er derfor unødvendig å utarbeide noko eige registreringsskjema for 1886-matrikkelen, og truleg òg 1838. Det kan elles vera aktuelt å registrere skattematrikkelen 1647, matrikkelen 1668, forslaget 1723 o.l. Det må vurderast om ein kan nytte ein felles standard for desse, eller om kvar enkelt skal ha sitt spesielt tilpassa registreringsskjema. Hovudposten vil ha data knytt til sjølve eigedomen (eller brukseininga), med opplysningar som kjeldereferanse, eigedomsnamn og -nummer (ev. nytt og gammalt), skyld (ev. ny og gammal) osv. Til kvar hovudpost skal ein kunne knytte eit vilkårleg tal personpostar, som under 3.3.5. Desse må i tillegg ha opplysningar om persontype (eigar, brukar o.l.) og kvar eigar sin ideelle part av den totale skylda på eigedomen. Matrikkelen 1668 og forslaget i 1723 inneheld mange tilleggsopplysningar i høve til dei andre, spesielt driftsopplysningar. Sjå nærare om dette nedafor.

Tingbøker: denne kjeldetypa er vel den som kjem nærast fritekstkjeldene beskrive i 3.3.5. Hovudposten må da i staden for «emne» ha felt for sakstype (odelssak o.l.), ev. tingstad osv. Personpostane må i tillegg ha felt for personen sin status i saken, dvs. «saksøkar», «vitne», «tiltala» osv. På same viset som i 3.3.5 må ein òg kunne ha eit vilkårleg tal bustad- eller eigedomspostar knytt til hovudposten, men ev. med opplysningar om skyld i tillegg (som nemnt i 3.3.4).

Lensrekneskap: omfattar i tillegg til skattelister som nemnt over saker som bygsel, holding og sakefall. Bygsel og holding er knytt til ein bestemt bustad eller brukseining, medan sakefall er knytt til person(ar). Bygsel og holding vil i stor grad kunne organiserast på same viset som skattelister over. Hovudposten må innehalde opplysningar om kjeldereferanse, type (dvs. bygsel eller holding), tidspunkt, eigedom eller brukseining (namn, nr osv) og felt for avgift (beløpet) og skyld. Dei tilknytte personpostane blir òg etter same mønster, med relasjonar mellom postane og spesifikasjon av bustad som avvik frå brukseininga. Ved fyrstebygsel er det elles nødvendig å skilje mellom ny og gammal brukar. Forskjellen i høve til skattelistene er at ein ikkje treng eigedomspostar knytt til hovudposten. Sakefall blir derimot å samanlikne med tingbøker over. Hovudposten skal omfatte kjeldereferanse, tidspunkt og sakstype (t.d. leiermål, åbotsfall osv). Personpostane blir elles som for 3.3.5, med relasjonar seg i mellom. I tillegg må det knytast eit felt for bota (beløpet) til kvar post.

Panteregister: inneheld opplysningar av relativt varierande karakter, som skøyteoverdragingar, pantelån, kårytingar, bruksdeling og -samanføying osv. Hovudposten må innehalde kjeldereferanse, sakstype (skøyte, lån osv), tidspunkt, eigedom (namn, nr osv) og skyldstorleik. Tilknytte personpostar blir som for 3.3.5, med ev. relasjonar. Det er elles nødvendig å kunne spesifisere kva slags status dei ulike personane har i enkelte innførslar, t.d. kven som skriv ut og kven som får skøytet, kven som yter kåret og kven som nyt godt av det osv. Innførslar som ikkje er knytt til personar (reine bruksdelingar) kan ein etter nærare vurdering la vera å registrere. Denne kjeldetypa er elles aktuell å nytte manuelt, med ev. registrering av førebels ukjente personar slik det er nemnt i 3.2.

Manntal: hovudposten byggast opp med opplysningar knytt til kjeldereferanse, tidspunkt, bustad (brukseining) med namn, ev. nr og skyld, skatteklasse osv. Personpostane blir som i 3.3.5, med spesifikasjon av relasjonar seg i mellom. Alle personar må elles kategoriserast på type (brukar, husmann, lausgjengar osv).

3.3.7 Kjelder med driftsopplysningar

Det er ein del kjelder som skil seg ut ved at dei omhandlar driftsopplysningar (jordbruksopplysningar) knytt til den enkelte brukseininga, spesielt dyretal, utsæd og avling. Dette gjeld t.d. kvegskatten 1657, matrikkelen 1668, matrikkelforslaget 1723, mange dødsbu- og arveskifte, dei ulike jordbruks- og folketeljingane på 1800-talet, andre dyre- og fôrteljingar m.m. Det må vurderast om ein kan utforme eitt standard registreringsskjema for alle slike opplysningar. Ved registrering av dei ulike kjeldetypane i sine respektive standardskjema som nemnt framafor, kan ein da hente fram driftsopplysningsskjemaet i tillegg, som eit «underskjema» eller ein dialog.

Dette sikrar at ein får eit einsarta oppsett av driftsopplysningar frå mange ulike kjelder, og vil vesentleg forenkle det seinare arbeidet med analyse av talmaterialet. Det er mogleg at metoden til ein viss grad strir mot krava (b) og (c) framafor, men bør ikkje utan vidare avskrivast. Alternativet kan vera å ikkje registrere desse opplysningane i systemet i det heile teke, men legge dei direkte inn i eit eige rekneark eller liknande. Det vil neppe vera rekningssvarande å fyrst registrere dei i sine spesielle oppsett knytt til kvar enkelt kjeldeserie, for seinare å få konvertert dei over i same tabellformat for vidare analyse.

4 Oppretting og vedlikehald av bustadregisteret

Bustadregisteret slik det er beskrive i 2.6.1–2.6.3 skal i utgangspunktet byggast opp og endrast interaktivt frå brukaren si side. Det blir ikkje lagt opp til at bustadkjelder lenkast på same viset som personkjelder. I den grad det er nødvendig med direkte tilvisingar frå bustader i registeret til enkelte kjeldepostar, kan desse opprettast manuelt som ei «ekstern» kopling i kvart enkelt høve, sjå 2.6.2.

Det må derfor utformast registreringsskjema for bustader (eigedomar, bruk og område) i samsvar med definisjonane tidlegare. Alle endringar av innhaldet i bustadregisteret vil da kunne skje ved å nytte same skjemaet. I tillegg til skjemaet for den enkelte bustaden bør sjølve bustadstrukturen, med hierarkiet av ulike element, presenterast på ein enkel og intuitiv måte for brukaren. Dette kan gjerast ved å nytte ein trestruktur etter mønster av «utforskar»-modulen i Windows e.l. Det skal vera enkelt å markere element med bruk av mus eller tastatur, få opp det tilhøyrande skjemaet, ev. «dra» elementet til ein annan stad i hierarkiet osv, sjølvsagt innafor dei avgrensingane som må settast for at strukturen skal vera konsistent.

Det bør under registrering eller endring av eit element i bustadstrukturen vera mogleg å gjera enkle søk på bustadnamn og ev. nummer i datamaterialet, slik at eit utval av kjeldepostar kan presenterast i ei enkel, sortert liste. Dette vil vera til stor hjelp når enkelte verdiar i skjemaet skal settast, spesielt tidspunkt for ulike hendingar (periode for busettinga), ulike matrikkeldata osv. Ein slik funksjon vil langt på veg erstatte den manglande lenkeprosessen av bustadkjelder.

Fyrste gongs oppretting av bustadregisteret kan elles til ein viss grad basere seg på maskinelle rutinar. Det er da nokre få kjeldetypar som er aktuelle som eit grunnlag, t.d. matrikkelen 1886, folketeljinga 1900 og ev. spesiallister frå GAB-registeret eller andre tilsvarande, offentlege databasar. Ein kan òg nytte dei registrerte bustad- og personskjema (3.3.2), i den grad desse gjev detaljert nok informasjon. Resultatet vil etter den maskinelle opprettinga vera eit «flatt» bustadregister eller eigedomsregister (viss matrikkelen nyttast), utan tilhøyrande personopplysningar osv. Det er derfor grunn til å vurdere nytten av ein slik maskinell rutine, sett opp mot kostnaden med å utvikle den. Alle element i strukturen må utan omsyn likevel endrast manuelt av brukaren, og da vil ein neppe tape vesentleg med tid på å registrere alle bustader manuelt samstundes som ein bygger opp den hierarkiske strukturen.

Det kan elles vurderast nærare om rutinen over kan utvidast til å gjelde fleire sentrale bustadkjelder. Dette vil da fyrst og fremst gjelde matrikkelen 1668 og matr.forslaget 1723, saman med matrikkelen 1838 (som tidlegare nemnt vil denne etterkvart vera tilgjengeleg elektronisk). Desse vil saman med dei nemnte kjeldene over gje meir omfattande eigedomsopplysningar over eit lengre tidsrom. For å nyttiggjera seg dette grunnlaget må ein redigere det «flate» bustadregisteret ved å flette saman alle elementa som gjeld same eigedomen. Resultatet blir noko meir «fyldige» bustad- eller eigentleg eigedomspostar, men dette er sjølvsagt avhengig av at ein nyttar element som handterer matrikkeldata fullt ut. Det vil vera lite rekningssvarande å gjennomføre denne prosessen, viss resultatet er eigedomspostar med 4–5 variantar av skrivemåten på namnet og lite eller ingenting anna.

Endringar i bustadstrukturen må elles handterast på ein konservativ måte. Det er viktig å identifisere konfliktsituasjonar, slik at ein unngår at data går tapt eller at det oppstår «lause» delar av strukturen som ikkje er lenka til resten. Namnedata (hovudnamn, tilvisingar, sorteringsnamn osv) kan utan vidare endrast for dei ulike elementa. Det same gjeld bruksdata og eksterndata.

Endring av matrikkeldata vil bli noko meir komplisert. Oppretting av nye matrikkelhendingar vil vera uproblematisk. Flytting av hendingar er uaktuelt. Tidspunktet for ei hending kan ikkje endrast slik at det kjem i konflikt med tidsperioden for dei tilhøyrande nummer- og skyldtilhøva. Sletting av matrikkeldata kan ikkje skje utan samstundes å fjerne ev. referansar inn til den aktuelle posten (ved frådeling osv).

Elles vil oppretting av nye element i bustadstrukturen ikkje skape konflikt med alt etablerte einingar. Det vil likevel vera nødvendig med omnummerering av elementa på det aktuelle nivået i hierarkiet, viss nye bustader (bruk) eller bustaddelar blir oppretta. Det kan ikkje opprettast nye element (område, bruk eller eigedomar) utan at desse blir knytt til og liggande under eit alt eksisterande område.

Flytting av element kan gjennomførast med visse avgrensingar. Viss flyttinga elles kan gjennomførast vil alle underliggande strukturar fylgje med, og ev. lenker som viser tilbake til elementet må oppdaterast. Område, bruk og eigedomar kan flyttast seg i mellom under eitt og same områdeelement, eller flyttast og plasserast under eit anna, eksisterande område. Flytting av bruk vil medføre omnummerering av elementa under kvart av områda. Flytting av bustaddelar innan same bruket (bustaden) vil òg medføre omnummerering av delane. Flytting av bustaddelar mellom ulike bruk vil koma i konflikt med dei underliggande persongruppene, som har referansar attende til den overliggande bustaden (for å få generert tilvisingar). Ein må da fyrst gå gjennom lista med alle tilknytte persongrupper, for oppdatering av referansane tilbake til bustaden.

Sletting av element skal handterast konservativt, dvs. ingen element kan slettast så lenge det har tilknytte, underliggande strukturar. Dette medfører at eit områdeelement ikkje kan slettast så lenge det er tilknytte, underliggande område, bruk eller eigedomar. Eit bruk (bustad) kan ikkje slettast så lenge det finst definerte bustaddelar på bruket, og ein bustaddel kan ikkje fjernast så lenge ein finn tilknytte persongrupper. Eit element kan heller ikkje slettast viss det er oppretta ein referanse dit i samband med ei matrikkelhending. Viss føresetnadene elles er til stades, vil sletting av eit bruk eller ein bustaddel medføre omnummerering av dei tilsvarande elementa. Det må elles vurderast om alle matrikkeldata knytt til eit element skal kunne slettast samla.

Typeendring for eit element i strukturen (dvs. endre «bruk» til «område» t.d.) bør oppfattast som å slette elementet, dvs. eit bruk kan omdefinerast til område og omvendt berre viss føresetnadene for sletting er til stades.

Fletting av element kan gjennomførast med ein del restriksjonar. Elementa må i utgangspunktet vera av same type. Vidare kan flettinga skje berre viss det eine elementet elles har oppfylt krava til sletting, dvs. ikkje har nokon underliggande struktur. Viss føresetnaden for fletting elles er til stades, vil dette generere omnummerering etter same mønster som nemnt under flytting og sletting. Brukaren må elles gjerast merksam på opplysningar i dei to elementa som kjem i konflikt med einannan, slik at korrekte verdiar blir vald (ulike namn, tidspunkt m.m.). Elles blir resultatet ein union av dei to opphavlege elementa.

5 Lenking, kopling og bustadtilknyting

Grunnlaget for og den overordna arbeidsmetoden knytt til desse prosessane er beskrive i 1 og 2.1–2.4. Den nødvendige strukturen som må byggast opp i datasystemet for å handtere lenker, koplingar, namnestandardisering osv må i stor grad basere seg på dei løysingane som alt er implementert i FamRek. I teksta nedafor blir det derfor berre ein del overordna prinsipp som drøftast.

Ein konkret lenkeoperasjon baserast på identifikasjon av enkeltpersonar i datamaterialet. Dette skjer ved å søke fram utval av personhendingar frå dei ulike tabellane i datamaterialet. Søkinga vil kunne skje berre i ein del nøkkelfelt, som finst gjennomgåande i alt materialet som skal nyttast. Dette vil fyrst og fremst dreie seg om namneopplysningar, både på bustader og personar. I tillegg vil det vera naturleg å kunne avgrense søket til bestemte tidsperiodar. Det må òg vera mogleg å velja om ein vil søke berre i dei kjeldepostane som ennå ikkje er lenka til nokon person (personeining), eller i heile materialet. Det må vera mogleg å nytte «jokerteikn» for å spesifisere vilkårlege teikn (?) og strengar (*). Søket skal elles kunne gjennomførast med AND-operator på verdiar i ulike felt, men det blir neppe aktuelt med meir avanserte søkeprosessar (t.d. bruk av logiske operatorar på fleire ulike resultatlister). Sjølve søket må spesifiserast i eit eige skjema eller tabelloppsett.

Eit sentralt problem med framsøking av og sorteringa av utval, er særs varierande skriveformer av alle slags namn, rein feilskrift i kjelda, doble fornamn, samanblanding av familienamn/slektsnamn/gardsnamn osv. Det vil vera nødvendig med ein vel utvikla rutine for standardisering av alle slags namn, spesielt frå eldre tid (før siste halvdel av 1800-talet). Det er alt utvikla metodar og rutinar knytt til slik standardisering, som kan nyttast i det vidare arbeidet. Det er i denne samanhengen nok å vise til løysinga fyrst og fremst i FamRek.

Resultatet av eit søk presenterast i ei enkel liste, som skal kunne sorterast etter ulike kriterium, i utgangspunktet tidspunkt for hendinga. Brukaren markerer hendingar som gjeld same person, og genererer ein ny post i personregisteret. Lenker blir oppretta til dei aktuelle hendingane, relevante data blir kopiert over til personregisteret, og kan seinare presenterast i eit eige skjema for manuell redigering. Saman med opplysningane i personeininga skal ein få lista opp dei ulike hendingane som er tilknytt personen.

Det kan stillast opp nokre enkle krav til sjølve lenkestrukturen:

(a) systemet skal lenke saman berre dei personhendingane som verkeleg høyrer til same person, og ingen fleire. Ut frå formålet med datasystemet vil det bli oppfatta som verre at ein person får ei feilaktig lenke, enn at ein person kan ha ei eller fleire manglande lenker. Dette medfører også at maskinell lenking vanskeleg kan gjennomførast.

(b) systemet må sikre at kvar personhending blir knytt til ei og berre ei personeining.

(c) det må skje ein kontroll av den logiske samanhengen mellom opplysningane i dei ulike personhendingane tilknytt same personeining. Prioritet av motstridande opplysningar må definerast der dette har konsekvens for oppretting av personeininga (t.d. mange ulike fødselstidspunkt etter kva kjelde som nyttast).

(d) det må vera mogleg å markere enkelte lenker som usikre.

Med oppretta personeiningar kan ein gjennomføre prosessen med kopling av materialet. Dette vil skje i form av ein maskinell kontroll av alle implisitt og eksplitt gjevne relasjonar i kjeldene, med oppretting av koplingar mellom postane i personregisteret som beskrive i 2.4 (personrelasjonar). I tillegg til den maskinelle rutinen må det sjølvsagt vera mogleg å opprette manuelle koplingar. På same viset som lenkene over, vil det vera krav om at enkelte koplingar eller relasjonar kan markerast som tvilsame eller usikre. Systemet må òg foreta ein kontroll av samanhengen mellom dei oppgjevne relasjonane og ulike hendingar knytt til dei impliserte personane (slik at ein oppdager «giftarmål» etter «dødsfall» o.a. inkonsekvensar). Det er også her grunn til å vise til hovudformålet med datasystemet – feilkopla personar vil vera langt verre enn manglande koplingar, dvs «ukjente» personar kan godtakast i større grad.

Både maskinell og manuell kopling resulterer i oppretta personrelasjonar i systemet. Desse må vidare knytast til nye eller alt eksisterande persongrupper som kan hentast fram. Persongruppene blir så plassert under (lenka til) sine respektive bustader, viss dette ikkje alt er gjort. Handteringa av desse elementa bør skje etter same mønster som nemnt under bustadstrukturen framafor, med bruk av lister og trestrukturar.

På same viset som for bustadeiningar i 4, må det vera mogleg å opprette nye, endre eller fjerne lenker og koplingar, dvs. element eller postar i personregisteret, personrelasjonar og persongrupper. Men her òg må ein sikre seg at dette blir handtert på ein måte som ikkje fører til konflikt med andre strukturar i systemet.

I praksis vil dette medføre at oppretting av nye element vil vera uproblematisk, så lenge dei får eit reelt innhald av nødvendige opplysningar. Sletting, flytting og fletting av element skal ikkje kunne gjennomførast, utan at konsistensen i dei underliggande strukturane blir teke vare på. Det må her utarbeidast ein omfattande oversikt over kva slags konfliktsituasjonar som kan oppstå. For fleire av operasjonane vil det bli nødvendig å gjennomføre «dekomponering» av personar, dvs. å bryte alle oppbygde lenker til hendingar (kjeldepostar) frå personeininga, og fjerning av koplingar mellom personar. Etter den gjennomførte endringa (t.d. sletting av ein post i personregisteret) kan så nye element byggast opp ved å gjennomføre lenking og kopling på nytt for det aktuelle materialet.

Manuell endring av verdiane i dei oppbygde elementa (t.d. namnedata for personar, årstal for giftarmål osv) vil sjølvsagt overstyre dei verdiane som hentast frå kjeldenivået, slik at ein kan rette feil i kjeldematerialet, tilføye namneelement (t.d. skifte av fornamn i vaksen alder) m.m.

6 Utskrift og rapportar

Datasystemet skal ha gode rutinar for utskrift av lister og rapportar frå dei fleste modulane. Nesten all utskrift vil skje ved å legge ut data på filer med enkelt tekst- eller tabellformat, slik at dei kan etterbehandlast i tekstprogram eller rekneark før utskrift på papir. På dette viset unngår ein å utvikle formaterte oppsett (layout) av dei ulike utskriftene i sjølve datasystemet, noko som kan vera arbeidskrevjande i høve til nytten.

Det vil i hovudsak vera tre–fire utskriftstypar og rapportar som er aktuelle. For det fyrste skal ein kunne skrive ut innhaldet i dei fleste tabellar og register i systemet. Dette inneber at ein må kunne produsere enkle lister basert på innhaldet i kjeldetabellane, personregisteret og bustadregisteret, med tilhøyrande hjelpetabellar over ulike relasjonar, lenker, koplingar osv. Det må vera mogleg for brukaren å spesifisere kva felt som skal vera med i den enkelte utskrifta, og det må vera mogleg å søke fram utval av tabellane eller registra for utskrift, etter same mønster som for lenkinga. Det vil vera naturleg at opplysningane blir lagt ut i eit enkelt tabellformat, men det bør i alle fall for kjeldetabellane vera mogleg å generere ein «komprimert» tekststreng der ein nyttar spesielle skiljeteikn etter eit nærare bestemt format. Dette kan vera med på å forenkle korrekturarbeidet i høve til kjeldematerialet.

Vidare må brukaren kunne be om ein overordna systemrapport, som presenterer statistikk over innhaldet i alle dei ulike tabellane og registra. Denne rapporten må i stor grad automatiserast. Det bør vera mogleg å liste ut formatet (oppsettet) til den enkelte tabellen eller registeret, og oversikt over storleik eller omfang i form av tal postar, både for heile tabellen og ev. framsøkte utval.

Den mest omfattande rutinen for utskrifter vil sjølvsagt bli knytt til produksjon av sjølve sluttresultatet, eit utkast til manus for busetnadssoga. Rutinen skal traversere den oppbygde bustadstrukturen etter ein rekursiv djupne-fyrst metode (som forklart i 2.6.3), og alle relevante opplysningar i bustad- og personregistra skal listast ut etter eit nærare bestemt, delvis brukarstyrt format. Kvart element i bustadstrukturen skal få utlista sine data ved fyrste gongs besøk i gjennomgangen (t.d. bruksnamn, -historie, matrikkeldata osv). Deretter blir alle data for underliggande strukturar lista ut, før ein går vidare til neste element på same nivå, eller tilbake til nivået over. For kvar bustaddel som blir besøkt i gjennomgangen må da alle persongrupper knytt til bustaddelen listast ut sekvensielt, før ein går vidare til neste del eller bustad. Vidare må kvar persongruppe som blir besøkt få lista ut data for alle dei personane som knytt til gruppa, før ein går vidare til neste gruppe eller neste bustaddel. Det må elles vera mogleg å spesifisere berre delar av strukturen som skal listast ut, ned til kvar enkelt persongruppe under ein bestemt bustad.

Formatet for utlisting av opplysningar frå registra må ha ein relativt fast, førehandsdefinert struktur, men brukaren skal kunne velja ulike standardfraser knytt til enkelte verdiar, for å spesifisere relasjonar m.m. Spesielt gjeld dette personopplysningar og relasjonane mellom personar i den enkelte persongruppa. Ei tenkt utlisting kan da t.d. bli slik, framstilt skjematisk:

namnegard (område) [namn, historie, matrikkeldata, …]

bruk (bustad) [namn, historie, matrikkeldata, bruksdata, …]

bustaddel [nemning]

persongruppe [nummer, tidsperiode, *personar]

Vidare vil *personar kunne formaterast t.d. slik (opplysningar med {} bør til ein viss grad kunne formaterast av brukaren):

[*hovudperson 1] [førre persongruppe til hovudperson1] [førre personrelasjon til hovudperson1] {relasjon} [*hovudperson 2] [førre persongruppe til hovudperson2] [førre personrelasjon til hovudperson 2] [førre persongruppe til relasjonen 1–2] [historie1] {barn}:

[liste med *barn]

[historie2] [neste persongruppe til relasjonen 1–2] [neste persongruppe til hovudperson 1] [neste personrelasjon til hovudperson 1] [neste persongruppe til hovudperson 2] [neste personrelasjon til hovudperson 2]

[hovudperson 3] osv.

Elementa [førre persongruppe …] og [førre personrelasjon …] osv vil bli heilt ulike alt ettersom den aktuelle kombinasjonen av personrelasjonar og bustadopplysningar. Det kan oppstå kompliserte situasjonar som må utgreiast nærare, men i utgangspunktet kan dette fungere slik: viss HP er knytt til ei tidlegare persongruppe (som pr def. er knytt til ein annan bustad), vil det bli gjeve ei tilvising dit. Dette gjeld da anten HP har hatt familie tidlegare, eller om han har budd der einsleg. Viss HP har tidlegare partnerrelasjonar (med eller utan tilhøyrande barn) der bustaden er ulik for partnerane, bustaden er ukjent eller fell utanom den definerte bustadstrukturen, så blir dei fulle opplysningane for denne tidlegare relasjonen lista ut (dette vil da vanlegvis gjelde «uekte» fødde). På same viset vil [neste persongruppe …] osv fungere, men [neste personrelasjon …] er aktuell å handsame berre viss HP ikkje er knytt til nokon neste persongruppe. Viss førre eller neste persongruppe til HP er den same som den aktuelle, blir det sjølvsagt ikkje gjeve nokon tilvising, opplysingane er da alt lista ut, eller blir det seinare under same persongruppe. Tilsvarande vil elementa som gjeld førre og neste persongruppe for relasjonen (dvs. samla for hovudpersonane 1 og 2) nyttast for å gje tilvisingar slik at ein oppnår eit konsistent system med flytteinformasjon. Det fullstendige oppsettet over vil da òg berre bli nytta der den aktuelle persongruppa gjeld hovudbustaden til personane. Sjå elles 2.4 og 2.5 for drøfting kring nokre av desse opplysningane.

Elementet *hovudperson kan t.d. handsamast slik:

[fornamn] {farsnamn} [slektsnamn] {tilvising opphavsstad} {fødselstidspunkt} {dødstidspunkt}

Brukaren skal i utgangspunktet til ein viss grad kunne formatere opplysningane merka med {}, med ledetekster , spesialteikn, suffiks osv. Til slutt vil *barn kunne formaterast slik:

[nr] [fornamn] {fødselstidspunkt} [personhistorie] {tilvising hovudbustader}

Elementet personhistorie kan òg bli noko komplisert. Det er tenkt å fungere slik: opplysningar knytt til ein personrelasjon (medrekna ukjent partner eller som einsleg person, sjå 2.4) der bustaden er ukjent, partnerane har ulik bustad eller bustaden ikkje er definert i systemet blir formatert ut etter om lag same oppsett for persongrupper over, men sjølvsagt i ein samanhengande tekststreng utan lineskift. Personhistoria vil bli nytta berre så lenge barnet ikkje er knytt til nokon definert bustad som hovudperson, elles vil dei tilsvarande opplysningane bli handsama der, slik det er beskrive over. I ekstreme tilfelle risikerer ein at det er definert samanhengande personrelasjonar for etterkomarane i fleire generasjonar nedover, utan at nokon av dei er knytt til nokon bustad. Det vil medføre ein rekursiv utlisting av personopplysningar som raskt går ut over kva ein meiner med ei forståeleg og leseleg tekst . Det må derfor vurderast om det skal settast ei grense for kor mange nivå som blir omfatta av ei slik nøsting av opplysningar (ein generasjon er truleg tilstrekkeleg). Elles vil ein arbeidsmetode som resulterer i slike omfattande strukturar av personrelasjonar utan at nokon av personane er knytt til bustader stri mot intensjonane eller formålet med datasystemet.

7 Import og eksport av data

Systemet må ha rutinar for import og eksport av data, både som «råmateriale» – dvs registrert, ubehandla og statisk kjeldemateriale – men òg ferdig oppbygde strukturar som beskrive i 2.2 til 2.6 – dvs eit ferdig lenka og kopla personregister, knytt saman med eit oppbygd bustadregister.

Utveksling av kjeldemateriale vil kunne handterast etter same prinsipp som drøfta tidlegare i 3.3, ein må her basere seg på dei standardane som alt eksisterer (t.d. Histform), saman med dei løysingane som blir vald for anna type materiale. Ved fletting av same type materiale frå fleire databasar, må det syrgjast for ein kontroll av intern eintydigheit, dvs alle postreferansar (t.d. personrelasjonar) må oppdaterast slik at ein oppnår absolutt og eintydig adressering av postar innan det samanslåtte materialet.

Import av grunnlagsmateriale frå andre kjelder (t.d. Excel, BD87, Access osv) skal kunne handterast vha oppbygging av ein metatabell som nemnt i 2.2, for «tolking» eller «konvertering» av datamaterialet. Føresetnaden er da sjølvsagt at det aktuelle materialet har format og beskriving som gjer det mogleg å tolke innhaldet. Vurdering og løysing av aktuelle problemstillingar må gjennomførast i kvart enkelt høve.

Utveksling av strukturert materiale skal òg kunne gjennomførast. Ved fletting av to databasar må det da på same viset som for kjeldematerialet utførast ein kontroll av alle relasjonar og referansar i registra, slik at eintydigheit blir oppnådd. Dette vil vera ein omfattande operasjon, men forenklast ved at lenking og kopling av materialet mellom dei to opphavlege basane ev. må gjennomførast manuelt i etterkant av samanføyinga. Det blir med andre ord ikkje lagt opp til nokon maskinell gjenkjenning og fletting av postar eller elementa mellom dei oppbygde strukturane.

Når det gjeld eksport av data til andre formål (t.d. analyse vha statistikkprogram), kan dette gjennomførast ved å legge ut ein meir eller mindre direkte kopi av kjeldemateriale og andre register, som seinare tolkast av den aktuelle applikasjonen. Alternativt kan eksporten skje i eit bestemt format til slike formål, i den grad det er utarbeidd generelle, etablerte standardar. I denne samanhengen kan det òg nemnast at datasystemet bør ha ein rutine for å legge ut data i GEDCOM-format, som ein service overfor amatørslektsforskarar og andre.