On 27 Feb at 11:50, Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote: > I've seen a lot of references to really old versions of GEDCOM. GEDCOM > 5.5.1 seems to satisfy my immediate needs[1], but has been in draft > status for a very long time. GEDCOM 6 is still a work in progress and > I'm not sure where GEDCOM-X is. What is the prognosis for the major > players to support at least GEDCOM 5.5.1 in UTF-8? > > [1] E.g., storing both a secular and a religous name, storing a > romanized transliteration of a name in a non-roman script, > storing a date in two different calendars. My opinion is a zilch prognosis. The problem with GEDCOM is that it makes it relatively easy to transfer a lot of the data between genealogy programs. But for the programmer this is not Good News; how much better to lock the user into their program by making GEDCOM transfers more difficult? Yo might get more mileage by asking your current program owners when _They_ are going to provide the above features. -- Tim Powys-Lybbe tim@powys.org for a miscellany of bygones: http://powys.org/

On Wed, 27 Feb 2013 13:39:23 +0000, Tim Powys-Lybbe <tim@powys.org> wrote: >On 27 Feb at 11:50, Shmuel (Seymour J.) Metz ><spamtrap@library.lspace.org.invalid> wrote: > >> I've seen a lot of references to really old versions of GEDCOM. GEDCOM >> 5.5.1 seems to satisfy my immediate needs[1], but has been in draft >> status for a very long time. GEDCOM 6 is still a work in progress and >> I'm not sure where GEDCOM-X is. What is the prognosis for the major >> players to support at least GEDCOM 5.5.1 in UTF-8? >> >> [1] E.g., storing both a secular and a religous name, storing a >> romanized transliteration of a name in a non-roman script, >> storing a date in two different calendars. > >My opinion is a zilch prognosis. The problem with GEDCOM is that it >makes it relatively easy to transfer a lot of the data between genealogy >programs. But for the programmer this is not Good News; how much better >to lock the user into their program by making GEDCOM transfers more >difficult? > >Yo might get more mileage by asking your current program owners when >_They_ are going to provide the above features. > >-- >Tim Powys-Lybbe tim@powys.org > for a miscellany of bygones: http://powys.org/ Seems to me the problem has recently been discussed here. Users demand unique abilities in programs and developers try to satisfy. Even for an accomplished programmer methinks it would be very difficult to accomodate every variation even with options. Seems like a standardized version of GEDCOM with a program to adapt it to specific needs would be more of an answer. But I'm a user, not an enabler. Hugh

In <512e34c5.4820774@news.eternal-september.org>, on 02/27/2013 at 04:37 PM, Eagle@bellsouth.net (J. Hugh Sullivan) said: >Seems to me the problem has recently been discussed here. Users >demand unique abilities in programs and developers try to satisfy. >Even for an accomplished programmer methinks it would be very >difficult to accomodate every variation even with options. The draft GEDCOM 5.5.1 already supports the features I mentioned, but a lot of software doesn't support it yet. -- Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel> Unsolicited bulk E-mail subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. Reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org

On Wed, 27 Feb 2013 13:39:23 +0000, Tim Powys-Lybbe <tim@powys.org> wrote: >On 27 Feb at 11:50, Shmuel (Seymour J.) Metz ><spamtrap@library.lspace.org.invalid> wrote: > >> I've seen a lot of references to really old versions of GEDCOM. GEDCOM >> 5.5.1 seems to satisfy my immediate needs[1], but has been in draft >> status for a very long time. GEDCOM 6 is still a work in progress and >> I'm not sure where GEDCOM-X is. What is the prognosis for the major >> players to support at least GEDCOM 5.5.1 in UTF-8? >> >> [1] E.g., storing both a secular and a religous name, storing a >> romanized transliteration of a name in a non-roman script, >> storing a date in two different calendars. > >My opinion is a zilch prognosis. The problem with GEDCOM is that it >makes it relatively easy to transfer a lot of the data between genealogy >programs. But for the programmer this is not Good News; how much better >to lock the user into their program by making GEDCOM transfers more >difficult? Which is not good news for users, because when the programmer dies, their data is as good as dead. And as soon as the news got around, nobody would touch their program with a bargepole. -- Steve Hayes from Tshwane, South Africa Blog: http://khanya.wordpress.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

In <mpro.mivsln1d7akow0095.tim@powys.org>, on 02/27/2013 at 01:39 PM, Tim Powys-Lybbe <tim@powys.org> said: >My opinion is a zilch prognosis. The problem with GEDCOM is that it >makes it relatively easy to transfer a lot of the data between >genealogy programs. But for the programmer this is not Good News; >how much better to lock the user into their program by making >GEDCOM transfers more difficult? In my experience, deliberate lock-in is something that programmers do only when ordered to by management. >Yo might get more mileage by asking your current program owners >when _They_ are going to provide the above features. My current program has a scripting facility; it is easy to generate whatever format I want. The problem is that I want to be able to share my data, and until at least GEDCOM 5.5.1 is ubiquitous, there's no universal format that will handle my data. -- Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel> Unsolicited bulk E-mail subject to legal action. I reserve the right to publicly post or ridicule any abusive E-mail. Reply to domain Patriot dot net user shmuel+news to contact me. Do not reply to spamtrap@library.lspace.org

