---

En alternativ måde at arbejde med GEDCOM standarden på, kunne være, at
opstille en nordisk gedcomfil, med alle de tags og
kombinationsmuligheder i, som vi ønsker alle slægtsprogrammer skal
kunne håndtere.

Der kan evt. opstilles 3 forskellige nordiske gedcomfiler, såsom en
minimums gedcom, en standard gedcom og endelig den store forkromede
model, der afspejler alle vores ønsker/krav fuldt ud.

Guleroden til slægtsprogramsproducenterne vil så være, at de kan
reklamere med at være kompatibel med GEDCOM-Nordic i klasse I,
klasse II eller klasse III.

mvh
Arne

---

On 2004-03-18 02:05:07 +0100, aafe <intet@svar.dk> said:

> En alternativ måde at arbejde med GEDCOM standarden på, kunne være, at
> opstille en nordisk gedcomfil, med alle de tags og
> kombinationsmuligheder i, som vi ønsker alle slægtsprogrammer skal
> kunne håndtere.

Jeg synes bare de burde understøtte hele molevitten. Det kan vel ikke være
så svært, jeg ved der er programmer der gør det (GEDitCOM til MacOS 9/X er
ét).

Det er lidt tabt at de efter så mange år stadig ikke har fået taget sig
sammen til at følge standarden...

Men nu må jeg vidst hellere lukke for galden :)

mvh
Mikkel Eide Eriksen

---

On Thu, 18 Mar 2004 02:14:43 +0100, Mikkel Eide Eriksen wrote:

>Jeg synes bare de burde understøtte hele molevitten. Det kan vel ikke være
>så svært, jeg ved der er programmer der gør det (GEDitCOM til MacOS 9/X er
>ét).

Ja, hvis du med hele molevitten mener, at gedcom 5.5 standarden skal
understøttes fuldt ud, er vi jo enige om det. Men, sagen er, at de
alle hævder at kunne håndtere gedcom 5.5 standarden, hvor de i
virkeligheden kun kan håndtere et subset af standarden, og hvor de i
nogle tilfælde tolker visse dele af standarden forkert.

>Det er lidt tabt at de efter så mange år stadig ikke har fået taget sig
>sammen til at følge standarden...

Der er ikke rigtig noget der for alvor motiverer dem til at følge
standarden fuldt ud. Det kan måske argumenteres, at den eneste grund
til at følge standarden fuldt ud, skulle være for at gøre det nemmere
at skifte program via en en gedcom eksport/import, og det mener de
måske ikke er i deres interesse.

med venlig hilsen

Arne

---

On 2004-03-18 10:54:00 +0100, aafe <intet@svar.dk> said:

> On Thu, 18 Mar 2004 02:14:43 +0100, Mikkel Eide Eriksen wrote:
>
> >Jeg synes bare de burde understøtte hele molevitten. Det kan vel ikke
være >så svært, jeg ved der er programmer der gør det (GEDitCOM til MacOS
9/X er >ét).
>
> Ja, hvis du med hele molevitten mener, at gedcom 5.5 standarden skal
> understøttes fuldt ud, er vi jo enige om det. Men, sagen er, at de
> alle hævder at kunne håndtere gedcom 5.5 standarden, hvor de i
> virkeligheden kun kan håndtere et subset af standarden, og hvor de i
> nogle tilfælde tolker visse dele af standarden forkert.

Nu i eksemplet GEDitCOM (www.geditcom.com), så har jeg aldrig haft
problemer med import af velformede gedcom-filer, ej heller med eksport. På
deres side kan du se hvor meget de går op i det...

> >Det er lidt tabt at de efter så mange år stadig ikke har fået taget sig
>sammen til at følge standarden...
>
> Der er ikke rigtig noget der for alvor motiverer dem til at følge
> standarden fuldt ud. Det kan måske argumenteres, at den eneste grund
> til at følge standarden fuldt ud, skulle være for at gøre det nemmere
> at skifte program via en en gedcom eksport/import, og det mener de
> måske ikke er i deres interesse.
> med venlig hilsen

Det er måske sandt nok, men det er vel i deres interesse at brugerne får en
god oplevelse med programmet, for eksempel i forbindelse med sider som
gedcomp, gencircles, rootsweb, etc. Jeg ville blive lidt træt i ansigtet
hvis det viste sig at det program jeg brugte ikke kunne lave filer der
kunne uploades til disse sider...

mvh
Mikkel Eide Eriksen

---

On Fri, 19 Mar 2004 01:11:44 +0100, Mikkel Eide Eriksen wrote:

>Det kan vel ikke være
>så svært, jeg ved der er programmer der gør det (GEDitCOM til MacOS
>9/X er ét).

Det slår mig, at du må være virkelig godt inde i GEDCOM strukturen, og
ligge inde med en stor *detailviden* om GEDCOM test, som jeg håber du
vil lade komme vores projekt til gode.

Viden om perfekte programmer har vi ikke brug for. I en mindre end
perfekt verden, er det nemlig ingen garanti at have det perfekte
program, hvis man vil kommunikere med den mindre perfekte omverden. Og
GEDCOM er jo et transmissionsmiddel, der - som sådan - skal kunne
bruges af alle slægtsprogrammer.

>Det er lidt tabt at de efter så mange år stadig ikke har fået taget sig
>sammen til at følge standarden...

Jo, men sagen er, at de allesammen egentlig mener, at lige netop deres
program er perfekt, samt at problemer med kompabiliteten altid ligger
hos konkurrenterne. Og ofte bakkes de jo temmelig enthusiastisk op af
deres enthusiastiske brugere, der nemlig også mener, at det er de
andre programmer, der er noget i vejen med.

>Det er måske sandt nok, men det er vel i deres interesse at brugerne får en
>god oplevelse med programmet, for eksempel i forbindelse med sider som
>gedcomp, gencircles, rootsweb, etc. Jeg ville blive lidt træt i ansigtet
>hvis det viste sig at det program jeg brugte ikke kunne lave filer der
>kunne uploades til disse sider...

Ja, det har du søreme ret i, at det *er* i producenternes interesse at
deres brugere får en god oplevelse med programmet. Men, det virker nu
også, som om brugerne stadig får en god oplevelse med programmerne,
selvom disse måske kun nødstørftigt opfylder GEDCOM standarden.

Det er imidlertid også i producenternes interesse, at spare dyr
udviklingstid, istedet for at komme ud i alle hjørner og kroge med
detaljer, som måske kun er til glæde for ganske få brugere. Og, derfor
venter producenterne måske med at gøre noget ved dit og dat, indtil
deres kunder smider problemerne på bordet.

med venlig hilsen

Arne

---

On 2004-03-19 07:39:39 +0100, aafe <intet@svar.dk> said:

> On Fri, 19 Mar 2004 01:11:44 +0100, Mikkel Eide Eriksen wrote:
>
> >Det kan vel ikke være
> >så svært, jeg ved der er programmer der gør det (GEDitCOM til MacOS
> >9/X er ét).
>
> Det slår mig, at du må være virkelig godt inde i GEDCOM strukturen, og
> ligge inde med en stor *detailviden* om GEDCOM test, som jeg håber du
> vil lade komme vores projekt til gode.

Det er nok så meget sagt. Jeg kan i store træk læse og forstå GEDCOM, men
det er så også det. Men jeg synes da at idéen GEDCOM-Nordic har potentiale
og vil gerne hjælpe hvor jeg kan komme til det. Bare ikke lige nu -- jeg
skriver projekt til skolen :)

En hurtig indskydelse: Man kunne eventuelt bruge kongefamilien til
GEDCOM-Nordic.

mvh
Mikkel Eide Eriksen

---

Mikkel Eide Eriksen <carthagtuek@softhome.net> skrev Fri, 19 Mar 2004
01:11:44 +0100


>Det er måske sandt nok, men det er vel i deres interesse at brugerne får en
>god oplevelse med programmet, for eksempel i forbindelse med sider som
>
Producenterne har først og fremmest en interesse i at bevise, at netop
deres program kan noget som andre programmer ikke kan. Og derfor laver
de helere end gerne gedcom-filer som andre programmer ikke forstår
(Microsoft-syndromet om igen).

Mht. Upoload til de store amerikanske databaser så har nogle programmer
jo dette indbygget, stort set uden at brugeren har kontrol over havd der
bliver uploadet og i hvilken form. Et andet meget udbredt program kan
kun lave web-sider til oplægning på producentens egen Site, igen uden at
brugeren har nævneværdig indflydelse på form og indhold.

Flere af de store programmer tillader eksport af datoer i et ikke
entydigt format, og ved import læser de datoer som fanden læser biblen.

Ikke alle programmer kan håndtere simple ting som 'BEF', 'AFT', 'ABT'
korrekt, men til gengæld kan man indsætte videosekvenser af op til flere
minutters varighed. )

Og sådan kunne man blive ved. Fakta er (IMHO) at producenterne er
*meget* lidt interesserede i gedcom som en fælles standard - men gerne
bruger den som en platform til at præsentere hvad lige netop deres
program kan, og som andre ikke kan.!

Dette problem kan (IMHO) kun løses, enten ved et masivt brugerpres og
det er nok urealistisk, eller også ved en egentlig international
standard a'la ISO eller lign.

>gedcomp, gencircles, rootsweb, etc. Jeg ville blive lidt træt i ansigtet
>hvis det viste sig at det program jeg brugte ikke kunne lave filer der
>kunne uploades til disse sider...
>
Selve ideen med gedcom er jo at kunne udveksle filer mellem forskellige
programmer og at kunne skifte til et andet program.

Og set fra producenterens synspunkt er dette jo helt og aldeles
unødvendigt. Folk kan jo bare bruge netop deres program - så er der ikke
alle disse problemer!

Men sålænge vi står her i vadesteddet, gedcom5.5 er uklart formuleret og
næppe ordentligt implementeret i eet eneste program, og en ny standard
lader vente på sig[1], så kunne det måske godt være en ide med et
nordisk initiativ i retning af det Arne E. foreslår.

[1].
Hvorvidt er sådan ny standard er en gedcom6.0 eller noget xml-haløj er
for mig at se inderligt ligegyldigt. Xml er bare en anden måde måde at
definere de samme ting på.


--
mvh, A:\Feldborg

Folketællinger Hammerum og Bølling herreder, kirkebøger Hammerum herred
http://www.haunstrup.dk/feldborg/genealogi/download/

---

aafe skrev:
> On Thu, 18 Mar 2004 02:14:43 +0100, Mikkel Eide Eriksen wrote:
>
>
>>Jeg synes bare de burde understøtte hele molevitten. Det kan vel ikke være
>>så svært, jeg ved der er programmer der gør det (GEDitCOM til MacOS 9/X er
>>ét).
>
>
> Ja, hvis du med hele molevitten mener, at gedcom 5.5 standarden skal
> understøttes fuldt ud, er vi jo enige om det. Men, sagen er, at de
> alle hævder at kunne håndtere gedcom 5.5 standarden, hvor de i
> virkeligheden kun kan håndtere et subset af standarden, og hvor de i
> nogle tilfælde tolker visse dele af standarden forkert.
>
>
>>Det er lidt tabt at de efter så mange år stadig ikke har fået taget sig
>>sammen til at følge standarden...
>
>
> Der er ikke rigtig noget der for alvor motiverer dem til at følge
> standarden fuldt ud. Det kan måske argumenteres, at den eneste grund
> til at følge standarden fuldt ud, skulle være for at gøre det nemmere
> at skifte program via en en gedcom eksport/import, og det mener de
> måske ikke er i deres interesse.
>

Opplever her at du forutsetter at en full bruk av GEDCOM-koden kan skje
ved overføring av egne data, fra mine tidligere programmer til mine nye
programmer.

Kan ikke se at dette gavner andre enn omsetningen til
programvareprodusenter. Som et relativt oppegående menneske ser jeg for
meg de _e-tjenester_ denne standarden ville kunne gi meg innen
slektsgranskning/genealogi, hvor nettopp mulighetene til å utveksle data
til og fra andre genealoger er sentralt.

Dersom standarden ikke behøver å omfatte import/eksport, ja da har jeg
fått svar på mitt tidligere spørsmål om; _er genealogi er en individuell
sport_

Å motivere programvareprodusenter innebærer ikke å fjerne krav, men å
stille krav som er relevante for våre behov.

mvh kjell

---

On Sat, 20 Mar 2004 21:02:12 +0100, Kjell Henry Skåden wrote:

>Opplever her at du forutsetter at en full bruk av GEDCOM-koden kan skje
>ved overføring av egne data, fra mine tidligere programmer til mine nye
>programmer.

Det håber jeg sandelig ikke jeg gør, fordi en sådan forudsætning jo
ikke er en egentlig gedcom problematik, men derimod er en
programvareproblematik.

>Kan ikke se at dette gavner andre enn omsetningen til
>programvareprodusenter. Som et relativt oppegående menneske ser jeg for
>meg de _e-tjenester_ denne standarden ville kunne gi meg innen
>slektsgranskning/genealogi, hvor nettopp mulighetene til å utveksle data
>til og fra andre genealoger er sentralt.

Jo, men så efterlyser du jo i virkeligheden en standard for, hvad et
slægtsprogram skal kunne, og hvordan slægtsprogrammet skal kunne det.
Og, det er - ved den søde grød - ikke en egentlig gedcom problematik.

>Dersom standarden ikke behøver å omfatte import/eksport, ja da har jeg
>fått svar på mitt tidligere spørsmål om; _er genealogi er en individuell
>sport_

Ja, du må undskylde, men jeg forstår ikke hvad du der mener.

>Å motivere programvareprodusenter innebærer ikke å fjerne krav, men å
>stille krav som er relevante for våre behov.

Eller sagt på en anden måde, bliver det - alt andet lige - nemmere at
diskutere problemer direkte, frem for at føre egentlige
programvareproblematikker over på en transportprotokol som gedcom.

med venlig hilsen

Arne

---

aafe skrev:

> On Sat, 20 Mar 2004 21:02:12 +0100, Kjell Henry Skåden wrote:
>
>
>>Opplever her at du forutsetter at en full bruk av GEDCOM-koden kan skje
>>ved overføring av egne data, fra mine tidligere programmer til mine nye
>>programmer.
>
>
> Det håber jeg sandelig ikke jeg gør, fordi en sådan forudsætning jo
> ikke er en egentlig gedcom problematik, men derimod er en
> programvareproblematik.
>
>
>>Kan ikke se at dette gavner andre enn omsetningen til
>>programvareprodusenter. Som et relativt oppegående menneske ser jeg for
>>meg de _e-tjenester_ denne standarden ville kunne gi meg innen
>>slektsgranskning/genealogi, hvor nettopp mulighetene til å utveksle data
>>til og fra andre genealoger er sentralt.
>
>
> Jo, men så efterlyser du jo i virkeligheden en standard for, hvad et
> slægtsprogram skal kunne, og hvordan slægtsprogrammet skal kunne det.
> Og, det er - ved den søde grød - ikke en egentlig gedcom problematik.
>
Hva kommer først, - hønen eller egget. Er det slik at hønen er eggets
måte for å "lave flere egg".

I en tilsvarende _hva_kommer_først_analogi_, som omfatter GEDCOM og
slektsprogrammer, hva vil sammenhengen være.
Bør det ikke være slik at GEDCOM er programmerernes måte/verktøy til at
få aksept for sine markedsførte slektsprogrammer

mvh kjell

---

On Sun, 21 Mar 2004 12:07:01 +0100, Kjell Henry Skåden wrote:

>Bør det ikke være slik at GEDCOM er programmerernes måte/verktøy til at
>få aksept for sine markedsførte slektsprogrammer

Bingo - der har vi kernen i problemet: At der ikke eksisterer nogen
standard for, hvad slægtsprogrammer skal indeholde, og hvordan
slægtsprogrammer skal fungere!

Til gengæld eksisterer der en standard for primært *TRANSPORT* af
genealogiske data, og i mangel på en standard for *HVORDAN
SLÆGTSPROGRAMMER SKAL FUNGERE*, fokuserer i så på den standardiserede
transportprotokol/dataudvekslingsprotokol, ud fra den forudsætning, at
den ikke skal være, hvad den er, nemlig en
transport/dataudvekslings-protokolstandard, men at den istedet skal
være en slags udligningsanordning, der skal kunne løse programtekniske
problemer i de slægtsprogrammer, som der ikke eksisterer nogen
standard for.

Den omtalte side af sagen vil jeg imidlertid blande mig udenom, og
overlade til jer andre. Men, tilbage står der så stadig nogle
egentlige gedcom problemer, hvoraf Arne Feldborg f.eks. har nævnt
problemer med dato angivelser, og hvor jeg har nævnt flere forskellige
af Heredis og Legacys problemer med fejlimplementering af gedcom
standarden, og hvor vi f.eks. også har konstateret, at Brothers Keeper
pt. ikke importerer/eksporterer vidner, selvom en sådan import/eksport
er mulig med GEDCOM 5.5. Vi har også konstateret at Heredis - for
såvidt - både importerer og eksporterer vidner med " *ASSO*ciate
metoden, men at de har misforstået/fejlimplementeret metoden, således
at Heredis ikke kan importere vidner fra en korrekt implementering, og
således, at vidner - eksporteret fra Heredis - heller ikke kan
importeres i systemer hvor metoden er implementeret korrekt. Og, den
type problemstillinger vil jeg fortsætte med at beskæftige mig med.

Jeg er altså ikke den rette sparringspartner for den førstnævnte
problemstilling, men derimod nok for den sidstnævnte problemstilling.

Men, spørgsmålet er vel også, om det ikke er bedst at klappe hesten
indtil Gedcom-Nordic sitet er oppe at stå med debatforum osv. ?

med venlig hilsen

Arne

---

aafe skrev:
> On Sun, 21 Mar 2004 12:07:01 +0100, Kjell Henry Skåden wrote:
>
>
>>Bør det ikke være slik at GEDCOM er programmerernes måte/verktøy til at
>>få aksept for sine markedsførte slektsprogrammer
>
>
> Bingo - der har vi kernen i problemet: At der ikke eksisterer nogen
> standard for, hvad slægtsprogrammer skal indeholde, og hvordan
> slægtsprogrammer skal fungere!
>
> Til gengæld eksisterer der en standard for primært *TRANSPORT* af
> genealogiske data, og i mangel på en standard for *HVORDAN
> SLÆGTSPROGRAMMER SKAL FUNGERE*, fokuserer i så på den standardiserede
> transportprotokol/dataudvekslingsprotokol, ud fra den forudsætning, at
> den ikke skal være, hvad den er, nemlig en
> transport/dataudvekslings-protokolstandard, men at den istedet skal
> være en slags udligningsanordning, der skal kunne løse programtekniske
> problemer i de slægtsprogrammer, som der ikke eksisterer nogen
> standard for.
>
> Den omtalte side af sagen vil jeg imidlertid blande mig udenom, og
> overlade til jer andre. Men, tilbage står der så stadig nogle
> egentlige gedcom problemer, hvoraf Arne Feldborg f.eks. har nævnt
> problemer med dato angivelser, og hvor jeg har nævnt flere forskellige
> af Heredis og Legacys problemer med fejlimplementering af gedcom
> standarden, og hvor vi f.eks. også har konstateret, at Brothers Keeper
> pt. ikke importerer/eksporterer vidner, selvom en sådan import/eksport
> er mulig med GEDCOM 5.5. Vi har også konstateret at Heredis - for
> såvidt - både importerer og eksporterer vidner med " *ASSO*ciate
> metoden, men at de har misforstået/fejlimplementeret metoden, således
> at Heredis ikke kan importere vidner fra en korrekt implementering, og
> således, at vidner - eksporteret fra Heredis - heller ikke kan
> importeres i systemer hvor metoden er implementeret korrekt. Og, den
> type problemstillinger vil jeg fortsætte med at beskæftige mig med.
>
> Jeg er altså ikke den rette sparringspartner for den førstnævnte
> problemstilling, men derimod nok for den sidstnævnte problemstilling.
>
> Men, spørgsmålet er vel også, om det ikke er bedst at klappe hesten
> indtil Gedcom-Nordic sitet er oppe at stå med debatforum osv. ?
>

Tusen takk for denne voksenopplæring.

mvh kjell

---

On Sun, 21 Mar 2004 15:10:35 +0100, Kjell Henry Skåden wrote:

>Tusen takk for denne voksenopplæring.

Det gælder i mange af livets forhold om at sige til og fra. Og, det du
opfatter som en belæring, er blot et begrundet nej tak til at blive
"spændt for en anden mands vogn"

