Forsøk på å lage en ny og bedre GEDCOM standard

[dn01013]

Fant denne i kveld på Föreningen DIS (DIS) sin nye slektskonferanse:

http://bettergedcom.wikispaces.com/

Kanskje noe å ta tak i for også norske programleverandører og DIS-Norge.

Hva ønsker vi skal kunne overføres av informasjon mellom slektsprogrammer som ikke tas vare på i dag ?

Noe for et nytt utvalg ??

[Simen Øvrebø]

Har også kikket på denne. Kunne nok skrevet side opp og side ned om tanker rundt ønsker her, ja.

[dn01013]

Du deltok ikke her da den 10.-12. februar ??

http://rootstech.familysearch.org/

Lurer på hva som kom frem av det møtet ??

Men det var vel bare amerikanere som deltok ??

[Simen Øvrebø]

Nei, slikt har man hverken tiden eller råd til i løpet av semesteret på skolen.

Huff. LDS involvert i BetterGedcom? Skeptisk...

[dn01013]

Tror det var en forhastet konklusjon >/(

Les mer her:

http://bettergedcom.wikispaces.com/Who+Are+We%3F

Ser at Geir er involvert.

Så der har DIS-Norge en evt. en mulig kanal.

Men selv må jeg få hodet over vannet først ang. GEDtreff 2011. Selv øynene føles vanskelig å holde klar av vannet for øyeblikket (Renser kode for minnelekkasjer som involverer mye rart )

Og på toppen av det fikk jeg svn-krasj da jeg kommitet koden til server

Men checksumfeilen som oppsto synes å være lokal. Ved nedlasting av koden på nytt i ny katalog og sammenlikning av sist redigerte fil med nedlastet kode fra server viser det seg nå at sist innskrevne kodelinje var kommet med i svn-basen på server, men lokal svn-kopi ikke var oppdatert. Ga ikke akkurat god nattesøvn og sto opp alt for tidlig for å sjekke.

[Simen Øvrebø]

Det var nå noe mer lovende. Det mangler veldig mye slik GEDCOM er nå for norske forhold etter min mening.

Ai! Krysser fingre for at det gikk greit med koden. 5.0.1.550 er den siste jeg har testet. Ingen problemer oppdaget.

[Otto Jørgensen]

Til Alf og første innlegg i tema.

For mange år siden prøvde undertegnede og et par andre å starte en norsk diskusjon om hva vi i Norge ville ha med i en GEDCOM.

Desverre var interesse fra alle andre av NULL interess og det ble skrinlagt. Det var da også intensjonen å være aktiv overfor det internasjonal miljøet på dette området.

Vi vet alle at det er store mangeler i GEDCOM på mange områder. Dette vesentlig fordi GEDCOM var tilpasset et spesielt miljø og ikke ganget opp (la oss kalle det) multikulturelle miljøer.

[Gunnar Østegården]

Jeg henger ikke med i debatten, egentlig!

Men jeg kjenner meg allikevel frustrert.
Dette burde vel vært noe som programprodusentene burde ha løst for lenge siden,
- hvis det hadde vært noen interesse.
Eller?

EN superfleksibel og utbyggbar standard!
- Er det fryktelig vanskelig å få til, eller?

Men det er jo liten mening i hva jeg som bruker måtte mene, hvis programprodusentene ignorerer det uansett.

Om jeg nå bare, i det minste, hadde visst bedre:
- så skulle jeg gjerne ha boicotta allverdens programmer
- og satsa på DET (eneste), - fornuftige - , alternativet.
Gi meg, stakkars uvitende sjel, svaret!


Mvh Gunnar.

[Simen Øvrebø]

Jeg henger ikke med i debatten, egentlig!

Men jeg kjenner meg allikevel frustrert.
Dette burde vel vært noe som programprodusentene burde ha løst for lenge siden,
- hvis det hadde vært noen interesse.
Eller?

EN superfleksibel og utbyggbar standard!
- Er det fryktelig vanskelig å få til, eller?

Men det er jo liten mening i hva jeg som bruker måtte mene, hvis programprodusentene ignorerer det uansett.

Om jeg nå bare, i det minste, hadde visst bedre:
- så skulle jeg gjerne ha boicotta allverdens programmer
- og satsa på DET (eneste), - fornuftige - , alternativet.
Gi meg, stakkars uvitende sjel, svaret!


Mvh Gunnar.

Historien er kort og skamløst stjålet fra wikipedien:

GEDCOM står for GEnealogical Data COMmunications (altså «genealogisk datakommunikasjon») og er en protokoll (filformat eller en måte å strukturere informasjon på) som er utviklet av Family History Department (FHD) hos Jesu Kristi Kirke av Siste Dagers Hellige (mormonerne) i Salt Lake City, USA.

Tanken bak Gedcom var å lage et verktøy for å utveksle informasjon mellom slektsgranskere, uavhengig av hvilke slektsdataprogram som ble benyttet. Protokollen er i dag en de facto standard for utveksling av data mellom de fleste slektsdataprogrammer som finnes. Filer lagret på Gedcomformatet er rene tekstfiler som også kan leses av vanlige tekstbehandlingsprogrammer, og det aktuelle tegnsettet som benyttes er en del av filas innhold. Dette forenkler også transport på tvers av maskinvare- og operativsystemplatformer.

Gedcomstandarden er utviklet over mange år, men synes nå å ha stoppet opp. Det finnes flere ulike versjoner av protokollen, men fram til versjon 6.0 synes disse (stort sett) å være bakoverkompatible. Ikke alle opplysninger som lagres av et slektsdataprogram blir eksportert til Gedcomfiler. Opplysninger som ikke omfattes av den aktuelle standarden kan ikke påregnes å være med ved transport til et annet program.

Gedcomstandarden finnes i flere ulike versjoner, men det er det bare noen av disse som er offisielle. Versjon 4.0 og 5.5 (sistnevnte fra januar 1996) er offisielle, mens versjoner mellom 5.0 og 5.4, samt versjon 5.5.1 (fra oktober 1999) er alle «kladdeutgaver». Det er også skrevet spesifikasjoner til Gedcom 6.0, men denne spesifikasjonen baserer seg på bruk av XML. Også denne er kun i en «kladdeutgaver» og den er heller ikke bakoverkompatibel med andre versjoner. Dataprogrammer som bare kan lagre Gedcomfiler i en av «kladdeversjonene» kan forårsake problemer når eksporterte opplysninger skal importeres i andre programmer. Det samme vil også være tilfelle hvis man importerer filer fra en nyere versjon enn den slektsdataprogrammet var skrevet for.

Selv om versjon 5.5 tar vare på mye av den informasjonen som er lagret i et slektsdataprogram, må brukerne allikevel regne med å legge inn en del opplysninger manuelt når Gedcom brukes for å flytte data.

Ut over de rene kodene som er spesifisert i 5.5, kan produsentene lage egne koder som alle skal starte med _ (underscore). Disse kan være forskjellige fra produsent til produsent og kan vanskeliggjøre ren import og eksport av data.

5.5 synes å være det mormonerne er fornøyd med, så da må vi også være det...

På dine spørsmål:

1. Ja, programprodusentene burde samarbeidet go funnet en felles løsning i stedet for X antall varianter av tags for samme type hendelse.

2. Vanskelig? Det tror jeg ikke, men da må det være et åpent forum. Jeg er skeptisk til høy grad av innblanding fra LDS.

[Otto Jørgensen]

Gedcom ble jo til for at noen følte et identisk behov for data uansett hvilket program. Dermed kon standarden.

Den er ikke tilfredstillende 100% men dekker på lang vei de allere fleste behov også med hensyn til å legge inn spesifiserte egne hendelser.

Et av problemene i starten var at GEDCOM spesifiserte 3 karaktersett som askptable og derav 1 som var anbefalt at alle program burde ha. Mange program tok ikke hensyn til det og har det heller ikke. I tillegg er det kommet et karaktersett og dermed er største utfordringen ved at f.eks. æøå og andre aksentuerte tegn og bokstaver ikke overføres korrekt.

Den andre utfordringen er datoformatet. GEDCOM sier helt klart hva det skal være, men da er det op til de enkelte program å bygge inn konverteringssett slik at formen er riktig og at nasjonale definisjoner blir konvertert til/fra Standardsettet ved bruk av Gedcom.

Edcom er i utgangspunkt i Engelsk språkformat.

[Otto Jørgensen]

Svar til Simen Øvrebø

Det er ikke lett å bli enig. Vi her i Norge blir ikke enige, jfr. f.eks. datoformatet i Ft1910 som avviker både fra det som er registrert og det folk er vant til (se ditt eget bankkort og personnnummr)

Under testingen som var på programsiden for en del år siden, var den veldig mange fokus, men stort sett alle som uttalte seg hadde alltid i bakhodet det programmet de var vant til og det var ikke lett å bli enige. Ble vi det montro

Dermed tror jeg det samme vil være hvis programleverandørene/utviklerne skal bli enige. Det er for store økonomiske interesser inne til at man blir enige.

Følger alle den standard som står i 5.5.(1) vil de fleste kunne overføre data mellom programmene uten problemer.

[Simen Øvrebø]

Svar til Simen Øvrebø

Det er ikke lett å bli enig. Vi her i Norge blir ikke enige, jfr. f.eks. datoformatet i Ft1910 som avviker både fra det som er registrert og det folk er vant til (se ditt eget bankkort og personnnummr)

Under testingen som var på programsiden for en del år siden, var den veldig mange fokus, men stort sett alle som uttalte seg hadde alltid i bakhodet det programmet de var vant til og det var ikke lett å bli enige. Ble vi det montro

Dermed tror jeg det samme vil være hvis programleverandørene/utviklerne skal bli enige. Det er for store økonomiske interesser inne til at man blir enige.

Følger alle den standard som står i 5.5.(1) vil de fleste kunne overføre data mellom programmene uten problemer.

Hvis det er datoformatet på søkesiden du peker til så følger den NS-ISO 8601.

Jeg synes det er viktigere ting å fokusere på enn datoformater i en slik sammenheng selv om det selvfølgelig er en viktig del av standardiseringen. Dette blir som en bagatell å regne. Utvekslingsformatet (la oss fortsatt kalle dyret GEDCOM) kan ha et bestemt datoformat som gjelder uansett. Ved en eventuell import kan programvaren til brukeren sørge for at h*n får sine forhåndssatte valg.

Jeg ser ikke logikken her. Hvis jeg var utvikler av programvare for slektsforskere ville jeg være strålende fornøyd om jeg hadde en god og veldokumentert standard å følge. Da kunne jeg heller konsentrert meg om å implementere funksjonalitet som selger.

Klart alle burde støttet 5.5/5.5.1 fullt ut nå, men de holder ikke mål.

[dn01013]

Klart alle burde støttet 5.5/5.5.1 fullt ut nå, men de holder ikke mål.

Problemet oppstår når Gedcom skal begrense datamodellen i programmet for å kunne eksportere/importere alt i gedcom.

I og med det er masse som Gedcom opplagt ikke støtter i andre land enn USA, så vil masse som folk gjerne vil ha, ikke kunne inngå i datamodellen.

Det er vel neppe hensikten ??

[Otto Jørgensen]

Ført litt generelt (gjelder ikke dette tma)

Kan ikke se vitsen ved at en legger innn sitater av hele meldinger eller store avsnitt. Meldinger har gjerne en sammenheng. Det som burde være (hint til DIS) gjeninjnføre linkede meldinger slik at de henger sammen og man lettere ser hva en har svart på.

Så til tema. Det er greit at man har standarder (ISO) men en kilde skal i utgangspunkt være kildetro. Det har også Arkivverket selv sagt og innrømmet og har tatt dette adnita. Ditt bankkort.

Jeg er enig (som også nevnt i mange år) at GEDCOM ikke holder dagens krav, men alle kan allikevel følge den standard med hensyn til datoformater og tegnsetting. Det er noe helt annet enn strurelle oppbygging.

Dato format og tegnsett er noe av det enkleste å få til. Her kodeifiserer man internasjonalt både tegnsetting og datoformatog gjør alle det går det greit.

Gedcom har bestemt at en dato skal skrives i Engelsk og på en bestemt måte.

Det har ingen innvirkning på om Gedcom HETER 5.5. 6 ELLER 10 for den sags skyld. Dato skal uansett konverteres til ulike nasjonal standarder og språk i de ulike program

[dn01013]

Det er ikke lett å bli enig. Vi her i Norge blir ikke enige, jfr. f.eks. datoformatet i Ft1910 som avviker både fra det som er registrert og det folk er vant til (se ditt eget bankkort og personnnummr)

Så lenge alle slektsprogrammer dropper å støtte NS-ISO 8601 som er internasjonalt godkjent, blir det selvsagt krangel når Riksarkivet innfører bruk av standarden og ikke hva "folk flest"-folket bruker

(Polsk riksdag er gøy)

[Simen Øvrebø]

I og med det er masse som Gedcom opplagt ikke støtter i andre land enn USA, så vil masse som folk gjerne vil ha, ikke kunne inngå i datamodellen.

Det er vel neppe hensikten ??

Nettopp. Hensikten burde være å lage en mer globalt rettet modell. Om man så skal ha disse produsentspesifikke tags med underscore så kunne man kanskje heller gjort det slik at en den samme hendelsen får 30 forkjellige navn.

[dn01013]

Det har ingen innvirkning på om Gedcom HETER 5.5. 6 ELLER 10 for den sags skyld. Dato skal uansett konverteres til ulike nasjonal standarder og språk i de ulike program

det bør programmene ta seg av.


Program 1 datoformat -> GEDCOM standard -> Program 2 sitt format.

F.eks. program 1 yyyyddmm -> dd MMM yyyy (gedcom standard) -> program 2: dd-mm-yyyy

Ved å ha et fast, rigid, entydig bestemt med et fast format på månedsangivelser i ETT språk slipper man tolkingsproblem av Gedcom-fila.

Velger man polsk riksdag i gedcom-fila kan man som regel gå ut fra at program 2 ikke kan importere datoen som dato, men som fritekst som man selv må redigere.

[Gunnar Østegården]

Men hvis man vil ha standardisering og er skeptisk til høy grad av innblanding fra LDS.
Er man ikke da ille ute?
Er ikke det like håpløst som å kjempe mot Microsoft?

Mvh Gunnar.

[Simen Øvrebø]

Program 1 datoformat -> GEDCOM standard -> Program 2 sitt format.

F.eks. program 1 yyyyddmm -> dd MMM yyyy (gedcom standard) -> program 2: dd-mm-yyyy

Eksakt. Ser jeg var litt uklar lenger opp, men du skisserer det jeg mente.

[Simen Øvrebø]

Men hvis man vil ha standardisering og er skeptisk til høy grad av innblanding fra LDS.
Er man ikke da ille ute?
Er ikke det like håpløst som å kjempe mot Microsoft?

Nei, det synes jeg ikke. De er en klar deltaker, men en slik prosess bør være åpen og ha en klar maktbalanse.

[dn01013]

Men hvis man vil ha standardisering og er skeptisk til høy grad av innblanding fra LDS.
Er man ikke da ille ute?
Er ikke det like håpløst som å kjempe mot Microsoft?

Mvh Gunnar.

Ikke nødvendigvis, kun hvis de vil ha vetorett og bruker det på alt som ikke høver et medlem av Jesu kristi kirke

F.eks. homofile ekteskap og samboerskap mellom heterofile.

[dn01013]

En annen nøtt å løse i fremtiden er født av surrogatmor hvor både egg og spermier kommer fra dem som bestilte eller kanskje fra ukjente personer

[Gunnar Østegården]

Ikke nødvendigvis, kun hvis de vil ha vetorett og bruker det på alt som ikke høver et medlem av Jesu kristi kirke.

F.eks. homofile ekteskap og samboerskap mellom heterofile.

Men idag!
Viser mormonerne noen vilje til å inngå kompromisser?

Mvh Gunnar

[Gunnar Østegården]

En annen nøtt å løse i fremtiden er født av surrogatmor hvor både egg og spermier kommer fra dem som bestilte eller kanskje fra ukjente personer

Ja - vi har jo fått venne oss til å opperere med en og annen mer eller mindre tvilsom 'surrogatfar'.

Slektsgransking er i stor grad et spørsmål om biografi. Det er ikke meningen at et eller annet slektsgranskingsprogram skal både registrere og skrive slektshistoria vår.

Spørsmålet er kanskje om programmene har gått for langt i å etterkomme brukernes krav om at man vill putte inn alle facts, - så lager programmet allt annet som behøves.
Det forekommer meg at jeg har mange flere tagger i slektsprogrammet mitt enn jeg behøver. Mon tro om man kunne komme overens om forenklinger, - men at alle brukerne lærer å bruke programmets funksjoner KUN slik som det har vært forutsatt.

Mvh Gunnar.

[dn01013]

Husk at en del genetikkforskere også bruker enkelte slektsprogrammer til forsking. Men de fleste bruker nok spesiallagde programmer. Men de har fortsatt samme problem

[Otto Jørgensen]

Det erm noe sider vi bør skille fra hver andre, men til stadig blandes.

Datoformat.
Hvilket format en bruker av et slektsprogram velger å benytte seg av, bør ikke ha større betydning bare det er gjordt et valg, f.eks.

Format 1 24-jun-1954
Format 2 24 jun 1954
Format 3 06/24/1954
Format 4 06-24-1954
Format 5 jun-24-1954
Format 6 jun 24 1954
Format 7 24-jun-1954
Format 8 24 jun 1954
Format 9 24-06-1954
Format 10 1954.06.24
Format 11 1954-06-24

Dette registrerres og inn i selve databasen til programmet blir dette ivaretatt på en egnet måte.

Deretter skal det lages en GEDCOM. Dette er et program som lager en standard som kommukan leses av det mottakende program og så bli presentert i et for brukeren vennlig format. Dette valget er et valg som ligger tilgjengelig i programmet.

Brukeren skal ikke bry seg om den GEDCOMstandard som settes/brukes på datoen. Det er programansvarlig av programmet sin jobb.

Språk
Meste skritt er bruke av bokstaver. Dagens Gedcom aksepterer for de fleste programm ascii, ansi, ansel og UTF-8.

I dagens verden er det gitt noen anbefalinger, også i dagengens GEDCOM 5.5 som tross alt er det eneste og beste vi har. Vi får akseptere at det er dagens verden.

Så har vi en rekke hendellser og der har vi en begrening ved at mange (for oss Normale hendelser) ikke inngår i GED5.5. Noen programmere har akseptert dette og laget en del Tags som starter med _ (underscore) i samsvar med anbefalingen i GED5.5. Noen produsener har tilpasset seg markedet og lagt inn hendelser som er normale i en del land, f.eks. introdusjon (av en kvinne etter en barnefødsel).
Så til slutt har man alle de hendelsene som den enkelte bruker produserer av ulike årsaker. Selv disse har i GED5.5 sin beskrivelse om hvordan de skal være.

Dermed vil jeg påstå at mye kan gjøres paralellt, Øke graden av kommunikasjon innefor dagens verden samtidig som man arbeider for en bedre mulighet.

Strukturer av database.
Stor sett betyr ikke det så veldig mye. I utgangspunkt er det et lagrinsted som skal være effektiv, så hvilket programvare som er brukt for oppbygging av databasen, er for bruker av mindre betyning bare den er stabil og effektiv.

Presentasjoner
Jeg har med vilje unlatt webløsninger, rapporter, grafer etc, da dette er tekniske finesser som ligger utenfor selve databasen og intensjonen vi har med selve databasen og de strukturer som ligger der.

[Gunnar Østegården]

Jeg har en tid hatt planer om å gå over til et annet databaseprogram.

Jeg HAR laget gedcom-fil av databasen. Men når jeg forsøker å importere den til et nytt program, får jeg opp en liste på en håndfull tagger som programmet ikke forstår. Da blir jeg usikker.

Det virker litt håpløst: - å finne fram til hva eksport-kodene betyr.
Det virker enda mer håpløst: - å finne fram til en import-kode som passer.

Nåvel, formodentlig er det ikke så viktig informasjon som vil bli borte.
Men jeg har foreløpig ikke tatt spranget. Jeg er jo fornøyd og jeg hører om problemer med datoformatet - eller med de nordiske bokstavene.

Men det var aldri åpenbart for meg, at jeg i årevis har gjort meg nytte av koder med såkallt underscore.
Det forekommer meg helt åpenbart, at den som lager programmene ønsker ihvertfall ikke at jeg skal bytte program.

Ettersom programprodusentene er uinteressert i det: - burde ikke vi som brukere prøve å advare hverandre?
Var det mulig å få en liste med tagger som man bør sky unna bruken av?
Var det mulig å få en liste med tagger som kan fungere som (nestbeste) alternativ?
(Og ikke bare en liste med kryptiske bokstaver, men forståelige ord og meninger)
Og en liste med øvrige valg/innstillinger man skal sky?
Eller skal alle vente - til alle er enige om en ny standard?

Mvh Gunnar.

[Otto Jørgensen]

Uten å vite hvilken konder som avvises vil jeg tro at det er enten produsentens definerte koder/Tags (skal starte med _ (underscore)) eller er brukerens definerte koder.

Gedcom 5.5 standarden bør alle program i dag klare, men det kan variere sterkt hva et program klarer av de øvrige kodene fra et vilkårlig program.

[Gunnar Østegården]

Det dreier seg utelukkende om koder som starter med underscore.
Eksport fra BK - til Legacy.
(Skulle det kanskje være som å bevege seg fra asken til ilden?)

Nå bør jeg vel forsøke å finne de ulike kodene - og jeg vet hvor jeg skal finne dem, Otto.
Så skal jeg prøve å erstatte dem med noe mer anvendelig og eksporvennligere i mitt gamle program.
Og jeg må framfor allt slutte å bruke dem.

Mvh Gunnar.

[Otto Jørgensen]

I og med at du ikke forteller mye nok og ikke forteller i BK-Nordic, er det desverre for lite jeg kan supplere med her.

Kan for sikkerhets skyld og for andre nevne at http://www.bkwin.info/bk6/hjelp-stotte/ ... norsk.html har en oversikt over koder som en rekke ulike program har i bruk. Om alt er dekket der kan jeg ikke si, da det avhenger av responsen fra de ulike kontaktpersonene for de forskjellige programmene i Norge.

[Gunnar Østegården]

Poenget her er vel at dette ser ut til å være et generellt problem.
Det gjelder antagelig alle programmene.
Og
- de fleste av oss brukere aner ingenting om disse underscore-taggene når vi begynner å ta i bruk programmene våre.
- mange av oss begynner kanskje tilogmed å definere våre egne tagger.
- mange av oss tar i bruk sine egen-definerte datoformater.
- mange finner veldig kreative løsninger på allskens 'mangler' ved sitt program.

Men om ikke programmet advarer på et eller annet tidspunkt, - så blir våre systemer mindre og mindre kompatible jo lenger tiden går.

Det synes altså som om programskaperne ikke er interessert i å lage sine programmer mer samarbeidsvillige, snarere tvert om.
Dessverre!

Mvh Gunnar.

[Otto Jørgensen]

Problemet er vel

at GEDCOM (språket vi skal bruke for å utveksle data) ble utviklet for mange år siden og er ikke siden særlig oppdatert. Dog foregår en viss utvikling og muligens vil det om noen år finnes en ny løsninge.

at brukerne har behov for flere koder og proogramutviklerne lager også flere. En oversikt som viser dette har jeg nevnt tidligere.

at noen programutviklere lager også i sine programmer interne løsninger somgjør at import av andres program går greit. (de internt oversetter andre programmers løsninger).

desverre så skytes det på ulike sider av denne verden; noen skylder på avgivende program mens noen skyldes på mottakende program. Begge sider har sin del av elendigheten. I stedet burde brukerne i større grad gå mot produsentene av sitt program og prøve å påvirke disse til å gjøre sitt program bedre.

at man i de ulike program må følge det som i det minste er satt som standarder i GEDCOM5.5 m.h.t. tegnsetting, datoformater og kodestruktur. Dette er tross alt det vi har og enda i mange år må leve med.

[55901]

I stedet burde brukerne i større grad gå mot produsentene av sitt program og prøve å påvirke disse til å gjøre sitt program bedre.
at man i de ulike program må følge det som i det minste er satt som standarder i GEDCOM5.5 m.h.t. tegnsetting, datoformater og kodestruktur.

Er det noen som gjør dette?

[Otto Jørgensen]

Du kan jo se litt på http://www.bkwin.info/bk6/hjelp-stotte/ ... er-gedcom/ men det finnes også mange andre steder.

Men Norsk aktivitet synes å være liten.

[Gunnar Østegården]

at brukerne har behov for flere koder og proogramutviklerne lager også flere.

Mon tro om brukerne behøver flere koder!
At visse brukere ønsker flere koder er kanskje en annen sak.
Men å lage en ny kode forat man skal kunne beskrive alle livets tenkelige tildragelser, må da være å gå for langt, eller?
Det burde vel kunne gå an å legge til en tekststreng i fritekst til en eksisterende kode iblant også, - eller?
Og når produsenten legger inn en ny kode som ikke finnes i Gedcom - burde han vel kunne ta av seg skylappene og skjele over til hvordan andre produsenter løser dette. Eller regnes dette som plagiat og er dermed ulovlig?

Men for oss brukere er dette et problem som ikke eksisterer; - før vi skal eksportere vårt produkt. Mange av oss har aldri visst, at vi - i løpet av mange år - har skapt oss et problem.

Mvh Gunnar.

[dn10375]

Slektsprogrammet TMG bruker følgende standardmetode i sin GEDCOMeksport for å angi hendelser som ikke er standard og derfor defineres av brukeren:

1 EVEN
2 TYPE Vasaloppet
2 DATE 6 MAR 2011

Hendelsen angis altså som type EVEN og et forståelig navn under TYPE. Da er det ikke noe problem for (de fleste?) importerende program å tolke hva hendelsene betyr.

TMG bruker ikke "understrek-metoden" som feks "_VLOPP".
Likevel har ikke TMG noe problem med å importere slike hendelser, de kan oversettes til forståelig språk av brukeren under impordialogen. Forutsatt at det framgår fra eksporterende program hva disse "underscore-hendelsene" betyr.

Torleif Haugødegård

[dn01013]

Slektsprogrammet TMG bruker følgende standardmetode i sin GEDCOMeksport for å angi hendelser som ikke er standard og derfor defineres av brukeren:

1 EVEN
2 TYPE Vasaloppet
2 DATE 6 MAR 2011

Hendelsen angis altså som type EVEN og et forståelig navn under TYPE. Da er det ikke noe problem for (de fleste?) importerende program å tolke hva hendelsene betyr.

Dette er standardmetoden for å overføre data om tags som er ukjente.

Disgen gjør akkurat det samme, og har også en egen post for dette (Spesial)

Underscore-tag'ene er kun ment for overføring av data mellom to brukere av samme program, maksimalt.

Hm. Kanskje marked for en konverterigsrutine ??

[Otto Jørgensen]

Kommentar til Alf Chr.:

Bruken av Underscore ble definert og beskrevet i GEDCOM5.4 og er siden ikke trukket tilbake http://homepages.rootsweb.ancestry.com/ ... int.htm#S2

Hvis det er overføring av data mellom to program av samme type ville jeg neppe brukt GEDCOM. De fleste program (tror jeg) har mulighet til å plukke ut deler av sin database og sende dette til mottakeren. Man får samme effekt på en mer effektiv måte og man er mer sikker på at alt man ønsker blir med. En GEDCOM er ikke en garanti for dett. Hvor mange har eksportrt sin database (avansert brukt) og importrt denne igjen uten å miste data?

Det er for øvrig en rekke programleverandører som har i bruk Underscore. En oversikt over for meg kjente programmer vises på http://www.bkwin.info/bk6/hjelp-stotte/ ... koder.html Her mangler sikkert en god del, men det skyldes at det ikke er lett å få tilbakemeldinger fra produsentene eller fra norske faddere/representanter.

For øvrig kan jo brukerne av slektsprogrammer selv velge sine muligheter fra programmets enkleste muligheter til programmenes maksimale muligheter.

[dn01013]

Jeg er fullt klar over definisjonen.
Men den er særdeles lite velgjennomtenkt og det finnes ikke standarder for hvordan informasjonen skal overbringes. Kun navnet.

Tag'en EVEN derimot har en standard funksjon og er enkel å bruke til dette.

Underscore-tags burde bli fjernet fra neste revisjon da den er en informasjonsoverføringsmessig blindvei.

[Gunnar Østegården]

Slektsprogrammet TMG bruker følgende standardmetode i sin GEDCOMeksport for å angi hendelser som ikke er standard og derfor defineres av brukeren:

1 EVEN
2 TYPE Vasaloppet
2 DATE 6 MAR 2011

Hendelsen angis altså som type EVEN og et forståelig navn under TYPE. Da er det ikke noe problem for (de fleste?) importerende program å tolke hva hendelsene betyr.

Det høres helt suverent ut.
Men hva skjer med det Vasaloppet i 2011, - dersom jeg, mot formodning, skulle ønske å bytte program? Da blir det vel borte, da - ihvertfall for en middels begavet datamaskin-amatør?

Men TMG ønsker vel ikke å advare mot slik ekstravagant (mis-)bruk av hendelser. Derigården er det sikkert ingen som ønsker at noen skal bytte til et annet program.
- Og dette er vel hele problemets kjerne. De store programskaperne ØNSKER ingen standardisering.

Mvh Gunnar.

[dn10375]

Slektsprogrammet TMG bruker følgende standardmetode i sin GEDCOMeksport for å angi hendelser som ikke er standard og derfor defineres av brukeren:

1 EVEN
2 TYPE Vasaloppet
2 DATE 6 MAR 2011

Hendelsen angis altså som type EVEN og et forståelig navn under TYPE. Da er det ikke noe problem for (de fleste?) importerende program å tolke hva hendelsene betyr.

Det høres helt suverent ut.
Men hva skjer med det Vasaloppet i 2011, - dersom jeg, mot formodning, skulle ønske å bytte program? Da blir det vel borte, da - ihvertfall for en middels begavet datamaskin-amatør?

Men TMG ønsker vel ikke å advare mot slik ekstravagant (mis-)bruk av hendelser. Derigården er det sikkert ingen som ønsker at noen skal bytte til et annet program.
- Og dette er vel hele problemets kjerne. De store programskaperne ØNSKER ingen standardisering.

Mvh Gunnar.

TMG bruker som sagt en _standard_ GEDCOMmetode (EVEN) til å definere nye hendelser som ikke allerede finnes i TMG. Eksempelvis hendelsen "Vasaloppet".

Dette er helt kurant å bruke og det er ingen grunn til advarsler mot dette. Eksporten av "Vasaloppet" ut fra TMG er også helt uproblematisk, med metoden nevnt over. Når hendelsen en gang for alle er lagt inn i TMG vil eksporten gå automatisk uten at brukeren må spesifisere noen GEDCOMkoder.

Og import av "underscore-tags" inn i TMG er også helt uproblematisk, som nevnt over.

Torleif Haugødegård

[dn10375]

.... Det er for øvrig en rekke programleverandører som har i bruk Underscore. En oversikt over for meg kjente programmer vises på http://www.bkwin.info/bk6/hjelp-stotte/ ... koder.html Her mangler sikkert en god del, men det skyldes at det ikke er lett å få tilbakemeldinger fra produsentene eller fra norske faddere/representanter.
...

Grei oversikt.
Hvordan skal en importør av en GEDCOM fra BK ellers vite hvilken hendelse som skjuler seg bak GEDCOMkoder som disse:
_ADPN
_BIRN
_CURN
_EYEC
... osvosv

Ved import i TMG kan brukeren undervegs for hver av disse skrive inn et fullt navn på aktuell hendelse. Hvis hun får vite hva som skjuler seg bak de uforståelige kodene.
Deretter er hendelsen opprettet i TMG med sine nye navn.

torleif h

[Gunnar Østegården]

[Dette er helt kurant å bruke og det er ingen grunn til advarsler mot dette. Eksporten av "Vasaloppet" ut fra TMG er også helt uproblematisk, med metoden nevnt over. Når hendelsen en gang for alle er lagt inn i TMG vil eksporten gå automatisk uten at brukeren må spesifisere noen GEDCOMkoder.

Og import av "underscore-tags" inn i TMG er også helt uproblematisk, som nevnt over.

Torleif Haugødegård

Helt knirkefritt
Hvis man kjører Rolls Roys så fungerer allt som det bør.
Det er kanskje litt vanskeligere om man vil importere noe av ekstrautstyret og montere det inn i ei vanlig folkevogn?
Mvh Gunnar.

[Otto Jørgensen]

Siden Torleif Haugødegård kommenterer meg.

Programmet jeg bruker har på sett og vis tre løsninger.

1) Rene GEDCOM 5.5 tags (som ligger i programmet)
2) Produsentdefinerte koder i henhold til GEDCOM5.5 hvor underscore er benyttet
3) Brukerens egen definering av hendelser.

