BK GEDCOM datoformat? 7-OCT-1923, 0-___-1942, mfl.

[dn10375]

En testbruker av TMG har problemer som kan skyldes rare datoformat i
GEDCOMfil fra BK, hva har skjedd med datoformatet her?

0 HEAD
1 SOUR BROSKEEP
2 VERS 6.1.31 WINDOWS
1 DEST BROSKEEP (BROTHERS KEEPER)
1 DATE 14 JAN 2005
.........
0 @I33@ INDI
1 NAME Aaaaaaaaa /Bbbbbbbbbb/
1 SEX M
1 BIRT
2 DATE 7-OCT-1923
1 DEAT
2 DATE 0-___-1942

og her er andre problemdatoer der brukeren tydeligvis har brukt
datofeltet til andre data enn datoer, hvorfor?
........
2 DATE Bor pêa Gol
........
2 DATE HEMSEDAL
......
1 DSCR
2 DATE ADOPTERT.
......

---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
[email protected]
http://www.tha.no

[Otto Jørgensen]

On Sun, 23 Jan 2005 10:07:48 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

En testbruker av TMG har problemer som kan skyldes rare datoformat i
GEDCOMfil fra BK, hva har skjedd med datoformatet her?

0 HEAD
1 SOUR BROSKEEP
2 VERS 6.1.31 WINDOWS
1 DEST BROSKEEP (BROTHERS KEEPER)
1 DATE 14 JAN 2005
........
0 @I33@ INDI
1 NAME Aaaaaaaaa /Bbbbbbbbbb/
1 SEX M
1 BIRT
2 DATE 7-OCT-1923
1 DEAT
2 DATE 0-___-1942

og her er andre problemdatoer der brukeren tydeligvis har brukt
datofeltet til andre data enn datoer, hvorfor?
.......
2 DATE Bor pêa Gol
.......
2 DATE HEMSEDAL
.....
1 DSCR
2 DATE ADOPTERT.

vedkommende har ikke satt opp programmet sitt i henhold til hvordan
vedkommende skriver inn datoen

Anmod vedkommend eå lese manualen, se på min hjemmeside eller ta
kontakt med meg
Det samme gjelder de andre feltene.
Vedkommende har skrevet inn Bor på Gol i et datofelt . Det samme
gjøres med Hemsedal.

Datofelt er til å bruke som datofelt og ikke aom angivelse av
stedsnavn

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[dn10375]

On Sun, 23 Jan 2005 10:12:06 +0100, Otto Jørgensen

On Sun, 23 Jan 2005 10:07:48 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

En testbruker av TMG har problemer som kan skyldes rare datoformat i
GEDCOMfil fra BK, hva har skjedd med datoformatet her?

0 HEAD
1 SOUR BROSKEEP
2 VERS 6.1.31 WINDOWS
1 DEST BROSKEEP (BROTHERS KEEPER)
1 DATE 14 JAN 2005
........
0 @I33@ INDI
1 NAME Aaaaaaaaa /Bbbbbbbbbb/
1 SEX M
1 BIRT
2 DATE 7-OCT-1923
1 DEAT
2 DATE 0-___-1942


vedkommende har ikke satt opp programmet sitt i henhold til hvordan
vedkommende skriver inn datoen

GEDCOMs datoformat skal leveres korrekt uansett oppsett av datoformat

i programmet.
BK gjør dette til et brukervalg?

Korrekte format:
DATE 7 OCT 1923
DATE 1942


---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
[email protected]
http://www.tha.no

[Otto Jørgensen]

On Sun, 23 Jan 2005 11:37:07 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

On Sun, 23 Jan 2005 10:12:06 +0100, Otto Jørgensen
On Sun, 23 Jan 2005 10:07:48 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

En testbruker av TMG har problemer som kan skyldes rare datoformat i
GEDCOMfil fra BK, hva har skjedd med datoformatet her?

0 HEAD
1 SOUR BROSKEEP
2 VERS 6.1.31 WINDOWS
1 DEST BROSKEEP (BROTHERS KEEPER)
1 DATE 14 JAN 2005
........
0 @I33@ INDI
1 NAME Aaaaaaaaa /Bbbbbbbbbb/
1 SEX M
1 BIRT
2 DATE 7-OCT-1923
1 DEAT
2 DATE 0-___-1942


vedkommende har ikke satt opp programmet sitt i henhold til hvordan
vedkommende skriver inn datoen

GEDCOMs datoformat skal leveres korrekt uansett oppsett av datoformat
i programmet.
BK gjør dette til et brukervalg?

Korrekte format:
DATE 7 OCT 1923
DATE 1942

Det er formatet som skal komme ut i GEDCOM og det gjør det også, men

det er klart at HEMSEDAL som du hadde i ditt første innlegg overhode
ikke kan komme i det formatet. Det sier seg selv

Så hvis du skriver et stedsnavn i et datofelt og du i tillegg får
bekjed om at dette er feil format, da kan du ikke forvente HEMSEDAL
skal bli til en dato: Tror du at det finnes noen trollmann inne i
programmet som har en direkte kanal til hjernen til den som skriver
inn disse opplysningene. Da hadde vi jo ikke trengt tastatur i det
hele tatt

Når det gjelder datoformat generelt, så har brukeren mulighet til å
skrive inn dato på mange måter, f.eks

dd mm yyyy eller mm dd yyyy
(for flere varianter vises til hjelpefilen)

Hvordan skal programmet vite at det er dag som står først eller måned
som står først. 01 04 1914, hva er det oversatt til i f.eks. GEDCOM?

Videre diskusjon om dette tema er til ingen nytte, da dette har du
mast på utrolig mange ganger og du vet svaret inderlig godt. Jeg har
svart utrolig mange ganger i alle de år siden du startet med dette
markedsføringsløpet.

Jeg henviser deg til hjelpefilen.

Forøvrig skal alle som får tilsendt programvaren fra USA også ha med
en liten melding i sending på norsk som forteller akkurat dette om de
forskjellige muligheten som er gitt brukerne om å kunne velge
forskjellige datoformat. Gjør de dette så er det ikke noe problem.

Det er også gitt klar melding om at brukere med eldre versjoner (BK5
og BK6W6.0.86), bare av hensyn til GEDCOM bør oppdatere sine
programmer.

At brukerne kan få velge å sette opp et datoformat til å bruk ved
innskriving er et tilbud til brukerne. At det i dine øyne er negativt,
får stå for din regning. Programmet kommer med et oppsett som jo
selvfølgelig brukeren kan benytte seg av, men det er et valg som
brukeren selv må avgjøre og ikke jeg.
Det er en tjeneste for brukerne slik de kan registrere inn
datoformatet på mange måter, for å dekke et behov for hva brukerne
selv er vant til å registrere i sitt daglige liv. Detaljer om
formatene finner du også i hjelpefilen


--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[dn10375]

On Sun, 23 Jan 2005 12:08:54 +0100, Otto Jørgensen

On Sun, 23 Jan 2005 11:37:07 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

On Sun, 23 Jan 2005 10:12:06 +0100, Otto Jørgensen
On Sun, 23 Jan 2005 10:07:48 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

En testbruker av TMG har problemer som kan skyldes rare datoformat i
GEDCOMfil fra BK, hva har skjedd med datoformatet her?

0 HEAD
1 SOUR BROSKEEP
2 VERS 6.1.31 WINDOWS
1 DEST BROSKEEP (BROTHERS KEEPER)
1 DATE 14 JAN 2005
........
0 @I33@ INDI
1 NAME Aaaaaaaaa /Bbbbbbbbbb/
1 SEX M
1 BIRT
2 DATE 7-OCT-1923
1 DEAT
2 DATE 0-___-1942


vedkommende har ikke satt opp programmet sitt i henhold til hvordan
vedkommende skriver inn datoen

GEDCOMs datoformat skal leveres korrekt uansett oppsett av datoformat
i programmet.
BK gjør dette til et brukervalg?

Korrekte format:
DATE 7 OCT 1923
DATE 1942


Det er formatet som skal komme ut i GEDCOM og det gjør det også,

Det er jo nettopp det som ikke har skjedd, se over.
Her er flere linjer fra mottatt BK-GEDCOMfil, altså hummer- og
kanari-datoer:

1 BIRT
2 DATE 04.01.1913
1 DEAT
2 DATE 01.09.74
1 BIRT
2 DATE 16 MAY 1996
1 MARR
2 DATE 18-OCT-1913
1 MARR
2 DATE 0-___-1940
1 MARR
2 DATE 0-___-1908

Jeg har anbefalt brukeren å rette opp alle datofeil i BKfilen med
manuell søk-og-erstatt før ny import i TMG.


---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
[email protected]
http://www.tha.no

[Otto Jørgensen]

On Sun, 23 Jan 2005 15:13:46 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

Det er jo nettopp det som ikke har skjedd, se over.
Her er flere linjer fra mottatt BK-GEDCOMfil, altså hummer- og
kanari-datoer:

1 BIRT
2 DATE 04.01.1913
1 DEAT
2 DATE 01.09.74
1 BIRT
2 DATE 16 MAY 1996
1 MARR
2 DATE 18-OCT-1913
1 MARR
2 DATE 0-___-1940
1 MARR
2 DATE 0-___-1908

Jeg har anbefalt brukeren å rette opp alle datofeil i BKfilen med
manuell søk-og-erstatt før ny import i TMG.

Dette er enkelt.
Brukeren har ikke skrevet inn datoene slik vedkommende selv har satt
opp programmet eller importert data fra andre.

Uansett dette tyder på at vedkommende ikke har vært konsekvent i sin
måte å behandle data.
Kan ha registrert datoene som følgende
04.01.1913
01.01.74
16 mai 1996
18-okt-1913
et eller annet-1940
et eller annet-1908

Alt dette er forskjellige datoformater som kun viser at dette er
skrevet inn som blanding av fugl og fisk og ikke konsekvent,
sansynligvis importert GEDCOM over mange år fra ulike programmer eller
særlig ukonsekvent i sin registrering av dato.

Det er nå ikke sikkert at vedkommende en gang vil klare dette med søk
or erstatt, da selv en dato som 04.01.1913 kan bety både 4 januar 1913
eller 1 april 1913.
Dette skyldes igjen ikke konsekvent behandling og registrering av sine
egne data, hvilket jo sammen med de tidligere nevnte stedsnavn i
datofeltet sier jo sitt.

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Stein Ole Kjær]

Det er rart at BK (og andre programmer for den del) ikke har en
innebygget funksjon som automatisk endrer intastet dato til det som er
forhåndsvalgt som std. F.eks.: 1-1-2005 blir 1. jan 2005 og også
01,01,05 blir 1. jan 2005.

Stein

Dette er enkelt.
Brukeren har ikke skrevet inn datoene slik vedkommende selv har satt
opp programmet eller importert data fra andre.

Uansett dette tyder på at vedkommende ikke har vært konsekvent i sin
måte å behandle data.
Kan ha registrert datoene som følgende
04.01.1913
01.01.74
16 mai 1996
18-okt-1913
et eller annet-1940
et eller annet-1908

Alt dette er forskjellige datoformater som kun viser at dette er
skrevet inn som blanding av fugl og fisk og ikke konsekvent,
sansynligvis importert GEDCOM over mange år fra ulike programmer eller
særlig ukonsekvent i sin registrering av dato.

Det er nå ikke sikkert at vedkommende en gang vil klare dette med søk
or erstatt, da selv en dato som 04.01.1913 kan bety både 4 januar 1913
eller 1 april 1913.
Dette skyldes igjen ikke konsekvent behandling og registrering av sine
egne data, hvilket jo sammen med de tidligere nevnte stedsnavn i
datofeltet sier jo sitt.
--

Stein Ole Kjær
[email protected]

[Otto Jørgensen]

On Sun, 23 Jan 2005 17:00:51 +0100, in no.fritid.slektsforsking.it
Stein Ole Kjær <[email protected]> wrote:

Det er rart at BK (og andre programmer for den del) ikke har en
innebygget funksjon som automatisk endrer intastet dato til det som er
forhåndsvalgt som std. F.eks.: 1-1-2005 blir 1. jan 2005 og også
01,01,05 blir 1. jan 2005.

Det er innebygget rutiner som sier hva som skal være til hva, men

eksemplet med
05.08.1950
kan blir to forskjellige resultat, slik at du MÅ sette opp hva som
skal blir hva
5 august eller 8 mai.

Dette må du bestemme ved ditt oppsett. Det er ingen andre enn deg selv
som vet hva du tenker når du skriver sen slik dato


--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Stein Ole Kjær]

In article <[email protected]>,
Otto Jørgensen <otjoerge%øføø%@online.norway> wrote:

On Sun, 23 Jan 2005 17:00:51 +0100, in no.fritid.slektsforsking.it
Stein Ole Kjær <[email protected]> wrote:

Det er rart at BK (og andre programmer for den del) ikke har en
innebygget funksjon som automatisk endrer intastet dato til det som er
forhåndsvalgt som std. F.eks.: 1-1-2005 blir 1. jan 2005 og også
01,01,05 blir 1. jan 2005.

Det er innebygget rutiner som sier hva som skal være til hva, men
eksemplet med
05.08.1950
kan blir to forskjellige resultat, slik at du MÅ sette opp hva som
skal blir hva
5 august eller 8 mai.

Dette må du bestemme ved ditt oppsett. Det er ingen andre enn deg selv
som vet hva du tenker når du skriver sen slik dato

Det jeg mente Otto er at hvis en i eget program def. dato til å skulle
være dd.mm.yyyy, så skal altså programmet automatisk gjøre om dine
inntastinger 1,1,05 evt. 01-01-2005 evt. 1/1/2005 til det rette
formatet, nemlig 1. jan 2005.

En legger jo som regel inn dataene i eget program da

Stein
--
Stein Ole Kjær
[email protected]

[Otto Jørgensen]

On Sun, 23 Jan 2005 17:41:46 +0100, in no.fritid.slektsforsking.it
Stein Ole Kjær <[email protected]> wrote:

In article <[email protected]>,
Otto Jørgensen <otjoerge%øføø%@online.norway> wrote:

On Sun, 23 Jan 2005 17:00:51 +0100, in no.fritid.slektsforsking.it
Stein Ole Kjær <[email protected]> wrote:

Det er rart at BK (og andre programmer for den del) ikke har en
innebygget funksjon som automatisk endrer intastet dato til det som er
forhåndsvalgt som std. F.eks.: 1-1-2005 blir 1. jan 2005 og også
01,01,05 blir 1. jan 2005.

Det er innebygget rutiner som sier hva som skal være til hva, men
eksemplet med
05.08.1950
kan blir to forskjellige resultat, slik at du MÅ sette opp hva som
skal blir hva
5 august eller 8 mai.

Dette må du bestemme ved ditt oppsett. Det er ingen andre enn deg selv
som vet hva du tenker når du skriver sen slik dato

Det jeg mente Otto er at hvis en i eget program def. dato til å skulle
være dd.mm.yyyy, så skal altså programmet automatisk gjøre om dine
inntastinger 1,1,05 evt. 01-01-2005 evt. 1/1/2005 til det rette
formatet, nemlig 1. jan 2005.

En legger jo som regel inn dataene i eget program da

Jo, man legger inn i eget program og derfor , skriver jeg 17051814
blir det etter mitt oppsett 17 mai 1814 fordi jeg har satt at 17 er
dag 05 er måned og 1814 er år.
Skriver jeg inn 05171814 så blir det feil, da det ikke er 17 måneder.

Men hvis jeg skriver 08051814 så går programmet ut fra at jeghar
formatet ( som jeg har satt til) dd mmm 1814 og behandler dette
deretter, men eksemplene som dette tema starter med viser at brukeren
har en sammensurium av dataformater, alt fra rene tekster som er
stedsnavn til ulike datoer.

Det er også klart at man kan legge inn mye systematikk og testing på
datoer, men jeg antar at de fleste mennesker er relativt ryddige i
hvordan de skriver inn en dato og ikke vimser frem og til bake uten
mål og mening.

Vi har vel alle etterhvert opparbeidet vår måte å skrive en dato på
Og det vil naturlig og enkelt at denne også brukes når man registrerer
datoer.
Man kan gjerne forvente at en programleverandør skal lage løsninger
som tester på alle mulige unike varianter, men jeg foretrekker heller
at en programleverandør bruker ressursene til andre deler som kommer
oss som brukere til gode. Og ellers anser at vi som registrerer data
er noenlunde strukturerte både med hensyn til hva som er stedsnavn og
datoer og klarer å plassere dette i riktige felt

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[dn10375]

On Sun, 23 Jan 2005 15:25:35 +0100, Otto Jørgensen

On Sun, 23 Jan 2005 15:13:46 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

Det er jo nettopp det som ikke har skjedd, se over.
Her er flere linjer fra mottatt BK-GEDCOMfil, altså hummer- og
kanari-datoer:

1 BIRT
2 DATE 04.01.1913
1 DEAT
2 DATE 01.09.74
1 BIRT
2 DATE 16 MAY 1996
1 MARR
2 DATE 18-OCT-1913
1 MARR
2 DATE 0-___-1940
1 MARR
2 DATE 0-___-1908

Jeg har anbefalt brukeren å rette opp alle datofeil i BKfilen med
manuell søk-og-erstatt før ny import i TMG.

Dette er enkelt.
Brukeren har ikke skrevet inn datoene slik vedkommende selv har satt
opp programmet eller importert data fra andre.

Uansett dette tyder på at vedkommende ikke har vært konsekvent i sin
måte å behandle data.

Ja, dette er enkelt. Ikke legg skylda på brukeren for mangler og feil
i programmet.

Inntastingsformatet er én ting, utskriftsformatet er noe annet.
Uansett inntasting må jo BK være konsekvent i sin måte å skrive datoer
i GEDCOMfilen, ikke vingle mellom alle slags rare og ulovlige format.


---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
[email protected]
http://www.tha.no

[Otto Jørgensen]

On Sun, 23 Jan 2005 19:44:39 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

On Sun, 23 Jan 2005 15:25:35 +0100, Otto Jørgensen
On Sun, 23 Jan 2005 15:13:46 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

