Jump to content


Photo

Fact Types


  • Please log in to reply
17 replies to this topic

#1 reborrell

reborrell

    Advanced Member

  • Members
  • PipPipPip
  • 108 posts

Posted 18 October 2016 - 04:37 AM

It's great that RM has the ability for the user to add fact types.  Here are ones that I use.  Please feel free to add some of yours to the list.

 

Acceeded
Adoption
Age100+
Alt. Birth
Alt. Birth Info
Alt. Death
Alt. Marriage
Alternate Name
Ancestral File Number
Annulment
AwardsHonors
Baptism
Bar Mitzvah
Bas Mitzval
Birth Hospital
Birth-Alt
Birth-Alt
Blessing
Bullet
Burial
Caste
CatholicBishop
CatholicCardinal
CatholicPope
CatholicPriest
CemeteryPHOTO
CemeteryPLOT
Census1790
Census1800
Census1810
Census1820
Census1830
Census1840
Census1850
Census1860
Census1870
Census1880
Census1890
Census1890CW
Census1900
Census1910
Census1920
Census1930
Census1940
CensusLocal
Ceremony By
Christen (adult)
Christened
Church
CityDirectory
Confirmation
Constable
Court
Cremation
Death-Alt
Decorations
Degree
Description
Direct Ancestor
Direct Ancestor Nora
Divorce
Divorce filed
DNA Test
Education
Election
Emigration
Engagement
Event
Excommunicatioin
Fact 1
Fact 2
Fact 3
Fact 4
Fact 5
Fact 6
Fact 7
Fact 8
Fact 9
Family Forest Ref #
First communion
Forester
Fraternal_IORM
FraternalCOLUMB
FraternalELKS
FraternalIOOF
Fraternal-IORM
FraternalMASON
Fraternal-OES
FraternalPYTHIA
GenealRankMembe
Godparents
Graduation
Illness
Immigration
Info 2
Info 3
InquestPerson
InquestPerson
Jury
Justice
Land
Land
Land - BLM
Living
Magna Carta Surety
Manorial Estate
Marriage Bann
Marriage Contract
Marriage Face
Marriage License
Marriage-Alt
MedicalDENTIST
MedicalDOCTOR
MedicalVET
Military
Military Rank
Military Servic
Military1776
Military1812
MilitaryCOLONIA
MilitaryCWunion
MilitaryCWunkno
MilitaryIraq1
MilitaryIraq2
MilitaryKorean
MilitaryNatGuar
MilitarySPANISH
MilitaryVIETNAM
Military-WW1
MilitaryWW1reg
Military-WW2
MilitaryWW2regi
Mission
MP - MemberOfParliment
Name - Favorite
Namesake
Nationality
Naturalization
NewspaperArticle
Nickname
Nobility Baronet
Nobility Esquire
Nobility Gentleman
Nobility Knight
Nobility Laird
Nobility Patrician
Nobility Seigneur
Obituary
Occupation
Offices
Ordination
Partners
Petition
PoliticsGOV
PoliticsGOVERNM
PoliticsMAYOR
PoliticsPRES
PoliticsSTsen
PoliticsUSrep
Politics State Delegate
PoliticsUSsenat
PowerAttorney
Probate
Religion Abbess
Religion Abbot
Religion Minister
Religion Monsignor
Residence
Reverdy
Royal Archduke
Royal Baron
Royal Baroness
Royal Count
Royal Countess
Royal Duke
Royal Dutchess
Royal Earl
Royal Emperor
Royal King
Royal Knight
Royal Lady
Royal Landgrave
Royal Maquess
Royal Margrave
Royal Marquis
Royal Prince
Royal Princess
Royal Queen
Royal Sultan
Royal Viscount
Ruled
ScannedDoc
Separation
SlaveOwner
Soc Sec No
Stillborn
Taxes Rent Roll
Title (Nobility)
Titled
Triplet
Twin
Undertaker
WillADMIN
WillINVENTORY
WillProved
Witness
 


#2 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3535 posts

Posted 18 October 2016 - 10:00 AM

Without getting into all the details of all the user defined facts I use, I would comment that I think that RM's user defined facts are one of its best features and I use them heavily. I do worry a great deal about the interchange of my data with third party software, and my experience is that user defined facts are one RM feature that seems to interchange pretty well - unlike, for example, Place Details and Shared Facts. An exception for user defined facts and exchange with third party software is FamilySearch Family Tree but the FSFT data model is so severely limited that I decided a long time ago not to let the limitations of FSFT's data model govern my own research.

 