med venlig hilsen

Arne

---

aafe skrev:
> On Sun, 21 Mar 2004 15:10:35 +0100, Kjell Henry Skåden wrote:
>
>
>>Tusen takk for denne voksenopplæring.
>
>
> Det gælder i mange af livets forhold om at sige til og fra. Og, det du
> opfatter som en belæring, er blot et begrundet nej tak til at blive
> "spændt for en anden mands vogn"
>
> med venlig hilsen
>
> Arne
>
En meget klok refleksjon

mvh kjell

---

Kjell Henry Skåden <old.navy@online.no> skrev Sun, 21 Mar 2004 12:07:01
+0100

>I en tilsvarende _hva_kommer_først_analogi_, som omfatter GEDCOM og
>slektsprogrammer, hva vil sammenhengen være.
>Bør det ikke være slik at GEDCOM er programmerernes måte/verktøy til at
>få aksept for sine markedsførte slektsprogrammer
>
Nej. Gedcom skal ikke afspejle alle det enkelte programs
fortræffeligheder - det er jo netop det der er problemet med den måde
Gedcom i vid udstrækning bruges på i dag.

Gedcom skal kunne flytte data fra eet program til et andet. Det er så
(udfra en given standard) såvel det afgivende som det modtagende
programs ansvar at håndtere dette så *ingen* data mistes.

Da der jo er stor forskel på hvilke begreber og funktioner der findes i
de forskellige programmer betyder det så også, at der vil være en del
data der ikke kan placeres 100% korrekt i det modtagende program.

Her er det IMHO såvel det afgivende program, som det modtagende, som
selve standardens ansvar at disse ting kan fortolkes og placeres mest
hensigtsmæssigt i det modtagende program.

Ligesom man bruger RTF-filer til at overføre data fra een
tekstbehandling til en anden, og ligesom man bruger csv-filer til at
overføre data fra eet regneark til et andet, sådan bør man også kunne
bruge Gedcom til at overføre data fra eet slægtsprogram til et andet.



--
mvh, A:\Feldborg

Folketællinger Hammerum og Bølling herreder, kirkebøger Hammerum herred
http://www.haunstrup.dk/feldborg/genealogi/download/

---

Sun, 21 Mar 2004 15:09:58 +0100, in dk.videnskab.historie.genealogi,
Arne Feldborg <feldborg@haunstrup.dk> wrote:

>Her er det IMHO såvel det afgivende program, som det modtagende, som
>selve standardens ansvar at disse ting kan fortolkes og placeres mest
>hensigtsmæssigt i det modtagende program.
>
>Ligesom man bruger RTF-filer til at overføre data fra een
>tekstbehandling til en anden, og ligesom man bruger csv-filer til at
>overføre data fra eet regneark til et andet, sådan bør man også kunne
>bruge Gedcom til at overføre data fra eet slægtsprogram til et andet.

vi vet også at en RTF fil ikke er bare rett frem da det her er forskjell
i en RTF file om den er laget for Word Perfect eller MS Word.

Det samme gjelder GEDCOM.
Det er forskjell i hvordan verdier skal tolkes
Det er mulig å bruke kodeverk av typen _ (underscore)
Det er mulig å bruke kodeverk av typen TYPE/EVEN

Alt dette bidrar til at det ikke er noen 100 % rett frem overføring fra
et program til et annet program

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

---

Otto Jørgensen <otjoerge%øføø%@online.noAWAY> skrev Sun, 21 Mar 2004
15:16:29 +0100

>>Ligesom man bruger RTF-filer til at overføre data fra een
>>tekstbehandling til en anden, og ligesom man bruger csv-filer til at
>>overføre data fra eet regneark til et andet, sådan bør man også kunne
>>bruge Gedcom til at overføre data fra eet slægtsprogram til et andet.
>
>vi vet også at en RTF fil ikke er bare rett frem da det her er forskjell
>i en RTF file om den er laget for Word Perfect eller MS Word.
>
Hvilke forskelle.?

Forskelle der gør at det modtagende program ikke forstår og genkender
alle data.?

>Det samme gjelder GEDCOM.
>Det er forskjell i hvordan verdier skal tolkes
>
Det burde der ikke være.

>Det er mulig å bruke kodeverk av typen _ (underscore)
>
Det burde det ikke være (IMHO). Det burde ihvertfald ikke være tilladt
at lægge vigtige data i sådanne tags.

>Det er mulig å bruke kodeverk av typen TYPE/EVEN
>
Forudsat at både det afgivende og det modtagende program er fornuftigt
indrettet burde det ikke værre noget problem.

>Alt dette bidrar til at det ikke er noen 100 % rett frem overføring fra
>et program til et annet program
>
Det er jo netop det der er problemet. Og det løser men ikke ved endnu
flere proprietære tags - tværtimod.



--
mvh, A:\Feldborg

Folketællinger Hammerum og Bølling herreder, kirkebøger Hammerum herred
http://www.haunstrup.dk/feldborg/genealogi/download/

---

Sun, 21 Mar 2004 19:40:40 +0100, in dk.videnskab.historie.genealogi,
Arne Feldborg <feldborg@haunstrup.dk> wrote:

>Otto Jørgensen <otjoerge%øføø%@online.noAWAY> skrev Sun, 21 Mar 2004
>15:16:29 +0100
>
>>>Ligesom man bruger RTF-filer til at overføre data fra een
>>>tekstbehandling til en anden, og ligesom man bruger csv-filer til at
>>>overføre data fra eet regneark til et andet, sådan bør man også kunne
>>>bruge Gedcom til at overføre data fra eet slægtsprogram til et andet.
>>
>>vi vet også at en RTF fil ikke er bare rett frem da det her er forskjell
>>i en RTF file om den er laget for Word Perfect eller MS Word.
>>
>Hvilke forskelle.?
>
>Forskelle der gør at det modtagende program ikke forstår og genkender
>alle data.?

Yes.
En RTF-file laget i et annet program enn mottagende program kan ofte
medføre at formateringer m.m. ikke blir det samme


>>Det samme gjelder GEDCOM.
>>Det er forskjell i hvordan verdier skal tolkes
>>
>Det burde der ikke være.

Det er jeg enig i men resultatet er desverre noen ganger motsatt


>>Det er mulig å bruke kodeverk av typen _ (underscore)
>>
>Det burde det ikke være (IMHO). Det burde ihvertfald ikke være tilladt
>at lægge vigtige data i sådanne tags.
>
>>Det er mulig å bruke kodeverk av typen TYPE/EVEN
>>
>Forudsat at både det afgivende og det modtagende program er fornuftigt
>indrettet burde det ikke værre noget problem.

Der har vi jo forholdet at de ulike programutviklere har sine
fortolkninger og der er de ikke altid enig.
Hadde det vært helt klar fortolkning så hadde en del banale forhold ikke
eksistert

>>Alt dette bidrar til at det ikke er noen 100 % rett frem overføring fra
>>et program til et annet program
>>
>Det er jo netop det der er problemet. Og det løser men ikke ved endnu
>flere proprietære tags - tværtimod.

I grunnen enig, men TYPE/EVEN har den svakhet at man selv setter opp hva
akkurat denne kombinasjonen skal bety i et spesielt tilfelle. Det settes
gjerne en forklaring f.eks. borglig konfirmasjon.

Sender vi dette til USA så blir det noe vanskelig, da det er ikke noe
som oversetter borglig konfirmasjon til engelsk.
Ei heller ligger det noe i GEDCOM som tar med en slik oversettelse.
Og dermed er noe av hensikten med den koden borte (så lenge man ikke har
med en tekst som kan direkte oversettes, gjevnfør at kodene ellers i
GEDCOM er universale)


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

---

Otto Jørgensen <otjoerge%øføø%@online.noAWAY> skrev Sun, 21 Mar 2004
20:04:07 +0100

>>>vi vet også at en RTF fil ikke er bare rett frem da det her er forskjell
>>>i en RTF file om den er laget for Word Perfect eller MS Word.
>>>
>>Hvilke forskelle.?
>>
>>Forskelle der gør at det modtagende program ikke forstår og genkender
>>alle data.?
>
>Yes.
>En RTF-file laget i et annet program enn mottagende program kan ofte
>medføre at formateringer m.m. ikke blir det samme
>
Læs lige det du svarer på en gang til. )

Det du svarer bunder jo i at de to programmer faktisk er forskellige,
ikke i at de opfatter eller udnytter rtf-standarden forskelligt.



--
mvh, A:\Feldborg

Folketællinger Hammerum og Bølling herreder, kirkebøger Hammerum herred
http://www.haunstrup.dk/feldborg/genealogi/download/

---

Sun, 21 Mar 2004 20:16:40 +0100, in dk.videnskab.historie.genealogi,
Arne Feldborg <feldborg@haunstrup.dk> wrote:

>Otto Jørgensen <otjoerge%øføø%@online.noAWAY> skrev Sun, 21 Mar 2004
>20:04:07 +0100
>
>>>>vi vet også at en RTF fil ikke er bare rett frem da det her er forskjell
>>>>i en RTF file om den er laget for Word Perfect eller MS Word.
>>>>
>>>Hvilke forskelle.?
>>>
>>>Forskelle der gør at det modtagende program ikke forstår og genkender
>>>alle data.?
>>
>>Yes.
>>En RTF-file laget i et annet program enn mottagende program kan ofte
>>medføre at formateringer m.m. ikke blir det samme
>>
>Læs lige det du svarer på en gang til. )
>
>Det du svarer bunder jo i at de to programmer faktisk er forskellige,
>ikke i at de opfatter eller udnytter rtf-standarden forskelligt.


og hva er så et RTF-format.?
Hva er hensikten med RTF-formatet?

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

---

Otto Jørgensen <otjoerge%øføø%@online.noAWAY> skrev Sun, 21 Mar 2004
21:04:55 +0100


>og hva er så et RTF-format.?
>
Rich Text Format.

Iøvrigt en propreitær standard ligesom Gedcom. Men selvom den faktisk er
langt mere indviklet, så har diverse programproducenter åbenbart haft
nemmere ved at følge den, end producenter af slægtsprogrammer har haft
ved at følge Gedcom standarden.?

>Hva er hensikten med RTF-formatet?
>
At overføre data mellem to programmer - uden at data går tabt.!

Samt, efter et fastlagt skema, at overføre de formateringskoder der er
nødvendige, for at det modtagende program kan vise disse data på en
fornuftig måde (indenfor de rammer det modtagende program nu engang har
til rådighed) - uden at data går tabt, og uden at forståelsen af data
går tabt.

Det er i princippet også formålet med Gedcom. Men i praksis fungerer det
ikke sådan.

Du må for min skyld godt kalde det at mødes på laveste fællesnævner (det
mener jeg nu ikke det er), men jeg mener altså at der kræves tre ting
for at det kan komme til at fungere i praksis:

a.
At det eksporterende program faktisk eksperterer data med henblik på at
andre programmer skal kunne forstå det - istedet for tværtimod at bruge
det som en platform til at vise, hvad netop dette program har af
forkromede finesser.

b.
At det modtagende program vitterligt forsøger at fortolke de modtagne
data, så de passer ind i de funktioner som netop dette program har til
rådighed - istedet for bare at afvise ting det ikke umiddelbart forstår.

c.
En forholdsvis simpel standard, der gør det ovenstående muligt.


Min pointe er simpelthen, at ved en overførsel med gedcomfiler må der
*aldrig* gå data tabt.

Et program må *aldrig*afvise data fordi det ikke forstår formatet, men
skal altid indplacere dem bedst muligt (og i værste fald under Noter)

Det må *aldrig* *nogensinde* forekomme at datoer fortolkes forkert pga.
uhensigtsmæssig overførsel.

Mht. det sidste så er der kun 2 muligheder: Enten skal datoer overføres
som Timestamps (bruger kan jo være ligeglad, han ser dem normalvis
ikke), eller også skal datoer altid overføres som ddmmmyyyy.

Selv er jeg ikke tilstrækkeligt inde i den nuværende gedcom standard til
at kunne kommentere de enkelte Tags - men som bruger ved jeg så
nogenlunde hvordan jeg ønsker resultatet skal blive.

Først og fremmest driftsikkerhed på dette eller hint niveau. Og når
(eller hvis) man så har nået det, så kan man altid senere hæve
ambitionsniveauet hen ad vejen.




--
mvh, A:\Feldborg

Folketællinger Hammerum og Bølling herreder, kirkebøger Hammerum herred
http://www.haunstrup.dk/feldborg/genealogi/download/

---

Mon, 22 Mar 2004 00:09:49 +0100, in dk.videnskab.historie.genealogi,
Arne Feldborg <feldborg@haunstrup.dk> wrote:

>Selv er jeg ikke tilstrækkeligt inde i den nuværende gedcom standard til
>at kunne kommentere de enkelte Tags - men som bruger ved jeg så
>nogenlunde hvordan jeg ønsker resultatet skal blive.

der er vi nok enig.
Jeg vet hva jeg vil ha overført :=)

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

---

aafe <intet@svar.dk> skrev Thu, 18 Mar 2004 02:05:07 +0100

>En alternativ måde at arbejde med GEDCOM standarden på, kunne være, at
>opstille en nordisk gedcomfil, med alle de tags og
>kombinationsmuligheder i, som vi ønsker alle slægtsprogrammer skal
>kunne håndtere.
>
Der rammer du lige ned i min kæphest.

For hvad er det egentlig vi ønsker.?

Nogen vil have så mange Tags som vel muligt, og gerne et hav af
selvdefinerede Tags - som kun det selvsamme program forstår.

Andre (heriblandt undertegnede) vil bare gerne have noget helt basalt,
der virker og som kan overføre de rå data - og som virker i alle
programmer.

For mig at se har de fleste producenter fuldstændig overset selve
formålet med Gedcom, og bruger det istedet for til at demonstrere alle
de fortræffeligheder netop deres program besidder.

Selve tankegangen er tydeligvis "Microsoft modellen": Hvis det virker i
vore programmmer - men ikke i de andre - så er det i sig selv bevis på
at vore programmer er overlegne.!

En gedcom version der kun kan bruges til at overføre data til det
selvsamme program er IMHO totalt værdiløst. Til det formål er det
pågældende programs eget datbaseformat alt andet lige lang mere
velegnet.

Og i nogle programmer er det endog drevet så vidt, at end ikke det samme
program kan importere sin egen Gedcomfil uden at brokke sig over
ulovlige Tags.

Bare en helt triviel ting som datoformatet kan de forskellige programmer
jo ikke engang finde ud af. Men selvdefinerede Tags for kilder i 4de
niveau kan de godt klare - for det viser jo hvor overlegne de er.!

Det vi (efter min mening) mangler er en helt uafhængig organisation, som
vi kender feks. mht. diverse programeringssprog, så simpelthen siger at
sådan skal det være, for at man har lov til at bruge betegnelsen gedcom.

Eller måske nærmere en ISO-standard som vi har det på mange andre af
dagligdagens områder.

>Guleroden til slægtsprogramsproducenterne vil så være, at de kan
>reklamere med at være kompatibel med GEDCOM-Nordic i klasse I,
>klasse II eller klasse III.
>
For mig at se er der intet der tyder på at producenterne overhovedet er
intereserede i en fælles standard, for det ville jo netop fratage dem
"MicroSoft fordelen".

Selvfølgelig kunne et masivt brugerpres ændre på dette. Men det er ikke
mit indtryk at brugerne generelt interesserer sig for dette. Og når de
en sjælden gang bruger gedcom, og oplever problemer, så holder de sig
til, at det jo nok er deres program der gør det rigtige (for det står
der jo i Help-filen).


--
mvh, A:\Feldborg

Folketællinger Hammerum og Bølling herreder, kirkebøger Hammerum herred
http://www.haunstrup.dk/feldborg/genealogi/download/

---

Thu, 18 Mar 2004 04:00:17 +0100, in dk.videnskab.historie.genealogi,
Arne Feldborg <feldborg@haunstrup.dk> wrote:

>For mig at se har de fleste producenter fuldstændig overset selve
>formålet med Gedcom, og bruger det istedet for til at demonstrere alle
>de fortræffeligheder netop deres program besidder.

Ville en løsning med at programmet kan lage to varianter være løsningen:
1: en GEDCOM file som inneholder alle "offisielle" tags (GEDCOM 5.5) og
alle tags som starter med _ (underscore)
2: en GEDCOM file som inneholder alle "offisielle" tags (GEDCOM 5.5) og
ingen produsent produserte eller brukerproduserte tags


Dette burde gir tisltrekkelig mangfold?

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

---

> Ville en løsning med at programmet kan lage to varianter være løsningen:
> 1: en GEDCOM file som inneholder alle "offisielle" tags (GEDCOM 5.5) og
> alle tags som starter med _ (underscore)
> 2: en GEDCOM file som inneholder alle "offisielle" tags (GEDCOM 5.5) og
> ingen produsent produserte eller brukerproduserte tags

Otto jeg er ikke enig her - det er der ikke nogen udvikling i.

Arnes forslag med at anvende Klasse systemet, giver brugeren mulighed for at
se hvilken grad af GEDCOM programmet anvender. Det er jo netop
producenternes mulighed for at oprette nye TAGS med _ (underscore) forand
der har "ødelagt" GEDCOM standarden.
Hvis derimod det var en uafhængig (bruger)organisation der bestyrer
indholdet i de enkelte Klasser - er der langt nemere at meddele at et
program ikke overholder den vedtaget standard.

Jeg mener at det IKKE skal være muligt (læs: tilladt) for producenten at
oprette nye TAGS udenfor standarden og påstå at at programmet understøtter
standarden. Enten overholder programmet standarden eller så gør det ikke.


Med venlig hilsen
Chris Gade Oxholm Sørensen - www.brotherskeeper.dk -
support@brotherskeeper.dk

---

Thu, 18 Mar 2004 08:21:38 +0100, in dk.videnskab.historie.genealogi,
<support@bk6.dk> wrote:

>
>> Ville en løsning med at programmet kan lage to varianter være løsningen:
>> 1: en GEDCOM file som inneholder alle "offisielle" tags (GEDCOM 5.5) og
>> alle tags som starter med _ (underscore)
>> 2: en GEDCOM file som inneholder alle "offisielle" tags (GEDCOM 5.5) og
>> ingen produsent produserte eller brukerproduserte tags
>
>Otto jeg er ikke enig her - det er der ikke nogen udvikling i.
>
>Arnes forslag med at anvende Klasse systemet, giver brugeren mulighed for at
>se hvilken grad af GEDCOM programmet anvender. Det er jo netop
>producenternes mulighed for at oprette nye TAGS med _ (underscore) forand
>der har "ødelagt" GEDCOM standarden.
>Hvis derimod det var en uafhængig (bruger)organisation der bestyrer
>indholdet i de enkelte Klasser - er der langt nemere at meddele at et
>program ikke overholder den vedtaget standard.
>
>Jeg mener at det IKKE skal være muligt (læs: tilladt) for producenten at
>oprette nye TAGS udenfor standarden og påstå at at programmet understøtter
>standarden. Enten overholder programmet standarden eller så gør det ikke.
>
Jeg mente heller ikke det som utvikling, men det er stadig tilfeller at
det fra flere brukere kommer reaksjoner at man ikke får importer/eksport
data. Og når jeg skrev så var det ut fra dagens situasjon.

I dag bør alle program dekke ren standard GEDCOM5.5
dette er det enklest alternativ, Ren GEDCOM5.5 og ingen produsent
definert kode (bruk av underscore).
Da skulle alle data går rett inn.

Så har vi bruke av underscore som også er legalt, men som da blir en
produsent variant. Denne metoden har mange brukt i dag, men alle program
handterer ikke denne og en del av disse kommer inn på feillogger eller
forsvinner i tåken.

Det er her ikke noen god løsning for handtering av disse og det trenges

Dette er en slags minimum for å ha en brukbart liv i dag (førstehjelp).
Dette tror jeg vil redusere antall henvendelser feil i
gedcomeksport/import som skyldes at programmene ikke snakker sammen. Da
kan man få tid og fred til neste skritt

Så løfter vi blikket fremover mot bedre tider og tar med Arnes forslag
og vi er på vei fremover mot det som kan bli et bedre liv :=)



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

---

On Thu, 18 Mar 2004 04:00:17 +0100, Arne Feldborg wrote:

>Der rammer du lige ned i min kæphest.
>
>For hvad er det egentlig vi ønsker.?

Ja, det skal vi prøve at finde frem til, og derefter opstille een
eller flere gedcoms svarende til vores ønsker/krav.

