RubReg
Et program for behandling av
data fra humanistiske kilder
av Asbjørn Brændeland:
 

I denne presentasjonen beskrives RubReg for Macintosh. De grunnleggende funksjonene er felles for DOS- og Macintosh-versjonen av RubReg, men detaljene er forskjellige, ikke minst på grunn av ulikheten mellom de to operativsystemenes grensenitt.


Bakgrunn
- Kort historikk
- Databehandlerens behov
- Sirkularitet og linearitet
- Ad hoc bestemmelse av datatyper
- Dataformater og plassutnyttelse
- Distribuert funksjonalitet
- Integrert funksjonalitet
- RubReg som databaseprogram
Kildens flytende struktur
- Organiseringen av datamengden
- Formattering og typefisering
RubRegs funksjonalitet
- Oversikt
- Blaing i data
- Registrering og redigering av data
- Gjennomgående endring av felt
- Søking
- Gruppering av poster, Utvalg
- Frekvensbaserte utvalg
- Ordning av poster, Sortering
- Postindeks
- Eksport og Import
- Rapportering
- Frekvenstelling
- Krysstabell
- Register
- Lenking
RubRegs grensesnitt
- Det logiske skjemaet
- Det grafiske skjemaet
- Alternative skjema
- Tabell og zoomet felt
- Oppsetting av skjema
Filorganisering og datastruktur
- Filorganisering
- Post- og feltformatet
RubReg-konseptet
 

Bakgrunn

 

Kort historikk

Bruk av datamskinen i humanistisk forskning har en historie like lang som datamaskinen selv. Alt tidlig i denne historien gikk de humanistiske forskerne inn og tok hånd om deler av de myke sidene ved teknologiutviklingen. Innsatsen kunne variere fra utviklingen av små enkle programmer for opptelling av data til utviklingen av hele databseprogrammer for humanistiske kildemateriale. (I tillegg gir logikere og lingvister betydelige bidrag til utviklingen av informasjonsteknologien på et mer generelt plan, men det er en annen historie.)

Programmet RubReg ble i utgangspunktet utviklet for å ta vare på de spesielle behov historieforskere har i forbindelse med registrering og behandling av kilder - typisk kirkebøker og eldre folketellinger.

Utviklingen ble startet av Kåre A. Andersen tidlig på 1980-tallet.
De aller første versjonene av programmet ble skrevet for UiOs daværende mainframe-maskin DEC-10, men utviklingen ble raskt overført til DOS-maskiner.
I 1990 startet Asbjørn Brændeland utviklingen av en versjon av RubReg for Macintosh.

Andersen og Brændeland arbeidet på 80-tallet ved HF-Data som var en kombinert brukertjeneste, utviklingssenter og undervisningsinstitusjon for IT ved Det historisk-filosofiske fakultet ved Universitetet i Oslo. Institusjonen er nå tatt opp i Institutt for lingvistiske fag der Andersen og Brændeland fremdeles forestår utvikling og undervisning innenfor området bruk av datamaskiner i humanistisk forskning.
Innhold

Den humanistiske databehandlers behov

Det man fremfor alt ønsket seg i forbindelse med databehandling av kilder for humanistisk forskning, var å kunne

• automatisere databehandlingen så langt det lot seg gjøre uten samtidig å ødelegge forskningsprosessens iboende dynamikk (vekselvirkningen mellom det å se data i sin sammenheng, og det å lære mer om sammenhengen gjennom de data man ser),

• tillate behandling av de ulike data i en kilde ut fra en ad hoc bestemmelse av deres typer og formater,

• optimalisere organiseringen av data fra kilder med stor variasjon i postenes størrelse,

• distribuere databehandlingen mellom enkeltfunksjoner som hver for seg la et minimum av føringer på de tilsvarende delene av forskningsprosessen, og

• integrere de ulike databehandlingsfunksjonene innenfor ett ensartet grensesnitt.

(Den uhøytidelige undertittelen på introduksjonssiden henspiller delvis på denne behovslisten, og delvis på Kåre A. Andersens artikkel Blantforsknigsspiraler, hermeneutiske sirkler og firkantedeedb-løsninger. [1990].)
Innhold

Hermeneutisk sirkularitet vs programmert linearitet