Det er jo nettopp det som ikke har skjedd, se over.
Her er flere linjer fra mottatt BK-GEDCOMfil, altså hummer- og
kanari-datoer:

1 BIRT
2 DATE 04.01.1913
1 DEAT
2 DATE 01.09.74
1 BIRT
2 DATE 16 MAY 1996
1 MARR
2 DATE 18-OCT-1913
1 MARR
2 DATE 0-___-1940
1 MARR
2 DATE 0-___-1908

Jeg har anbefalt brukeren å rette opp alle datofeil i BKfilen med
manuell søk-og-erstatt før ny import i TMG.

Dette er enkelt.
Brukeren har ikke skrevet inn datoene slik vedkommende selv har satt
opp programmet eller importert data fra andre.

Uansett dette tyder på at vedkommende ikke har vært konsekvent i sin
måte å behandle data.

Ja, dette er enkelt. Ikke legg skylda på brukeren for mangler og feil
i programmet.

Inntastingsformatet er én ting, utskriftsformatet er noe annet.
Uansett inntasting må jo BK være konsekvent i sin måte å skrive datoer
i GEDCOMfilen, ikke vingle mellom alle slags rare og ulovlige format.

Vil du ikke forstå, så vil du ikke forstå.

Som i eksemplene du kom med i begynnelsen, så kan ikke programmet
omforme stedsnavn til datoer.

Oppsettet som programmet har ved mottakelse hos brukeren er
06241954 (MMDDÅÅÅ) det vil si at man skriver inn månedsstallet først
her = 06, deretter skriver man inn dagen= her = 24, og deretter
årstallet, her = 1954. Vil man gjøre det annerledes, så må man gjøre
det under oppsett.

Det er vel klart og ikke noe mer å diskutere.

Hvis du vil fortsette dette tema, kan du diskutere med deg selv

Ha en fortsatt hyggelig hobby

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Sun, 23 Jan 2005 19:44:39 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

Inntastingsformatet er én ting, utskriftsformatet er noe annet.
Uansett inntasting må jo BK være konsekvent i sin måte å skrive datoer
i GEDCOMfilen, ikke vingle mellom alle slags rare og ulovlige format.

utskriften i GEDCOM er riktig, men det er en god og gammel regel som
sier "skitt inn, gir skitt ut" og forstår du ikke det, kan du
fortsette diskusjonen med deg selv.

Ha fortsatt en god helg

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[dn10375]

On Sun, 23 Jan 2005 19:57:23 +0100, Otto Jørgensen

On Sun, 23 Jan 2005 19:44:39 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

Inntastingsformatet er én ting, utskriftsformatet er noe annet.
Uansett inntasting må jo BK være konsekvent i sin måte å skrive datoer
i GEDCOMfilen, ikke vingle mellom alle slags rare og ulovlige format.

utskriften i GEDCOM er riktig, men det er en god og gammel regel som
sier "skitt inn, gir skitt ut" og forstår du ikke det, kan du
fortsette diskusjonen med deg selv.

BKs GEDCOMdatoer er feil, se tidligere i tråden.
Nok om det.


---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
[email protected]
http://www.tha.no

[Otto Jørgensen]

On Sun, 23 Jan 2005 20:38:25 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

On Sun, 23 Jan 2005 19:57:23 +0100, Otto Jørgensen
On Sun, 23 Jan 2005 19:44:39 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

Inntastingsformatet er én ting, utskriftsformatet er noe annet.
Uansett inntasting må jo BK være konsekvent i sin måte å skrive datoer
i GEDCOMfilen, ikke vingle mellom alle slags rare og ulovlige format.

utskriften i GEDCOM er riktig, men det er en god og gammel regel som
sier "skitt inn, gir skitt ut" og forstår du ikke det, kan du
fortsette diskusjonen med deg selv.


BKs GEDCOMdatoer er feil, se tidligere i tråden.
Nok om det.

Stakkar, du gir deg ikke. Hvis data som er lagt inn jft at man legger
inn stedsnavn inn i dato felt, ja dat blir det feil, men som nevnt
"skitt inn gir skitt ut, uansett hvordan du vender og vrir på det"
Du får da leve med din tro,

"Lev lykkelig og salig i din tro" er det noe som heter

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Niels Baggesen]

Otto J?rgensen <otjoerge%?f??%@online.norway> wrote:

Stakkar, du gir deg ikke. Hvis data som er lagt inn jft at man legger
inn stedsnavn inn i dato felt, ja dat blir det feil, men som nevnt
"skitt inn gir skitt ut, uansett hvordan du vender og vrir på det"
Du får da leve med din tro,

Problemet er at BK tillader at de data ender i databasen. Det er ikke
nok at de vises med rødt på skærmen, og så håbe at brugeren "gør det
rigtige".

/Niels

--
Niels Baggesen -- @home -- Århus -- Denmark -- [email protected]
The purpose of computing is insight, not numbers -- R W Hamming

[dn10375]

torleif haugødegård <[email protected]>:

On Sun, 23 Jan 2005 19:57:23 +0100, Otto Jørgensen
On Sun, 23 Jan 2005 19:44:39 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

Inntastingsformatet er én ting, utskriftsformatet er noe annet.
Uansett inntasting må jo BK være konsekvent i sin måte å skrive datoer
i GEDCOMfilen, ikke vingle mellom alle slags rare og ulovlige format.

utskriften i GEDCOM er riktig, men det er en god og gammel regel som
sier "skitt inn, gir skitt ut" og forstår du ikke det, kan du
fortsette diskusjonen med deg selv.


BKs GEDCOMdatoer er feil, se tidligere i tråden.

Nok en BKtest, datoformat satt til dd.mm.åååå i BK, feks 14.5.1999.
Datoer tastet inn som 11.5.1888 osv.

Eksport til GEDCOM viser at BK ikke skriver datoene riktig:

0 @I1@ INDI
1 NAME Ole /Nord/
1 SEX M
1 BIRT
2 DATE 11.5.1888
2 PLAC Oslo
2 SOUR @S1@
1 BAPM
2 DATE 2.6.1910
2 PLAC Drammen
1 DEAT
2 DATE 14.2.1999

DIS-Norges testkriterier er som følger:

II-C10 Eksport gedcom; dato?
Forklaring: Kommer alle dato felt korrekt inn?
(1 p)Vanlige datoer (1 FEB 1970)?
(1 p) Norske kort-måneder (mai, okt, des) oversatt til MAY, OCT, DEC?
(1 p) Datomoderator AFT og BEF?
(1 p) Datomoderator ABT?
(1 p) Datomoderator BET - AND? (1 Per Roger Oband yrke)

---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
[email protected]
http://www.tha.no

[børge askholm]

torleif haugødegård skrev:

BKs GEDCOMdatoer er feil, se tidligere i tråden.
Nok om det.

Nu må osse jeg blande mig i debatten. Jeg har brugt BK i mangfoldige år
og aldrig set at datoformaterne som jeg havde forud valgt (i
indstillingen) blev skrevet forkert. Og så kan man sætte BK til at
fortælle om datoen er angivet forkert - således osse hvis man kommer til
at skrive andet end datoer i datoformatet.


)) Børge Askholm

[børge askholm]

Niels Baggesen skrev:

Problemet er at BK tillader at de data ender i databasen. Det er ikke
nok at de vises med rødt på skærmen, og så håbe at brugeren "gør det
rigtige".

Det problem ligner mere en fejl 40.
I slægtsforskning om i alle andre af livets forhold gælder det at man
selv må tænke sig om og kontrollere sine data.

;-( Børge

[Otto Jørgensen]

On Mon, 24 Jan 2005 07:19:19 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

torleif haugødegård <[email protected]>:

On Sun, 23 Jan 2005 19:57:23 +0100, Otto Jørgensen
On Sun, 23 Jan 2005 19:44:39 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

Inntastingsformatet er én ting, utskriftsformatet er noe annet.
Uansett inntasting må jo BK være konsekvent i sin måte å skrive datoer
i GEDCOMfilen, ikke vingle mellom alle slags rare og ulovlige format.

utskriften i GEDCOM er riktig, men det er en god og gammel regel som
sier "skitt inn, gir skitt ut" og forstår du ikke det, kan du
fortsette diskusjonen med deg selv.


BKs GEDCOMdatoer er feil, se tidligere i tråden.

Nok en BKtest, datoformat satt til dd.mm.åååå i BK, feks 14.5.1999.
Datoer tastet inn som 11.5.1888 osv.

kan du ikke se hva som står i beskrivelsen og under oppsett av
datoformatet i stedet for å fortsette i samme duren.

Når du ikke vil sette opp programmet så får du feil og når du ikke
forstår hva jeg sier så har du et problem.

Er dette enda et triks for å¨fremføre økt markedsføring av TMG ?

Når du har satt opp BK riktig så kan vi fortsette dialogen

Lykke til med ditt oppsett

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Mon, 24 Jan 2005 07:19:19 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

DIS-Norges testkriterier er som følger:

II-C10 Eksport gedcom; dato?
Forklaring: Kommer alle dato felt korrekt inn?
(1 p)Vanlige datoer (1 FEB 1970)?
(1 p) Norske kort-måneder (mai, okt, des) oversatt til MAY, OCT, DEC?
(1 p) Datomoderator AFT og BEF?
(1 p) Datomoderator ABT?
(1 p) Datomoderator BET - AND? (1 Per Roger Oband yrke)

det er da ikke noen som diskutere dette.

Fortsatt er det at du ikke gidder å sette opp programmet til tross for
at det er fortalt utallige ganger.

Vet snart ikke hva dette skal beskrives om, men tur frem.
Det forteller mer om deg enn om programmet


Har du foresten glemt dette med alle stedsnavn som ble innskrevet i
datofeltet?
Eller var det en generaltabbe fra din side ?
Eller forventer du fortsatt at stedsnavn i datofeltet skal konverteres
til "normale datoer" ?




--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Mon, 24 Jan 2005 05:37:38 +0000 (UTC), in
no.fritid.slektsforsking.it [email protected] (Niels Baggesen)
wrote:

Otto J?rgensen <otjoerge%?f??%@online.norway> wrote:
Stakkar, du gir deg ikke. Hvis data som er lagt inn jft at man legger
inn stedsnavn inn i dato felt, ja dat blir det feil, men som nevnt
"skitt inn gir skitt ut, uansett hvordan du vender og vrir på det"
Du får da leve med din tro,

Problemet er at BK tillader at de data ender i databasen. Det er ikke
nok at de vises med rødt på skærmen, og så håbe at brugeren "gør det
rigtige".

Det er her minst to diskusjoner.

at en person skriver inn data feil er en side av saken.

Men skriver en person inn data riktig, så kommer det også ut riktig i
GEDCOM.

Så dermed kan en diskutere inntasting og GEDCOM og det er forskjellige
sider.
At en person legger inn stedsnavn i et datofelt.

Det er også en dato hvis en skriver inn 4 påskedag 1789 og da også
om dette skrives på latin eller svensk, dansk eller hvilket som helst
språk.
Dette angis da med rødt for å fortelle at her er en feilinntasting.
Skal man ha horn og blåsere eller kan man klare å se at man taster inn
feil.
Alle har ikke koblet inn høytalere.
Eller skal man ikke godta slike datoer i det hele tatt ?

Det er et sammenheng mellom det datoformatet som er satt opp under
oppsett av programmet og konverteringen som skjer til GEDCOM.
Har man ikke gjordt det riktig så blir også resultatet feil.

Man kan gjerne diskutere om dette er beste løsning, men for alle som
klarer å lese norsk og følge denne enkle regel, så er det ikke noe
problem.

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[dn10375]

børge askholm <[email protected]>:

torleif haugødegård skrev:

BKs GEDCOMdatoer er feil, se tidligere i tråden.
Nok om det.

Nu må osse jeg blande mig i debatten. Jeg har brugt BK i mangfoldige år
og aldrig set at datoformaterne som jeg havde forud valgt (i
indstillingen) blev skrevet forkert. Og så kan man sætte BK til at
fortælle om datoen er angivet forkert - således osse hvis man kommer til
at skrive andet end datoer i datoformatet.

børge askholm, hva er så gjort feil her:

Datoformat satt til dd.mm.åååå i BK, feks 14.5.1999.
Datoer tastet inn som 11.5.1888 osv. Ingen feilmelding med rødt.

Eksport til GEDCOM viser at BK ikke skriver datoene riktig:

0 @I1@ INDI
1 NAME Ole /Nord/
1 SEX M
1 BIRT
2 DATE 11.5.1888
2 PLAC Oslo
2 SOUR @S1@
1 BAPM
2 DATE 2.6.1910
2 PLAC Drammen
1 DEAT
2 DATE 14.2.1999
1 CHR
2 DATE 12.6.1888


Mer fra mottatt fil fra en BKbruker som tester TMG:

1 BIRT
2 DATE 21-DEC-1940
1 BIRT
2 DATE 15-SEP-1941
1 DSCR Bruker Eikre Arnesen som etternavn
2 DATE Bor pêa Gol
1 DEAT
2 DATE 0-___-1964
1 BURI
2 DATE HEMSEDAL
1 BIRT
2 DATE 0-___-1885
1 DSCR
2 DATE ADOPTERT.
1 BURI
2 DATE HEMSEDAL

Hva skal BKbrukeren gjøre her for å få produsert en korrekt GEDCOM?
Er det noen annen mulighet enn manuell redigering av GEDCOMfilen?
Hva bør skje med stedsnavn som er skrevet i datofeltet?


---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
[email protected]
http://www.tha.no

[Otto Jørgensen]

On Mon, 24 Jan 2005 19:51:48 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

børge askholm <[email protected]>:
torleif haugødegård skrev:

BKs GEDCOMdatoer er feil, se tidligere i tråden.
Nok om det.

Nu må osse jeg blande mig i debatten. Jeg har brugt BK i mangfoldige år
og aldrig set at datoformaterne som jeg havde forud valgt (i
indstillingen) blev skrevet forkert. Og så kan man sætte BK til at
fortælle om datoen er angivet forkert - således osse hvis man kommer til
at skrive andet end datoer i datoformatet.

børge askholm, hva er så gjort feil her:

Datoformat satt til dd.mm.åååå i BK, feks 14.5.1999.
Datoer tastet inn som 11.5.1888 osv. Ingen feilmelding med rødt.

Eksport til GEDCOM viser at BK ikke skriver datoene riktig:

formatet sier ddmmåååå som fire sammenhengende
eller som dd.mm.aaaa
14.5.1999 er ikke i samsvar med noen av disse
men skriver du
14.05.1999
slik det står angitt
eller 14051999
så får du noe annet.

Du må da gjøre slik det står beskrevet

Men du har nok rett i at rødfargen ikke er der, men det forsvarer
allikevel ikke at du ikke kan skrive riktig

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Mon, 24 Jan 2005 19:51:48 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

Mer fra mottatt fil fra en BKbruker som tester TMG:

1 BIRT
2 DATE 21-DEC-1940
1 BIRT
2 DATE 15-SEP-1941
1 DSCR Bruker Eikre Arnesen som etternavn
2 DATE Bor pêa Gol
1 DEAT
2 DATE 0-___-1964
1 BURI
2 DATE HEMSEDAL
1 BIRT
2 DATE 0-___-1885
1 DSCR
2 DATE ADOPTERT.
1 BURI
2 DATE HEMSEDAL

Hva skal BKbrukeren gjøre her for å få produsert en korrekt GEDCOM?
Er det noen annen mulighet enn manuell redigering av GEDCOMfilen?
Hva bør skje med stedsnavn som er skrevet i datofeltet?

for det første bør han bestemme hvilket format vedkommende vil skrive
inn datoen i og lagre det og så får han rydde i sine datoer, flytte
alle stedsnavn over til der de hører hjemme under stedsnavn
legg adoptert der det hører hjemme etc

Og muligens lese hva som står beskrevet om datoformat


Hvordan går foresten disse datoene i TMG

og hva skjer om man holder datoformatet og legger inn datoer som

februar 1723
før/etter 1723
1720-28

Etter hva rykter sier så skal jo det være et problem også hos TMG?
Blir dette riktig i rappporter og i GEDCOM ?

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Anne Lise Hovdal]

"Otto Jørgensen" <otjoerge%øføø%@online.norway> skrev i melding

Det er også en dato hvis en skriver inn 4 påskedag 1789 og da også
om dette skrives på latin eller svensk, dansk eller hvilket som helst
språk.

Da kan jo også f.eks. 8.p.trinit. 1789 regnes som en dato,
det er jo slike tidsbetegnelser som det oftest står i kirke-
bøkene for 1700-tallet. Det er jo da riktig å skrive inn dette
syns jeg. Jeg skriver inn f.eks. 8.p. trinit.1789 i datofeltet,
og så kan jeg skrive inn datoen under M. På noen har jeg
gjort motsatt. Nå sender jo jeg ikke gedcomfiler til noen,
og legger heller ikke ut informasjon på hjemmesider.

Egentlig burde det vel vært mulig å legge inn datoen i
parentes, og det gjør jeg når jeg forsker for andre. Da
lager jeg jo eget Dokument i "Mine Dokumenter" hvis
det er omfattende. Jeg er ikke interessert i å legge inn
andres aner i mitt program, med mindre en kommer inn
på mine aner.

Anne Lise Hovdal

[Otto Jørgensen]

On Mon, 24 Jan 2005 21:11:52 +0100, in no.fritid.slektsforsking.it
"Anne Lise Hovdal" <[email protected]> wrote:

"Otto Jørgensen" <otjoerge%øføø%@online.norway> skrev i melding

Det er også en dato hvis en skriver inn 4 påskedag 1789 og da også
om dette skrives på latin eller svensk, dansk eller hvilket som helst
språk.

Da kan jo også f.eks. 8.p.trinit. 1789 regnes som en dato,
det er jo slike tidsbetegnelser som det oftest står i kirke-
bøkene for 1700-tallet. Det er jo da riktig å skrive inn dette
syns jeg. Jeg skriver inn f.eks. 8.p. trinit.1789 i datofeltet,
og så kan jeg skrive inn datoen under M. På noen har jeg
gjort motsatt. Nå sender jo jeg ikke gedcomfiler til noen,
og legger heller ikke ut informasjon på hjemmesider.