>Nogen vil have så mange Tags som vel muligt, og gerne et hav af
>selvdefinerede Tags - som kun det selvsamme program forstår.

Tjah, det kan jo ærlig talt ikke bruges til noget.

>Andre (heriblandt undertegnede) vil bare gerne have noget helt basalt,
>der virker og som kan overføre de rå data - og som virker i alle
>programmer.

Ja, det er jeg enig med dig i, men spørgsmåler er så blot, hvor vi
trækker grænsen mellem det nødvendige og det overflødige.

>Det vi (efter min mening) mangler er en helt uafhængig organisation, som
>vi kender feks. mht. diverse programeringssprog, så simpelthen siger at
>sådan skal det være, for at man har lov til at bruge betegnelsen gedcom.

Det er også en del af tanken med GEDCOM-Nordic, der så istedet for at
lave en norm, laver nogle gedcomfiler, som programmerne skal kunne
importere og geneksportere perfekt, for at kunne betegnes som
opfyldende GEDCOM-Nordic.

>Eller måske nærmere en ISO-standard som vi har det på mange andre af
>dagligdagens områder.

GENTECH http://www.gentech.org/ngsgentech/main/Home.asp har vist
forsøgt sig med en RFC, men jeg synes nu ikke det virker imponerende.

http://xml.coverpages.org/GENTECH-DataModelV11.pdf

>For mig at se er der intet der tyder på at producenterne overhovedet er
>intereserede i en fælles standard, for det ville jo netop fratage dem
>"MicroSoft fordelen".
>
>Selvfølgelig kunne et masivt brugerpres ændre på dette. Men det er ikke
>mit indtryk at brugerne generelt interesserer sig for dette. Og når de
>en sjælden gang bruger gedcom, og oplever problemer, så holder de sig
>til, at det jo nok er deres program der gør det rigtige (for det står
>der jo i Help-filen).

Ja, jeg er enig med dig i, at det dybest set falder tilbage på os
selv, for i det øjeblik vi massivt kunne fortælle programproducenterne
hvad vi vil have, så får vi det også.

Jeg undrer mig f.eks. over, at der laves programmer med 3D
anepræsentationer, der kan roteres og vendes og drejes på alle mulige
måder, mens den basale gedcom import/eksport er mangelfuld/defekt, og
der samtidig mangler elementære muligheder for, manuelt, at kunne
rokere med rækkefølgen af ægteskaber og rækkefølgen af børn. Men, det
skyldes selvfølgelig, at jeg har brug for at have samlet nogle
praktiske værktøjer i mit slægtsprogram, mens jeg ikke har bug for at
rotere mine aner i 3D.

Det flotte og smarte og lidt spil-prægede underholdning siger mig ikke
rigtig noget, og hører - efter min mening - ikke hjemme i
slægtsprogrammer: Men, der må vel være købere til det, eftersom det
altså også finder vej til slægtsprogrammerne, eller er det blot et
resultat af, at programmørerne/producenterne går i selvsving og mister
jordforbindelsen?

Lad os prøve at give GEDCOM-Nordic en chance, og se, om ikke der kan
komme noget brugbart ud af det.

med venlig hilsen

Arne

---

> Der kan evt. opstilles 3 forskellige nordiske gedcomfiler, såsom en
> minimums gedcom, en standard gedcom og endelig den store forkromede
> model, der afspejler alle vores ønsker/krav fuldt ud.
>
> Guleroden til slægtsprogramsproducenterne vil så være, at de kan
> reklamere med at være kompatibel med GEDCOM-Nordic i klasse I,
> klasse II eller klasse III.
>

Genialt Arne - det kan kun gå for langsomt

Med venlig hilsen
Chris Gade Oxholm Sørensen - www.brotherskeeper.dk -
support@brotherskeeper.dk

---

Thu, 18 Mar 2004 02:05:07 +0100, skrev aafe:

>Guleroden til slægtsprogramsproducenterne vil så være, at de kan
>reklamere med at være kompatibel med GEDCOM-Nordic i klasse I,
>klasse II eller klasse III.

Softwareproducenter spiser desværre ikke gulerødder. De reklamerer jo
allesammen med, at deres program er kompatibelt med GEDCOM-standarden,
men det er bare løwn i djer hals.

En produktomtale, skrevet af producenten selv, der hævder at være
kompatibel med en nordisk standard, ville jeg ikke stole på over en
dørtærskel.

Men hvorfor i det hele taget gå så meget op i at understøtte og
udbygge en "standard" der allerede er afgået ved døden for flere år
siden. De sidste dages hellige har forlængst meddelt, at de stopper
vedligehildelsen af standarden og satser på XML (eller hvad det nu
hedder).

Venlig hilsen
Kurt Hansen
kurt/snabel-a/towle/punktum/dk

---

> Softwareproducenter spiser desværre ikke gulerødder. De reklamerer jo
> allesammen med, at deres program er kompatibelt med GEDCOM-standarden,
> men det er bare løwn i djer hals.

Ja desværre

> En produktomtale, skrevet af producenten selv, der hævder at være
> kompatibel med en nordisk standard, ville jeg ikke stole på over en
> dørtærskel.

Du har sikkert ret - men ved at at det var en ufhængig organisation er
opsatte et Klasse system GEDCOM eller XML ville måske være mere farbar.

> Men hvorfor i det hele taget gå så meget op i at understøtte og
> udbygge en "standard" der allerede er afgået ved døden for flere år
> siden. De sidste dages hellige har forlængst meddelt, at de stopper
> vedligehildelsen af standarden og satser på XML (eller hvad det nu
> hedder).

Spørgsmålet er om GEDCOM nødvendigvis skal være død, ideen bag GEDCOM
standarden er OK og det virker i grundprincippet.
Og hvorfor skal "De sidste dages hellige" igen have eneret til en ny
standard?
Og en standard, der givet kommer til at indeholde producent-mulighed for at
oprette egne TAGS - og hvor er vi så - ser det som samme sted som med
GEDCOM.

Og for at gentage dit udsagn omkring produktomtale, hvor der bliver skrevet
at programmet overholder XML standarden - kan der stoles på dette så -
sikkert heller ikke.

Tillid er godt - kontrol er bedre

Med venlig hilsen
Chris Gade Oxholm Sørensen - www.brotherskeeper.dk -
support@brotherskeeper.dk

---

Thu, 18 Mar 2004 09:12:00 +0100, skrev <support@bk6.dk>:

>> En produktomtale, skrevet af producenten selv, der hævder at være
>> kompatibel med en nordisk standard, ville jeg ikke stole på over en
>> dørtærskel.
>
>Du har sikkert ret - men ved at at det var en ufhængig organisation er
>opsatte et Klasse system GEDCOM eller XML ville måske være mere farbar.

Fint med sådan en instans. Måske kunne der ligefrem gå prestige i at
få det eftertragtede logo der betyder, at softwaren overholder
standarden og at det er kontrolleret af "The XL-GED Association" -
ligesom f.eks. det europæiske E-mærke.

>> Men hvorfor i det hele taget gå så meget op i at understøtte og
>> udbygge en "standard" der allerede er afgået ved døden for flere år
>> siden. De sidste dages hellige har forlængst meddelt, at de stopper
>> vedligehildelsen af standarden og satser på XML (eller hvad det nu
>> hedder).
>
>Spørgsmålet er om GEDCOM nødvendigvis skal være død, ideen bag GEDCOM
>standarden er OK og det virker i grundprincippet.
>Og hvorfor skal "De sidste dages hellige" igen have eneret til en ny
>standard?
>Og en standard, der givet kommer til at indeholde producent-mulighed for at
>oprette egne TAGS - og hvor er vi så - ser det som samme sted som med
>GEDCOM.

Jeg skal ikke gøre mig klog på XML, men det er vist noget med at man
opretter "felter" som man finder behov for og disse forsynes med en
"header" (beskrivelse) der sætter modtageren i stand til at
identificere hvad det er for nogle data der er i feltet og kan så selv
beslutte "som hvad" det skal importeres i hendes eget program.

>Og for at gentage dit udsagn omkring produktomtale, hvor der bliver skrevet
>at programmet overholder XML standarden - kan der stoles på dette så -
>sikkert heller ikke.
>
>Tillid er godt - kontrol er bedre

I dette tilfælde ja, men i almindelighed hylder jeg det modsatte.

Venlig hilsen
Kurt Hansen
kurt/snabel-a/towle/punktum/dk

---

On Thu, 18 Mar 2004 08:45:38 +0100, Kurt Hansen wrote:

>En produktomtale, skrevet af producenten selv, der hævder at være
>kompatibel med en nordisk standard, ville jeg ikke stole på over en
>dørtærskel.

Men, der er det jo os, der afgør, om et program er kompatibel med den
nordiske standard eller ej: Vi offentliggør standardens klasse I,
klasse II og klasse III så fabrikanterne ved hvad de har at rette sig
efter, og så tester vi, om dette eller hint program overholder denne
eller hin klasse i den nordiske standard.

>Men hvorfor i det hele taget gå så meget op i at understøtte og
>udbygge en "standard" der allerede er afgået ved døden for flere år
>siden. De sidste dages hellige har forlængst meddelt, at de stopper
>vedligehildelsen af standarden og satser på XML (eller hvad det nu
>hedder).

Sagen er, at gedcom standarden ikke er afgået ved døden, men faktisk
er det eneste vi har. Sagen er også, at gedcom standarden fortsat vil
leve i en del år, efter xml modellen er taget i brug. Jeg vil gætte på
mindst 5 år.

Det der er afgået ved døden, er vedligeholdelsen og videreudviklingen
af gedcom standarden, og det er så det vi vil prøve at gøre noget ved.

Når LDS-Kirken begynder at bruge deres nye xml-gedcom system, skrues
tiden på mange tilbage til dengang de i sin tid introducerede deres
gedcom: Mødet med den virkelige verden vil formentlig vise sig også at
indebære børnesygdomme, som der måske kan gå så meget som 10 år med at
få udryddet, mens den nuværende gedcom 5.5 vel har fået udryddet de
fleste af sine børnesygdomme.

De erfaringer vi formentlig kommer til at indhøste, behøver jo ikke at
gå tabt, men kan vel senere - i nogen grad - flyttes over xml
modellen, hvis/når den er kommet i praktisk brug.

med venlig hilsen

Arne

---

On Thu, 18 Mar 2004 02:05:07 +0100, aafe <intet@svar.dk> wrote:

>En alternativ måde at arbejde med GEDCOM standarden på, kunne være, at
>opstille en nordisk gedcomfil, med alle de tags og
>kombinationsmuligheder i, som vi ønsker alle slægtsprogrammer skal
>kunne håndtere.

Det nærmeste vi vel p.t. kan komme på et udenomkirkeligt
standardiserings organ for GEDCOM er vel GENTECH.
http://www.gentech.org/gttech.htm

http://www.gentech.org/ngsgentech/projects/Projects.asp

Det var vist meningen, at GENTECH skulle opstille en standard
gedcomfile, som de forskellige slægtsprogrammer skulle kunne håndtere.
Men såvidt jeg ved, er denne standard gedcom aldrig blevet til noget.
Istedet er det så blevet til en Genealogisk Data Model:
http://www.gentech.org/ngsgentech/projects/Gdm/Gdm.asp
og et såkaldt Testbook Projekt:
http://www.gentech.org/ngsgentech/projects/TestBook2001/
hvor et udvalg af slægtsprogrammer er testet.

Men, jeg ved søreme ikke hvor brugbar datamodellen egentlig er for
andre end programproducenter, og testen daterer sig tilbage til 2001,
hvor f.eks. Brothers Keeper versionen var 6.0.53.

Og, man må vel spørge om nytten af en tre år gammel test, der
endvidere kun omfatter et begrænset antal amerikanske
slægtsprogrammer.

Det nærmeste vi vel p.t. kan komme en egentlig testged, er måske
armidales master.ged:
ftp://armidalesoftware.com/pub/armidale/issue/master.ged
der vel også kan diskuteres, idet den udover det korrekte GEDCOM 5.5
indhold, som programmerne bør kunne håndtere, også - med vilje -
indeholder nogle fejlimplementeringer, der er kendt fra visse
programmers fejlimplementering af gedcom standarden.

Det kan så diskuteres, om sådanne kendte fejlimplementeringer skal
medtages i testgeden, med det formål at teste om slægtsprogrammerne
afviser sådanne fejlimplementeringer.

I en test kan det vel være meget godt at få sådanne egenskaber belyst,
men i det virkelige liv kan vi vel egentlig være ligeglade med, om et
slægtsprogram måske også kan indlæse "dårlig" og/eller "forkert"
gedcom - når blot det bringes til korrekt intern anvendelse - og når
blot sådan "dårlig/forkert" kodning ikke geneksporteres i samme form.

ftp://armidalesoftware.com/pub/armidale/issue/master.ged kan evt.
downloades og tjene til inspirationskilde for opstillingen af
GEDCOM-Nordic, samt tjene som diskussionsobjekt.

med venlig hilsen

Arne

---

"aafe" <intet@svar.dk> wrote in message news:fbth505lc1b25jabhkj62r57hodk725pd9@4ax.com...
> En alternativ måde at arbejde med GEDCOM standarden på, kunne være, at
> opstille en nordisk gedcomfil, med alle de tags og
> kombinationsmuligheder i, som vi ønsker alle slægtsprogrammer skal
> kunne håndtere.
>
> Der kan evt. opstilles 3 forskellige nordiske gedcomfiler, såsom en
> minimums gedcom, en standard gedcom og endelig den store forkromede
> model, der afspejler alle vores ønsker/krav fuldt ud.
>
> Guleroden til slægtsprogramsproducenterne vil så være, at de kan
> reklamere med at være kompatibel med GEDCOM-Nordic i klasse I,
> klasse II eller klasse III.


LOL

XML Standard is the way
http://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=gedcom+replacement

http://www.ancestry.com/library/view/columns/eastman/3396.asp

>> GEDCOM has always suffered from numerous shortcomings, one limitation being the use of text. Other limitations have included
difficulties with handling non-European names, handling imprecise data, and also the method of handling contradictory data such as
we all find in genealogy research.<<


I leave it to the techies

Hugh W

--
Welsh genealogy - Merionethshire
http://www.rootsweb.com/~wlsmer/index.html
http://boards.ancestry.com/mbexec/board/an/localities.britisles.wales.mer.general

---

For at komme igang har jeg nu bestilt følgende web-adresse:
www.gedcom-nordic.org

Der går lige nogle dage inden den er aktiv.
Alle udgifter i forbindelse med oprettelse og drift det skal jeg nok betale.

I første omgang vil jeg få opstillet en liste på GEDCOM opdelt i de 3
klasser.

Klasse I
Indeholder de mest basale TAGS
Klasse II
Indeholder væsentlige TAGS fra GEDCOM 5.5
Klasse III
Indeholder alle øvrige TAGS samt TAGS der starter med _ (underscore)

[Ovenstående er et forslag til opdeling]

Foruden denne opdeling mener jeg der skal være en standard GEDCOM fil for
hver af de 2 vigtigste Klasser, hvormed der kan foretages en test med.

Hertil bør der være en oversigt over hvilke slægtsforskningsprogrammer der
overholder henholdsvis Klasse I og II. (import/eksport)

For at få www.gedcom-nordic.org til at være anvendelig, er der behov for
følgende:

En der kan fremstille de nødvendige GEDCOM-nordic GED filer.
En eller flere der kan hjælpe med at få fremstillet en god web-side.
Der som et krav skal indeholde et debatforum
En der er tilstrækkelig god til engelsk, således at en vedtaget betydning
for de enkelte TAGS kan oversættes korret til engelsk.
Foruden dansk/engelsk mener jeg der er behov for en oversættelse som minimum
til norsk og svensk.


Med venlig hilsen
Chris Gade Oxholm Sørensen - www.brotherskeeper.dk -
support@brotherskeeper.dk

---

On Thu, 18 Mar 2004 17:32:07 +0100, <support@bk6.dk> wrote:

>For at komme igang har jeg nu bestilt følgende web-adresse:
>www.gedcom-nordic.org
>
>Der går lige nogle dage inden den er aktiv.
>Alle udgifter i forbindelse med oprettelse og drift det skal jeg nok betale.
>
>I første omgang vil jeg få opstillet en liste på GEDCOM opdelt i de 3
>klasser.
>
> Klasse I
>Indeholder de mest basale TAGS
> Klasse II
>Indeholder væsentlige TAGS fra GEDCOM 5.5
> Klasse III
>Indeholder alle øvrige TAGS samt TAGS der starter med _ (underscore)
>

Og så den metode som allerede er standardisert for at brukerdefinere
tags;

   1 EVEN
   2 TYPE

Både ved import og eksport.

Og så må det skilles mellom innebyggede standardtags og muligheten for
at brukeren kan definere sine tags utfra standardisert oppbygging.


---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
tha@tha.no
www.tha.no

---

torleif haugødegård skrev:

> On Thu, 18 Mar 2004 17:32:07 +0100, <support@bk6.dk> wrote:
>
>
>>For at komme igang har jeg nu bestilt følgende web-adresse:
>>www.gedcom-nordic.org
>>
>>Der går lige nogle dage inden den er aktiv.
>>Alle udgifter i forbindelse med oprettelse og drift det skal jeg nok betale.
>>
>>I første omgang vil jeg få opstillet en liste på GEDCOM opdelt i de 3
>>klasser.
>>
>> Klasse I
>>Indeholder de mest basale TAGS
>> Klasse II
>>Indeholder væsentlige TAGS fra GEDCOM 5.5
>> Klasse III
>>Indeholder alle øvrige TAGS samt TAGS der starter med _ (underscore)
>>
>
>
> Og så den metode som allerede er standardisert for at brukerdefinere
> tags;
>
>    1 EVEN
>    2 TYPE
>
> Både ved import og eksport.
>
> Og så må det skilles mellom innebyggede standardtags og muligheten for
> at brukeren kan definere sine tags utfra standardisert oppbygging.
>
Hvorfor vil du det da Torleif, dersom vi (og du) ønsker å etablere en ny
standard for slektsprogrammer, - en som ikke er programvareavhengig.

mvh kjell

---

On Thu, 18 Mar 2004 20:30:53 +0100, Kjell Henry Skåden wrote:

>torleif haugødegård skrev:
>> ...
>> Og så den metode som allerede er standardisert for at brukerdefinere
>> tags;
>>
>>    1 EVEN
>>    2 TYPE
>>
>> Både ved import og eksport.
>>
>> ...
>
>Hvorfor vil du det da Torleif, dersom vi (og du) ønsker å etablere en ny
>standard for slektsprogrammer, - en som ikke er programvareavhengig.

GEDCOM 5.5 STANDARDEN siger om EVEN/TYPE:

Lineage-Linked GEDCOM Form bruger TYPE tag til yderligere at
klassificere det overordnede tag *for brugerne*. Værdi/indholds-delen
i TYPE tag har *IKKE* til formål at instruere et computerprogram i
hvorledes data skal behandles. Forskellen mellem dette tags indhold og
indholdet i en NOTE, er at fremvisningssystemer altid skal fremvise
TYPE indholdet når der fremvises data fra den tilknyttede kontekst.
Dette giver brugerne lidt fleksibilitet mht. yderligere at *beskrive
den fremviste information*, men kræver *IKKE* at softwaren skal
genkende og reagere på det brede udvalg af qualifiers der kan være
brugt. Som f.eks.:

1 EVEN
2 TYPE Awarded BSA Eagle Rank
2 DATE 1980

Dette har - iht. GEDCOM 5.5 STANDARDEN - absolut intet med
brugerdefinerede tags at gøre.

mvh
Arne

---

"aafe" <intet@svar.dk> wrote in message
news:elcl50t8grd0hlb9pee18jufuokveo4vhn@4ax.com...
> On Thu, 18 Mar 2004 20:30:53 +0100, Kjell Henry Skåden wrote:
...............
> 1 EVEN
> 2 TYPE Awarded BSA Eagle Rank
> 2 DATE 1980
>
> Dette har - iht. GEDCOM 5.5 STANDARDEN - absolut intet med
> brugerdefinerede tags at gøre.
.............
(OBD) Neivelnei.
Gratulerer med en innsiktsfull bemerkning.

---

On Fri, 19 Mar 2004 14:11:55 +0100, "Ole Bjørn Darrud" wrote:

>(OBD) Neivelnei.
>Gratulerer med en innsiktsfull bemerkning.
>

Ja, vi har tydeligvis forskellige interesser!

---