"Tim Powys-Lybbe" <tim@powys.org> wrote in message news:mpro.mivsln1d7akow0095.tim@powys.org... > On 27 Feb at 11:50, Shmuel (Seymour J.) Metz > <spamtrap@library.lspace.org.invalid> wrote: > >> I've seen a lot of references to really old versions of GEDCOM. GEDCOM >> 5.5.1 seems to satisfy my immediate needs[1], but has been in draft >> status for a very long time. GEDCOM 6 is still a work in progress and >> I'm not sure where GEDCOM-X is. What is the prognosis for the major >> players to support at least GEDCOM 5.5.1 in UTF-8? >> >> [1] E.g., storing both a secular and a religous name, storing a >> romanized transliteration of a name in a non-roman script, >> storing a date in two different calendars. > > My opinion is a zilch prognosis. The problem with GEDCOM is that it > makes it relatively easy to transfer a lot of the data between genealogy > programs. But for the programmer this is not Good News; how much better > to lock the user into their program by making GEDCOM transfers more > difficult? > > Yo might get more mileage by asking your current program owners when > _They_ are going to provide the above features. > > -- > Tim Powys-Lybbe tim@powys.org > for a miscellany of bygones: http://powys.org/ Programmers would not benefit by locking people into a genealogical product Tim. I'm sure you appreciate that genealogy relies on data sharing. Even if someone doesn't want to benefit from someone else's research, they will certainly want to pass on their own research to friends and family. If sharing is a fundamental tenet of genealogy then some mechanism to exchange data accurately and in a vendor-neutral fashion is essential. GEDCOM became a de facto standard but it was never envisioned as that originally. It now shows the fallacy of having a proprietary model which was loosely-defined and has now been abandoned by its creator. Ideally, we should have a community-defined model with a freely-available, high-quality standard. This is what FHISO (http://fhiso.org) are all about. I have raised this topic before in this group. Irrespective of the negativity and cup-half-full mentality of some other folks in this group, such a standard will evolve. If you want a say in its requirements, you really need to become a member. Tony Proctor FHISO Organising Member

On Thu, 28 Feb 2013 09:07:18 -0000, "Tony Proctor" <tony@proctor_NoMore_SPAM.net> wrote: > >"Tim Powys-Lybbe" <tim@powys.org> wrote in message >news:mpro.mivsln1d7akow0095.tim@powys.org... >> On 27 Feb at 11:50, Shmuel (Seymour J.) Metz >> <spamtrap@library.lspace.org.invalid> wrote: >> >>> I've seen a lot of references to really old versions of GEDCOM. GEDCOM >>> 5.5.1 seems to satisfy my immediate needs[1], but has been in draft >>> status for a very long time. GEDCOM 6 is still a work in progress and >>> I'm not sure where GEDCOM-X is. What is the prognosis for the major >>> players to support at least GEDCOM 5.5.1 in UTF-8? >>> >>> [1] E.g., storing both a secular and a religous name, storing a >>> romanized transliteration of a name in a non-roman script, >>> storing a date in two different calendars. >> >> My opinion is a zilch prognosis. The problem with GEDCOM is that it >> makes it relatively easy to transfer a lot of the data between genealogy >> programs. But for the programmer this is not Good News; how much better >> to lock the user into their program by making GEDCOM transfers more >> difficult? >> >> Yo might get more mileage by asking your current program owners when >> _They_ are going to provide the above features. >> >> -- >> Tim Powys-Lybbe tim@powys.org >> for a miscellany of bygones: http://powys.org/ > >Programmers would not benefit by locking people into a genealogical product >Tim. I'm sure you appreciate that genealogy relies on data sharing. Even if >someone doesn't want to benefit from someone else's research, they will >certainly want to pass on their own research to friends and family. > >If sharing is a fundamental tenet of genealogy then some mechanism to >exchange data accurately and in a vendor-neutral fashion is essential. > >GEDCOM became a de facto standard but it was never envisioned as that >originally. It now shows the fallacy of having a proprietary model which was >loosely-defined and has now been abandoned by its creator. Ideally, we >should have a community-defined model with a freely-available, high-quality >standard. > >This is what FHISO (http://fhiso.org) are all about. I have raised this >topic before in this group. Irrespective of the negativity and cup-half-full >mentality of some other folks in this group, such a standard will evolve. If >you want a say in its requirements, you really need to become a member. > > Tony Proctor > FHISO Organising Member > Tony, I think your plan is nobel, but I really don't see a lot of support for it. Based on my experience over the last 10 years as president of our Family Association, 95% of the people interested in their family history have absolutely no interest in having or running a genealogy program. What they want is the information, in as easily accessable format as possible. Printed seems the favorite form, but internet access has certainly gained in popularity in recent years. Our Family Association has sold about 300 family CDs at our reunions over the last several years. The CDs contain a lot of information about the family, including several PDF "books" that used to be sold in printed form. They do NOT contain a GEDCOM of the data, and we've never received even one request for a GEDCOM to be included. There ARE many genealogists, and sharing of information is important, but many serious genealogists would never consider importing a GEDCOM into their database, not from concern about the GEDCOM transferring information properly, but because they want to first verify the data. My personal belief is that most of the requests for a better means of transferring data between programs comes from genealogists who want to use two or more programs for their own data, not for transferring or receiving information to or from other people.