Egentlig burde det vel vært mulig å legge inn datoen i
parentes, og det gjør jeg når jeg forsker for andre. Da
lager jeg jo eget Dokument i "Mine Dokumenter" hvis
det er omfattende. Jeg er ikke interessert i å legge inn
andres aner i mitt program, med mindre en kommer inn
på mine aner.

Dato er dato og akkurat med datoformater som du der nevnt så skal det
gjøre noe annerledes i GEDCOM enn hva som er situasjonen, men når det
gjelder datofeltet generelt så er det forbeholdt datoer og ikke
stedsnavn og "adopsjon" og andre rariteter.

Men det er også mulig å legge inn den latinske datoen inn i
merknadsfeltet til hendelsen, da jo f.eks. DIStreff liker latinske
datoer heller Men Distreff klarer seg i grunnen da den bare tar tak
i årstallet, men aldersberegninger blir feil.


--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Anne Lise Hovdal]

"Otto Jørgensen" <otjoerge%øføø%@online.norway> skrev i melding news:

Men når det
gjelder datofeltet generelt så er det forbeholdt datoer og ikke
stedsnavn og "adopsjon" og andre rariteter.

Jeg har nok gjort mye rart i mitt slektsprogram, men
hvis jeg har hatt stedsnavn og andre rariteter der enn
datoer eller tidsbetegnesler som p.trinit. osv så tror jeg
det skal være rettet.

Anne Lise Hovdal

[Otto Jørgensen]

On Mon, 24 Jan 2005 22:03:57 +0100, in no.fritid.slektsforsking.it
"Anne Lise Hovdal" <[email protected]> wrote:

"Otto Jørgensen" <otjoerge%øføø%@online.norway> skrev i melding news:

Men når det
gjelder datofeltet generelt så er det forbeholdt datoer og ikke
stedsnavn og "adopsjon" og andre rariteter.

Jeg har nok gjort mye rart i mitt slektsprogram, men
hvis jeg har hatt stedsnavn og andre rariteter der enn
datoer eller tidsbetegnesler som p.trinit. osv så tror jeg
det skal være rettet.

Jeg vet heller ikke hvem som har gjordt dette, men det er visstnok

blitt en del av et problem som jeg tror de aller fleste ikke har og
man klare å takle på en normal måte :=)

Eneste veien i slike tilfeller er å ta den tunge veien, men man kan
bruke ulike hjelpemidler for å finne frem til dette.

En er jo fakten å gå igjennom GEDCOMfilen og se hvor dette er gjordt
og så rette i programmet.

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[dn10375]

On Mon, 24 Jan 2005 20:14:09 +0100, Otto Jørgensen
<otjoerge%øføø%@online.norway> wrote:
....

Hvordan går foresten disse datoene i TMG

og hva skjer om man holder datoformatet og legger inn datoer som

februar 1723
før/etter 1723
1720-28

Etter hva rykter sier så skal jo det være et problem også hos TMG?
Blir dette riktig i rappporter og i GEDCOM ?

Rykter?
Otto har tydeligvis interesse av å følge med i TMGs åpne epostliste
der temaet er under diskusjon, svaret finnes også der
http://dk.groups.yahoo.com/group/tmg-basen


---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
[email protected]
http://www.tha.no

[Otto Jørgensen]

On Mon, 24 Jan 2005 22:57:05 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

On Mon, 24 Jan 2005 20:14:09 +0100, Otto Jørgensen
otjoerge%øføø%@online.norway> wrote:
...
Hvordan går foresten disse datoene i TMG

og hva skjer om man holder datoformatet og legger inn datoer som

februar 1723
før/etter 1723
1720-28

Etter hva rykter sier så skal jo det være et problem også hos TMG?
Blir dette riktig i rappporter og i GEDCOM ?

Rykter?
Otto har tydeligvis interesse av å følge med i TMGs åpne epostliste
der temaet er under diskusjon, svaret finnes også der
http://dk.groups.yahoo.com/group/tmg-basen

Da må jeg visstnok registrere meg, da dette synes ikke å være åpent
for alle, uten registrering

Jeg har jo heldigvis noen venner som følger med og seg og forteller
meg av og till at det ikke er likefrem alle steder. Ingen er helt
feilfrie

Men ellers var også hyggelig at du fant 14.5.1888 saken.
Den ligger utenfor definisjonen da den jo skulle vært skrevet som
14.05.1888.
Men jeg har nå oversendt den til produsenten, slik 14.5.1888 og
14.05.1888 blir behandlet likt.
Inntil videre må du nok forholde deg til at du skal skrive slik som
det står beskrevet, nemlig dd.mm.yyyy, i ditt tilfelle 14.05.1888 og
har du satt opp programmet til at dette formatet til å bruke for
datoer, så blir resultatet i GEDCOM riktig også her.

Finner du flere "virkelige" feil, tar jeg gjerne i mot disse, men
vennligst ikke repiter og repiter. Jeg trenger ikke mer et eksemplar
for hvert nye "virkelige" tilfelle.
Og jeg skal love at disse sender jeg over til produsenten.

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Anne Lise Hovdal]

"Otto Jørgensen" <otjoerge%øføø%@online.norway> skrev i melding news:

"Anne Lise Hovdal" <[email protected]> wrote:

Jeg har nok gjort mye rart i mitt slektsprogram, men
hvis jeg har hatt stedsnavn og andre rariteter der enn
datoer eller tidsbetegnesler som p.trinit. osv så tror jeg
det skal være rettet.

Jeg vet heller ikke hvem som har gjordt dette, men det er visstnok
blitt en del av et problem som jeg tror de aller fleste ikke har og
man klare å takle på en normal måte :=)

De fleste som er nybegynnere kan iallfall gjøre slike tabber,
og jeg har fått rette mye rart. Regner med å fremdeles måtte
rette en del da. Legger meg ikke borti diskusjonen mellom
deg og Thorleif.

Ellers har jeg lest kirkeboken for Hemnes fra 1707 og fremover
i tid i dag på mikrofilm, og der er det med både datoer og f.eks.
p.trinit. Årene fra 1704 og fremover til ca 1720 er virkelig gode
å lese for Hemnes, og årene deretter er ganske lesbare frem til utpå
1740-tallet(Ca 1748?). Da blir de helt håpløse de nærmeste 10
årene iallefall. Stopper der siden jeg er helt utenfor emnet.

Anne Lise Hovdal

[Otto Jørgensen]

On Mon, 24 Jan 2005 23:43:48 +0100, in no.fritid.slektsforsking.it
"Anne Lise Hovdal" <[email protected]> wrote:

"Otto Jørgensen" <otjoerge%øføø%@online.norway> skrev i melding news:
"Anne Lise Hovdal" <[email protected]> wrote:

Jeg har nok gjort mye rart i mitt slektsprogram, men
hvis jeg har hatt stedsnavn og andre rariteter der enn
datoer eller tidsbetegnesler som p.trinit. osv så tror jeg
det skal være rettet.

Jeg vet heller ikke hvem som har gjordt dette, men det er visstnok
blitt en del av et problem som jeg tror de aller fleste ikke har og
man klare å takle på en normal måte :=)

De fleste som er nybegynnere kan iallfall gjøre slike tabber,
og jeg har fått rette mye rart. Regner med å fremdeles måtte
rette en del da. Legger meg ikke borti diskusjonen mellom
deg og Thorleif.

ulike program gjør ting på ulik måte

Ellers har jeg lest kirkeboken for Hemnes fra 1707 og fremover
i tid i dag på mikrofilm, og der er det med både datoer og f.eks.
p.trinit. Årene fra 1704 og fremover til ca 1720 er virkelig gode
å lese for Hemnes, og årene deretter er ganske lesbare frem til utpå
1740-tallet(Ca 1748?). Da blir de helt håpløse de nærmeste 10
årene iallefall. Stopper der siden jeg er helt utenfor emnet.

husk å bruke datospenn måt du tar for deg datoer som f.eks. 1740-1750

Dobbeltklikk i datofeltet og det åpner seg et vindu som du kan
benytte.
Det gir også riktig resultat i GEDCOM

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Anne Berit Hildrum]

"børge askholm" <[email protected]> skrev i melding
news:[email protected]...

Niels Baggesen skrev:

Problemet er at BK tillader at de data ender i databasen. Det er ikke
nok at de vises med rødt på skærmen, og så håbe at brugeren "gør det
rigtige".

Det problem ligner mere en fejl 40.
I slægtsforskning om i alle andre af livets forhold gælder det at man
selv må tænke sig om og kontrollere sine data.

Å nei, du har misforstått helt. Programmene skal skjønne
hva du mener uansett hva du har satt opp og hva du skriver inn.
Burde vi ikke snart forvente at de også kunne finne anene
og slektningene for oss og fylle inn alt selv, slik a vi slapp denne
inntastingen? <Smil>

Anne

[børge askholm]

Anne Hildrum skrev:

"børge askholm" <[email protected]> skrev i melding

Det problem ligner mere en fejl 40.
I slægtsforskning om i alle andre af livets forhold gælder det at man
selv må tænke sig om og kontrollere sine data.



Å nei, du har misforstått helt. Programmene skal skjønne
hva du mener uansett hva du har satt opp og hva du skriver inn.
Burde vi ikke snart forvente at de også kunne finne anene
og slektningene for oss og fylle inn alt selv, slik a vi slapp denne
inntastingen? <Smil

Jeg ser grant at du har ret og at jeg var gal på den!!

Selvfølgelig skal det være som du skriver - til gengæld er jeg bange for
at jeg kommer til at kede mig en smule til den tid.

::-))) Børge Askholm

[børge askholm]

Otto Jørgensen skrev:

Eneste veien i slike tilfeller er å ta den tunge veien, men man kan
bruke ulike hjelpemidler for å finne frem til dette.

En er jo fakten å gå igjennom GEDCOMfilen og se hvor dette er gjordt
og så rette i programmet.

En måde at få retter sine fejlagtige datoer er at sende en gedcomfil til
GEDCOMP, Lars Chr. Lundins udmærkede program der sammenligner
gedcomfiler for at finde ens personer - personer andre arbejder med. Gør
man det skal man nok få at vide om der står noget forkert i fx.
datofelterne; se nedenfor, der er et citat fra Gedcomp

"Din GEDCOM-fil er blevet kontrolleret på en række punkter. Grunden til
det er, at forkerte oplysninger (f.ex. forkert indtastede datoer) kan
gøre det svært for GEDCOMP at finde personsammenfald. Derfor er din fil
blevet gennemgået på en række punkter. Resultatet står i det følgende.

'Fejl' betyder, at der et problem med data i filen, og at dette problem
formentlig vil reducere muligheden for at finde identiske personer i
andre filer.

'Advarsel' kan betyde 2 ting:
1) Der et problem med data i filen. Problemet vil dog næppe
reducere muligheden for at finde identiske personer i andre filer.
2) Der er måske er et problem med data i filen, og hvis der er, så vil
det formentlig reducere muligheden for at finde identiske personer i
andre filer."

Jeg ved ikke hvor kendt LKLs program er i Norge (eller i Sverige) men
det dækker så vidt jeg ved skulle der ikke være problemer med at være "på".
Jeg sender samtidig en kopi til Lars, så kan han efter tid og
temperament reagere.

Børge

[børge askholm]

torleif haugødegård skrev:

børge askholm <[email protected]>:

torleif haugødegård skrev:


BKs GEDCOMdatoer er feil, se tidligere i tråden.
Nok om det.

børge askholm, hva er så gjort feil her:

Datoformat satt til dd.mm.åååå i BK, feks 14.5.1999.
Datoer tastet inn som 11.5.1888 osv. Ingen feilmelding med rødt.

I BK er der mulighed for denne datoangivelse. Er det en fejl kan man
blot i opsætningen vælge en anden og måske mere korrekt.

Eksport til GEDCOM viser at BK ikke skriver datoene riktig:

0 @I1@ INDI
1 NAME Ole /Nord/
1 SEX M
1 BIRT
2 DATE 11.5.1888
2 PLAC Oslo
2 SOUR @S1@
1 BAPM
2 DATE 2.6.1910
2 PLAC Drammen
1 DEAT
2 DATE 14.2.1999
1 CHR
2 DATE 12.6.1888


Mer fra mottatt fil fra en BKbruker som tester TMG:

1 BIRT
2 DATE 21-DEC-1940
1 BIRT
2 DATE 15-SEP-1941
1 DSCR Bruker Eikre Arnesen som etternavn
2 DATE Bor pêa Gol
1 DEAT
2 DATE 0-___-1964
1 BURI
2 DATE HEMSEDAL
1 BIRT
2 DATE 0-___-1885
1 DSCR
2 DATE ADOPTERT.
1 BURI
2 DATE HEMSEDAL

Hva skal BKbrukeren gjøre her for å få produsert en korrekt GEDCOM?
Er det noen annen mulighet enn manuell redigering av GEDCOMfilen?
Hva bør skje med stedsnavn som er skrevet i datofeltet?

Her er der skrevet noget andet end datoer i datofeltet, og det er en
helt klar fejl 40!! Det er IKKE BK der er gl på den her....
For at få en korrekt GEDCOM må indtasteren en korrekt DATO i datofeltet!!!

Børge

[Lars Kr. Lundin]

Tue, 25 Jan 2005 08:31:54 +0100 skrev børge askholm:

En måde at få retter sine fejlagtige datoer er at sende en gedcomfil til
GEDCOMP, Lars Kr. Lundins udmærkede program der sammenligner gedcomfiler
for at finde ens personer - personer andre arbejder med. Gør man det
skal man nok få at vide om der står noget forkert i fx. datofelterne

Det er sandt:

Sender man sin GEDCOM-fil til [email protected] får man i løbet af meget
kort tid (minutter eller timer afhængig af døgnets tidspunkt) en meget
detaljeret kontrol rapport af sin GEDCOM-fil.

Jeg ved ikke hvor kendt LKLs program er i Norge (eller i Sverige) men
det dækker så vidt jeg ved skulle der ikke være problemer med at være
"på". Jeg sender samtidig en kopi til Lars, så kan han efter tid og
temperament reagere.

GEDCOMP har modtaget godt 70.000 personoplysninger fra norske
slægtsforskere (og knapt 100.000 ditto fra svenske).

Ud over den nyttige kontrol rapport har GEDCOMP også sat flertallet af de
norske (og svenske) brugere i kontakt med beslægtede slægtsforskere.

De norske og svenske slægtsforskeres mulighed for at få udbytte af GEDCOMP
blev væsentligt forbedret sidste år, hvor GEDCOMP begyndte at bruge en
stednavne database, som ud over danske stednavne også indeholder norske
og svenske stednavne.

Læs mere om GEDCOMP via linket nedenfor.

Mvh,
-Lars Lundin.
--
GEDCOMP: En omfattende og gratis database for slægtsforskere med
interesse i Danmark: http://www.lklundin.dk/gedcomp/

[John Morten Malerbakken]

Problemet er at BK tillader at de data ender i databasen. Det er ikke
nok at de vises med rødt på skærmen, og så håbe at brugeren "gør det
rigtige".

Jeg klarer liksom ikke å se at det skulle være noe problem egentlig. Slik
jeg kjenner BK så har man altså stor frihet til å legge inn data i
datofeltet slik man måtte ønske å bruke det. Derfor kan man bruke både ISO
standard (altså det som gjelder akkurat nå), eller notasjoner som ble brukt
omtrent på Methusalems tid.

For meg som bruker er det mer enn tilstrekkelig at jeg får en beskjed på
skjermen i rødt som sier at denne datoene er det noe feil med i forhold til
det formatet jeg har satt opp som "standard". Da gjør programmet jobben sin
helt enkelt. Men det blir da jeg som bruker som kan bestemme meg for hvordan
jeg vil angi det som står i feltet.

For min del liker jeg det på den måten ettersom programmer som "styrer opp"
inntastingen som regel ikke har tatt med seg mange nok mulige variasjoner av
hvilke datoformater (i dette tilfellet, men problemstilingen er generell)
som kan forekomme. Her presenterer BK en variant hvor det gis tydelig
tilbakemelding om at noe avviker fra det som er valgt som format, men
overlater det til brukeren å velge å korrigere det, og gir videre muligheten
til å faktisk beholde den avvikende formen. Kan ikke bli bedre slik jeg ser
det.

At så programmet får et problem når man forsøker å eksportere data med
avvikende format til en standardisert protokoll er da en naturlig
"følgeskade" av den valgfriheten som er beskrevet i avsnittet over. Det kan
sikkert diskuteres i det vide og brede om hvor god informasjon brukerne av
BK (eller andre program) finner om konsekvensene av å bruke felt på andre
måter enn det de er satt opp til, men jeg klarer ikke å se at dette er et
problem for programmet. Det er knyttet til valg som gjøres av brukerne.

Basert på dette så kan det sikkert hevdes, slik Torleif også gjør det, at BK
ikke burde eksportere data som ikke følger de innstillingene som er gjort i
programmet. Men det blir da igjen veldig knyttet til bruken av den filen. Om
to brukere av BK ønsker å eksportere data til og fra hverandre så blir altså
valgene den ene har gjort overført til den andre.

Til andre programmer (har aldri eksportert til TMG så jeg aner ikke hva som
eventuelt skjer der) så kan det sikkert by på problemer. Jeg går ut fra ta
det gjøres en konsistenssjekk på mottatte data i de fleste program,og litt
avhengig av hvordan en sånn sjekk gjøres så kan det jo hende at en import
stopper helt opp eller at det kommer en eller annen beskjed om at noe ikke
er helt som forventet. Er det da noe "schwung" over det mottagende systemet
så blir brukeren presentert med en mulighet til å avvise/akseptere/endre
slik at prosessen kan gå videre.