"aafe" <intet@svar.dk> wrote in message
news:j5tl505e9p7fgi4htihi85sqbv9odrm634@4ax.com...
> On Fri, 19 Mar 2004 14:11:55 +0100, "Ole Bjørn Darrud" wrote:
>
> >(OBD) Neivelnei.
> >Gratulerer med en innsiktsfull bemerkning.
> >
>
> Ja, vi har tydeligvis forskellige interesser!

(OBD) Dette har ikke noe med mine interesser å gjøre.
Mener du på alvor at EVEN/TYPE ikke kan benyttes som løsning på
egendefinerte tags i Gedcom 5.5?
Mvh
Ole Bjørn

---

On Sat, 20 Mar 2004 07:30:10 +0100, "Ole Bjørn Darrud" wrote:

>Mener du på alvor at EVEN/TYPE ikke kan benyttes som løsning på
>egendefinerte tags i Gedcom 5.5?

EVEN og TYPE er i forvejen defineret som tags i GEDCOM 5.5 standarden,
og når du ikke kan forstå det, er der nok ikke noget at gøre ved det,
og derfor skal du ikke forvente yderligere svar/kommentarer fra min
side!

---

"aafe" <intet@svar.dk> wrote in message
news:48sn5058c8n6g4b11038816cbbasueahih@4ax.com...
> On Sat, 20 Mar 2004 07:30:10 +0100, "Ole Bjørn Darrud" wrote:
>
> >Mener du på alvor at EVEN/TYPE ikke kan benyttes som løsning på
> >egendefinerte tags i Gedcom 5.5?
>
> EVEN og TYPE er i forvejen defineret som tags i GEDCOM 5.5 standarden,
> og når du ikke kan forstå det, er der nok ikke noget at gøre ved det,
> og derfor skal du ikke forvente yderligere svar/kommentarer fra min
> side!
>

(OBD) Hmmm...
Dersom vi er enige om at EVEN/TYPE er en mulighet i 5.5 for egendefinerte
hendelser, så er saken klar.
Hvorfor da bruke mye energi på å utvikle "klasser" av gedcom eller
"underscore"?
Underlig.
Mvh
Ole Bjørn

---

Sat, 20 Mar 2004 09:52:30 +0100, in dk.videnskab.historie.genealogi,
"Ole Bjørn Darrud" <darrud@online.no> wrote:

>
>"aafe" <intet@svar.dk> wrote in message
>news:48sn5058c8n6g4b11038816cbbasueahih@4ax.com...
>> On Sat, 20 Mar 2004 07:30:10 +0100, "Ole Bjørn Darrud" wrote:
>>
>> >Mener du på alvor at EVEN/TYPE ikke kan benyttes som løsning på
>> >egendefinerte tags i Gedcom 5.5?
>>
>> EVEN og TYPE er i forvejen defineret som tags i GEDCOM 5.5 standarden,
>> og når du ikke kan forstå det, er der nok ikke noget at gøre ved det,
>> og derfor skal du ikke forvente yderligere svar/kommentarer fra min
>> side!
>>
>
>(OBD) Hmmm...
>Dersom vi er enige om at EVEN/TYPE er en mulighet i 5.5 for egendefinerte
>hendelser, så er saken klar.
>Hvorfor da bruke mye energi på å utvikle "klasser" av gedcom eller
>"underscore"?
>Underlig.

Her kan man igjen starte en evinderlig diskusjon, men det er klart at
begge løsningene

EVEN/TYPE
og
_ (underscore)

er legal bruk av regelverket for GEDCOM5.5

** EVENT/TYPE
En ulempe med EVEN/TYPE er at brukeren selv lager sine koder og som da
overføres til brukeren med den betydning og det naven som brukeren selv
vil ha. Det er ingen konvertering til noe språk om hva teksten betyr.
Den kan være skrevet på norsk, dansk, svensk eller hva og mottater vil
ikke forstå hva dette betyr, f.eks. "borgerlig konfirmasjon" sendt til
en som kan fransk.

Fordelen med det samme er den store frihet brukeren har til å definere
alt fritt og rett frem uten å tenke igjennom om det allerede finnes
koder til akkurat denne hendelsen

** _ (underscore)
Bruk av _ (underscore) rydder unna problematikken med språk. Alle slik
koder er laget av produsenten til å dekke akkutte behov som finnes
utover standard GEDCOM5.5
En fil sendt over til en annen bruker, vil få med seg en oversettelse
til aktuell kode og mottaker vil da lett finne dette plassert.
koden er entydig og mer spesifisert i innehold enn TYPE /EVENT og alle
program som kan lese en kode som starter med _ (underscore) vil ha en
entydig opplysning

Ulempen med det siste, er litt lite oversikt over disse koden og stor
kreativitet.
Imidlertid vises nederst på
http://home.online.no/~otjoerge/bk/gedcom_trans.htm
at dette ikke er noe uvanlig.
Her vises også (desverre) at en rekke produsenter bryter det basale i
GEDCOM 5.5. ved å lage egne koder og ikke markere disse inn som
"produsent produserte koder".
Denne svikt gjelder også at mange koder som er nevnt er fra tidligere
versjoner av GEDCOM og burde ved nyere versjoner av sine program, enten
markeres klart at "denne GEDCOM lages med grunnlag i eldre versjoner av
GEDCOM". Hvis det ikke er slike angivelser i programmet, bør alle
program kun kjøre ren GEDCOM 5.5 og for kodeverk som ikke tilfredstiller
dette, bør kodene starte med _ (underscore)
Noen program klarer imidlertid dette, f.eks.

_MARN {PAF 5.1.12.0}: = Married name = Navn som gift
_MARN {BKW6}: = Married name = Navn som gift

to program bruker samme kode og det er ikke noe problem å lese inn en
GEDCOM fra PAF til BKW6 eller omvendt

Dette viser om et samarbeid mellom to programmer som også viser at det
er økt behov for kodeverk utover GEDCOM5.5 og at produsentene har gått
sammen om det som ligger innenfor regelverket.

Det som er mer ille er de nederste kodene hvor hele regelverket brytes,
med andre ord alle de koder som her ikke er GEDCOM5.5 og hvor kodene
ikke starter med _ (underscore) og heller ikke er i form TYPE/EVEN
Disse kodene skaper virkelig trøbbel for overføring mellom ulike program

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

---

On Sat, 20 Mar 2004 09:52:30 +0100, "Ole Bjørn Darrud" wrote et eller
andet:
PLONK

---

aafe <intet@svar.dk> skrev:
19 Mar 2004 09:51:08 +0100 i dk.videnskab.historie.genealogi

>GEDCOM 5.5 STANDARDEN siger om EVEN/TYPE:
>
>Lineage-Linked GEDCOM Form bruger TYPE tag til yderligere at
>klassificere det overordnede tag *for brugerne*. Værdi/indholds-delen
>i TYPE tag har *IKKE* til formål at instruere et computerprogram i
>hvorledes data skal behandles.........
>Dette har - iht. GEDCOM 5.5 STANDARDEN - absolut intet med
>brugerdefinerede tags at gøre.

Jeg var ikke klar over at der fandtes en officiel Dansk
oversættelse af Gedcom 5.5

I min version læser jeg:

***************
The EVEN tag in this structure is for recording general events
that are not shown in the above <<INDIVIDUAL_EVENT_STRUCTURE>>.
The event indicated by this general EVEN tag is defined by the
value of the subordinate TYPE tag.

For example, a person that signed a lease for land dated October
2, 1837 and a lease for equipment dated November 4, 1837 would be
written in GEDCOM as::
1 EVEN
2 TYPE Land Lease
2 DATE 2 OCT 1837
1 EVEN
2 TYPE Equipment Lease
2 DATE 4 NOV 1837
**************

Jeg kan ikke se andet end at:

" general events that are not shown in the above
<<INDIVIDUAL_EVENT_STRUCTURE>> "

må være det samme som det du kalder brugerdefinerede tags.


Erik Helmer Nielsen

---

On Fri, 19 Mar 2004 16:14:53 +0100, Erik Helmer Nielsen wrote:

>Jeg var ikke klar over at der fandtes en officiel Dansk
>oversættelse af Gedcom 5.5

Det havde unægtelig været sjovere, hvis du havde været istand til at
argumentere sagligt, når du sådan føler dine interesser gået for nær.

Men, det kunne du altså ikke, så istedet satser du på lidt godt
gammeldags tilsvining, hvor du prøver at give gruppens deltagere
indtryk af, at jeg forleder dem, og fylder dem med løgn. Og det prøver
du så at bevise, ved at lægge en helt anden tekst frem, end den jeg
var så venlig at oversætte til dansk.

>
>I min version læser jeg:
>
>***************
>The EVEN tag in this structure is for recording general events
>that are not shown in the above <<INDIVIDUAL_EVENT_STRUCTURE>>.
>The event indicated by this general EVEN tag is defined by the
>value of the subordinate TYPE tag. ...

Det du der har fundet frem, har intet at gøre med det afsnit jeg
oversatte. Det afsnit jeg oversatte findes i kapitel2, afsnittet om
*Lineage-Linked Form Usage Conventions* og det tredje underpunkt
(starter med bullet), der på udenbysk ser således ud:

"The Lineage-Linked GEDCOM Form uses the TYPE tag to further classify
its superior tag for the viewer. The value portion given by the TYPE
tag is not intended to inform a computer program how to process the
data. The difference between this value and a note value is that
displaying systems should always display the type value when they
display the data from the associated context. This gives the user some
flexibility in further describing the informationprovided but does not
require the software to recognize and respond to the large variety
qualifiers that might be used. For example:

1 EVEN
2 TYPE Awarded BSA Eagle Rank
2 DATE 1980"

Så skulle den side af sagen vist være sat på plads - ihvertfald hos de
af gruppens deltagere, der forstår engelsk.

Hvad angår brugerdefinerede TAGS, er det - som ordet siger - tags, der
ikke er defineret og beskrevet i GEDCOM standarden. Og for EVEN og
TYPE tags gælder, at de begge er defineret og beskrevet i GEDCOM
standarden.

Hvad angår begrebet "brugerdefineret", nævnes der flere steder i
GEDCOM standarden, at det der i standarden forstås som brugere, ikke
er de mennesker, der sender gedcomfiler til hinanden, men derimod er
de programproducenter, der "bruger" gedcom import/eksport i deres
produkter.

Brugerdefinerede TAGS er kendetegnet ved, ikke at være defineret og
beskrevet i GEDCOM standarden, udover at brugerdefinerede TAGS, der
starter med en underscore er "tilladt" i gedcomfiler. Dog således at
sådanne brugerdefinerede tags kun kan *forventes* forstået ud fra det
afsendende programs kontekst.

For EVEN og TYPE gælder som sagt, at de begge er defineret og
beskrevet i GEDCOM standarden.

---

Fri, 19 Mar 2004 09:51:08 +0100, in dk.videnskab.historie.genealogi,
aafe <intet@svar.dk> wrote:

>On Thu, 18 Mar 2004 20:30:53 +0100, Kjell Henry Skåden wrote:
>
>>torleif haugødegård skrev:
>>> ...
>>> Og så den metode som allerede er standardisert for at brukerdefinere
>>> tags;
>>>
>>>    1 EVEN
>>>    2 TYPE
>>>
>>> Både ved import og eksport.
>>>
>>> ...
>>
>>Hvorfor vil du det da Torleif, dersom vi (og du) ønsker å etablere en ny
>>standard for slektsprogrammer, - en som ikke er programvareavhengig.
>
>GEDCOM 5.5 STANDARDEN siger om EVEN/TYPE:
>
>Lineage-Linked GEDCOM Form bruger TYPE tag til yderligere at
>klassificere det overordnede tag *for brugerne*. Værdi/indholds-delen
>i TYPE tag har *IKKE* til formål at instruere et computerprogram i
>hvorledes data skal behandles. Forskellen mellem dette tags indhold og
>indholdet i en NOTE, er at fremvisningssystemer altid skal fremvise
>TYPE indholdet når der fremvises data fra den tilknyttede kontekst.
>Dette giver brugerne lidt fleksibilitet mht. yderligere at *beskrive
>den fremviste information*, men kræver *IKKE* at softwaren skal
>genkende og reagere på det brede udvalg af qualifiers der kan være
>brugt. Som f.eks.:
>
> 1 EVEN
> 2 TYPE Awarded BSA Eagle Rank
> 2 DATE 1980
>
>Dette har - iht. GEDCOM 5.5 STANDARDEN - absolut intet med
>brugerdefinerede tags at gøre.
>
tja, mon tro det.

Dette er ofte den deinering som ligger til brukeren å gjøre ved at
programmøren legger inn denne muligheten.

Dette gjerne i motsetning til koder som starter med "underscore" hvor
det er hardkodet i programmet.

Tar jeg ikke feil er begge disse definert i programmet rundt begrepet
"user".
Spørsmålet blir vel om "user" her er beregnet på den som skal bruke
GEDCOM5.5 til sitt bruk i utvikling av GEDCOM i programmet eller den
derpåfølgende "bruker" av programmet.

Det er neppe for de fleste spesiellt aktuell for brukerne å sette seg
inn i GEDCOM. Brukerne i denne sammenheng setter vel sin tillitt til at
programmøren har gjordt jobben som "bruker" av spesifikasjoner av GEDCOM
?

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

---

> www.gedcom-nordic.org
>
> Der går lige nogle dage inden den er aktiv.
> Alle udgifter i forbindelse med oprettelse og drift det skal jeg nok
betale.
>

Som en start indtil www.gedcom-nordic.org linket er på plads har jeg oprette
filerne på følgende web-adresse:

www.brotherskeeper.dk/gedcom-nordic/


Med venlig hilsen
Chris Gade Oxholm Sørensen - www.brotherskeeper.dk -
support@brotherskeeper.dk

---

On Thu, 18 Mar 2004 22:45:08 +0100, <support@bk6.dk> wrote:

>Som en start indtil www.gedcom-nordic.org linket er på plads har jeg oprette
>filerne på følgende web-adresse:
>
>www.brotherskeeper.dk/gedcom-nordic/
>

som en slags for-smagsprøve har jeg lagt en lille pre-beta pakke ud i
news:dk.binaer.historie, hvor den forhåbentligt dukker op inden så
længe.

Gedcom'en kan og skal naturligvis ikke bruges rigtigt i denne udgave,
der primært kan tjene som et diskussions supplement, men som
selvfølgelig godt kan give et fingerpeg om, hvad programmerne kan
vente sig

Men altså primært et diskussionssupplement.

mvh
Arne

---

On Thu, 18 Mar 2004 17:32:07 +0100, <support@bk6.dk> wrote:

> For at komme igang har jeg nu bestilt følgende web-adresse:
> www.gedcom-nordic.org

Tak for dit initiativ!

Jeg tror det er meget godt at få eget hjemsted med tilhørende
debatfora osv. - en anden mulighed havde været, at etablere sig hos
SourceForge, hvor vi ville få en masse faciliteter stillet frit til
rådighed, og herunder også deres CVS-system, der muliggør, at flere
kan arbejde samtidigt på de samme ting osv., men hvor ulempen er, at
det hele vist nok skal foregå på engelsk.

> I første omgang vil jeg få opstillet en liste på GEDCOM opdelt i de 3
> klasser.
>
> Klasse I
> Indeholder de mest basale TAGS
> Klasse II
> Indeholder væsentlige TAGS fra GEDCOM 5.5
> Klasse III
> Indeholder alle øvrige TAGS samt TAGS der starter med _ (underscore)
>
> [Ovenstående er et forslag til opdeling]

Jeg havde egentlig forestillet mig den stik modsatte lagdeling, hvor
klasse I (første klasse) var toppen af kransekagen, fordi vi
sædvanligvis opfatter en første klasses vare som det bedste, mens en
anden klasses vare er lidt mindre osv.

> Foruden denne opdeling mener jeg der skal være en standard GEDCOM fil for
> hver af de 2 vigtigste Klasser, hvormed der kan foretages en test med.

Ja, min tanke var ikke at lave en ny standard, men at lave tre
forskellige gedcomfiler der hver især skulle svare til en af de
nordiske klasser. Og samtidig at lave tre tilsvarende .grm filer, der
så enten skal kunne bruges sammen med GEDCHK.EXE eller Gedcom
Explorer. Og, det vil så igen sige, at vi skal have diskuteret/stemt
om, hvorvidt vi vil bruge GEDCHK.EXE eller Gedcom Explorer til vores
test.

Gedcomfilerne skal bruges til at teste slægtsprogrammernes
gedcom-import evne. Og, .gmr filerne skal bruges af vores testprogram,
til at teste slægtsprogrammernes gedcom-export evne. Derudover skal vi
naturligvis teste slægtsprogrammernes evne til at kunne genimportere
den GEDCOM kode slægtsprogrammerne selv har produceret.

> Hertil bør der være en oversigt over hvilke slægtsforskningsprogrammer der
> overholder henholdsvis Klasse I og II. (import/eksport)

Ja, en af GEDCOM standardens svagheder er netop, at det er
programproducenterne selv der afgør, hvorvidt deres programmer
overholder GEDCOM eller ej. Kapitel 4 i GEDCOM standarden omhandler
ellers produktregistrering, der indebærer at LDS-Kirken afgør, hvem
der opfylder GEDCOM standarden og dermed har ret til at hævde, at de
opfylder GEDCOM standarden: Men, kontrollen virker tilsyneladende ikke
særlig godt.

> For at få www.gedcom-nordic.org til at være anvendelig, er der behov for
> følgende:
>
> En der kan fremstille de nødvendige GEDCOM-nordic GED filer.

Jeg vil foreslå, at vi tager udgangspunkt i en eksisterende gedcomfil
som f.eks. den tidligere omtalte master.ged, og at vi derefter
diskuterer, hvad der hhv. skal udbygges med, eller evt. pilles ud. De
tre klasser kan så diskuteres i hvert sit debatforum.

> En eller flere der kan hjælpe med at få fremstillet en god web-side.
> Der som et krav skal indeholde et debatforum
> En der er tilstrækkelig god til engelsk, således at en vedtaget betydning
> for de enkelte TAGS kan oversættes korret til engelsk.
> Foruden dansk/engelsk mener jeg der er behov for en oversættelse som minimum
> til norsk og svensk.

Ja, jeg håber også at folk melder sig, og støtter op om initiativet.

En af de første diskussioner vi måske skal have, er vel, om vi kan
være enige om, at vi ikke laver en ny/anderledes GEDCOM standard, men
at vi i stedet fastlægger nogle klasser indenfor den eksisterende
standards rammer, som slægtsprogrammerne skal kunne opfylde.

Med venlig hilsen

Arne
Ps. Hvor skal www.gedcom-nordic.org hostes ? Og understøtter det pgl.
sted PHP, MySQL og Perl ?

---

> > For at komme igang har jeg nu bestilt følgende web-adresse:
> > www.gedcom-nordic.org
>
> Tak for dit initiativ!
>
> Jeg tror det er meget godt at få eget hjemsted med tilhørende
> debatfora osv. - en anden mulighed havde været, at etablere sig hos
> SourceForge, hvor vi ville få en masse faciliteter stillet frit til
> rådighed, og herunder også deres CVS-system, der muliggør, at flere
> kan arbejde samtidigt på de samme ting osv., men hvor ulempen er, at
> det hele vist nok skal foregå på engelsk.

Ok - når web-siden kommer rigtigt op er der også mulighed for mange
forskellige til her bl.a. debatforum.


> > I første omgang vil jeg få opstillet en liste på GEDCOM opdelt i de 3
> > klasser.
> >
> > Klasse I
> > Indeholder de mest basale TAGS
> > Klasse II
> > Indeholder væsentlige TAGS fra GEDCOM 5.5
> > Klasse III
> > Indeholder alle øvrige TAGS samt TAGS der starter med _ (underscore)
> >
> > [Ovenstående er et forslag til opdeling]
>
> Jeg havde egentlig forestillet mig den stik modsatte lagdeling, hvor
> klasse I (første klasse) var toppen af kransekagen, fordi vi
> sædvanligvis opfatter en første klasses vare som det bedste, mens en
> anden klasses vare er lidt mindre osv.

Den er jeg med på
Bliver rettet i filerne der nu ligger på
www.brotherskeeper.dk/gedcom-nordic/


> Ja, min tanke var ikke at lave en ny standard, men at lave tre
> forskellige gedcomfiler der hver især skulle svare til en af de
> nordiske klasser. Og samtidig at lave tre tilsvarende .grm filer, der
> så enten skal kunne bruges sammen med GEDCHK.EXE eller Gedcom
> Explorer. Og, det vil så igen sige, at vi skal have diskuteret/stemt
> om, hvorvidt vi vil bruge GEDCHK.EXE eller Gedcom Explorer til vores
> test.

