Jump to content


Photo

Baptism date on person list

list

  • Please log in to reply
35 replies to this topic

#21 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3410 posts

Posted 20 September 2015 - 09:52 PM

I had forgotten about the Christen (adult) fact type. If there were also a Baptism (adult) fact type, it would surely reduce the objections to using the Baptism fact type when appropriate as a surrogate for an approximate birth date in the same way that the Christen fact type is used. I don't know why there isn't a Baptism (adult) fact type. Perhaps there is a GEDCOM reason. And of course, you could add your own Baptism (adult) fact type, but doing so would do you no good unless at the same time RM also added support for the Baptism fact type to be treated as an infant baptism for the purpose of estimating birth dates. Or perhaps the fact type that should be added and supported for the purpose of estimating birth dates should be called Baptism (infant). I would just reiterate that the exact terminology to be used would need to consider and respect how strong the feelings are about this issue in a wide variety of religious and cultural traditions.

 

Jerry

 



#22 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6147 posts

Posted 20 September 2015 - 10:15 PM

CHR {CHRISTENING}:=
The religious event (not LDS) of baptizing and/or naming a child.
CHRA {ADULT_CHRISTENING}:=
The religious event (not LDS) of baptizing and/or naming an adult person
BAPM {BAPTISM}:=
The event of baptism (not LDS), performed in infancy or later. 
 
from the draft 5.5.1 GEDCOM standard.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#23 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8316 posts

Posted 21 September 2015 - 10:15 AM

I am always curious when this discussion happens how people would expect the program to behave if you let RootsMagic replace the missing birth fact with a christen or baptism fact. What takes priority if the person has both a christen and a baptism fact? Both are actually extremely possible in some religions. Wouldn't we have to again put one in priority over the other. 


Renee
RootsMagic

#24 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3410 posts

Posted 21 September 2015 - 07:04 PM

I am always curious when this discussion happens how people would expect the program to behave if you let RootsMagic replace the missing birth fact with a christen or baptism fact. What takes priority if the person has both a christen and a baptism fact? Both are actually extremely possible in some religions. Wouldn't we have to again put one in priority over the other. 

 

The earlier of the christening date and the baptism dates should be used as the estimate for the birth date if there were no birth date. (And only if the user had enabled an option to take the baptism date into consideration.) It should not be the case the christening takes priority over baptism or vice versa.

 

Jerry



#25 fitz

fitz

    Advanced Member

  • Members
  • PipPipPip
  • 121 posts

Posted 22 September 2015 - 04:01 AM

If I had date for a baptism and a date for birth, I used to have the option of which one to mark as priority.  Have never had occasion to used Christening.  I have found some instances where the date of the birth was recorded as after the date of baptism! 



#26 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 22 September 2015 - 04:49 AM

Say, I have an adult that was baptized at the age of 76, a child baptized at age 16 and an infant baptized shortly after birth in Baptism fact.

Using the Baptism fact in place of the Birth fact as a global option in relation to the adult age 76 and child age 16 would be useless especially if I have other facts with dates before the baptizm date.

The simplest solution are the choices we already have. Add an estimated birth date to the Birth fact and use Christen or Baptism as we choose. Or use Christen for an infant baptism to replace the Birth fact and change the default sentences if needed.

#27 fitz

fitz

    Advanced Member

  • Members
  • PipPipPip
  • 121 posts

Posted 22 September 2015 - 06:06 AM

Yes of course you would put in an estimated birth date if you have other facts.  But I have Catholic baptisms in Ireland that are before Irish registration, 1864, and the person died before the first census, 1901.  Since baptisms usually took place shortly after birth I did not need an estimated birth date as my old program would use baptism.  But in RM I now have blank spaces for date in index for people.



#28 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3410 posts

Posted 22 September 2015 - 10:43 AM

Using the Baptism fact in place of the Birth fact as a global option in relation to the adult age 76 and child age 16 would be useless especially if I have other facts with dates before the baptizm date.

 