"Charlie Hoffpauir" <invalid@invalid.com> wrote in message news:cnmui8lllu5qc8do2d3c77u17d1ahnmpm3@4ax.com... > On Thu, 28 Feb 2013 09:07:18 -0000, "Tony Proctor" > <tony@proctor_NoMore_SPAM.net> wrote: > >> >>"Tim Powys-Lybbe" <tim@powys.org> wrote in message >>news:mpro.mivsln1d7akow0095.tim@powys.org... >>> On 27 Feb at 11:50, Shmuel (Seymour J.) Metz >>> <spamtrap@library.lspace.org.invalid> wrote: >>> >>>> I've seen a lot of references to really old versions of GEDCOM. GEDCOM >>>> 5.5.1 seems to satisfy my immediate needs[1], but has been in draft >>>> status for a very long time. GEDCOM 6 is still a work in progress and >>>> I'm not sure where GEDCOM-X is. What is the prognosis for the major >>>> players to support at least GEDCOM 5.5.1 in UTF-8? >>>> >>>> [1] E.g., storing both a secular and a religous name, storing a >>>> romanized transliteration of a name in a non-roman script, >>>> storing a date in two different calendars. >>> >>> My opinion is a zilch prognosis. The problem with GEDCOM is that it >>> makes it relatively easy to transfer a lot of the data between genealogy >>> programs. But for the programmer this is not Good News; how much better >>> to lock the user into their program by making GEDCOM transfers more >>> difficult? >>> >>> Yo might get more mileage by asking your current program owners when >>> _They_ are going to provide the above features. >>> >>> -- >>> Tim Powys-Lybbe tim@powys.org >>> for a miscellany of bygones: http://powys.org/ >> >>Programmers would not benefit by locking people into a genealogical >>product >>Tim. I'm sure you appreciate that genealogy relies on data sharing. Even >>if >>someone doesn't want to benefit from someone else's research, they will >>certainly want to pass on their own research to friends and family. >> >>If sharing is a fundamental tenet of genealogy then some mechanism to >>exchange data accurately and in a vendor-neutral fashion is essential. >> >>GEDCOM became a de facto standard but it was never envisioned as that >>originally. It now shows the fallacy of having a proprietary model which >>was >>loosely-defined and has now been abandoned by its creator. Ideally, we >>should have a community-defined model with a freely-available, >>high-quality >>standard. >> >>This is what FHISO (http://fhiso.org) are all about. I have raised this >>topic before in this group. Irrespective of the negativity and >>cup-half-full >>mentality of some other folks in this group, such a standard will evolve. >>If >>you want a say in its requirements, you really need to become a member. >> >> Tony Proctor >> FHISO Organising Member >> > Tony, > > I think your plan is nobel, but I really don't see a lot of support > for it. Based on my experience over the last 10 years as president of > our Family Association, 95% of the people interested in their family > history have absolutely no interest in having or running a genealogy > program. What they want is the information, in as easily accessable > format as possible. Printed seems the favorite form, but internet > access has certainly gained in popularity in recent years. Our Family > Association has sold about 300 family CDs at our reunions over the > last several years. The CDs contain a lot of information about the > family, including several PDF "books" that used to be sold in printed > form. They do NOT contain a GEDCOM of the data, and we've never > received even one request for a GEDCOM to be included. > > There ARE many genealogists, and sharing of information is important, > but many serious genealogists would never consider importing a GEDCOM > into their database, not from concern about the GEDCOM transferring > information properly, but because they want to first verify the data. > > My personal belief is that most of the requests for a better means of > transferring data between programs comes from genealogists who want to > use two or more programs for their own data, not for transferring or > receiving information to or from other people. > > Thanks Charlie but it's actually not just about sharing between individuals. The way that data is made available to users online could use the same model. Also, the same format becomes a safe representation for long-term storage - one that is neutral with respect to hardware, vendor, software package, and locale. I understand about written forms, and I generate them from my own data. However, I do not consider the written form to be my definitive copy since software can, and does, help you make conclusions, but it requires a computer-readable format to work with. Narrative needn't be excluded from this. In fact, FHISO is not even solely concerned with a format for exchange and long-term storage. They're also representing our collective interests in all data standards that affect genealogy, e.g. ontologies, sources/citations, Internet-based Authorities, semantic tagging, etc. They are already reaching out to other standards bodies and research groups in order to collaborate on issues that affect genealogy. I'm afraid the sleight in my previous post was aimed at those annoying folks who say: it's not possible (it is), it'll never work (it will), why should I pay for accessing some new standard (you don't, it would be freely available), why should I have to implement some new standards (it's not mandatory, and it's primarily for import/export), and who are these FHISO people dictating to me (FHISO are its members, and that membership should include everyone who gives a rat's ** about the future of genealogy. ...there, I've said it now! :-)) Tony Proctor