Liste over alle koder i 1 og 2 finnes til gjengelige på min hjemmeside og i hjelpefilen til programmet. De finnes med både norsk og enkelsk tekst. Og om brukeren skifter til andre språk vil dette ivaretas grunnet de mange språk programmet er oversatt til.

Brukerdefinerte koder tilfredstiller den metodikk som er forklart og skulle derfor ikke være noe problem. Her vil dog den besikrivelse som bruker har brukt ikke bli oversatt.

Noen program bruker som nevnt tidligere også underscore for de hendelser som produsenten legger til rette for.

Her har produsenten av det program jeg bruker bl.a. lagt til rette for "introdusjon", "jordet" (som jo er noe annet enn begravet), "bekreftelse" (som er noe annet enn dåp i kirken selv om dette foregår i kirken; vanlig etter en hjemmedåp). Dette er hendelser som berører veldig mange av personer noe tilbake i tiden).

[dn10375]

... Her har produsenten av det program jeg bruker bl.a. lagt til rette for "introdusjon", "jordet" (som jo er noe annet enn begravet), "bekreftelse" (som er noe annet enn dåp i kirken selv om dette foregår i kirken; vanlig etter en hjemmedåp). Dette er hendelser som berører veldig mange av personer noe tilbake i tiden).

En test av GEDCOMeksport fra BK med et par av spesialhendelsene nevnt ovenfor og etterfølgende import i og eksport fra TMG:

BK-filen:
0 HEAD
1 SOUR BROSKEEP
2 VERS 6.4.19 WINDOWS
1 DEST BROSKEEP (BROTHERS KEEPER)
1 DATE 13 MAR 2011
1 CHAR ANSI
1 FILE C:\Brother’s Keeper 6\Data\gedtest-tha.GED
1 GEDC
2 VERS 5.5
2 FORM LINEAGE-LINKED
0 @I1@ INDI
1 NAME Eva /Olsdatter/
1 SEX F
1 BIRT
2 DATE 1888
2 PLAC Oslo
1 _CHWN
2 DATE 1920
1 _MEMR
2 DATE 1977
2 PLAC Hamar
0 TRLR

Under importen i TMG vil brukeren oversette kodene _CHWN og _MEMR til hhv. Introduksjon og Jordfestelse.
Metoden og sluttresultatet i TMG er vist i detaljer her: http://www.tha.no/?page_id=194

Eksportert fra TMG igjen har hendelsene fått forståelige navn iht. GEDCOMreglene:
0 HEAD
1 SOUR TMG
2 VERS v 7.04.0000
1 SUBM @SUB1@
1 GEDC
2 VERS 5.5
2 FORM LINEAGE-LINKED
1 DEST GED55
1 DATE 13 MAR 2011
2 TIME 12:37
1 CHAR ANSI
1 FILE C:\Users\torleif\Documents\The Master Genealogist v7\Export\bktest-fraTMG.ged
0 @SUB1@ SUBM
1 NAME Submitter Name
0 @I2@ INDI
1 NAME Eva /Olsdatter/
1 SEX F
1 CHAN
2 DATE 13 MAR 2011
1 BIRT
2 DATE 1888
2 PLAC Oslo
1 EVEN
2 TYPE Introduksjon
2 DATE 1920
1 EVEN
2 TYPE Jordfestelse
2 DATE 1977
2 PLAC Hamar
0 TRLR


