[#11888] Ny måte å visa kyrkjeboksdatabasar

[Gjest Jan Oldervoll]

Eg trur ikkje på standardar når det ikkje finst noko makt til å setja standarden ut i livet. Jfr. denne debatten. Eg trur heller ikkje det er viktig. Derimot trur eg det er viktig at det blri utarbied eit regelsett. Dette vil då folk kunna følgja eller la vera å følgja alt etter som dei vil Men fordelen er at dei som er usikre på korleis ein bør gjera slikt arbeid har noko dei kan ta utgangspunkt i. Dette er grunnen til at me arbeider med dette. Ikkje at me vil påtvinga alle vår måte å sjå ting på. Og det vil heller aldri bli slik at me bojkottar folk som har gjort det onnorleis; i DA skal det vera plass til alle. Men det vil så fast at det me presentera på nettet vil bli omforma slik at det får ein mest mogeleg lik struktur. Det trur eg alle er tente med. Og det er me som utformer denne strukturen. Men i denne saka som i alle andre er me lydhøyre. Somt synest me er godt, anna høver ikkje inn hos oss. Sjøl om ein av og til kan få inntrykk av det så er det ikkje slik at DA blir styrt av eit slags digitalt allmøte i debattforuma.

[Gjest Sissil Bruun Sørensen]

Jeg har heller ikke tro på standarder som man presser folk til å bruke - til det er jeg altfor stor indiviualist. Men det kreves en del erfaring med registreringsarbeid for å vurdere hva som er godt og hva som er dårlig. Jeg har aldri vurdert 4G som en 'offisiell mal', og derfor hadde jeg heller ingen problemer med å forkaste den på bakgrunn av mine egne erfaringer. Det blir annerledes hvis ARKIVVERKET stiller med to forskjellige standarder. Da er det jammen ikke så lett for en nybegynner å vite hva man bør forholde seg til.Vi er nok veldig klar over at DA ikke lar seg styre, men det er veldig kjekt å kunne bidra med synspunkter....:-)

[Gjest Jan Oldervoll]

Det er også svært kjekt, og nyttig, å motta synspunkt. Det har eg sagt før og det gjentek eg. No kan ein kanskje sei at det kan bli i meste laget. Denne debatten passerte nett 57 A4-sider.Elles er det ikkje slik at at Arkivverket stiller med to standardar. Lars Nygård er så vidt eg veit er med på å utarbeida Histform. Sjølv om han har sitt daglege virke i Riksarkivet, er det ikkje denne insitusjonen som utarbeider Histform. Han har, som han sjølv har sagt i denne debatten, mange hattar.

[Gjest Sissil Bruun Sørensen]

Det var flott - da var det jeg som misforsto. Og det er jeg glad for! Vi får vel også være takknemlig for at de 57 A4-sidene er en miljøvennlige framstilling av synspunkter....:-)

[Gjest Sissil Bruun Sørensen]

Jeg stilte et spørsmål tidligere som jeg gjerne ville hatt svar på: hvilke datoformat skal vi benytte? Spørsmålet er egentlig todelt:1. Skal henvisninger til helligdager skrives som vanlig datoformat?2. I malen står det oppgitt 2 alternativer for dato. 31. desember 1800 kan skrives som '3112' og med '3112 1800' dersom registreringsåret er 1801, eller det kan konsekvent skrives '3112 1800'. Visuelt sett foretrekker jeg den første, rett og slett fordi den inneholder færre tall. Men ved ettertanke er det kanskje mer hensiktsmessig med den siste dersom man skal sortere etter dato. Det er vel ikke oss vanlige brukere som kommer til å benytte oss mest av denne muligheten, men hvis såpass enkle grep kan få en praktisk nytteverdi, bør vi jo legge til rette for det?SÅ har jeg også et spørsmål til Jan. Du har sagt at du kan motta et hvilket som helst format, men hvilket format foretrekker du ideelt sett? Et regneark i flatt format, et regneark med nummererte hendelser hvor 'Hendelse' og 'Personer' står separat med hendelsesnummer som kobling, eller noe helt annet?

[Gjest Arild Kompelien]