The existing RM behavior only uses christening as a birth date estimator when there is no birth date. And when it uses christening as a birth date estimator, it only uses it as a birth date estimator in RM screens, not for reports. The expectation is that if baptism were added as an option for a birth date estimator that it would work the same way, only in the absence of a birth date, only if the user enabled the option, and only in RM screens and not for reports.

 

Jerry



#29 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3359 posts

Posted 22 September 2015 - 12:29 PM

The existing RM behavior only uses christening as a birth date estimator when there is no birth date. And when it uses christening as a birth date estimator, it only uses it as a birth date estimator in RM screens, not for reports. The expectation is that if baptism were added as an option for a birth date estimator that it would work the same way, only in the absence of a birth date, only if the user enabled the option, and only in RM screens and not for reports.

 

 

FTR: I find Jerry perfectly logical in his description of how this should work, after all that is what many users do artificially. As usually the earliest life fact, excepting birth proof, it stems that Baptism or Christening are usually the most accurate estimator for Birth and employing an option covers all angles.


“Your most unhappy customers are your greatest source of learning.” -Bill Gates

 

The great Indian mathematician Aryabhat caclulated the value of pi at 3.1416, ~1500 years ago and without a computer!

 

 

User of Family Historian 6.2.7, Rootsmagic 7.5.9, Family Tree Maker 2014 & Legacy 7.5 (in order of preference)

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#30 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 22 September 2015 - 12:45 PM

The Christen fact is used as a replacement for a missing Birth fact on the Pedigree, Box chart, and timeline chart reports.

Thar is useless misleading information if that was the Baptism fact for a person baptized at age 86 or 16 as the date would not be any where near the person's actual birth date.

At least, for the baptism of an infant, the date is close.

Also, the Christen fact is used to calculate the age for other facts if the Birth date is missing.   If the baptism fact is used as a replacement for a missing birth fact for an adult or older child all the ages for other facts will be off by many years and useless.

I can't see embarrassing myself by sending one of those reports to someone else with that misleading data in it.

I don't want to even mislead myself.

I never really notice whether the date is a Birth date or Christen date on the screens if I am not doing indepth data entry or research.  I just look where the Birth date should be.

If I forgot I had Baptism facts for persons not baptized as infants and chose an option to have the Baptism fact as a replacement for a missing Birth fact, I would be misleading myself and possiblly others if I sent them one of the reports.

And, my ages would be messed up for other facts.
 



#31 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6147 posts

Posted 22 September 2015 - 03:26 PM

I am inclined to agree that there is not adequate justification for making a Baptism(infant) fact type that functions equivalently to the Christen fact type for age calculations and substitute birth date for reports and displays in the absence of a Birth fact. For anyone to convert the normal Baptism fact to Baptism (infant) is as much work as converting it to Christen, to no obvious advantage. Perhaps the real need is a convenient and powerful fact type conversion tool with which the conversion from Baptism to Christen might be made. Or, alternatively, a convenient and powerful tool with which to add the Birth fact with estimated date to those persons having either a Baptism or Christen fact but lacking the Birth fact. The latter is what everyone recommends should be done but it is tedious, if not overwhelming, to do so with the current tools in RootsMagic when there are very many of these cases in the database. Adding a fact to a group of people has been a longstanding enhancement request as has bulk conversion of fact types. This discussion about Birth/Baptism/Christen simply adds justification and scope to those requests.

 

Indicative of the one longstanding request is the SQLite script Facts - Change Fact Type which was an outboard response for a global change to a fact type. Conceivably, it could be extended to change the fact type for only those members in a named group, e.g. created with the criteria:

Birth fact does not exist

AND

Baptism fact does exist

 

The other longstanding request was partly answered with the outboard script Copy Fact to Group. A variant of this could add a fact to a group, e.g., add the Birth fact to the above group instead of changing the Baptism fact, copying the Baptism date and changing it to a Before date or to an Estimated date.

 