Den humanistiske forskningsprosessens iboende dynamikk består i vekselvirkningen mellom det å se data i sin sammenheng, og det å lære mer om sammenhengen gjennom de data man ser. Dette beskrives bl.a. som den hermeneutiske sirkel. Automatisk databehandling kan introdusere en klargjørende linearitet i kildegranskningen, men forfølges en linje for langt, skjærer man ut av den hermeneutiske sirkel med fare for å ende opp med almene, men lite interessante forklaringer av utvendige aspekter ved kilden, i stedet for en tolkning av kildens mening (dette er foråvidt en fare som hefter ved den lineære betraktningen i og for seg — uavhengig av i hvilken grad betraktningene er understøttet av automatiserte beregninger). Denne problemstillingen diskuteres mer inngående i Andersen [1989].
Innhold

Ad hoc bestemmelse av datatyper

Data i historiske kilder har ofte et delvis fritt format både i den forstand at man ikke alltid finner faste felter som kan identifiseres direkte ut fra kildens layout, og i den forstand at dataformatet i de enkelte feltene kan variere slik at f.eks. datoer av og til skrives med tall og av og til med bokstaver. Tradisjonelle databasesystemer stiller krav til defineringen av databasen mht. post- og feltinndeling og angivelse av felttyper som gjør det i prinsippet umulig å sette opp en base der slike data er representert direkte. Skulle man bruke et tradisjonelt system, måtte man enten tolke og skrive om noen av dataene eller utelukke data som ikke svarte til den ene eller andre forhåndsdefinerte typen. Et slikt system har imidlertid den styrken at den typemessige ensrettingen muliggjør effektiv og søking, sortering og opptelling etter differensierte typeavhengige kriterier. Det man ønsket seg var et et program som i utgangspunktet tillot en blanding av alle typer data innenfor samme rubrikk, men som i neste omgang gjorde det mulig å søke etter, sortere og telle opp verdier på grunnlag av ad hoc bestemmelser av datatypene tilsvarende ulike synvinkler på et materiale.
Innhold

Dataformater og plassutnyttelse

I mange historiske kilder der data i utgangspunktet har fast format, kan antallet utfylte felt variere sterkt mellom de ulike postene. I andre kilder der faste data som steds- og tidsangivelser og navn på hovedpersoner er blandet med med fri tekst, vil en rubrisert kildetranskripsjon kunne inneholde felt av svært varierende lengde. Dette gjør det nødvendig å utnytte plassen optimalt ved organiseringen av data både på fil og i datamaskinens hukommelse.
I et tradisjonelt system vil data gjerne være organisert i poster og felt med faste lengder.
Et slikt system gjør det enkelt å aksessere gitte data, siden posisjonen til et gitt felt i en gitt post er en direkte funksjon av de faste lengdene og postens og feltets numre. I flere programmeringsspråk er denne funksjonaliteten bygget direkte inn i språket ved dets forhåndsdefinerte typer og standardrutiner. For et materiale med sterkt varierende postlengder, ville imidlertid bruken av et slikt system føre til et urimelig stort plassforbruk både på disk og i maskinens hukommelse. Det man ønsket seg var et et program der data ble organisert slik at hverken datafilen eller datastrukturen i maskinens hukommelse inneholdt flere tegn enn kilden, samtidig som programmet muliggjorde direkte aksess til gitte poster og felt.
Innhold

Distribuert funksjonalitet

Tradisjonelle databasesytemer, statistikkpakker og andre analyseverktøy krevde gjerne en detaljert og omfattende spesifikasjon av inndata. Dette ga tilsvarende detaljerte og omfattende utdata hvorav det meste kanskje var uten interesse for forskeren. Vel så viktig var det imidlertid at dette tvang forskeren inn i et forarbeid som i verste fall kunne bringe forskningsprosessen av sporet. Data måtte tilrettelegges, og forskeren måtte sette seg inn i de metodiske problemstillingene som lå implisitt i de tilgjengelige programmene. Nå kan tilretteleggelsen av data i seg selv være klargjørende, idet det kan åpenbare tidligere upåaktede relasjoner eller mangelen på antatte relasjoner. Det kan også være klargjørende å sette seg inn i metodikken til et datamaskinprogram, forsåvidt som det viser hvordan og i hvilken grad visse metoder kan operasjonaliseres. Problemet var at forskerens innsats for å tilrettelegge data og lære seg å bruke et programmer kunne nå et nivå hvorfra en nedstigning (eller oppstigning — avhengig av perspektivet) ikke lenger var mulig. Det forberedende arbeidet fikk en egenverdi i kraft av sitt blotte omfang.
Det man ønsket seg var et program som
- ikke krevde mer enn et minimum av tilretteleggelse av data i utgangspunktet,
- lot eventuell ytterligere tilretteleggelse av data bli en funksjon av forskningsprosessen og ikke omvendt
- hadde enkle funksjoner for søking, sortering og statistikk som i seg selv ikke krevde noen tilretteleggelse av data.
Innhold