DatoBare et par ord om dette. Ved presentasjon, utlegging på DA synes jeg ikke det betyr så mye hvordan man gjør det så lenge det er konsekvent.Men ved registrering synes jeg det er en fordel å registrere datoer i 3 felt DD - MM - ÅÅÅÅ. Kanskje bare en følelse, men for meg blir det bedre orden slik, og det er også mindre sjanse for rot.FormatI en forlengelse av Sissils spørsmål til Jan om hvilket format de ønsker databasene i, er det også fristende å spørre hvordan mann ikke vil ha dem. Hva er arbeidssomt - hva lager problemer? At konverteringa går raskt med minst mulig arbeidsinnsats må jo være vesentlig.

[Gjest Jan Oldervoll]

Den enklaste formatet er ein flat fil med standard feltavgrensing, slik program som Excel, Access, dBase eller andre lagar dei. Når det gjeld data vil eg rett og slett ikkje sei noko. Eg har mi meining, men kan ikkje DA få lov til å bestamma seg for kva som er DA si meining?

[Gjest Geir Thorud]

Først noen få kommentarer til Lars Nygaards innlegg.Muligheten til å slå sammen baser på tvers av tid er også en konsekvens av å slå sammen baser geografisk. Jeg ser ingen problemer med å slå sammen baser i tid så lenge konverteringen til søkedatabasen håndterer unionen av forkjellige typer felter som brukes i ulike tidsperioder. Antall perioder som det lages skjema for kan med fordel bestemmes etter at en del andre prinsipper er på plass. Jeg vil understreke det som er sagt om å ta høyde for ”hyppig forekommende” informasjon istedenfor å binde seg for sterkt til de trykte skjema. Det vil være en fordel med ET utvekslingsformat, hva gjelder logisk struktur og felter.For øvrig finner jeg ikke noe spesielt å innvende mot det Lars beskriver av prinsipper for løsning. Så lenge det ser ut som de fleste er enig i prinsippene er vel neste steg å komme ut med et dokument som oppsummerer prinsippene og som kommer ut med konkrete eksempler for f.eks et par skjemamodeller for døpte. Hvis komiteen ikke klarer å komme med noe slik i løpet av la oss si et års tid, bør vel komiteen vurdere tiltak for å øke framdriften vesentlig.Til Jans kommentarer til ”hovedhensyn en ny standard bør ivareta”, så er det Lars som nevner de 4 første, de 3 punktene jeg la til står jeg fast ved. Vi må også ha noe som fungerer for oss som ikke er så kompetente på området. Dette får man komme tilbake til i en standardiseringsprosess.Diskusjonen om konsekvensen av at DA utgir en spesifikasjon får også utstå til vi ser hva som kommer.Når det gjelder datoer mener jeg man i utvekslingsformatet må gi rom for at en dato kan ha både latinsk og vanlig format i hver sitt felt, i samme post. Jeg klarer ikke å se at en beregnet dato gjør noen skade når ledsagende dokumentasjon oppgir at den er beregnet og * brukes. Latinsk dato i kilde bør alltid registreres – og ”utveksles”. DA kan evt. velge å overse datoer med *, og presentere datoen som de vil. I utvekslingsformatet bør det være enkelt å finne delene av en vanlig dato, spesielt årstall. Om man i registreringsskjema velger å bruke et annet format enn utvekslingsformatet får være opp til den som lager programvaren.

[Gjest Sissil Bruun Sørensen]

Dersom man skal oversette datoer til vanlig format, bør det vel foreligge en henvisning til programmet 'Dage', og komplett oversikt over avvikene som ikke er registrert i dette programmet?Når det gjelder det vanlige formatet, ville jeg foretrukket at det var skrevet på formen '31.12' eller '31.12.1800'. For min del synes jeg det er mer intuitivt enn formen '3112 1800'. Et annet moment er at for å skrive på den formen som er foreslått i malen, må man f.eks. i Excel omdefinere en celle fra datoformat til tekstformat. Er det noen spesiell grunn til at man foretrekker formatet som er foreslått i utkastet til mal?

[Gjest Tor Andersen]

For oss som ikke har bedt om å få tilsendt det nye formatet; hvilket datoformat er foreslått? En amerikaner har nok en intuitiv oppfatning av 0408 1900, men den er ikke den samme som vår.Når det gjelder dato så er jo det et område der det finnes en ISO-standard. Dagens dato er '20030113' evnt '2003-01-13' for økt lesbarhet. Denne formen har den fordelen at kan sorteres uten spesielle programløsninger. Den reduserer også problemene med norsk vs amerikansk skrivemåte da ingen av disse har årstallet først, men dd og mm bytter plass. Jeg ville derfor ønsket dette som et normalisert datofelt (i tillegg til det som er registrert).