Of course there will be exceptions that a batch process may mishandle compared to one at a time and there are limitations in the RootsMagic Group creation process that make it impossible to disallow these exceptions. But a hundred exceptions should be a whole lot less of a challenge to fix than a thousand or 10,000 missing Birth/Christen facts.


Edited by TomH, 22 September 2015 - 03:28 PM.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#32 Don Newcomb

Don Newcomb

    Advanced Member

  • Members
  • PipPipPip
  • 1033 posts

Posted 03 October 2015 - 01:09 PM

I am always curious when this discussion happens how people would expect the program to behave if you let RootsMagic replace the missing birth fact with a christen or baptism fact. What takes priority if the person has both a christen and a baptism fact? Both are actually extremely possible in some religions. Wouldn't we have to again put one in priority over the other. 

 

In the program as I would write it, there would be an Infant Baptism fact, which would imply birth. 



#33 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6147 posts

Posted 03 October 2015 - 01:59 PM

 

In the program as I would write it, there would be an Infant Baptism fact, which would imply birth. 

How would your program map its Infant Baptism, its non-infant Baptism fact, and its Christening facts to/from the GEDCOM standard tags?:

 

CHR {CHRISTENING}:=
The religious event (not LDS) of baptizing and/or naming a child.
CHRA {ADULT_CHRISTENING}:=
The religious event (not LDS) of baptizing and/or naming an adult person
BAPM {BAPTISM}:=
The event of baptism (not LDS), performed in infancy or later. 

 

I think therein lies the problem. If you do not have a 1:1 relationship with GEDCOM, then an export/import process with any other software (and for that matter, drag'n'drop in RootsMagic) is going to result in undesired consequences. This may have to await the adoption of a new interchange standard that does support two or more age ranges for Baptism, i.e., infant and other(s).


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#34 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3442 posts

Posted 03 October 2015 - 02:17 PM

I'd suggest the Christen fact LOSE its use for age-calculations? MANY folks don't even know of that capability and even more do not rely on it.
I bet a lot more folks would be adding a Birth fact with a BEF (or ABT or CA or whatever) and the date of the Christen or infant Baptism.

---
--- "GENEALOGY, n. An account of one's descent from an ancestor who did not particularly care to trace his own." - Ambrose Bierce
--- "The trouble ain't what people don't know, it's what they know that ain't so." - Josh Billings
---Ô¿Ô---
K e V i N


#35 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 03 October 2015 - 04:29 PM

Not all users want to add an estimated birth date if they have a Christen fact.

Suspose I have a Christening date without an eatimated Birth date, and I add a fact or multiple facts which has an age say, census or marriage records.

I could compare the age based on the Christening fact to the age given in the census or marriage  record.

That will at least give me an idea of how reliable the age in the record is.  And, in some cases, it might even clue me in that the Census or marriage fact, etc. is not for that person.



#36 Don Newcomb

Don Newcomb

    Advanced Member

  • Members
  • PipPipPip
  • 1033 posts

Posted 03 October 2015 - 05:07 PM

How would your program map its Infant Baptism, its non-infant Baptism fact, and its Christening facts to/from the GEDCOM standard tags?:

 

CHR {CHRISTENING}:=
The religious event (not LDS) of baptizing and/or naming a child.
CHRA {ADULT_CHRISTENING}:=
The religious event (not LDS) of baptizing and/or naming an adult person
BAPM {BAPTISM}:=
The event of baptism (not LDS), performed in infancy or later. 

 

I think therein lies the problem. If you do not have a 1:1 relationship with GEDCOM, then an export/import process with any other software (and for that matter, drag'n'drop in RootsMagic) is going to result in undesired consequences. This may have to await the adoption of a new interchange standard that does support two or more age ranges for Baptism, i.e., infant and other(s).

 

I think the issue comes down to the innate bias of the people who created the GEDCOM standard. The GEDCOM standard then becomes the justification for propagation of the error. Since GEDCOM is largely obsolete (or at least obsolescent) I'd suggest that this issue be taken up by whomever writes the standards that replace it.