<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Build a BetterGEDCOM or learn GEDCOMBetter?</title>
	<atom:link href="http://www.beholdgenealogy.com/blog/?feed=rss2&#038;p=803" rel="self" type="application/rss+xml" />
	<link>http://www.beholdgenealogy.com/blog/?p=803</link>
	<description>the Development of my Genealogy Program named Behold</description>
	
		<image>
	<link>http://www.beholdgenealogy.com/blog</link>
	<url>http://www.beholdgenealogy.com/blog/../beholdblog.gif</url>
	</image>
	<copyright>Comments by Louis Kessler are Copyright 2000-2013 Louis Kessler, All Rights Reserved.  Comments by others belong to the people who made them.</copyright>
		<item>
		<title>By: Responses &#8211; Exploring Gedcom &#8212; #Technology, #Genealogy | Stanczyk &#8211; Internet Muse</title>
		<link>http://www.beholdgenealogy.com/blog/?p=803#comment-467</link>

				<dc:creator>Responses &#8211; Exploring Gedcom &#8212; #Technology, #Genealogy | Stanczyk &#8211; Internet Muse</dc:creator>

		<pubDate>Sun, 26 Feb 2012 21:41:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.beholdgenealogy.com/blog/?p=803#comment-467</guid>
		<description>[...] Jones (Modern Software Experience), Louis Kessler (BeholdGenealogy.com),  and  Stan Mitchell (GenApps.net / ezGED [...]</description>
		<content:encoded><![CDATA[<p>[...] Jones (Modern Software Experience), Louis Kessler (BeholdGenealogy.com),  and  Stan Mitchell (GenApps.net / ezGED [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Louis Kessler</title>
		<link>http://www.beholdgenealogy.com/blog/?p=803#comment-464</link>

				<dc:creator>Louis Kessler</dc:creator>

		<pubDate>Fri, 24 Feb 2012 14:42:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.beholdgenealogy.com/blog/?p=803#comment-464</guid>
		<description>Stanczyk:

There are as many "answers" as there are people. We each have our opnions. That's why a standard is so tough - because everyone has to compromise.

The difference with SQL is that enhancements can often be added to specific implementations without worry. Usually the SQL code does not get transported from one site to another. When it is known that SQL transfer is required, basic SQL is used.

But the purpose of GEDCOM is data transfer. Every enhancement one vendor adds means that those specific features must be handled by the other programs, or the data transfer is lost. That is why it is so much more important that genealogy programs adhere to the GEDCOM standard as much as possible. 

And personally, I am amazed that 99% of genealogy programs today (hundreds of them) at least make an attempt to read and write GEDCOM ... even now, 15 years later.  It will be very hard to get the community to change en-mass to a new standard. The future will be interesting.

Louis</description>
		<content:encoded><![CDATA[<p>Stanczyk:</p>
<p>There are as many &#8220;answers&#8221; as there are people. We each have our opnions. That&#8217;s why a standard is so tough - because everyone has to compromise.</p>
<p>The difference with SQL is that enhancements can often be added to specific implementations without worry. Usually the SQL code does not get transported from one site to another. When it is known that SQL transfer is required, basic SQL is used.</p>
<p>But the purpose of GEDCOM is data transfer. Every enhancement one vendor adds means that those specific features must be handled by the other programs, or the data transfer is lost. That is why it is so much more important that genealogy programs adhere to the GEDCOM standard as much as possible. </p>
<p>And personally, I am amazed that 99% of genealogy programs today (hundreds of them) at least make an attempt to read and write GEDCOM &#8230; even now, 15 years later.  It will be very hard to get the community to change en-mass to a new standard. The future will be interesting.</p>
<p>Louis</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: meliasz</title>
		<link>http://www.beholdgenealogy.com/blog/?p=803#comment-463</link>

				<dc:creator>meliasz</dc:creator>

		<pubDate>Fri, 24 Feb 2012 11:02:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.beholdgenealogy.com/blog/?p=803#comment-463</guid>
		<description>Thanks for leaving your comments on my blog post (http://wp.me/q0aQ)

. I now follow you (and I also follow Tamura Jones  -- I love his blog).

I will follow-up with your cogent comment and try to passionately persuade you on my points!   The answer is there between us. 

May I add that your view and mine coincide in that I want GEDCOM to continue and evolve (evolution, not revolution). It is only a defacto Standard now (after a decade and a half of inattentiveness) and of course it lacks openness as a true standard. May I offer SQL as a standard that is comparable -- i.e. a Standard and yet vendors provide their own enhancements and everyone is happy and it keeps improving.

--Stanczyk (Polish-American genealogist)</description>
		<content:encoded><![CDATA[<p>Thanks for leaving your comments on my blog post (http://wp.me/q0aQ)</p>
<p>. I now follow you (and I also follow Tamura Jones  &#8212; I love his blog).</p>
<p>I will follow-up with your cogent comment and try to passionately persuade you on my points!   The answer is there between us. </p>
<p>May I add that your view and mine coincide in that I want GEDCOM to continue and evolve (evolution, not revolution). It is only a defacto Standard now (after a decade and a half of inattentiveness) and of course it lacks openness as a true standard. May I offer SQL as a standard that is comparable &#8212; i.e. a Standard and yet vendors provide their own enhancements and everyone is happy and it keeps improving.</p>
<p>&#8211;Stanczyk (Polish-American genealogist)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Louis Kessler</title>
		<link>http://www.beholdgenealogy.com/blog/?p=803#comment-461</link>

				<dc:creator>Louis Kessler</dc:creator>

		<pubDate>Wed, 22 Feb 2012 15:32:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.beholdgenealogy.com/blog/?p=803#comment-461</guid>
		<description>Brett,

I think who wins as the future GEDCOM is very much up in the air. There have been dozens of proposals to date that never caught on. And there's several new initiatives now, and each may get to some point of usability, or may not.

People don't realize how much time and work it takes to develop a new standard. I respect the work effort and time that it took the LDS to develop GEDCOM. They had a full time staff working years on it. We're lucky we've at least got GEDCOM, or we'd have nothing.

I am encouraged by the GEDCOMX effort. It does appear that FamilySearch appear to be committed and are willing to devote staff and money and time to this effort. I feel there needs to be a leader and one with resources and clout. 

Meanwhile, I'm sure Ancestry is working on their own model. It is a competition and a race. Other online database firms are producing APIs of their own which are akin to data models which map to standards. AncestrySync has their own paradigm which they'd better finish first to usurp the others. Maybe the next best thing has not been invented yet.

Who ever would have expected that in the race between Beta and VHS, that DVD's would have won ... or maybe Blueray?

Louis</description>
		<content:encoded><![CDATA[<p>Brett,</p>
<p>I think who wins as the future GEDCOM is very much up in the air. There have been dozens of proposals to date that never caught on. And there&#8217;s several new initiatives now, and each may get to some point of usability, or may not.</p>
<p>People don&#8217;t realize how much time and work it takes to develop a new standard. I respect the work effort and time that it took the LDS to develop GEDCOM. They had a full time staff working years on it. We&#8217;re lucky we&#8217;ve at least got GEDCOM, or we&#8217;d have nothing.</p>
<p>I am encouraged by the GEDCOMX effort. It does appear that FamilySearch appear to be committed and are willing to devote staff and money and time to this effort. I feel there needs to be a leader and one with resources and clout. </p>
<p>Meanwhile, I&#8217;m sure Ancestry is working on their own model. It is a competition and a race. Other online database firms are producing APIs of their own which are akin to data models which map to standards. AncestrySync has their own paradigm which they&#8217;d better finish first to usurp the others. Maybe the next best thing has not been invented yet.</p>
<p>Who ever would have expected that in the race between Beta and VHS, that DVD&#8217;s would have won &#8230; or maybe Blueray?</p>
<p>Louis</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brett</title>
		<link>http://www.beholdgenealogy.com/blog/?p=803#comment-459</link>

				<dc:creator>Brett</dc:creator>

		<pubDate>Wed, 22 Feb 2012 08:08:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.beholdgenealogy.com/blog/?p=803#comment-459</guid>
		<description>Louis

I have recently sent the following to Tamura.

Do you have any thoughts.

****
Have we gone from 'No one cares any more' to 'too many peas in the pod'?

Will there be acceptable discussion and compromise between parties?

Will it end up with 2+ new GEDCOM versions, which software companies either ignore or choose one over another?

Is this potentially another Beta vs VHS scenario?

All I want is to be able to share all my recorded data with others, including those who may not use the same storage program, and obtain same from others.
****

Brett</description>
		<content:encoded><![CDATA[<p>Louis</p>
<p>I have recently sent the following to Tamura.</p>
<p>Do you have any thoughts.</p>
<p>****<br />
Have we gone from &#8216;No one cares any more&#8217; to &#8216;too many peas in the pod&#8217;?</p>
<p>Will there be acceptable discussion and compromise between parties?</p>
<p>Will it end up with 2+ new GEDCOM versions, which software companies either ignore or choose one over another?</p>
<p>Is this potentially another Beta vs VHS scenario?</p>
<p>All I want is to be able to share all my recorded data with others, including those who may not use the same storage program, and obtain same from others.<br />
****</p>
<p>Brett</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Louis Kessler</title>
		<link>http://www.beholdgenealogy.com/blog/?p=803#comment-457</link>

				<dc:creator>Louis Kessler</dc:creator>

		<pubDate>Sat, 18 Feb 2012 02:50:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.beholdgenealogy.com/blog/?p=803#comment-457</guid>
		<description>Thanks, Kulath,

With the new BetterGEDCOM and now GEDCOM X work being done, I'm trying to stress that they attempt simplicity rather than complicated models attempting to include everything. They attempt to include everything because they think that this will allow the data to be transferred, but by doing so will doom a new standard to failure because they introduce more ways that the developers implementing the new standard can make mistakes. As simple as GEDCOM is, a new version somehow needs to be even simpler. 

We'll see what comes to be. I'm looking forward to whatever might come, and I'll be ready to implement it ... barring it being too complex.</description>
		<content:encoded><![CDATA[<p>Thanks, Kulath,</p>
<p>With the new BetterGEDCOM and now GEDCOM X work being done, I&#8217;m trying to stress that they attempt simplicity rather than complicated models attempting to include everything. They attempt to include everything because they think that this will allow the data to be transferred, but by doing so will doom a new standard to failure because they introduce more ways that the developers implementing the new standard can make mistakes. As simple as GEDCOM is, a new version somehow needs to be even simpler. </p>
<p>We&#8217;ll see what comes to be. I&#8217;m looking forward to whatever might come, and I&#8217;ll be ready to implement it &#8230; barring it being too complex.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kulath</title>
		<link>http://www.beholdgenealogy.com/blog/?p=803#comment-455</link>

				<dc:creator>kulath</dc:creator>

		<pubDate>Sat, 18 Feb 2012 00:32:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.beholdgenealogy.com/blog/?p=803#comment-455</guid>
		<description>Don't feel like a lone wolf! I have been looking for some time for someone else with this view, sorry it's so long after your post!

I keep trying to find out "what is wrong with GEDCOM", and (apart from some really minor tweaks) all I can find is example of where poor implementation of the standard means that different programs do different things.

For example, you mention the BetterGEDCOM test with address information (actually phone number). Well, although they say "Looking at the GEDCOM 5.5 it appears that the format is correct", I don't think it is. Phone number simply isn't allowed where they found it, so their complaints have absolutely nothing to do with whether GEDCOM is any good.

I agree with you that there are very few standards that are as widely implemented as GEDCOM, and any new standard is just as likely to be abused.</description>
		<content:encoded><![CDATA[<p>Don&#8217;t feel like a lone wolf! I have been looking for some time for someone else with this view, sorry it&#8217;s so long after your post!</p>
<p>I keep trying to find out &#8220;what is wrong with GEDCOM&#8221;, and (apart from some really minor tweaks) all I can find is example of where poor implementation of the standard means that different programs do different things.</p>
<p>For example, you mention the BetterGEDCOM test with address information (actually phone number). Well, although they say &#8220;Looking at the GEDCOM 5.5 it appears that the format is correct&#8221;, I don&#8217;t think it is. Phone number simply isn&#8217;t allowed where they found it, so their complaints have absolutely nothing to do with whether GEDCOM is any good.</p>
<p>I agree with you that there are very few standards that are as widely implemented as GEDCOM, and any new standard is just as likely to be abused.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Twitter Trackbacks for Louis Kessler’s Behold Blog [beholdgenealogy.com] on Topsy.com</title>
		<link>http://www.beholdgenealogy.com/blog/?p=803#comment-176</link>

				<dc:creator>Twitter Trackbacks for Louis Kessler’s Behold Blog [beholdgenealogy.com] on Topsy.com</dc:creator>

		<pubDate>Thu, 06 Jan 2011 10:29:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.beholdgenealogy.com/blog/?p=803#comment-176</guid>
		<description>[...] Louis Kessler’s Behold Blog  beholdgenealogy.com/blog/?p=803 &#8211; view page &#8211; cached  A month ago, I blogged about the BetterGEDCOM endeavor. In the ensuing month, I’ve gotten involved and added my two cents worth. I find I’m mostly a lone wolf in the woods. [...]</description>
		<content:encoded><![CDATA[<p>[...] Louis Kessler’s Behold Blog  beholdgenealogy.com/blog/?p=803 &ndash; view page &ndash; cached  A month ago, I blogged about the BetterGEDCOM endeavor. In the ensuing month, I’ve gotten involved and added my two cents worth. I find I’m mostly a lone wolf in the woods. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Louis Kessler</title>
		<link>http://www.beholdgenealogy.com/blog/?p=803#comment-175</link>

				<dc:creator>Louis Kessler</dc:creator>

		<pubDate>Thu, 06 Jan 2011 07:06:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.beholdgenealogy.com/blog/?p=803#comment-175</guid>
		<description>Russ,

I think that the work you are doing is excellent. Without placing blame on which program might be wrong, the bottom line is that the two programs simply did not interpret and implement the standard the same way.

In my opinion, your tests are great because they are showing the areas where data transfer with GEDCOM is failing. 

If the program authors really cared about their users, they'd realize that their users feel that transferring their data between programs and archiving it in a GEDCOM file that can be read again later is extremely important to them.How many people have lost their data when the vendor dissolved and they lost their copy of their program when their computer crashed? They only had that program's proprietary database backed up, but nothing to read it. (Got any 8-tracks lying around?).

Those program authors would make sure their program at least will export to GEDCOM according to the standards. The users will feel assured that there should be some program out there that should then be able to read it in. But if the standards are not followed, then there is no guarantee.

On the Wiki, expect controversy. Especially from us programmers. We are a wildly eccentric bunch.</description>
		<content:encoded><![CDATA[<p>Russ,</p>
<p>I think that the work you are doing is excellent. Without placing blame on which program might be wrong, the bottom line is that the two programs simply did not interpret and implement the standard the same way.</p>
<p>In my opinion, your tests are great because they are showing the areas where data transfer with GEDCOM is failing. </p>
<p>If the program authors really cared about their users, they&#8217;d realize that their users feel that transferring their data between programs and archiving it in a GEDCOM file that can be read again later is extremely important to them.How many people have lost their data when the vendor dissolved and they lost their copy of their program when their computer crashed? They only had that program&#8217;s proprietary database backed up, but nothing to read it. (Got any 8-tracks lying around?).</p>
<p>Those program authors would make sure their program at least will export to GEDCOM according to the standards. The users will feel assured that there should be some program out there that should then be able to read it in. But if the standards are not followed, then there is no guarantee.</p>
<p>On the Wiki, expect controversy. Especially from us programmers. We are a wildly eccentric bunch.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: hrworth</title>
		<link>http://www.beholdgenealogy.com/blog/?p=803#comment-174</link>

				<dc:creator>hrworth</dc:creator>

		<pubDate>Thu, 06 Jan 2011 06:13:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.beholdgenealogy.com/blog/?p=803#comment-174</guid>
		<description>Louis,

From the testing that I have done, between two programs, I think the issue is really in the details that were provided in the GEDCOM 5.5 Documentation. Technology has changes, and the developers, over that time, had not gone back to look at that document and ask questions or tightening up the requirements.

Sure, there are many other features, like Randy mentions, that we need to get into the requirements of the next vehicle that is used to Share Information.

I have shown, a couple of non-technical details on the BetterGEDCOM Blog, where I tried to point out. I have taken a couple of specific examples and looked at the GEDCOM 5.5 document to see what the issue is. In this Non-Technical, End User's point of view, the problem might be in the 5.5 requirements. Sure, there is more stuff to do, but at this point, this started because two end users couldn't share data.

I am not trying to say or show which program is "wrong", cause I don't really know.

For example:

I used a Burial Fact / Event, trying to get it between two programs. For the example, I used the Location and the Cemetery Name.

The Sending Program, has a Place field and a Description field. The Location when into the Place field, the Cemetery name into the Description.

Sent that GEDCOM to a second program. Guess what, the Place name ended up where it belonged AND the Description (Cemetery Name) ended up in the Description field on the other program. However, the Other Program wanted the Cemetery Name in  a Detail field, not Description field.

Looking at the GEDCOM file, this End User, couldn't tell if the GEDCOM file had the information in the right order or not.

Just this afternoon, I took that same GEDCOM file, and opened it in another program. The Location came in OK, but the Cemetery Name is now where to be found. Now, I just started to use this program this afternoon, so I still will look around before I post anything about these results. Also, this program is due for an upgrade, shortly. So, I won't do any more testing until I have the upgrade.

The next set of tasks, is with Sources and Citations.

Beyond this basic sharing of information issue, This project is trying to think ahead a little bit, to see what might need to be needed for the larger Genealogy community. Specifically, those leaders in this field who are struggling with how to do research or how to evaluate our research. Looking at some of the 'new' standards that are showing up.

The GPS by Mark Tucker is one example.

I heard Elizabeth Shown Mills talk about 2 years ago, and I think Randy was in that talk, where she pointed out that we need to Evaluate our Evidence, now that we have collected it. The BetterGEDCOM project doesn't need to develop those tools, but have the ability to share what conclusions we reached in our research and how we got there. I think there is a GEDCOM Tag for sharing a 1 to 3 star rating on a Source, but what I am talking about it beyond that.

I have listened to End Users for about 10 years on this sharing topic, tried to help them know what they are doing or not doing, what can expect or not expect. So, I have heard most of the stories. Forgotten many though. But these tests that I am trying to post on the blog are examples of a common End User trying to share research using the vehicle we have today. Then, let the Technical folk create a useful solution that the Application Developers can 'buy into'.

I think the Wiki is getting to some of the details, which is why we have the Wiki. I think that for the amount of time that this project has been 'live' on the Wiki, we have made lots of headway.

Thank you for your participation in the Conference Call earlier in the week and thank you for this blog.

Russ</description>
		<content:encoded><![CDATA[<p>Louis,</p>
<p>From the testing that I have done, between two programs, I think the issue is really in the details that were provided in the GEDCOM 5.5 Documentation. Technology has changes, and the developers, over that time, had not gone back to look at that document and ask questions or tightening up the requirements.</p>
<p>Sure, there are many other features, like Randy mentions, that we need to get into the requirements of the next vehicle that is used to Share Information.</p>
<p>I have shown, a couple of non-technical details on the BetterGEDCOM Blog, where I tried to point out. I have taken a couple of specific examples and looked at the GEDCOM 5.5 document to see what the issue is. In this Non-Technical, End User&#8217;s point of view, the problem might be in the 5.5 requirements. Sure, there is more stuff to do, but at this point, this started because two end users couldn&#8217;t share data.</p>
<p>I am not trying to say or show which program is &#8220;wrong&#8221;, cause I don&#8217;t really know.</p>
<p>For example:</p>
<p>I used a Burial Fact / Event, trying to get it between two programs. For the example, I used the Location and the Cemetery Name.</p>
<p>The Sending Program, has a Place field and a Description field. The Location when into the Place field, the Cemetery name into the Description.</p>
<p>Sent that GEDCOM to a second program. Guess what, the Place name ended up where it belonged AND the Description (Cemetery Name) ended up in the Description field on the other program. However, the Other Program wanted the Cemetery Name in  a Detail field, not Description field.</p>
<p>Looking at the GEDCOM file, this End User, couldn&#8217;t tell if the GEDCOM file had the information in the right order or not.</p>
<p>Just this afternoon, I took that same GEDCOM file, and opened it in another program. The Location came in OK, but the Cemetery Name is now where to be found. Now, I just started to use this program this afternoon, so I still will look around before I post anything about these results. Also, this program is due for an upgrade, shortly. So, I won&#8217;t do any more testing until I have the upgrade.</p>
<p>The next set of tasks, is with Sources and Citations.</p>
<p>Beyond this basic sharing of information issue, This project is trying to think ahead a little bit, to see what might need to be needed for the larger Genealogy community. Specifically, those leaders in this field who are struggling with how to do research or how to evaluate our research. Looking at some of the &#8216;new&#8217; standards that are showing up.</p>
<p>The GPS by Mark Tucker is one example.</p>
<p>I heard Elizabeth Shown Mills talk about 2 years ago, and I think Randy was in that talk, where she pointed out that we need to Evaluate our Evidence, now that we have collected it. The BetterGEDCOM project doesn&#8217;t need to develop those tools, but have the ability to share what conclusions we reached in our research and how we got there. I think there is a GEDCOM Tag for sharing a 1 to 3 star rating on a Source, but what I am talking about it beyond that.</p>
<p>I have listened to End Users for about 10 years on this sharing topic, tried to help them know what they are doing or not doing, what can expect or not expect. So, I have heard most of the stories. Forgotten many though. But these tests that I am trying to post on the blog are examples of a common End User trying to share research using the vehicle we have today. Then, let the Technical folk create a useful solution that the Application Developers can &#8216;buy into&#8217;.</p>
<p>I think the Wiki is getting to some of the details, which is why we have the Wiki. I think that for the amount of time that this project has been &#8216;live&#8217; on the Wiki, we have made lots of headway.</p>
<p>Thank you for your participation in the Conference Call earlier in the week and thank you for this blog.</p>
<p>Russ</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Louis Kessler</title>
		<link>http://www.beholdgenealogy.com/blog/?p=803#comment-173</link>

				<dc:creator>Louis Kessler</dc:creator>

		<pubDate>Thu, 06 Jan 2011 04:22:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.beholdgenealogy.com/blog/?p=803#comment-173</guid>
		<description>Thanks Randy.

I've now been doing some research into the early beginnings and thoughts and concepts that Bill Harten and his team had about GEDCOM. My respect for their work grows with every tidbit of history that I uncover.

Redoing GEDCOM is not a simple task that two dozen people can accomplish in their spare time on a Wiki and with weekly one-hour chats. It took a dedicated team of expert genealogists and programmers from the Family History Department of the LDS church years to work together to formulate a comprehensive standard, and then refine and expand it, and do so several times. The resulting product is not a put together mess. It is a cohesive meaningful and at the time comprehensive standard, of which every tiny part was debated and decided on with good reason. 

If I had my druthers, I'd get that team, or a team of similar structure, together again with paid salaries and dedicated responsibility to the standard, who understand the concepts that have been included in it so far, to take over the evolution of the standard from here. Hello LDS? Can I pray for a miracle?</description>
		<content:encoded><![CDATA[<p>Thanks Randy.</p>
<p>I&#8217;ve now been doing some research into the early beginnings and thoughts and concepts that Bill Harten and his team had about GEDCOM. My respect for their work grows with every tidbit of history that I uncover.</p>
<p>Redoing GEDCOM is not a simple task that two dozen people can accomplish in their spare time on a Wiki and with weekly one-hour chats. It took a dedicated team of expert genealogists and programmers from the Family History Department of the LDS church years to work together to formulate a comprehensive standard, and then refine and expand it, and do so several times. The resulting product is not a put together mess. It is a cohesive meaningful and at the time comprehensive standard, of which every tiny part was debated and decided on with good reason. </p>
<p>If I had my druthers, I&#8217;d get that team, or a team of similar structure, together again with paid salaries and dedicated responsibility to the standard, who understand the concepts that have been included in it so far, to take over the evolution of the standard from here. Hello LDS? Can I pray for a miracle?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rjseaver</title>
		<link>http://www.beholdgenealogy.com/blog/?p=803#comment-172</link>

				<dc:creator>rjseaver</dc:creator>

		<pubDate>Thu, 06 Jan 2011 02:54:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.beholdgenealogy.com/blog/?p=803#comment-172</guid>
		<description>Excellent thoughts...I've had some of the same but haven't been able to elucidate on them as well as you have.  

From what I've read, I think the three biggest problems with the current GEDCOM standard is:

1)  The lack of a way to attach media
2)  The nuclear family structure.  
3)  The ANSI vs Unicode problem with languages and alphabets

I'm not enough of an expert to figure all of that out (hmmm, I'm not any kind of expert, just a user...).  

Perhaps if the group can get the software companies to buy-in to the standards set by GEDCOM then we could have an improved standard.

But it seems to me that the companies want to have their own version to be able to do some things differently from the other companies.  What other reason would there be to have different GEDCOM tags or formats?  Seems that Ancestry.com has an interest in keeping FTM different from the others.  If the FamilySearch Family Tree becomes the de facto leader in free online family trees, then perhaps the software companies will agree to a standard, but FS don't seem to care any more - they're depending on the affiliates to do the hard work of adapting to the FSFT model and formats.</description>
		<content:encoded><![CDATA[<p>Excellent thoughts&#8230;I&#8217;ve had some of the same but haven&#8217;t been able to elucidate on them as well as you have.  </p>
<p>From what I&#8217;ve read, I think the three biggest problems with the current GEDCOM standard is:</p>
<p>1)  The lack of a way to attach media<br />
2)  The nuclear family structure.<br />
3)  The ANSI vs Unicode problem with languages and alphabets</p>
<p>I&#8217;m not enough of an expert to figure all of that out (hmmm, I&#8217;m not any kind of expert, just a user&#8230;).  </p>
<p>Perhaps if the group can get the software companies to buy-in to the standards set by GEDCOM then we could have an improved standard.</p>
<p>But it seems to me that the companies want to have their own version to be able to do some things differently from the other companies.  What other reason would there be to have different GEDCOM tags or formats?  Seems that Ancestry.com has an interest in keeping FTM different from the others.  If the FamilySearch Family Tree becomes the de facto leader in free online family trees, then perhaps the software companies will agree to a standard, but FS don&#8217;t seem to care any more - they&#8217;re depending on the affiliates to do the hard work of adapting to the FSFT model and formats.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Louis Kessler</title>
		<link>http://www.beholdgenealogy.com/blog/?p=803#comment-171</link>

				<dc:creator>Louis Kessler</dc:creator>

		<pubDate>Thu, 06 Jan 2011 02:39:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.beholdgenealogy.com/blog/?p=803#comment-171</guid>
		<description>Yes Gene, and even in your comment, you're still blaming the delivery boy ("rely on GEDCOM"), when the real culprits are the exporting program and the importing program.

I don't blame you for this. It is the natural thing to do.

What you and all users should have done for years is complain. Complain LOUDLY to the vendors of the software, and insist that they fix their programs.</description>
		<content:encoded><![CDATA[<p>Yes Gene, and even in your comment, you&#8217;re still blaming the delivery boy (&#8221;rely on GEDCOM&#8221;), when the real culprits are the exporting program and the importing program.</p>
<p>I don&#8217;t blame you for this. It is the natural thing to do.</p>
<p>What you and all users should have done for years is complain. Complain LOUDLY to the vendors of the software, and insist that they fix their programs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: genej</title>
		<link>http://www.beholdgenealogy.com/blog/?p=803#comment-170</link>

				<dc:creator>genej</dc:creator>

		<pubDate>Thu, 06 Jan 2011 02:22:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.beholdgenealogy.com/blog/?p=803#comment-170</guid>
		<description>Hi Louis:

Another great blog posting. 
I think the part of the Build a BetterGEDCOM blog effort to which you are referring is aimed at providing real time, user-to-user examples of genealogical data being transferred between two programs using GEDCOM. 

I won't speak for Russ, but I know I sure haven't set out to play GEDCOM expert on the blog. 

Separately, it's been years since I felt I could rely on a GEDCOM transfer. When it fails, I feel a little like a Microsoft Windows user in 1993 -- it's always the other guy's fault. --GJ</description>
		<content:encoded><![CDATA[<p>Hi Louis:</p>
<p>Another great blog posting.<br />
I think the part of the Build a BetterGEDCOM blog effort to which you are referring is aimed at providing real time, user-to-user examples of genealogical data being transferred between two programs using GEDCOM. </p>
<p>I won&#8217;t speak for Russ, but I know I sure haven&#8217;t set out to play GEDCOM expert on the blog. </p>
<p>Separately, it&#8217;s been years since I felt I could rely on a GEDCOM transfer. When it fails, I feel a little like a Microsoft Windows user in 1993 &#8212; it&#8217;s always the other guy&#8217;s fault. &#8211;GJ</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.793 seconds -->