[Gjest Bente Kopperdal]

Foreslått datoformat er ddmm. I dei tilfella året for hendinga avvik frå registreringsåret ynskjer me datoformat ddmm åååå.

[Gjest Hans Myhre]

Sissil, hvilke avvik i 'Dage' mener du? Det er vel ikke nødvendig med en henvisning til Dage hvis en konverterer datoene fra de gamle helligdagene, men:Den gamle datoen bør stå i meldingsfeltet fordi det brukes flere metoder til konvertering og noen gir feil daoter. Førøvrig er det greit slik Bente beskriver datofeltet. Hans Myhre

[Gjest Geir Thorud]

Jeg lurer på hva som er argumentene for å velge DDMM ÅÅÅÅ framfor F.EKS. (NB F.EKS) DD.MM.ÅÅÅÅ ?Et skilletegn mellom DD og MM (og evt MM ÅÅÅÅ) øker lesbarheten betraktelig.Å bruke ÅÅÅÅ-MM-DD passer meget dårlig med originalen.

[Gjest Bente Kopperdal]

Det viktigaste argumentet for å bruka ddmm (eller evt. ddmm åååå) utan skiljeteikn er at det er raskare å registrera.Eg vil gjera merksam på at dette datoformatet berre er eit forslag frå vår side. Me har ikkje bestemt oss for om det er dette me vil gå for til sjuande og sist.

[Gjest Steinar Vasaasen]

Dette har etterhvert blitt en lang og interessant debatt. Så lang at jeg desverre ikke har hatt tid til å lese hele. Det siste om hurtigheten ved registrering av dato uten skilletegn er feil, ihvertfall ved bruk av Bd87 ! Etter å ha drevet med registrering i 20 år er jeg helt klart tilhenger av å bruke mere tid på registreringen idag enn det en ser for seg å ha bruk for akkurat nå. Det er langt lettere siden å slå sammen flere felt i en presentasjon enn det er å maskinelt dele opp ett felt i flere. Mens dere diskuterer videre fortsetter vi med vår registrering etter S4G og med Bd87. Jeg er spent på hvor lang tid det vil ta før noen klarer å erstatte Bd87 med et like anvendelig Windows-program. Egentlig er 'klipp og lim' og bruk av peker det eneste jeg savner i Bd87. Anvendeligheten av programmet er utrolig god, bare man gidder lese brukerveiledningen !mvh Steinar Vasaasen leder i Hedmark Slektshistorelag

[Gjest Sissil Bruun Sørensen]

Jeg er enig med Geir om at DD.MM.ÅÅÅÅ (alternativt et annet skilletegn) er det visuelt beste alternativet. Registreringsmessig er det ingen problemer. Både programmer laget i Access og andre programmer kan enkelt programmeres til å legge inn skilletegn automatisk. I Excel gjør en enkel makro samme nytten.Hans: Det foregår en debatt om avvikene i Dage på newsgruppen no.fritid.slektsforsking.diverse' under emnet tolkning av dato. Jeg trodde kun at det var Maria Bebudelsesdag som ble endret her i Norge, men det ser ut til å være flere dager.

[Gjest Hans Myhre]

Sissil, Alle Helgens Dag også. Dette er diskutert så flisene føyk på DIS-forum, ingen har til nå kunnet motbevise mine påstander der men holder enda på det som var før. Endringen kom i Stuenses korte 'regjeringstid' da noen dager ble avskaffet og noen flyttet, blant annet disse to her. Dansken som har laget Dage står på sitt men skjønner ikke fakta .Men dette skulle ikke diskuteres her. BRA Steinar. Hans

[Gjest Sissil Bruun Sørensen]

Korreksjon: I Excel kan det gjøres enda enklere ved å formatere hele kolonnen som egendefinert med format 00-00-0000. Men her nytter det ikke med punktum. Kolonnen kan også benyttes til latinske datoer uten at man får feilmeldinger.

[Gjest Hans Myhre]

Nåja, regskjemaene kan man lag som man vil,også i BD87,men det er best å bruke de ferdige ,da får vi hele basen lik.Du får det ikke noe bedre i Exel eller Access. Noe av problemet med disse to er at alle registratorer har ikke disse programmene. Å kjøpe dem inn blir kostbart. BD87 er ikke så kostbart. Dessuten bruker vi endel gamle maskiner som man ikke kan kjøre nevnte programmer på.Skjønner du enda ikke hvorfor vi bruker BD87 og 4G standard? Hans