Torleif Haugødegård

[Otto Jørgensen]

Til Torleif:

Bra, da har jo TMG en løsning for sitt vedkommende.

Forøvrig en bra henvisning til http://www.tha.no/?page_id=194 selv om den var litt unyansert når den bare henviser til kun et program. Dog bruker en rekke program underscore som jeg viste til tidligere i min oversikt på http://www.bkwin.info/bk6/hjelp-stotte/ ... koder.html
Verden består ikke av noen få program; den er mangfoldig.

Tilleggsmerknad 14 mars 2011:
Jordfestelse er nødvendigvis ikke det samme som begravelse. Det er gjerne det i dag da hele seremonien gjerne skjer samtidig, men i eldre tiden kunne kisten begraves/senkes i jorden flere måneder før presten kom og det var da ofte en senere handling på kirkegården hvor den dødes kiste ble jordfestet. Hvor og når dette ble gjordt varierer med sted og tid. Derfor er også begrepet bisettelse noe annet enn begravelse selv i dag, hvor man som følge av bisettelse har kremasjon og senere urnenedsettelse.

[Gunnar Østegården]

Det høres bra ut.
Da skal man bare ha tunga rett i munnen, slik at man holder orden på de kryptiske kodene.

Men kanskje man burde presse på for å få BK til å konvertere sine underscore-tagger til tagger av EVEN - TYPE.
Alternativt burde vel:
- vi som er brukere av BK heller gå over til å bruke egendefinerte tagger.
For da går vel importen til TMG enda enklere

