---

på er tidspunkt mener jeg at have læst her i gruppen om et program til
indlæsning af gedcomp filer fra Lars Lundin, er det rigtigt og hvor kan jeg
finde det ?

Steen

---

Wed, 04 Dec 2002 19:36:41 +0100 skrev Steen Mogensen:

> på er tidspunkt mener jeg at have læst her i gruppen om et program til
> indlæsning af gedcomp filer fra Lars Lundin, er det rigtigt og hvor kan
> jeg finde det ?

Måske tænker du på et program til indlæsning af GEDCOM-filer?

Sådan et har jeg oversat fra engelsk til dansk, det hedder
GRAMPS og kan anvendes under styresystemet Linux.
Se f.eks.
http://www.dis-danmark.dk/i_progra.htm#gramps

Eller måske tænker du på min slægtsforsker-service, GEDCOMP,
som finder overlap mellem GEDCOM-filer? Se i så fald nedenfor

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

---

der er en meddelelse fra Bo Ekelund den 30/11 2002 om hans progammer, se
http://www.boekelund.dk/

her kan du finde det program, du efterlyser (tror jeg nok)

Kjeld jakobsen


"Steen Mogensen" <dsl52801@vip.cybercity.dk> skrev i en meddelelse
news:asli02$2ri7$1@news.cybercity.dk...
> på er tidspunkt mener jeg at have læst her i gruppen om et program til
> indlæsning af gedcomp filer fra Lars Lundin, er det rigtigt og hvor kan
jeg
> finde det ?
>
> Steen
>
>

---

On Wed, Dec 04, 2002 at 11:14:31PM +0100, Steen Mogensen wrote:
> Hej Lars
> Det er muligt at jeg ikke udtrykker mig helt korrekt, men det drejer sig om
> følgende, du har sendt mig en mail:
> -----
>> Til Steen Mogensen.
>>
>> Din indsendte GEDCOM-fil dk30615a.ged er blevet sammenlignet med GEDCOM-
>> filen dk51109a.ged og der er blevet fundet 98 mulige personsammenfald.
>>
>> dk51109a.ged er indsendt af ...
> -----
> er der et program hvor man kan lægge disse personsammenfald ind, som derved
> letter sorteringen, i stedet for at gøre det manuelt ?
> Jeg håber du forstår hvad jeg mener

Nu gør jeg.

Du ønsker et program til læsning af person-oplysningerne i en
såkaldt bingo-email, som GEDCOMP udsender titusindvis af.

En GEDCOMP-bruger har for flere år siden skrevet sådan et program.

Jeg har aldrig prøvet programmet og har længe glemt
hvem der skrev det. Men måske nogen her kan hjælpe?

Selv synes jeg bedst om manuelt at gennemgå de nye oplysninger
- og at det er den bedste måde til at opdage fejl og
uoverensstemmelser.

Så jeg nøjes med et program til at finde de personer, der er
interessante, fordi kun den ene part har oplysninger om personens
familieforbindelser: http://www.lklundin.dk/lkl/perl/hfamfind.pl

Efter installation af perl kan programmet anvendes sådan her:
perl hfamfind.pl out.dk51109a.dk30615a

Og man vil få uddata som:
dk51109a.ged <=> dk30615a.ged
Margrethe /Nielsdatter/ <=> Margrethe/Nielsdatter/
FAMC: 1:@F50@ <=> 0

Kirsten /Ibsen/ <=> Kirsten/Ibsdatter/
FAMC: 0 <=> 1:@F71@

Anders /Larsen/ <=> Anders/Larsen/
FAMS: 1:@F221@ <=> 0

Heraf ses, at du kan få hjælp med oplysninger om
Margrethe Nielsdatters forældre/søskende og Anders Larsens
ægtefælle/børn, mens du til gengæld kan hjælpe indsenderen af
dk51109a.ged med oplysninger om Kirsten Ibsdatters forældre/søskende.

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

---

In article <pan.2002.12.04.23.56.09.259674.11714@lklundin.dk>, news-gi-
20@lklundin.dk says...
> Så jeg nøjes med et program til at finde de personer, der er
> interessante, fordi kun den ene part har oplysninger om personens
> familieforbindelser: http://www.lklundin.dk/lkl/perl/hfamfind.pl

Smart, en slags "diff" til Gedcom filer :)

Lars, jeg har længe grublet over hvilket program du bruger til at checke
gedcom filerne for det vi i dine mails ser som advarsler og fejl. Mange
slægtsforskningsprogrammer har jo idag den mulighed, men de "ignorerer"
jo ofte deres egne fejl, hvilket er lidt irriterende når man skal
indsende en fil til Gedcomp. Kunne man nu selv checke for de fleste
advarsler og fejl inden man sendte den ind, ville det spare for en del
"støj" i de mails man får fra dig.
Hvilket helt naturligt leder mig over til det egentlige spørgsmål:
Hvilket program bruger du til valideringen? Er det egetudviklet eller
noget man kan finde på nettet?

Med venlig hilsen
Brian Jensen

---

Thu, 05 Dec 2002 08:41:01 +0100 skrev Brian Jensen:

> Lars, jeg har længe grublet over hvilket program du bruger til at checke
> gedcom filerne for det vi i dine mails ser som advarsler og fejl. Mange
> slægtsforskningsprogrammer har jo idag den mulighed, men de "ignorerer"
> jo ofte deres egne fejl, hvilket er lidt irriterende når man skal
> indsende en fil til Gedcomp.

Programmet til behandling af GEDCOM-syntaksfejl har jeg selv skrevet.

Jeg er enig i, at vi burde være foruden alle de syntaksfejl
som stadig er almindeligt forekommende i GEDCOM-filer.

Bemærk: Uanset hvad en slægtsforsker indtaster i sit
slægtsprogram, så er det en fejl ved programmet hvis det
kan bringes til at generere en GEDCOM-fil med syntaks-fejl.

Så frem for at lade slægtsprogrammernes brugere bakse med et
program til fejlretning, har jeg et forslag jeg synes er bedre:

Når man f.eks. via GEDCOMP bliver opmærksom på at der et problem
med GEDCOM-genereringen i det slægtsprogram man bruger, så send
en fejl-rapport om det til producenten.

Eksempel: Mange slægtsforskere skriver til mig:
Jeg har nu brugt XYZ timer på at (forsøge at) rette de
forkert formatterede datoer i min GEDCOM-fil.

Den slags er irrelevant arbejde for en slægtsforsker og
nærmest spild af tid.

Istedet bør man (meget gerne sammen med andre brugere) henvende
sig til producenten af slægtsprogrammet og sige noget i stil med:
Vi er rimeligt tilfredse med dit program. Men vi er blevet opmærksomme
på at programmets GEDCOM-generering er fejlbehæftet, se nedenfor.
Vi vil sætte stor pris på at denne fejl bliver rettet i næste
version af programmet.

Og har man fået en fejl-rapport fra GEDCOMP, så kan man vedlægge
de relevante dele af den som dokumentation.

Hvis ikke producenten er interesseret i at rette fejl i
produktet, er det en god grund til at skifte til et andet.

Bemærk at ikke alle fejl i kontrol-rapporten fra GEDCOMP
er syntaks-fejl. Eksempel:
> INDI I33 har modstridende dato-oplysninger om sin død. Den skulle være
> tidligst 04 DEC 1899 på grund af hendes datter INDI I2475 (En kvinde skal
> være i live ved sit barns fødsel). Men den er også angivet at ske senest 31
> DEC 1852.

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

---

Hej Lars.

.........

LKL> Når man f.eks. via GEDCOMP bliver opmærksom på at der et problem
LKL> med GEDCOM-genereringen i det slægtsprogram man bruger, så send
LKL> en fejl-rapport om det til producenten.

LKL> Eksempel: Mange slægtsforskere skriver til mig:
LKL> Jeg har nu brugt XYZ timer på at (fors¢ge at) rette de
LKL> forkert formatterede datoer i min GEDCOM-fil.

LKL> Den slags er irrelevant arbejde for en slægtsforsker og
LKL> nærmest spild af tid.

LKL> Istedet b¢r man (meget gerne sammen med andre brugere) henvende
LKL> sig til producenten af slægtsprogrammet og sige noget i stil med:
LKL> Vi er rimeligt tilfredse med dit program. Men vi er blevet
opmærksomme
LKL> på at programmets GEDCOM-generering er fejlbehæftet, se nedenfor.
LKL> Vi vil sætte stor pris på at denne fejl bliver rettet i næste
LKL> version af programmet.

Kunne du ikke offentligg¢re hvilke programmer der ikke lever op til
standarden
og hvor de ikke g¢r det? Så ved vi, hvad vi ikke evt. ikke skal skifte til.

For nu at kaste ved på bålet: Er det WinFamily, Brother's Keeper, Family
Tree Maker eller PAF, som jeg mener er de mest udbredte programmer eller er
der andre? Og hvad er der galt?

Er der overhovedet nogen af indsenderne til GEDCOMP der bruger The Master
Genealogist, som skulle være suverænt?

--
Mvh. Leif - leif@nightcall.dk

---

Thu, 05 Dec 2002 18:09:46 +0100 skrev Leif Thor Olsen:

> Kunne du ikke offentligg¢re hvilke programmer der ikke lever op til
> standarden
> og hvor de ikke g¢r det?

Jeg har modtaget GEDCOM-filer med ugyldig DATE-information fra
følgende programmer:

WINFAM 6.02
FTW (Family Tree Maker for Windows) 10.0
BROSKEEP (Brothers Keeper) 6.1.8
PAF (Personal Ancestral File) 5.2.18.0
CFTREE (Cumberland Family Tree) CFTREE Windows Ver Pro 3.12
FamilyOrigins (Family Origins(R) for Windows) 8.0
TMG (The Master Genealogist) 4.0c
Legacy 4.0

og givetvis mange andre programmer. Formentlig alle.

Ovenstående programmer er så vidt jeg ved kommercielle.
Derfor vil jeg ikke bruge tid på at komme med en liste
over hvad hver producent burde rette i sit produkt.

> Er der overhovedet nogen af indsenderne til GEDCOMP der bruger The
> Master Genealogist, som skulle være suverænt?

Se http://www.lklundin.dk/gedcomp/sw_stat.asc .

Altså en halv snes stykker.

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

---

Da der tilsyneladende er et problem med eksport fra Brothers Keeper til
GEDCOM formatet.



Vil jeg derfor opfordre brugerne af både BK6.1.9 (eller større) og GEDCOMP
til at sende mig en kopi af kontrol-rapporten sammen med versionsnummeret af
BK til mig. (Se mailadressen herunder).

Således at der kan ske en henvendelse til producenten i USA John Steed. Med
det formål at få rettet på eventuelle fejl i programmet.


--
Chris Gade Oxholm Sørensen
support@brotherskeeper.dk

BK - software - opdatering - manual - www.brotherskeeper.dk


"Lars Kr. Lundin" <news-gi-20@lklundin.dk> skrev i en meddelelse
news:pan.2002.12.06.15.53.23.652520.10513@lklundin.dk...
> Thu, 05 Dec 2002 18:09:46 +0100 skrev Leif Thor Olsen:
>
> > Kunne du ikke offentligg¢re hvilke programmer der ikke lever op til
> > standarden
> > og hvor de ikke g¢r det?
>
> Jeg har modtaget GEDCOM-filer med ugyldig DATE-information fra
> følgende programmer:
>
> WINFAM 6.02
> FTW (Family Tree Maker for Windows) 10.0
> BROSKEEP (Brothers Keeper) 6.1.8
> PAF (Personal Ancestral File) 5.2.18.0
> CFTREE (Cumberland Family Tree) CFTREE Windows Ver Pro 3.12
> FamilyOrigins (Family Origins(R) for Windows) 8.0
> TMG (The Master Genealogist) 4.0c
> Legacy 4.0

---

"Chris Gade Oxholm Sørensen" <support@brotherskeeper.dk> skrev:
Sat, 7 Dec 2002 11:41:11 +0100 i dk.videnskab.historie.genealogi
>Da der tilsyneladende er et problem med eksport fra Brothers Keeper til
>GEDCOM formatet.
>Vil jeg derfor opfordre brugerne af både BK6.1.9 (eller større) og GEDCOMP
>til at sende mig en kopi af kontrol-rapporten sammen med versionsnummeret af
>BK til mig. .............
Hvorfor begrænse problemet til version 6.1.9 eller større ?
Er det for at undgå at for mange klager ?
De sidste hundredevis af opgraderinger af BK har jo overhovedet
ikke ændret på dette gamle problem.

Erik

---

Erik skrev:

> Hvorfor begrænse problemet til version 6.1.9 eller større?
> Er det for at undgå at for mange klager?
> De sidste hundredevis af opgraderinger af BK har jo overhovedet
> ikke ændret på dette gamle problem.

Det er jo i grunden ikke nødvendigt at komme med et ønske om en fejlretning
på en gammel programversion. Hvilket ville være spild af god tid.
Omkring for mange klager - det har jeg ikke nogen problemer med - klager er
velkommen - men bedst hvis der ikke kom nogen, for det er vel udtryk for at
programmet virker som det skal. Men sådan er verden nok ikke.
At der er kommet opgraderinger ser jeg som et ønske om at tilpasse sig
hurtigt til brugernes ønsker - hvad den sidste version netop nu lever op
til.
--
Chris Gade Oxholm Sørensen
support@brotherskeeper.dk