I notice that you have census facts for each census year. I do the same thing. There are big advantages within RM to do so. For example, it allows you to search on place and year for the same census fact which you really can't do with RM's built-in census fact (e.g., with the built-in fact a search for  census place of Texas and census date of 1850 will find somebody who was enumerated in Tennessee in 1850 and in Texas in 1860). For another example, census facts for each census year allows you to use People View in a productive way to look at census data, which the built-in census fact does not do.

 

I notice that you have a City Directory fact. I also have a City Directory fact, except that I am converting mine to be a City Directory fact for each year for the same reasons I made the census fact be by year.

 

I have split the Burial fact into three facts - the Burial fact (still the original built-in one), burial inscription, and burial GPS. I don't have a burial photo fact, but the burial photo is a source for the burial inscription and for the burial fact itself.

 

I have split the Death fact into three facts - the Death fact (still the original built-in one), death certificate, and obituary. The death certificate and obituary are also sources, and the sources apply to the Death fact, death certificate fact, and obituary fact as a appropriate.

 

I have split the Birth fact into three facts - Birth, Birth certificate, and newspaper birth announcement, similar to the Death fact.

 

I am taking the same approach to a number of other fact types. Splitting them in this manner makes narrative reports read better, it makes it easier to attach sources to the appropriate facts, and it makes People View much more useful.

 

Jerry



#3 reborrell

reborrell

    Advanced Member

  • Members
  • PipPipPip
  • 108 posts

Posted 18 October 2016 - 10:39 AM

I find the Fact types a great way to quickly search on various items.  I use them all the time.

 

What fact types do you use that I don't have in my list?



#4 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8414 posts

Posted 18 October 2016 - 11:02 AM

FSFT - FamilySearch Family Tree status

WebHints - Track status of WebHints and last time checked

 

I use these to keep track of my research and what still needs to be done. I use key words to search on those facts.


Renee
RootsMagic

#5 reborrell

reborrell

    Advanced Member

  • Members
  • PipPipPip
  • 108 posts

Posted 18 October 2016 - 12:28 PM

That is an excellent idea for the WebHints.

 

Is there a way to create a Fact Type that globally includes everyone in the database AND becomes a sort of standard fact template for when you add new people?



#6 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3535 posts

Posted 18 October 2016 - 01:04 PM

 

Is there a way to create a Fact Type that globally includes everyone in the database AND becomes a sort of standard fact template for when you add new people?

 

There is not a way within RM. You can add a fact of a given type to everyone in your database using SQLite.

 

In addition to user defined fact types that you intend to print out (e.g. census by year), it can be useful to create user defined fact types that you don't include in reports. Such "dummy" fact types can be searched, they can be used with People View, and they can be used to define color coding or Named Groups, etc.

 

The main barrier to using user defined facts in this way is that you can't easily add such facts to everybody in your database, nor can you globally change any values associated with such facts on any kind of bulk basis. TMG refugees converting to RM are accustomed to such a feature in TMG, and TMG refugees usually ask for RM to include such a feature. Whether RM might eventually include such a feature by doing it with user defined facts or by doing it in some other way is completely unknown.

 

Jerry



#7 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8414 posts

Posted 18 October 2016 - 03:09 PM

On the Add Person screen click the link in the bottom left corner "Customize this form", to add any fact to that screen. 


Renee
RootsMagic

#8 RWells1938

RWells1938

    Advanced Member

  • Members
  • PipPipPip
  • 215 posts

Posted 18 October 2016 - 04:02 PM

Great ideals 

 

What would be great is for a sample sentence templates for each fact type.

 

Roger



#9 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 207 posts

Posted 19 October 2016 - 06:33 AM

Do regular/standard fact have a TYPE as well. In GEDCOM you can "type" every fact. This way you can give a fact like BIRTh a TYPE of "still" to designate a "stillborn" fact, or for the MARRiage tag a TYPE of "civil" or "religious" can be set to indicate a subtype of the primary fact. A NAME can have a TYPE as well, so a name can be "married", "birth", "aka", "adopted", etc. The CENSus tag could have TYPE indicating the year.

Also I'm not sure why you would add a new fact of "Divorce Filed" when GEDCOM already has a DIVF tag, or "Social Security" when it has a SSN tag. "MARL" for marriage license, "MARC" for marriage contract. Does RM not support these standard GEDCOM tags?

Maybe I'm misunderstanding the term "Fact Types" in this context, I create user defined facts in GEDCOM which is different than using Fact Types.