Om jeg skulle få lov til å ønske meg en forbedring til BK måtte det være at
det gjøres en konsistenssjekk på data også ved generering av GEDCOM slik at
jeg måtte ta stilling til avvik under prosessen med mulighet for å rette
underveis.

Men jeg ønsker meg ikke endringer i BK (eller i andre programmer) som
begrenser mulighetene mine til å gjøre valg selv. Det som kunne være en ide
(og ikke bare for BK) var om den teksten som kommer opp med beskjed om at
noe er feil med datoformatet også var en lenke til en beskrivelse der det
kommer klart fram hva konsekvensene av å legge inn et avvikende format kan
bli. (F.eks. problemer med overføring av GEDCOM formatert informasjon mellom
forskjellige programmer).

Jeg ser ikke på denne debatten som stort annet enn at man sikkert kan være
klarere med informasjon til brukerne i forhold til den friheten som ligger i
BK, og som jeg får inntrykk av at ikke er helt den samme i TMG (selv om det
sikkert på vanlig måte finnes massevis med innstillinger man kan skru på
der). En hel del er beskrevet i hjelpesidene i BK, og så kan jo JS som lager
BK bestemme om han vil legge informasjon om konsekvensene litt nærmere til
brukeren.

John Morten

[John Morten Malerbakken]

"torleif haugødegård" <[email protected]> wrote in message
news:[email protected]...

Hva skal BKbrukeren gjøre her for å få produsert en korrekt GEDCOM?

Enkelt. Gå tilbake til registreringssidene sine og endre på det som han
finner ut må endres.

Er det noen annen mulighet enn manuell redigering av GEDCOMfilen?

Ja, det enkleste er å bruke selve programmet til å rette i data. Hvis det
dreer seg om en "gjennomgående feil" der man altså har gjort systematisk
feil så kan det jo bli litt jobb. Jeg hadde på grunn av begrensninger i en
tidligere utgave av BK brukt "Diverse" feltet for å angi både konfirmasjoner
og Emigrasjon (skilte på det med tekstbeskrivelsen). Da jeg så gikk over til
en nyere versjon så ble det helt feil selvsagt, og GEDCOM ble enda galere.
Og det måtte jeg da bare sette meg ned å rydde opp i. Det var min feil å ta
i bruk et felt til noe annet enn det det var laget for fra dem som hadde
definert det.

Men jeg gjorde det ikke i GEDCOM. Det finnes selvsagt en mulighet for å ta
en GEDCOM fil inn i en fornuftig editor for "masseendring" eller kjøre noen
"grep" på den, men for de aller fleste brukere så gjøres nok slike endringer
lettest ved hjelp av selve programmet.

Indikerer spørsmålet at det finnes utvidede muligheter for "masseendringer"
i andre programmer så hadde det vært fint å høre om det. Tror kanskje ikke
at det hadde vært så lett å sette opp en kommandostruktur for å dele mine
konfirmasjoner og emigrasjoner egentlig. Så konsekvent hadde jeg nemlig ikke
vært at jeg kunne ha garantert at jeg hadde konsistente søkeord i teksten på
alle poster til det feltet. Men jeg hører gjerne om "bedre" eller "andre"
metoder for å automatisere ting.

Jeg har forresten eksportert hele BK-basen min via GEDCOM til en mySQL
database som en del av bruk av PhpGedView (http://www.phpgedview.net) på nettet.
Der skulle jeg jo kunne kjøre makroer på hele basen som består av massevis
med små GEDCOM snutter. Men igjen er vi inne på måter å gjøre ting på som
krever ganske mye datakunnskap av brukerne, og jeg ser ikke at dette er noen
løsning for de fleste som driver med slekt heller.

Hva bør skje med stedsnavn som er skrevet i datofeltet?

Etter min mening ikke noe annet enn det som skjer i BK i dag. Brukeren får
beskjed om at det som er skrevet inn avviker fra de innstillingene som
gjelder for programmet hans, og så får det være opp til brukeren å bestemme
seg for å gjøre noe med det.

Så har jeg skrevet en lang harang om dette med avvikende formater og varsler
i en annen post under samme overskrift så henviser bare dit.

John Morten

[Ole Bjørn Darrud]

Det ser ut som herrene Otto og Torleif snakker forbi hverandre.
Det debatteres datofenomerner på forskjellige plan, relativt unyansert.

1) BK ser ut til (basert på eksemplene i denne debatten) å akseptere
informasjon i datofelt, som ikke er en gyldig dato (samme hvilket format
bruker har valgt).
Dette er i seg selv greit, men programmet skal varsle bruker at dato-malen
ikke følges. BK varsler tydeligvis ikke bruker om slike feil.

2) Et slektsprogram som aksepterer informasjon i datofeltet som ikke kan
gjenkjennes ihht valgt dato-mal, skal "merke" denne informasjonen slik at
den omsluttes av en parentes når en gedcomfil lages. Alle de eksemplene som
er nevnt i denne debatten som stedsnavn eller ulovlige gedcomdatoer skulle
ha hatt en parentes "rundt seg". Eks (Hemsedal), (1-8-1952).
Et mottagende program vil da iimportere dette som tekst i datofeltet.

DATE_PHRASE:= {Size=1:35}

(<TEXT>)

Any statement offered as a date when the year is not recognizable to a
date parser, but which gives information about when an event occurred. The
date phrase is enclosed in matching parentheses.

..........

Det ser for meg ut som om BK
a) bør skjerpe sine rutiner mhp å varsle bruker om at valgt dato-mal brytes
og hva konsekvensen er.
b) Må rette den feil som åpenbart er der når slik informasjon ikke
eksporteres som tekst, mao med omsluttende parentes.

Mvh
Ole Bjørn Darrud
DIS-Norge

[John Morten Malerbakken]

1) BK ser ut til (basert på eksemplene i denne debatten) å akseptere
informasjon i datofelt, som ikke er en gyldig dato (samme hvilket format
bruker har valgt).
Dette er i seg selv greit, men programmet skal varsle bruker at dato-malen
ikke følges. BK varsler tydeligvis ikke bruker om slike feil.

Min utgave av programmet gjør det, men denne sjekken er en opsjon som må
slås på av den enkelte brukeren og er ikke satt til "På" som standard.
Ettersom det er kjent at mange brukere har problemer med sånne
innstillinger, hadde det kanskje vært en ide om Otto eller andre som har
jevnlig kontakt med JS å foreslå at denne opsjonen er påslått som standard.
Men funksjonen er der og virker som den skal når den er slått på.

2) Et slektsprogram som aksepterer informasjon i datofeltet som ikke kan
gjenkjennes ihht valgt dato-mal, skal "merke" denne informasjonen slik at
den omsluttes av en parentes når en gedcomfil lages. Alle de eksemplene
som
er nevnt i denne debatten som stedsnavn eller ulovlige gedcomdatoer skulle
ha hatt en parentes "rundt seg". Eks (Hemsedal), (1-8-1952).
Et mottagende program vil da iimportere dette som tekst i datofeltet.

DATE_PHRASE:= {Size=1:35}

(<TEXT>)

Any statement offered as a date when the year is not recognizable to a
date parser, but which gives information about when an event occurred. The
date phrase is enclosed in matching parentheses.

Der ser det i alle fall ut som om du har funnet en feil eller svakhet i BK i
alle fall. Ettersom standarden er temmelig tydelig på dette så burde det
være en kandidat for en forbedring av BK i alle fall.

Vet ikke helt hva som ville skje hvis man da bare vil overføre en BK
database rått fra en bruker til en annen i form av en GEDCOM (altså uten å
ville endre på innmatinger som nok er feil, men som brukeren allikevel vil
ha sånn), men det finnes jo mer direkte måter å "rå-kopiere" databaser på
da.

Det ser for meg ut som om BK
a) bør skjerpe sine rutiner mhp å varsle bruker om at valgt dato-mal
brytes
og hva konsekvensen er.

Jeg foreslo at det kunne finnes en mulighet for brukeren til å få
informasjon direkte knyttet opp til den markeringen som gis i dag slik at
man ikke behøver å lese hele brukerhåndboka for å forstå mulige konsekvenser
av valgene sine. Som sagt så får man markering av at man er utenfor
spesifikasjonen på formatet i dag, men det er et klart potensiale for å
forbedre informasjonen (som vanlig for de fleste programmer.)

b) Må rette den feil som åpenbart er der når slik informasjon ikke
eksporteres som tekst, mao med omsluttende parentes.

Helt klart. Bør komme snart også. Vet ikke hvor gammel den spesifikasjonen
er, men dette ser ut som noe som kan ha vært en svakhet lenge.

John Morten

[Otto Jørgensen]

On Tue, 25 Jan 2005 14:40:02 +0100, in no.fritid.slektsforsking.it
"Ole Bjørn Darrud" <[email protected]> wrote:

Det ser ut som herrene Otto og Torleif snakker forbi hverandre.
Det debatteres datofenomerner på forskjellige plan, relativt unyansert.

1) BK ser ut til (basert på eksemplene i denne debatten) å akseptere
informasjon i datofelt, som ikke er en gyldig dato (samme hvilket format
bruker har valgt).
Dette er i seg selv greit, men programmet skal varsle bruker at dato-malen
ikke følges. BK varsler tydeligvis ikke bruker om slike feil.

det gjør den. Det er en opsjon under oppsett av programmet.
Det er ikke horn og basurer, men markering at datoen er feil

2) Et slektsprogram som aksepterer informasjon i datofeltet som ikke kan
gjenkjennes ihht valgt dato-mal, skal "merke" denne informasjonen slik at
den omsluttes av en parentes når en gedcomfil lages. Alle de eksemplene som
er nevnt i denne debatten som stedsnavn eller ulovlige gedcomdatoer skulle
ha hatt en parentes "rundt seg". Eks (Hemsedal), (1-8-1952).

i og med at en kan skrive inn f.eks. latinske datoer m.m., så blir
dette markert som ugyldig dato, da dette faller utenfor standard
tall-formater. Det er videre meget vanskelig å teste på slike dager,
da dette vil variere meget på skrivemåte og språk m.m

.........

Det ser for meg ut som om BK
a) bør skjerpe sine rutiner mhp å varsle bruker om at valgt dato-mal brytes
og hva konsekvensen er.
b) Må rette den feil som åpenbart er der når slik informasjon ikke
eksporteres som tekst, mao med omsluttende parentes.

Brukeren må være seg noe bevisst.
Når man opplever at folk skriver inn stedsnavn i datofeltet og dato i
stedsfeltet så kommer dette mest ann på personene selv og ikke
programet og spesielt når man man ser at brukeren som taster inn slike
forhold uten å være konsekvente, jfr eksemplet fra tha, hvor det var
en blanding av datoformater og sansynligvis neppe konsekvent at
stedsnavn var skrevet i datofeltet.


Når det gjelder feil grunnet inntasting så er det klart at det kan bli
enda bedre, men man kan ikke gå så langt at man skal stenge/låse
felter/program hvis en bruker skriver feil.
Skal en ha horn og basuner, krever det også at brukeren kobler inn lyd

Det må også stilles krav til at brukeren bruker programmen slik som
man forutsetter og er konsekvente og strukturerte i sitt arbeid

De sies; rette åpenbare feil.
Tar gjerne i mot mange gode forslag på dette.

Når det så gjelder programmets transport så ligger det krav til den
datakvalitet som skal ekporteres og da er det også å kreve at
datakvaliteten er tilstrekkelig god.

Jeg vil igjen henvise til at 01.05.1999 ikke nødvendigvis er det samme
som 05.01.1999.
Her kreves et signal om vi snakker om mai eller januar og dette er det
kun brukeren av programmet som kan defineres.
Det gjøres under oppsett av programmet.

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Tue, 25 Jan 2005 14:24:31 GMT, in no.fritid.slektsforsking.it "John
Morten Malerbakken"
<[email protected]> wrote:

(ODB)

Any statement offered as a date when the year is not recognizable to a
date parser, but which gives information about when an event occurred. The
date phrase is enclosed in matching parentheses.


Der ser det i alle fall ut som om du har funnet en feil eller svakhet i BK i
alle fall. Ettersom standarden er temmelig tydelig på dette så burde det
være en kandidat for en forbedring av BK i alle fall.

denne feilen kjenner vi til da den allerede er anmerket i testen til
DIS, se II-C18 Import gedcom; import av dato?
BK er også trukket for poeng i testen for dette forholdet

Forholdet er også meldt fra til produsenten

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Tue, 25 Jan 2005 12:12:10 GMT, in no.fritid.slektsforsking.it "John
Morten Malerbakken"
<[email protected]> wrote:

Basert på dette så kan det sikkert hevdes, slik Torleif også gjør det, at BK
ikke burde eksportere data som ikke følger de innstillingene som er gjort i
programmet. Men det blir da igjen veldig knyttet til bruken av den filen. Om
to brukere av BK ønsker å eksportere data til og fra hverandre så blir altså
valgene den ene har gjort overført til den andre.

Hvis hver av brukerne har satt opp programmet i henhold til standard
for sitt bruk og legger inn datoer riktig, så blir også datoene
overført riktig. Det spiller ikke noe rolle da om den ene brukeren har
valgt å bruke 1954.06.24 og den andre 24 jun 1954
Dette ivaretas av standardformatet i GEDCOM og oppsettet og disse vil
spille riktig sammen

Det har da ingen betydning om mottaker har valg å bruke et eget
datoformat hos seg, så sant denne også har satt opp sitt program
riktig.

GEDCOM standarden f.eks. 17 MAY 1814
blir da konvertert til brukeren valgt format i henhold til at brukeren
har valgt riktig format.

Det er derfor valget under Oppsett av BK som gir resultatet. Det er en
konvertering som skjer med bakgrunn av GEDCOMfilens standard og
Oppsettet av Dato som igjen gir brukeren det riktig bildet i
Redigeringsbildet.



--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Tue, 25 Jan 2005 12:12:10 GMT, in no.fritid.slektsforsking.it "John
Morten Malerbakken"
<[email protected]> wrote:

Om jeg skulle få lov til å ønske meg en forbedring til BK måtte det være at
det gjøres en konsistenssjekk på data også ved generering av GEDCOM slik at
jeg måtte ta stilling til avvik under prosessen med mulighet for å rette
underveis.

vi ønsker mange endringer og forbedringer og mange er også presentert
produsenten.

Både fra Norsk og Dansk side har vi en god kommunikasjon mot
produsenten og flere av våre ønsker realiseres etter hver.

Vi ønsker å opprettholde denne gode dialogen, samtidig som vi presser
på for å presentere brukernes ønsker best mulig.

Vi har derfor også en egen postliste for BK i Norden, hvor vi kan
diskurere forhold som berører BK brukere
Her etterstrebes en konstruktiv diskusjon

En rekke forslag ble også presentert og diskutert i USA i høst da
Chris var i USA hos produsenten.
Alt om dette er også tilgjengelig på våre to hjemmesider.

Men det vil alltid komme nye behov og ønsker.

Dette er både en konsekvens av at hobbien øker i omfang og vi vil ha
flere opplysninger.
Det er ikke så lenge siden de fleste var fornøyd med navn og dato på
noen få begivenheter, til man nå ønsker å lage store slektsbøker.
Utviklingen er kommet og den vil også fortsette

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[dn10375]

Anne Lise Hovdal <[email protected]>:

Da kan jo også f.eks. 8.p.trinit. 1789 regnes som en dato,
det er jo slike tidsbetegnelser som det oftest står i kirke-
bøkene for 1700-tallet. Det er jo da riktig å skrive inn dette
syns jeg. Jeg skriver inn f.eks. 8.p. trinit.1789 i datofeltet,
og så kan jeg skrive inn datoen under M. På noen har jeg
gjort motsatt. Nå sender jo jeg ikke gedcomfiler til noen,
og legger heller ikke ut informasjon på hjemmesider.

Egentlig burde det vel vært mulig å legge inn datoen i
parentes, og det gjør jeg når jeg forsker for andre.

Datoer bør legges inn på en slik måte at programmet kan tolke den som
en gyldig dato, fordi programmet har (bør ha) beregnings- og
sorteringsfunksjoner som avhenger av dette.
Eksempelvis om du sorterer søkelista etter fødselsdato, eller vil
skrive ut ei liste over personer født før 1814, eller vil finne alle
som døde før de var 10 år gamle.
Datoer som du er usikker på kan legges inn med modifikatorer som "ca",
"før", "etter" o.a.

Den latinske skrivemåten bør også tas med, hvis den finnes i kilden,
men da i et fritekstlig notat til hendelsen eller til kildereferansen.
Du kan også angi en kildekvalitet for datoen som sådan, feks på
skalaen 0-3 der 3 er brennsikker.

---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
[email protected]
http://www.tha.no

[Otto Jørgensen]

On Tue, 25 Jan 2005 14:40:02 +0100, in no.fritid.slektsforsking.it
"Ole Bjørn Darrud" <[email protected]> wrote:

Det ser ut som herrene Otto og Torleif snakker forbi hverandre.
Det debatteres datofenomerner på forskjellige plan, relativt unyansert.

tja
Jeg har nå prøvd å dele dette opp i to

- Innlegging/registrering av dato-/steds-informasjon og den siden av
saken

_ behandling av riktige data i programmet og eksporten av disse


I begge sammenheng har jeg også prøvd å vise til at man normalt prøver
å sette opp et program etter det man ønsker.

Håper nå at en eventuell videre diskusjon starter som to serparate
tema (start helt med ny melding og nytt tema)
Da kan det bli litt mer ryddig og leserne som ikke kjenner til sakene
ikke blir helt forvirret.


--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Alf Christophersen]

On Sun, 23 Jan 2005 12:08:54 +0100, Otto Jørgensen
<otjoerge%øføø%@online.norway> wrote:

Så hvis du skriver et stedsnavn i et datofelt og du i tillegg får
bekjed om at dette er feil format, da kan du ikke forvente HEMSEDAL
skal bli til en dato: Tror du at det finnes noen trollmann inne i

Det er ingen forskjell fra Gedcoms synsvinkel om du skriver Hemsedal,
1. Juledag eller hva som helst annen tekststreng.