BK - software - opdatering - manual - www.brotherskeeper.dk

---

On Sun, 8 Dec 2002 01:29:09 +0100, "Chris Gade Oxholm Sørensen"
<support@brotherskeeper.dk> wrote:

>Det er jo i grunden ikke nødvendigt at komme med et ønske om en fejlretning
>på en gammel programversion. Hvilket ville være spild af god tid.
>Omkring for mange klager - det har jeg ikke nogen problemer med - klager er
>velkommen - men bedst hvis der ikke kom nogen, for det er vel udtryk for at
>programmet virker som det skal. Men sådan er verden nok ikke.
>At der er kommet opgraderinger ser jeg som et ønske om at tilpasse sig
>hurtigt til brugernes ønsker - hvad den sidste version netop nu lever op
>til.

Etter hva jeg kan se av data fra BK er at John Steed bruker tekst til
å lagre datoer og ikke en binær presentasjon av en dato. Det medfører
store problemer om en bruker endrer datoformat for input, f.eks. fra
dd.mm.yyyy til mm.dd.yyyy hvor da 1. februar umiddelbart vil bli tl 2.
januar Hvis ikke dato i input konverteres umiddelbart til en binær
presentasjon vil man enten måtte bruke en ekstra integer for hver
eneste dato som forteller hvilket inputformat ble brukt, noe som er
sløsing med dataareal eller så er man avhengig av å konvertere til
korrekt Gedcom-format ut fra hva som er nå registrert som datoformat,
noe som åpner for feiltolkinger på senere tidspunkt hvis formatet
endres underveis. F.eks. at for 4 år siden la man inn en dato som
04.03.1777 med dd.mm.yyyy som inputformat, dvs. 4. mars 1777, og så
for 1 år siden har man ednret til mm.dd.yyyy som medfører at datoen nå
skulle eksporteres til Gedcom som 3 APR 1777.

Problemet originalt var vel at BK ikke kunne konvertere i det hele
tatt. Skulle man få ut datoer på Gedcom-format så måtte de skrives på
Gedcom-format. dd.mm.yyyy eksporteres som det, mm.dd.yyyy eksporteres
eksakt slik det er skrevet, tekstlig og dd MMM yyyy ble eksportert som
det. Intet forsøk som i andre program om å endre 3.4.1777 til antall
dager siden år 0 eller siden 1.1.1900 (altså et negativ antall dager)
som også¨BK burde ha benyttet fra første dag, men muligens ikke mulig
i databasesystemet som benyttes i BK.

---

Fri, 27 Dec 2002 11:39:54 +0100, in dk.videnskab.historie.genealogi, Alf
Christophersen <alf.christophersen@basalmed.uio.no> wrote:

>Etter hva jeg kan se av data fra BK er at John Steed bruker tekst til
>å lagre datoer og ikke en binær presentasjon av en dato. Det medfører
>store problemer om en bruker endrer datoformat for input, f.eks. fra
>dd.mm.yyyy til mm.dd.yyyy hvor da 1. februar umiddelbart vil bli tl 2.
>januar Hvis ikke dato i input konverteres umiddelbart til en binær
>presentasjon vil man enten måtte bruke en ekstra integer for hver
>eneste dato som forteller hvilket inputformat ble brukt, noe som er
>sløsing med dataareal eller så er man avhengig av å konvertere til
>korrekt Gedcom-format ut fra hva som er nå registrert som datoformat,
>noe som åpner for feiltolkinger på senere tidspunkt hvis formatet
>endres underveis. F.eks. at for 4 år siden la man inn en dato som
>04.03.1777 med dd.mm.yyyy som inputformat, dvs. 4. mars 1777, og så
>for 1 år siden har man ednret til mm.dd.yyyy som medfører at datoen nå
>skulle eksporteres til Gedcom som 3 APR 1777.

Dette er ikke riktig om man følger hva som er beskrevet om oppsett av
dotoformater.
Få nå det snart inn at det har ingen betydning omhvordan et datoformat
er lagret i BK sin database om man setter opp programmet riktig.

I databasen registreres ikke 1. februar som dato. Det er ikke i
oversenstemmelse med beskrivelsen om hvordan dato skal registreres.
Jeg tør henvise Christophersen til å lese hjelpefilen for BK før han
uttaler seg videre

F.eks. når det gjelder 04.03.1777 vil det avhenge av hvilket datoformat
som er anvendt i oppsettet. Hvis man registrerte det dette i betydning
av 4 mar 1777 og senere ønsker å tolke dette som 3 apr 1777, da skal man
foreta en konvertering av databasen.

Det er også beskrevet i hjelpefilen som er med i programmet og som
Christophersen nå anbefales å lese før han uttaler seg videre.
Følr man uttaler seg om et program så forutsettes at man setter seg inn
i programmet og dets regler.

Følger man spillereglene er her ikke noe problem. Det er kun de som har
vill fantasi som fortsatt har problemer.

Man må snart komme bort fra stadiet "Jeg vet best og leser ikke
veiledningen. Den er bare tull og den leser jeg først når alt går feil"

Fortsatt hyggelig jul

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

On Fri, 27 Dec 2002 14:09:50 +0100, Otto Jorgensen
<otjoerge@online.no> wrote:

>Dette er ikke riktig om man følger hva som er beskrevet om oppsett av
>dotoformater.
>Få nå det snart inn at det har ingen betydning omhvordan et datoformat
>er lagret i BK sin database om man setter opp programmet riktig.

Hvorfor blir da ikke datoer tastet inn med et format endret til nytt
format om man endrer format hvis ikke det er slik at datoer lagres
tekstlig (og avhengig av oppsett) og ikke binært (uavhengig av oppsett
av format)

---

Mon, 30 Dec 2002 03:43:50 +0100, in dk.videnskab.historie.genealogi, Alf
Christophersen <alf.christophersen@basalmed.uio.no> wrote:

>On Fri, 27 Dec 2002 14:09:50 +0100, Otto Jorgensen
><otjoerge@online.no> wrote:
>
>>Dette er ikke riktig om man følger hva som er beskrevet om oppsett av
>>dotoformater.
>>Få nå det snart inn at det har ingen betydning omhvordan et datoformat
>>er lagret i BK sin database om man setter opp programmet riktig.
>
>Hvorfor blir da ikke datoer tastet inn med et format endret til nytt
>format om man endrer format hvis ikke det er slik at datoer lagres
>tekstlig (og avhengig av oppsett) og ikke binært (uavhengig av oppsett
>av format)


Det er et resultat av at brukerne selv har fremmet ønske om at dette vil
de styre selv.
Hva som ligger i databasen er uten betydning.

Hvis man skal ha en systematisk som har tankeoverføring fra hva brukeren
mener når vedkommende registrerer 12.05.1912 eller 05.12.1912
eller 1. påskedag 1918
Det er altså forventet at programmet uten videre skal fortolke dette til
et format som i neste hand blir slik som GEDCOM ønsker det
Er ikke det litt langt med kommunikasjonen av tankevirksomheten mellom
maskin og menneske

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

Netop problemet med muligheden for at kunne anvende et datoformat der alene
består af tal (f.eks. 05.12.1912), derfor anbefaler jeg altid at ens datoer
indeholder månedsnavnet skrevet med bogstaver (f.eks. 05 dec 1912). Så er
der ikke nogen fejllæsningsmulighed. Det giver den mulighed at datoen også
kan læses af andre som måske læser en dato med månedsangivelsen sat først
(f.eks. i USA (dec. 05 1912)). Den valgte skriveform skal naturligvis passe
til programmets opsætning - jo nærmest logik - men sådan er verden bare
ikke.

Som Otto flere gange har været inde på er netop brugeren der ofte er årsag
til fejl (fejl 40 = en fejl der opstår 40 cm fra skærmen). Som et eksempel
på nogle af de fejl jeg ofte bliver bedt om hjælp til med, er kopiering af
filer fra et mail til programbiblioteket, hjælp når opgraderingsfiler er
blevet gemt på harddisken som BK6W.EXE og dermed starter
opdateringsprocessen igen og igen, hver gang brugeren forsøger at starte
Brothers Keeper. Dette skrevet med fuld bevidsthed om at lagt hovedparten af
brugerne har en meget begrænset edb viden og på ingen måde er en nørd. Og
disse brugere SKAL der også være plads til.

Derfor er der også blevet sendt en længere liste på ønsker, leveret af
brugerne, til John Steed, hvor der bl.a. var ønsker om at gøre flere
funktioner i Brothers Keeper langt mere sikre, herunder eksport til en
GEDCOM fil og ved sammenlægning af to databaser. Hvor netop datoformatet kan
være forskellig - dette velvidende, at der i hjælpefilen er beskrevet
hvilket der bør (skal) foretages inden en sådan handling startes.

Ud fra de mange indlæg der har været i denne tråd. Mener jeg at kunne
konkludere, at alle er enige om, at ingen af slægtsforskningsprogrammerne er
optimale og derfor må det være et pres fra brugerne direkte eller gennem
repræsentanterne for de enkelte programmer, om at få så mange
fejl/uheldigheder og/eller fejlmuligheder fjernet så hurtigt som muligt.
Og når Lars Lundin kan konstatere at de GEDCOM-filer han modtager er fyldt
med fejl, om disse opstår ved brugeren eller som en programfejl, så må målet
være at få ændret programmet, således at dette kan undgås.

Jeg skal ikke her give udtryk for hvorledes andre programrepræsentanter har
tænkt sig eller gør, men jeg tager sikkert ikke fejl, hvis holdningen er den
samme som både Otto og jeg meget gerne vil - nemlig at få rapporteret
tilbage, når der konstateres fejl i programmet eller uhensigtsmæssigheder i
måden hvorpå brugerflader er præsenteret på.

Lad dette være udgangen og lad os hellere få samlet information sammen på
ting der ønskes forbedret eller videreudviklet, for i sidste ende er det til
glæde for os selv som bruger og så er det langt mere positivt, at se at
programmet udvikler sig i en retning som man selv har været med til at
foreslå.

--
Bedste nytårs hilsner fra
Chris Gade Oxholm Sørensen
support@brotherskeeper.dk

BK - software - opdatering - manual - www.brotherskeeper.dk


> Det er et resultat av at brukerne selv har fremmet ønske om at dette vil
> de styre selv.
> Hva som ligger i databasen er uten betydning.
>
> Hvis man skal ha en systematisk som har tankeoverføring fra hva brukeren
> mener når vedkommende registrerer 12.05.1912 eller 05.12.1912
> eller 1. påskedag 1918
> Det er altså forventet at programmet uten videre skal fortolke dette til
> et format som i neste hand blir slik som GEDCOM ønsker det
> Er ikke det litt langt med kommunikasjonen av tankevirksomheten mellom
> maskin og menneske
>
> --
> Otto Jørgensen
> http://home.online.no/~otjoerge/
> http://home.online.no/~otjoerge/bk/

---

"Chris Gade Oxholm Sørensen" <support-snabela-brotherskeeper.dk> skrev i en
meddelelse news:3e10460e$0$71602$edfadb0f@dread11.news.tele.dk...
> Netop problemet med muligheden for at kunne anvende et datoformat der
alene
> består af tal (f.eks. 05.12.1912), derfor anbefaler jeg altid at ens
datoer
> indeholder månedsnavnet skrevet med bogstaver (f.eks. 05 dec 1912). Så er
> der ikke nogen fejllæsningsmulighed. Det giver den mulighed at datoen også
> kan læses af andre som måske læser en dato med månedsangivelsen sat først
> (f.eks. i USA (dec. 05 1912)). Den valgte skriveform skal naturligvis
passe
> til programmets opsætning - jo nærmest logik - men sådan er verden bare
> ikke.
>
> Som Otto flere gange har været inde på er netop brugeren der ofte er årsag
> til fejl (fejl 40 = en fejl der opstår 40 cm fra skærmen). Som et eksempel
> på nogle af de fejl jeg ofte bliver bedt om hjælp til med, er kopiering af
> filer fra et mail til programbiblioteket, hjælp når opgraderingsfiler er
> blevet gemt på harddisken som BK6W.EXE og dermed starter
> opdateringsprocessen igen og igen, hver gang brugeren forsøger at starte
> Brothers Keeper. Dette skrevet med fuld bevidsthed om at lagt hovedparten
af
> brugerne har en meget begrænset edb viden og på ingen måde er en nørd. Og
> disse brugere SKAL der også være plads til.
>
> Derfor er der også blevet sendt en længere liste på ønsker, leveret af
> brugerne, til John Steed, hvor der bl.a. var ønsker om at gøre flere
> funktioner i Brothers Keeper langt mere sikre, herunder eksport til en
> GEDCOM fil og ved sammenlægning af to databaser. Hvor netop datoformatet
kan
> være forskellig - dette velvidende, at der i hjælpefilen er beskrevet
> hvilket der bør (skal) foretages inden en sådan handling startes.
>
> Ud fra de mange indlæg der har været i denne tråd. Mener jeg at kunne
> konkludere, at alle er enige om, at ingen af slægtsforskningsprogrammerne
er
> optimale og derfor må det være et pres fra brugerne direkte eller gennem
> repræsentanterne for de enkelte programmer, om at få så mange
> fejl/uheldigheder og/eller fejlmuligheder fjernet så hurtigt som muligt.
> Og når Lars Lundin kan konstatere at de GEDCOM-filer han modtager er fyldt
> med fejl, om disse opstår ved brugeren eller som en programfejl, så må
målet
> være at få ændret programmet, således at dette kan undgås.
>
> Jeg skal ikke her give udtryk for hvorledes andre programrepræsentanter
har
> tænkt sig eller gør, men jeg tager sikkert ikke fejl, hvis holdningen er
den
> samme som både Otto og jeg meget gerne vil - nemlig at få rapporteret
> tilbage, når der konstateres fejl i programmet eller uhensigtsmæssigheder
i
> måden hvorpå brugerflader er præsenteret på.
>
> Lad dette være udgangen og lad os hellere få samlet information sammen på
> ting der ønskes forbedret eller videreudviklet, for i sidste ende er det
til
> glæde for os selv som bruger og så er det langt mere positivt, at se at
> programmet udvikler sig i en retning som man selv har været med til at
> foreslå.
>
> --
> Bedste nytårs hilsner fra
> Chris Gade Oxholm Sørensen
> support@brotherskeeper.dk
>
> BK - software - opdatering - manual - www.brotherskeeper.dk