Integrert funksjonalitet

Det mest synlige motivet for å utvikle et program som RubReg lå, rent historisk, i det nærmest fryktinngytende grensesnittet den humanistiske forsker måtte forhold seg til ved maskinell registrering og behandling av data langt inn på 1980-tallet.
Det logiske grensesnittet kunne være svært uryddig. I den grad de foreliggende databasesystemer var uegnet for historisk kildebehandling, måtte forskeren forholde seg til en serie ulike programmer for registrering, organisering og analyse av data — typisk en linjeorientert editor for registrering av data, et hjemmesnekret program for preparering av data, operativsystemets sorteringsfunksjon for ordning av data, og en statistikkpakke for analyse av data.
Det logiske grensesnittet var under enhver omstendighet nokså ugjennomtrengelig for den alminnelige humanistiske forsker. Både operativsystemet og de ulike programsystemene var styrt av tastede kommandoer som kunne, og i visse tilfeller måtte, spesifiseres ved mer eller mindre komplekse tegnstrenger. Dersom man ikke brukte de aktuelle systemene daglig over lang tid, var man stort sett nødt til å konsultere lite lesevennlige brukerveiledninger for hvert eneste skritt i prosessen.
Til alt overmål var selve det fysiske grensesnittet svært lite bekvemt. Med 60-og 70-tallets hullkortlesere og 70- og 80-tallets skrivende terminaler og linjeorienterte skjermterminaler gikk faktisk mye av registreringsarbeidet med til å telle seg frem til feltenes posisjoner i innmatingsmediet.
Det man ønsket seg var et program som
- integrerte fleste mulig av de funksjonene forskeren kunne tenkes å ønske seg, og forøvrig
- tillot en friksjonsfri utveksling av data med andre programmer
- hadde et tilnærmet uniformt grensesnitt for alle programmets funksjoner, og
- hadde et grafisk grensesnitt der bruker selv kunne utforme detaljene mht. feltenes visuelle plassering og form.
Innhold

RubReg som databaseprogram

Den generelle karakteristikken som passer best på RubReg er databaseprogram.
Siden utviklingen av RubReg startet på begynnelsen av 80-tallet, har både maskin- og programvaretilbud utviklet seg slik at mange av de ønskene som er nevnt over, er realisert hver for seg, eller også mer eller mindre samlet i kommersielle systemer. Spesielt gjelder dette programmer som tillater kombinasjon av faste felt og fritekst. Er kildene tilstrekkelig ryddige, vil et mer tradisjonelt databaseprogram som forutsetter reelt faste formater (slik at det er samsvar mellom de definerte og de faktiske datatyper og felt- og postlengder) i visse henssender kanskje være vel så effektivt som RubReg.
RubReg er imidlertid fremdeles det eneste programmet vi kjenner til som tilfredstiller alle de kravene vi har listet opp over.
RubReg kan dessuten på sin side være et alternativ til andre systemer også utenfor en humanistisk forskningssammenheng. Programmet egner seg godt for behandling av alle typer rubriserbare data. Med rubriserbare data mener vi data som har en gjennomgående struktur — medlemskartotek, saksregistre, o.l., såvel som data med mer eller mindre fast struktur — kontorjournaler, private dagbøker og andre former for journaler, protokoller, notatsamlinger o.l.
Innhold

 

Den humanistiske kildens flytende struktur

Organiseringen av datamangden

