Gå til innhold
Arkivverket

[#11888] Ny måte å visa kyrkjeboksdatabasar


Gjest Bente Kopperdal
 Del

Recommended Posts

Gjest Sissil Bruun Sørensen

Jeg er enig med Geir i at det først å fremst er viktig å fjerne alle muligheter/oppfordring til tolkning av dokumentene.Intensjonen med denne malen er vel at den skal være utgangspunktet for visningen i DA? Eller har jeg misforstått?Jeg synes også at kolonnene som står i kirkebøkene bør være et rimelig utgangspunkt. Kilder i fritekst må under alle omstendigheter tilpasses. En slik inndeling vil også forenkle inntasting av kirkebøker fra 1800-tallet.For meg er det ikke noe poeng at man sparer noen tastetrykk ved å utelate felter. Men jeg ser utmerket godt at DA vil få et problem ved mange felt. Som bruker av DA ser jeg heller ikke noe poeng i en rekke av feltene som er nevnt. Tvert imot synes jeg få felt er en absolutt fordel hvis jeg skal søke etter informasjon utenom de 'faste' kolonnene. Og som grunnlag for statistikker kan man benytte funksjonen 'inneheld' og deretter plukklister. Men det er vel kanskje til bruk utenom DA at behovet for flere felt er tilstede?

Lenke til kommentar
Del på andre sider

Gjest Jan Oldervoll

Vårt utganspunkt er følgjande:- Malen skal liggja så når opp til orignalen som mogleg.- Malen skal vera slik at det ikkje kostar altfor mykje arbeid å konvertera til eit format som gjer det tenleg å analysera ved hjelp av programvaren vår.Me følgjer debatten mes store interesse.Jan

Lenke til kommentar
Del på andre sider

Gjest Sissil Bruun Sørensen

En ting som står i kirkebøkene som jeg skriver av fram til midten av 1700-tallet, men som ikke er nevnt i malen, er hvilket kjønn faddere har. Denne informasjonen synes jeg det er lite hensiktsmessig å legge inn i andre felt. Men jeg ser heller ikke den store nytteverdien av å ha den med. Riktignok er det navn hvor man ikke kan si umiddelbart om dette er kvinne eller mann, men jeg ser ingen problemer med å legge disse få opplysningene inn i et felles merknadsfelt. Sorteringsmessig kan jeg heller ikke se noen gevinst i et kjønnsfelt for faddere så lenge de samme personene gjentas flere ganger. Men her er det altså systematisk informasjon fra kirkebøkene som ikke kommer med. Synspunkter?

Lenke til kommentar
Del på andre sider

Gjest Ketil Firing Hanssen

DIS-Norge kommer snart med registeringsprogrammet 'Augustus' - så vidt jeg vet basert på 4G. Dessuten jobber vel Arkivverket med Histform for kirkebøker som skal rette opp endel av svakhetene ved 4G. Er Digitalarkivet involvert i disse prosjektene?

Lenke til kommentar
Del på andre sider

Gjest Bente Kopperdal

Digitalarkivet er ikkje med i utarbeidinga av Augustus eller i arbeidet med histform for kyrkjebøker. Den versjonen av Augustus som kjem no baserer seg på Standard 4G, men seinare versjonar skal verta meir fleksible når det gjeld val av feltstruktur.Geir: Du har rett felta far/mor fødestad og fars og mors alder har falle ut i den versjonen du fekk, men dei skal altså vera med.

Lenke til kommentar
Del på andre sider

Gjest Ketil Firing Hanssen

I følge samarbeidsavtalen mellom DIS-Norge og Riksarkivaren, skal Standard 4G benyttes inntil Histoform for kirkebøker foreligger. Samtidig forplikter Arkivverket seg til å gjøre ferdigstilt materiale tilgjengelig for søk på internett. Betyr det at Digitalarkivets registreringsmal blir kompatibel med 4G/Histform?

Lenke til kommentar
Del på andre sider

Gjest Geir Thorud

Er det noen som vet hvilke organisasjoner som er involvert i arbeidet med 4G/Histform. Det overrasker meg at Digitalarkivet ikke er med.(Kommer tilbake på resten av diskusjonen senere)

Lenke til kommentar
Del på andre sider

Gjest Yngve Nedrebø

Digitalarkivet har så langt lagt ut nesten 3000 filer. Av disse er 611 kirkebokfiler. Rundt 50 av disse er levert etter noe som minner om Standard 4G. Vi får ellers levert filer i et utall ulike formater. Det er arbeidskrevende for oss. Mange av de filene vi får er små, noen hundre poster. Det betyr mye arbeid, og relativt liten gevinst.Standard 4G har ulike skjema for ulike kirkelige handlinger, og er svært oppstyltet, 114 felt i skjemaet for døpte, 53 felt i skjemaet for dødfødte. Det er en ekstrem oppdeling av noe som i kirkebokens skjema er oppdelt i 10-12 felt.Vår jobb er å legge databasene ut på web. Da må vi ta hensyn til de begrensninger som ligger i web-presentasjonssystemene. 114 felt lar seg vanskelig håndtere, og det er svært lite effektivt for den som skal søke i materialet. De verktøyene Digitalarkivet har til disposisjon kan presentere på web opp til rundt 40 felt. Man kan gjerne kreve at vi skal presentere 114 på 40, men da må det en betydelig konvertering til. Vi ønsker oss den prosessen så enkel som mulig, og vi ønsker oss filer på web som er så effektive i bruk som mulig.De registreringssystemene vi ønsker oss skal også være effektive. Jeg har drevet med edb-registrering i nesten 20 år, og jeg vet utmerket godt at strømlinjeforming av registreringsverktøyet er avgjørende for hvor kjapt og greit en jobb kan gjøres. Jeg er smertelig klar over at mange som driver i denne bransjen enten ikke bryr seg om effektivitet, eller ikke helt vet hvordan man da skal ordne seg. Men vi har budsjetter å forholde oss til, og har gjennom det krav på oss.Dersom vi ikke får filer som det er mulig for oss å jobbe videre med, vil vi selvsagt ikke kunne bruke tid på dem. Og skulle de avtaler som måtte være inngått komme i veien, så får vi forlange disse reforhandlet. Avtalen med DIS-Norge bør vi nok nå ved årsskiftet sette oss ned for å evaluere - se hva vi og Digitalarkivets brukere har fått for det det har kostet oss.Vi er også forbauset over hvordan enkelte organisasjoner og enkeltpersoner arbeider med sine standarder.

Lenke til kommentar
Del på andre sider

Gjest Ketil Firing Hanssen

Med den nye måten å presentere kirkebokregistreringer på, oppdelt i to posttyper og en post for hver person, er det vel mulig å presentere filer med over 100 felt? For dåp bruker 4G totalt 114 felt (inkl. 8 faddere og hjemmedøper). En personpost vil imidlertid ikke bestå av mer enn 10-15 felt. I tillegg kommer posttypen for den spesifikke handlingen, med omtrent like mange felt.Jeg kan derfor ikke se at antall felt begrenser muligheten for å publisere materialet på web, med effektive søkemuligheter. Registreringsmessig kan det stille seg annerledes, men dette kan løses med brukervennlige registreringsprogram.

Lenke til kommentar
Del på andre sider

Gjest Arild Kompelien

Jeg har i utgangspunktet mine meininger om hvordan jeg vil registrere, og mener det er viktig å hevde disse i en diskusjon, men håper jeg også er i stand til gi slipp på noe for å komme fram til en felles plattform. Er jo klar over at noen av synspunktene er flisespikkeri.Dette sagt nærmest i oppgitthet over at det ikke er mer samarbeid mellom de organisasjonene som arbeider med det samme. Litt synd i et lite land som Norge at hver organisasjon sitter på hver si tuve istedet for å slå ressursene sammen.

Lenke til kommentar
Del på andre sider

Gjest Geir Thorud

Om antall felter:Jeg forstår at DA har behov for å effektivisere utleggingen, men tror dette er mulig å gjøre på en annen nåte enn den som er forslått.Jeg mener man må skille mellom formatene som brukes ved utveksling av data, lagring i DAs databaser, mal i registreringsskjema, m.m. Det er avhengigheter mellom formatene, men de trenger ikke være like. På denne måten bør det være mulig å ha en standard for utveksling mellom mange typer systemer (ikke bare for innlevering i DA) som har mange detaljerte felt, samtidig som man definerer konverteringsregler til et internt format som brukes i DA - gjerne med færre felter.Jeg har selv konvertert over 100 kirkebok-baser fra bla 4G, og mener at det bør være mulig å lage konverteringsrutiner, for f.eks døpte, på maksimalt en dag - forutsatt at konverteringsreglene foreligger. Når dette er implementert skjer det dere kaller en betydelig konvertering fra utvekslingsformat til internt DA-format (eller format som ligner den foreslåtte malen) på sekunder vha noen tastetrykk.Man kan sogar la en slik konvertering skje hos avsender, men dette vil føre til at konverteringsrutinene må implementeres flere ganger (totalkostnaden øker) og DA mister kontrollen med (fleksibilitet) hvordan konverteringen skjer.Når folk legger ned hundrevis av timer for å registrere en bit av ei kirkebok, vil det meget uheldig at dette skal skje i et 40-felts format bare for å spare noen minutters arbeid i DA. Det er å gjøre som enkelte gjør i boksa når det er kaldt.Som Kjetil påpeker bør problemet med mange felt være løst med ny struktur i DA. Jeg aksepterer ikke at antall rubrikker i kirkeboka skal ha noen betydning for antallet i et utvekslingsformat, å sammenligne antall felter i de to har ingen mening uten at man knytter det opp mot praktiske konsekvenser. (Malen følger uansett ikke dette prinsippet på noen måte.)Forutsatt at DA har noen få dagsverk med f.eks. Access 'programmering' tilgjengelig for å lage konverteringsrutiner, så burde ikke dette være noe stort problem i det hele tatt.

Lenke til kommentar
Del på andre sider

Gjest Sissil Bruun Sørensen

Arrester meg hvis jeg tar feil, men jeg synes det virker som om det er en sammenblanding mellom egne, private behov og det som er DAs behov når det gjelder en ny standard.Først og fremst synes jeg vi bør respektere DAs prioritering av de ressurser de har til rådighet, både med hensyn til maskinkapasitet, konvertering og tilrettelegging, samt brukergrensesnitt. Vi kan være så enige eller uenige vi vil, men det er lite hensiktsmessig med demokratiske beslutninger på dette området.DA har et krav om at antall felter for registrering skal ligge så nær opp til originalen som mulig. For det første vil jo dette i seg selv i større grad være en kvalitetssikring av informasjonen som kan kontrolleres på en enkel og hensiktsmessig måte. For det andre er dette allerede en etablert standard for kirkebøkene i en gitt periode, slik at punchearbeidet blir enklere. For det tredje slipper man en rekke individuelle tolkninger av hvor data skal plasseres.Som bruker av DA vil jeg også foretrekke få, standardiserte felt for søk. Det gjelder forsåvidt alle typer systemer - det overordnede nivået må ikke være større enn at det er lett oversiktlig. Med de søkemulighetene som foreligger i DA er det jo heller ikke noe problem å søke etter informasjon i dybden dersom man ønsker det.Den foreslåtte standarden er oversiktlig, og den inneholder de feltene som brorparten av brukerne er på jakt etter. Derfor spør jeg, og det er mulig at jeg er treg som ikke har forstått det enda, men hva er gevinsten ved å ha så mange felt?

Lenke til kommentar
Del på andre sider

Gjest Geir Thorud

Til Sissil: Du er herved arrestert, jeg synes du kan avstå fra å karakterisere noe som 'private behov' - dette er ikke en passende måte å argumentere på. Det faktum at disse feltene allerede finnes i en defacto standard synes jeg borger for at dette ikke bare er private behov.Standarder fastsettes ofte ved demokratiske prossesser - mens andre bruker 'markedsmakt'. Jeg oppfatter utsending av utkastet for kommentar som at man vil ha en viss form for 'demokratisk' prosess, hvis ikke forstår jeg ikke hvorfor man ber om kommentarer. Jeg tror DA selv kan si ifra hva de ønsker på dette punkt. Problemet er at det ikke foregår noen offentlig prosess mht utarbeidelse av en ny 4G/Histform. Jeg har holdt på med internasjonal og nasjonal IT-standardisering i mer enn 10 år. Hvis det er offentlige myndigheter innvolvert i denne prosessen, så vil jeg karakterisere det som en meget uvanlig prossess hvis 4G/Histform ikke skal gjennom i det minste en høringsprosess før den ferdigstilles. Hvis vi nå får en mal fra DA og om et år eller så får en avvikende standard tredd ned over hodet - da har vi et problem.Forøvrig synes jeg diskusjonen har gitt oss en god forståelse av problemene. Ulempen er at problemene kan synes større enn de i realiteten er. Når man ser på det konkrete forslaget ligger det et sted mellom ytterpunktene i de prinsippene som har vært hevdet, så jeg tror ikke uenigheten nødvendigvis er så stor som man kan få inntrykk av ut fra prinsippdiskusjonen.Jeg mener svarene på det Sissil spør om står over.Det er forøvrig ikke min menig å belære Digitalarkivet, jeg bare prøver å få konkrete proposjoner på debatten ut fra egne erfaringer. Noen konkrete holdepunkter må man etablere ellers blir en slik diskusjon umulig.

Lenke til kommentar
Del på andre sider

Gjest Sissil Bruun Sørensen

Jeg synes det er svært relevant å skille mellom private behov (herunder også frivillige organisasjoner) og DA sine behov. Det er først og fremst viktig for å avgrense debatten til det dette gjelder - nemlig standarden som skal benyttes av DA. Jeg føler overhodet IKKE at dette var en upassende måte å argumentere på. Jeg tviler ikke et sekund på at DA klarer å argumentere for seg selv, men det må da være tillatt for andre å gi uttrykk for å være enige med DA?Min henvisning til behov for å bruke 'markedsmakt' (hvis vi kan bruke dette uttrykket i denne sammenheng), var myntet på forslaget om at DA skulle lage konverteringsprogram, forestå konverteringen osv. Jeg kan ikke forstå hvorfor DA skal bruke sine ressurser på slikt? Og når det gjelder utarbeidelse av standarden har da DA virkelig invitert til en demokratisk prosess!Jeg har fremdeles ikke fått svar på hva som er gevinsten ved å bruke mange felter.

Lenke til kommentar
Del på andre sider

Gjest Jan Oldervoll

Digitalarkivet prøver ikkje å laga nokon mal som alle skal forholda seg til under registrering. Me lagar ein mal som me skal brukar under UTLEGGJING. Prinsippet, slik me tenkjer, er at me skal ha eit sett med variablar me kan bruka for all kyrkjeboksinformasjon, enten det no er er døypte, gravlagde eller kva det no måtte vera. Frå dette sette av variablar lagar me så eit undersett for kvar kyrkjeleg handling. Så har me laga eit program for konvertering. Det fungerer på den måten at me får opp strukturen i databasen me har fått, G4, ein heimelaga struktur eller kva det no måtte vera, i venstre skjermhalvdel. I høgre halvdel har me vår struktur slik me har bestemt at han skal vera. Så 'mappar' me desse; bestemer kva framande variablar (ein eller fleire) som skal leggjast inn i 'våre' variablar. Når det er gjort trykkjer me på knappen og databasen blir generert. Resultetet av dette er at alle kyrkjeboksdatabasane vil vera så like som det går an å få dei, og at i alle fall variablar med likt innhald har same namn.Me kjem ikkje til å krevja at folk skal registrera etter denne malen; det må dei gjera som dei sjølve synest. Vårt krav er at me skal kunna konvertera til vårt format, utan altfor mykje arbeid. I tillegg meiner me at registreringa bør avspegla originalen så godt som mogeleg. Av begge desse grunnar synest eg lite om Geir sine 'tusen' felt. Det meste av kyrkjeboksmaterialet finst i kolonneoppdelte protokollar; i tabellar. Det redligaste er då å leggja dei ut i tilsvarande tabellar digitalt, med ein variable for kvar kolonne. Om nokon då har klipt desse kolonnene opp i mange felt står me overfor to problem; eit lite som består i at det kostar oss arbeid å lima dei saman og eit stort som består i at me limer dei saman på ein annan måte enn slik dei var i originalen. Dermed blir vår digitale utgåve av teljinga altfor forskjellig frå originalen.

Lenke til kommentar
Del på andre sider

Gjest Sissil Bruun Sørensen

Hva er hensikten med et eget felt for hjemmedøperen? Så vidt jeg kan se av forslaget til malen, er det kun avsatt ett felt til dette navnet. Vedkommende må dermed også plasseres som fadder for å være søkbar på lik linje med de øvrige fadderne. Dette finner jeg helt naturlig ettersom hun/han også er vitne til at dåpen har funnet sted. Så hvorfor et eget felt?

Lenke til kommentar
Del på andre sider

Gjest Sissil Bruun Sørensen

Jeg har lest alt du har skrevet nøye, og forsøkt å forstå nytteverdien, men jeg klarer ikke å se at nytteverdien oppveier ulempene. Jeg regner med at man hadde en målsetting og en vurdering av strukturen den gangen 4G ble utviklet. Det hadde vært greit å vite hvilke kriterier som ligger til grunn for hvert av valgene man gjorde.Jeg leste avsnittet du henviste til, og er like klok. Så lenge man legger inn alle data som er ført i kirkeboken, trenger man vel ikke noen huskeliste? Så langt jeg kan se, gir det også en bedre kvalitetskontroll både ved registrering, korrekturlesing og evt. senere revisjon dersom feltene følger tabellen i kirkeboken?At datoer bør være i egne felt, er jeg helt enig i. Og jeg kan utmerket godt se nytteverdien av å sette inn betegnelser for kjønn på barnet - selv om det ikke står oppført i kirkeboken. Men jeg kan ikke forstå nytteverdien av å samle navn på hjemmedøpere i ett felt. Hva slags informasjon skal man hente ut av dette feltet?

Lenke til kommentar
Del på andre sider

Gjest Arild Kompelien

For en såkalt glad amatør klargjør Jans siste innlegg ei side av debatten. Siden DA først og fremst snakker om en mal som de bruker til å konvertere data før de legges ut, er det selvsagt viktig å vite hvordan denne malen takler dataene i forhold til hvilket format eller program de er registrert i? Hva er lett å konvertere fra og hva skaper problemer? Og foregår det samarbeid med DIS-Norge og det nye registreringsprogrammet Augustus? Mye av det som vil bli registrert i programmet havner vel i Dagitalarkivet en dag. Ei enkel konvertering bør være en selvfølge.

Lenke til kommentar
Del på andre sider

Gjest Jan Oldervoll

Først gong eg har høyrt om Augustus er i denne debatten. Tekniske løysingar for konvertering er eg ikkje redd me ikkje skal klara, så lenge eit program skriv ut data i eit eller anna tekstformat. Eg er meir redd for registrering der det er uråd å skilja kva som står i kjelda frå tolkingar registrator har gjort.

Lenke til kommentar
Del på andre sider

Gjest Geir Thorud

Til Jans innlegg nr 67 - beklager at dette blir langt:- Hva spesifiserer malen: Malen skal altså beskrive høyresida i konverterings verktøyet. Uten å kjenne konverteringsfunksjonene i detalj og kostnadene er det vanskelig å forholde seg til malens format. At man enkelt skal kunne konvertere til dette formatet gir sterke føringer på et utvekslingsformatet. Det beste hadde vært om man istedet spesifiserte feltene i et foretrukket utvekslingsformat eller 'yttergrensene' for et slik format - samtidig som man beskrev hvordan dette konverters til et intern format. Det er utvekslingsformatet som er viktigst for de som skal levere til DA.Jeg regner med at malen vil kunne gi føringer på en kommende 4G/Histform, eller at den ender opp som et defacto utvekslingsformat. Hvis 4G/Histform er like rundt hjørnet er det merkelig at DA lager noe som ikke er samkjørt med denne. Derfor har jeg et videre perspektiv på denne malen enn noe som kun angår levering til DA.- Sammenligning med 4G: Ser man bort fra felter i 4G som det ser ut som alle er enige om å fjerne, eller slå sammen/omdøpe, så er det 6 felter i 4G døpte som ikke er med i den foreslåtte malen. Tar man hensyn til et felt i malen som ikke finnes i 4G, vil disse feltene gi 66 felter totalt, kontra 61 felter i forslaget (med 8 faddere). I tillegg har 4G 'fullt sett av felter ' for hjemmedøper, som hvis man splittet det opp som i malen, ville resultere i 3 felter til.Jeg forstår ikke hvorfor 66 eller 69 felter er tusen mer enn 61? Jeg forstår heller ikke hvorfor 61 er så mye mer lik de 10-12 kolonnene i kilden, enn 66/69. Å snakke om tusener av felt er ikke spesielt presis argumentasjon. Jeg tror den prinsipielle diskusjonen her gjør problemene større enn de er, la oss heller ta dette felt for felt.-Konvertering: Manuell konvertering må til hvis man skal ta imot mange formater, men når man benytter en standard forstår jeg ikke hvorfor man må gjøre dette manuelt. Jeg trodde standarden skulle beskrive hvordan dere ønsker å få levert avskriftene, og forutsatt at mange innleveringer følger standarden, at dere ønsket å redusere arbeidet ved at man gjorde konverteringen tilnærmet automatisk.Men hvis dere ikke automatiserer, så synes jeg ikke det er noe argument å spare et minutt ved å utelate noen felter.- Antall felter i utvekslingsformat og internt i DA: Har man førstes brukket opp informasjonen i mange felter ved registrering, så mener jeg at denne oppdelingen bør bevares i et utvekslingsformat. Ved utskrift på papir (f.eks. ved korrekturlesning) eller ved bruk i DA kan så felter slås sammen og ledetekster plasseres inn i et diversefelt for evt. å få det hele til å ligne på kirkeboka. (Det er enklere å slå sammen felter enn å brekke de fra hverandre.) Jeg har ikke noe problem med at DA viser tvilling og leiermålsnr. i et diversefelt så lenge dere tar i mot filer der denne informasjonen ligger i separate felter.- Et konkret eksempel (antakelig til det kjedsommelige): 4G inneholder feltet vielsesår. Jeg ønsker å motta dette feltet i utvekslingsformat fra en som skriver av for så å kjøre en automatisk kontroll på om årstallet er rimelig. Det samme utvekslingsformatet ønsker jeg antakelig med tid og stunder å bruke for å sende avskriften til DA. Hvis DA ønsker å gjemme bort feltet i et diversefelt så er det greit for meg, men jeg ønsker å vite om jeg kan levere fila med dette feltet til DA. Da bør feltet være med i en spesifikasjon som sier dette, men det trenger ikke nødvendigvis være med på høyresida i konverteringsverktøyet (dvs i malen). For meg spiller det ingen rolle om dette feltet finnes som en spesiell rubrikk i kirkeboka. Og hvis noen har så god råd at de vil skrive ut noen tusen sider av dette med samme ”layout” som i kirkeboka for korrektur så gjerne det også, jeg ser ikke at et eget felt skaper noe problem.

Lenke til kommentar
Del på andre sider

Gjest Jan Oldervoll

Eg har anna å gjera enn å skriva lange innlegg.- Me ser ikkje for oss at me kjem i ein situasjon der me kan konvertera automatisk. Me må rekna med sjølve å mappa varialbar i den mottatte basen mot vårt format.- Me ønskjer å leggja ting ut i eit format som i størst mogeleg grad avspeglar formatet i kyrkjeboka. Grunn: Me ønskjer ikkje leggja ut tolkingar; dei får brukaren sjølve gjera.- Kven som vil må kunna laga eit registreringsformat; det legg ikkje me oss borti. Og så lenge det ikkje skaper altfor store praktiske problem for oss, eller det bryt totalt med prinsippet overfor, vil me leggja ut data registrert i eit kvart format.- Så til 4G.(Som blir kalla ein standard, men sjølsagt ikkje er det. Kven har gjeve Samarbeidsrådet for historielaga i Oppland makt til å fastsetja norske standardar?) Eg ser ikkje nokon grunn til å sei noko om det. Om 4G i noverande eller framtidig versjon oppfyller kravet om at databasen skal framstå som avskrift og ikkje tolking er eg vel nøgd.Eg er smad med at 1000 var flåsete. Men samstundes har dei databasane EG har sett frå 4G hatt meir enn 66 felt. Og vår mal har vel eigentleg mykje mindre enn 61 felt. Eg veit ikkje kva du har sett, men eg har i alle høve ikkje sett noko med så mykje felt.

Lenke til kommentar
Del på andre sider

Gjest Geir Thorud

Utkast fra DA av 30.12.2002: 26 felter i utkast + 4 pr fadder x 8 faddere + 4 felter glemt i utkast = 26 + 32+ 4 = 62 felter for døpte. Eller har jeg regnet feil?Du har rett i at døpte i 4G har mange felt (114), men det er ingen som har foreslått å beholde 4G som den er.Jeg oppfatter ikke det å ha et eget felt kalt vielsesår som en tolkning, og antar at slike felt som umulig kan innbære tolkning som greie.

Lenke til kommentar
Del på andre sider

 Del

  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...

Viktig Informasjon

Arkivverket bruker cookies (informasjonskapsler) på sine nettsider for å levere en bedre tjeneste. De brukes til bl.a. skjemaoppdateringer og innlogging. Bruk siden som normalt, eller lukk informasjonsboksen for å akseptere bruk av cookies.