[Gjest Sissil Bruun Sørensen]

Jeg har ingen problemer med å forstå at noen velger BD87 for registrering. Som jeg sa tidligere, er dette en smaksak. Poenget mitt var at man bør gjøre det enkelt også for de som velger andre alternativer.Jeg kommer aldri til å forstå at noen velger å registrere etter 4G 'standarden', og spesielt ikke etter at de har lest de motforestillingene som har kommet fram i denne debatten.

[Gjest Anette Skogseth Clausen]

For å gi dere noe nytt å diskutere (komme med tilbakespill på) har vi nå lagt ut en skjematisk oversikt over hvordan databaser basert på kirkebøker skal bli vist i Digitalarkivet. Bente Kopperdal og jeg har laget oversikten og vi er veldig enige i hva vi gjør, derfor er vi helt avhengig av å få tilbakemeldinger fra dere for å få inn nye perspektiv og ideer til løsninger.Som dere vil se av skjemaet har vi prøvd å være konsekvent når det gjelder å holde handlingsfelt og personfelt adskilt, men vi vet ikke om vi blir for strenge i vårt oppsett. Husk at dette skal være like anvendbart på kirkebøker fra 1600-tallet som de skjematiske bøkene fra 1800-tallet.Et konkret spørsmål: Vi har valgt å føre forsørgere og hjemmedøpere i ett felt på handlingsnivå. Er dette hensiktsmessig eller bør disse stå oppført som personer i en handling med rollebenenvelse forsørger og hjemmedøper? Her må en bl.a. vurdere registreringsarbeidet de ulike løsningene innebærer. Om en velger siste løsning, blir det mer arbeid for den som registrerer enn om en velger den første. Samtidig vil den siste løsningen gjøre at en viktig biperson blir søkbar på personnivå på lik linje med de andre personene involvert i handlingen.Dere får se og vurdere selv. Vi venter i spenning på den videre diskusjonen!Feltplan for visning av kirkebokdatabaser: http://da2.uib.no/nykbregfeltplan.htm

[Gjest Sissil Bruun Sørensen]

Jeg synes dette var VELDIG bra, og svært oversiktlig. For å svare på det konkrete spørsmålet: Jeg synes at forsørgere og hjemmedøpere bør stå oppført som personer i en handling slik at de blir søkbare. Så veldig mye mer arbeid blir det vel ikke, og intensjonen bak dette er jo at man på en enkel måte skal finne fram til personer.Så noen spørsmål til malen:- Jeg reagerte litt på at alder var krysset av ved dåp. Det har jeg aldri sett, men det forekommer kanskje?- Bosted/gård + fødested krysset av ved dåp. Dette er en klar fordel spesielt etter at barn begynner å bli født på sykehus. Men det bør kanskje være en avklaring på hvilket av feltene som skal fylles ut for barn som blir født hjemme?- Kryssinformasjon dåp/konfirmasjon og dåp/introduksjon. Jfr. tidligere innlegg. Dersom introduksjon føres sammen med dåp - vil den da bli søkbar på tvers av basene under introduksjon? Eller bør en database med både dåp og introduksjon splittes?- Under flytting er det krysset av for flyttet fra og flyttet til. Med dette antar jeg det er by/bygd som menes. Det er ikke krysset av for gårdsnavn, selv om vedkommende ofte vil være oppgitt med gårdsnavn når flyttingen skjer. Det blir vel feil å definere dette gårdsnavnet som etternavn, selv om det i mange tilfeller kanskje blir det?- Burde ikke bosted/gårdsnavn også være krysset av ved offentlig skrifte, introduksjon og kommunikant?- Burde ikke dødssted være et eget felt? Jeg har flere eksempler på soldater som dør i felten, eldre som dør hos sine barn eller andre, noen dør på reiser, men disse opplysningene kan jo også stå i et merknadsfelt. Jeg ser ikke noe spesielt behov for å søke etter denne typen informasjon.- Dødsårsak er vel et felt som kanskje burde vurderes. Det kan vel være aktuelt å søke etter dødsårsak i mange tilfeller, f.eks. for å følge utviklingen av epidemier.Det er et veldig godt stykke arbeid dere har lagt ned her. Den endelige malen bør nok lagres som pdf-fil eller lignende. For å ta utskrift av den oppgitte malen, måtte jeg bruke A3-format, og fikk fremdeles ikke med de siste bokstavene på høyre side. De færreste har tilgang til det. Og en slik mal vil nok de fleste ha i papirversjon.