Datamengden i en kilde kan organiseres på ulike måter mer eller mindre uavhengig av kildens opprinnelige ytre struktur. En ordning kan bl.a. bidra til å øke gjenfinningsgraden for visse data, men i humanistisk forskning er de interessante ordningene de som gir kilden mening i den ene eller andre sammenheng. Meningen til en kilde er ikke objektiv og faktisk, men en funksjon av bl.a. forskerens egen aktivitet. Den yttre struktur kilden måtte ha, er ikke uten betydning, men den struktur forskeren legger på kilden ved å anlegge en bestemt innfallsvinkel, er minst like viktig.
I RubReg er det lagt vekt på at kildedata ved enkle håndgrep skal kunne ordnes på ulike skiftende måter. For å konkretisere ulike alternative innfallsvinkler skal data kunne grupperes, sorteres, telles opp og formatteres uten besvær og bindinger. Resultatene av de ulike konkretiseringer skal kunne kastes, holdes i mente eller arkiveres og eventuelt deretter sammenkobles, sammenlignes og kontrasteres.
Den sentrale komponenten i den vedvarende struktureringen av kildedata er utvalget.  Et utvalg av poster fra en kilde vil i utgangspunktet være basert på et enkelt søk eller en frekvenstelling og det kan i neste omgang være modifisert gjennom nye inkluderende eller ekskluderende søk og innlemmelse eller fjerning av enkeltvise poster.
Et foreliggende utvalg kan i seg selv gjøres til gjenstand for ny strukturering ved at det danner utgangspunkt for et nytt utvalg, eller ved at det sorteres, frekvenstelles eller formateres.
Et foreliggende utvalg kan også benyttes som et kraftigere virkemiddel for redigering av kildedata.
Innhold

Formattering og typefisering av data

Grunnoperasjoner i behandling av data er (etter registrering og redigering) søk, sortering, opptelling og rapportering.
I utgangspunktet er alle data i en RubReg-fil uspesifiserte, slik at det i prinsippet er mulig å legge inn data av en hvilken som helst type hvor som helst i en datafil. (Riktignok kan man i RubReg for Macintosh spesifisere et felts datatype til f.eks.heltall, men man kan samtidig sette kontrollnivået ved registrering slik at alle data tillates). Et felts type er fra forskerens synspunkt mest interessant når data skal analyseres. Hvilken type man ønsker å gi et felt, vil kunne variere med ulike innfalssvinkler til samme materiale. RubReg tillater derfor at et felts datatype spesifiseres ad hoc i forbindelse med alle grunnoperasjoner.
Vi ønsker f.eks. å lete etter et bestemt tall i et strengfelt (uspesifisert felt), slik at et søk etter tallet 2 gir tilslag for strengen 'X2Y', men ikke for strengen 'X123Y' (når X og Y er strenger uten sifre — evt. tomme strenger); eller vi ønsker å lete etter en bestemt sifferstreng i et tallfelt slik at et søk etter strengen '2' gir tilslag både for tallene 2 og 123.
Tilsvarende kan vi mht. sortering og opptelling f.eks. spesifisere strengfelt som et tallfelt slik at strengen 'X2Y' rangeres foran strengen 'X123Y'; eller vi kan spesifisere et tallfelt som et strengfelt, slik at f.eks. tallet 123 rangeres foran tallet 2.

Også den logiske feltinndelingen i en post, vil kunne variere med innfalssvinkelen. Det kan være ønskelig å betrakte to eller flere felt som ett, eller å betrakte en del av et felt som et eget felt.
Sammensetning av flere felt til ett er mulig i RubReg (som i de fleste systemer) ved alle grunnoperasjoner.
Spesifisering av subfelt er mulig i forbindelse med sortering, opptelling og rapportering. Et subfelt spesifiseres ved angivelse av lengde og startposisjon relativt til hele feltets begynnelse eller slutt eller til eventuelle andre typebestemte referansepunkter (plassen etter siste siffer for heltall, desimalkommaet for relle tall og skillene mellom dag, måned og år for datoer).
Det er i prinsippet også mulig å spesifisere subfelt ved søk, men dette er ikke implementert i noen foreliggende versjonen av RubReg (riktignok kan man søke etter første del, siste del, en hvilken som helst del eller et helt felt, men altså ikke etter et posisjonsbestemt subfelt).
Innhold


 

RubRegs funksjonalitet

Oversikt

De viktigste funksjonene i RubReg er:
Innhold

Blaing i data