Ovenstående er jo ganske spændende læsning. Og lærerigt!
I forbindelse med indsendelse af en GEDCOM-fil til CEDCOMP, fik jeg den
sørgelige tilbagemelding at mit datoformat var forkert. Det var jo ikke gode
nyheder!
Jeg havde brugt datoformatet 30.12.2002 (eksempelvis) og det viste sig IKKE
at være GEDCOM-standard.
Der blev, fra en anden, henvist til at BK har en default-opsætning, som man
burde benytte, og, at såfremt der opstod problemer, måtte det være
brugereren som havde været inde og rode i opsætningen.
I mit tilfælde, er det nu interessant, at jeg ALDRIG (før nu) har været inde
og pille i opsætningen af datoformatet.
Resultatet af en manglende brugbar default-indstilling er, at jeg nu er i
gang med at rette alle 3678 personer i min database manuelt! En for en -
samtlige datoer - alle begivenheder. Et sted mellem 16-18.000 rettelser!
Fandens til arbejde!
Jeg vil derfor gerne spørge om det ikke var muligt, at få en vejledning
drekte på redigeringsvinduet når dette åbnes.
Det kunne eksempelvis stå til højre for feltet hvor alder angives.
Det kan vel ikke være det store problem, at gøre brugerne opmærksom på hvad
der er GEDCOM-standard og hvad der kan bruges som datoformat i CEDCOMP.
Da flere og flere oplysninger vedr. slægtsforskning bliver tilgængelige på
internettet - hvad jo også denne gruppe vidner om - ville det da være mest
praktisk at have en fælles standard, som alle kan benytte umiddelbart.
Også sådanne som jeg, der ikke lige har været opmærksom på de forskellige
datoformater! At jeg så måske ikke har lyttet ordentlig efter i timen, må
jeg jo selv tage de små smæk for - men, der kommer jo hele tiden nye
vordende slægstforskere til her i gruppen. Hvorfor dog ikke spare dem for en
hulens masse arbejde, besvær og ærgelser!?
Det kan jo gøres ret nemt og let for nye brugere - en lille vejledning
direkte dér hvor man foretager sine indtastninger.
Nå, men jeg må videre med mine rettelser - har desværre kun nået ca.
halvdelen af alle personer i databasen.
Ønsker alle et rigtigt Godt Nyår - og mange spændende oplevelser og nye fund
i det nye år.

Med venlig hilsen

Steven

---

Mon, 30 Dec 2002 17:25:56 +0100, in dk.videnskab.historie.genealogi,
"Steven" <ccc98484@vip.cybercity.dk> wrote:

>
>"Chris Gade Oxholm Sørensen" <support-snabela-brotherskeeper.dk> skrev i en
>meddelelse news:3e10460e$0$71602$edfadb0f@dread11.news.tele.dk...
>> Netop problemet med muligheden for at kunne anvende et datoformat der
>alene
>> består af tal (f.eks. 05.12.1912), derfor anbefaler jeg altid at ens
>datoer
>> indeholder månedsnavnet skrevet med bogstaver (f.eks. 05 dec 1912). Så er
>> der ikke nogen fejllæsningsmulighed. Det giver den mulighed at datoen også
>> kan læses af andre som måske læser en dato med månedsangivelsen sat først
>> (f.eks. i USA (dec. 05 1912)). Den valgte skriveform skal naturligvis
>passe
>> til programmets opsætning - jo nærmest logik - men sådan er verden bare
>> ikke.
>>
>> Som Otto flere gange har været inde på er netop brugeren der ofte er årsag
>> til fejl (fejl 40 = en fejl der opstår 40 cm fra skærmen). Som et eksempel
>> på nogle af de fejl jeg ofte bliver bedt om hjælp til med, er kopiering af
>> filer fra et mail til programbiblioteket, hjælp når opgraderingsfiler er
>> blevet gemt på harddisken som BK6W.EXE og dermed starter
>> opdateringsprocessen igen og igen, hver gang brugeren forsøger at starte
>> Brothers Keeper. Dette skrevet med fuld bevidsthed om at lagt hovedparten
>af
>> brugerne har en meget begrænset edb viden og på ingen måde er en nørd. Og
>> disse brugere SKAL der også være plads til.
>>
>> Derfor er der også blevet sendt en længere liste på ønsker, leveret af
>> brugerne, til John Steed, hvor der bl.a. var ønsker om at gøre flere
>> funktioner i Brothers Keeper langt mere sikre, herunder eksport til en
>> GEDCOM fil og ved sammenlægning af to databaser. Hvor netop datoformatet
>kan
>> være forskellig - dette velvidende, at der i hjælpefilen er beskrevet
>> hvilket der bør (skal) foretages inden en sådan handling startes.
>>
>> Ud fra de mange indlæg der har været i denne tråd. Mener jeg at kunne
>> konkludere, at alle er enige om, at ingen af slægtsforskningsprogrammerne
>er
>> optimale og derfor må det være et pres fra brugerne direkte eller gennem
>> repræsentanterne for de enkelte programmer, om at få så mange
>> fejl/uheldigheder og/eller fejlmuligheder fjernet så hurtigt som muligt.
>> Og når Lars Lundin kan konstatere at de GEDCOM-filer han modtager er fyldt
>> med fejl, om disse opstår ved brugeren eller som en programfejl, så må
>målet
>> være at få ændret programmet, således at dette kan undgås.
>>
>> Jeg skal ikke her give udtryk for hvorledes andre programrepræsentanter
>har
>> tænkt sig eller gør, men jeg tager sikkert ikke fejl, hvis holdningen er
>den
>> samme som både Otto og jeg meget gerne vil - nemlig at få rapporteret
>> tilbage, når der konstateres fejl i programmet eller uhensigtsmæssigheder
>i
>> måden hvorpå brugerflader er præsenteret på.
>>
>> Lad dette være udgangen og lad os hellere få samlet information sammen på
>> ting der ønskes forbedret eller videreudviklet, for i sidste ende er det
>til
>> glæde for os selv som bruger og så er det langt mere positivt, at se at
>> programmet udvikler sig i en retning som man selv har været med til at
>> foreslå.
>>
>> --
>> Bedste nytårs hilsner fra
>> Chris Gade Oxholm Sørensen
>> support@brotherskeeper.dk
>>
>> BK - software - opdatering - manual - www.brotherskeeper.dk
>
>Ovenstående er jo ganske spændende læsning. Og lærerigt!
>I forbindelse med indsendelse af en GEDCOM-fil til CEDCOMP, fik jeg den
>sørgelige tilbagemelding at mit datoformat var forkert. Det var jo ikke gode
>nyheder!
>Jeg havde brugt datoformatet 30.12.2002 (eksempelvis) og det viste sig IKKE
>at være GEDCOM-standard.

30.12.2002 er ikke GEDCOMformat, det er 30 DEC 2002, men det er ikke noe
problem å overføre det dataformatet til GEDCOMfilen

>Der blev, fra en anden, henvist til at BK har en default-opsætning, som man
>burde benytte, og, at såfremt der opstod problemer, måtte det være
>brugereren som havde været inde og rode i opsætningen.
>I mit tilfælde, er det nu interessant, at jeg ALDRIG (før nu) har været inde
>og pille i opsætningen af datoformatet.
>Resultatet af en manglende brugbar default-indstilling er, at jeg nu er i
>gang med at rette alle 3678 personer i min database manuelt! En for en -
>samtlige datoer - alle begivenheder. Et sted mellem 16-18.000 rettelser!
>Fandens til arbejde!

Hva gjør du vis du ikke gjør ditt arbeid riktig.

Hvis du har benyttet format 30.12.2002 i forståelsen av at dette betryr
30 desember 2002, da er ikke det noe problem, men har du blandet fugl go
fisk og også skrevet inn 30.12.2002, 1 juledag 2002, 2002.12.30 slik som
CHrist har omtalt, da har du en jobb, men ikke uvoreokommelig. Det
eneste er å holde hodet klart når du skal foreta disse endringene

Men har du vært gjennomgpende i dine arbeider, så vil sikkert både Chris
og undetegnede gi deg råd på vegen om hva som kan være enklest utvei av
det problemet du muligens har kommet opp i.

>Jeg vil derfor gerne spørge om det ikke var muligt, at få en vejledning
>drekte på redigeringsvinduet når dette åbnes.

Det er rettledning i BK6 som i de fleste andre progra og det er den
kjente og internasjonale tasten F1
Uansett program så er det en kode som man bør lære seg å bruke om man
lurer på noe

>Det kunne eksempelvis stå til højre for feltet hvor alder angives.
>Det kan vel ikke være det store problem, at gøre brugerne opmærksom på hvad
>der er GEDCOM-standard og hvad der kan bruges som datoformat i CEDCOMP.

GEDCOMP er er spesielt tilegnet fil og det om det og det er ikke noen i
veien for at det innholdet skal bli riktig. Det var i den filen jeg har
på 26MB en del feil, hvilket også var feil som overhode ikke kom fra BK,
men som var tillaget av andre. Dette skal (etterhva jeg forstå være
ordnet). Jeg har ikke funnet siste versjon av filen og kan derfor ikke
si noe om kvaliteten i den filen

>Da flere og flere oplysninger vedr. slægtsforskning bliver tilgængelige på
>internettet - hvad jo også denne gruppe vidner om - ville det da være mest
>praktisk at have en fælles standard, som alle kan benytte umiddelbart.
>Også sådanne som jeg, der ikke lige har været opmærksom på de forskellige
>datoformater! At jeg så måske ikke har lyttet ordentlig efter i timen, må
>jeg jo selv tage de små smæk for - men, der kommer jo hele tiden nye
>vordende slægstforskere til her i gruppen. Hvorfor dog ikke spare dem for en
>hulens masse arbejde, besvær og ærgelser!?

Det man henter ned fra Internet er sikkert OK hvis det er fullført som
en standard GEDCOM-fil i GEDCOM5.5 og det er derfor heller ikke større
problemer med å importere dette til BK enn til andre programmer som
aksepterer GEDCOM5.5

>Det kan jo gøres ret nemt og let for nye brugere - en lille vejledning
>direkte dér hvor man foretager sine indtastninger.
>Nå, men jeg må videre med mine rettelser - har desværre kun nået ca.
>halvdelen af alle personer i databasen.

SLik er desverre situasjonen, hvis man ikke tar for seg manual og
hjelpefil, hvor oppsettet av programmet også med hensyn til datoformat
er omtalt

>Ønsker alle et rigtigt Godt Nyår - og mange spændende oplevelser og nye fund
>i det nye år.

SLike ønsker kan aldri være protkastet. GODT NYTTÅR

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

Mon, 30 Dec 2002 18:21:33 +0100 skrev Otto Jorgensen:

> 30.12.2002 er ikke GEDCOMformat, det er 30 DEC 2002, men det er ikke noe
> problem å overføre det dataformatet til GEDCOMfilen

Nu har 3 personer, nemlig undertegnede, Arne Feldborg og Alf
Christophersen adskillige gange og på flere forskellige måder
forsøgt at forklare at det faktisk er meget vanskeligt for
BK-brugere at danne en GEDCOM-fil fri for ugyldige datoer.

På den baggrund må jeg sige at det er udtryk for en imponerende
viljefasthed at forsætte påstanden om at det i BK er problemfrit
at overføre datoer korrekt til en GEDCOM-fil.

> GEDCOMP er er spesielt tilegnet fil

Nej, se signaturen.

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

---

"Lars Kr. Lundin" <news-gi-29@lklundin.dk> skrev i en meddelelse
news:pan.2002.12.30.23.04.51.630761.725@lklundin.dk...
> Mon, 30 Dec 2002 18:21:33 +0100 skrev Otto Jorgensen:
>
> > 30.12.2002 er ikke GEDCOMformat, det er 30 DEC 2002, men det er ikke noe
> > problem å overføre det dataformatet til GEDCOMfilen
>
> Nu har 3 personer, nemlig undertegnede, Arne Feldborg og Alf
> Christophersen adskillige gange og på flere forskellige måder
> forsøgt at forklare at det faktisk er meget vanskeligt for
> BK-brugere at danne en GEDCOM-fil fri for ugyldige datoer.
>
> På den baggrund må jeg sige at det er udtryk for en imponerende
> viljefasthed at forsætte påstanden om at det i BK er problemfrit
> at overføre datoer korrekt til en GEDCOM-fil.
>