Enig


> Gedcomfilerne skal bruges til at teste slægtsprogrammernes
> gedcom-import evne. Og, .gmr filerne skal bruges af vores testprogram,
> til at teste slægtsprogrammernes gedcom-export evne. Derudover skal vi
> naturligvis teste slægtsprogrammernes evne til at kunne genimportere
> den GEDCOM kode slægtsprogrammerne selv har produceret.

Også enig


> > Hertil bør der være en oversigt over hvilke slægtsforskningsprogrammer
der
> > overholder henholdsvis Klasse I og II. (import/eksport)
>
> Ja, en af GEDCOM standardens svagheder er netop, at det er
> programproducenterne selv der afgør, hvorvidt deres programmer
> overholder GEDCOM eller ej. Kapitel 4 i GEDCOM standarden omhandler
> ellers produktregistrering, der indebærer at LDS-Kirken afgør, hvem
> der opfylder GEDCOM standarden og dermed har ret til at hævde, at de
> opfylder GEDCOM standarden: Men, kontrollen virker tilsyneladende ikke
> særlig godt.

Eller producenterne antager at de bliver godkendt

>
> > For at få www.gedcom-nordic.org til at være anvendelig, er der behov for
> > følgende:
> >
> > En der kan fremstille de nødvendige GEDCOM-nordic GED filer.
>
> Jeg vil foreslå, at vi tager udgangspunkt i en eksisterende gedcomfil
> som f.eks. den tidligere omtalte master.ged, og at vi derefter
> diskuterer, hvad der hhv. skal udbygges med, eller evt. pilles ud. De
> tre klasser kan så diskuteres i hvert sit debatforum.

Ja - men delvis enig - mener at der en fordel at alle klasserne holdes i
samme forum

> > En eller flere der kan hjælpe med at få fremstillet en god web-side.
> > Der som et krav skal indeholde et debatforum
> > En der er tilstrækkelig god til engelsk, således at en vedtaget
betydning
> > for de enkelte TAGS kan oversættes korret til engelsk.
> > Foruden dansk/engelsk mener jeg der er behov for en oversættelse som
minimum
> > til norsk og svensk.
>
> Ja, jeg håber også at folk melder sig, og støtter op om initiativet.
>
> En af de første diskussioner vi måske skal have, er vel, om vi kan
> være enige om, at vi ikke laver en ny/anderledes GEDCOM standard, men
> at vi i stedet fastlægger nogle klasser indenfor den eksisterende
> standards rammer, som slægtsprogrammerne skal kunne opfylde.

Helt enig

Med venlig hilsen
Chris Gade Oxholm Sørensen - www.brotherskeeper.dk -
support@brotherskeeper.dk

---

In article <405a249f$0$304$edfadb0f@dread12.news.tele.dk>,
<support@bk6.dk> wrote:

> > > For at komme igang har jeg nu bestilt følgende web-adresse:
> > > www.gedcom-nordic.org
> >
Har fulgt med på diskusjonen og kikket litt på det programmet jeg selv
har ovesatt til norsk - Reunion. Her er det nok mye merkelig. Nedenfor
følger en oversikt over hva jeg i farten ekstraherte ut fra en
gedcomstring i programmet, Noe kan ha gått tapt og alle forklarende ord
er utelatt - men allikevel ;-(

Blandede hendelser EVEN
Født BIRT
Død DEAT
ekteskap MARR
Ugift UMAR
Sambo CLAW
Separerte SEPA
Annullert ANUL
Skilt DIV
Begravet BURI
Døpt CHR
Besegle barn SLGC
Dåp BAPM
Dåp SDH BAPL
Bar Mitzvah BARM
Bas Mitzvah BASM
Velsignelse BLESS
Kremert CREM
Gave ENDL
Konfirmation CONF
Konfirmation (SDH) CONL
Første nattverd FCOM
Examen (vid) GRAD
Immigration IMMI
Emigration EMIG
Fikk statsborgerskap NATU
Pension RETI
Adoptert ADOP
Census (USA) CENS
Statsborger CITN
Ansatt EMPL
Utmerkelser HONO
Landkjøp PURC
Prestevigsel ORDN
Residens RESI
Forlovelse ENGA
Separert SEPA
Søkte om skilsmisse DIVF
ekteskapslisens MARL
Residens RESI R
Besegle partner SLGS
Diverse hendelser EVEN
Navn som gift NAMM
Utdannelse EDUC
Yrke OCCU
Religion RELI
Ane-Intr.nivå ANCI
Anst Fil# AFN
Alias ALIA
DødsÅrsak CAUS
Hudfarg COLO
Ak.examen DEGR
Beskrivelse DESC
øyefarge EYES
HÅrfarge HAIR
Lengde HEIG
Hobbys HOBB
Utmerkelser HONO
Referanse # REFN
Pers.nr. # SSN
Rase RACE
Nasjonalitet NATI
Religiøst navn NAMR
Navne NAMS
Vekt WEIG
Notiser NOTE
Militært MILI
Medisinskt HEAL
Forskning HIST
Notiser NOTE
Presteskap CLER
Militær MILF
Tidligste ane EARL
Forskning komplett COMP
Privat PRIV
Forfatter AUTH
Tittel TITL
Bok/Periodiskt navn PERI
ID nummer CALN
Sammenstiller CPLR
Kontaktperson CNTC
Copyright COPR
Dato DATE
Lest DATV
Detalj DETA
Utgave EDTN
Editor EDTR
Filnavn FILE
Filnummer FILN
Filmnummer FILM
Informatør INFT
intervjuperson INTE
Intervjuer INTV
Utgave ISSU
Bibliotek/Arkiv REPO
Lokalitet PLAC
Kildens plassering LOCA
Mediatype MEDI
eier OWNR
Utgivernavn (plass og dato) PUBL
Side PAGE
Datakvalitet QUAY
Notarie RECO
Register REGI
Oppbevaringssted REPO
Opplysningskilde SUBM
URL URL
Volumnummer VOL

Fritext
Bok AUTH,PERI,EDTR,PUBL,VOL,PAGE
CD ROM TITL,VOL,EDTN,SUBM,REGI,PUBL
Census (USA) TITL,PLAC,DATE,MEDI,LOCA,DATV
Gerning TITL,DATE,REGI,LOCA
E-Mail beskjed AUTH,TITL,DATE,LOCA
Familiebibel TITL,PERI,PUBL,OWNR,LOCA,MEDI
Gedcomfil TITL,DATE,SUBM,FORM
Genline ID (GID) TITL,CALN,URL,DATE,NOTE
Intervju TITL,DATE,INTV,PLAC,REPO
Brev TITL,DATE,LOCA
Tidning TITL,PERI,PLAC,DATE,PAGE,MEDI,LOCA
Periodisk skrift AUTH,TITL,PERI,VOL,DATE
Taxeringskalender TITL,PLAC,DATE,REGI,MEDI,LOCA
Fødselsbok TITL,DATE,PLAC,FILN,REGI,MEDI,LOCA,CALN
Dødsbok TITL,DATE,PLAC,FILN,REGI,MEDI,LOCA,CALN
Vigselsbok TITL,DATE,PLAC,FILN,REGI,MEDI,LOCA,CALN
Husførhørslengd TITL,DATE,PLAC,FILN,REGI,MEDI,LOCA,CALN
Bok over ikke tilstedeværende TITL,DATE,PLAC,FILN,REGI,MEDI,LOCA,CALN
Innflyttningsregister TITL,DATE,PLAC,FILN,REGI,MEDI,LOCA,CALN
Utflyttningsregister TITL,DATE,PLAC,FILN,REGI,MEDI,LOCA,CALN
Kommunionsregister TITL,DATE,PLAC,FILN,REGI,MEDI,LOCA,CALN
Sockenstemmoprotokoll TITL,DATE,PLAC,FILN,REGI,MEDI,LOCA,CALN
Regnskaper TITL,DATE,PLAC,FILN,REGI,MEDI,LOCA,CALN
Domsbok TITL,DATE,PLAC,FILN,REGI,MEDI,LOCA,CALN
Boligopptegnelse TITL,DATE,PLAC,FILN,REGI,MEDI,LOCA,CALN
Militærruller TITL,DATE,PLAC,FILN,REGI,MEDI,LOCA,CALN
Passasjerliste TITL,DATE,PLAC,FILN,REGI,MEDI,LOCA,CALN
Webside AUTH,TITL,URL,DATE
Testamente TITL,FILN,REGI,LOCA

--
Stein Ole Kjær
steinole@broadpark.no.nospam

---

Fri, 19 Mar 2004 00:13:46 +0100, in dk.videnskab.historie.genealogi,
Stein Ole Kjær <steinole@broadpark.no.nospam> wrote:

>In article <405a249f$0$304$edfadb0f@dread12.news.tele.dk>,
> <support@bk6.dk> wrote:
>
>> > > For at komme igang har jeg nu bestilt følgende web-adresse:
>> > > www.gedcom-nordic.org
>> >
>Har fulgt med på diskusjonen og kikket litt på det programmet jeg selv
>har ovesatt til norsk - Reunion. Her er det nok mye merkelig. Nedenfor
>følger en oversikt over hva jeg i farten ekstraherte ut fra en
>gedcomstring i programmet, Noe kan ha gått tapt og alle forklarende ord
>er utelatt - men allikevel ;-(
>


hvillken programversjon har du.
Jeg kunne tenke å legge tillegget som ikke er i GEDCOM 5.5 inn i
oversikten på http://home.online.no/~otjoerge/bk/gedcom_trans.htm

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

---

<support@bk6.dk> skrev Thu, 18 Mar 2004 17:32:07 +0100

>For at komme igang har jeg nu bestilt følgende web-adresse:
>www.gedcom-nordic.org
>
Godt initiativ - at reservere domænet altså.

Men jeg håber da at det er med henblik på at overdrage det til
DIS-Danmark, eller hvem der nu måtte komme til stå som fadder til
projektet.?

Et projekt af den her art - og et domæne under 'org' - signalerer
komplet og aldeles uafhængighed.

Og selv om jeg overhovdet ikke mistænker dig for at ville udnytte
domænet i forbindelse med din forhandling af et bestemt program, så vil
bare mistanken om noget sådant være nok til at ødelægge hele projektet.


--
mvh, A:\Feldborg

Folketællinger Hammerum og Bølling herreder, kirkebøger Hammerum herred
http://www.haunstrup.dk/feldborg/genealogi/download/

---

> >For at komme igang har jeg nu bestilt følgende web-adresse:
> >www.gedcom-nordic.org
> >
> Godt initiativ - at reservere domænet altså.

TAk

> Men jeg håber da at det er med henblik på at overdrage det til
> DIS-Danmark, eller hvem der nu måtte komme til stå som fadder til
> projektet.?

Gerne for mig - men som medstarter er jeg gerne med fra start.
Jeg håber at der er tilstrækkelig mange der vil være med til at løfte
opgaven.
Så i første omgang er det initiativet det gælder.

>
> Et projekt af den her art - og et domæne under 'org' - signalerer
> komplet og aldeles uafhængighed.

Netop - og ideen er også at ved at bruge 'org' er at det ikke vil blive
opfattet som noget lokalt i Danmark - men mere internationalt, hvormed
specielt de amerikanske producenter vil vende blikket på dette tiltag - hvad
de sandsynligvis ikke ville hvis det var f.eks. en 'dk' adresse. Jeg kunne
også have valgt 'com' - men her opfatter jeg det mere som noget med penge -
og det er *det* ikke.


> Og selv om jeg overhovdet ikke mistænker dig for at ville udnytte
> domænet i forbindelse med din forhandling af et bestemt program, så vil
> bare mistanken om noget sådant være nok til at ødelægge hele projektet.

Helt enig - derfor skrev jeg at det KUN var foreløbigt at siderne var lagt
ind på www.brotherskeeper.dk/gedcom-nordic/
Så snart web-holtellet er klar - holdes der flyttedag.
Som der allerede kan ses er kendte slægtsprogrammer langt op i alfabetisk
orden og INGEN er af disse er klassificeret.
Klassificeringen af de enklete programmer *skal* foregå på måde og hvad det
så vil betyde for de enkelte programmer vil tiden vise.

Mit forehavende er helt klart at få BK opgraderet ved producenten således at
BK opfylder de krav der nu måtte gælde. Det samme forventer jeg også af
andre repræsentanter vil gøre.
Det første tiltag/interesse kan jeg se der er kommet fra Stein Ole Kjær
(Reunion).

Dette viser at netop ideen er rigtig.

Med venlig hilsen
Chris Gade Oxholm Sørensen - www.brotherskeeper.dk -
support@brotherskeeper.dk

---

aafe skrev:
> En alternativ måde at arbejde med GEDCOM standarden på, kunne være, at
> opstille en nordisk gedcomfil, med alle de tags og
> kombinationsmuligheder i, som vi ønsker alle slægtsprogrammer skal
> kunne håndtere.
>
> Der kan evt. opstilles 3 forskellige nordiske gedcomfiler, såsom en
> minimums gedcom, en standard gedcom og endelig den store forkromede
> model, der afspejler alle vores ønsker/krav fuldt ud.
>
> Guleroden til slægtsprogramsproducenterne vil så være, at de kan
> reklamere med at være kompatibel med GEDCOM-Nordic i klasse I,
> klasse II eller klasse III.
>
Synes ditt forslag har meget i seg. På en slik måte må levereandører
dokumentere og vi kan velge den kompabilitet som gir oss "beste vare for
beste valutta".

Hvem er det som sier at Slektsforskning skal være en "individuell
sport", hvor alle slektsforskere kjemper mot alle.

Slektsforskning er å dokumentere at tilgjengelige kildedata har
nødvendig pålitelighet.
Slektsprogrammer må derfor inneholde all funksjonalitet som kreves for
at data registreres, lagres, behandles, presenteres og overføres (også
mello9m programmer) på en ensartet og vedtatt metodikk.

Selv om jeg personlig hadde ønsket 1-en-standard er ditt forslag om å
"lokke" med disse GEDCOM-NORDIC, klasse I, II, III en spennende gullrot

mvh kjell

---

"aafe" <intet@svar.dk> wrote in message
news:fbth505lc1b25jabhkj62r57hodk725pd9@4ax.com...
> En alternativ måde at arbejde med GEDCOM standarden på, kunne være, at
> opstille en nordisk gedcomfil, med alle de tags og
> kombinationsmuligheder i, som vi ønsker alle slægtsprogrammer skal
> kunne håndtere.
>
> Der kan evt. opstilles 3 forskellige nordiske gedcomfiler, såsom en
> minimums gedcom, en standard gedcom og endelig den store forkromede
> model, der afspejler alle vores ønsker/krav fuldt ud.
>
> Guleroden til slægtsprogramsproducenterne vil så være, at de kan
> reklamere med at være kompatibel med GEDCOM-Nordic i klasse I,
> klasse II eller klasse III.
...............
Dette med å ha forskjellige klasser forstår jeg ikke meningen med.
GEDCOM 5.5 har sine mangler, men de trenger ikke gjøres større enn nødvendig
av "proprietære" leverandører som nok har et tendens for å "låse" sine
brukere inne til en viss grad.
GEDCOM 5.5 har et sett med definerte hendelser/tags som burde holde for de
fleste amtørfoskeres behov.
Enkelte program klarer ikke engang å forholde seg til dette....
Videre har GEDCOM 5.5 en generell mulighet til å importere/eksportere
egendefinerte hendelser via EVEN/TYPE regelen.
Dersom utviklerne av programmer var villige til å benytte/tolke dette med
litt velvilje så er det svært lite informasjon som ikke lar seg flytte på
mellom slektsprogram.
Enkelte program velger å lage "underscore" tags (= egendefinert
informasjonstype som ikke lar seg _overføre_ via GEDCOM) fremfor å brnytte
den åpne EVEN/TYPE muligheten.

Oppsummert; GEDCOM 5.5 er den "standarden" som finnes idag og inntil noen
har kommet opp med et alternativ som man kan enes om bør utviklerne av
program vise mer vilje til å bruke/tolke denne til en slektsforskers beste.
Det er svært lite informasjon som ikke kan overføres via GEDCOM 5.5 idag.

Mvh
Ole Bjørn

---

On Fri, 19 Mar 2004 07:07:59 +0100, "Ole Bjørn Darrud" wrote:

>Dette med å ha forskjellige klasser forstår jeg ikke meningen med.
>GEDCOM 5.5 har sine mangler, men de trenger ikke gjøres større enn nødvendig
>av "proprietære" leverandører som nok har et tendens for å "låse" sine
>brukere inne til en viss grad.

Vi er ikke, og skal ikke være leverandører på nogen måde, ligesom vi
heller ikke satser på at udvikle proprietære tags eller datamodeller.

Vi låser heller ikke brugerne inde i forskellige klasser.
Klasseinddelingen er en sorteringsstørrelse.

>Oppsummert; GEDCOM 5.5 er den "standarden" som finnes idag og inntil noen
>har kommet opp med et alternativ som man kan enes om bør utviklerne av
>program vise mer vilje til å bruke/tolke denne til en slektsforskers beste.

Vores udgangspunkt er at forholde os til den faktiske GEDCOM standard,
samt til den virkelighed der hersker idag, og herunder ikke at
forfalde til at ville pådutte alle andre programproducenter en enkelt
programproducents ideer om og opfattelse af GEDCOM standarden.

med venlig hilsen

Arne

---

Fri, 19 Mar 2004 07:07:59 +0100, in dk.videnskab.historie.genealogi,
"Ole Bjørn Darrud" <darrud@online.no> wrote:

>Enkelte program velger å lage "underscore" tags (= egendefinert
>informasjonstype som ikke lar seg _overføre_ via GEDCOM) fremfor å brnytte
>den åpne EVEN/TYPE muligheten.

Jeg har vel ikke sett noe problem i at et program lager tag av formen
_(underscore). Problemet er mer at mottakende program ikke er i stand
til å lese inn disse, med untak av de program som har definert samme tag
i sitt program, jfr oversikt på
http://home.online.no/~otjoerge/bk/gedcom_trans.htm


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

---

On Thu, 18 Mar 2004 02:05:07 +0100, aafe wrote:

>Der kan evt. opstilles 3 forskellige nordiske gedcomfiler, såsom en
>minimums gedcom, en standard gedcom og endelig den store forkromede
>model, der afspejler alle vores ønsker/krav fuldt ud.

Jeg vil foreslå, at i hvert fald de to gedcomfiler - af indlysende
grunde - navngives som, tandgnost.ged og tandgrisner.ged - den tredje
gedcom kan så måske - for symbolikkens skyld - navngives som
tjalfet.ged

med venlig hilsen

Arne

---

Sat, 20 Mar 2004 08:31:50 +0100, in dk.videnskab.historie.genealogi,
aafe <intet@svar.dk> wrote:

>On Thu, 18 Mar 2004 02:05:07 +0100, aafe wrote:
>
>>Der kan evt. opstilles 3 forskellige nordiske gedcomfiler, såsom en
>>minimums gedcom, en standard gedcom og endelig den store forkromede
>>model, der afspejler alle vores ønsker/krav fuldt ud.
>
>Jeg vil foreslå, at i hvert fald de to gedcomfiler - af indlysende
>grunde - navngives som, tandgnost.ged og tandgrisner.ged - den tredje
>gedcom kan så måske - for symbolikkens skyld - navngives som
>tjalfet.ged
>
hvorfor det. Det var litt vanskelig for en vestnorsk leser å få med seg
:=))

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

---

On Sat, 20 Mar 2004 08:46:06 +0100, Otto Jørgensen wrote:

>hvorfor det. Det var litt vanskelig for en vestnorsk leser å få med seg
>:=))

Jamen, skal de da så hedde tandgnisle.ged og tandglese.ged ? eller
sagt på en anden måde, hvad hedder de to geder da så på norsk?

med venlig hilsen

Arne

---

Så har jeg lagt et opdateret UDKAST til GEDCOM klassifikation online.
Adressen er: www.brotherskeeper.dk/gedcom-nordic/

Med venlig hilsen
Chris Gade Oxholm Sørensen - www.brotherskeeper.dk -
support@brotherskeeper.dk

---

On Sat, 20 Mar 2004 09:39:18 +0100, <support@bk6.dk> wrote:

>Så har jeg lagt et opdateret UDKAST til GEDCOM klassifikation online.
>Adressen er: www.brotherskeeper.dk/gedcom-nordic/
>
Kopiert fra siden ovenfor:
------------------------------------------------------------------------------------
GEDCOM-nordic er opdelt i 3 klasser.

Klasse I (bedst)
Indeholder GEDCOM-koder fra GEDCOM standard 5.5 samt
programproducenterne egne GEDCOM-koder. For at kunne henregnes til
kategorien Klasse I skal alle GEDCOM-koderne i både Klasse II og III
kunne anvendes i såvel import og eksport.
Oprettelse af egne GEDCOM-koder skal starte _ (underscore)
------------------------------------------------------------------------------------

Noen kommentarer/spørsmål:

A
"GEDCOM-koder fra GEDCOM standard 5.5" bør være de koder som står i
dokumentet "THE GEDCOM STANDARD Release 5.5" av 2 January 1996:

   "Appendix A Lineage-Linked GEDCOM Tag Definition".

B
Hva menes med "samt programproducenterne egne GEDCOM-koder"?

C
"Oprettelse af egne GEDCOM-koder skal starte _ (underscore)" bør
endres til
"Oprettelse af egne GEDCOM-koder skal starte _ (underscore) eller med
metoden EVEN/TYPE".

D
Det er nok med 1 klasse, klasse I.
Og evt. grader (%) av oppfyllelse av denne.
Hvis ikke, hvem definerer hva som "væsentlige GEDCOM-koder" og "basale
GEDCOM-koder"? Har du eksempler på 'basale' koder? BIRT?

E
Det må skilles mellom eksport og import, fordi det er viktig å
_importere_ flest mulige tags. Også tags som er feil, som ikke er
standard 5.5 eller som har vært tidligere standarder (feks 4.0).

F
Siden "Standard GEDCOM-Nordic klasse I"
http://www.brotherskeeper.dk/gedcom-nordic/klasse1.htm
innholder også koder som ikke er std5.5, hvorfor?

Eksempel:
   ARVL {ARRIVAL}
   ATTR {ATTRIBUTES}:

G
Det må kartlegges om programmets bruker gis anledning til å definere
sine egne hendelser m/GEDCOMkode, altså nye hendelser som ikke finnes
som standard i programmet.


---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
tha@tha.no
www.tha.no

---

Sat, 20 Mar 2004 11:06:12 +0100, in dk.videnskab.historie.genealogi,
torleif haugødegård <tha@tha.no> wrote:

>Siden "Standard GEDCOM-Nordic klasse I"
>http://www.brotherskeeper.dk/gedcom-nordic/klasse1.htm
>innholder også koder som ikke er std5.5, hvorfor?
>
>Eksempel:
>   ARVL {ARRIVAL}
>   ATTR {ATTRIBUTES}:

Det står angitt at kodene ikke finnes i std 5.5
I grunnen burde det vel holde.

Det er mer alvorlig hvor det er koder som overhode, så langt ikke
tilfredstiller kodeverket, hverken snevert eller utvidet.

se nederst på en samlet oversikt
http://home.online.no/~otjoerge/bk/gedcom_trans.htm#Not_legal
(så langt) over koder som brukes i ulike program

Spørsmål vil måtte være om koder fra eldre versjoner av GEDCOM skal
inngå eller ei

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

---

On Sat, 20 Mar 2004 11:14:50 +0100, Otto Jørgensen
>Sat, 20 Mar 2004 11:06:12 +0100, in dk.videnskab.historie.genealogi,
>torleif haugødegård <tha@tha.no> wrote:
>
>>Siden "Standard GEDCOM-Nordic klasse I"
>>http://www.brotherskeeper.dk/gedcom-nordic/klasse1.htm
>>innholder også koder som ikke er std5.5, hvorfor?
>>
>>Eksempel:
>>   ARVL {ARRIVAL}
>>   ATTR {ATTRIBUTES}:
>
>Det står angitt at kodene ikke finnes i std 5.5
>I grunnen burde det vel holde.
>
De bør fjernes fra den tabellen som skal innholde tilltatte koder
etter v5.5, det er egen side for disse:
http://www.brotherskeeper.dk/gedcom-nordic/ged-koder-ej-i-55.htm

Men igjen: det må skilles mellom eksport og import.

>Det er mer alvorlig hvor det er koder som overhode, så langt ikke
>tilfredstiller kodeverket, hverken snevert eller utvidet.
>
>se nederst på en samlet oversikt
>http://home.online.no/~otjoerge/bk/gedcom_trans.htm#Not_legal
>(så langt) over koder som brukes i ulike program
>
>Spørsmål vil måtte være om koder fra eldre versjoner av GEDCOM skal
>inngå eller ei

Inngå ved import, ikke ved eksport etter v5.5.
Dog bør eksport etter v4.0 være et alternativ.

---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
tha@tha.no
www.tha.no

---

Sat, 20 Mar 2004 11:24:51 +0100, in dk.videnskab.historie.genealogi,
torleif haugødegård <tha@tha.no> wrote:

>
>Inngå ved import, ikke ved eksport etter v5.5.
>Dog bør eksport etter v4.0 være et alternativ.

da bør dette stå spesifikt at dette er eksport etter v4.0 og ikke la
dette blir en del av v5.5

Enten er det
ren 5.5
ren 4.0
eller
fritt frem av alle varianter og tidligere versjoner

Det siste bør da heller ikke komme frem i noen form for krav.

Ser ikke at det skal legges noen forskjell i eksport eller import, eller
bør det det ?
Hvorfor?
Hvis man så sier at et program skal kunne inportere alt (noe som
selvfølgelig kan være gunstig) så kan programmet ikke kritiseres hvis
det ikke tar med alt som ligger utenfor.

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

---

Sat, 20 Mar 2004 11:06:12 +0100, in dk.videnskab.historie.genealogi,
torleif haugødegård <tha@tha.no> wrote:

>C
>"Oprettelse af egne GEDCOM-koder skal starte _ (underscore)" bør
>endres til
>"Oprettelse af egne GEDCOM-koder skal starte _ (underscore) eller med
>metoden EVEN/TYPE".

Dette er det to saker.

Koder med _ (underscore) er laget fra produsenten, mens
koder etter type EVEN/TYPE er laget av brukeren (i den grad
programutvikler har lagt til rette for at bruker skal kunne opprette
sine egne koder)

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

---

"Otto Jørgensen" skrev:

> >"Oprettelse af egne GEDCOM-koder skal starte _ (underscore) eller med
> >metoden EVEN/TYPE".
>
> Dette er det to saker.
>
> Koder med _ (underscore) er laget fra produsenten, mens
> koder etter type EVEN/TYPE er laget av brukeren (i den grad
> programutvikler har lagt til rette for at bruker skal kunne opprette
> sine egne koder)