Man kan bla i enkeltfelt, enkeltposter og sider med felt og poster fordelt på kolonner og linjer (tabellformat).
For blaingen brukes først og fremst Macintosh standard grensesnitt med rullesjakter og piltaster.
I tillegg kan man
- bla til en gitt post ved å angi dens nummer,
- søke etter verdier med automatisk fremrulling og markering av eventuelle funn som resultat (se Søking under),
- klikke i en eventuell foreliggende indeks med feltverdier (se Postindeks under) med fremrulling til den posten der den klikkede verdien forekommer, som resultat, og
- klikke i et lenkingsfelt assossiert til en gitt post.
Innhold

Registrering og redigering av data

Dersom data ikke importeres fra en foreliggende fil, må de skrives inn feltvis og postvis. Ved løpende registrering skrives den ene posten inn etter den andre inntil prosessen avbrytes. Postene arkiveres i den rekkefølgen de skrives inn, og når løpende registrering eventuelt gjenopptas, legges nye poster etter tidligere registrerte.
Rekkefølgen er forutsetningsvis valgt slik at den svarer til postenes rekkefølge i kilden. Den kan imidlertid endres ved vilkårlig innsetting eller klipping, kopiering og innliming av enkeltposter.
Forøvrig kan data i registrerte poster endres, uten at postfølgen endres.
Løpende registrering, innsetting av enkeltpost og endring av enkeltpost kan utføres innenfor alle de ulike grafiske grensesnitt (feltvis, postvis eller i tabell).
Innhold

Standardisering av feltverdier — Gjennomgående endring av felt

Data kan redigeres en bloc for en hel fil eller et utvalg av poster i henhold til regelmessigheter som bruker har observert, eller som erfaringsmessig gjelder for visse kildetyper. Redigeringen spesifiseres feltvis til ett av:
1) Innsetting av en gitt verdi i alle poster.
2) Sletting av innholdet i alle poster.
3) Kopiering av feltets innhold fra foregående post dersom samme felt i løpende post er tomt (kopieringen utføres f.o.m. første ikke-tomme felt, og gjentas deretter for eventuelle sekvenser av etterfølgende tomme felt).
4) Sletting av innholdet i det gitte feltet dersom det er identisk med innholdet i samme felt i foregående post.
5) Øking av feltverdien i et heltallsfelt med 1 i forhold til verdien i foregående felt, hvis samme felt i løpende post er tomt (er feltet i utvalgets første post tomt, får det verdien 1, og verdiene i eventuelle etterfølgende tomme felt økes i forhold til dette).
Standardiseringsmåtene 1) og 2) kan typisk brukes for å legge inn samme verdi i et kodefelt i et utvalg av poster med verdier som tilfredstiller et gitt kriterium.
Standardiseringsmåtene 3)..5) svarer til regelmessigheter i forholdet mellom visse feltverdier som man bl.a. finner i eldre folketellinger.
Innhold

Søking

Man kan søke etter enkeltstrenger hvor som helst i et datasett (på tvers av feltskiller), eller man kan søke etter verdier i et gitt felt eller en kombinasjon av gitte felt. Forut for et søk i gitte felt, settes det opp en såkalt søkeprofil der de aktuelle verdiene angis sammen med ulike parametre for hver søkestreng.
To av parametrene er også relevante for søking på tvers av feltskiller. Disse gjelder
- "case"-sensitivitet (om det skal skilles mellom små og store bokstaver eller ikke) og
- ordskille-sensitivitet (om det bare skal søkes etter hele ord eller ikke).
De øvrige parametrene er bare relevante for de enkelte feltene i en profil. Disse gjelder
- datatypen (se over),
- hvilken del av feltet som må matche søket (hele, fronten, enden, eller hva som helst), og
- sammenligningsoperatoren (=, <>, <, <=, >, >=)