[Gjest Geir Thorud]

Flott at vi har noe konkret å forholde oss til slik at vi slipper å snakke forbi hverandre. Forutsatt at man presiserer at dette ikke er ment som en mal for registreringsskjema synes jeg generelt dette er et bra utkast.Det som kanskje for ordens skyld burde sies eksplisitt i forbindelse med strukturen er at felter som finnes i en registrert base, men som ikke er med i strukturen, vil bli plassert med passende ledetekst i Merknadsfeltene.Bosted/gård: Et felt som har voldt mange problemer ved registrering er bostedsfeltet, jfr bla diskusjon over. Ut fra registreringsmalen som er diskutert over regner jeg med at ”gård” i ”Bosted/gård” betyr et gårdsnavn som kan være brukt som et etternavn, men ikke nødvendigvis i alle tilfelle et sted der vedkommende bor. La meg begynne med å spørre om dette er riktig tolket?Forsørger/hjemmedøper: Jeg kan ikke se at det er noe problem med ekstrarbeid å registrere forsørger og hjemmedøper som personer. Det er ønskelig å kunne søke på disse som personer.Personfeltet Konfirmasjon: Menes her både dato og sted?Kommer tilbake på flere punkter senere, må sjekke de enkelte hendelsene mer i detalj.

[Gjest Bente Kopperdal]

Sissil:- alder ved dåp er tenkt ført om foreldra til barnet. Dette har eg sett i fleire kyrkjebøker.- fødestad ved dåp er i første rekkje meint for foreldra, men i nyare kyrkjebøker kan det også vera aktuelt å føra det for barnet.- bustad/gard skal vera kryssa av ved offentleg skrifte, introduksjon og kommunikant. Det har vorte utegløymd.- eg er samd med Sissil om at dødsstad ikkje bør vera eige felt. Dette finst, såvidt eg veit, ikkje som eige felt i kyrkjebøker, men vert førte i merknadsfeltet.- Dødsårsak er i skjemaet kalla Årsak og er plassert på øvste nivå.- Me skal nok finna ein annan måte å publisera den endelege malen på.Geir:- Malen er ikkje meint som mal for registreringsskjema, men som ei oversikt over kva for felt som kan nyttast under registrering av kyrkjebøkene.- Korleis me ynskjer at feltet bustad/gard skal brukast finn du forklart i malen du fekk tilsendt.- Eg er samd med deg at det kan vera ynskjeleg å registrera heimedøypar og forsørgjar som personar, men skal då også lysningsforlangar, anmeldar, dåpsvitner etc. førast som personar? Dette synes eg vert for omfattande. Når det gjeld forsørgjar som eigen person er dette i mange tilfelle komplisert. Sjå t.d forsørgjarfeltet i denne databasen: [url="http://digitalarkivet.uib.no/cgi-win/webcens.exe?slag=visbase&filnamn=digitalpensjonatet/radoygard/sabd1881>Lenke eller

[Gjest Geir Thorud]

Hjemmedøper, forsørger. etc:Går ut fra at problemet vedr. forsørger er ”Faren” og ”Kona”? Hvis så, er dette en utmerket anledning til å innføre et diversefelt pr person, som også kan ha andre anvendelser som nevnt i debatten. Behovet for forsørger som egen person mener jeg er meget stort. Den beste (og kanskje i noen tilfeller eneste) måten å finne mange begravde barn på er å søke på faren.Ellers bør dere vel lage et fleksibelt opplegg som kan ta hensyn til flere måter å registrere på, og da ser jeg ikke noe i veien for å ha en rolle for hjemmedøper – evt i tillegg til eget felt på hendelsesnivå om ønskelig. Når ingen har foreslått roller for dåpsvitne, lysningsforlanger og anmelder ser jeg ikke at dette er et problem, man kan vel kalle det en hyptetisk problemstilling. Og skulle noen ønske en egen rolle for disse, så får de si ifra – jeg kan ikke se noen stor skade i slike roller. Jeg klarer ikke å se de praktiske konsekvensene av argumentasjonen om at ”dette blir for omfattende” – hva er problemet?Et mål må vel være en løsning der man i DA kan utnytte maksimalt at et meget stort antall poster er, og blir, registrert med Forsørger og Hjemmedøper som egne personer.