A fact type is a subset of the primary fact while a user defined fact is a new fact. User defined fact can be "typed" as well to create a fact of Military, with a TYPE of "induction" or "discharge". NOTE: The "Military" tag does not existing standard GEDCOM, but can be created using standard GEDCOM syntax.

I'm trying to understand this because, if I were to ever move to of use an out of the box program like RM it would have to support GEDCOM.

#10 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3535 posts

Posted 19 October 2016 - 07:24 AM

There is obviously a terminology confusion with the term "type" in RM vs. the term "type" in GEDCOM. Keeping that in mind, RM "fact types" cannot be "typed" in the sense that is supported by GEDCOM. Which is to say, there is no way in RM to create a subset of an RM fact type, neither the built-in RM fact types nor user defined fact types. For example, there is no way in RM to create a fact type for a particular census year except to create a completely new fact type. You cannot create a subset of the built-in census fact type.

 

If RM did add the ability to create a subset of a fact type, I suspect I would be reluctant to use it for fear that such a feature would not play well with third party genealogy software. For example, RM's Place Details feature already has this problem so I don't use the feature.

 

Jerry



#11 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8414 posts

Posted 19 October 2016 - 07:44 AM

Great ideals 

 

What would be great is for a sample sentence templates for each fact type.

 

Roger

 

I don't have a sentence template for either my FSFT or WebHint fact type. Simply because they are not something I want in a narrative report. If I was to create one I would use the < [Date]> and < [Desc]> field in it.


Renee
RootsMagic

#12 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3406 posts

Posted 19 October 2016 - 09:19 AM

I'm trying to understand this because, if I were to ever move to of use an out of the box program like RM it would have to support GEDCOM.

 

Just for the record and before the genealogy community starts speaking in tongues you would only find in the delta quadrant, I only use user defined facts for the purposes of my own research purposes, not core information which would be exchanged with other researchers or online resources, if everyone did with no backwards translation then the game would be lost and completely insular to the researcher.

 

I once received a gedcom with 105 custom fact variations of "Address xxxx" where "xxxx" was the year, the RM "Residence" fact covers all these entries using the Date field as intended and I converted them all back to that standard. I fully realise that the Gedcom standard has its problems but it does encompass most needs except for bespoke user tags for their own research needs and I believe we should try to stay within it where possible. I will be nice when my research lives on beyond me that it will not be like decrypting the tombs of the pharaohs for whoever inherits it.

 

Just because you can design your own singular and individual set of facts doesn't mean it is a good idea to reinvent the wheel imo.


We are all limited by our visions and abilities

Whilst we can borrow from the visions of others we cannot always deliver.

 

User of Family Historian 6.2.7, Rootsmagic 7.6.0, Family Tree Maker 2014 & Legacy 7.5

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#13 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3535 posts

Posted 19 October 2016 - 09:56 AM

 

Just for the record and before the genealogy community starts speaking in tongues you would only find in the delta quadrant, I only use user defined facts for the purposes of my own research purposes, not core information which would be exchanged with other researchers or online resources, 

 

Until relatively recently (like three or four years ago), I followed the exact same approach you are describing and for the same reasons. But as I have discussed in these forums, I have begun to deviate a little bit from standard fact types for what seems to be compelling reasons. Deviating in this way does make me a little bit concerned about my genealogical legacy if ever someone wanted to import my GEDCOM with all my strange user defined facts. Let me describe a little bit of my reasoning and maybe you could suggest how you would deal with my GEDCOM if ever you received it.

 

Example #1: I use "census by year" fact types because using the built-in Census fact type creates multiple facts of the same type for an individual and because RM deals so awkwardly with multiple facts of the same type for an individual. For example, if a person is enumerated in both the 1850 and 1860 census, then there are two instances of the built-in Census fact type which makes it difficult or impossible to use People View or groups or color coding for census data. I used Tom's script to convert the built-in Census fact type to the "census by year" fact types, and he has another script to convert the census by year fact types back to the standard. But what if I didn't run his script to convert the fact types back to standard and what if I sent you some GECOM with the "census by year" fact types. The "census by year" data does import to most any software package and nothing is really lost, but you might still rather have it in the standard census fact type.  How awkward would my data be to deal with?

 

Example #2. I have moved obituaries from the Note field of the built-in Death fact type to the Note field of a custom fact type called Obituary. I now have hundreds of instances of the Obituary fact type. Again, if I sent you data with my Obituary fact type, how awkward you find it to be, and how would you prefer to receive it instead? Would you prefer to receive the obituaries in the Death note? I'm not sure that's a standard, either.

 