Det ser ud til, at GEDCOM-Nordic initiativet blev afsporet inden det rigtig
nåede at komme igang ;-(

med venlig hilsen

Arne



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.639 / Virus Database: 408 - Release Date: 22-03-2004

---

Tue, 23 Mar 2004 12:34:19 +0100, in dk.videnskab.historie.genealogi,
"aafe" <intet@svar.dk> wrote:

>"Otto Jørgensen" skrev:
>
>> >"Oprettelse af egne GEDCOM-koder skal starte _ (underscore) eller med
>> >metoden EVEN/TYPE".
>>
>> Dette er det to saker.
>>
>> Koder med _ (underscore) er laget fra produsenten, mens
>> koder etter type EVEN/TYPE er laget av brukeren (i den grad
>> programutvikler har lagt til rette for at bruker skal kunne opprette
>> sine egne koder)
>
>Det ser ud til, at GEDCOM-Nordic initiativet blev afsporet inden det rigtig
>nåede at komme igang ;-(
>

Kan ikke se at det er noen avsporing i mitt innlegg.
Slik jeg tolker 5.5 så er det slik at EVEN/TYPE er generert for at
brukerne skal kunne lage sine egne hendelser som programmene ikke har
definert.

koder med _ (underscore) er så langt jeg har sett alle laget av
produsentene som en del av den presentasjon som de tilbyr for å dekke
opp akkutte/lokale behov for hendelser.

Så langt er det ingen program som lar brukerne lage disse kodene.

Hvis jeg tar feil, så gjerne korrigering.

Men som nevnt innledningvis, kan jeg ikke se at det er noen avsporing av
noe som helst.
Etter min mening kun en kostatering av at i dagens situasjon finnes 3
sett koder:

GEDCOM 5.5 direkte med sine koder (vanligvis 4 bokstaver)
Koder som starter med underscore med en etterfølgende kode
Koder som bygger på prinsippet om bruke av EVEN/TYPE


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

---

On Tue, 23 Mar 2004 17:22:01 +0100, Otto Jørgensen wrote:

>Kan ikke se at det er noen avsporing i mitt innlegg.
>Slik jeg tolker 5.5 så er det slik at EVEN/TYPE er generert for at
>brukerne skal kunne lage sine egne hendelser som programmene ikke har
>definert.
>
>koder med _ (underscore) er så langt jeg har sett alle laget av
>produsentene som en del av den presentasjon som de tilbyr for å dekke
>opp akkutte/lokale behov for hendelser.
>
>Så langt er det ingen program som lar brukerne lage disse kodene.
>
>Hvis jeg tar feil, så gjerne korrigering.

Afsporingen ligger i, at EVEN/TYPE er en meget lille detalje, der -
som jeg ser det - bliver blæst op til noget det iflg. gedcom
specifikationens forklarende noter ikke er tænkt som, fra standardens
skaberes side.

Og, så tænker jeg, at EVEN/TYPE måske bruges på en speciel måde af et
enkelt program (men, jeg ved ikke om det faktisk forholder sig sådan).
Og, hvis det er tilfældet, er det - efter min opfattelse - en
afsporing i forhold til at nå frem til noget generelt brugbart.

>GEDCOM 5.5 direkte med sine koder (vanligvis 4 bokstaver)
>Koder som starter med underscore med en etterfølgende kode
>Koder som bygger på prinsippet om bruke av EVEN/TYPE

Når du piller de direkte GEDCOM 5.5 koder, EVEN/TYPE ud af gedcom
standarden, og gør dem til noget specielt, så er det hele kørt af
sporet, og kan ikke interessere andre end folk der synes det er
interessant med politiske spilfægterier.

Men, der er jo ingen grund til at blive uvenner over det: I kan gøre
som i vil!

med venlig hilsen
Arne

---

Tue, 23 Mar 2004 17:49:22 +0100, in dk.videnskab.historie.genealogi,
aafe <intet@svar.dk> wrote:

>On Tue, 23 Mar 2004 17:22:01 +0100, Otto Jørgensen wrote:
>
>>Kan ikke se at det er noen avsporing i mitt innlegg.
>>Slik jeg tolker 5.5 så er det slik at EVEN/TYPE er generert for at
>>brukerne skal kunne lage sine egne hendelser som programmene ikke har
>>definert.
>>
>>koder med _ (underscore) er så langt jeg har sett alle laget av
>>produsentene som en del av den presentasjon som de tilbyr for å dekke
>>opp akkutte/lokale behov for hendelser.
>>
>>Så langt er det ingen program som lar brukerne lage disse kodene.
>>
>>Hvis jeg tar feil, så gjerne korrigering.
>
>Afsporingen ligger i, at EVEN/TYPE er en meget lille detalje, der -
>som jeg ser det - bliver blæst op til noget det iflg. gedcom
>specifikationens forklarende noter ikke er tænkt som, fra standardens
>skaberes side.
>
>Og, så tænker jeg, at EVEN/TYPE måske bruges på en speciel måde af et
>enkelt program (men, jeg ved ikke om det faktisk forholder sig sådan).
>Og, hvis det er tilfældet, er det - efter min opfattelse - en
>afsporing i forhold til at nå frem til noget generelt brugbart.
>
>>GEDCOM 5.5 direkte med sine koder (vanligvis 4 bokstaver)
>>Koder som starter med underscore med en etterfølgende kode
>>Koder som bygger på prinsippet om bruke av EVEN/TYPE
>
>Når du piller de direkte GEDCOM 5.5 koder, EVEN/TYPE ud af gedcom
>standarden, og gør dem til noget specielt, så er det hele kørt af
>sporet, og kan ikke interessere andre end folk der synes det er
>interessant med politiske spilfægterier.
>
>Men, der er jo ingen grund til at blive uvenner over det: I kan gøre
>som i vil!
>
Jeg plukker direkte ut EVEN/TYPE fra sammenhengen, men nevner dette i
sammenheng med den versjon vi har av GEDCOM, hvor innflytelsen i
innholdet til de tre sette med koder som er nevnt tidligere.
Vi kan jo sette det slik om det lyder bedre
GEDCOM 5.5 totalt
Mulighetene som produsenten har til å påvirke ekstra koder
Mulighetene som brukerne har til å påvirke ekstra koder.

Om vi går den ene elle andre veier, betyr ikke noe i grunnen.
Vi vet hva GEDCOM sier, men vi vet ikke hva produsentene definerer og vi
vet ikke hva brukerne vil definere.

Tja og det var det.
Det er mine øyne og ikke noe til hinder for at andre ser det annerledes


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

---

On Tue, 23 Mar 2004 18:13:16 +0100, Otto Jørgensen wrote:

>Det er mine øyne og ikke noe til hinder for at andre ser det annerledes

Omvendt kan man også sige, at GEDCOM standarden kan ikke skrives på en
måde, så dele af standarden ikke kan misforstås, ikke kan tolkes
forskelligt eller ikke kan vendes og drejes - og der hører det så oven
i købet også med i billedet, at der sågar har sneget sig skrivefejl
ind i 5.5 standarden, som man først har rettet i 5.5.1.

Men, gedchk.exe samt ged55.gmr er autoritativ, idet det er hvad der
bruges til officiel test af gedcomfiler.

Og, gedchk.exe samt ged55.gmr klassificerer ikke EVEN/TYPE som andet
end almindelig "lovlig" gedcom syntax, hvorimod alt der starter med
underscore bliver klassificeret som "extensions to the grammar"

Du kan derfor skelne imellem:
1. hvad der ligger udenfor den definerede gedcom grammar, og som ikke
er en udvidelse af grammar (lig med fej).
2. hvad der ligger indenfor den definerede gedcom grammar (nomal
lovlig gedcom)
3. hvad der er udvidelser af gedcom grammar (extensions)

Som i klassificerer det, hører både EVEN/TYPE og koder startende med
underscore ind under extensions.

Som gedchk.exe klassificerer det, hører EVEN/TYPE indenfor den
definerede gedcom grammar, mens alene koder startende med underscore
klassificeres som extension.

Gedcom standarden nævner heller ikke noget om, at noget er til brug
for programproducenter, mens andet er til brug for programmernes
slutbrugere. Gedcom standarden definerer derimod, at det der i
standardens forstand betragtes som brugere, er de der laver de
programmer der bruger gedcom standarden.

Gedcom standarden nævner også, at TYPE i EVEN/TYPE definerer, ikke
skal kunne forstås eller tolkes af slægtsprogrammerne, men simpelthen
betragtes som slet og ret tekst/labels.

Men, som sagt, når vi går ind i den normale gedcom grammar, og piller
ting ud derfra og begynder at definere dette som extensions, så er vi
i konflikt med det eneste autoritative i gedcomsammenhænge, nemlig
gedchk.exe med tilhørende ged55.gmr.

med venlig hilsen

Arne

---

Tue, 23 Mar 2004 19:27:23 +0100, in dk.videnskab.historie.genealogi,
aafe <intet@svar.dk> wrote:

>On Tue, 23 Mar 2004 18:13:16 +0100, Otto Jørgensen wrote:
>
>>Det er mine øyne og ikke noe til hinder for at andre ser det annerledes
>
>Omvendt kan man også sige, at GEDCOM standarden kan ikke skrives på en
>måde, så dele af standarden ikke kan misforstås, ikke kan tolkes
>forskelligt eller ikke kan vendes og drejes - og der hører det så oven
>i købet også med i billedet, at der sågar har sneget sig skrivefejl
>ind i 5.5 standarden, som man først har rettet i 5.5.1.

Uansett, 5.5.1 er ikke noen offisiell godkjent standard, det er DRAFT
>

Mitt utgangspunkt var dagens situasjon om hva brukerne ønsker.

Målet for brukerne flest er kommunikasjon og samspill slik at en
GEDCOM-fil, kan benytte og importeres til alle programmer og da uten å
ta hensyn til språklige bariærer.
Det eneste som kan dette ligger i det kodeverk som ikke inneholder
_(underscore) og Type/event.

Selv om begge er innenfor regelverket er det ikke noe som oversetter
innholdet om det nå er omforming av selve tagen _(underscore) eller
teksten i type/event. Den blir i dag slik den er i avgivende program og
avhenger av mottagende program (om det derfinnes noe som kan oversette)

Da ser jeg på dette internasjonalt og regner da ikke med at alle kan
språket i det avgivende land.

Jeg har her ikke tatt standpunkt til hva som brukes for testing av
program. Selv slike program er farget av de som lager disse, om da ikke
både opphavet til kodeverket og programleverandører aksepterer dette
testverktøy.


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

---

On Tue, 23 Mar 2004 19:48:28 +0100, Otto Jørgensen wrote:

>Uansett, 5.5.1 er ikke noen offisiell godkjent standard, det er DRAFT

Otto - det er jo endeløst. der er simpelthen ingen grænser for, hvad
der ikke kan føres af alenlange tomme diskussioner, hvor der kun
diskuteres, hvad det er der diskuteres.

Det er for surt, og livet er for kort til det!

Det var ikke et spørgsmål om, at rette sig efter et draft. Det var en
konstatering af, at nogle åbenlyse skrivefejl i version 5.5 ikke blev
rettet i version 5.5, men først blev rettet i draft 5.5.1. Og det i
sig selv, kan der så atter føres alenlange tomme diskussioner om,
fordi nogen klart kan se og forstå, at der var tale om skrivefejl i
5.5, mens andre ikke kan se/forstå det.

Men, glem nu det med 5.5.1. Det afgørende er nemlig, hvad indholdet er
i grammarfilen, ged55.gmr - der jo er den officielle grammarfil - og
den grammarfil retter sig ikke efter 5.5.1 - som sådan - men, retter
sig heller ikke efter skrivefejlene i 5.5.

Så, det er ikke et spørgsmål om, hvad man tror eller mener. Det er
simpelthen et spørgsmål om, hvad der glider igennem testen med gedchk,
og hvad der ikke glider igennem. Så, hvad det angår, er det ikke mig
du diskuterer med, det er indholdet i den officielle grammarfil,
ged55.gmr, du diskuterer med.

>Mitt utgangspunkt var dagens situasjon om hva brukerne ønsker.

Jeg sidder her og vil forholde mig til noget konkret, og der forstår
jeg helt enkelt ikke hvad du mener: Mener du, at brugerne ønsker at
EVEN/TYPE skal pilles ud af den almindelige gedcom grammar, og istedet
gøres til extension til grammar ?

>Målet for brukerne flest er kommunikasjon og samspill slik at en
>GEDCOM-fil, kan benytte og importeres til alle programmer og da uten å
>ta hensyn til språklige bariærer.

Men, det er jo en utopi - de fleste bilister vil også gerne have
biler, der kan accellere vanvittigt hurtigt, bremse på stedet og køre
et par hundrede kilometer på literen. Det kan bare ikke lade sig gøre


Hvis du ville nøjes med lidt mindre, var der større chance for at opnå
resultater.

1. Såvidt jeg ved, er der ingen slægtsprogrammer, der forstår og
bruger alle gedcom standardens muligheder. Prøv blot at se, hvor lidt
LDS eget program - PAF 5.2 - forstår af LDS' egen GEDCOM standard:
http://hoppalong.1go.dk/importlog.html

2. Såvidt jeg ved, kan alle - eller de fleste - slægtsprogrammer
forstå, hvad vi kan kalde den mest basale del af gedcom strukturen.
Der hvor det går galt, er når vi kommer ud i nogle af de sjældent
brugte muligheder, eller noget af det, der forholdsvis fornyelig er
kommet ind i gedcom, eller som for nyelig er blevet omstruktureret.

3. Såvidt jeg ved, kan nogle slægtsprogrammer også bruge visse
proprietære tags, som andre slægtsprogrammer er begyndt at bruge, og
derfor kan man i nogen grad også tale om, at visse proprietære tags er
tæt på at være standardiseret udenfor gedcom standarden.

4. Så er jeg også stødt på, at nogle slægtsprogrammer har misforstået
dele af gedcomstandarden, således at de alene af den grund er ude af
stand til at kunne udveksle visse data med andre programmer, og
endelig er jeg stødt på, at nogle slægtsprogrammer ikke engang kan
importere dele af de gedcomfiler, de selv har produceret

Ja, der er nok at tage fat på, og stump for stump er det vel også til
at opnå resultater på disse områder.

>Det eneste som kan dette ligger i det kodeverk som ikke inneholder
>_(underscore) og Type/event.

Ja, ja, prøv du blot at importere testgeden i forskellige programmer,
så skal du bare se løjer, som f.eks. her:
http://hoppalong.1go.dk/importlog.html

>Selv om begge er innenfor regelverket er det ikke noe som oversetter
>innholdet om det nå er omforming av selve tagen _(underscore) eller
>teksten i type/event. Den blir i dag slik den er i avgivende program og
>avhenger av mottagende program (om det derfinnes noe som kan oversette)

chkged klassificerer ikke de koder, der starter med underscore, som en
del af gedcom grammar, men derimod som en udvidelse af gedcom grammar
- men, det er håbløst at diskutere dette.

>Da ser jeg på dette internasjonalt og regner da ikke med at alle kan
>språket i det avgivende land.
>
>Jeg har her ikke tatt standpunkt til hva som brukes for testing av
>program. Selv slike program er farget av de som lager disse, om da ikke
>både opphavet til kodeverket og programleverandører aksepterer dette
>testverktøy.

Jamen Otto, det er fuldkommen håbløst. Som du lægger det frem, har
ikke engang skaberne af gedcom standarden ret i, hvordan deres
standard er og skal testes.

Alt er politisk tåge og elastik, der kan vendes drejes og tolkes og
ikke mindst diskuteres endeløst: Og, det kan jeg ikke være med til.

Jeg tror ikke på, der fremkommer løsninger og forbedringer af politisk
tåge og elastik - jeg tror kun der kommer endeløse diskussioner ud af
det. Men det gode er jo, at i selvfølgelig kan gøre hvad i vil

Og lad os så stoppe her, og ikke tærske mere tomt langhalm på det.

med venlig hilsen

Arne

---

Tue, 23 Mar 2004 21:09:57 +0100, in dk.videnskab.historie.genealogi,
aafe <intet@svar.dk> wrote:

>1. Såvidt jeg ved, er der ingen slægtsprogrammer, der forstår og
>bruger alle gedcom standardens muligheder. Prøv blot at se, hvor lidt
>LDS eget program - PAF 5.2 - forstår af LDS' egen GEDCOM standard:
>http://hoppalong.1go.dk/importlog.html

grei oversikt

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

---

aafe skrev:
> On Tue, 23 Mar 2004 19:48:28 +0100, Otto Jørgensen wrote:
>
>
>>Uansett, 5.5.1 er ikke noen offisiell godkjent standard, det er DRAFT
>
>
> Otto - det er jo endeløst. der er simpelthen ingen grænser for, hvad
> der ikke kan føres af alenlange tomme diskussioner, hvor der kun
> diskuteres, hvad det er der diskuteres.
>
> Det er for surt, og livet er for kort til det!
>
> Det var ikke et spørgsmål om, at rette sig efter et draft. Det var en
> konstatering af, at nogle åbenlyse skrivefejl i version 5.5 ikke blev
> rettet i version 5.5, men først blev rettet i draft 5.5.1. Og det i
> sig selv, kan der så atter føres alenlange tomme diskussioner om,
> fordi nogen klart kan se og forstå, at der var tale om skrivefejl i
> 5.5, mens andre ikke kan se/forstå det.
>
> Men, glem nu det med 5.5.1. Det afgørende er nemlig, hvad indholdet er
> i grammarfilen, ged55.gmr - der jo er den officielle grammarfil - og
> den grammarfil retter sig ikke efter 5.5.1 - som sådan - men, retter
> sig heller ikke efter skrivefejlene i 5.5.
>
> Så, det er ikke et spørgsmål om, hvad man tror eller mener. Det er
> simpelthen et spørgsmål om, hvad der glider igennem testen med gedchk,
> og hvad der ikke glider igennem. Så, hvad det angår, er det ikke mig
> du diskuterer med, det er indholdet i den officielle grammarfil,
> ged55.gmr, du diskuterer med.
>
>
>>Mitt utgangspunkt var dagens situasjon om hva brukerne ønsker.
>
>
> Jeg sidder her og vil forholde mig til noget konkret, og der forstår
> jeg helt enkelt ikke hvad du mener: Mener du, at brugerne ønsker at
> EVEN/TYPE skal pilles ud af den almindelige gedcom grammar, og istedet
> gøres til extension til grammar ?
>
>
>>Målet for brukerne flest er kommunikasjon og samspill slik at en
>>GEDCOM-fil, kan benytte og importeres til alle programmer og da uten å
>>ta hensyn til språklige bariærer.
>
>
> Men, det er jo en utopi - de fleste bilister vil også gerne have
> biler, der kan accellere vanvittigt hurtigt, bremse på stedet og køre
> et par hundrede kilometer på literen. Det kan bare ikke lade sig gøre
>
>
> Hvis du ville nøjes med lidt mindre, var der større chance for at opnå
> resultater.
>
> 1. Såvidt jeg ved, er der ingen slægtsprogrammer, der forstår og
> bruger alle gedcom standardens muligheder. Prøv blot at se, hvor lidt
> LDS eget program - PAF 5.2 - forstår af LDS' egen GEDCOM standard:
> http://hoppalong.1go.dk/importlog.html
>
> 2. Såvidt jeg ved, kan alle - eller de fleste - slægtsprogrammer
> forstå, hvad vi kan kalde den mest basale del af gedcom strukturen.
> Der hvor det går galt, er når vi kommer ud i nogle af de sjældent
> brugte muligheder, eller noget af det, der forholdsvis fornyelig er
> kommet ind i gedcom, eller som for nyelig er blevet omstruktureret.
>
> 3. Såvidt jeg ved, kan nogle slægtsprogrammer også bruge visse
> proprietære tags, som andre slægtsprogrammer er begyndt at bruge, og
> derfor kan man i nogen grad også tale om, at visse proprietære tags er
> tæt på at være standardiseret udenfor gedcom standarden.
>
> 4. Så er jeg også stødt på, at nogle slægtsprogrammer har misforstået
> dele af gedcomstandarden, således at de alene af den grund er ude af
> stand til at kunne udveksle visse data med andre programmer, og
> endelig er jeg stødt på, at nogle slægtsprogrammer ikke engang kan
> importere dele af de gedcomfiler, de selv har produceret
>
> Ja, der er nok at tage fat på, og stump for stump er det vel også til
> at opnå resultater på disse områder.
>
>
>>Det eneste som kan dette ligger i det kodeverk som ikke inneholder
>>_(underscore) og Type/event.
>
>
> Ja, ja, prøv du blot at importere testgeden i forskellige programmer,
> så skal du bare se løjer, som f.eks. her:
> http://hoppalong.1go.dk/importlog.html
>
>
>>Selv om begge er innenfor regelverket er det ikke noe som oversetter
>>innholdet om det nå er omforming av selve tagen _(underscore) eller
>>teksten i type/event. Den blir i dag slik den er i avgivende program og
>>avhenger av mottagende program (om det derfinnes noe som kan oversette)
>
>
> chkged klassificerer ikke de koder, der starter med underscore, som en
> del af gedcom grammar, men derimod som en udvidelse af gedcom grammar
> - men, det er håbløst at diskutere dette.
>
>
>>Da ser jeg på dette internasjonalt og regner da ikke med at alle kan
>>språket i det avgivende land.
>>
>>Jeg har her ikke tatt standpunkt til hva som brukes for testing av
>>program. Selv slike program er farget av de som lager disse, om da ikke
>>både opphavet til kodeverket og programleverandører aksepterer dette
>>testverktøy.
>
>
> Jamen Otto, det er fuldkommen håbløst. Som du lægger det frem, har
> ikke engang skaberne af gedcom standarden ret i, hvordan deres
> standard er og skal testes.
>
> Alt er politisk tåge og elastik, der kan vendes drejes og tolkes og
> ikke mindst diskuteres endeløst: Og, det kan jeg ikke være med til.
>
> Jeg tror ikke på, der fremkommer løsninger og forbedringer af politisk
> tåge og elastik - jeg tror kun der kommer endeløse diskussioner ud af
> det. Men det gode er jo, at i selvfølgelig kan gøre hvad i vil
>
> Og lad os så stoppe her, og ikke tærske mere tomt langhalm på det.
>
Som den gamle kone sa da hun lastet på hesten; "tar du den, så tar du
den". Jeg gavner vel ikke å se hva denne diskusjonen vil medføre på lang
sikt, men_la_oss_nå_redde_hesten_.

Hvem og hvordan vi nå kan løfte det opprinnelige initativet, fra en lang
diskusjon, til noe som kan realiseres. Arne og Otto er, til tross for
faglig uenighet, dyktige spillere vi trenger for å kunne flytte spillet
høyere opp på banen.

med vennlig hilsen kjell

---

aafe skrev:
> "Otto Jørgensen" skrev:
>
>
>>>"Oprettelse af egne GEDCOM-koder skal starte _ (underscore) eller med
>>>metoden EVEN/TYPE".
>>
>>Dette er det to saker.
>>
>>Koder med _ (underscore) er laget fra produsenten, mens
>>koder etter type EVEN/TYPE er laget av brukeren (i den grad
>>programutvikler har lagt til rette for at bruker skal kunne opprette
>>sine egne koder)
>
>
> Det ser ud til, at GEDCOM-Nordic initiativet blev afsporet inden det rigtig
> nåede at komme igang ;-(
>

Otto har advart mot mulighetene for at et slik initativ vil kunne ende i
en diskusjon om slektsprogrammer. At dette skjer er vel ikke til å unngå
fordi de aller fleste programmerere har valgt sine egne forståelser og
egne "approaches" i de markedsførte løsningene.

Dog bør vi komme noe lenger (meget lenger) i diskusjonene enn å
resignere allerede nå. Initativet er alt for godt til at bli glemt eller
avlivet

Kan hende trenger vi (_lett_spøkefullt_); - "en person med så tykk hud
at han kan stå oppreist selv uten ryggrad" (dette er også definisjonen
på en politiker)

mvh kjell

---

On Tue, 23 Mar 2004 17:34:48 +0100, Kjell Henry Skåden wrote:

>Kan hende trenger vi (_lett_spøkefullt_); - "en person med så tykk hud
>at han kan stå oppreist selv uten ryggrad" (dette er også definisjonen
>på en politiker)

Jamen, du har ret i, at det er ren politisk spilfægteri, at tage en
ganske normal EVEN/TYPE konstellation og pille ud af det sæt
almindelig gedcom tags/gedcom konstellationer som EVEN/TYPE er en helt
normal og upåfaldende del af.

Og, der skal man så netop tænke på, om man vil lave noget der kan stå
respekt om, eller om man vil lave noget, der i og for sig ikke kan
respekteres, men som måske kan fjerne et pres fra en bestemt side.

Problemet er nok, at vi fik disse diskussioner førend GEDCOM-Nordic
sitet kom op at stå, og førend vi fik konkretiseret inholdet i de tre
klasser og procedurer for tests osv.

Nu blev det så istedet en diskussion om kæpheste ;-(

med venlig hilsen

Arne

ps. Jeg prøvede lige for sjov at teste, i hvor høj grad LDS (i PAF
5.2) følger sin egen standard. Det gav så mange fejl, at jeg - af
tidsmangel og kedsommelighed - måtte opgive at kommentere det hele,
men noget af det fik dog en kommentar med på vejen:

http://hoppalong.1go.dk/importlog.html

---

Tue, 23 Mar 2004 18:23:08 +0100, in dk.videnskab.historie.genealogi,
aafe <intet@svar.dk> wrote:

>On Tue, 23 Mar 2004 17:34:48 +0100, Kjell Henry Skåden wrote:
>
>>Kan hende trenger vi (_lett_spøkefullt_); - "en person med så tykk hud
>>at han kan stå oppreist selv uten ryggrad" (dette er også definisjonen
>>på en politiker)
>
>Jamen, du har ret i, at det er ren politisk spilfægteri, at tage en
>ganske normal EVEN/TYPE konstellation og pille ud af det sæt
>almindelig gedcom tags/gedcom konstellationer som EVEN/TYPE er en helt
>normal og upåfaldende del af.
>
>Og, der skal man så netop tænke på, om man vil lave noget der kan stå
>respekt om, eller om man vil lave noget, der i og for sig ikke kan
>respekteres, men som måske kan fjerne et pres fra en bestemt side.
>
>Problemet er nok, at vi fik disse diskussioner førend GEDCOM-Nordic
>sitet kom op at stå, og førend vi fik konkretiseret inholdet i de tre
>klasser og procedurer for tests osv.
>
>Nu blev det så istedet en diskussion om kæpheste ;-(
>
Siden dette tydeligvis peker mot meg, legger jeg for min del ned
diskusjonen om dette tema.


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

---

Otto Jørgensen skrev:
> Tue, 23 Mar 2004 18:23:08 +0100, in dk.videnskab.historie.genealogi,
> aafe <intet@svar.dk> wrote:
>
> Siden dette tydeligvis peker mot meg, legger jeg for min del ned
> diskusjonen om dette tema.
>

Mitt innlegg var:

>Otto har advart mot mulighetene for at et slik initativ vil kunne ende
>i en diskusjon om slektsprogrammer. At dette skjer er vel ikke til å
>unngå fordi de aller fleste programmerere har valgt sine egne
>forståelser og egne "approaches" i de markedsførte løsningene.<

Beklager Otto, dersom du finner noe her som du opplever som negativt og
rettet mot deg. Personlig mener jeg at både initativet og diskusjonene
om temaet "GEDCOM-Nordic" bare vil tape seg ved at du trekker deg herfra.

mvh kjell

---

On Tue, 23 Mar 2004 19:02:34 +0100, Otto Jørgensen wrote:

>Siden dette tydeligvis peker mot meg, legger jeg for min del ned
>diskusjonen om dette tema.

Jeg har måske ikke fulgt godt nok med i den problematik, men jeg havde
nu ikke indtryk af, at du var kæphestens ophavsmand. Og, jeg svarede
dig jo også, at i naturligvis kan gøre hvad i vil.

med venlig hilsen

Arne

---

Tue, 23 Mar 2004 12:34:19 +0100, in dk.videnskab.historie.genealogi,
"aafe" <intet@svar.dk> wrote:

>"Otto Jørgensen" skrev:
>
>> >"Oprettelse af egne GEDCOM-koder skal starte _ (underscore) eller med
>> >metoden EVEN/TYPE".
>>
>> Dette er det to saker.
>>
>> Koder med _ (underscore) er laget fra produsenten, mens
>> koder etter type EVEN/TYPE er laget av brukeren (i den grad
>> programutvikler har lagt til rette for at bruker skal kunne opprette
>> sine egne koder)
>
>Det ser ud til, at GEDCOM-Nordic initiativet blev afsporet inden det rigtig
>nåede at komme igang ;-(
>

det kan vel her være noe språklige nyanser.

Jeg definerer EVENT/TYPE som en bruker-produsent Tag: seg selv er ikke
det riktig, da EVEN og TYPE er to vanlige og aksepterte tags innen
GEDCOM5.5.
Når jeg definerer dette som en bruker-definert tag ligger det i at
brukeren nå i mange program kan definere egne "hendelser". Dette
inkludert tekst (f.eks. borglig konfirmasjon).
I GEDCOM-eksporten er det meg bekjent kombinasjonen EVEN/TYPE samt
brukerens tekst som utgjør "den totale koden" I tillegg kommer øvrige
tags som angir dato, sted m.m.
Dette har de fleste program ikke noe problem med.
Bruk av kombinasjonen EVEN/TYPE samt tilhørende tekst, er et resulat av
manglende spesifikasjon av hendelser som programbrukerne ønsker å
definere og overføre, i stedet for å skrive dette inn som vanlig tekst
knyttet til de enkelte personer

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

---

"torleif haugødegård" <tha@tha.no> skrev i en meddelelse
news:hn5o509h2gvnoq9dmrv33ajsq63ratkmk7@4ax.com...
> Noen kommentarer/spørsmål:
>
> A
> "GEDCOM-koder fra GEDCOM standard 5.5" bør være de koder som står i
> dokumentet "THE GEDCOM STANDARD Release 5.5" av 2 January 1996:

Ja - helt enig


> "Appendix A Lineage-Linked GEDCOM Tag Definition".
>
> B
> Hva menes med "samt programproducenterne egne GEDCOM-koder"?

Det er GEDCOM koder som starter med _ (underscore) og som *er* TAGS som
producenten har defineret.


> C
> "Oprettelse af egne GEDCOM-koder skal starte _ (underscore)" bør
> endres til
> "Oprettelse af egne GEDCOM-koder skal starte _ (underscore) eller med
> metoden EVEN/TYPE".

Er ikke enig, EVEN/TYPE koder er for de TAGS som brugeren opretter og som
jeg foreslår er EVEN/TYPE GEDCOM-koden placeret i KLaase II



> D
> Det er nok med 1 klasse, klasse I.
> Og evt. grader (%) av oppfyllelse av denne.
> Hvis ikke, hvem definerer hva som "væsentlige GEDCOM-koder" og "basale
> GEDCOM-koder"? Har du eksempler på 'basale' koder? BIRT?

Hvem der definer - ja det er jo det som dette projekt går ud på - mit
forslag er:

Klasse III
Basale TAGS for Livets faste (normale) begivenheder:
Født, døbt, konfirmeret, gift, stilling, død og begravet.
Hertil note/biografi, køn samt de GEDCOM-koder der er nødvendige for at
kunne oprette de enkelte personer f.eks. køn samt at kunne binde de enkelte
personer sammen i databasen.

Klasse II
Væsentlige TAGS er en persons/families andre begivenheder men som alene er
findes i GEDCOM standarden - altså ikke noget med egne koder fra
producentens side.

Klasse I
Resten af GEDCOM-koderne som ikke er nævnt i Klasse II og III
Producentens egne GEDCOM-koder og som starter med _ (underscore)
Bruger oprettede begivenheder indgår som en EVEN/TYPE TAGS

- - -
Med denne klassificering, kan ses at minimums kravet for et slægtsprogram er
at det opfylder Klasse III. Hvilket de programmer som understøtter GEDCOM
også kan.
For at opfylde Klasse II stilles der større krav til antallet af TAGS både
for import og eksport.
For Klasse I (bedst) er der frit for producenten at anvender TAGS startende
med _ (underscore) samt alt alle GEDCOM-koder i 5.5 kan
eksporteres/importeres.

Anvendes der TAGS som ikke findes i 5.5 og som ikke starter med _
(underscore) vil der ikke kunne opnås en klassifisering.



> E
> Det må skilles mellom eksport og import, fordi det er viktig å
> _importere_ flest mulige tags. Også tags som er feil, som ikke er
> standard 5.5 eller som har vært tidligere standarder (feks 4.0).

Jeg opfatter eksport og import som lige vigtige - hvad er det værd hvis
programmet godt kan eksportere men ikke importere.
Fint nok at et program kan *importere* tidligere standarder - men det går
ikke at et nyt (læs: opdateret) programmet eksportere med TAGS der høre
under en tidligere standard.


>
> F
> Siden "Standard GEDCOM-Nordic klasse I"
> http://www.brotherskeeper.dk/gedcom-nordic/klasse1.htm
> innholder også koder som ikke er std5.5, hvorfor?
>
> Eksempel:
> ARVL {ARRIVAL}
> ATTR {ATTRIBUTES}:

Ups.
Min fejl - er slettet


> G
> Det må kartlegges om programmets bruker gis anledning til å definere
> sine egne hendelser m/GEDCOMkode, altså nye hendelser som ikke finnes
> som standard i programmet.

Hvis det programmet anvender ny(e) begivenhedstype(r) som der ikke findes en
GEDCOM-kode til, skal den starte med _ (underscore), hvis det er begivheder
som producentet har defineret, er det brugeren der opretter en ny
begivenhed, f.eks. Balsameret skal anvendes EVEN/TYPE.

Med venlig hilsen
Chris Gade Oxholm Sørensen - www.brotherskeeper.dk -
support@brotherskeeper.dk

---

<support@bk6.dk> wrote:
>> E
>> Det må skilles mellom eksport og import, fordi det er viktig å
>> _importere_ flest mulige tags. Også tags som er feil, som ikke er
>> standard 5.5 eller som har vært tidligere standarder (feks 4.0).
>
>Jeg opfatter eksport og import som lige vigtige - hvad er det værd hvis
>programmet godt kan eksportere men ikke importere.
>Fint nok at et program kan *importere* tidligere standarder - men det går
>ikke at et nyt (læs: opdateret) programmet eksportere med TAGS der høre
>under en tidligere standard.
>
Nettopp, derfor må det testes både eksport og import og gis separete
proeng for begge funksjoner.
Et program bør eksportere iht. v5.5, men importere flest mulige
varianter av v5.5 og tidligere GEDCOMtags.

>> G
>> Det må kartlegges om programmets bruker gis anledning til å definere
>> sine egne hendelser m/GEDCOMkode, altså nye hendelser som ikke finnes
>> som standard i programmet.
>
>Hvis det programmet anvender ny(e) begivenhedstype(r) som der ikke findes en
>GEDCOM-kode til, skal den starte med _ (underscore), hvis det er begivheder
>som producentet har defineret, er det brugeren der opretter en ny
>begivenhed, f.eks. Balsameret skal anvendes EVEN/TYPE.
>
Ja, og det må testes om programmet gir brukeren denne friheten.

---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
tha@tha.no
www.tha.no

---

Wed, 24 Mar 2004 23:53:42 +0100, in dk.videnskab.historie.genealogi,
torleif haugødegård <tha@tha.no> wrote:

><support@bk6.dk> wrote:
>>> E
>>> Det må skilles mellom eksport og import, fordi det er viktig å
>>> _importere_ flest mulige tags. Også tags som er feil, som ikke er
>>> standard 5.5 eller som har vært tidligere standarder (feks 4.0).
>>
>>Jeg opfatter eksport og import som lige vigtige - hvad er det værd hvis
>>programmet godt kan eksportere men ikke importere.
>>Fint nok at et program kan *importere* tidligere standarder - men det går
>>ikke at et nyt (læs: opdateret) programmet eksportere med TAGS der høre
>>under en tidligere standard.
>>
>Nettopp, derfor må det testes både eksport og import og gis separete
>proeng for begge funksjoner.
>Et program bør eksportere iht. v5.5, men importere flest mulige
>varianter av v5.5 og tidligere GEDCOMtags.
>
Nødvendigvis ikke enig. Det har en hensikt til at man i 5.5 har fjernet
en del koder og det bryter med standarden om disse importeres?

Eksempler finnes vel på koder som er brukt og som har andre løsninger
DESC er gitt ulik betydning i et program og i 5.5
UMAR løses på ulike måter ved hjelpe av Y eller N

Dette vil skape konflikt og vi bør vel da ikke akseptere at kodeverk som
er på tvers av 5.5 ukritisk skal importres?

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

---

On Thu, 25 Mar 2004 01:17:32 +0100, Otto Jørgensen
<otjoerge%øføø%@online.noAWAY> wrote:

>>Nettopp, derfor må det testes både eksport og import og gis separete
>>proeng for begge funksjoner.
>>Et program bør eksportere iht. v5.5, men importere flest mulige
>>varianter av v5.5 og tidligere GEDCOMtags.
>>
>Nødvendigvis ikke enig. Det har en hensikt til at man i 5.5 har fjernet
>en del koder og det bryter med standarden om disse importeres?
>
>Eksempler finnes vel på koder som er brukt og som har andre løsninger
>DESC er gitt ulik betydning i et program og i 5.5
>UMAR løses på ulike måter ved hjelpe av Y eller N
>
>Dette vil skape konflikt og vi bør vel da ikke akseptere at kodeverk som
>er på tvers av 5.5 ukritisk skal importres?

Så du mener at brukeren skal plages med manuell datainntasting fordi
den ankomne GEDCOMfil tilfeldigvis ikke tilfredsstiller denne
mangelfulle standarden fullt ut ;)

Programmet bør selvfølgelig være mest mulig hjelpsomt overfor brukeren
ved dataimport, og gi alle muligheter til å importere enhver
GEDCOMkode - om den også måtte være fullstendig feil.


---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
tha@tha.no
www.tha.no

---

Thu, 25 Mar 2004 19:29:14 +0100, in dk.videnskab.historie.genealogi,
torleif haugødegård <tha@tha.no> wrote:

>On Thu, 25 Mar 2004 01:17:32 +0100, Otto Jørgensen
><otjoerge%øføø%@online.noAWAY> wrote:
>
>>>Nettopp, derfor må det testes både eksport og import og gis separete
>>>proeng for begge funksjoner.
>>>Et program bør eksportere iht. v5.5, men importere flest mulige
>>>varianter av v5.5 og tidligere GEDCOMtags.
>>>
>>Nødvendigvis ikke enig. Det har en hensikt til at man i 5.5 har fjernet
>>en del koder og det bryter med standarden om disse importeres?
>>
>>Eksempler finnes vel på koder som er brukt og som har andre løsninger
>>DESC er gitt ulik betydning i et program og i 5.5
>>UMAR løses på ulike måter ved hjelpe av Y eller N
>>
>>Dette vil skape konflikt og vi bør vel da ikke akseptere at kodeverk som
>>er på tvers av 5.5 ukritisk skal importres?
>
>Så du mener at brukeren skal plages med manuell datainntasting fordi
>den ankomne GEDCOMfil tilfeldigvis ikke tilfredsstiller denne
>mangelfulle standarden fullt ut ;)
>
>Programmet bør selvfølgelig være mest mulig hjelpsomt overfor brukeren
>ved dataimport, og gi alle muligheter til å importere enhver
>GEDCOMkode - om den også måtte være fullstendig feil.

Jeg har kun påpekt at enkelte koder i ulike sammenheng og i leveranse
fra forskjellig programmer har ulike betydning.
Dette skaper konflikt ved import til forskjellig programmer og vil
uansett ikke gjøre situasjonen bedre for brukerne.

Hvordan dette skal løses på kort og lang sikt er et annet spørsmål, men
vi kan ikke skyve under tepe at situasjonen er tilstede og at enkelte
program i større grad enn andre leverer koder som kommer i konflikt ved
at de ikke er markert med _(underscore) men har rene bokstavkoder.

Hendelser knyttet til "TYPE/EVEN med tilhørende tekst" samt koder med
_(underscore) vil ikke gi samme situasjon.


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

---

support@bk6.dk skrev:

> Så har jeg lagt et opdateret UDKAST til GEDCOM klassifikation online.
> Adressen er: www.brotherskeeper.dk/gedcom-nordic/
>
> Med venlig hilsen
> Chris Gade Oxholm Sørensen - www.brotherskeeper.dk -
> support@brotherskeeper.dk
>
>
>
En meget god oversikt i klasse I, II og III. Pr dags dato finnes vel
GEDCOM v5.5 som den versjon de fleste "vedlikeholder". Altså _krav i
v5.5_ er hva klasse I må oppfylle _(?!!!)_

Har tatt noen av kommentarene i forslag I som eksempel:

BROT:   Forsvant i 5.4
BUYR:   Kom i 5.2, forsvant 5.4
CANC:   Ikke i 5.5
CRIM:   Før 5.2, ikke i 5.5

Uten å gjøre denne diskusjonen til en programvareavhengig diskusjon vil
jeg spørre om hva som tenkes gjort for de eksemplene som refereres til
ovenfor.

Koden og dets bruk er uten betydning i dette spørsmålet, men her har vi
eksempler på koder som ikke finnes i siste versjon, bare i de tidligere.
Å åpne opp for "_et tre-hodet troll_" (klasse I, II og III) vil ikke gi
oss standardiseringsforbedringer i forhold til dagens mange
GEDCOM-tolkinger, slik de er utformet i de forskjellige slektsprogram.

Vil det kanhende det være mer riktig å stadfeste at:

klasse I = GEDCOM v5.5
klasse II = GEDCOM v5.4
klasse III = GEDCOM v5.2

mvh kjell

---

On Sat, 20 Mar 2004 13:47:30 +0100, Kjell Henry Skåden wrote:

>Vil det kanhende det være mer riktig å stadfeste at:
>
>klasse I = GEDCOM v5.5
>klasse II = GEDCOM v5.4
>klasse III = GEDCOM v5.2

Nej, sådan forstår jeg det ihvertfald ikke.

Efter min mening, kan vi kun forholde os til enten version 5.5 eller
evt. 5.5.1 - og selvom det rigtigeste ville være, kun at nævne den
gældende standard, 5.5, nævner jeg alligevel 5.5.1 fordi f.eks.
GEDCHK's 5.5 grammar file, ihvertfald på nogle punkter følger 5.5.1,
hvor denne afviger fra 5.5 (f.eks. ved ASSO), ligesom Gedcom Explorer
føger ver. 5.5.1.

Efter min mening må det i dag være et absolut minimumkrav til alle
slægtsprogrammer, at de følger den gældende standard 5.5.

At programmerne muligvis også kan importere og forstå udgåede tags,
kan vi ikke have noget imod, men den går ikke, hvis programmerne også
eksporterer udgåede tags.

Det er meningen, at klasserne nærmere skal indhold er noget vi skal
diskutere, og derefter fastlægge, når først det kommende site er oppe
at stå med debatforum osv.

mvh
Arne

---

aafe skrev:
> On Sat, 20 Mar 2004 13:47:30 +0100, Kjell Henry Skåden wrote:
>
>
>>Vil det kanhende det være mer riktig å stadfeste at:
>>
>>klasse I = GEDCOM v5.5
>>klasse II = GEDCOM v5.4
>>klasse III = GEDCOM v5.2
>
>
> Nej, sådan forstår jeg det ihvertfald ikke.
>
> Efter min mening, kan vi kun forholde os til enten version 5.5 eller
> evt. 5.5.1 - og selvom det rigtigeste ville være, kun at nævne den
> gældende standard, 5.5, nævner jeg alligevel 5.5.1 fordi f.eks.
> GEDCHK's 5.5 grammar file, ihvertfald på nogle punkter følger 5.5.1,
> hvor denne afviger fra 5.5 (f.eks. ved ASSO), ligesom Gedcom Explorer
> føger ver. 5.5.1.
>
> Efter min mening må det i dag være et absolut minimumkrav til alle
> slægtsprogrammer, at de følger den gældende standard 5.5.
>
> At programmerne muligvis også kan importere og forstå udgåede tags,
> kan vi ikke have noget imod, men den går ikke, hvis programmerne også
> eksporterer udgåede tags.
>
> Det er meningen, at klasserne nærmere skal indhold er noget vi skal
> diskutere, og derefter fastlægge, når først det kommende site er oppe
> at stå med debatforum osv.
>

Er ikke uenig, men nå står vi begge i fare for å bli programvareavhengig
i det svaret som vi må ha. En totalversjon 5.5 + 5.5.1 er ikke mulig
uten at de inneholder, - _erstatter de "tidligere" koder som som holdes
i live av de tilgjengelige slektsprogrammer på markedet_

Enten må vi ha _en standard_ som inneholder alt hva som finnes i denne
totalversjonen (inneholder 5.5+5.5.1), eller så må vi kreere en helt ny
standard, som ikke behøver å være se bakover til tidligere standarder.

En slik ny standard, til å erstatte GEDCOM kan utgå fra en teknkologisk
utvikling _state-of-art_ , som nå skjer innen databaseteknologien
og/eller programmeringsverktøyer for slektsprogram.

Å utvikle noe hvor dagens brukere må betale for nye maskinvareplatformer
tror jeg også bare vil bli en betinget suksess.

mvh kjell

---

On Sat, 20 Mar 2004 16:42:02 +0100, Kjell Henry Skåden wrote:

> Er ikke uenig, men nå står vi begge i fare for å bli programvareavhengig
> i det svaret som vi må ha. En totalversjon 5.5 + 5.5.1 er ikke mulig
> uten at de inneholder, - _erstatter de "tidligere" koder som som holdes
> i live av de tilgjengelige slektsprogrammer på markedet_

Tags der er røget ud af gedcom standarden - altså tags der ikke er med
i ver. 5.5 - er ikke længere gyldige gedcom tags, og hvis nogen holder
sådanne gamle koder "kunstigt" i live, betyder det blot, at de ikke
overholder gedcom standarden, men istedet bruger deres egen
hjemmelavede standard: Og - som sådan - kan sådanne produkter ikke
klassificeres.

Funktionaliteten er ikke blevet mindre af den udvikling gedcom
standarden har været igennem, men gedcom koden er blevet bedre
struktureret, således at noget der tidligere blev opnået på een måde,
nu - istedet - opnås på en anderledes måde: Og, der er det
selvfølgelig op til programproducenterne, om de vil ændre og tilpasse
deres gamle procedurer og metoder, så de passer til gedcom standarden
(der p.t. er ver. 5.5). Men, hvis producenterne ikke vil det, kan
deres programmer bare ikke klassificeres.

> Enten må vi ha _en standard_ som inneholder alt hva som finnes i denne
> totalversjonen (inneholder 5.5+5.5.1), eller så må vi kreere en helt ny
> standard, som ikke behøver å være se bakover til tidligere standarder.

Men, vi skal ikke lave standarder. Vi skal bare teste og sikre, at
produkterne overholder den gældende standard (GEDCOM 5.5).

Som det er fremhævet fra forskellig side - både her i gruppen og
udenfor gruppen - er programproducenterne interesseret i, at netop
deres program har noget, som de andre programmer ikke har; og derfor
kan det også være i producenternes interesse, at have nogle tags eller
metoder, der ikke matcher med de aktuelle standarder. Og der gælder
det for os om, at holde hovedet koldt og indse, at gedcom er en
transportprotokol og ikke et magisk middel, der kan interface
modstridende metoder.

> En slik ny standard, til å erstatte GEDCOM kan utgå fra en teknkologisk
> utvikling _state-of-art_ , som nå skjer innen databaseteknologien
> og/eller programmeringsverktøyer for slektsprogram.

Men, vi skal ikke lave en ny standard. Det er der andre, der arbejder
med; det er faktisk derfor den løbende udvikling af gedcomstandarden
blev sat i stå, for nu mange år siden: Vi skal vel nærmere prøve at
udfylde det tomrum, der er opstået, fordi man gik igang med at lave en
ny standard.

> Å utvikle noe hvor dagens brukere må betale for nye maskinvareplatformer
> tror jeg også bare vil bli en betinget suksess.

Gedcom standarden er i nogen grad platformsuafhængig, og når
gedcomstandarden ikke er 100% platformsuafhængig, skyldes det at
Windows/DOS, *nix, Linux og Apple systemerne bruger forskellige
linjeafslutningstegn.

med venlig hilsen

Arne

---

On Sat, 20 Mar 2004 18:32:20 +0100, aafe <intet@svar.dk> wrote:

>On Sat, 20 Mar 2004 16:42:02 +0100, Kjell Henry Skåden wrote:
>

Hvem er det som skriver når anonyme "aafe" skriver?


---------------------------------------------------
Torleif Haugødegård, Hamar/Trondheim
tha@tha.no
www.tha.no

---

Sat, 20 Mar 2004 13:47:30 +0100, in dk.videnskab.historie.genealogi,
Kjell Henry Skåden <old.navy@online.no> wrote:

>En meget god oversikt i klasse I, II og III. Pr dags dato finnes vel
>GEDCOM v5.5 som den versjon de fleste "vedlikeholder". Altså _krav i
>v5.5_ er hva klasse I må oppfylle _(?!!!)_
>
>Har tatt noen av kommentarene i forslag I som eksempel:
>
>BROT:   Forsvant i 5.4
>BUYR:   Kom i 5.2, forsvant 5.4
>CANC:   Ikke i 5.5
>CRIM:   Før 5.2, ikke i 5.5

Man kan jo stille spørmålet om hvorfor noe av disse forsvant aog andre
kom inn, men det ligger vel noe i tankegodset til de som har ført
standardene i pennen

>Uten å gjøre denne diskusjonen til en programvareavhengig diskusjon vil
>jeg spørre om hva som tenkes gjort for de eksemplene som refereres til
>ovenfor.

Det er klart vi har en rekke koder, ref tidligere melding som har ulike
årsaker (se lengre ned) og finnes i mange ulike program.
Håper ikke vi kommer inn i noen programvarediskusjon, da her er det
snakk om definere hendelser som vi trenger til våre registreringer.

>Koden og dets bruk er uten betydning i dette spørsmålet, men her har vi
>eksempler på koder som ikke finnes i siste versjon, bare i de tidligere.
>Å åpne opp for "_et tre-hodet troll_" (klasse I, II og III) vil ikke gi
>oss standardiseringsforbedringer i forhold til dagens mange
>GEDCOM-tolkinger, slik de er utformet i de forskjellige slektsprogram.
>
>Vil det kanhende det være mer riktig å stadfeste at:
>
>klasse I = GEDCOM v5.5
>klasse II = GEDCOM v5.4
>klasse III = GEDCOM v5.2


Det føler jeg ikke er riktig.
Om vi skal ta med 5.4 etc så kan vi like godt ta med 5.5.1

Vi har kun en officiell versjon og det er 5.5.
Spørsmålet blir heller i hvilken grad man skal åpne for bruker av
TYPE/EVEN og _ (underscore)

Begge de to siste er innenfor GEDCOM 5.5 og et resultat av sneverheten
og det umulig å kunne definere alle mulig koder for alle mulige
hendelser rundt om i hele verden

litt historie:

Someone cautioned me that GedEdit used GEDCOM 5.3, a "draft" version of
GEDCOM, before the "standard" 5.5 was published by LDS. Since I had no
problems using GedEdit after doing some light editing on some of the
opening fields in some of the GEDCOMs I tested on it, I decided to
see if GEDCOM 5.3 and 5.5 were all that different and to do that I had
to plunge into my GEDCOM spec file to see how GEDCOM evolved. The
by-product is this is a time line of the parallel release of Personal
Ancestral File and the GEDCOM versions that served it. I hope it will be
of use to those searching for the past versions of GEDCOM documentation.

Here is a list of GEDCOM versions (extacted from LDS' documentation)
that I have in my files and articles by those involved in the gensoft
press. The evolution of GEDCOM runs parallel to the development of
PAF that for many years, especially 1985-1989, was LDS' real-world
implementation of GEDCOM.

2.0 Dec 1985 (its existence is cited in the version 5.5 release and
date taken from Bill Harten's article in "Genealogical Computing,"
Jan-Mar 1990) (PAF 2.0)
The version number was that of the version of PAF it supported.

2.1 Feb 1987 for GEDCOM for PAF 2.1 (Harten).

3.0 9 October 1987 GEDCOM Standard (Title Page)
8 Jun 1988 (Title page for PAF 2.0 and 2.1 implementation of 3.0)

4.0 August 1989 GEDCOM Standard (PAF 2.x-2.31)

(LDS doc) Versions prior to these were preliminary and were not
established as a standard. Between 4.0 and 5.5 there were several
drafts. (end of LDS doc).

The evolution from 4.0 to 5.5 moved at a snail's pace, and developers
where hamstrung trying to market new features while still claiming
their programs were "GEDCOM-Compatible."

Some developers grabbed 5.3 and began using it because it allowed for
schema that supported user-defined tags, something that excited the
developers competitive interest in adding bells and whistles to their
programs. The schema was dropped in 5.4 and not included in version
5.5 that by then had enough new tags to support many new multi-media
features.

(All 5.x's were drafts except 5.5, the final release)
5.0 (date?) (There was a PAF GEDCOM Specifications document dated 25 Jan
1990
and "GEDCOM Interim Tag, Value and Pointer Combinations
Specification for Lineage-linked Data," dated 17 Jul 1990)
5.1 18 Sep 1992 (Title Page of GEDCOM 5.1)
5.2 A Draft Release Note No. 1 was dated 2 Jun 1993 asking for
comments by 1 Oct 1993 on tags supporting source documentation.)
5.3 4 November 1993 (Title page of GEDCOM 5.3)
5.4 21 Aug 1995 (this version and date are based on non LDS sources and
is uncorroborated by any documents in my files, as the covering
letter for 5.3 as a "draft" said that the next released would be
"The GEDCOM Standard.")
5.5 11 Dec 1995 (Title Page for 5.5)

May 1997 PAF 3.0 (DOS) released

1 May 1998 LDS announces a proposed GEDCOM (Future Direction) to
replace 5.5

Feb 2000 PAF 4.0 released | (These are freeware for Win9x/NT.
Version Nov 2000 PAF 5.0 released | 4.0 was a reduced version of
Ancestral Quest.
| Both support GEDCOM 5.5 and are
| distributed via LDS distribution sites.




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