Mvh Gunnar.

[Otto Jørgensen]

Hvorfor skal en gjøre det for enkelt slik at man kan bruke diverse programmer i ren konverteringsøyemed.

Tar man en gedcomfile og vil over til et annet program, må det være opp til det mottagende program å behandle dataene.

Det er forutsatt at gedcomfilen er laget i henhold til standard og så langt er det ikke noe som tyder på at så ikke er tilfelle

Nå klarer jo TMG dette og da er jo det problemet løst for TMGs vedkommende.

[55901]

Legacy hadde ingen problemer ved import av BK-gedcom. Det ble varslet om to ukjente tags og det ble gitt muligheter til å knytte til kjente eller lage nye. Jeg valgte det siste og resultatet ble slik som vist nedenfor, ved eksport av GEDCOM-fil. Er det noe å utsette på resultatet?

0 HEAD
1 SOUR Legacy
2 VERS 7.5
2 NAME Legacy (R)
2 CORP Millennia Corp.
3 ADDR PO Box 9410
4 CONT Surprise, AZ 85374
1 DEST Gedcom55
1 DATE 16 Mar 2011
1 SUBM @S0@
1 FILE C:\Documents and Settings\Legacy til 55.ged
1 GEDC
2 VERS 5.5
2 FORM LINEAGE-LINKED
1 CHAR ANSI
0 @S0@ SUBM
1 NAME Ikke gitt
0 @I1@ INDI
1 NAME Eva /Olsdatter/
2 GIVN Eva
2 SURN Olsdatter
1 SEX F
1 BIRT
2 DATE 1888
2 PLAC Oslo
1 DEAT Y
1 EVEN Introduksjon
2 TYPE Introduksjon
2 DATE 1920
1 EVEN Jordfestelse
2 TYPE Jordfestelse
2 DATE 1977
2 PLAC Hamar
1 _UID 546CD2C803B54E5F82A524667409CA5108BF
1 CHAN
2 DATE 16 Mar 2011
3 TIME 11:12
0 TRLR

[Otto Jørgensen]

Bra

Dette viser bare at Legacy selv har løsning til å behandle dette i sin import. dette må være det riktige at programmene som importerer, behandler dette selv.

[55901]

Har også prøvd import av samme BK-gedcom til Family Tree Maker 2011. Importen gikk uten at det ble gitt beskjed om feil eller ukjente tags. Her er resultatet. GEDCOM-eksporten var lik importen.





Ved å gå inn på Facts under personen og endre de respektive tags, og deretter foreta en GEDCOM-eksport, ble dette resultatet:





0 HEAD
1 SOUR FTM
2 VERS Family Tree Maker (20.0.0.368)
2 NAME Family Tree Maker for Windows
2 CORP Ancestry.com
3 ADDR 360 W 4800 N
4 CONT Provo, UT 84604
3 PHON (801) 705-7000
1 DEST GED55
1 DATE 16 MAR 2011
1 CHAR ANSI
1 FILE C:\Documents and Settings\FTM til 55 korr.ged
1 SUBM @SUBM@
1 GEDC
2 VERS 5.5
2 FORM LINEAGE-LINKED
0 @SUBM@ SUBM
0 @I1@ INDI
1 NAME Eva /Olsdatter/
1 SEX F
1 BIRT
2 DATE 1888
2 PLAC Oslo
1 EVEN
2 TYPE Introduksjon
2 DATE 1920
1 EVEN
2 TYPE Jordfestelse
2 DATE 1977
2 PLAC Hamar
0 TRLR

[Otto Jørgensen]

Bare for å påpeke en gang til. Hva andre program klarer eller ikke klarer, er deres sak. Klarer de det ikke, er det også deres sak og ikke sak for BK.

BK produserer sine Gedcom etter standard og importere Gedcomfiler.

[Gunnar Østegården]

Ja, nå har også jeg forsøkt meg litt med å eksportere gedcom. Det ser ut til at jeg skal klare å få med meg alle taggene mine inn i et nytt program, - dersom jeg skulle få lyst til det. Men jeg er jo svært godt fornøyd med programmet mitt.

Men et annet problem som jeg først nå er blitt klar over, - jeg får hundrevis med feilmeldinger på datoformat som ikke forstås. Her har jeg nok i årevis vært slurvete med datoene.
Bl. a. har jeg ofte skrevet årstall som et spenn mellom to år, - hvilket tydligvis ikke godtas av gedcom.
Her får jeg visst litt av en jobb å gjøre, - uansett om jeg skal eksportere gedcom eller ei.

Mvh Gunnar.

[dn10375]

Ja, nå har også jeg forsøkt meg litt med å eksportere gedcom. Det ser ut til at jeg skal klare å få med meg alle taggene mine inn i et nytt program, - dersom jeg skulle få lyst til det. Men jeg er jo svært godt fornøyd med programmet mitt.

Men et annet problem som jeg først nå er blitt klar over, - jeg får hundrevis med feilmeldinger på datoformat som ikke forstås. Her har jeg nok i årevis vært slurvete med datoene.
Bl. a. har jeg ofte skrevet årstall som et spenn mellom to år, - hvilket tydligvis ikke godtas av gedcom.
Her får jeg visst litt av en jobb å gjøre, - uansett om jeg skal eksportere gedcom eller ei.

Mvh Gunnar.

Hva sier feilmeldingene, kan det være at datoer som "17 mai 1814" ikke forstås/kan tolkes av det importerende programmet?

Årsintervall i datoer er kurant i GEDCOM.
TMG eksporterer dette slik:

1 BIRT
2 DATE BET 1888 AND 1899
2 PLAC Oslo

Torleif H.

[dn10375]

Legacy hadde ingen problemer ved import av BK-gedcom. Det ble varslet om to ukjente tags og det ble gitt muligheter til å knytte til kjente eller lage nye. Jeg valgte det siste og resultatet ble slik som vist nedenfor, ved eksport av GEDCOM-fil. Er det noe å utsette på resultatet?

......
0 @I1@ INDI
1 NAME Eva /Olsdatter/
2 GIVN Eva
2 SURN Olsdatter
1 SEX F
1 BIRT
2 DATE 1888
2 PLAC Oslo
1 DEAT Y
1 EVEN Introduksjon
2 TYPE Introduksjon
2 DATE 1920
1 EVEN Jordfestelse
2 TYPE Jordfestelse
2 DATE 1977
2 PLAC Hamar
1 _UID 546CD2C803B54E5F82A524667409CA5108BF
1 CHAN
2 DATE 16 Mar 2011
3 TIME 11:12
0 TRLR

Konstruksjonen
1 EVEN Introduksjon
2 TYPE Introduksjon
ser ikke riktig ut, det skal ikke stå noe bak "EVEN".
Hendelsen Introduksjon blir importert i TMG med et tilleggsnotat med tekst "Introduksjon" av denne grunn.

Det står ikke noe i den originale GEDCOMfilen fra BK om død, slik Legacy har eksportert det:
1 DEAT Y

Hva betyr denne:
1 _UID 546CD2C803B54E5F82A524667409CA5108BF

Torleif H.

[Otto Jørgensen]

I BK dobbeltklikker man på datofeltet og det åpnes et vindu hvor man legger inn datospennet.

Dette står forklart i hjelpefilen til programmet.

Hjelpefilen aktiveres ved å trykke <F1>

Rart at folk ikke lærer å bruke de hjelpemidler som ligger rett foran seg, nemmlig den hjelp som ligger i selve programmet.

[55901]

Hva betyr denne:
1 _UID 546CD2C803B54E5F82A524667409CA5108BF

Torleif H.

_UID: Et unikt identifikasjonsnummer gitt til hver person i en familiefil.
Dette i følge hjelpefilen.


Hvorfor og hvordan resten har blitt som det er, vet jeg ikke. Derfor spurte jeg også om det var noe å utsette på resultatet.
At det står oppgitt som død, kan det være fordi Legacy (av meg) er innstilt på å automatisk å sette alle født 110 år før dags dato er å anse som døde? Får jo opp et varsel dersom jeg legger inn en fødselsdato og ingen dødsdato ved lagring.
Er dette da en feil i produksjonen av GEDCOM?


1 EVEN Introduksjon
2 TYPE Introduksjon
Ser at både TMG og FTM ikke har noen beskrivelse etter EVEN. Er dette da en feil i Legacy som bør rapporteres til produsenten?

[dn18596]

Tilbake til Alfs åpning av denne tråden har jeg bare en refleksjon. Det blir sagt att man ikke får fram en ny GEDCOM standard fordi de forskjellige produsentene hevder sin særart som de har i sine program med forskjellige varianter av underscore etc. Dette fortsetter i neste ledd når de norske forhandlere av noen program også viser på fordeler med sitt egne eller ulemper med andres.

