Arkistonäkymässä ei tällä hetkellä lainaus erotu varsinaisesta viestistä. Suosittelemme että vilkaisette ns. täydellistä versiota: : Gedcom versio 7 julkaistu
Family Search on 7. kesäkuuta päivittänyt gedcom-määrityksensä 5.5.1 uuteen versioon 7.x . Seiskan dokumentaatio löytyy
https://gedcom.io/specifications/FamilySearchGEDCOMv7.pdf
Tietääkseni mikään varsinainen sukututkimusohjelma ei ole vielä ilmoittanut tukevansa myös uutta seiskaversiota. On hyvä tietää, että ohjelmat eivät sitä ennen kykene kirjoittamaan tai lukemaan seiskalla tuotettua tiedostoa.
Dietrich Hesmerin "Gedcom Service Programs" -työkalupaketti julkaisi jo version 8, josta löytyy tuki gedcomin uudelle versiolla. Suosittelen pakettia muutenkin, siitä löytyy erillistukea Suomessakin käytetyille ohjelmille kuten Ahnenblatt, Ahnenforscher. Brothers Keeper, FTM. Legacy, MyHeritage. Reunion ja TNG. Lisää tietoa
http://ofb.hesmer.name/gedserpro_e.html
Isotammi-palvelun "gedcom-työkalut" osaa joukon gedcom-vakiointeja mm. Sukujutuille ja Suku 2004:lle on omat muunnospakettinsa. Tästä tarkemmin
http://wiki.isotammi.net/wiki/Wikitammi:Sukutietojen_vakiointi_Gedcom-ohjelmilla
Isotammi-tiimin puolesta
Pekka Valta
Edellinen yleisesti tunnettu Gedcom-versio on 5.5. Onko ollut versiota 6.x ollenkaan?
Eipä ole. Family Search (aikaisempi Family History Department of The Church of Jesus Christ of Latter-day Saints) on suhtautunut omistamaansa gedcom-määritykseen epämääräisesti. Löi ensin laimin version 5.5.1 virallistamisen. Teki sitten gedcomin korvaajaksi aiotun "Gedcom 6.0 XML"-määrityksen ja ehti jopa jakaa sen kehittäjille v. 2002, kunnes pisti tämän hankkeensa jäihin.
"epämääräisesti" on varmaan epäoikeudenmukaisesti sanottu. LSD-kirkon uskonnollisiin tarpeisiin gedcom 5.5 lienee ihan riittävä. Sekulaareille sukututkijoille gedcomin jäntevämpi kehittäminen olisi tietenkin ollut toivottavaa.
Kommentti version 7.0.5 spekseistä Suomen oloissa:
Suomen oloissa muuttoihin käytetään edelleen näköjään yksittäisiä tapahtumia (individual events):
EMIG Leaving one’s homeland with the intent of residing
elsewhere.
IMMI Entering into a new locality with the intent of
residing there.
Jälkimmäistä voisi jollain tavalla käyttää Suomen olosuhteissa tuloon jonnekin paikkakunnalle, kylään tai taloon. Edelleen pohdintana: tuossa on ainoastaan paikkakunta. Ei kylää erikseen tai taloa. Siitä johtuen se antaa ei-yksikäsitteisen mahdollisuuden merkitä paikkaa. Ja siis talot ja kylät voivat sekoittua.
Family Search (aikaisempi Family History Department of The Church of Jesus Christ of Latter-day Saints) on suhtautunut omistamaansa gedcom-määritykseen epämääräisesti. Löi ensin laimin version 5.5.1 virallistamisen. Teki sitten gedcomin korvaajaksi aiotun "Gedcom 6.0 XML"-määrityksen ja ehti jopa jakaa sen kehittäjille v. 2002, kunnes pisti tämän hankkeensa jäihin.
Nyt siellä on mainittu jo Semantic Versioning (https://semver.org/).
Jälkimmäistä voisi jollain tavalla käyttää Suomen olosuhteissa tuloon jonnekin paikkakunnalle, kylään tai taloon. Edelleen pohdintana: tuossa on ainoastaan paikkakunta. Ei kylää erikseen tai taloa. Siitä johtuen se antaa ei-yksikäsitteisen mahdollisuuden merkitä paikkaa. Ja siis talot ja kylät voivat sekoittua.
Oletko miettinyt, miten sivulla 72 esiteltyä rakennetta FORM (Format) <g7:PLAC-FORM> voisi hyödyntää paikan tarkentamisessa?
Oletko miettinyt, miten sivulla 72 esiteltyä rakennetta FORM (Format) <g7:PLAC-FORM> voisi hyödyntää paikan tarkentamisessa?
En ole (vielä) miettinyt. Jos sen saa toimivaksi, niin se ratkaisee tämän tiedossa olleen ongelman.
Sillä voisi olla vaikutusta esim. Geniin. Siellähän on "yhteinen sukupuu" ja se on näyttänyt voimansa yhteistyön ja sen lisäarvon merkeissä. Genissä ei ole määritelty erityisemmin paikkoja kylien ja talojen tarkkuudella. Niissä on sitten sekaannuksia aiheuttavia moniselitteisyyksiä. Talon nimi onkin kylän nimen paikalla ja päinvastoin.
Pitääpä ottaa selvää tuosta FORM:ista. Kiitos.
Toinen asia on DNA-haploryhmät. Uusi standardi antanee mahdollisuuden lisätä Gedcom-dataan henkilön mt-dna haploryhmän ja miehille sen lisäksi y-dna haploryhmän.
Sukututkimusohjelmassa voi olla sitten propagoitumisrutiini, joka on Genistä tuttu.
Oletko miettinyt, miten sivulla 72 esiteltyä rakennetta FORM (Format) <g7:PLAC-FORM> voisi hyödyntää paikan tarkentamisessa?
Tuossa on vielä sellainen juttu, että vaikka sen voisi määritellä FORM:illa, niin gedcom-muotoisen tiedon lukijankin pitää ymmärtää ja osata tulkita tieto oikein.
Esimerkiksi Geni, My Heritage, FTDNA, jne. Niiden tulisi osata sitten ne FORM:it asettaa omiin tietorakenteisiinsa oikein.
Epäilys tulee, että eivät tule osaamaan. Standardien kehittelyssä tulisi olla yksiselitteinen.
Mutta onhan sekin jo jotain, jos joku sukututkimusohjelma osaa tuon 7.x version pääasiat oikein.
HEADERin PLAC FORMAT kuten EMIG ja IMMI ovat entisellään. FORMATia ei ole tähän mennessä implementoitu sukututkimusohjelmiin enkä usko näin tapahtuvan jatkossakaan. Samassa gedcom-tiedostossa voi olla eri maiden paikkoja ja jokaisella maalla on useita paikkarakenteita, seuraten historiallisia vaiheita.
Gedcomin suuria puutteita on edelleen maan sisäisten muuttojen tägien puute. Isotammen laatuohjeissa tämä on paikattu LÄHTÖMUUTTO ja TULOMUUTTO tapahtumilla. Paikkatieto on niissä sillä tarkkuudella, kun varmasti tiedetään. Siis vaikka tilan tarkkuudella, jos muuttaja tuli muualta tietylle tilalle.
On hyvä' huomata, että epävamaksi jäävä paikka muutossa (esim. "lähti Espoon Stensvikistä Viipuriin") ei mitenkään todenna hänen koskaan päätyneen Viipuriin. Vain lähtöpaikka "Stensvik,Espoo" on varma ja "Viipuri" jätetään kuvaukseen.
Olen sitä mieltä, että standardeihin ei saisi jättää tulkinnanvaraisuuksia. Ainakaan miettimättä sitä kahteen kertaan. Toinen silmiin pistävä asia on version 7 keskittyminen lähinnä Mormonikirkon tarpeisiin ihmisten tiedoista.
Nyt pitäisi kysyä, että onko tarvetta toiselle maailmanlaajuiselle standardille tuon de facto -standardin rinnalle tai peräti syrjäyttäjäksi. Voi olla, ettei Gedcom-standardin luojilla ole edes tarvetta kehittää sitä universaaliksi.
Uuden standardin leviäminen yleiseen käyttöön on sitten oma kysymyksensä. Vaatii paljon lobbausta.
Tulee mieleen siirtyminen sähköautoihin. Jo 1830-luvulla ilmestyivät ensimmäiset mallit ja 2020-luvulla Suomikin siirtyy niihin. Ilmeisesti matkan varrella oli joitain haasteita tekniikan, standardien yms. alueilla.
FamilySearchin passiivisuuteen kyllästyivät ensimmäisenä saksalaiset, jotka kehittivät siihen parannuksia ns. Gedcom-L hankkeessaan. Lopputulosta voi katsella http://wiki-en.genealogy.net/Gedcom_5.5EL. Saksalaisten omat sukututkimusohjelmat ovat implementoineet siitä jotain.
Anglosaksit käynnistivät 2010 ns. BetterGedcom-hankkeen, joka tuotettuaan 3400 wikisivua (ks. sen arkisto https://archive.fhiso.org/BetterGEDCOM/) organisoitiin pari vuotta myöhemmin FHISO:ksi (ks. https://fhiso.org/). Sen takana on alan tunnettuja henkilöitä ja yrityksiä. Valitettavasti koronapandemia lamautti tätäkin työtä. Toivottavasti näemme jotain valmista lähivuosina.
Ehdotan Ilkka harkittavaksi, että välität näkemyksesi FHISO:lle. Täällä Härmässä kehitykseen ei juurikaan voida vaikuttaa.
yst terv Pekka Valta
Kitios tiedoista. Minulle tulee tässä mieleen noin 2007 aikoihin avoimet standardit kuten ODF. Sen oli tarkoitus olla yksi kaikkialla toimiva standardi ilman yhteensopivuusongelmia. Heti Microsoft julkaisi oman avoimen standardinsa. Kokeiluissa yksi tekstinkäsittely-asiakirja tuotti yli 100 000 virheilmoitusta! Minun analyysini on, että Microsoft halusi varmistaa, että vain heidän tuotteillaan voi sitä avointa standardia käyttää.
Oli kolmaskin taho W3, joka loi oman avoimen standardin.
Onkohan tässä Gedcomissa sama juttu, että kaikki haluavat luoda itselleen sopivan muodon hyvästä yhteisestä ideasta. :)
Pohdiskelen tuota vaikuttamiskeinoa, sillä pidän sinänsä tärkeänä, että tulisi yksi standardi, joka toimii kaikkialla maailmassa ja jossa olisi mahdollisimman vähän tulkinnanvaraisuuksia ja jota tultaisiin käyttämään ainakin yleisimmissä sukututkimuspalveluissa.
< Olen sitä mieltä, että standardeihin ei saisi jättää tulkinnanvaraisuuksia. Ainakaan miettimättä sitä kahteen kertaan. Toinen silmiin pistävä asia on version 7 keskittyminen lähinnä Mormonikirkon tarpeisiin ihmisten tiedoista.
Nyt pitäisi kysyä, että onko tarvetta toiselle maailmanlaajuiselle standardille tuon de facto -standardin rinnalle tai peräti syrjäyttäjäksi. Voi olla, ettei Gedcom-standardin luojilla ole edes tarvetta kehittää sitä universaaliksi.
Uuden standardin leviäminen yleiseen käyttöön on sitten oma kysymyksensä. Vaatii paljon lobbausta. >
Tai sitten siirtymistä oikeiden välineiden käyttöön tai pikemminkin oikeiden välineiden valitsemista, jolloin standardia ei tarvittane.
Sinänsä jokaisella käyttäjällä on oma käyttäjänäkemyksensä yleisiin sukutietoihin, joten standardi on silloin kapeikko tietojen siirrossa, koska se on vain osajoukko tiedoista.
Lukemisiin
Nyt pitäisi kysyä, että onko tarvetta toiselle maailmanlaajuiselle standardille tuon de facto -standardin rinnalle tai peräti syrjäyttäjäksi. Voi olla, ettei Gedcom-standardin luojilla ole edes tarvetta kehittää sitä universaaliksi.
Jos se yksi selviää näistä suomalaisista muuttomerkinnöistä siten, että suuret tietoja tallentavat tahot (Geni, My Heritage, FTDNA, yms.) osaavat käsitellä datan oikein, niin toista standardia ei tarvita. Epäilen, että nuo eivät osaa käsitellä tietoa oikealla tavalla tai ollenkaan, jos se on ikäänkuin lisätieto.
Ja nykyaikana dna-haploryhmät ovat melko oleellisia tietoja henkilöistä sukututkimusmielessä.
Tässä kaksi esimerkkiä sille, että tarvitaan parempi standardi. Voisin uskoa, että dna-haploryhmätieto voisi tulla uudempaan Gedcomin versioon, jos sitä lobataan.
Nykyinen gedcom venyy kyllä sekä muuttojen että haplotietojen välitttämiseen. Tarvitaan vain kaksi asiaa: sukututkimusohjelma sallii ao. tietojen tallentamisen niin, että ne välittyvät gedcom-tiedostoon. Toisaalta yhtä tärkeää on, että ohjelmat on ohjelmoitu lukemaan ne siten, että ohjelmaan koodatut lisätoiminnallisuudet osaavat raportoida, suodattaa yms. henkilöitä ja tietoja tavoitteen mukaisesti.
Kokeilin. Tein Grampsissa yhden henkilön kannan. Laitoin hänelle henkilötasolla haploryhmän (alla olevassa printissä 1 FACT N1234
2 TYPE Haploryhmä). Toisaalta kokeilin häneen liitetyllä tapahtumalla (Tyyppi=DNA-testi) haplotiedon tallentamista tapahtuman kuvaukseen (Haplo Z556688) ja tapahtuman lisätietona (Haplo RR223344).
Ehkä pieni kokeiluni varmentaa sen, että ainakin Grampsin tapauksessa on tällaisiakin vaihtoehtoja tallentaa ja välittää tietoja haploryhmästä. En tunne tarkemmin dna-tietojen käyttötarpeita sukututkimusohjelmassa, joten jätän jatkomiettimisen tietävimmille.
ps. printissä näkyy myös, miten gedcomiin välittyy Grampsissa tyypin Lähtömuutto -tapahtuma Pariisista Helsinkiin Isotammen laatuohjeiden mukaisesti.
0 HEAD
1 SOUR Grampsk2 VERS AIO64-5.1.4-1
2 NAME Gramps
1 DATE 11 NOV 2021
2 TIME 15:19:56
1 SUBM *SUBM*
1 FILE C:\Users\Pekan Book\Downloads\DNA-testi 2.ged
1 COPR Copyright (c) 2021 Pekka.
1 GEDC
2 VERS 5.5.1
2 FORM LINEAGE-LINKED
1 CHAR UTF-8
1 LANG Finnish
0 *SUBM* SUBM
1 NAME Pekka
0 *I0000* INDI
1 NAME Testi /testisukunimi/
2 GIVN Testi
2 SURN testisukunimi
1 SEX M
1 EVEN Helsinkiin
2 TYPE Lähtömuutto
2 DATE 1 JAN 2003
2 PLAC Pariisi
1 EVEN Haplo Z556688
2 TYPE DNA-testi
2 NOTE *N0000*
1 FACT N1234
2 TYPE Haploryhmä
1 CHAN
2 DATE 11 NOV 2021
3 TIME 13:09:05
0 *N0000* NOTE Haplo RR223344
0 TRLR
Kokeilin. Tein Grampsissa yhden henkilön kannan. Laitoin hänelle henkilötasolla haploryhmän (alla olevassa printissä 1 FACT N1234
2 TYPE Haploryhmä). Toisaalta kokeilin häneen liitetyllä tapahtumalla (Tyyppi=DNA-testi) haplotiedon tallentamista tapahtuman kuvaukseen (Haplo Z556688) ja tapahtuman lisätietona (Haplo RR223344).
Tämä on hyvä esimerkki. Nyt kun joku sukututkimusohjelma tekee tuon muotoisen tiedon gedcomissa ja se viedään vaikkapa Geniin, niin Geni ei välttämättä osaa ymmärtää, että kysymys on haploryhmästä.
Niiden tyyppien pitäisi olla ennalta määriteltyjä sanoja, jotta vastaanottava puoli tunnistaisi ne. Tätä olen ajanut takaa tässä keskustelussa.
Kun standardi on yksiselitteinen, niin tiedonsiirrossa ei tule tiedon hukkumisia eikä mene vääriin kenttiin.
vBulletin® v3.8.11, Copyright ©2000-2024, vBulletin Solutions Inc.