Jeg kan kun erklære mig 100% enig i ovenstående, og jeg er også imponeret
over Otto Jorgensen´s viljefasthed omkring BK´s evner til at håndtere
GEDCOM.

Jeg har assisteret adskellige brugere i at konvertere fra BK til Family Tree
Maker (FTM), og jeg er glad for, at GEDCOM filerne er rene tekst filer, så
der kan laves en Søg og Erstat for at rette ale de fejlagtige datoformater.

Det bedste ville være, hvis programmet lagrede datoformatet i ét unikt
format, og at brugeren så kunne vælge et format til at VISE datoer, og at
enhver indtastning automatisk blev konverteret til det valgte VIS format,
uden at ændre på formatet for lagring. Så ville problemet være løst - et
langt stykke hen ad vejen.

Det gør bl.a. FTM

> > GEDCOMP er er spesielt tilegnet fil
>
> Nej, se signaturen.
>

Helt enig!!! Den "snupper" også de fejl, der måtte være i FTM´s datoformat,
specielt omkring FØR, EFT, OMK & MLM!!!

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

Ole P. Bielefeldt
Ry

FTM: www.familytreemaker.dk

---

Mon, 30 Dec 2002 23:32:17 +0100, in dk.videnskab.historie.genealogi,
"Ole P. Bielefeldt" <ole.bielefeldt@adslhome.dk> wrote:

>"Lars Kr. Lundin" <news-gi-29@lklundin.dk> skrev i en meddelelse
>news:pan.2002.12.30.23.04.51.630761.725@lklundin.dk...
>> Mon, 30 Dec 2002 18:21:33 +0100 skrev Otto Jorgensen:
>>
>> > 30.12.2002 er ikke GEDCOMformat, det er 30 DEC 2002, men det er ikke noe
>> > problem å overføre det dataformatet til GEDCOMfilen
>>
>> Nu har 3 personer, nemlig undertegnede, Arne Feldborg og Alf
>> Christophersen adskillige gange og på flere forskellige måder
>> forsøgt at forklare at det faktisk er meget vanskeligt for
>> BK-brugere at danne en GEDCOM-fil fri for ugyldige datoer.
>>
>> På den baggrund må jeg sige at det er udtryk for en imponerende
>> viljefasthed at forsætte påstanden om at det i BK er problemfrit
>> at overføre datoer korrekt til en GEDCOM-fil.
>>
>
>Jeg kan kun erklære mig 100% enig i ovenstående, og jeg er også imponeret
>over Otto Jorgensen´s viljefasthed omkring BK´s evner til at håndtere
>GEDCOM.
>
>Jeg har assisteret adskellige brugere i at konvertere fra BK til Family Tree
>Maker (FTM), og jeg er glad for, at GEDCOM filerne er rene tekst filer, så
>der kan laves en Søg og Erstat for at rette ale de fejlagtige datoformater.
>
>Det bedste ville være, hvis programmet lagrede datoformatet i ét unikt
>format, og at brugeren så kunne vælge et format til at VISE datoer, og at
>enhver indtastning automatisk blev konverteret til det valgte VIS format,
>uden at ændre på formatet for lagring. Så ville problemet være løst - et
>langt stykke hen ad vejen.
>

Jeg gir opp.

Når man ikke har evne til å se forskjell på hva et program gjør med
riktig innlagte data

Og det faktum at det forutsettes at brukerne legger inn riktig
datoformat og dette tiltross for ulike eksempler,
da er enhver videre diskujson meningsløs

Det gir ikke mer hverken for meg eller brukerne

GODT nyttår


--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

Mon, 30 Dec 2002 23:52:03 +0100 skrev Otto Jorgensen:

> Og det faktum at det forutsettes at brukerne legger inn riktig
> datoformat

Den forudsætning er en fundamental fejl i designet af BK.

Een væsentlig fordel ved EDB er netop at det kan opdage
nogle af de fejl, vi mennesker uvægerligt begår.

Ingen her bestrider (heldigvis) det faktum, at BK kan
skrive hobevis af ugyldige datoer i sine GEDCOM-filer.

Og der er altså ingen undskyldning for, at et slægtsprogram
ikke har kontrol over det format, som datoer skrives med
ifbm. GEDCOM-eksport.

For at ingen nu skal tro at jeg er specielt kritisk over for
BK, har jeg lavet en oversigt over kvaliteten af GEDCOM-filer
genereret af forskellige programmer.

Fra enkelte programmer har jeg modtaget GEDCOM-filer helt fri
for syntaks-fejl. Det drejer sig om programmerne
xtex2ged.pl Version 0.9
SeeGedcom Version 0.6b1
GeneWeb Version 3.06

Det første er et perl-program jeg selv har skrevet
Det andet er (shareware) til MacOS X, det tredje er et frit (!)
program til både Unix, Windows og MacOS X.

Jeg har dog kun modtaget en enkelt fil fra hver af disse
programmer, så det er slet ingen garanti for at deres
GEDCOM-eksport er fejlfri

For de øvrige programmer har jeg optalt både antallet af individer
og antallet af syntaks-fejl i GEDCOM-filer genereret af samme
program (og samme version). Jeg har valgt kun at se på nyeste
version, jeg har modtaget filer fra.

Som mål for kvaliteten har jeg brugt antallet af individer per
antal syntaks-fejl. Et stort tal betyder altså at programmet
skriver GEDCOM-filer af relativ god kvalitet.

Tabellen nedenfor viser for hvert program antal filer undersøgt
fra det program, samlet antal individer og syntaks-fejl samt
altså forholdet mellem disse to tal.

SOFTWARE GEDCOMs INDIs Errors Quality
GRAMPS Version 0.7.3 1 10098 3 3366.0
MinSläkt Version V3.0a 3 2949 1 2949.0
EasyTree Version V8.0 3 2820 8 352.5
SLÆGTSPROGRAM Version 23.08.02 4 1687 10 168.7
TMG Version 4.0d 3 6142 37 166.0
FamilyOrigins Version 8.0 2 2635 21 125.5
CFTREE Version Windows Ver Pro 3.12 2 9742 192 50.7
Legacy Version 4.0 9 6661 138 48.3
DISGEN Version 7.0e-1 2 4146 116 35.7
REUNION Version V4.0 5 4040 158 25.6
Family Treasures Version 3.0 3 3331 139 24.0
WINFAM Version 6.02 99 83891 4634 18.1
PAF Version 5.2.18.0 5 19534 1300 15.0
BROSKEEP Version 6.1.10 WINDOWS 4 19641 2385 8.2
FTW Version 109.0 7 3309 812 4.1
FamilyTies Version 1.0 11 6082 2044 3.0
Reunion Version V7.0 7 5326 2761 1.9

Man kan umiddelbart konstatere at BK ikke er det eneste program,
der har givet sine brugere alvorlige problemer med at skrive en
GEDCOM-fil fri for syntaks-fejl.

Og så vil jeg tilføje at de 3 fundne fejl i GRAMPS er kendte
af udviklerne, og at fejlene er ved at blive rettet.

Sjovt at to frie programmer klarer sig så godt i denne (simple)
sammenligning.

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

---

Tue, 31 Dec 2002 01:39:52 +0100, in dk.videnskab.historie.genealogi,
"Lars Kr. Lundin" <news-gi-29@lklundin.dk> wrote:

>
>Og der er altså ingen undskyldning for, at et slægtsprogram
>ikke har kontrol over det format, som datoer skrives med
>ifbm. GEDCOM-eksport.

Det er i begrenset kontroll og den er ikke god. Men det er heller ingen
undskyldning om at bruker ikke setter opp sitt program. Det gjøres med
de aller fleste program og er stort sett en normal posssess etter
installasjon av et program

Jeg er ikke uenig i at kontrollen for inntasting av feilaktig datoformat
kunne vært bedre og dette presiseres også overfor produsenten.

Men når man gjør dette riktig så er det ikke noe i selve
GEDCOMprossessen i programmet som gjør at resultatet blir feil

Derfor har jeg også hele tiden hatt et skille i diskusjonen mellom de
data som leveres fra bruker og selve GEDCOM prossessen.

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

On Mon, 30 Dec 2002 23:52:03 +0100, Otto Jorgensen
<otjoerge@online.no> wrote:

>Når man ikke har evne til å se forskjell på hva et program gjør med
>riktig innlagte data
>
>Og det faktum at det forutsettes at brukerne legger inn riktig
>datoformat og dette tiltross for ulike eksempler,
>da er enhver videre diskujson meningsløs

Jo, Otto, vi har fått med oss at setter man opp BK til å akseptere
datoer på format dd MMM yyyy, så vil datoer bli eksportert riktig.
Skriver man noe annet, får man også noe annet ut igjen.

Ha et riktig Godt Nytt År.

(PS. Hvorfor insisterer fortsatt en viss person på å kalle ANSI for
Windows ?? Enda godt dog at han har akseptert at ANSI <> DOS-format,
selv om det tok flere år å få det rettet)

---

Tue, 31 Dec 2002 22:07:56 +0100, in dk.videnskab.historie.genealogi, Alf
Christophersen <alf.christophersen@basalmed.uio.no> wrote:

>On Mon, 30 Dec 2002 23:52:03 +0100, Otto Jorgensen
><otjoerge@online.no> wrote:
>
>>Når man ikke har evne til å se forskjell på hva et program gjør med
>>riktig innlagte data
>>
>>Og det faktum at det forutsettes at brukerne legger inn riktig
>>datoformat og dette tiltross for ulike eksempler,
>>da er enhver videre diskujson meningsløs
>
>Jo, Otto, vi har fått med oss at setter man opp BK til å akseptere
>datoer på format dd MMM yyyy, så vil datoer bli eksportert riktig.
>Skriver man noe annet, får man også noe annet ut igjen.
>

da har man kommet langt datoformeter har vanligvis ulike formater om man
er i eruropa eller USA og dermed blir dette forskjell og skriver man
datoer som 03.04.1910 eller 04.03.1910 må man vite hvor i verden man er
og hvordan man skal lese dette.

Derfor har jeg alltid en anbefaling om at man bruker datoformat hvor
måned kommer frem i klartekst, f.eks. 3 apr 1910 eller 4 mar 1910

Eller får man jo håpe at diskusjonen i 2002 har avklart en del forhold
som man kan ta med seg inn i 2003

Fortsatt GODT NYTTÅR

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

"Otto Jorgensen" <otjoerge@online.no> skrev i en meddelelse
news:0aj51vso2aqljv7q7ftmr7s6pgur13pufo@4ax.com...
> Tue, 31 Dec 2002 22:07:56 +0100, in dk.videnskab.historie.genealogi, Alf
> Christophersen <alf.christophersen@basalmed.uio.no> wrote:
>
> >On Mon, 30 Dec 2002 23:52:03 +0100, Otto Jorgensen
> ><otjoerge@online.no> wrote:
> >
> >>Når man ikke har evne til å se forskjell på hva et program gjør med
> >>riktig innlagte data
> >>
> >>Og det faktum at det forutsettes at brukerne legger inn riktig
> >>datoformat og dette tiltross for ulike eksempler,
> >>da er enhver videre diskujson meningsløs
> >
> >Jo, Otto, vi har fått med oss at setter man opp BK til å akseptere
> >datoer på format dd MMM yyyy, så vil datoer bli eksportert riktig.
> >Skriver man noe annet, får man også noe annet ut igjen.
> >
>
> da har man kommet langt datoformeter har vanligvis ulike formater om man
> er i eruropa eller USA og dermed blir dette forskjell og skriver man
> datoer som 03.04.1910 eller 04.03.1910 må man vite hvor i verden man er
> og hvordan man skal lese dette.
>
> Derfor har jeg alltid en anbefaling om at man bruker datoformat hvor
> måned kommer frem i klartekst, f.eks. 3 apr 1910 eller 4 mar 1910
>
> Eller får man jo håpe at diskusjonen i 2002 har avklart en del forhold
> som man kan ta med seg inn i 2003
>
> Fortsatt GODT NYTTÅR
>
> --
> Otto Jørgensen
> http://home.online.no/~otjoerge/
> http://home.online.no/~otjoerge/bk/

Programmet kunne jo gøre sig den umage, at "slå op" i de indstillinger man
selv har sat i Kontrolpanelet under Internatinale, for der står jo det
datoformat man generelt øndker.

Også fortsat godt Nytår herfra.

Ole P. Bielefeldt
Ry

FTM: www.familytreemaker.dk

---

Wed, 1 Jan 2003 13:23:57 +0100, in dk.videnskab.historie.genealogi, "Ole
P. Bielefeldt" <ole.bielefeldt@adslhome.dk> wrote:

>Programmet kunne jo gøre sig den umage, at "slå op" i de indstillinger man
>selv har sat i Kontrolpanelet under Internatinale, for der står jo det
>datoformat man generelt øndker.


testen på dato, kan som nevnt være bedre og det ligger også ønske om
dette hos produsenten og det er bedt om at man i større grad skal teste
mot det oppsettet.


--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

On Wed, 01 Jan 2003 12:15:54 +0100, Otto Jorgensen
<otjoerge@online.no> wrote:

>da har man kommet langt datoformeter har vanligvis ulike formater om man
>er i eruropa eller USA og dermed blir dette forskjell og skriver man
>datoer som 03.04.1910 eller 04.03.1910 må man vite hvor i verden man er
>og hvordan man skal lese dette.

I ACWinGenea kunne jeg knatte inn datoer på i alt 14 formater og man
kunne endre disse når som helst fordi jeg ikke lagret dem som det, men
som et float, dvs. tDateTime. Der hvor man ikke kunne konvertere dato
til et float, dvs. antall dager siden år 0 fordi man ikke hadde eksakt
dag ble dato lagret som tekst og med en variabel i tillegg som
inneholdt hvilket input-format som var blitt brukt. Alle ikke-eksakte
datoer ble eksportert i Gedcom som '(dato)', dvs. at dato starter med
en parentes og avsluttes med en parentes.

---

Wed, 01 Jan 2003 18:30:18 +0100, in dk.videnskab.historie.genealogi, Alf
Christophersen <alf.christophersen@basalmed.uio.no> wrote:

>On Wed, 01 Jan 2003 12:15:54 +0100, Otto Jorgensen
><otjoerge@online.no> wrote:
>
>>da har man kommet langt datoformeter har vanligvis ulike formater om man
>>er i eruropa eller USA og dermed blir dette forskjell og skriver man
>>datoer som 03.04.1910 eller 04.03.1910 må man vite hvor i verden man er
>>og hvordan man skal lese dette.
>
>I ACWinGenea kunne jeg knatte inn datoer på i alt 14 formater og man
>kunne endre disse når som helst fordi jeg ikke lagret dem som det, men
>som et float, dvs. tDateTime. Der hvor man ikke kunne konvertere dato
>til et float, dvs. antall dager siden år 0 fordi man ikke hadde eksakt
>dag ble dato lagret som tekst og med en variabel i tillegg som
>inneholdt hvilket input-format som var blitt brukt. Alle ikke-eksakte
>datoer ble eksportert i Gedcom som '(dato)', dvs. at dato starter med
>en parentes og avsluttes med en parentes.

Det er 12 forskjellige datoformater i BK, men det gir ikks varet på om
de to nevnte datoer skal av programmet forståes som 4 april eller 3
mars.

Hvis du ta skriver inn disse to datoen, hvilke forutsetninger har du da
lget i programmet at inntastingen blir tolket riktig.
Det er ikke gitt noe svar på det

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

On Wed, 01 Jan 2003 18:41:38 +0100, Otto Jorgensen
<otjoerge@online.no> wrote:

>Det er 12 forskjellige datoformater i BK, men det gir ikks varet på om
>de to nevnte datoer skal av programmet forståes som 4 april eller 3
>mars.
>
>Hvis du ta skriver inn disse to datoen, hvilke forutsetninger har du da
>lget i programmet at inntastingen blir tolket riktig.
>Det er ikke gitt noe svar på det

Joda, det som programmereren har lagt inn. Det er bare på et tidspunkt
at noe kan kontrolleres, og det er i det øyeblikk skrivemerket
forlater feltet for innlegging av dato.Da skal det som skrives
fortolkes mot det du har oppgitt som fasit. Stemmer det ikke skal
bruker bli nektet å forlate datofeltet og melding gis om hvorfor.

---

On Wed, 01 Jan 2003 12:15:54 +0100, Otto Jorgensen
<otjoerge@online.no> wrote:


>da har man kommet langt datoformeter har vanligvis ulike formater om man
>er i eruropa eller USA og dermed blir dette forskjell og skriver man
>datoer som 03.04.1910 eller 04.03.1910 må man vite hvor i verden man er
>og hvordan man skal lese dette.

Blot en reflektorisk tanke, for de fleste civiliserede lande har for
længe siden undertegnet en international konvention, iføge hvilken
tidsangivelser skal ske på følgende måde 2002.01.12. og med forsat
punktuering timer, minutter, sekunder og brøkdele af sekunder etc.

Men som sædvanlig med den slags standarder, drøjer det noget med at få
dem taget effektivt i brug. Tænk blot på 'metric' i England, USA
m.fl., men der er da sporet en vis start med dette datoformat i breve
og forretningspost som fakturaer etc. i Europa.

Før det finder vej til vor hobby, f.eks. som internt
'omregningsformat', er der dog (sikkert) lang vej, ikke mindst da
standarden og udviklingen på sæt og vis dikteres af vore
stokkonservative amerikanere...
>
>Derfor har jeg alltid en anbefaling om at man bruker datoformat hvor
>måned kommer frem i klartekst, f.eks. 3 apr 1910 eller 4 mar 1910
>
Salig Jens Finderup var ganske stædig i sin anbefaling af, altid at
indrette sin BK med datoformat "9" som noget af det første; mens
indtastning så kunne foretages med 0204(19)10. Parentesen, fordi
forvalg af årstal (19) også kunne reguleres centralt.

Venligst
John

---

Mon, 30 Dec 2002 23:04:52 +0100, in dk.videnskab.historie.genealogi,
"Lars Kr. Lundin" <news-gi-29@lklundin.dk> wrote:

>> GEDCOMP er er spesielt tilegnet fil
>
>Nej, se signaturen.

Som jeg referet til i en tidligere melding hadde jeg b versjonen på 36
MB og den inneholdt GEDCOMkoder som ikke var laget av BK., bla. COMM
istedet for NOTE
Dette ble også innrømmet av produsenten av den aktuell filen og rettet.
Jeg vil anta at eksistere versjon c har rette koder, men da jeg ikke ser
å kunne finne den for nedlasting, kan jeg ikke kontrollere den siste
versjonen, hverken med hensyn til kodebruk eller innlesingstid

Men i og for seg betyr det jo lite


GODT NYTTÅR

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

Ovenstående er jo ganske spændende læsning. Og lærerigt!
I forbindelse med indsendelse af en GEDCOM-fil til CEDCOMP, fik jeg den
sørgelige tilbagemelding at mit datoformat var forkert. Det var jo ikke gode
nyheder!
Jeg havde brugt datoformatet 30.12.2002 (eksempelvis) og det viste sig IKKE
at være GEDCOM-standard.

> 30.12.2002 er ikke GEDCOMformat, det er 30 DEC 2002, men det er ikke noe
> problem å overføre det dataformatet til GEDCOMfilen

Der blev, fra en anden, henvist til at BK har en default-opsætning, som man
burde benytte, og, at såfremt der opstod problemer, måtte det være
brugereren som havde været inde og rode i opsætningen.
I mit tilfælde, er det nu interessant, at jeg ALDRIG (før nu) har været inde
og pille i opsætningen af datoformatet.
Resultatet af en manglende brugbar default-indstilling er, at jeg nu er i
gang med at rette alle 3678 personer i min database manuelt! En for en -
samtlige datoer - alle begivenheder. Et sted mellem 16-18.000 rettelser!
Fandens til arbejde!

> Hva gjør du vis du ikke gjør ditt arbeid riktig.
> Hvis du har benyttet format 30.12.2002 i forståelsen av at dette betryr
> 30 desember 2002, da er ikke det noe problem, men har du blandet fugl go
> fisk og også skrevet inn 30.12.2002, 1 juledag 2002, 2002.12.30 slik som
> CHrist har omtalt, da har du en jobb, men ikke uvoreokommelig. Det
> eneste er å holde hodet klart når du skal foreta disse endringene
>
> Men har du vært gjennomgpende i dine arbeider, så vil sikkert både Chris
> og undetegnede gi deg råd på vegen om hva som kan være enklest utvei av
> det problemet du muligens har kommet opp i.

Jeg vil derfor gerne spørge om det ikke var muligt, at få en vejledning
direkte på redigeringsvinduet når dette åbnes.

> Det er rettledning i BK6 som i de fleste andre progra og det er den
> kjente og internasjonale tasten F1
> Uansett program så er det en kode som man bør lære seg å bruke om man
> lurer på noe

Det kunne eksempelvis stå til højre for feltet hvor alder angives.
Det kan vel ikke være det store problem, at gøre brugerne opmærksom på hvad
der er GEDCOM-standard og hvad der kan bruges som datoformat i CEDCOMP.

> GEDCOMP er er spesielt tilegnet fil og det om det og det er ikke noen i
> veien for at det innholdet skal bli riktig. Det var i den filen jeg har
> på 26MB en del feil, hvilket også var feil som overhode ikke kom fra BK,
> men som var tillaget av andre. Dette skal (etterhva jeg forstå være
> ordnet). Jeg har ikke funnet siste versjon av filen og kan derfor ikke
> si noe om kvaliteten i den filen
>
Da flere og flere oplysninger vedr. slægtsforskning bliver tilgængelige på
internettet - hvad jo også denne gruppe vidner om - ville det da være mest
praktisk at have en fælles standard, som alle kan benytte umiddelbart.
Også sådanne som jeg, der ikke lige har været opmærksom på de forskellige
datoformater! At jeg så måske ikke har lyttet ordentlig efter i timen, må
jeg jo selv tage de små smæk for - men, der kommer jo hele tiden nye
vordende slægstforskere til her i gruppen. Hvorfor dog ikke spare dem for en
hulens masse arbejde, besvær og ærgelser!?

> Det man henter ned fra Internet er sikkert OK hvis det er fullført som
> en standard GEDCOM-fil i GEDCOM5.5 og det er derfor heller ikke større
> problemer med å importere dette til BK enn til andre programmer som
> aksepterer GEDCOM5.5

Det kan jo gøres ret nemt og let for nye brugere - en lille vejledning
direkte dér hvor man foretager sine indtastninger.
Nå, men jeg må videre med mine rettelser - har desværre kun nået ca.
halvdelen af alle personer i databasen.

> SLik er desverre situasjonen, hvis man ikke tar for seg manual og
> hjelpefil, hvor oppsettet av programmet også med hensyn til datoformat
> er omtalt

Ønsker alle et rigtigt Godt Nyår - og mange spændende oplevelser og nye fund
i det nye år.

> SLike ønsker kan aldri være protkastet. GODT NYTTÅR

> --
> Otto Jørgensen
> http://home.online.no/~otjoerge/
> http://home.online.no/~otjoerge/bk/


Hej Otto,

Mange tak for dit svar.
Jeg KENDER meget vel til F1 tasten ........ bruger den da ofte i mit
arbejde.

Og nej, jeg har ikke blandet hverken fugl, fisk eller noet andet sammen i
mit arbejde!!!!
Jeg har hele vejen igennem brugt det samme datoformat. Jeg, jeg har også
læst vejledning og alt det andet.
Det der så bare undrer mig, er, at der er så mange som kommer ud i problemer
med datoformatet, når de vil indsende deres GEDCOM-fil til GEDCOMP v/Lars
Kr. Lundin.
BK's default-opsætning er jo IKKE det datofomat, som skal anvendes i
GEDCOMP!
Hvorfor dog ikke blot lave en lille vejledning i det vindue -
redigeringsvinduet - hvor vi jo indtaster vore oplysninger! Det behøver jo
ikke at fylde alverden.
Noget af mit materiale stammer fra et, nu hedgangent, firma der gjorde meget
i slægtsforskning. Den store bog jeg således også har set i, brugte er
datoformat som det jeg tidligere beskrev: dd.mm.åååå - f.eks. 30.12.002 - og
de var så sandelig ikke de eneste.
Jeg har også håndskrevne notater fra omkring 1940 hvor det samme datoformat
anvendes.
Når man sidder med en slægtsforskningsbog, som er lavet af mennesker, som
har dette som deres levevej, vil man jo umiddelbart få den opfattelse, at
det datoformat disse mennesker anvender er det rigtige - ikke sandt!?
Det, der var mit ærinde her, var at fremkomme med et positivt forslag -
således som jeg opfattede at man ønskede - og ikke at blive belært om hvor
dum jeg er. Det ved jeg meget vel i forvejen.
Hvad der også var mit ærinde, var at få nogle af de "gamle" drenge og piger
her, til at forstå, at for nytilkomne er debatten meget indforstået, og der
anvendes termer og ord, som nye brugere ikke fatter en brik af!
Mit anbringende er, at det er de nye brugere her i gruppen, som gerne skulle
føre vores arbejde videre for kommende slægter til gavn og glæde for alle.
Så, hvorfor dog ikke gøre det bare lidt lettere for dem?
For - vi "gamle" her i gruppen sidder vel ikke og laver en masse
slægtsforskning, kigger i gamle bøger, fiser land og rige rundt, bruger en
hulens masse tid på vor interesse - blot for at det hele skal gå i
glemmebogen - vel!?
Og ja, du kan da gerne daske mig med en masse rigtige bebrejdelser over
næsen over at jeg ikke har læst grundigt nok i help og anden vejledning - og
jeg må så stille til pisk ude på gårdspladsen - men, hvad med alle de nye
som er voldsomt ivrige for at komme igang med deres nye
slægtsforskningsprojekter?
Der har jo lige være en serie på TV om slægtsforskning og alle de spændende
ting man kunne opleve i forbindelse hermed.
Tror du virkelig, at unge nye her i gruppen vil sætte megen pris på, at få
læst og påskrevet fra første dag?
Mit indlæg her er ingen kritik af de mange seriøse, dygtige, hjælpsomme og
rare mennesker jeg har mødt her - det er alene en opfordring til at man
måske vil overveje at gøre det lidt lettere for de nye - og også sådanne som
mig selv - og gøre det til en sjov, spændende og nydelsesfuld oplevelse at
være med til at afdække, dyrke og videreføre vore rødder.
Lad mig lige for en sikkerheds skyld pointere, at jeg ellers ikke har meget
andet at udsætte på BK - det eneste jeg kunne tænke mig, var - ud over F1
tasten, som det blev påpeget at jeg skulle bruge noget mere - en mere
brugervenlig vejledning direkte i redigeringsvinduet.
Hvlket program der end måtte være det bedste, ønsker jeg ikke at geråde i
diskussion om - det ved jeg ganske enkelt ikke nok om.