Det er greit og enkelt fullt tillatt å angi som dato, selv om Hemsedal
er ikke noen dato i det hele tatt.

Uansett, så skal BK eksportere det som tekststreng når dato ikke kan
oversettes til formatet dd MMM yyyy, det gjelder om dato er
01-MAR-1789, Hemsedal, 01-03-1789 or whatever ulikt 01 MAR 1789.

Det SKAL innesluttes i parenteser. ALLTID. Gjentar: ___ALLTID___

Altså er korrekt angivelse

2 DATE (Hemsedal)

Sørg for at Steed får dette med seg i første og beste oppgradering!

Inntil så skjer bør der inkluderes en sterk advarsel i testen av BK om
at dato eksporteres feil hvis dato ved innskrift ikke er satt opp på
formatet dd MMM yyyy. (F.eks. dd-MMM-yyyy som altså gir 01-MAR-1789
som resultat ved gedcom-eksport) etter hva du forteller om oppsett

[Alf Christophersen]

On Sun, 23 Jan 2005 15:25:35 +0100, Otto Jørgensen
<otjoerge%øføø%@online.norway> wrote:

Alt dette er forskjellige datoformater som kun viser at dette er
skrevet inn som blanding av fugl og fisk og ikke konsekvent,
sansynligvis importert GEDCOM over mange år fra ulike programmer eller
særlig ukonsekvent i sin registrering av dato.

Aha. Enda en feil. Også feil i import av dato bør det advares mot.