Det som Alf tok opp og som jeg mener DIS sammen med leverandører/representanter i Norge skulle gjøre er å spesifisere en standard som dekker våre behov. Gjerne bredde det med de andre Nordiske foreninger for å få litt tyngde bakom ønskemålene.

Jeg kan ikke forstå att dette ikke skulle være umulig, vi ville ikke hatt mobiltelefoner som kan tas med over det meste av verden eller mye annen datakommunikasjon om ikke produsentene gikk sammen om å skrive standarder. Dette skjer kontinuerlig og jeg har selv vært med i møte med ingeniører fra de fem-seks største mobiltelefonprodusentene som seriøst og uten prestisje diskuterte hva som skulle fungere best.

Mvh Niels

[Gunnar Østegården]

I BK dobbeltklikker man på datofeltet og det åpnes et vindu hvor man legger inn datospennet.

Dette står forklart i hjelpefilen til programmet.

Hjelpefilen aktiveres ved å trykke <F1>

Rart at folk ikke lærer å bruke de hjelpemidler som ligger rett foran seg, nemmlig den hjelp som ligger i selve programmet.

Nei, å åpne hjelpefilen til programmet, - det er nederlag, det
Programmet mitt viser röd skrift hvis jeg setter inn feil format. Jeg har nå begynnt å rette meg etter dette tydelige signalet. Men det ser ut til at visse feilformater har sluppet igjennom denne kontrollen allikevel.

Mine feilmeldinger ved gedcomimport spenner over ut uttall årsaker, - som: hösten 1860, 24 april 1799, mikkelsmess 1814, 1816 - 1821, tvillinger, o.m.m.
Jeg laster ikke programmet mitt for disse blunderne
Og er glad for at jeg nå tror jeg er blitt klar over hvordan jeg SKAL före datoene.

Mvh Gunnar.

[dn10351]

Jeg hvet lite om lagingen av Gedcom, men har et ønske til den som måtte ha innflytelse på utviklingen. Kan det lages et eget felt for mellomnavn? Pr. i dag bruker jeg Prefix til mellomnavn (samme felt som eks Mc.....) Dette er egentlig ikke riktige felt, men programutvikler sa at det blir vanskelig med annet så lenge gedcom-standard ikke har det.

Vi i Norge har brukt mellomnavn i over hundre år med litt forskjellige grunner. Til og med offentlige skjema har eget felt for mellomnavn. Jeg synes det bør vises respekt for dette

[Otto Jørgensen]

Til Lena Ekholt

Hva er mellomnavn

En kar heter Otto Asbjørn Hansen. Hans bruker og er kjent med navnet Arbjørn Hansen, men rekkefølgenb av navne er som angitt.

Hvorfor ha eget felt for mellomnavn. Vet at ofte har myndighetene benevnet et navn som mellomnavn, men hvis personen er døpt som Anne Marie og bruker dette i alle sammenheng; hva er da mellomnavnet? Marie?

Ting som Mac Von der Van der etc er en sak som man bør klare med sletsprogrammet og forteller en evt. Gedcom hva dette er. Man trenger ikke lage ekstra blanke felter i Gedcom for det. Dette er en programmessig job for programutvikler

[dn10375]

Jeg hvet lite om lagingen av Gedcom, men har et ønske til den som måtte ha innflytelse på utviklingen. Kan det lages et eget felt for mellomnavn? Pr. i dag bruker jeg Prefix til mellomnavn (samme felt som eks Mc.....) Dette er egentlig ikke riktige felt, men programutvikler sa at det blir vanskelig med annet så lenge gedcom-standard ikke har det.

Vi i Norge har brukt mellomnavn i over hundre år med litt forskjellige grunner. Til og med offentlige skjema har eget felt for mellomnavn. Jeg synes det bør vises respekt for dette

TMG har eget felt for mellomnavn og det eksporteres til GEDCOM på denne måten:

1 NAME Eva /Olsdatter Hansen/
2 GIVN Eva
2 SPFX Olsdatter
2 SURN Hansen

Koden "SPFX" betyr "Surname Prefix" som i TMG er oversatt med "Fars-/Mellomnavn".
TMGv8 vil importere SPFX til sitt felt for Fars-/Mellomnavn, det skjer ikke i TMGv7.

Torleif H

[Johan Arthur Hansen]

[quote="Otto"]Til Lena Ekholt

Hva er mellomnavn

En kar heter Otto Asbjørn Hansen. Hans bruker og er kjent med navnet Arbjørn Hansen, men rekkefølgenb av navne er som angitt.

Hvorfor ha eget felt for mellomnavn. Vet at ofte har myndighetene benevnet et navn som mellomnavn, men hvis personen er døpt som Anne Marie og bruker dette i alle sammenheng; hva er da mellomnavnet? Marie?

Verken Asbjørn eller Marie er mellomnavn - det er fornavn. I dag er det vel en del som har pikenavnet som mellomnavn eks. Olsen Pedersen hvis de ikke bruker Olsen-Pedersen, men da er det et etternavn. Trodde alle slektprogram hadde eget felt for mellomnavn, men det er få ganger jeg bruker mellomnavnsfeltet i Embla.
Mvh. Johan Arthur Hansen

[Otto Jørgensen]

Tror disse definisjonene fra GEDCOM 5.5. kan være greie

NPFX {NAME_PREFIX}: =
Text which appears on a name line before the given and surname parts of a name.
i.e. ( Lt. Cmndr. ) Joseph /Allen/ jr.
In this example Lt. Cmndr. is considered as the name prefix portion.

NSFX {NAME_SUFFIX}: =
Text which appears on a name line after or behind the given and surname parts of a name.
i.e. Lt. Cmndr. Joseph /Allen/ ( jr. )
In this example jr. is considered as the name suffix portion.

SPFX {SURN_PREFIX}: = A name piece used as a non-indexing pre-part of a surname.

http://homepages.rootsweb.ancestry.com/ ... gcappa.htm

Ser vi videre på navn:

Otto Asbjørn Hanse Prugelhei
navnebruken for vedkommende er Asbjørn Hansen
militærregisteret definerte han som Otto (fornavn) og Prugelhei (etternavn) Prugelhei er bare stedsnavnsom definisjon av stedet han var født, men er ikke døpenavn, ei heller hvilket sted han ble født på, men stedet han tilfeldigvis var på ved innkalling til det militære.

Forøvrig har ikke BK begrepet mellomnavn


På denne siden (ca halvveis) http://homepages.rootsweb.ancestry.com/ ... ch2.htm#S6 finner en tema NAME_PERSONAL
Dette kan det være fornuftig å studere litt relatert til dette tema.

[dn18596]

Uten å tenke på vad de forskjellige programmene gjør vil jeg gjerne fortsette med ett forsøk å få debatten inn på vad en ny og bedre standard skulle inneholde. For det er vel det viktigste?

Vi har kompliserte navneskikker i Norden og det krever en del omtanke for å se om det kan løses. Og hvordan.

Ulempen med bruk av pre-og suffix er att det per definisjon ikke er mellom- eller gårdsnavn. Det er en måte en del program tydeligvis har valgt for å løse den nå gjellende, og mangelfulle, GEDCOM standarden, men jeg kan ikke se att det vil fungere i alle situasjoner.

Spansktalende land har ofte med morsnavn som mellomnavn og gjerne ett par ekstra mellomnavn for de som står høyt på den sosiale rangstigen. Det må en ny standard også ta hensyn til sammen med sikkert flere andre egenheter man kan fine rundt i verden.

Mvh
Niels

[dn01013]

Mellomnavn opptrer når et barn døpes med et slektsnavn i tillegg til ordinære fornavn

F.eks. står det i min bestefars oppførsel

Otto Albert Wyller

Men i dagligtale het han Arnesen til etternavn.

Men som voksen fikk han tillatelse til å stryke Arnesen, men måtte kalle seg Wüller og ikke Wyller

Så dette er da et mellomnavn.


For øvrig, for å ikke få problem med den slags i DIStreff trekkes i dag kun ut 1. fornavn for å ikke få problem med mellomnavn.

DISBYT derimot støtter sletting av slikt ved å bruke navnenormalisering og hvis de resterende fornavna finnes i tabellen tas de med.

[dn24975]

Dette prosjektet er sikkert spennende nok for de involverte, men hva er sjansen for at dette blir bredt adoptert de som skriver programmene folk flest bruker - uten at disse selv er involvert i utviklingen?

Jeg antar programutviklerne kan ha betydelig interesse i å være med på utviklingen av en ny og bedre standard, disse må jo daglig slite med begrensningene i den mangelfulle datamodellen GEDCOM bygger på. Dessuten er det hos disse både pengene og veldig mye av den faktiske kompetansen ligger. De forskjellige kommersielle aktørene er sikkert i stand til å samarbeide også, på dette nivået.

Hvis man absolutt skal klamre seg til GEDCOM-navnet i dette prosjektet ville jeg foretrukket GEDCOM 7 framfor "BetterGEDCOM". Sistnevnte virker litt sammenrasket.

[6878]

Hvis det i en kilde står "Otto Asbjørn Hansen Prugelhei" og hvis det i anetavler og rapporter blir stående "Otto Asbjørn Hansen Prugelhei" uten at man trenger å ha et felt for mellomnavn (dvs dagens situasjon). Hva er da vitsen med å ha et felt for mellomnavn? Hva skal det brukes til? Det samme gjelder patronym. Kan ikke feltene like gjerne hete etternavn?