Godt Nytår


Steven

---

Tue, 31 Dec 2002 00:09:20 +0100, in dk.videnskab.historie.genealogi,
"Steven" <ccc98484@vip.cybercity.dk> wrote:

>Ovenstående er jo ganske spændende læsning. Og lærerigt!
>I forbindelse med indsendelse af en GEDCOM-fil til CEDCOMP, fik jeg den
>sørgelige tilbagemelding at mit datoformat var forkert. Det var jo ikke gode
>nyheder!
>Jeg havde brugt datoformatet 30.12.2002 (eksempelvis) og det viste sig IKKE
>at være GEDCOM-standard.

hvis du gjennomgående har brukt det formatet, da er det ikke mer
vanskelig enn at du markere under datoformat under oppsett av BK
Format 12 24.06.1954

Dette er i oversenstemmende med den intasting du sier og du har gjordt
og med dette valget og under forutsetning at du ikke har fjernet
markering for Engelsk konvertering (default verdi)
så skulle du være i land

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

On Mon, 30 Dec 2002 18:21:33 +0100, Otto Jorgensen
<otjoerge@online.no> wrote:

>fisk og også skrevet inn 30.12.2002, 1 juledag 2002, 2002.12.30 slik som
>CHrist har omtalt, da har du en jobb, men ikke uvoreokommelig. Det
>eneste er å holde hodet klart når du skal foreta disse endringene

Skriver man i datofeltet 1. Juledag 2002 så skal Gedcom eksportere
dette som (1. juledag 2002) og i og med at det er pakket inn i
parenteser skal importerende program ikke fortolke datoen i det hele
tatt.

---

Tue, 31 Dec 2002 22:04:48 +0100, in dk.videnskab.historie.genealogi, Alf
Christophersen <alf.christophersen@basalmed.uio.no> wrote:

>On Mon, 30 Dec 2002 18:21:33 +0100, Otto Jorgensen
><otjoerge@online.no> wrote:
>
>>fisk og også skrevet inn 30.12.2002, 1 juledag 2002, 2002.12.30 slik som
>>CHrist har omtalt, da har du en jobb, men ikke uvoreokommelig. Det
>>eneste er å holde hodet klart når du skal foreta disse endringene
>
>Skriver man i datofeltet 1. Juledag 2002 så skal Gedcom eksportere
>dette som (1. juledag 2002) og i og med at det er pakket inn i
>parenteser skal importerende program ikke fortolke datoen i det hele
>tatt.

hvor står det i GEDCOM 5.5 ?

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

On Wed, 01 Jan 2003 12:12:37 +0100, Otto Jorgensen
<otjoerge@online.no> wrote:

>Tue, 31 Dec 2002 22:04:48 +0100, in dk.videnskab.historie.genealogi, Alf
>Christophersen <alf.christophersen@basalmed.uio.no> wrote:
>
>>On Mon, 30 Dec 2002 18:21:33 +0100, Otto Jorgensen
>><otjoerge@online.no> wrote:
>>
>>>fisk og også skrevet inn 30.12.2002, 1 juledag 2002, 2002.12.30 slik som
>>>CHrist har omtalt, da har du en jobb, men ikke uvoreokommelig. Det
>>>eneste er å holde hodet klart når du skal foreta disse endringene
>>
>>Skriver man i datofeltet 1. Juledag 2002 så skal Gedcom eksportere
>>dette som (1. juledag 2002) og i og med at det er pakket inn i
>>parenteser skal importerende program ikke fortolke datoen i det hele
>>tatt.
>
>hvor står det i GEDCOM 5.5 ?
>
side 41 i min udskrift under:
Primitive Elements of the Lineage-Linked Form
DATE:=

DATE_PRHASE:=
(<TEXT>)
TEXT = ethvert udsagn som anvendes som en dato, der ikke kan
oversættes
Med venlig hilsen
Jens V. Olsen

---

Wed, 01 Jan 2003 12:28:11 GMT, in dk.videnskab.historie.genealogi,
jvo@post6.tele.dk (Jens V. Olsen) wrote:

>On Wed, 01 Jan 2003 12:12:37 +0100, Otto Jorgensen
><otjoerge@online.no> wrote:
>
>>Tue, 31 Dec 2002 22:04:48 +0100, in dk.videnskab.historie.genealogi, Alf
>>Christophersen <alf.christophersen@basalmed.uio.no> wrote:
>>
>>>On Mon, 30 Dec 2002 18:21:33 +0100, Otto Jorgensen
>>><otjoerge@online.no> wrote:
>>>
>>>>fisk og også skrevet inn 30.12.2002, 1 juledag 2002, 2002.12.30 slik som
>>>>CHrist har omtalt, da har du en jobb, men ikke uvoreokommelig. Det
>>>>eneste er å holde hodet klart når du skal foreta disse endringene
>>>
>>>Skriver man i datofeltet 1. Juledag 2002 så skal Gedcom eksportere
>>>dette som (1. juledag 2002) og i og med at det er pakket inn i
>>>parenteser skal importerende program ikke fortolke datoen i det hele
>>>tatt.
>>
>>hvor står det i GEDCOM 5.5 ?
>>
>side 41 i min udskrift under:
>Primitive Elements of the Lineage-Linked Form
>DATE:=
>
>DATE_PRHASE:=
>(<TEXT>)
>TEXT = ethvert udsagn som anvendes som en dato, der ikke kan
>oversættes

Jeg har sett det punktet, men har nok tolket dette annerledes, men skal
ta det opp med produsenten.
Slik jeg tolker ditt innelegg betyr det at man i et datofelt da skal
skrive (1 pinsedag 1940) og ikke 1 pinsedag 1940
?

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

Wed, 01 Jan 2003 13:39:41 +0100 skrev Otto Jorgensen:

>>DATE_PRHASE:=
>>(<TEXT>)
>>TEXT = ethvert udsagn som anvendes som en dato, der ikke kan oversættes

Lidt mere præcist oversat: DATE_PHRASE kan anvendes som nævnt når
det er årstallet, der ikke kan oversættes.

> Slik jeg tolker ditt innelegg betyr det at man i et datofelt da skal
> skrive (1 pinsedag 1940) og ikke 1 pinsedag 1940 ?

Så tilfældet 1 pinsedag 1940 kan skrives
DATE 1940 (1 pinsedag)
eller (hvilket mit egen GEDCOM-fil anvender):
DATE 12 MAY 1940 (1 pinsedag)

Den store (og gode) forskel er at en dato-information, der kun står
i parentes ikke forventes oversat af en GEDCOM-fortolker, mens
især det sidste eksempel gør dato-informationen fuldt forståelig
selv for en GEDCOM-fortolker.

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

---

Wed, 01 Jan 2003 16:27:57 +0100, in dk.videnskab.historie.genealogi,
"Lars Kr. Lundin" <news-gi-29@lklundin.dk> wrote:

>Wed, 01 Jan 2003 13:39:41 +0100 skrev Otto Jorgensen:
>
>>>DATE_PRHASE:=
>>>(<TEXT>)
>>>TEXT = ethvert udsagn som anvendes som en dato, der ikke kan oversættes
>
>Lidt mere præcist oversat: DATE_PHRASE kan anvendes som nævnt når
>det er årstallet, der ikke kan oversættes.
>
>> Slik jeg tolker ditt innelegg betyr det at man i et datofelt da skal
>> skrive (1 pinsedag 1940) og ikke 1 pinsedag 1940 ?
>
>Så tilfældet 1 pinsedag 1940 kan skrives
>DATE 1940 (1 pinsedag)
>eller (hvilket mit egen GEDCOM-fil anvender):
>DATE 12 MAY 1940 (1 pinsedag)
>
>Den store (og gode) forskel er at en dato-information, der kun står
>i parentes ikke forventes oversat af en GEDCOM-fortolker, mens
>især det sidste eksempel gør dato-informationen fuldt forståelig
>selv for en GEDCOM-fortolker.
>

Men her er vel så mye sprøsmål om hva brukeren skal skrive.
Han skal ikke skrive DATE
Det er en GEDCOM kode-
Det er viktig at man skiller mellom hva som genereres i en GEDCOM og hva
brukeren skal skrive i sitt datofelt

vi må snart komme så langt at man skiller mellom de ulike opratørenes
virksom.
Brukeren og slektsprogrammet :=))

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

Wed, 01 Jan 2003 16:42:21 +0100 skrev Otto Jorgensen:

> Men her er vel så mye sprøsmål om hva brukeren skal skrive. Han skal
> ikke skrive DATE
> Det er en GEDCOM kode-
> Det er viktig at man skiller mellom hva som genereres i en GEDCOM og hva
> brukeren skal skrive i sitt datofelt

Ja, det er godt du endelig indser det.

For de foregående indlægsskrivere i denne tråd, nemlig undertegnede,
Jens V. Olsen og Alf Christophersen skriver om hvordan parenteser kan
anvendes ifbm. GEDCOM-repræsentation af dato-information.

Jeg ved ikke hvordan du overhovedet kan få den ide at det brugeren
skal indtaste i et dato-felt skal basere sig på hvad der står i
GEDCOM-standarden.

Man kan snarere sige at _hvis_ det brugeren indtaster i et dato-felt
_ikke_ kan forstås af programmet, så skal denne information ifbm.
GEDCOM-eksport angives i parenteser.

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

---

Wed, 01 Jan 2003 17:00:48 +0100, in dk.videnskab.historie.genealogi,
"Lars Kr. Lundin" <news-gi-29@lklundin.dk> wrote:

>Wed, 01 Jan 2003 16:42:21 +0100 skrev Otto Jorgensen:
>
>> Men her er vel så mye sprøsmål om hva brukeren skal skrive. Han skal
>> ikke skrive DATE
>> Det er en GEDCOM kode-
>> Det er viktig at man skiller mellom hva som genereres i en GEDCOM og hva
>> brukeren skal skrive i sitt datofelt
>
>Ja, det er godt du endelig indser det.
>
>For de foregående indlægsskrivere i denne tråd, nemlig undertegnede,
>Jens V. Olsen og Alf Christophersen skriver om hvordan parenteser kan
>anvendes ifbm. GEDCOM-repræsentation af dato-information.
>
>Jeg ved ikke hvordan du overhovedet kan få den ide at det brugeren
>skal indtaste i et dato-felt skal basere sig på hvad der står i
>GEDCOM-standarden.
>
>Man kan snarere sige at _hvis_ det brugeren indtaster i et dato-felt
>_ikke_ kan forstås af programmet, så skal denne information ifbm.
>GEDCOM-eksport angives i parenteser.
>

men ingen av disse sier om brukeren skal legge inn parentesen rundt
aktuelle dato eller om det er programmet som skal legge denne rundt.
Eksemplet med DATE er hentet fra et resultat i GEDCOMfilen men det
forteller ikke hva brukeren skal gjøre.

Dette er en annen tolkning enn hva DIS-Norge har i sin test av
tilsvarende situasjon, hvor feks. 1. pinsedag betraktes som en feil

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

On Wed, 01 Jan 2003 18:39:16 +0100, Otto Jorgensen
<otjoerge@online.no> wrote:

>men ingen av disse sier om brukeren skal legge inn parentesen rundt
>aktuelle dato eller om det er programmet som skal legge denne rundt.
>Eksemplet med DATE er hentet fra et resultat i GEDCOMfilen men det
>forteller ikke hva brukeren skal gjøre.

Det har brukeren ingenting med. Programmet skal gjøre dette hvis det
ikke klarer å tolke datoen hvis det du har skrevet ikke følger angitt
standard (valgt ved oppsett antar jeg)

---

Thu, 02 Jan 2003 02:12:46 +0100, in dk.videnskab.historie.genealogi, Alf
Christophersen <alf.christophersen@basalmed.uio.no> wrote:

>On Wed, 01 Jan 2003 18:39:16 +0100, Otto Jorgensen
><otjoerge@online.no> wrote:
>
>>men ingen av disse sier om brukeren skal legge inn parentesen rundt
>>aktuelle dato eller om det er programmet som skal legge denne rundt.
>>Eksemplet med DATE er hentet fra et resultat i GEDCOMfilen men det
>>forteller ikke hva brukeren skal gjøre.
>
>Det har brukeren ingenting med. Programmet skal gjøre dette hvis det
>ikke klarer å tolke datoen hvis det du har skrevet ikke følger angitt
>standard (valgt ved oppsett antar jeg)

Ref til DIS-norges test

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

On Mon, 30 Dec 2002 17:25:56 +0100, "Steven"
<ccc98484@vip.cybercity.dk> wrote:

>Jeg havde brugt datoformatet 30.12.2002 (eksempelvis) og det viste sig IKKE
>at være GEDCOM-standard.