Både ved søking på tvers av feltskiller og i gitte felt kan det benyttes såkalt jokernotasjon. Har man valgt dette, vil tre tegn være reservert for spesielle tolkninger under søket. (Her vises standardverdiene for disse tegnene. Om ønskelig kan man velge andre jokertegn).
'?' tolkes som et hvilket som helst enkelttegn, slik at f.eks. 'G?rd' gir tilslag for 'Gard' og 'Gård' (og for den saks skyld 'Gerd' og 'Gyrd').
'*' tolkes som en hvilken som helst streng, slik at f.eks.  'G*rd' gir tilslag for, 'Gard', 'Gård' og 'Gaard' (og for den saks skyld for 'Grd' og 'Geirangerfjord').
'/' tolkes som skille mellom alternativer, slik at f.eks. 'Gard/Gård/Gaard' gir tilslag for 'Gard', 'Gård' og 'Gaard'.
Alle tre jokertegn kan brukes innenfor ett og samme søk. I praksis er det imidlertid satt en grense på 7 alternative søkestrenger og 7 vilkårlig atskilte strenger (skilt med '*') innenfor hver alternative søkestreng.
Innhold

Gruppering av poster — Utvalg

Et utvalg vil i utgangspunktet være basert på enten et søk eller en frekvenstelling (se under). Utvalget gjøres enten fra hele datasettet eller fra et allerede foreliggende utvalg.
Når et utvalg foreligger, kan det modifiseres på flere måter.
- Det kan utvides eller reduseres på grunnlag av en ny søkeprofil.
- Enkeltposter kan legges til eller fjernes fra utvalget.
Innhold

Frekvensbaserte utvalg

Et utvalg kan genereres på grunnlag av frekvenstelling (se under). Funksjonen er spesielt nyttig for analyse av data der antatt samme fenomen eller individ er angitt ved varierende skrivemåter. En frekvenstelling for det relevante feltet gir en liste med normalt betydelig færre verdier enn det er poster i datasettet. Listen presenteres i et grensesnitt som gjør det enkelt å velge de verdier som antas å identifisere samme fenomen eller individ. Numrene til de postene i datasettet der de valgte verdiene forekommer, legges inn i en egen utvalgsfil.
Innhold

Ordning av poster — Sortering

Postene i et utvalg eller i hele datsettet kan sorterers mht. ett enkelt felt, en feltdel eller en kombinasjon av felt/feltdeler. På samme måte som for søk (og utvelgelse), baseres en sortering på en bestemt profil.
En sorteringsprofil settes opp ved å angi én eller flere deler av en sorteringsnøkkel. Hver enkelt del hentes fra ett felt og rekkefølgen til delene i nøkkelen angis vha. bokstaver.
En nøkkeldel kan bestå av et helt felt eller et subfelt. Et subfelt angis ved lengde og posisjon relativt til begynnelsen eller slutten av feltet eller et typebestemt referansepunkt i feltet (se over). Parametrene for hvert enkelt felt i profilen gjelder
- datatype (se over)
- "case"-sensitivitet
- sorteringsretning (forfra eller bakfra — gjelder også subfeltets referansepunkt)
- sorteringsorden (stigende eller synkende)
Innhold

Postindeks

Man kan sette opp en profil for indeksering av et helt datasett på samme måte som man setter opp en sorteringsprofil. Indeksen vises i en egen del av vinduet med én nøkkel for hver post i alfabetisk orden, og slik at like nøkler er nummerert innbyrdes. Et klikk i en linje i en åpen indeksen bringer frem den posten der den aktuelle feltverdien forekommer.
Innhold

Eksport og Import

Data fra en RubReg-fil kan eksporteres til vanlige tekstfiler og med fritt valgte felt- og postskiller. Man kan enten eksportere alle feltdata eller data fra utvalgte felt i fritt valgt rekkefølge.
Data kan også importeres fra vanlige tekstfiler med gitte felt- og postskiller. Siden det etterhvert finnes en god del maskinregistrerte kilder, er dette en nokså vanlig måte å legge data inn i en RubReg-fil på, men den forutsetter at man har satt opp et skjema med den feltrekkefølge man forventer å finne i importfilen.
Ved import og eksport brukes et såkalt utvekslingsformat der data er pakket sammen mellom felt- og postskilletegn. Feltskillet skal være et ikke-alfanumerisk tegn, tabulator eller CR (Carriage Return). Postskillet skal være et ikke-alfanumerisk tegn eller CR alene eller et ikke-alfanumerisk tegn fulgt av CR.
Med disse valgmulighetene kan man finne riktig utvekslingsformatet for de fleste programmer som har tilsvarende eksport- og importfunskjoner. De dekker også alle de varianter som er og har vært i bruk ved rubrikkdefinert kilderegistrering i norsk sammenheng.
Innhold

Rapportering