Det er BK sin jobb å oversette dato hvis det skjønner hva som er ib
feltet eller registrere det som tekstlig dato, f.eks. som en
kommentar.
(Og da skal teksten eksporteres som tekst, ikke utgis for å være en
dato i henhold til Gedcom-format.

[Alf Christophersen]

On Sun, 23 Jan 2005 19:55:40 +0100, Otto Jørgensen
<otjoerge%øføø%@online.norway> wrote:

Som i eksemplene du kom med i begynnelsen, så kan ikke programmet
omforme stedsnavn til datoer.

Det skal markere at det er fritekst. Og eksportere det som fritekst.
Dvs. pakke det inn i parenteser.

[Otto Jørgensen]

On Wed, 26 Jan 2005 00:31:01 +0100, in no.fritid.slektsforsking.it Alf
Christophersen <[email protected]> wrote:

On Sun, 23 Jan 2005 12:08:54 +0100, Otto Jørgensen
otjoerge%øføø%@online.norway> wrote:

Så hvis du skriver et stedsnavn i et datofelt og du i tillegg får
bekjed om at dette er feil format, da kan du ikke forvente HEMSEDAL
skal bli til en dato: Tror du at det finnes noen trollmann inne i

Det er ingen forskjell fra Gedcoms synsvinkel om du skriver Hemsedal,
1. Juledag eller hva som helst annen tekststreng.

Det er greit og enkelt fullt tillatt å angi som dato, selv om Hemsedal
er ikke noen dato i det hele tatt.

Uansett, så skal BK eksportere det som tekststreng når dato ikke kan
oversettes til formatet dd MMM yyyy, det gjelder om dato er
01-MAR-1789, Hemsedal, 01-03-1789 or whatever ulikt 01 MAR 1789.

Det SKAL innesluttes i parenteser. ALLTID. Gjentar: ___ALLTID___

Altså er korrekt angivelse

2 DATE (Hemsedal)

Sørg for at Steed får dette med seg i første og beste oppgradering!

Inntil så skjer bør der inkluderes en sterk advarsel i testen av BK om
at dato eksporteres feil hvis dato ved innskrift ikke er satt opp på
formatet dd MMM yyyy. (F.eks. dd-MMM-yyyy som altså gir 01-MAR-1789
som resultat ved gedcom-eksport) etter hva du forteller om oppsett

Ingen bestrider at det her skal inn en parentes rundt en slik dato

Og leser du selv det som står i testen så er dette også angitt i
testens resultat.
Jeg går ut fra at du har fått med deg dette.

Når det gjelder at dette volumet av slike stedsnavn i datofeltet så
vil jeg jo ikke kommentere dette mer enn tidligere. Det synes som
enkelte har problemer å forstå at et stedsfelt er til stedsnavn og
datofelt er til dato

At i tillegg personen har tastet inn mange ulike datoformater. er en
side av saken og bør jo ikke forefinnes, men som nevnt er det varsel
om feilaktig datoinnlegging.

Det underlige er jo at enkelte klarer å gjøre alt feil.
Det er også underlig at enkelte debatanter ikke klarer å skille mellom
personens innlegging av data og programmet behandling av de innlagte
data, til tross for at de samme personene har terpet på dette i mange
fora og fått tilsvarende mange svar på sine spørsmål.

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Wed, 26 Jan 2005 00:31:04 +0100, in no.fritid.slektsforsking.it Alf
Christophersen <[email protected]> wrote:

On Sun, 23 Jan 2005 19:55:40 +0100, Otto Jørgensen
otjoerge%øføø%@online.norway> wrote:

Som i eksemplene du kom med i begynnelsen, så kan ikke programmet
omforme stedsnavn til datoer.

Det skal markere at det er fritekst. Og eksportere det som fritekst.
Dvs. pakke det inn i parenteser.

Det tema tok du opp i tidligere melding for få sekund siden og
tidligere i dette tema.

Jeg tror de aller fleste har fått med seg poenget. Jeg tor det her er
mer et problem at du har fått svar, men ikke har klart å ta det
innover deg.

Jeg tror du skal lese dine egene spørsmål og de svar som du har fått.

Men uansett, en bruker kan ikke fraskrive seg ansvaret for sine data.

I grunnen er det kun snakk om en feil.
Nemlig at ugyldige datoer, skal ha en parentes. Dette er nevnt i
testen fra DIS og det er akseptert at dette er en feil.

Skal vi snakke om flere feil, så er det at brukeren overhode ikke
leser bruksveiledningen.


--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Wed, 26 Jan 2005 00:31:03 +0100, in no.fritid.slektsforsking.it Alf
Christophersen <[email protected]> wrote:

On Sun, 23 Jan 2005 15:25:35 +0100, Otto Jørgensen
otjoerge%øføø%@online.norway> wrote:

Alt dette er forskjellige datoformater som kun viser at dette er
skrevet inn som blanding av fugl og fisk og ikke konsekvent,
sansynligvis importert GEDCOM over mange år fra ulike programmer eller
særlig ukonsekvent i sin registrering av dato.

Aha. Enda en feil. Også feil i import av dato bør det advares mot.

Svært så mange feil du kan klare å gjøre av en feil

Det er BK sin jobb å oversette dato hvis det skjønner hva som er ib
feltet eller registrere det som tekstlig dato, f.eks. som en
kommentar.
(Og da skal teksten eksporteres som tekst, ikke utgis for å være en
dato i henhold til Gedcom-format.

Dette er også omtalt i testen så hvis man leser det, vil man finne at
dette er omtalt

Det er er avgivende program som skal sørge for at det er riktig vel så
mye at mottagende program skal sørge for at det er riktig

Men mest av alt er det bruker av programvaren som også bør ha en stor
egeninteresse å kontrollere sine egne data.

Dette glir som om du putter blyholdig bensin i en bil som går på
blyfri bensin.


Så her er det i grunnen kun en feil, at det som ikke kan defineres som
dato ikke har fått en parentes rundt seg.
Saken er jo grei, det dreier seg om hva brukeren har puttet inn i det
feltet som er markert som dato og som brukeren av mangel på
alminnelige kunnskaper ikke forstår at dette er feil og at et
stedsnavn ikke er dato.
Jeg kan desverre ikke sitte å fortelle en person slike grunnleggende
kunnskaper som bl.a. å lese en overskrift over en kolonne.

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Ole Bjørn Darrud]

For ordens skyld:

DIS-Norges test slik den i dag fremstår fanger ikke opp alle de
problemstillinger som er tatt opp her ang. gedcom og bruk av parentes.
De nye testkriteriene som det nå jobbes med vil fange opp både import og
eksport av tekst i datofelt.
"Alle" program vil i denne sammenheng bli testet opp mot de nye kriteriene.
Jeg vil/kan derfor ikke kommentere hvordan "alle" programmene klarer dette
pt.
Mine tidligere kommentarer var som nevnt baser på info gitt i dette forum,
ikke basrt på DIS-N testkriterier.
Generelt anbefaler jeg ihuga programforkjempere å sjekke "egne" program og
ta dette opp med "egen" leverandør, fremfor å tåkelegge debatten med
skit-kasting.

Mvh
Ole Bjørn

[Alf Christophersen]

On Mon, 24 Jan 2005 23:42:13 +0100, Otto Jørgensen
<otjoerge%øføø%@online.norway> wrote:

husk å bruke datospenn måt du tar for deg datoer som f.eks. 1740-1750

Mener du at du skal bruke enten BTW 1740 AND 1750 eller FROM 1740 TO
1750, eller aksepterer BK 1740-1750 ?? Ser til stadighet det siste i
Gedcomfiler, en notasjon det ikke er dekning for i Gedcom 5.5

Kanskje bør også BK innføre mer rigid datoinnskriving hvor valgt
datoformat medfører at det dukker opp inputfelter hvor det testes på
rimelighet av dato før man får lov til å forlate innskrivingsfeltet,
men hvor layout av inputfeltet varierer med hva man har angitt som mal
og at det innskrevne konverteres ved lagring til et entydig format,
slik at det ved senere retting og endret datoformat dukker opp på rett
form og hvor man kan angi om dato skal angis tekstlig og tolkes dit og
dit. (Altså eksporteres INT 17 FEB 1793 (1. søndag i faste 1793) eller
bare (1. søndag i faste 1793)

Ved å innføre rigid kontroll slipper man masse rettearbeide senere når
andre begynner å spørre eller man ikke lenger klarer å tolke hva man
selv registrerte.

[Alf Christophersen]

On Tue, 25 Jan 2005 08:59:03 +0100, "Lars Kr. Lundin"
<[email protected]> wrote:

Det er sandt:

Sender man sin GEDCOM-fil til [email protected] får man i løbet af meget
kort tid (minutter eller timer afhængig af døgnets tidspunkt) en meget
detaljeret kontrol rapport af sin GEDCOM-fil.

I motsetning til hva Lundin påstår i siste Diskulogen (medlemsbladet
til Föreningen DIS) så foretar også GEDtreff-programmet (som brukes
til å lage Distreff/Distræf materiale) slike sjekker, men rapporterer
også feil i soknenavn.

Alle medlemmer i DIS-Norge har full anledning til å hente ned
GEDtreff, og når det er bedre testet for danske forhold, vil også
medlemmer av DIS-Danmark få anledning til det samme.

Noe arbeide gjenstår før også medlemmer i Föreningen DIS kan ta det i
bruk hjemme.

[Alf Christophersen]

On Tue, 25 Jan 2005 14:24:31 GMT, "John Morten Malerbakken"
<[email protected]> wrote:

Helt klart. Bør komme snart også. Vet ikke hvor gammel den spesifikasjonen
er, men dette ser ut som noe som kan ha vært en svakhet lenge.

Tviler jeg sterkt på i og med feilen har vært påpekt omtrent like
lenge som GEDtreff-prosjektet har pågått.
Det er faktisk siden 2002 (Dvs. da slapp første versjon ut til
bruk av faddere)

[Alf Christophersen]

On Tue, 25 Jan 2005 17:18:27 +0100, Otto Jørgensen
<otjoerge%øføø%@online.norway> wrote:

denne feilen kjenner vi til da den allerede er anmerket i testen til
DIS, se II-C18 Import gedcom; import av dato?
BK er også trukket for poeng i testen for dette forholdet

Hvor mange oppdateringer har kommet uten at dette er korrigert? Det
tyder sterkt på at produsent ikke tar denne feilen seriøst. På lik
linje med vedkommendes manglende interesse i sin tid for å korrigere
navn på tegnsettet som ble brukt ved eksport (ANSI ble konsekvent kalt
IBM PC, et tegnsettnavn som angir at kun bokstavene A-Z og a-z er
gyldige bokstaver og utvidete tegnsett kodes etter CODEPAGE 437, noe
som ga mye rart når tegnsettet i virkeligheten var ANSI, et tegnsett
hvor æ,ø og å og mange andre tegn er definert på en helt annen plass
enn i ANSI. Noe som ga resultat i mye rart ved innlesing av
Gedcom-filer. med my, lambda og andre greske tegn i tekstene etc.

[Otto Jørgensen]

On Thu, 27 Jan 2005 15:42:04 +0100, in no.fritid.slektsforsking.it Alf
Christophersen <[email protected]> wrote:

On Tue, 25 Jan 2005 17:18:27 +0100, Otto Jørgensen
otjoerge%øføø%@online.norway> wrote:

denne feilen kjenner vi til da den allerede er anmerket i testen til
DIS, se II-C18 Import gedcom; import av dato?
BK er også trukket for poeng i testen for dette forholdet

Hvor mange oppdateringer har kommet uten at dette er korrigert? Det
tyder sterkt på at produsent ikke tar denne feilen seriøst. På lik
linje med vedkommendes manglende interesse i sin tid for å korrigere
navn på tegnsettet som ble brukt ved eksport (ANSI ble konsekvent kalt
IBM PC, et tegnsettnavn som angir at kun bokstavene A-Z og a-z er
gyldige bokstaver og utvidete tegnsett kodes etter CODEPAGE 437, noe
som ga mye rart når tegnsettet i virkeligheten var ANSI, et tegnsett
hvor æ,ø og å og mange andre tegn er definert på en helt annen plass
enn i ANSI. Noe som ga resultat i mye rart ved innlesing av
Gedcom-filer. med my, lambda og andre greske tegn i tekstene etc.

Det nå ANSEL som er det mest saliggjørende formatet for GEDCOM, ref
spesifikasjonen til GEDCOM 5.5

Og det er vel også det som skal være saliggjørende for DISTREFF.
Jeg vil anta at det ikke er noen feil der.

Og om det er en feil ved at det står IBMPC eller ansi så er vel
kodesettet som her kan i filene være feilaktig angitt være i samsvar
med ANSI ?

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Thu, 27 Jan 2005 15:41:58 +0100, in no.fritid.slektsforsking.it Alf
Christophersen <[email protected]> wrote:

On Mon, 24 Jan 2005 23:42:13 +0100, Otto Jørgensen
otjoerge%øføø%@online.norway> wrote:

husk å bruke datospenn måt du tar for deg datoer som f.eks. 1740-1750

Mener du at du skal bruke enten BTW 1740 AND 1750 eller FROM 1740 TO
1750, eller aksepterer BK 1740-1750 ?? Ser til stadighet det siste i
Gedcomfiler, en notasjon det ikke er dekning for i Gedcom 5.5

for datospenn klikker du i datofeltet og legger inn datoen og du har
riktig resultat i GEDCOM.

Når det gjelder det tredje formatet som er angitt så angis det som
feilaktig format, men aksepteres av programmet.

Kanskje bør også BK innføre mer rigid datoinnskriving hvor valgt
datoformat medfører at det dukker opp inputfelter hvor det testes på
rimelighet av dato før man får lov til å forlate innskrivingsfeltet,
men hvor layout av inputfeltet varierer med hva man har angitt som mal
og at det innskrevne konverteres ved lagring til et entydig format,
slik at det ved senere retting og endret datoformat dukker opp på rett
form og hvor man kan angi om dato skal angis tekstlig og tolkes dit og
dit. (Altså eksporteres INT 17 FEB 1793 (1. søndag i faste 1793) eller
bare (1. søndag i faste 1793)

til det siste med bruk av parentes, så tyder det på at en rekke
programmer ikke klarer dette.

For brukeren er vel for å sitere en annen persom
"Poenget må være å formidle tidspunktet for hendelsen på en måte som
mottakeren forstår"

Man kan etterstrebe det perfekte, men dette vil du aldre oppnå

I tillegg må jeg vel si at det finnes grenser hvor rigid man skal være
i innskriving av dato for å tilfredstille GEDCOM.
Og målet for de fleste er den slektsbok de vil distribuere til sine
slektninger.

At dette kommer i konflik med det perfekte og de sterke ønsker som
kommer fra "DIStreff-sjefen" må en vel bare konstatere.
Jeg tror brukerne ønsker må settes høyest.

Dette er ikke noe motstridende med at man skal strebe etter det
perfekte.

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Thu, 27 Jan 2005 15:42:02 +0100, in no.fritid.slektsforsking.it Alf
Christophersen <[email protected]> wrote:

On Tue, 25 Jan 2005 14:24:31 GMT, "John Morten Malerbakken"
John.Morten.removethisparttoreply@maler ... ovethiscom> wrote:

Helt klart. Bør komme snart også. Vet ikke hvor gammel den spesifikasjonen
er, men dette ser ut som noe som kan ha vært en svakhet lenge.

Tviler jeg sterkt på i og med feilen har vært påpekt omtrent like
lenge som GEDtreff-prosjektet har pågått.
Det er faktisk siden 2002 (Dvs. da slapp første versjon ut til
bruk av faddere)

du har irritert deg lenge over mange forhold og i den anledning har du
bedt om adresse til produsenten og jeg antar at det var i den mening
at du ville ta en forhold knyttet til datoformater opp med
vedkommende.

Jeg vet ikke om du har gjordt det, men som tidligere nevnt, ser jeg
jo gjerne at du retter en del av dine skudd direkte mot produsenten av
de respektive programmet
(det er flere programmer som har problemer innenfor denne rammen)

Muligens kan dette ha den virkning at parenteser kommer på plass i
flere program og at dateregistrering blir mer rigid (låsing av pC
eller horn og lur for å vekke folk)

Men jeg vil jo anmode at du er mer nyansert og ikke legger ut dine
kommentarer som om det kun er BK som har alle feilene du reagerer på

For deg kan det være ille nok, i og med at BK er et av de programmet
som er mest brukt og som er vel største bidragsyter i DISTREFF, men
flere program har feil og det ville være mer nyansert om du i større
grad gikk løs på problemet generelt over en større skala og legger opp
til å dekke samtlige tilgjengelig program.

La det bli en sak om bedre datoformat for alle slektsprogram

Vi som arbeider med spesifikke program, gjør det vi kan, men vi
trenger ofte backing og ikke det motsatte
Vi trenger seriøsitet også fra DISTREFF-siden

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Thu, 27 Jan 2005 10:49:41 +0100, in no.fritid.slektsforsking.it
"Ole Bjørn Darrud" <[email protected]> wrote:

For ordens skyld:

DIS-Norges test slik den i dag fremstår fanger ikke opp alle de
problemstillinger som er tatt opp her ang. gedcom og bruk av parentes.
De nye testkriteriene som det nå jobbes med vil fange opp både import og
eksport av tekst i datofelt.
"Alle" program vil i denne sammenheng bli testet opp mot de nye kriteriene.
Jeg vil/kan derfor ikke kommentere hvordan "alle" programmene klarer dette
pt.
Mine tidligere kommentarer var som nevnt baser på info gitt i dette forum,
ikke basrt på DIS-N testkriterier.
Generelt anbefaler jeg ihuga programforkjempere å sjekke "egne" program og
ta dette opp med "egen" leverandør, fremfor å tåkelegge debatten med
skit-kasting.

Kun en kort kommentar.

Jeg går ut fra at samtlige ihuga programtilhengere også har en rimelig
god oversikt over "sine" program.
De same vet også om DIStestene og det som står der og tar arbeidet som
nedlegges der som et seriøst arbeid så langt dette er mulig på
frivillig basis
Dermed skulle det ikke vær nødvendig med 50 til 100 innlegg for å
repitere dette flere ganger i året.
Distestene er tilgjengelig for alle.

Testene synes imidlertid så langt ¨ha en mangel på samspill som minst
også dekker opp andre produkter som leveres av DIS, men dette
forventes er dekket opp i den nye testen


--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Thu, 27 Jan 2005 15:42:04 +0100, in no.fritid.slektsforsking.it Alf
Christophersen <[email protected]> wrote:

On Tue, 25 Jan 2005 17:18:27 +0100, Otto Jørgensen
otjoerge%øføø%@online.norway> wrote:

denne feilen kjenner vi til da den allerede er anmerket i testen til
DIS, se II-C18 Import gedcom; import av dato?
BK er også trukket for poeng i testen for dette forholdet

Hvor mange oppdateringer har kommet uten at dette er korrigert? Det
tyder sterkt på at produsent ikke tar denne feilen seriøst. På lik
linje med vedkommendes manglende interesse i sin tid for å korrigere
navn på tegnsettet som ble brukt ved eksport (ANSI ble konsekvent kalt
IBM PC, et tegnsettnavn som angir at kun bokstavene A-Z og a-z er
gyldige bokstaver og utvidete tegnsett kodes etter CODEPAGE 437, noe
som ga mye rart når tegnsettet i virkeligheten var ANSI, et tegnsett
hvor æ,ø og å og mange andre tegn er definert på en helt annen plass
enn i ANSI. Noe som ga resultat i mye rart ved innlesing av
Gedcom-filer. med my, lambda og andre greske tegn i tekstene etc.

en tillegg til denne, hva står i header til disse filene du referer
til

2 VERS 6.1.35 WINDOWS
1 DEST BROSKEEP (BROTHERS KEEPER)
1 DATE 27 JAN 2005
1 CHAR ANSI

Hva er angitt som versjonenummer, ref . 1. linje
Vil gjerne ha dette slik at man har en skikkelig referansen.

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Alf Christophersen]

On Wed, 26 Jan 2005 06:38:02 +0100, Otto Jørgensen
<otjoerge%øføø%@online.norway> wrote:

I grunnen er det kun snakk om en feil.
Nemlig at ugyldige datoer, skal ha en parentes. Dette er nevnt i
testen fra DIS og det er akseptert at dette er en feil.

Ja, og når skal det rettes opp? I 2050?? Nå har det blitt påpekt
lenge, og intet skjer.

Skal vi snakke om flere feil, så er det at brukeren overhode ikke
leser bruksveiledningen.

Ang. eksporten til GEDCOM er det programmøren sin jobb å
kvalitetssikre dette.
Så lenge datamodellen ikke støtter dette, men aksepterer rubbel og bit
noen måtte komme til å skrive i datofeltet ved et uhell, så blir det
nok som det er. Kanskje fikses det i BK 25.34 (altså om 19 versjoner
til??)

Lykkelig over å bruke et program som sier piiiip og nekter å ta imot
bokstaver når et tall forventes og ved å trykke på en "lampe" ved
siden av datofeltet kan gå inn og fylle inn dato på de forventede
formater som ønskes, f.eks. før eller etter etc, tekststreng etc.

[Otto Jørgensen]

On Thu, 27 Jan 2005 23:05:06 +0100, in no.fritid.slektsforsking.it Alf
Christophersen <[email protected]> wrote:

On Wed, 26 Jan 2005 06:38:02 +0100, Otto Jørgensen
otjoerge%øføø%@online.norway> wrote:

I grunnen er det kun snakk om en feil.
Nemlig at ugyldige datoer, skal ha en parentes. Dette er nevnt i
testen fra DIS og det er akseptert at dette er en feil.

Ja, og når skal det rettes opp? I 2050?? Nå har det blitt påpekt
lenge, og intet skjer.


Skal vi snakke om flere feil, så er det at brukeren overhode ikke
leser bruksveiledningen.

Ang. eksporten til GEDCOM er det programmøren sin jobb å
kvalitetssikre dette.
Så lenge datamodellen ikke støtter dette, men aksepterer rubbel og bit
noen måtte komme til å skrive i datofeltet ved et uhell, så blir det
nok som det er. Kanskje fikses det i BK 25.34 (altså om 19 versjoner
til??)

Lykkelig over å bruke et program som sier piiiip og nekter å ta imot
bokstaver når et tall forventes og ved å trykke på en "lampe" ved
siden av datofeltet kan gå inn og fylle inn dato på de forventede
formater som ønskes, f.eks. før eller etter etc, tekststreng etc.

skulle ikke du skrive brev til Steed?

Jeg har ikke lyd på så piip eller puh ville ikke hjulpet allikevel,
men jeg reagerer på røde farger da jeg ikke er fargeblind.

Når det gjelder parentesen så er det vel flere andre program som og
har dette problemet meg beskjent.

BK25.34 vil sansynligvis kommer etter at vår levetid er ute, så det
får bli andre bekymring

Resten har jeg besvart utallige ganger og det begynner vel nå å komme
til et stadium at jeg ikke snart gidder å svare på dine innlegg

Ha en hyggelig natt


--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[dn10375]

On Tue, 25 Jan 2005 12:12:10 GMT, "John Morten Malerbakken"

..........

Jeg ser ikke på denne debatten som stort annet enn at man sikkert kan være
klarere med informasjon til brukerne i forhold til den friheten som ligger i
BK, og som jeg får inntrykk av at ikke er helt den samme i TMG (selv om det
sikkert på vanlig måte finnes massevis med innstillinger man kan skru på
der).

TMG har ingen bastante krav til inntastingsformatet, og har 9
forskjellige visningsformat individuelt for skjerm og rapporter.
Visningsformatet kan byttes om nårsomhelst, også separat for hver
rapport uavhengig av det valgte formatet på skjermen.
Og det skjer ingen farlig re-lagring av alle datoene i databasen, det
er bare visningen som endres.

Fem av visningsformatene har rekkefølgen dag+mnd+år som vi bruker i
Norge.
To av disse er: dd.mm.åååå og dd mmm åååå som kan bli feks 17.5.1814
og 17 mai 1814.
Det heilnorske "dd. mmm åååå" (med punktum bak dagtallet) finnes
dessverre ikke i TMG ennå.
TMG takler greit ufullstendige datoer som "mai 1814", så i en rapport
vil det stå "han var igjen på heisatur i Oslo i mai 1814".

Inntasting av datoer kan gjøres på mange måter, TMG tolker dem og
viser deg resultatet før du godkjenner det.
Om du lagrer en åpenbart irregulær dato som "før påske 1901" får du en
meldingsboks midt på skjermen som sier "før påske 1901 er lagret som
en irregulær dato". Det er å anbefale at brukeren skriver/beregner en
mer nøyaktig dato i slike tilfelle, feks "før 23.3.1901", slik at TMG
kan bruke datoen til nornmal sortering, søking, filtrering osv.
Av inntastingsformat som TMG tolker greitt er disse: 12f1888 =>
12.2.1888, 3o1999 => 3.10.1999, 2.2.1888 => 2. februar 1888.
12021999 tolkes derimot ikke som en gyldig dato.'

TMG har faktisk to datoer for hver hendelse, den andre er
sorteringsdatoen. Den er vanligvis identisk med hendelsesdatoen, men
styres helt av brukeren og brukes av TMG til å plassere hendelsen i
rett rekkefølge i forhold til de andre hendelsene. Som eksempelvis at
fødsel er før død hvis datoene er ufullstendige eller ukjente.

TMG lagrer datoene i et internt kodet format som er usynlig for
brukeren. Lagringsformatet har informasjon om datoen er en irregulær
type (som "to dager før påske"), om det er lagt inn en datomodifikator
(som "ca", "før" osv), om det er snakk om et tidsrom (altså fra-til
eller mellom).
Eksempel: "119610924000000000000" som betyr "før 9. september 1961".


---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
[email protected]
http://www.tha.no

[Alf Christophersen]

On Thu, 27 Jan 2005 16:09:21 +0100, Otto Jørgensen
<otjoerge%øføø%@online.norway> wrote:

At dette kommer i konflik med det perfekte og de sterke ønsker som
kommer fra "DIStreff-sjefen" må en vel bare konstatere.
Jeg tror brukerne ønsker må settes høyest.

Hittil har jeg opplevd problemet med feil i tekster i datofelt kun med
to programmer. Vedkommende bak det andre programmet tok hintet og
gjorde noe med det umiddelbart. Hittil har jeg ikke sett tilsvarende
respons med BK.

Får nok informere vedkommende om feilen selv.
Jaja.

[Alf Christophersen]

On Thu, 27 Jan 2005 15:53:59 +0100, Otto Jørgensen
<otjoerge%øføø%@online.norway> wrote:

Og om det er en feil ved at det står IBMPC eller ansi så er vel
kodesettet som her kan i filene være feilaktig angitt være i samsvar
med ANSI ?

Står det angitt IBM PC som kodesett skal tallverdiene bak bokstavene
tolkes helt annerledes, dvs. der skal da foretas en OemToANSI
konvertering, og da er man med en gang på gyngende grunn. Er
eksporterende maskin satt opp med Codepage 437, 850 eller 865 (i Norge
vel og merke) eller hva.

Hvis da tegnsettet var ANSI blir alle norske bokstaver og bokstaver
med aksenter oversatt i hytt og pine, som oftest til noe lite leselig.

Står det ANSI skal tegnene ikke oversettes.
Står det ANSEL skal tegnene oversettes fra ANSEL til ANSI i gedtreff
Står det MAC skal tegnene oversettes til ANSI under kjøring og tilbake
til Mac etterpå. Dette er dog ikke testet fullt ut ennå fordi
tilbakesending til en Mac kan foreta seg mye rart med tegnsettet.
Sikrest er dog å oversette tilbake til Mac og pakke fil med zip som
ikke endrer koding av bokstaver.

[Alf Christophersen]

On Thu, 27 Jan 2005 17:38:29 +0100, Otto Jørgensen
<otjoerge%øføø%@online.norway> wrote:

2 VERS 6.1.35 WINDOWS
1 DEST BROSKEEP (BROTHERS KEEPER)
1 DATE 27 JAN 2005
1 CHAR ANSI

Hva er angitt som versjonenummer, ref . 1. linje
Vil gjerne ha dette slik at man har en skikkelig referansen.

La du ikke merke til at jeg skrev, siterer: "I sin tid ikke ....."

[Otto Jørgensen]

On Fri, 28 Jan 2005 23:35:34 +0100, in no.fritid.slektsforsking.it Alf
Christophersen <[email protected]> wrote:

On Thu, 27 Jan 2005 17:38:29 +0100, Otto Jørgensen
otjoerge%øføø%@online.norway> wrote:

2 VERS 6.1.35 WINDOWS
1 DEST BROSKEEP (BROTHERS KEEPER)
1 DATE 27 JAN 2005
1 CHAR ANSI

Hva er angitt som versjonenummer, ref . 1. linje
Vil gjerne ha dette slik at man har en skikkelig referansen.

La du ikke merke til at jeg skrev, siterer: "I sin tid ikke ....."

Beklager ALf, Jeg snakker ikke om historie.
Når det kommer merknader så snakker jeg ikke om snøen som falt i
fjor, men dagens situasjon og som jeg har nevnt utallige ganger,

Hvis det ikke er angitt versjonnummer i GEDCOM-filen, da er det på
tide at det oppdateres og jeg forventer at jeg fra din side heller
ikke får merknader om filer som ikke har angitt versjonsnummer.


--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Fri, 28 Jan 2005 23:35:32 +0100, in no.fritid.slektsforsking.it Alf
Christophersen <[email protected]> wrote:

On Thu, 27 Jan 2005 15:53:59 +0100, Otto Jørgensen
otjoerge%øføø%@online.norway> wrote:

Og om det er en feil ved at det står IBMPC eller ansi så er vel
kodesettet som her kan i filene være feilaktig angitt være i samsvar
med ANSI ?

Står det angitt IBM PC som kodesett skal tallverdiene bak bokstavene
tolkes helt annerledes, dvs. der skal da foretas en OemToANSI
konvertering, og da er man med en gang på gyngende grunn. Er
eksporterende maskin satt opp med Codepage 437, 850 eller 865 (i Norge
vel og merke) eller hva.

Hvis da tegnsettet var ANSI blir alle norske bokstaver og bokstaver
med aksenter oversatt i hytt og pine, som oftest til noe lite leselig.

Står det ANSI skal tegnene ikke oversettes.
Står det ANSEL skal tegnene oversettes fra ANSEL til ANSI i gedtreff
Står det MAC skal tegnene oversettes til ANSI under kjøring og tilbake
til Mac etterpå. Dette er dog ikke testet fullt ut ennå fordi
tilbakesending til en Mac kan foreta seg mye rart med tegnsettet.
Sikrest er dog å oversette tilbake til Mac og pakke fil med zip som
ikke endrer koding av bokstaver.

Jeg synes du kan ta disse teoriene et annet sted.
Du klager på filene og da forholder jeg meg til det og ikke historie.
Det er vist i et annet svar til headingen i GEDCOMfilen.
Står det ikke versjonnummer så er det uten interesse. Er det nytt
versjonnummer og det er feil, da kan vi snakke om dette.

Alt annet er å kverne på gammelt støv

Alle som ikke har versjonnummer i heading på GEDCOMfilen, anbefales å
oppdatere.

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Fri, 28 Jan 2005 23:35:31 +0100, in no.fritid.slektsforsking.it Alf
Christophersen <[email protected]> wrote:

On Thu, 27 Jan 2005 16:09:21 +0100, Otto Jørgensen
otjoerge%øføø%@online.norway> wrote:

At dette kommer i konflik med det perfekte og de sterke ønsker som
kommer fra "DIStreff-sjefen" må en vel bare konstatere.
Jeg tror brukerne ønsker må settes høyest.

Hittil har jeg opplevd problemet med feil i tekster i datofelt kun med
to programmer. Vedkommende bak det andre programmet tok hintet og
gjorde noe med det umiddelbart. Hittil har jeg ikke sett tilsvarende
respons med BK.

Får nok informere vedkommende om feilen selv.
Jaja.

Jeg går at du har fått med deg dette med versjonsnummer og at brukere
som sender inn bidrag uten versjonnummer bør oppdatere sitt program.
Det er ikke mer å si om dette.

Jeg har ingen ting med andre programmer å gjøre, slik at det må bli
opp til deg eller andre å ta den saken.


Men jeg tror nå at man snart skal kunne glemme historikk og forholde
seg til dagens situasjon og da snakker vi i BK sammenheng om versjoner
som er datert i 2005.

Etter som jeg også har forstått er alle registrerte brukere av BK5
også tilskrevet direkte fra produsenten og orientert om at BK6
eksisterer.

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[dn10375]

Ole Bjørn Darrud
.....

DIS-Norges test slik den i dag fremstår fanger ikke opp alle de
problemstillinger som er tatt opp her ang. gedcom og bruk av parentes.
De nye testkriteriene som det nå jobbes med vil fange opp både import og
eksport av tekst i datofelt.
"Alle" program vil i denne sammenheng bli testet opp mot de nye kriteriene.
.....

DIS-Norges tester(e) bør bruke sin prisverdige og tilmålte fritid til
tester som er skikkelig viktige, denne parentesen er bare en parentes
i denne sammenheng, den er ytterst lite interessant og helt uten
betydning for slektsforskere. Og det er jo ingen som vil ha en
parentes rundt datoer i sine utskrifter.
Om den kreves i den gamle, stivbeinte og utdaterte GEDCOMstandarden er
uviktig, og diskutabelt. DIS-Norges DIStreffprogram har heller ingen
relevans her, om dette har lyst på parenteser.

Det som er viktig å teste for innlegging og GEDCOMeksport av datoer i
et slektsdataprogram er at programmets inntastingsskjermbilde

a) sier fra på en tydelig måte til brukeren om den inntastede dato
_ikke_ er akseptert som en gyldig dato

b) om aksepterte datoer eksporteres på korrekt format til GEDCOMfil,
altså DD MMM ÅÅÅÅ med engelsk MMM

c) at irregulære datoer (feks rein tekst) i datofeltet er mulig, men
at programmet sier fra om dette til brukeren når slik registrering
skjer

d) eksporten av irregulære "tesktdatoer" skal skje uten endring av
teksten

e) i tillegg må det, som nå, testes om de vanlige datomodifikatorer
kan legges inn og blir akseptert som en gyldig dato og blir eksportert
med de korrekte modifikatorkoder


