Search for content in message boards

Facts vs. Notes

Facts vs. Notes

Posted: 29 Nov 2012 2:23PM GMT
Classification: Query
As I'm working on my family tree, I had been entering "Birth Time" and "Cause of Death" and such as separate facts, partly because "Cause of Death" was a default fact in FTM and I went with the pattern. Now that I'm realizing that you can make notes for every fact, so why not put them in the "Birth" and "Death" notes?

I'm wondering when and or why you would make a separate fact vs. put something in a note. Any thoughts?

Re: Facts vs. Notes

Posted: 29 Nov 2012 2:36PM GMT
Classification: Query
It's okay to use notes to put more details about an event, but in general you give yourself more options in the long term when you store data in its own "fact". For example, if you wanted to compare causes of death across your tree, you could easily look at that in a report. If the cause of death were buried in your notes, however, any report made for this purpose would contain a lot of extra stuff to wade through.

Re: Facts vs. Notes

Posted: 29 Nov 2012 3:03PM GMT
Classification: Query
Edited: 29 Nov 2012 3:49PM GMT
I agree.

Some reasons for something in a fact description vs a fact note or vice-versa:

1) Reporting. The Genealogy (Register) Reports (ahnentafel or descending) contain an option under "items to include" of "fact notes" - yes or no. You can select facts individually to include in the report. Depending on your work habits, fact notes may add a lot of volume to your report; while adding the description field of a fact may add only one line per person.

2) Exporting. All facts will be exported in an export for the individuals selected, but you can choose to not export Private Notes (using the "Lock" icon).

3) FTM's standard filter - which can be used to see people in your index, or can be used to select individuals in a custom report (and some other). You can filter on text in notes, but it is easier (ie less memory) to filter based on a text string in a fact description.

So, if you think you might ever want to group a dataset of people in your database that share some trait - I would put it in a fact. If it is a piece of info that you might want to include in reports, but not include all of your fact notes, put it in as a fact description.

Another reason is that a Fact Note is somewhat "hidden" from view when viewing the person in Person View. If it is something you want to make visible in person view, you may want to put it in a fact description - or at least type the words "See Fact Note". Otherwise, the fact looks "empty" and not used.

Re: Facts vs. Notes

Posted: 12 Dec 2012 2:29AM GMT
Classification: Query
The only problem I have encountered in using the description field in Ancestry.com or FTM2012 is that the description field and the place field get merged into a single place field in gedcom transfers to other software. It becomes a huge mess trying to clean up the locations once that occurs.

If you plan on using FTM and Ancestry alone and aren't worried about being able to share the tree with someone using another software, then no problem.

If you create custom events, be careful about the label you use for the event. If you inadvertently use a label already in use by GEDCOM standard or software specific labels, it may cause problems duing gedcom tranfers later on.

Re: Facts vs. Notes

Posted: 19 Dec 2012 11:46PM GMT
Classification: Query
The problem of merging place and description fields in exported GEDCOMs is a real problem with FTM. However, there is a way round it which seems to work, at least with FTM 2012. For the export select output format as GEDCOM 5.5, choose whatever you want to include and then when you get asked to pick a destination choose FTM 2012 not Other. I have done this a number of times to move a file from FTM to Legacy [Because I am more familiar with the reporting in Legacy] and as long as you prevent Legacy from "adjusting" for the known PLAC problem with FTM it seems to work fine. No guarantees of course, I have not stress tested this.
per page

Find a board about a specific topic

  • Visit our other sites:

© 1997-2014 Ancestry.com | Corporate Information | Privacy | Terms and Conditions