Mitt poeng er at det må du da få lov til å gjøre så mye du vil. Og
hvis du går lei av det formatet, bør du til enhver tid kunne endre
inputformatet til hva som helst annet, dog ant. ikkepå format
"kirkelig høytidsdag år" da det forutsetter konverteringer som ikke er
enkle og varierer strengt tatt land imellom.

Men uansett om du registrerer dine data på den ene eller andre måte,
så er det programmets eget ansvar å eksportere alle datoer på
Gedcom-formatet. Det har ikke noe med input-delen å gjøre i det hele
tatt. Omdu skriver 1. JAN 1707, 01.01.1707, 1707.01.01 så skal uansett
Gedcom-eksporten skrive dette som 1 JAN 1707. Det har brukeren
ingenting med å gjøre. Og uansett språk skal Gedcom skrive 12 DEC 1707
hvis dato er skrevet inn som 1707.12.12 eller 12.12.1707 eller
whatsoever.

Det skjer altså tydeligvis ikke i alle sammenhenger.

---

Tue, 31 Dec 2002 22:01:43 +0100, in dk.videnskab.historie.genealogi, Alf
Christophersen <alf.christophersen@basalmed.uio.no> wrote:

>On Mon, 30 Dec 2002 17:25:56 +0100, "Steven"
><ccc98484@vip.cybercity.dk> wrote:
>
>>Jeg havde brugt datoformatet 30.12.2002 (eksempelvis) og det viste sig IKKE
>>at være GEDCOM-standard.
>
>Mitt poeng er at det må du da få lov til å gjøre så mye du vil. Og
>hvis du går lei av det formatet, bør du til enhver tid kunne endre
>inputformatet til hva som helst annet, dog ant. ikkepå format
>"kirkelig høytidsdag år" da det forutsetter konverteringer som ikke er
>enkle og varierer strengt tatt land imellom.
>
>Men uansett om du registrerer dine data på den ene eller andre måte,
>så er det programmets eget ansvar å eksportere alle datoer på
>Gedcom-formatet. Det har ikke noe med input-delen å gjøre i det hele
>tatt. Omdu skriver 1. JAN 1707, 01.01.1707, 1707.01.01 så skal uansett
>Gedcom-eksporten skrive dette som 1 JAN 1707. Det har brukeren
>ingenting med å gjøre. Og uansett språk skal Gedcom skrive 12 DEC 1707
>hvis dato er skrevet inn som 1707.12.12 eller 12.12.1707 eller
>whatsoever.
>
>Det skjer altså tydeligvis ikke i alle sammenhenger.


og skriver du 03.04.1990 eller 04.03.1990 så vet man dermed helt sikkert
om det er 3 april eller 4 mars.
Hvem forteller programmet hvordan dette skal tolkes ?

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

On Wed, 01 Jan 2003 03:40:00 +0100, Otto Jorgensen
<otjoerge@online.no> wrote:

>og skriver du 03.04.1990 eller 04.03.1990 så vet man dermed helt sikkert
>om det er 3 april eller 4 mars.
>Hvem forteller programmet hvordan dette skal tolkes ?

Det er oppsettet i programmet i det øyeblikk du taster inn datoen. Har
du satt opp datoformat dd.mm.yyyy og skriver03.04.1990 så er datoen 3.
april 1990 og X dager siden år 0 (har ikke kalkulator som regner ut
dette her og nå) som man bør lagre. Når man skriver ut datoer, så
konverterer man X til den datorepresentasjon man ønsker under
utskrift, f.eks. dd MMM yyyy og får da ut 03 APR 1990 (mens
input-format er et helt annet)

---

Wed, 01 Jan 2003 18:30:19 +0100, in dk.videnskab.historie.genealogi, Alf
Christophersen <alf.christophersen@basalmed.uio.no> wrote:

>On Wed, 01 Jan 2003 03:40:00 +0100, Otto Jorgensen
><otjoerge@online.no> wrote:
>
>>og skriver du 03.04.1990 eller 04.03.1990 så vet man dermed helt sikkert
>>om det er 3 april eller 4 mars.
>>Hvem forteller programmet hvordan dette skal tolkes ?
>
>Det er oppsettet i programmet i det øyeblikk du taster inn datoen. Har
>du satt opp datoformat dd.mm.yyyy og skriver03.04.1990 så er datoen 3.
>april 1990 og X dager siden år 0 (har ikke kalkulator som regner ut
>dette her og nå) som man bør lagre. Når man skriver ut datoer, så
>konverterer man X til den datorepresentasjon man ønsker under
>utskrift, f.eks. dd MMM yyyy og får da ut 03 APR 1990 (mens
>input-format er et helt annet)

Det var jo hyggelig, hvorfor skal det være annerledes å sette opp
formatet i BK enn i det programmet du her viser til.
I det ene øyeblikket kritiserer du at det ikke er riktig i BK.
Jeg henviser til oppsett av BK og det neglisjeres
Og så plutselig blir det viktig med oppsettet av programmet.

Dette begynner virkelig å bli originalt.

Tor du bør prøve BK litt før du uttaler deg vider.
Sett opp programmet og gjør det slik du skal gjøre :=))



--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

On Wed, 01 Jan 2003 18:52:07 +0100, Otto Jorgensen
<otjoerge@online.no> wrote:

>Dette begynner virkelig å bli originalt.

Hvorfor det? Detg som er essensielt er at datoen skal konverteres til
et format som programmet bruker, TOTALT uavhengig av hva bruker oppgir
som input-format, og uavhengig av hva man oppgir som outputformat. Da
slipper man å måtte gjøre denne konverteringen på alle datoer i
databasen i det øyeblikket man endrer format og man risikerer å komme
halvveis i konvertering, så går strømmen og halvparten av datoer har
plutselig feil format.
Konverteres det umiddelbart, så vil man være helt uavhengig av noe som
helst.

---

Thu, 02 Jan 2003 02:12:47 +0100, in dk.videnskab.historie.genealogi, Alf
Christophersen <alf.christophersen@basalmed.uio.no> wrote:

>On Wed, 01 Jan 2003 18:52:07 +0100, Otto Jorgensen
><otjoerge@online.no> wrote:
>
>>Dette begynner virkelig å bli originalt.
>
>Hvorfor det? Detg som er essensielt er at datoen skal konverteres til
>et format som programmet bruker, TOTALT uavhengig av hva bruker oppgir
>som input-format, og uavhengig av hva man oppgir som outputformat. Da
>slipper man å måtte gjøre denne konverteringen på alle datoer i
>databasen i det øyeblikket man endrer format og man risikerer å komme
>halvveis i konvertering, så går strømmen og halvparten av datoer har
>plutselig feil format.
>Konverteres det umiddelbart, så vil man være helt uavhengig av noe som
>helst.

det er originalt fordi jeg hele tiden henviser til oppsettet som ikke er
av interesse fra debatantene, men plutselig i forrige innlegg er
oppsettet viktig.

Det er ingen som har nektet for at innputkontrollen av dato kunne vært
bedre, men debatantene blander sammen innputkontrollen og
GEDCOMgenereringen og derfor har dette vært en diskusjon på to ulike
plan.
Noen bruker innputen til å omtale GEDCOMgenereringen, mens det som fra
flere hold burde vært konsentrert om innput kontrollen av datoen som jo
også er forutsetning. Og med riktig oppsett av programmet og konsekvens
bruk av det man har satt, skulle ikke det oppstår mange feil.
Det er heller ikke nektet det for at dagens test av data er meget enkel.
Det står også med disse ord beskrevet i hjelpefilen.

Jeg diskuterer ikke hva som produsenten burde ha gjordt med sin database
eller ei. Jeg konsentrerer med det faktum at programmet eksisterer og vi
som brukere skal legge inn data og ha ut data, hvordan den enkelte
produsent ordner opp i programmets interne forhold er i grunnen
likegyldig.

Jeg føler det mer viktig å arbeide for at utput og innput blir enklest
mulig og riktig.

Dermed avslutter jeg hele denne tråden som har blandet fugl og fisk.

--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

Fri, 27 Dec 2002 11:39:54 +0100, in dk.videnskab.historie.genealogi, Alf
Christophersen <alf.christophersen@basalmed.uio.no> wrote:

>Problemet originalt var vel at BK ikke kunne konvertere i det hele
>tatt. Skulle man få ut datoer på Gedcom-format så måtte de skrives på
>Gedcom-format. dd.mm.yyyy eksporteres som det, mm.dd.yyyy eksporteres
>eksakt slik det er skrevet, tekstlig og dd MMM yyyy ble eksportert som
>det. Intet forsøk som i andre program om å endre 3.4.1777 til antall
>dager siden år 0 eller siden 1.1.1900 (altså et negativ antall dager)
>som også¨BK burde ha benyttet fra første dag, men muligens ikke mulig
>i databasesystemet som benyttes i BK.

BK har minst de siste 10 år hatt innebygget funskjon som har gjordt det
mulig å konvertere databasen. I seg selv er det likegyldig hvordan BK
har i årene løp bygget opp sin interne database.
Det finnes ikke krav om hvordan databasen til noen program skal bygges
opp.
Det som er deinferte krav er tilsfredstillelse av GEDCOMformatet og for
dagens versjon BKW6.1.10 tilsfredstiller dette formatet i henhold til
GEDCOM 5.5 og det uansett hvordan databasen er bygget opp under en
forutsetning og det er at brukerne også registrerer data i henhold til
det oppsettet de selv setter for bruk av programmet.
En import som også tilfredstiller GEDCOM.5.5 er ikke problematisk å
importere til BK6.1.10

Har det tidligere vært feil i deler av GEDCOMimport og export så er det
rettet opp og det er også et ansvar til at brukerne har med seg de
rettinger som er tilgjengelig og disse oppdateringene er også
tilgjengelig for gratis nedlasting og oppdatering av programmet på
sammen linje som det har vært i mer enn 10 år. Gratis ut uten ekstra
kostnader for brukerne av BK, se side
http://ourworld.compuserve.com/homepages/Brothers_Keeper/


--
Otto Jørgensen
http://home.online.no/~otjoerge/
http://home.online.no/~otjoerge/bk/

---

LKL> @User-Agent: Pan/0.11.2 (Unix)
LKL> @NNTP-Posting-Date: Fri, 06 Dec 2002 15:53:24 MET
LKL> From: "Lars Kr. Lundin" <news-gi-20@lklundin.dk>

LKL> Thu, 05 Dec 2002 18:09:46 +0100 skrev Leif Thor Olsen:

>> Kunne du ikke offentligg*re hvilke programmer der ikke lever op til
>> standarden
>> og hvor de ikke g*r det?

LKL> Jeg har modtaget GEDCOM-filer med ugyldig DATE-information fra
LKL> f¢lgende programmer:

LKL> WINFAM 6.02
LKL> FTW (Family Tree Maker for Windows) 10.0
LKL> BROSKEEP (Brothers Keeper) 6.1.8
LKL> PAF (Personal Ancestral File) 5.2.18.0
LKL> CFTREE (Cumberland Family Tree) CFTREE Windows Ver Pro 3.12
LKL> FamilyOrigins (Family Origins(R) for Windows) 8.0
LKL> TMG (The Master Genealogist) 4.0c
LKL> Legacy 4.0

LKL> og givetvis mange andre programmer. Formentlig alle.

LKL> Ovenstående programmer er så vidt jeg ved kommercielle.
LKL> Derfor vil jeg ikke bruge tid på at komme med en liste
LKL> over hvad hver producent burde rette i sit produkt.

>> Er der overhovedet nogen af indsenderne til GEDCOMP der bruger The
>> Master Genealogist, som skulle være suverænt?

LKL> Se http://www.lklundin.dk/gedcomp/sw_stat.asc .

LKL> Altså en halv snes stykker.


Tak for det, Lars. Altså problemer med alle programmer! Så kan vi ligeså
godt
allesammen gå over til Famdex, der så vidt jeg ved ikke kan lave Gedcom.

På den anden side jeg har trods alt fået næsten 50 henvendelser fra
GEDCOMP, så
noget får jeg trods alt ud af det med mit fejlbehæftede program.

Forresten hvad med Cramps og Lifelines?

--
Mvh. Leif - leif@nightcall.dk

---

Sat, 07 Dec 2002 12:46:02 +0100 skrev Leif Thor Olsen:

> LKL> Jeg har modtaget GEDCOM-filer med ugyldig DATE-information fra
> LKL> f¢lgende programmer:

> LKL> og givetvis mange andre programmer. Formentlig alle.

>
> Tak for det, Lars. Altså problemer med alle programmer! Så kan vi ligeså
> godt
> allesammen gå over til Famdex, der så vidt jeg ved ikke kan lave Gedcom.
>

Nu gav jeg et _meget_ forenklet svar på et ellers omfattende spørgsmål.

Sagen er nemlig at nogle programmer har mange problemer med
GEDCOM-eksport, mens andre kun mangler detaljer. Eksempel:

GEDCOM-standarden siger at i en dato skal månedsdagen være
et tal, som faktisk findes i den pågældende måned.

Så et program dumper hvis det skriver datoen
31 SEP 1700

Men det er meget sværere end det at leve op til definitionen.
Min syretest er:

20 FEB 1700 er som bekendt _ikke_ en gyldig dato - i Danmark.
Omvendt er 30 FEB 1712 en gyldig dato i Sverige (de havde 2
skuddage det år). Udover GEDCOMP's kontrol-program har jeg ikke
mødt nogen programmer, der overhovedet tænker på denne specielle
variation af skuddage (ifbm. overgangen fra Juliansk til Gregoriansk
kalender).