En rapport vil normalt være en utskrift av utvalgte feltdata i en lay-out som er hensiktsmessig for lesing fra skjerm eller papir. Man setter opp rapportprofilen på tilsvarende måte som for sortering, men i rapporten fordeles verdiene i de enkelte feltene på kolonner. Man kan også lage rapporter med egne formater som brukes av andre programmer - f.eks. MS Word (så langt det eneste spesialformatet).
Innhold

Frekvenstelling

En frekvenstelling baseres på en profil som settes opp på samme måte som en sorteringsprofil. Tellingen kan altså gjøres for et enkelt felt, en feltdel eller en kombinasjon av felt/feltdeler, med feltspesifikke parametre for datatype, case-sensitivitetet, og sorteringsretning (sorteringsorden er ikke relevant ved frekvenstelling).
Innhold

Krysstabell

En frekvenstelling kan utføres for to atskilte felt slik at verdiene for disse krysses mot hverandre (profilen skal altså omfatte nøyaktig to felt, og det er dermed ikke mulig å kombinere feltverdier for de kryssede variablene). Resultatet vises i en matrise der verdiene fra de to feltene er fordelt hhv. langs den horisontale og den vertikale aksen.
Innhold

Register

Dersom data inneholder lokaliseringsreferanser til en kilde (f.eks. folionumre), og disse er kodet i et bestemt format, kan man få laget et register over innholdet i gitte felt (gitt ved en registerprofil som settes opp på tilsvarende måte som profiler for søk, sortering, etc.).
Kodeformatet er en modifisert utgave av det formatet som er beskrevet i Tingbøker og edb. Avskrivning og registrering, [Marthinsen og Sandvik 1990]. (Formatet ble modifisert for å unngå mulige tvetydigheter ved automatiseringen av registerfunksjonen.)
Registret vil inneholde oppslagsord fra datafila sammen med henvisninger til de stedene i kilden der oppslagsordene forekommer. De oppslagsordene som skal med i et register, må være gitt i datafila som hele felt eller som deler av kodede felt. Oppslagsordenes referanser kan være gitt sammen med ordene i de postene der de forekommer — enten i samme felt eller i et dedisert referansefelt. Oppslagsordene kan kodes på to nivåer slik at visse oppslagsord er underordnet andre. Et register med oppslagsord på to nivåer, vil være sortert primært mht. hovedoppslagsordene og sekundært mht. de underordnede oppslagsordene, slik at det etter hvert hovedord vil følge en sortert liste med underordnede ord.
Innhold

Lenking

En frittstående tekst i et grafisk skjema kan defineres som en lenkingstektst. En slik tekst kan under visningen av data knyttes fast til et skjema, eller den kan knyttes til enkeltposter. Målet for en lenkingstekst kan være en gitt post i, et gitt skjema for, eller et gitt utvalg fra løpende datafil, en annen datafil, evt. spesifisert mht. postnr, skjema og/eller utvalg, eller en tekstfil.
Innhold

 
 

RubRegs grensesnitt

Det logiske skjemaet

For registrering og behandling av data må det alltid foreligge et skjema. Skjemaet settes opp vha. RubRegs skjemadefineringsvindu der de enkelte feltene og deres ledetekster tegnes inn — evt. sammen med andre fasttekstfelter. Skjemaet bestemmer både rekkefølgen til feltene i posten, og det grafiske grensesnittet for bl.a. lesing og redigering av postenes data.
Innhold

Det grafiske skjemaet

Grunnformen til det grafiske skjemaet er et kort med ledetekster og innskrivingsfelt.
Hvert enkelt innskrivingsfelt kan være uten eller med linjering, det kan være uten ramme eller ha én av tre ulike rammer, og det kan ha en egen rullesjakt.
Hvert innskrivingsfelt og hver faste tekst kan gis sin egen font.
På et kort kan det dessuten forekommer frittstående faste tekster i tillegg til ledetekstene, og frittstående rammer som kan plasseres rundt grupper av felt og tilhørende ledetekster. En egen type frittstående faste tekster er lenkingstektstene (se over).
Innhold

Alternative grafiske skjema