I really am curious and I'm not trying to be argumentative. I think this is a very important issue for how best to enter certain kinds of data. Other examples I'm dealing with at present include tombstone inscriptions, GPS coordinates for tombstones, transcriptions of death certificates, transcriptions of birth certificates, transcriptions of courthouse marriage records, transcriptions of newspaper birth announcements, etc. All these data have in common that they can serve as sources or as facts or as both. The "source" part of recording the data really isn't an issue. The data can be recorded in a Master Source in RM or in a citation in RM and the data seems to go into GEDCOM just fine. It's only when you want such data also to be a fact and to be printed in a narrative report that deciding where to enter the data seems to be so much of a concern to me.

 

Jerry



#14 reborrell

reborrell

    Advanced Member

  • Members
  • PipPipPip
  • 108 posts

Posted 19 October 2016 - 10:24 AM

Tombstone GPS would be a great Fact Type.  I'm wondering how many people use GPS for tombstones.  Also, I would imagine there would be a phone app that would definitely give you (and record) your GPS coordinates while standing next to a tombstone.



#15 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3535 posts

Posted 19 October 2016 - 11:03 AM

Tombstone GPS would be a great Fact Type.  I'm wondering how many people use GPS for tombstones.  Also, I would imagine there would be a phone app that would definitely give you (and record) your GPS coordinates while standing next to a tombstone.

 

Most (maybe all?) smartphones automatically geocode photos, so a photo of a tombstone taken with a smart phone will be usually tagged with the GPS coordinates. I've not really used billiongraves.com (still using findagrave.com mostly), but I understand that billiongraves.com supports the GPS coordinates that are geocoded to a photo and that they have a free app for taking photos. I may not have the story entirely straight because I'm not sure why a billiongraves.,com app is necessary if the phone is tagging the photo with GPS coordinates anyway.

 

I do have a (not free) GPS app for my smart phone. In addition to the automatic geocoding that the phone already does, the app allows me to annotate photos as I take them. The app is quite good in many respects. It is designed for hiking and things like that, not so much for driving. But it's actually not very good for hiking and things like that because the battery life of the phone when the app is running is only an hour or two and because the app depends on Internet connectivity for maps. Internet connectivity is usually poor or non-existent on a hiking trail in the mountains. Of course, geocoding a photo works just fine without maps. It's just that the phone can't show you where you are on a map without Internet connectivity.

 

So for hiking, I have a GPS device designed specifically for hiking. It has onboard maps and it has wonderful battery life - like several days of continuous operation. I have also discovered that my GPS device device that is designed specifically for hiking is a bit more accurate than is my phone. For example, my hiking GPS device might be accurate to about 10 feet when I'm not in the mountains and my phone might be accurate to about 20 to 30 feet when I'm not in the mountains. So I'm still using my old digital camera for tombstone photos even though the photos are not geocoded because the quality is a little better than my phone, and I'm using my hiking GPS to get tombstone coordinates. It's more labor intensive than the billiongraves.com way of doing it, but I'm happier with the results. (By the way, any GPS device is less accurate in the mountains because the mountains block access to any of the GPS satellites that are near the horizon.)

 

Before I started splitting my facts in RM, I recorded tombstone coordinates in the note for RM's burial fact. Now that I'm splitting the data into multiple fact types, I'm recording tombstone coordinates in the description field for my user defined BurialGPS fact in RM. By doing it that way, the tombstone coordinates can become a column in RM's People View.

 

In addition to recording the GPS data in RM, I'm also placing it on my Web site. I am placing my data on my Web site in such a way that there is a live interface with Google Maps. So you can zoom in to see exactly where the tombstone is in the cemetery and you can zoom out to see how to find the cemetery. Here is an example in case anybody is curious. https://mappingsuppo...xt&t=h&label=on  I haven't done so, but I could also store these kinds of links to my Web site as WebTags in RM.

 

Jerry



#16 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3406 posts

Posted 19 October 2016 - 05:12 PM

Until relatively recently (like three or four years ago), I followed the exact same approach you are describing and for the same reasons. But as I have discussed in these forums, I have begun to deviate a little bit from standard fact types for what seems to be compelling reasons. Deviating in this way does make me a little bit concerned about my genealogical legacy if ever someone wanted to import my GEDCOM with all my strange user defined facts. Let me describe a little bit of my reasoning and maybe you could suggest how you would deal with my GEDCOM if ever you received it.

 

No argument here Jerry, hopefully just constructive discussion and I hope the construction team is listening to user needs and working hard to respond to those needs. I found the original post and fact list by reborrell a little excessive and certainly alternative to standards whilst also inviting more suggestions for custom fact types. I wanted to try and add some balance to the discussion before some new users rush off to make the mistakes I did years ago.

 