Men f.eks. TMG har en god GEDCOM-eksport. Det har Cumberland Family Tree
også. På et tidspunkt gjorde jeg opmærksom på et mindre problem med
Cumberland Family Tree, og det er vist rettet nu. Hvilket er en positiv
reaktion.

> På den anden side jeg har trods alt fået næsten 50 henvendelser fra
> GEDCOMP, så
> noget får jeg trods alt ud af det med mit fejlbehæftede program.

Det er da rart at høre.

> Forresten hvad med Cramps og Lifelines?

Jeg har endnu ikke set en GEDCOM-fil fra Lifelines.

De eneste problemer jeg har set med GRAMPS er de ovenfor nævnte,
(og jeg har for et par dage siden gjort den udviklingsansvarlige
opmærksom på det).

Når man sammenligner programmers antal af kendte fejl, så bør man
tage programmets alder i betragtning. GRAMPS er et meget nyt program,
som allerede har en god GEDCOM-eksport. Andre programmer har haft
GEDCOM-eksport siden DOS-dagene, og har stadig mange fejl. Og det
er ikke imponerende.

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

---

Fri, 06 Dec 2002 15:53:23 +0100, skrev Lars Kr. Lundin:

>Thu, 05 Dec 2002 18:09:46 +0100 skrev Leif Thor Olsen:
>
>> Kunne du ikke offentligg¢re hvilke programmer der ikke lever op til
>> standarden
>> og hvor de ikke g¢r det?
>
>Jeg har modtaget GEDCOM-filer med ugyldig DATE-information fra
>følgende programmer:
>
[klip]
>
>og givetvis mange andre programmer. Formentlig alle.

- hvilket vel dybest set kun tydeliggør, at GEDCOM er et råddent
format med alt for mange fejl- og fortolkningsmuligheder? At formatet
så også forlængst er afgået ved døden og dermed aldrig vil blive
vedligeholdt og opdateret, sætter fokus på et stigende problem, nemlig
udvikling af en ny og tidssvarende standard.

Venlig hilsen
Kurt Hansen

---

Sun, 08 Dec 2002 06:54:24 +0100 skrev Kurt Hansen:

> - hvilket vel dybest set kun tydeliggør, at GEDCOM er et råddent format
> med alt for mange fejl- og fortolkningsmuligheder? At formatet så også
> forlængst er afgået ved døden og dermed aldrig vil blive vedligeholdt og
> opdateret, sætter fokus på et stigende problem, nemlig udvikling af en
> ny og tidssvarende standard.

Det er jeg uenig i. De GEDCOM-fejl jeg typisk ser kan ikke
skyldes tolknings-muligheder i standarden. Som nævnt har flere
programmer kun små-problemer, som ofte rettes hen ad vejen.
De resterende programmers udviklere må være enten teknisk dårlige
eller uden respekt for brugere, der ønsker et godt produkt.

GEDCOM-formatet er på trods af alle sine mangelfulde
implementeringer de fakto standard.
Og det holder nok en god tid endnu.

Det er ukompliceret (og allerede prøvet) at omformulere
GEDCOM-standarden til XML. Problemet er at der er en del (mere
specielle) forhold, som slet ikke kan udtrykkes i GEDCOM. Så
der er en diskussion igang om de mangler, i højere grad end
om selve formatet.

Et simpelt eksempel er ægteskab mellem to personer af samme
køn. Dette forekommer i vore dage, men kan ikke udtrykkes i
GEDCOM - muligvis pga. standardens religiøse ophav.

Et mere vanskeligt eksempel er angivelsen af rækkefølgen af
børn i en familie. Standarden siger at de skal ordnes efter
alder. Men hvordan sorterer man dem hvis aldrene er ukendte?
Eller hvis man har modstridende aldersoplysninger?

Interesserede kan skifte til soc.genealogy.computing
se f.eks. tråden 'GEDCOM XML'.

-Lars Lundin.
PS. Jeg vil egentlig hellere have en tilbagemelding på mit
indlæg om danske kancelli end om mit ditto om GEDCOM.
--
GEDCOMP: En omfattende og gratis database for slægtsforskere med
interesse i Danmark: http://www.lklundin.dk/gedcomp/

---

"Lars Kr. Lundin" <news-gi-20@lklundin.dk> skrev:
08 Dec 2002 11:11:25 +0100 i dk.videnskab.historie.genealogi

>....Så der er en diskussion igang om de mangler, i højere grad end
>om selve formatet.
>Et simpelt eksempel er ægteskab mellem to personer af samme
>køn.
I Gedcom kan man udmærket knytte sådan to personer af samme køn
sammen. Det gør man med begrebet 'ASSO' (Associates), evt med en
beskrivende 'TYPE', f.eks. Partnerskab.
Man bør vel iøvrigt ikke kalde en sådan forbindelse for ægteskab,
men registreret partnerskab.

Der kan måske være det problem med begrebet Ægteskab (Marriage)
at terminologien på både Dansk og Engelsk er uklar med hensyn til
hvad der forstås ved Ægteskab (Marriage).
Ægteskab betyder nemlig ikke altid og for alle helt det samme som
kirkelig eller borgerlig Vielse.
I Gedcom defineres Marriage slet ikke som Vielse, men helt
generelt som:
'... an event of creating a family unit of a man and a woman ..'
En 'family unit' er i generelle termer
'... a family created by virtue of the birth of a child to its
biological father and mother.'
Det vil på Dansk blot sige et par, der får et barn sammen, og det
kræver rent biologisk to forældre af hver sit køn.

Gedcom kræver ikke, at der til oprettelsen af et sådant par
knyttes nogen særlig begivenhed (vielse). Parret kan for så vidt
rent tilfældigt have truffet hinanden på Halmtorvet, og det
behøver man ikke at fortælle.

Det er måske en mangel ved Gedcom, at der udover vielse (og
trolovelse) ikke findes udtryk for hvordan parret er dannet før
fødslen finder sted. Måske tilfældigt møde, gode vennner i nogle
år, boede sammen, delte seng og bord, eller lignende. Her mangler
både Engelsk og Dansk præcise betegnelser.
Nogle programmer afhjælper dette med deres egne udtryk, ellers er
man henvist til at beskrive det på anden måde, f.eks. i noterne.
Enkelte programmer påtvinger udtrykket Ægteskab/Vielse i alle
tilfælde, dette er følgelig forkert, og et eksempel på fejlagtig
brug af Gedcom.

Erik Helmer Nielsen

---

On Sun, 08 Dec 2002 11:11:25 +0100, "Lars Kr. Lundin"
<news-gi-20@lklundin.dk> wrote:

>Et simpelt eksempel er ægteskab mellem to personer af samme
>køn. Dette forekommer i vore dage, men kan ikke udtrykkes i
>GEDCOM - muligvis pga. standardens religiøse ophav.

Problemet er vel heller at man blander egentlig to begivenheter til en
begivenhet, sosiale ekteskap hvor dette kan opprettes mellom både
heterofile og homofile par (det siste gir ikke noe avkom av biologiske
årsaker) og gjentatte biologiske befruktninger hvor to personer blir
genetiske foreldre en eller flere ganger

Foreslår derfor at det i en XML-sak skilles mellom ekteskap (sosial
beguvenhet) og gruppebegrep for en rekke vellykkede befruktninger som
ender opp med levende fødte barn.

F.eks. MARR for sosiale forhold hvor begge kan være av samme kjønn og
COIT for befruktningen mellom Ysin x- eller y.kromosom og X sitt x-
eller x-kromosom (to mulige individer fra hver person) (som ikke
trenger å være gift i kirken i det hele tatt)

---

Kurt Hansen <kurt@towle.dk> skrev:
08 Dec 2002 06:54:24 +0100 i dk.videnskab.historie.genealogi

>- hvilket vel dybest set kun tydeliggør, at GEDCOM er et råddent
>format med alt for mange fejl- og fortolkningsmuligheder? ...
En så bastant påstand bør du dokumentere med nogle eksempler,
ellers er den intet værd.
Jeg kan ikke se hvilke fejl, du påstår der er i Gedcom.
Der er måske nok nogle programmører af slægtsprogrammer, der
'fortolker' den sjusket, fordi de ikke sætter sig ordentlig ind i
den, men det er så deres fejl.

> At formatet så også forlængst er afgået ved døden ....
Der er tusinder af brugere, der hver dag med stort udbytte bruger
Gedcom, så den påstand er der overhovedet ikke belæg for.

>... sætter fokus på et stigende problem, nemlig
>udvikling af en ny og tidssvarende standard.
Problemet er efter min mening ikke Gedcom standarden, men mange
slægtsprogrammers ringe evne til at bruge mulighederne i den
rigtigt. Det problem bliver ikke anderledes med en anden
standard, som nok også bliver mere kompliceret.

Erik Helmer Nielsen

---

Sun, 08 Dec 2002 22:22:13 +0100, skrev Erik Helmer Nielsen:

>Kurt Hansen <kurt@towle.dk> skrev:
>08 Dec 2002 06:54:24 +0100 i dk.videnskab.historie.genealogi
>
>>- hvilket vel dybest set kun tydeliggør, at GEDCOM er et råddent
>>format med alt for mange fejl- og fortolkningsmuligheder? ...
>
>En så bastant påstand bør du dokumentere med nogle eksempler,
>ellers er den intet værd.

Da jeg skrev det var det i den sikre overbevisning, at jeg i
påkommende tilfælde kunne hente snesevis af tilfælde i mit email-arkiv
fra en nordisk GEDCOM-mailinglist der var aktiv i en relativt kort
periode for et års tid siden. Nu ER det så blevet et "påkommende"
tilfælde, men ak..... nu viser det sig at jeg forlængst har slettet
disse gamle mails. Frem for at begynde at citere efter hukommelsen og
dermed uden dokumentation, vælger jeg at trække min påstand tilbage.

>> At formatet så også forlængst er afgået ved døden ....
>
>Der er tusinder af brugere, der hver dag med stort udbytte bruger
>Gedcom, så den påstand er der overhovedet ikke belæg for.

Ach, Helmer, du ved jo godt hvad jeg mener. Mormonerne har for et par
år siden meddelt, at de ikke længere vil udvikle og vedligeholde
standarden og det er DET jeg mener, når jeg siger at formatet er dødt.
At det så stadig bruges - delvist i mangel af nyere og bedre - er en
helt anden sag.

>>... sætter fokus på et stigende problem, nemlig
>>udvikling af en ny og tidssvarende standard.
>
>Problemet er efter min mening ikke Gedcom standarden, men mange
>slægtsprogrammers ringe evne til at bruge mulighederne i den
>rigtigt. Det problem bliver ikke anderledes med en anden
>standard, som nok også bliver mere kompliceret.

Det er en god, gammel regel for allehånde formidlere, at hvis en
instruktion bliver opfattet og omsat forskelligt af stort set alle der
anvender den, er den i bedste fald mangelfuldt og slapt udformet - i
værste fald værdiløs.

Venlig hilsen
Kurt Hansen

---

Mon, 09 Dec 2002 08:06:38 +0100 skrev Kurt Hansen:

> Det er en god, gammel regel for allehånde formidlere, at hvis en
> instruktion bliver opfattet og omsat forskelligt af stort set alle der
> anvender den, er den i bedste fald mangelfuldt og slapt udformet - i
> værste fald værdiløs.

Når heltallene fra 1 til 30 er gyldige månedsdage i november,
så kan det ikke være så svært at forstå at d. 0. november 2002
ikke er en gyldig dato.

GEDCOM-standardens indeholder simple og præcist formulerede regler,
og de regler er som sagt ikke fuldt af adskillige programmører.

Det kan ikke lægges standardens ophav til last.

Grunden til de mange ringe GEDCOM-implementeringer skyldes måske
snarere at ingen væsentlige økonomiske interesser afhænger af en
korrekt GEDCOM-implementering. Der er jo ingen stater, banker
eller andre store og pengestærke virksomheder der skal bruge en
korrekt GEDCOM-fil. Og så kan programmørerne jo langt nemmere
slippe godt fra at sjuske.

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

---

"Lars Kr. Lundin" <news-gi-20@lklundin.dk> skrev i en meddelelse
news:pan.2002.12.04.23.56.09.259674.11714@lklundin.dk...
>
> Du ønsker et program til læsning af person-oplysningerne i en
> såkaldt bingo-email, som GEDCOMP udsender titusindvis af.
>
> En GEDCOMP-bruger har for flere år siden skrevet sådan et program.
>
> Jeg har aldrig prøvet programmet og har længe glemt
> hvem der skrev det. Men måske nogen her kan hjælpe?
>
ja jeg har selv brugt programmet engang, desværre er det blevet slettet, der
må da være en eller anden der har det.

Steen

---

On Wed, 4 Dec 2002 19:36:41 +0100, "Steen Mogensen"
<dsl52801@vip.cybercity.dk> wrote:

>på er tidspunkt mener jeg at have læst her i gruppen om et program til
>indlæsning af gedcomp filer fra Lars Lundin, er det rigtigt og hvor kan jeg
>finde det ?
>
http://home6.inet.tele.dk/jvo/gedcom/gedcomp.htm

Med venlig hilsen
Jens V. Olsen