Til et foreliggende grafisk skjema  kan det defineres alternativer. Det skjema som ble satt opp i utgangspunktet kalles standardskjemaet, og eventuelle alternative skjema navngis etterhvert som det settes opp. I et alternativt skjema kan feltrammenes posisjon, bredde og høyde endres, og ett eller flere felt kan skjules.
Innhold

Tabell og zoomet felt

I tillegg til kortformatet, kan det zoomede feltet og tabellformatet brukes både under lesing og registrering av data. (En oppsetting av en profil starter alltid i kortformatet. Her kan man skifte til zoomet felt, men ikke til tabell.)

Når et felt zoomes inn, fyller feltet det meste av vinduet alene.

I tabellformatet vises flere poster av gangen linjevis. Feltene vises i kolonner i den rekkefølgen de ble innført i skjemaet. Kolonnenes bredder kan endres fritt. Er et alternativt skjema åpent når man velger tabellformat, vil eventuelle skjulte felt forbli skjult. Med utgangspunkt i standardskjemaet kan man fritt skjule og hente frem kolonner.
Innhold

Oppsetting og redigering av skjema

Skjemaet settes opp ved at de enkelte datafeltene og de tilhørende ledetekstene tegnes og skrives inn i vinduet. Feltene får i utgangspunktet en standard rammetype, font og datatype. Under oppsettingen kan man endre feltenes nummerorden fritt. Når et nyoppsett skjema arkiveres, opprettes det en ny fil der skjemaet plasseres i ressursgrenen, mens datagrenen er tom. For et skjema som er tatt i bruk (slik at datagrenen i den filen der skjemaet er lagret, ikke er tom), kan ikke feltenes nummerorden endres, men man kan fritt endre feltenes datatyper samt deres fonter, rammetyper og plasseringer.
Redigeringen av et skjema kan utføres i alle sammenhenger (lesing og registrering av data og oppsetting av profiler).
Innhold

 
 

RubRegs filorganisering og datastrukturer

RubRegs filorganisering og datastruktur er utformet både med henblikk på effektiv plassutnyttelse og rask aksess av data. I utgangspunket er filorganiseringen sekvensiell med et minimum av overhead for de enkelte poster og felt. I tillegg benyttes indeksfiler for direkte aksess av poster.

Filer

En datafil er alltid knyttet til et skjema, slik at rekkefølgen til feltene i postene er entydig bestemt. Skjema lagres i en egen gren i datafilen.
Postene lagres fortløpende i den rekkefølgen de skrives inn i utgangspunktet. Lengden til en post er gitt ved antall tegn i posten. For å holde rede på hvor i datafilen de enkelte postene ligger, brukes det en egen såkalt postreferansefil.
For en datafil kan det lages ett eller flere utvalg. Opprettelsen av et utvalg fører ikke til at det lagres flere data. I stedet opprettes det en egen referansefil som angir hvilke poster i datafilen som tilhører utvalget.
Innhold

Poster og felt

Innenfor en post lagres feltene fortløpende sammen med informasjon om hvert felts nummer og lengde. Det lagres ingen informasjon om uutfylte felt (de uutfylte feltene i en gitt post vil være de som ikke er repersentert ved noe feltnummer i posten). Posten innledes med to bytes som angir postlengden. Hvert felt med data innledes med tre bytes hvorav det første angir feltets nummer og de to andre angir feltets lengde. Dette formatet benyttes både på fil og for representasjon av poster i programmet. (i programmet benyttes dessuten ulike tilleggsstrukturer for å holde rede på feltdata under visse operasjoner).
Innhold

   
 

RubReg-konseptet — Utvikling og opphavsrett

RubReg er i utgangspunktet utviklet for DOS-maskiner av Kåre A. Andersen som har opphavsretten til RubReg-konseptet.

Konseptet er definert ved en nærmere beskrivelse av RubRegs egenskaper angående

Konseptet må sies å være realisert i et program som besitter de egenskapene som er beskrevet under 4 eller flere av disse punktene i dokumentet Bruken av "RubReg" som navn på datamaskinprogrammer.
Bruken av RubReg som programnavn er knyttet ekslusivt til RubReg-konseptet, og konseptet kan, i henhold til gjeldende lover om opphavsrett, ikke gjøres til gjenstand for etterligninger uten etter avtale med Kåre A. Andersen.

RubReg for Macintosh er utviklet av Asbjørn Brændeland etter avtale med Kåre A. Andersen.
Innhold