I also have uses Toms script for census splitting but I know from previous discussions both you and I can easily reverse this strategy, not all users could. I always try to design and advocate programmed solutions to such common research needs rather that employ a workaround I may have to spend time reversing in the future, identifying missing census records is one such programming need. Where multiple facts of the same type exist People View could and should present a drop down arrow to expand the various displayed fields associated with that fact, I know very well the temptation to create additional facts to overcome this shortcoming.

 

Whilst on People view, and also off topic, I really do hope RM8 facilitates creating multiple People view tabs with their own user defined layout similar to creating a new worksheet in Excel.

 

Regarding your Obituary fact I would have no trouble as I also have the same custom fact using the Description field as the publication name. I personally see obituaries as support information rather than core information, now US obituaries and usually well written and informative but in Ireland they will consist of a number of small inserts offering condolences from families and friends and useful clues for distant previously unrealized family links.

 

Geocoding of grave stones is very close to my heart and I have recently returned from a three week US trip where I also collected various grave stone GPS. At present I record various Place Details (I know you don't use them) like "Greenlawn Cemetery (#M-112)" and geocode that grave number, it works for my purpose at present but it is not ideal.

 

Tombstones I attach to the Burial fact where they can be printed if desired, I wouldn't transcribe it as a rule unless particularly informative.

 

Returning to what should be in the mission statement for a genealogy program -

 

*Aid the compilation of quality genealogy data through a quick and efficient interface.

*Guide the user towards finding and completing missing information towards improving quality.

*Produce quality reports and publications the end user will be proud of"


We are all limited by our visions and abilities

Whilst we can borrow from the visions of others we cannot always deliver.

 

User of Family Historian 6.2.7, Rootsmagic 7.6.0, Family Tree Maker 2014 & Legacy 7.5

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#17 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3406 posts

Posted 19 October 2016 - 05:18 PM

So I'm still using my old digital camera for tombstone photos even though the photos are not geocoded because the quality is a little better than my phone, and I'm using my hiking GPS to get tombstone coordinates. It's more labor intensive than the billiongraves.com way of doing it, but I'm happier with the results.

 

 

Jerry, I take a rough layout sketch and surrounding wide photos then grab the co-ordinates from aerial views on online maps. Not technically accurate from a purist point of view but suitable for the relocation of the stone in the future.


We are all limited by our visions and abilities

Whilst we can borrow from the visions of others we cannot always deliver.

 

User of Family Historian 6.2.7, Rootsmagic 7.6.0, Family Tree Maker 2014 & Legacy 7.5

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#18 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 207 posts

Posted 19 October 2016 - 06:57 PM

First let me say that a lot was written since my question and I have not yet read all of them. I will answer what I have read, then come back to read more with additional answers.

Regarding Obituaries, Headstones, Census and the like are all sources. A census in GEDCOM Can also be an "event", that is your say that an Individual or Family participated in a census event much like a person participating in their birth or death event, a TYPE tag would be added to indicate what census. Obituaries and Headstones are not events or attributes (fact is not used except as a type of attribute, like Education or occupation) of a person. So I would never add Obits or Headstones to a person as an attribute or event.

I add Headstones as sources under a repository of the cemetery, placing the plot information in the source-repository field. I add GPS coordinates in fields designed for this as subtags of the burial.place tag. Which not really correct since it is suppose to be long and lata data. I should, but don't, put GPS location in the source notes because this is most logical as it is source information.

So you're going to say, but this information is not going to show the way I want it in a report. And I get that. If you stored the info the way I do, I'd ask for a headstone report. The cemetery tag was removed from GEDCOM in Version 5.4.

One reoccurring issue with most programs I've tried to use is that they are geared toward exact and singular data points, I collect all data I can so an individual may have multiple birth and death dates or place depending on what the sources say. Eventually I either remove or mark bad information from my final reports by using the source-citation.Quality tag setting it to 0 (zero). But this is probably not available in RM.

For custom events and attributes GEDCOM recommends using either tha FACT or EVEN tags, using the TYPE subtag to define the actual custom event or attribute, then allowing a subtype using the FACT/EVEN description. I use EVEN tags to record military information. I've customize my use of GEDCOM a little to support battle information as well.

This data would look something like this.
1 EVEN enlistment
2 TYPE military

1 EVEN battle of bunker hill
2 TYPE military

1 FACT elks
2 TYPE fraternal

I don't think all Genealogy programs like this, but it is recommended GEDCOM.