Cheryl, How do you know it will be a GEDCOM? Legacy doesn't use one to access FS at present.
Ron Ferguson http://www.fergys.co.uk/ singhals <singh...@erols.com> wrote: >I *totally* agree that data placed in today's FSTree will be >around longer than most other depositories. > >That said, though, there are only one way to get data in >there: type each entry separately. They have not >implemented a massive-upload feature. And when they *do*, >the vehicle will be GED. The drawbacks to GED have been >well-discussed. > >That makes ANY depository better than NO depository, IMO. > >Cheryl > >John B. Lisle wrote: >> Jackie, >> >> Good points. >> >> Let me suggest that possibly the "archive" that is most >> likely to continue is the FamilySearch Tree. Several >> "senior" members of the Guild of One Name Studies are using >> that as the archive for their reconstructed family data, >> just because they data there will likely persist but also >> will be improved by the user community. >> >> To me, that is one of the reasons that I have to plan to >> keep my data integrated there. >> >> As more advanced genealogist use that resource, the more >> valuable and effective it will become. Watch this space... ;-) >> >> john. >> >> At 07:53 PM 12/6/2013, Jackie King wrote: >>> I have to comment here. >>> >>> I have come to the conclusion that relying on any one >>> archive - be it NEHGS or any other is not that good an >>> idea either. Therefore I have been updatig to several >>> including Wikitrees, two local archives and am noW looking >>> at those such as NEHGS. >>> >>> Each has their pluses and minuses ... and I work around >>> each. But what I find is what doesn't work on one may work >>> on another. Each has their standards and each has >>> standards that seem to be evolving. >>> >>> But what I find, is that by working around each, my >>> genealogy as a whole is a lot sounder. I don't begrudge >>> the extra time it takes me as each points out different >>> weaknesses in my database and my proofs. >>> >>> I've watched the standards evolve and while i wish there >>> was another standard like Gedcom was - it is so dated that >>> it does not encompass what many of us are capable of doing >>> now. Until someone either updates the old Gedcom standards >>> or comes up with a new generally accepted standard, we are >>> all going to be working with "problem" areas. To say one >>> group won't accept something because it is not Gedcom >>> acceptable tells me they may be missing out on a lot of >>> information. >>> >>> Just my thoughts. >>> >>> Jackie >>> >>> >>> On Fri, Dec 6, 2013 at 3:30 PM, John B. Lisle >>> <leg...@tqsi.com <mailto:leg...@tqsi.com>> wrote: >>> >>> CE, et al, >>> >>> As I have said previously, you have to build your >>> genealogy knowing >>> how you plan to publish it. >>> >>> If your goal is only to archive with NEHGS, then you >>> have to create >>> your family files to comply with their standards. >>> However, I have >>> spoken in the past with their Archivist, and he told >>> me that the >>> handling of electronic archives is an evolving >>> standard. When you >>> were told to give them a standard Gedcom, I believe >>> they were giving >>> a basic standard, not based on any true understanding >>> of what the >>> reality on the ground is. However, I truly believe >>> they have to >>> evolve. And will, in reality, accept anything. Would >>> it kill them >>> financially to maintain copies of all of the popular >>> genealogy >>> programs in the Archive department to allow them to >>> access their >>> member submissions? >>> >>> For instance, many folks have their electronic >>> archives in software >>> like TMG that does not export all of its data, only >>> the data that >>> fits into the narrow Gedcom 5.5.1 standard. I would >>> assume those >>> folks will want to submit beyond a Gedcom, a copy of >>> their TMG file. >>> Some folks have their archives in Word, Excel, Access, >>> or one of 100s >>> of other non-standard forms. >>> >>> The Guild of One Name Studies has a facility - which >>> they are >>> enhancing - for archiving any of a member's electronic >>> archive. We >>> are discussing how succession planning needs to be >>> done when someone >>> new wants to take on a Surname study that a previous >>> deceased or >>> retired member started. >>> >>> In contrast to what has been said on this list, I do >>> not think >>> SourceWriter is a current impediment to exporting a >>> "compliant" >>> Gedcom. The current structure exported may not be >>> pretty, but the key >>> information seems to be exported in a fashion that is >>> Gedcom 5.5.1 >>> compliant for sources. The more serious issue with SW >>> is that you >>> cannot export to Gedcom a SW source so that it can be >>> re-imported >>> back into Legacy as a SW source. >>> >>> Shared Events are a current problem. If you - meaning >>> anyone reading >>> this message - want to see Legacy have an OPTION to >>> export Shared >>> events as regular events, make that as a formal >>> suggestion. If enough >>> of you make that request, I suspect it will go high on >>> the project >>> list and happen in an L8 update. The developers >>> definitely respond to >>> user's requests when deciding what enhancements to do. >>> The more the merrier. >>> >>> But... in precise Gedcom-ese, how are you exporting >>> Child Status, >>> Marriage Status, Child-Parent Relationships, etc etc. >>> Concepts that >>> are so basic to the genealogy documentation yet not >>> within the scope >>> of the Gedcom 5.5.1 standard? Yet most vendors >>> transfer that data by >>> having accepted a common set of tags. Until you line >>> by line through >>> a Legacy Gedcom trying to see what is there, you >>> cannot really >>> understand what data you will lose if you have to >>> limit yourself to >>> what is within the confines of the Gedcom 5.5.1 standard. >>> >>> OK? >>> >>> john. >>> >>> >>> >>> >>> At 03:12 PM 12/6/2013, CE Wood wrote: >>> >Several in this group have posted regarding what >>> happens to their >>> >research when they die. The custom features of Legacy >>> which are not >>> >rendered correctly in GEDCOM pose a major problem in >>> this regard. >>> >The NEHGS has asked for my collection, including my >>> database. >>> >However, they will accept it only as a GEDCOM because >>> that is the >>> >only way that it can be read in whatever program they >>> use now or in >>> >the future (when I plan to die). >>> > >>> >That means using SourceWriter and Shared Events are >>> not an option for me. >>> > >>> >In addition to the problems using Legacy with online >>> websites except >>> >on Legacy's own barebones one, this is another reason >>> to wonder why >>> >all the focus on totally proprietary features. Until >>> GEDCOMs >>> >accommodate Legacy's fancy features, maintaining >>> one's research in a >>> >transferrable format is of primary importance. That >>> is, if it >>> >matters whether anyone will be able to access your >>> research in the future. >>> > >>> > >>> >CE >> > > > >Legacy User Group guidelines: >http://www.LegacyFamilyTree.com/Etiquette.asp >Archived messages after Nov. 21 2009: >http://www.mail-archive.com/legacyusergroup@legacyusers.com/ >Archived messages from old mail server - before Nov. 21 2009: >http://www.mail-archive.com/legacyusergroup@legacyfamilytree.com/ >Online technical support: http://www.LegacyFamilyTree.com/Help.asp >Follow Legacy on Facebook (http://www.facebook.com/LegacyFamilyTree) and on >our blog (http://news.LegacyFamilyTree.com). >To unsubscribe: http://www.LegacyFamilyTree.com/LegacyLists.asp > > Legacy User Group guidelines: http://www.LegacyFamilyTree.com/Etiquette.asp Archived messages after Nov. 21 2009: http://www.mail-archive.com/legacyusergroup@legacyusers.com/ Archived messages from old mail server - before Nov. 21 2009: http://www.mail-archive.com/legacyusergroup@legacyfamilytree.com/ Online technical support: http://www.LegacyFamilyTree.com/Help.asp Follow Legacy on Facebook (http://www.facebook.com/LegacyFamilyTree) and on our blog (http://news.LegacyFamilyTree.com). To unsubscribe: http://www.LegacyFamilyTree.com/LegacyLists.asp