På importsida for datoer er det sjølsagt ønskelig at programmet er
mest mulig alt-etende uten dikkedarer. Hvis programmet forstår og
aksepterer en dato er det ingen vits i å plage brukeren med meldinger
om at leveransen fra det andre programmet var kritikkverdig. Men hvis
datoen er av typen fritekst eller irregulær, bør dette meldes fra om i
den tilhørende kvitteringsfil fra importprosessen.

Lykke til videre med den verdifulle oppdateringa av testen!

(Jeg prøvde for flere dager siden å endre tittelen på dette
datotemaet, men ingen fulgte med på den tråden....)

---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
[email protected]
http://www.tha.no

[Otto Jørgensen]

On Sat, 29 Jan 2005 09:11:51 +0100, in no.fritid.slektsforsking.it
torleif haugødegård <[email protected]> wrote:

DIS-Norges tester(e) bør bruke sin prisverdige og tilmålte fritid til
tester som er skikkelig viktige, denne parentesen er bare en parentes
i denne sammenheng, den er ytterst lite interessant og helt uten
betydning for slektsforskere. Og det er jo ingen som vil ha en
parentes rundt datoer i sine utskrifter.
Om den kreves i den gamle, stivbeinte og utdaterte GEDCOMstandarden er
uviktig, og diskutabelt. DIS-Norges DIStreffprogram har heller ingen
relevans her, om dette har lyst på parenteser.

Det som er viktig å teste for innlegging og GEDCOMeksport av datoer i
et slektsdataprogram er at programmets inntastingsskjermbilde

a) sier fra på en tydelig måte til brukeren om den inntastede dato
_ikke_ er akseptert som en gyldig dato

b) om aksepterte datoer eksporteres på korrekt format til GEDCOMfil,
altså DD MMM ÅÅÅÅ med engelsk MMM

c) at irregulære datoer (feks rein tekst) i datofeltet er mulig, men
at programmet sier fra om dette til brukeren når slik registrering
skjer

d) eksporten av irregulære "tesktdatoer" skal skje uten endring av
teksten

e) i tillegg må det, som nå, testes om de vanlige datomodifikatorer
kan legges inn og blir akseptert som en gyldig dato og blir eksportert
med de korrekte modifikatorkoder


På importsida for datoer er det sjølsagt ønskelig at programmet er
mest mulig alt-etende uten dikkedarer. Hvis programmet forstår og
aksepterer en dato er det ingen vits i å plage brukeren med meldinger
om at leveransen fra det andre programmet var kritikkverdig. Men hvis
datoen er av typen fritekst eller irregulær, bør dette meldes fra om i
den tilhørende kvitteringsfil fra importprosessen.

på flere områder kan jeg nok være enig i synspunktene, fordi at for de

fleste brukere vil det neppe være problem om det står i gedcomfilen
1. september 1890 eller om det står 01 SEP 1890

Men når en først har bestemt seg for å teste eksport og import i
henhold til GEDCOMstandarden, så er nok min mening at da skal man
teste helespekteret knyttet til datoer og da får man ta med alt, både
parenteser, små bokstaver, feilaktige bindestreker osv.

Jeg må allikevel undre meg litt over endring i en del holdninger når
en plutselig fremkommer at det plutselig ikke er så farlig med mindre
avvik, mens det i tidligere diskusjon nettopp har vært tema at det
skal være i henhold til standarden.

Hadde standarden vært fulgt fullt ut ved forrige testrunde, hadde nok
resultatene på de program som er testet vist et annet resultat enn hva
som er presenter på akkurat dette område med GEDCOM import og eksport.

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Leif B. Kristensen]

Otto Jørgensen wrote:

Jeg må allikevel undre meg litt over endring i en del holdninger når
en plutselig fremkommer at det plutselig ikke er så farlig med mindre
avvik, mens det i tidligere diskusjon nettopp har vært tema at det
skal være i henhold til standarden.

Det er nok ikke avviket i seg selv som betyr noe for vår TMG-selger, men
hvilket program som produserer avviket.

Ellers noterer jeg meg at her er alt ved det gamle, en gråkald og
kjedelig lørdag formiddag da jeg kikker innom på gamle tomter. Og jeg
tenker for meg selv at denne diskusjonen kommer sikkert til å fortsette
her i tjue år til, om Torleif og Otto fortsatt lever. Hakk i plata,
hakk i plata, hakk i plata, hakk i plata ...
--
Leif Biberg Kristensen
http://solumslekt.org/

[Otto Jørgensen]

On Sat, 29 Jan 2005 11:00:19 +0100, in no.fritid.slektsforsking.it
"Leif B. Kristensen" <[email protected]> wrote:

Otto Jørgensen wrote:

Jeg må allikevel undre meg litt over endring i en del holdninger når
en plutselig fremkommer at det plutselig ikke er så farlig med mindre
avvik, mens det i tidligere diskusjon nettopp har vært tema at det
skal være i henhold til standarden.

Det er nok ikke avviket i seg selv som betyr noe for vår TMG-selger, men
hvilket program som produserer avviket.

Ellers noterer jeg meg at her er alt ved det gamle, en gråkald og
kjedelig lørdag formiddag da jeg kikker innom på gamle tomter. Og jeg
tenker for meg selv at denne diskusjonen kommer sikkert til å fortsette
her i tjue år til, om Torleif og Otto fortsatt lever. Hakk i plata,
hakk i plata, hakk i plata, hakk i plata ...

Om jeg må få lov å si så er det vel ikke Thorleif og undertegnede som
har de fleste hakkene i platen denne gangen.
I denne lille sidetråden til hovedveien, er det mest et spørsmål om
DIS skal teste datoformatene helt ut eller om man skal kun behandle
deler slik som tidligere.
Jeg står for at man nå gjør dette skikkelig både med import og eksport
på en seriør måte og så få vi Programfans, heller arbeide mot
respektive produsenter for å endre det som fortsatt ikke er i henhold
til standard.
Og ellers får man glemme historier om programmer og snakke om dagens
program.

Ellers få du jo ha en riktig god helg

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Anne Lise Hovdal]

"torleif haugødegård" <[email protected]> skrev i melding news:

denne parentesen er bare en parentes
i denne sammenheng, den er ytterst lite interessant og helt uten
betydning for slektsforskere. Og det er jo ingen som vil ha en
parentes rundt datoer i sine utskrifter.

Jeg vil gjerne ha parantes i utskrift hvis det f.eks. kan stå
7.p.trinit.(27.07) 1758. Slik skriver jeg det i "Mine Dokumenter"
når driver slektsforskning for andre som ikke vet hva p.trinit.
er. Samtidig ønsker jeg at det skal være med siden det faktisk
er det som står i kirkeboka. Jeg syns også det hadde vært
en fordel om dette kunne kommet med i utskrift fra slekts-
programmet. Ellers har jeg ingen forutsetning for å blande
meg inn i diskusjonen her.

Anne Lise Hovdal

[Otto Jørgensen]

On Sat, 29 Jan 2005 17:20:18 +0100, in no.fritid.slektsforsking.it
"Anne Lise Hovdal" <[email protected]> wrote:

"torleif haugødegård" <[email protected]> skrev i melding news:

denne parentesen er bare en parentes
i denne sammenheng, den er ytterst lite interessant og helt uten
betydning for slektsforskere. Og det er jo ingen som vil ha en
parentes rundt datoer i sine utskrifter.

Jeg vil gjerne ha parantes i utskrift hvis det f.eks. kan stå
7.p.trinit.(27.07) 1758. Slik skriver jeg det i "Mine Dokumenter"
når driver slektsforskning for andre som ikke vet hva p.trinit.
er. Samtidig ønsker jeg at det skal være med siden det faktisk
er det som står i kirkeboka. Jeg syns også det hadde vært
en fordel om dette kunne kommet med i utskrift fra slekts-
programmet. Ellers har jeg ingen forutsetning for å blande
meg inn i diskusjonen her.

Akkurat her ville jeg personlig lagt inn

27.07.1758 i datofeltet og lagt 7.p.trinit. 1758 i merknadsfeltet til
hendelsen

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[dn10375]

On Sat, 29 Jan 2005 17:31:22 +0100, Otto Jørgensen

On Sat, 29 Jan 2005 17:20:18 +0100, in no.fritid.slektsforsking.it
"Anne Lise Hovdal" <[email protected]> wrote:


"torleif haugødegård" <[email protected]> skrev i melding news:

denne parentesen er bare en parentes
i denne sammenheng, den er ytterst lite interessant og helt uten
betydning for slektsforskere. Og det er jo ingen som vil ha en
parentes rundt datoer i sine utskrifter.

Jeg vil gjerne ha parantes i utskrift hvis det f.eks. kan stå
7.p.trinit.(27.07) 1758. Slik skriver jeg det i "Mine Dokumenter"
når driver slektsforskning for andre som ikke vet hva p.trinit.
er. Samtidig ønsker jeg at det skal være med siden det faktisk
er det som står i kirkeboka. Jeg syns også det hadde vært
en fordel om dette kunne kommet med i utskrift fra slekts-
programmet. Ellers har jeg ingen forutsetning for å blande
meg inn i diskusjonen her.

Akkurat her ville jeg personlig lagt inn
27.07.1758 i datofeltet og lagt 7.p.trinit. 1758 i merknadsfeltet til
hendelsen

Nettopp, helt enig med Otto. Heller ikke her har vi bruk for dissa
parentesene som DIS-Norge syns er så viktige.

Jeg repeterer i all beskjedenhet mitt svar i en annen tråd:
............
Datoer bør legges inn på en slik måte at programmet kan tolke den som
en gyldig dato, fordi programmet har (bør ha) beregnings- og
sorteringsfunksjoner som avhenger av dette.
Eksempelvis om du sorterer søkelista etter fødselsdato, eller vil
skrive ut ei liste over personer født før 1814, eller vil finne alle
som døde før de var 10 år gamle.
Datoer som du er usikker på kan legges inn med modifikatorer som "ca",
"før", "etter" o.a.

Den latinske skrivemåten bør også tas med, hvis den finnes i kilden,
men da i et fritekstlig notat til hendelsen eller til kildereferansen.
Du kan også angi en kildekvalitet for datoen som sådan, feks på
skalaen 0-3 der 3 er brennsikker.
..................

---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
[email protected]
http://www.tha.no

[Alf Christophersen]

On Fri, 28 Jan 2005 23:48:50 +0100, Otto Jørgensen
<otjoerge%øføø%@online.norway> wrote:

Beklager ALf, Jeg snakker ikke om historie.
Når det kommer merknader så snakker jeg ikke om snøen som falt i
fjor, men dagens situasjon og som jeg har nevnt utallige ganger,

Jeg nevnte vedkommende episode fordi Steed mente det var korrekt å
kalle ANSI-tegnsettet for IBMPC. Det måtte argumenteres ganske lenge
den gangen før han gikk med på at den delen av tegnsettene som ikke er
US ASCII er meget forskjellige mellom IBMPC (ved forskjellige
codepage) og ANSI.

[Otto Jørgensen]

On Sat, 29 Jan 2005 18:54:59 +0100, in no.fritid.slektsforsking.it Alf
Christophersen <[email protected]> wrote:

On Fri, 28 Jan 2005 23:48:50 +0100, Otto Jørgensen
otjoerge%øføø%@online.norway> wrote:

Beklager ALf, Jeg snakker ikke om historie.
Når det kommer merknader så snakker jeg ikke om snøen som falt i
fjor, men dagens situasjon og som jeg har nevnt utallige ganger,

Jeg nevnte vedkommende episode fordi Steed mente det var korrekt å
kalle ANSI-tegnsettet for IBMPC. Det måtte argumenteres ganske lenge
den gangen før han gikk med på at den delen av tegnsettene som ikke er
US ASCII er meget forskjellige mellom IBMPC (ved forskjellige
codepage) og ANSI.

for å gjøre det enklere for alle, kan du tidfeste dette, slik at alle
vet hvilken periode du snakker om

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Anne Lise Hovdal]

"Otto Jørgensen" <otjoerge%øføø%@online.norway> skrev i melding > Akkurat
her ville jeg personlig lagt inn

27.07.1758 i datofeltet og lagt 7.p.trinit. 1758 i merknadsfeltet til
hendelsen

Hvorfor kan det ikke gjøres motsatt? Det er jo heller ikke
alle jeg har eksakt dato på, og da blir jo datofeltet tomt.
Overføringer via Gedcomfiler kommer ikke jeg til å bruke
likevel slik som det ser ut nå.

De fleste av dem jeg har funnet har jeg jo fra kirkebøkene,
og det er ikke alt en finner i kalendere som Dage og Bauers
kalender. Så da skulle det jo vært ganske mange hos meg
hvor tidsbetegnelse står som merknad til hendelsen, men
jeg mangler dato. Det blir også veldig mye å rette opp for
meg hvis jeg skal begynne med dette nå.

Anne Lise Hovdal

[Otto Jørgensen]

On Sat, 29 Jan 2005 22:13:28 +0100, in no.fritid.slektsforsking.it
"Anne Lise Hovdal" <[email protected]> wrote:

"Otto Jørgensen" <otjoerge%øføø%@online.norway> skrev i melding > Akkurat
her ville jeg personlig lagt inn
27.07.1758 i datofeltet og lagt 7.p.trinit. 1758 i merknadsfeltet til
hendelsen

Hvorfor kan det ikke gjøres motsatt? Det er jo heller ikke
alle jeg har eksakt dato på, og da blir jo datofeltet tomt.
Overføringer via Gedcomfiler kommer ikke jeg til å bruke
likevel slik som det ser ut nå.

De fleste av dem jeg har funnet har jeg jo fra kirkebøkene,
og det er ikke alt en finner i kalendere som Dage og Bauers
kalender. Så da skulle det jo vært ganske mange hos meg
hvor tidsbetegnelse står som merknad til hendelsen, men
jeg mangler dato. Det blir også veldig mye å rette opp for
meg hvis jeg skal begynne med dette nå.

ved ikke sikre datoer, kan en fint skrive inn ca 1758 eller bare 1758

inntil du har fått den eksakte datoen verifisert. Og jeg vill tro at
en dato som 1758 sier en mottaker av ditt arbeid mer enn det
7.p.trinit. 1758

Men det er jo selvfølgelig du selv som bestemmer hva og hvordan du vil
ha dataene. Forslaget var mer ment slik at du ikke kommer i konflikt
med regelverket for GEDCOM. I en vanlig utskrift vil jo dette normal
ikke noen betydning

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Alf Christophersen]

On Sat, 29 Jan 2005 17:50:44 +0100, torleif haugødegård <[email protected]>
wrote:

Nettopp, helt enig med Otto. Heller ikke her har vi bruk for dissa
parentesene som DIS-Norge syns er så viktige.

Det er standarden som sier at fritekst skal i gedcom-fila pakkes inn i
parenteser. Det er pakkende program som skal gjøre det, ikke brukeren,
og det er importerende program sitt ansvar for å pakke det ut igjen og
fjerne parentesene.

Med parenteser forenkles tolkingen av innholdet. Det markerer at man
ikke skal lete etter dato,måned og år når parenteser finnes, og
programmer unngår dermed å generere feil fordi det ikke er forventet
innhold der.

[dn10375]

On Sat, 29 Jan 2005 23:50:43 +0100, Alf Christophersen

On Sat, 29 Jan 2005 17:50:44 +0100, torleif haugødegård <[email protected]

Nettopp, helt enig med Otto. Heller ikke her har vi bruk for dissa
parentesene som DIS-Norge syns er så viktige.

Det er standarden som sier at fritekst skal i gedcom-fila pakkes inn i
parenteser. Det er pakkende program som skal gjøre det, ikke brukeren,
og det er importerende program sitt ansvar for å pakke det ut igjen og
fjerne parentesene.

Med parenteser forenkles tolkingen av innholdet. Det markerer at man
ikke skal lete etter dato,måned og år når parenteser finnes, og
programmer unngår dermed å generere feil fordi det ikke er forventet
innhold der.

Jeg kjenner ingen program som bryr seg med denne unødvendige
parentesen. Skal DIStesten trekke poeng manglende parentes rundt
datoer;-)

Etter det jeg leser i standarden er det ifbm modifikatoren INT at
denne unødvendige parentesmetoden beskrives:
...............
The date modifier (int) was added to the date format to indicate that
the associated date phrase has been interpreted and the interpretation
follows the int prefix in the date field. The date phrase is also
included in the date value enclosed in parentheses. (See
<DATE_APPROXIMATED>, page 43.)
............

Det er også vist til denne, som sier at den unødvendige parentesen
skal brukes _når årstallet ikke er gjenkjennbart_:
..............
DATE_PHRASE:= {Size=1:35} (<TEXT>) Any statement offered as a date
when the year is not recognizable to a date parser, but which gives
information about when an event occurred. The date phrase is enclosed
in matching parentheses.
..............
Så da må det bety at "julaften 1999" ikke skal ha parentes, mens
"julaften ifjor" skal ha parentes, altså nok et eksempel på hvor
tullete denne parentesmetoden er.

Bruk heller tid og krefter på viktige egenskaper som at eksporterte
datoer som programmet har godkjent skal ha et bestemt. format
DD MMM ÅÅÅÅ der MMM er engelsk.


---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
[email protected]
http://www.tha.no

[Anne Lise Hovdal]

"Otto Jørgensen" <otjoerge%øføø%@online.norway> skrev i melding > >

Men det er jo selvfølgelig du selv som bestemmer hva og hvordan du vil
ha dataene. Forslaget var mer ment slik at du ikke kommer i konflikt
med regelverket for GEDCOM. I en vanlig utskrift vil jo dette normal
ikke noen betydning

Jeg har bestemt meg for å lytte til erfarne folk her, og det kan jo
hende at noen en gang skal overta mitt program(håper det blir
lenge til siden jeg kun er 46 år). Så jeg skal nå etterhvert skrive
inn datoer i datofeltet og andre tidsangivelser i merknader. Så
jeg får nok koble meg på Bauers kalender som jeg har lastet ned
og ta fatt på dette snart. Vet av Dage, men det fungerer jo ikke
hos meg etter uttallige nedlastingsforsøk.