Jeg klarer ikke å se at det kan brukes til så mye annet en å sortere på. Å klassifisere ting som mellomnavn, patronym etc. tjener ikke til så mye annet enn å skape problemer. En løsning som tillater markering av flere etternavn, med mulighet for å sortere på del av et ord, tror jeg løser mye av sorteringsproblemet, og kan kanskje ha en mulighet for å bli akseptert internasjonalt.

Eller er det gode argumenter for å ha egne felt for mellomnavn eller patronym?

[dn01013]

Enig med Geir her.

Selv registrerer jeg i fornavnsfeltet alle fornavn og mellomnavn

I etternavnfeltet registrerer jeg evt. patronym og slektsnavn evt. gårdsnavn om det er nevnt brukt i kilder.

Hvis vedkommende flyttet mye, f.eks. som husmann eller kjøpte ofte ny gård, så nevner jeg gårdsnavnet videre i levdenotisene hvor jeg også angir tidsrom for dette.

For de som måtte lure, GEDtreff sjekker for patronymer i begge felter og trekker disse ut separat. Så Ole Olsen Øvrehagen kommer med både som Olsen\Ole og Øvrehagen\Ole

(Og bruker man et program som kan registrere ekstra navn så tas disse med også.

[Otto Jørgensen]

Jeg er vel litt stygg her, men sett ut fra et rent forhold i GEDCOM er det vel nesten å si at det er utenfor interess for GEDCOM hva DISTREFF/DISBYT gjør med dataene og fortolker disse.

Gedcom er et middel for kommunikasjon mellom slektsprogram fra forskjellige leverandører og på sin måte er DISDBYT/DISTREFF å betrakte som en hvilken som helst bruker som bruker en definert standard på sin spesielle måte og utnytter de opplysninger som finnes til det beste for medlenner av DIS. Å utnytte GEDCOM på sin måte er i seg selv ikke unikt.

[dn01013]

Jeg er vel litt stygg her, men sett ut fra et rent forhold i GEDCOM er det vel nesten å si at det er utenfor interess for GEDCOM hva DISTREFF/DISBYT gjør med dataene og fortolker disse.

Gedcom er et middel for kommunikasjon mellom slektsprogram fra forskjellige leverandører og på sin måte er DISDBYT/DISTREFF å betrakte som en hvilken som helst bruker som bruker en definert standard på sin spesielle måte og utnytter de opplysninger som finnes til det beste for medlenner av DIS. Å utnytte GEDCOM på sin måte er i seg selv ikke unikt.

Legg merke til konteksten: For de som måtte lure, GEDtreff sjekker etc. etc. etc..

Det er ofte spørsmål om hvordan man plasserer patronymer etc. Derfor benytter jeg anledningen til å minne om det.

Om du leste det som sto, så er det for DIStreffs vedkommende hipp som happ om man legger det i fornavn eller etternavnfeltet.

Men SPFX og lignende spesialiteter ignoreres.

[Otto Jørgensen]

Takhøyde her var desverre lav og hele mitt innlegg ble slettet av moderator selv om mye av teksten burde være meget relevant.

Dermed er tema avsluttet fra min side.

[dn10375]

....
Men SPFX og lignende spesialiteter ignoreres.

Så DISTREFF vil heller ikke i framtida importere personnavn, eksempelvis farsnavn, som er kodet med standard GEDCOMkode SPFX?

Torleif H

[dn01013]

....
Men SPFX og lignende spesialiteter ignoreres.

Så DISTREFF vil heller ikke i framtida importere personnavn, eksempelvis farsnavn, som er kodet med standard GEDCOMkode SPFX?

Torleif H

Når ble patronymer et slektsnavnprefix?

de la i 'de la Notte' er et surname prefix. Men, det finnes også i NAME-tagen som del av surnamedelen, i hverfall i de fleste tilfelle (og er i DIStreff-sammenheng en komponent som evt. utelukker treff hvis noen har registrert navnet med prefixer og andre uten.

Skal 'de la Notte' og 'Notte' gi tilslag eller ikke ??

Ved å ignorere SPFX vil man få 'Notte' som resultat i begge tilfeller og tilslag om fornavn er de samme.

Detaljer som 'de la' er noe man får rede på ved å ta kontakt med registrator. DIStreff er ikke ment som noen kilder man registrerer fra med evt. unntak av årstall og sokn|kommune for en begivenhet som et spor å følge videre. Resten får man finne selv.

Enten ved å kontakte kilden for dataregistreringen (avsender av datasettet) eller selve primærkilden.

[dn10351]

Jeg er nybegynner her, og jeg forstår det er forskjellig oppfatninger vedr mellomnavn. Det er også mye fagspråk her som jeg ikke forstår.

Det er litt jeg ønsker å si om det jeg forstod i tråden

1. Det ble sammenlignet fornavn med mellomnavn. I statene bruker de ordet "middle name" på annet område enn i Norge. Der er det snakk om fornavn. Jeg forstår da at de som fant opp Gedcom standarden ikke så verdien i 2 felt til fornavn Derimot har "mellomnavn" en egen plass her i Norge, hverken som fornavn eller etternavn. Eks. om jeg registrerer på et offentlig skjema fornavn, mellomnavn og etternavn i egne felt vil søkeresultatet bli annen rekkefølge på etternavn og mellomnavn enn om de begge var etternavn. Dette er i dag, men det offentlige har tatt hensyn og laget databasene sine deretter.

2. Med henhold til det å vise respekt for fødenavnet osv. Med all respekt for dem som ikke er av samme oppfatning så har jeg bestemt meg for at når eks. Hansen blir statisk, så skrives det som etternavn. Selv om en kan tenke at Per Hansen var mest kjent som Per Hansen og ikke Per Hanson Grasrot, så setter jeg på stedsnavn så lenge Hanson skifter til Person i neste ledd. Der jeg kommer fra var det vanlig for 100 år siden mm. på folkemunnet å beskrive Per Hanson "på Grasrot", akkurat som "Kari hans Per" eller "Per nas Kari". Så selv om vi skal være rettferdige med det de ble kallet så er det ikke sikkert de kun ble kallet fornavn og etternavn.

[6878]

Lena

Det finnes Internasjonalt minst 10 forskjellige betegnelser på ulike deler av navn. For mange av dem er det problemer med ulike definisjoner, og ikke minst å avgjøre om en del av et navn skal klassifiseres som det ene eller andre. Det har vært utrolig mange debatter om slik klassifisering på ulike fora. Dessuten vil et brukergrensesnitt med en haug med felter være problematisk.

I mitt forrige innlegg foreslo jeg at en fremtidig Gedcom bør prøve å unngå disse problemene ved å holde seg til en enkel modell med flere etternavn fordi det neppe er behov for en detaljert klassifisering i et slektsprogram. Eller er det det????

Når det gjelder Torleifs løsning er jeg enig med Alf. Et patronym er ikke et SPFX. Løsningen må vel klassifiseres som det noen gjør i buksa når det er kaldt. Det hadde vært bedre å overtale Bob Velke, dvs TMG, til å håndtere to etternavn i brukergrensesnittet mht sortering.

[dn10375]

I mitt forrige innlegg foreslo jeg at en fremtidig Gedcom bør prøve å unngå disse problemene ved å holde seg til en enkel modell med flere etternavn fordi det neppe er behov for en detaljert klassifisering i et slektsprogram. Eller er det det????

Når det gjelder Torleifs løsning er jeg enig med Alf. Et patronym er ikke et SPFX. Løsningen må vel klassifiseres som det noen gjør i buksa når det er kaldt. Det hadde vært bedre å overtale Bob Velke, dvs TMG, til å håndtere to etternavn i brukergrensesnittet mht sortering.

Det ser ut til at initiativet "BetterGEDCOM" har stranda fordi FamilySearch har et nytt format snart klart?
http://www.genealogymedia.com/2011/02/1 ... ata-model/
Du har jo deltatt i diskusjonen på BetterGEDCOMs Wiki og kjenner status?

Hva mener du med "håndtere to etternavn i brukergrensesnittet"?

Det er standardfeltet "PreSurname" som TMG eksporterer med kode SPFX, SurnamePreFiX.
I TMGv8 har dette navnefeltet fått betegnelsen "Fars-/Mellomnavn" og kan brukes til dette. Det er opp til brukeren av TMG å definere sin egen navnestil eller bruke den som er standard.

TMGv8s navnefelt er disse:
Tittel, Prefiks, Fornavn, Fars-/Mellomnavn, Etternavn, Suffiks, AnnetNavn, Sorteringsetternavn, Sorteringsforrnavn.

TMGv7 har de samme, men der er de ikke oversatt til norsk som standard.

Torleif H

[Otto Jørgensen]

Det er kalrt at legger mang andre for¨ståelser av de engelske beskrivelsemne for Gedcomcoden enn hva som er intensjonen i 5.5 blir det feil og det ligger til hver program å følge regelene.

[6878]

Torleif

Det er interessant å merke seg er at Familysearch (FS) i fjor høst oppga at de ikke hadde noen planer om å oppgradere Gedcom, og de nevnte heller ikke noe om at de hadde noe annet på gang. Etter en måned startet BettergGEDCOM prosjektet, og så tar det ikke mer enn to måneder før en av sjefene i FS kommer med en UFORMELL uttalelse om at FS jobber med noe (det er ikke sagt at det er et filformat, ryktene sier at det er et API nr 2 fra FS). Det skal ikke så mye fantasi til for å se at hensikten med å antyde at Familysearch kan komme med en spesifikasjon er å sørge for at FS har kontroll, og å ta knekken på andre initiativ ala det som ble forsøkt i Rootstech møtet, eller BetterGEDCOM eller OpenGen. Resultatet lot ikke vente på seg, det gikk noen få dager og så gikk lufta ut av BetterGEDCOM.

Det skal legges til at det var mange, inkl. undertegnede, som før BetterGEDCOM kom i gang, offentlig uttalte sterk skepsis til om BetterGEDCOM var i stand til å lage en standard. Det viste seg raskt at det som ble hevdet i starten om at programleverandørene var med på arbeidet ikke stemte, det er så vidt jeg vet kun noen få utviklere av mindre brukte program som har bidratt. Dessuten viste det seg raskt at det er ekstremt vanskelig å etablere en beslutningsmekanisme i et åpent forum. Men, så er spørsmålet, hva er alternativet – jo, enten skjer det ingen ting eller så er det de store amerikanske aktørene som styrer det hele, og vi vet hvordan det da går med europeiske og norske behov. Så selv om det raskt ble klart at BetterGEDCOM ville ha problemer med å lage en standard, så har jeg sett på det som en kanal for å publisere brukerbehov, og jeg har ikke hatt vondt av å delta i diskusjonene – jeg har lært mye. Så kan man spørre hvorfor vi ikke ga opp med en gang – vel, det er vanskelig å på forhånd si hva som kan komme ut av slike prosesser og det dummeste vi kunne gjort var å gi opp før vi hadde begynt – noe de fleste andre har gjort.

Avhengig av hva Familysearch kommer med, kan det hende at det viktigste resultatet av BetterGEDCOM var å provosere FS til å komme med noe. Men, man skal legge merke til FS ikke har kommet med en offisiell annonsering. Ryktene vil ha det til at FS er et godt stykke fra å ha noe klart, kanskje flere år. Så lenge ingen vet hva det er, er det ikke sikkert det vil tilfredsstille så mange bruker behov, kanskje snarere behov som NewFS har for å få en bedre kvalitet på arbeid som utføres når mange brukere roter i det samme bedet. Det er forholdsvis enkelt å løse behovet for overføring av multimedia, så det antar jeg kommer. Kanskje også en løsning med records for steder, som Gentech har en tvilsom løsning på. Hvis de har basert seg på Gentech modellen kan det f.eks bli problemer med informasjon om kilder. Det eneste programmet som har implementert kilder ihht Gentech er på vei bort fra modellens måte å gjøre dette på (jeg nevner ikke programnavn). Men nå er jo allerede eksport av kildeinformasjon fra mange program i Gedcom format et sabla rot allerede, så det kan vel ikke bli så mye verre en det er.

Et annet aspekt ved en Familysearch-løsning er at høytsittende folk i FS har proklamert at framtida ikke ligger i filformater, den ligger i APIer (dvs. bla. deres eget API) for å laste opp/ned til/fra databaser på internett. Det vil i mine ører si at FS er mest interessert i å maksimere sin egen database, brukernes behov for utveksling mellom egne og/eller andres program kommer i annen rekke. Det samme gjelder brukernes behov for langsiktig lagring av egne data, inkl. private data. FS er ikke de eneste som har dette synet. Hva slags føringer gir dette for en løsning? Tenk selv. En oppgradert Gedcom vil kunne gjøre det enklere for brukere å gjøre ting uten å måtte gi fra seg dataene til en nettdatabase. Det er interessant at leverandøren av et av bruker-programmene som promoteres av en av debattantene i dette tema har erklært at han ikke ønsker å supporte FS-APIet, men det blir han kanskje tvunget til.

Dette ble ikke så mye pent sagt om Familysearch, og det må legges til at de også gjør mye bra. Men, hvis man tar mål av seg til å ha en stor innflytelse på slektsforskningsprosessene, så må man finne seg i synspunkter på det man gjør, eller ikke gjør.

Vel, vi får se hvordan det går. Jeg kommer nok til å bruke noe mer tid på det jeg har holdt på med den siste måneden, å rydde opp i BetterGEDCOM wikien, slik at det blir letter å finne fram til de ulike tema som har vært diskutert.
---------

Når det gjelder etternavn så er det vel ikke så mange måter å sortere på flere etternavn. Dvs at programmet viser to forekomster av navnet i en sortert liste, en for Olsen og en for Melby, eller en for Berg og en for Hansen i Berg-Hansen. Poenget er at dette må være mulig uten å legge inn alternative navn. Neste steg er å få på plass mekanismer i Gedcom for å håndtere det.
---------

Vedr. etternavnprefix (SPFX) og TMG kan jeg tilføye følgende. Et aspekt er at man opererer med patronym (som kalles Farsnavn). De som har registrert kirkebokdata i BD87 programmet, iflg 4G standarden som har patronym og slektsnavn, vet at det ofte ikke er mulig å avgjøre om Olsen er et patronym eller slektsnavn. Digitalarkivet har for lenge siden gått bort fra å operere med patronym – hvis de noen gang har gjort det. Hvis TMG eksporterer patronym som et SPFX, uten noe etternavn, er det vel ikke usannsynlig at det i et mottakende program ikke vil vises noe sorterbart etternavn. Lurer på om Torleif har testet ut hva som vil skje i andre program?

Geir

[Otto Jørgensen]

Når det gjelder etternavn så er det vel ikke så mange måter å sortere på flere etternavn. Dvs at programmet viser to forekomster av navnet i en sortert liste, en for Olsen og en for Melby, eller en for Berg og en for Hansen i Berg-Hansen. Poenget er at dette må være mulig uten å legge inn alternative navn. Neste steg er å få på plass mekanismer i Gedcom for å håndtere det.

En person kan i gjennom sitt liv være registrert med flere etternavn basert på ulike kilder. Det som her er viktig er først og fremst å definere hva som er etternavn, bostedsnavn, slektsnavn, familienavn etc.

På dette område synes å herske stor forvirring.

I en virkelig oppfølging av en person er alle navnevarianter like viktige, basert på de kilder som gis.

[6878]

Jeg tror man må prøve å løfte hodet litt for å få overblikk. Hva er vitsen med all denne klassifiseringen? Hva brukes det til?

[dn10375]

....Når det gjelder etternavn så er det vel ikke så mange måter å sortere på flere etternavn. Dvs at programmet viser to forekomster av navnet i en sortert liste, en for Olsen og en for Melby, eller en for Berg og en for Hansen i Berg-Hansen. Poenget er at dette må være mulig uten å legge inn alternative navn. Neste steg er å få på plass mekanismer i Gedcom for å håndtere det.
......
Geir

Sortering av navn:
Hvis "Berg-Hansen" står i den aktuelle kilde vil det være naturlig å registrere kun dette, og ikke to alternative navn.
Bedre enn kun sortering av navnelistene er det ofte å bruke filtrering i tillegg:
- vis bare navn som inneholder "Berg" eller "Hansen".

TMGs SPFX (SurnamePrefix):
Du har rett i at bruken av dette feltet til Farsnavn/Mellomnavn ikke er bra/lurt, så det blir nok omdøpt til "EtternavnPrefiks" i TMGv8. TMGv7 bruker betegnelsen "SurnamePrefix".

BetterGEDCOM:
Ned som en skinnfell...

Torleif H

[6878]

Sortering av navn.

Det blir jo litt tungvint hvis man skal måtte filtrere. Det beste hadde vært om programmene tok behovet seriøst, det er jo en relativt enkel afære å implementere, og behovet er tilstede i det meste av Europa.

Det finnes et gratis program "Gramps" som som kommer med en løsning på dette, og det skyldes nok at miljøet bak har en ganske internsjonal bakgrunn. Men programmet er vel for de spesielt interesserte.

Jeg har bare nevnt brukergrensesnittet så langt, men ville jo også vært nyttig å kunne sortere på flere etternavn i registre i rapporter.

Et steg framover hadde vært å bli enige her hjemme om hva man ønsker i framtida, ikke bare med hensyn til dette. Men, man kommer neppe videre uten at man klarer å løsrive seg fra hvordan ting er implementert i sine programmer.

[6878]

Helt på slutten av følgende side kan man se at noe i ferd med å skje mht revison/erstattning av Gedcom.

http://rootstech.familysearch.org/schedule

Særdeles lite er meg bekjent offentlig kjent om dette, men man må regne med at programleverandører og andre viktige aktører kan bli konsultert før en mulig lansering av initiativet i begynnelsen av februar.

Jeg vil ikke bli overrasket hvis FS ønsker å etablere en eller annen organisasjon som skal står "ansvarlig" for standarden. Jeg tolker et annet initiativ for folk i FS dithen at man nå prøver å få synspunkter på hvordan en slik organisasjon skal arbeide.

Man skal ikke ta for gitt at standarden vil beskrive et filformat. Jeg gjetter på at FS vil fremme et forslag til standard (de har jobbet med et utakst en stund), og hvorvidt en organisasjon skal bedrive sandpåstrøing eller faktisk utvikling av en standard gjenstår å se.

Hvis organisasjonen skal bedrive utvikling vil det bli behov for å få fram forslag til endringer basert på evt. (sær)norske/nordiske behov.