Anne Lise Hovdal

[Otto Jørgensen]

On Sun, 30 Jan 2005 16:30:53 +0100, in no.fritid.slektsforsking.it
"Anne Lise Hovdal" <[email protected]> wrote:

"Otto Jørgensen" <otjoerge%øføø%@online.norway> skrev i melding

Men det er jo selvfølgelig du selv som bestemmer hva og hvordan du vil
ha dataene. Forslaget var mer ment slik at du ikke kommer i konflikt
med regelverket for GEDCOM. I en vanlig utskrift vil jo dette normal
ikke noen betydning

Jeg har bestemt meg for å lytte til erfarne folk her, og det kan jo
hende at noen en gang skal overta mitt program(håper det blir
lenge til siden jeg kun er 46 år). Så jeg skal nå etterhvert skrive
inn datoer i datofeltet og andre tidsangivelser i merknader. Så
jeg får nok koble meg på Bauers kalender som jeg har lastet ned
og ta fatt på dette snart. Vet av Dage, men det fungerer jo ikke
hos meg etter uttallige nedlastingsforsøk.

Kan jo trøste med at (om det nå er trøst) at jeg også har noen slike

dagsangivelser i mitt datofelt noen steder, men jeg også¨er klar over
hvor disse er og det er kun tidspørsmål før jeg oppdaterer disse. Men
nå har jeg heller ikke i nærmeste fremtid behov for å sende akkurat
den delen til andre, om det så skulle være som vanlig tekst-rapport
eller GEDCOM. :=
:=)


--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Alf Christophersen]

On Sat, 29 Jan 2005 22:13:28 +0100, "Anne Lise Hovdal"
<[email protected]> wrote:

"Otto Jørgensen" <otjoerge%øføø%@online.norway> skrev i melding > Akkurat
her ville jeg personlig lagt inn
27.07.1758 i datofeltet og lagt 7.p.trinit. 1758 i merknadsfeltet til
hendelsen

Hvorfor kan det ikke gjøres motsatt? Det er jo heller ikke
alle jeg har eksakt dato på, og da blir jo datofeltet tomt.
Overføringer via Gedcomfiler kommer ikke jeg til å bruke
likevel slik som det ser ut nå.

Skrives f.eks. 1758-07-09 (7. p.trin. 1758)
Eksporteres som

1 BIRT
2 DATE INT 9 JUL 1758 (7. p.trin. 1758)

Som trøst ang. andre datoer, hvis det var DIStreff du hadde i tankene,
så kan du gjerne skrive 'blablabla 1758' i datofeltet for født etc.
Det blir trukket ut som 1758 okke som.

Men det kommer en notis om det i filen med advarsler. Så kan du jo gå
inn på vedkommende person og notis og rette det opp.

Så sant det finnes fire sammenhengende sifre i størrelsesorden
1000-1925, så blir notisen godkjent for å bli tatt med, omtrent
uansett hvordan du skriver ting i datofeltet.

Jeg tar dog ting opp her fordi enkelte programmer gir mer
feilmeldinger enn andre.

[Alf Christophersen]

On Sun, 30 Jan 2005 10:16:01 +0100, torleif haugødegård <[email protected]>
wrote:

Jeg kjenner ingen program som bryr seg med denne unødvendige
parentesen. Skal DIStesten trekke poeng manglende parentes rundt
datoer;-)

Hvem har snakket om at det gjelder datoer Thorleif.

Det er når folk skriver f.eks. "Beitstad kirke" i datofeltet vi
snakker om.

Etter det jeg leser i standarden er det ifbm modifikatoren INT at
denne unødvendige parentesmetoden beskrives:

Har du sett på Date PHRASE ?

Det er dette tilfellet jeg snakker om

Ikke bland inn hummer og kanari her.

[Alf Christophersen]

On Sun, 30 Jan 2005 16:44:30 +0100, Otto Jørgensen
<otjoerge%øføø%@online.norway> wrote:

Kan jo trøste med at (om det nå er trøst) at jeg også har noen slike
dagsangivelser i mitt datofelt noen steder, men jeg også¨er klar over
hvor disse er og det er kun tidspørsmål før jeg oppdaterer disse. Men
nå har jeg heller ikke i nærmeste fremtid behov for å sende akkurat
den delen til andre, om det så skulle være som vanlig tekst-rapport
eller GEDCOM. :=
:=)

Har du angitt dem korrekt, så skal det ikke være noe problem Otto. Se
min andre kommentar.

[Anne Lise Hovdal]

"Otto Jørgensen" <otjoerge%øføø%@online.norway> skrev i melding
news:[email protected]...

On Sun, 30 Jan 2005 16:30:53 +0100, in no.fritid.slektsforsking.it
"Anne Lise Hovdal" <[email protected]> wrote:


"Otto Jørgensen" <otjoerge%øføø%@online.norway> skrev i melding

Men det er jo selvfølgelig du selv som bestemmer hva og hvordan du vil
ha dataene. Forslaget var mer ment slik at du ikke kommer i konflikt
med regelverket for GEDCOM. I en vanlig utskrift vil jo dette normal
ikke noen betydning

Jeg har bestemt meg for å lytte til erfarne folk her, og det kan jo
hende at noen en gang skal overta mitt program(håper det blir
lenge til siden jeg kun er 46 år). Så jeg skal nå etterhvert skrive
inn datoer i datofeltet og andre tidsangivelser i merknader. Så
jeg får nok koble meg på Bauers kalender som jeg har lastet ned
og ta fatt på dette snart. Vet av Dage, men det fungerer jo ikke
hos meg etter uttallige nedlastingsforsøk.

Kan jo trøste med at (om det nå er trøst) at jeg også har noen slike
dagsangivelser i mitt datofelt noen steder, men jeg også¨er klar over
hvor disse er og det er kun tidspørsmål før jeg oppdaterer disse.

Jeg ser nå med skrekk at jeg har skrevet noen tidsangivelser
i feltet for Sted/beskrivelse, og det gjelder i de tilfeller jeg har
fått lite plass i datofeltet. For eksempel tok det for stor plass
i datofeltet å skrive inn Dorothea Jensdatter Hønnichen som
døpt 3.søndag etter trinitatis 1725, og det havnet da i feltet for
sted og beskrivelse. Så jeg får nok noe å rette opp etterhvert ja.
Nå har 3.søndag etter trinitatis 1725 blitt skrevet inn der det
skal være under M.

Men

nå har jeg heller ikke i nærmeste fremtid behov for å sende akkurat
den delen til andre, om det så skulle være som vanlig tekst-rapport
eller GEDCOM. :=
:=)

Nei vel. Jeg har iallefall begynt å tenke at om ikke jeg skal
bruke gedcom så kan jeg jo legge til rette for at andre kan
bruke mitt program til det senere, og det kan jo også hende
at jeg en gang langt inn i fremtiden kommer så langt. Akkurat
nå er det å lese kirkebøker på mikrofilm mer interessant, og
jeg er nok noe forskjellig slik fra dagens moderne slektsforskere
som liker å klatre i andres slektstrær osv

Skulle ellers ønske at skiftene hadde vært enklere å lese, slik
at jeg oftere kunne brukt disse som kilde. Det er vel jeg som
mangler litt trening, og jeg har kun prøvd meg på å lese 4
skifter(3 av dem på mikrofilm)+noen jeg så litt på ellers på
de samme mikrofilmene. Skiftene for Helgeland er jo ikke noe
problem siden vi har en Svein Edvardsen, men det kunne jo
vært interessant å lese noen originale skifter her også. Nå er jeg
igjen kommet helt utenom emnet her.

Anne Lise Hovdal

[Otto Jørgensen]

On Sun, 30 Jan 2005 18:27:37 +0100, in no.fritid.slektsforsking.it Alf
Christophersen <[email protected]> wrote:

On Sun, 30 Jan 2005 16:44:30 +0100, Otto Jørgensen
otjoerge%øføø%@online.norway> wrote:

Kan jo trøste med at (om det nå er trøst) at jeg også har noen slike
dagsangivelser i mitt datofelt noen steder, men jeg også¨er klar over
hvor disse er og det er kun tidspørsmål før jeg oppdaterer disse. Men
nå har jeg heller ikke i nærmeste fremtid behov for å sende akkurat
den delen til andre, om det så skulle være som vanlig tekst-rapport
eller GEDCOM. :=
:=)

Har du angitt dem korrekt, så skal det ikke være noe problem Otto. Se
min andre kommentar.

jeg vet meget godt om de stedene jeg har lagt inn ting som ikke er
riktig i henhold til standard.

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Otto Jørgensen]

On Sun, 30 Jan 2005 18:05:06 +0100, in no.fritid.slektsforsking.it Alf
Christophersen <[email protected]> wrote:

On Sat, 29 Jan 2005 22:13:28 +0100, "Anne Lise Hovdal"
[email protected]> wrote:


"Otto Jørgensen" <otjoerge%øføø%@online.norway> skrev i melding > Akkurat
her ville jeg personlig lagt inn
27.07.1758 i datofeltet og lagt 7.p.trinit. 1758 i merknadsfeltet til
hendelsen

Hvorfor kan det ikke gjøres motsatt? Det er jo heller ikke
alle jeg har eksakt dato på, og da blir jo datofeltet tomt.
Overføringer via Gedcomfiler kommer ikke jeg til å bruke
likevel slik som det ser ut nå.

Skrives f.eks. 1758-07-09 (7. p.trin. 1758)
Eksporteres som

1 BIRT
2 DATE INT 9 JUL 1758 (7. p.trin. 1758)

Som trøst ang. andre datoer, hvis det var DIStreff du hadde i tankene,
så kan du gjerne skrive 'blablabla 1758' i datofeltet for født etc.
Det blir trukket ut som 1758 okke som.

Men det kommer en notis om det i filen med advarsler. Så kan du jo gå
inn på vedkommende person og notis og rette det opp.

Så sant det finnes fire sammenhengende sifre i størrelsesorden
1000-1925, så blir notisen godkjent for å bli tatt med, omtrent
uansett hvordan du skriver ting i datofeltet.

Jeg tar dog ting opp her fordi enkelte programmer gir mer
feilmeldinger enn andre.

hvis den normaliserte dato du oppgave, så vil AL være glad for
korreksjonen


--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[dn10375]

On Sun, 30 Jan 2005 18:26:13 +0100, Alf Christophersen
<[email protected]> wrote:

On Sun, 30 Jan 2005 10:16:01 +0100, torleif haugødegård <[email protected]

Jeg kjenner ingen program som bryr seg med denne unødvendige
parentesen. Skal DIStesten trekke poeng manglende parentes rundt
datoer;-)

Hvem har snakket om at det gjelder datoer Thorleif.

Se tittelen på tråden.

Det er når folk skriver f.eks. "Beitstad kirke" i datofeltet vi
snakker om.
Det er fortsatt ingen behov for å endre brukerens inntasting med en

parentes foran og bak. Brukerdata skal ikke røres, men overføres som
de er.

Etter det jeg leser i standarden er det ifbm modifikatoren INT at
denne unødvendige parentesmetoden beskrives:

Har du sett på Date PHRASE ?

Det er dette tilfellet jeg snakker om

Ikke bland inn hummer og kanari her.

Det gjelder tidsangivelser i datofeltet som ikke programmet tolker som
en gyldig dato, feks julaften 2000.

Det har med GEDCOMmodifikatoren INT å gjøre, og denne er feks ikke i
bruk i TMG. Brukeren kan her enkelt angi hvordan hun har kommet fram
til den angitte datoen ved et kort notat til kildereferansen.

---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
[email protected]
http://www.tha.no

[John Morten Malerbakken]

"Alf Christophersen" <[email protected]> wrote in message
news:[email protected]...

On Tue, 25 Jan 2005 14:24:31 GMT, "John Morten Malerbakken"
John.Morten.removethisparttoreply@maler ... ovethiscom> wrote:

Helt klart. Bør komme snart også. Vet ikke hvor gammel den spesifikasjonen
er, men dette ser ut som noe som kan ha vært en svakhet lenge.

Tviler jeg sterkt på i og med feilen har vært påpekt omtrent like
lenge som GEDtreff-prosjektet har pågått.
Det er faktisk siden 2002 (Dvs. da slapp første versjon ut til
bruk av faddere)

Ehhh, tror vi egentlig sier det samme over her Alf. Jeg forstod det sånn at
denne svakheten i BK hadde vært der lenge og forsøkte å påpeke at det
kanskje ikke hadde vært så dumt å få det retta opp snart. Med
tilleggsopplysningene om at det har vært et tema siden 2002 så bekrefter du
det jeg antydet.

John Morten

[Otto Jørgensen]

On Mon, 31 Jan 2005 00:01:14 GMT, in no.fritid.slektsforsking.it "John
Morten Malerbakken"
<[email protected]> wrote:

"Alf Christophersen" <[email protected]> wrote in message
news:[email protected]...
On Tue, 25 Jan 2005 14:24:31 GMT, "John Morten Malerbakken"
John.Morten.removethisparttoreply@maler ... ovethiscom> wrote:

Helt klart. Bør komme snart også. Vet ikke hvor gammel den spesifikasjonen
er, men dette ser ut som noe som kan ha vært en svakhet lenge.

Tviler jeg sterkt på i og med feilen har vært påpekt omtrent like
lenge som GEDtreff-prosjektet har pågått.
Det er faktisk siden 2002 (Dvs. da slapp første versjon ut til
bruk av faddere)


Ehhh, tror vi egentlig sier det samme over her Alf. Jeg forstod det sånn at
denne svakheten i BK hadde vært der lenge og forsøkte å påpeke at det
kanskje ikke hadde vært så dumt å få det retta opp snart. Med
tilleggsopplysningene om at det har vært et tema siden 2002 så bekrefter du
det jeg antydet.

Nå har Alf i dette tema slenkt rundt seg mange forhold. Noen av disse

tingen er ikke problem og noen er problem. Noen er et større problem
for Alf enn for andre.
Noen av problemene vet vi om, da disse er nevnt under testen til DIS,
bl.a. dette med parentesen som også er et problem for andre program

Elllers synes jeg vel at man skal forholde seg til dagens situasjon og
ikke dra inn historiske forhold som ikke lenger eksisterer.

For å avklare det som er mangel i BK kontra andre program, så er også
en del av de andre programs mangler kommet frem, men av en eller annen
spesiell grunner samme mangel et mye større problem i BK enn det er i
andre program, uten at jeg kan se at det skal være noen grunn til å
trekke slike konklusjoner.
Dette er det vel Alf som Distreff-sjef, kan avklare grunnen til

--
Otto Jørgensen
http://home.online.no/~otjoerge/bk/
All email is checked by NORTON

[Heidelberg]

On Sun, 30 Jan 2005 18:26:13 +0100, Alf Christophersen wrote:

On Sun, 30 Jan 2005 10:16:01 +0100, torleif haugødegård <[email protected]
wrote:

Jeg kjenner ingen program som bryr seg med denne unødvendige
parentesen. Skal DIStesten trekke poeng manglende parentes rundt
datoer;-)

Hvem har snakket om at det gjelder datoer Thorleif.

Det er når folk skriver f.eks. "Beitstad kirke" i datofeltet vi
snakker om.

Har ikke det bøss med det, men når du av alle landets kirker nevner
Beitstad blir jeg nysgjerrig. Har jobbet i den kirken, det er nok derfor
jeg ble nysgjerrig

mvh Knut

--
Knut Klaveness Heidelberg
http://knut.heidelberg.no

[Alf Christophersen]

On Sun, 30 Jan 2005 21:52:16 +0100, torleif haugødegård <[email protected]>
wrote:

Se tittelen på tråden.

Javel, hvorfor trakk du da inn

2 DATE Hemsedal ??

Den hører jo ikke til tittelen din.

Det var denne type dato jeg kommenterte.

den er legal eksportert som

2 DATE (Hemsedal)

hemsedal kan anses som en "Phrase", og skal derfor skrives innenfor
parenteser.

Hadde du glemt hva du skrev i startinnlegget?? Isåfall skulle KMF
hatt sitt årsmøte i går, men ingen husket det

[Alf Christophersen]

On Mon, 31 Jan 2005 10:37:49 +0100, Heidelberg
<[email protected]> wrote:

Har ikke det bøss med det, men når du av alle landets kirker nevner
Beitstad blir jeg nysgjerrig. Har jobbet i den kirken, det er nok derfor
jeg ble nysgjerrig

Tidligere kalt Solberg kirke, og når folk som arbeider med gården
Solberg, f.eks. Solberg i Drangedal, kun skriver Solberg, så havner
slekta deres i Beitstad kommune.

Standardeksemplet mitt på viktigheten av å registrere sokn/kommune for
gårdsnavn og ikke kun gårdsnavn-
Andre eksempler er f.eks. Bolstad som havner i Bolstad församling i
Sverige, registrere varianter over friteksten "Han vokste opp" som
stedsnavn i hendelse (som blir Opp county i USA) etc. Rekorden har en
stakkar med 17500 fritekster registrert som sted for diverse
hendelser, hvorav 8900 varianter på temaet "Han/hun/Ola/Per/Aud vokste
opp" som konfirmasjonssted.
Jaja.

Tror de aller fleste vil ha glede av å prøve Gedtreff om ikke annet
for å få en rapport over glemte rariteter fra "von anno dazumal" da
slektsprogrammet ikke kunne registrere fritekst og man måtte være
oppfinnsom med å benytte sjeldent brukte hendelser, som f.eks.
konfirmert, til å registrere fritekst.

Disgen er dessverre ikke unntatt, om det er til trøst for Otto. Ser i
bladet vårt tips om å bruke utflyttet-notisen (som er strengt tatt
foreldet) til å registrere navneskifte.
Tror neppe vedkommende forslagsstiller har tenkt lenger enn til
nesetippen sin ang. konsekvenser av slikt forslag, den dagen en
stakkar som har fulgt rådet og skal eksportere data til noen
slektninger og vedkommende får som Utflyttet navneskifte til NN
(:-( ) Jeg vet ikke helt om jeg skal le eller gråte.