Jump to content


Photo

Registration Date


  • Please log in to reply
23 replies to this topic

#1 allan1932

allan1932

    Advanced Member

  • Members
  • PipPipPip
  • 37 posts

Posted 31 August 2016 - 03:58 AM

Is there justification for registration dates of birhs, marriages, & deaths to be added to the Facts list, bearing in mind that they may differ from the actual dates of the events? I just wonder what the general opinion is.



#2 zhangrau

zhangrau

    Advanced Member

  • Members
  • PipPipPip
  • 1520 posts

Posted 31 August 2016 - 04:47 AM

I try to record the "best available" info for BMD facts, with sources linked for documentation. When all I have is a birth registration indicating a 3-month span, for instance "Jul-Sep 1913", I usually record something like "before Sep 1913". Then I continue to look for more data. Not surprisingly, I am researching many people who appear in birth, baptism, confirmation, marriage, census,military, and death records and indices = and those records may often vary in their specificity (does it include year, month and day? or not?) and accuracy (I've seen the year of birth vary on multiple records). In genealogy, we must go with the preponderance of evidence - if I have questions about the veracity of what I have recorded, I just keep looking....



#3 allan1932

allan1932

    Advanced Member

  • Members
  • PipPipPip
  • 37 posts

Posted 31 August 2016 - 04:58 AM

I try to record the "best available" info for BMD facts, with sources linked for documentation. When all I have is a birth registration indicating a 3-month span, for instance "Jul-Sep 1913", I usually record something like "before Sep 1913". Then I continue to look for more data. Not surprisingly, I am researching many people who appear in birth, baptism, confirmation, marriage, census,military, and death records and indices = and those records may often vary in their specificity (does it include year, month and day? or not?) and accuracy (I've seen the year of birth vary on multiple records). In genealogy, we must go with the preponderance of evidence - if I have questions about the veracity of what I have recorded, I just keep looking....

Would you like separate RootsMagic Facts for, for instance, Birth & Birth Registration, so that the Dates & Sources can be inserted accordingly?



#4 zhangrau

zhangrau

    Advanced Member

  • Members
  • PipPipPip
  • 1520 posts

Posted 31 August 2016 - 06:11 AM

No, I wouldn't use separate facts. I don't have many UK-born individuals in my database, and maybe if I had a lot more I would think differently. But, then, I don't record a Delayed Record of Birth separately, either. It all goes into the birth fact, since that's what I'm documenting. I almost always have explanatory notations in the Birth Fact Note, which will print in reports, to elaborate on what I've learned.



#5 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3608 posts

Posted 31 August 2016 - 06:38 AM

There are differing opinions on entering separate events into RM when there is conflicting data about dates. Consider, for example, just plain old dates, let alone registration dates. In the case of multiple and conflicting dates for the same event, some users prefer to enter the data into RM as multiple events such as multiple birth events - one event in RM for each conflicting date. Others prefer to enter the data into RM as a single event with the event date being the best estimate for the date and with the alternate dates documented and explained as notes. I prefer the "single event plus notes" approach, but I'm not sure that there is a written standard anywhere that supports the way I do it.

 

I think that entering dates such as "third quarter 1913" is a separate issue from whether to enter multiple date events because "third quarter 1913" might the only data point you have. If it's the only data point you have, my preference would be to enter it as something like "third quarter 1913" or "3Q 1913". But my recollection from previous discussions on these forums is that RM doesn't handle such dates very well. I could be wrong, and I'm sure other user will chime in about such dates. RM would support a date such as "between 1 Jul 1913 and 30 Sep 1913", but that is not what you really want. I don't have any registration dates in my database, so I don't have any direct experience with them.

 

Jerry



#6 allan1932

allan1932

    Advanced Member

  • Members
  • PipPipPip
  • 37 posts

Posted 31 August 2016 - 06:42 AM

There are differing opinions on entering separate events into RM when there is conflicting data about dates. Consider, for example, just plain old dates, let alone registration dates. In the case of multiple and conflicting dates for the same event, some users prefer to enter the data into RM as multiple events such as multiple birth events - one event in RM for each conflicting date. Others prefer to enter the data into RM as a single event with the event date being the best estimate for the date and with the alternate dates documented and explained as notes. I prefer the "single event plus notes" approach, but I'm not sure that there is a written standard anywhere that supports the way I do it.

 

I think that entering dates such as "third quarter 1913" is a separate issue from whether to enter multiple date events because "third quarter 1913" might the only data point you have. If it's the only data point you have, my preference would be to enter it as something like "third quarter 1913" or "3Q 1913". But my recollection from previous discussions on these forums is that RM doesn't handle such dates very well. I could be wrong, and I'm sure other user will chime in about such dates. RM would support a date such as "between 1 Jul 1913 and 30 Sep 1913", but that is not what you really want. I don't have any registration dates in my database, so I don't have any direct experience with them.

 

Jerry

Birth Date & Birth Registration Date are not conflicting dates.



#7 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 213 posts

Posted 31 August 2016 - 07:16 AM

My personal opinion is guided by the GEDCOM standard. GEDCOM allows for multiple BIRT(birth) facts, each with a single date, place, and some other attributes, as well as multiple source, note and media tags.

I see our databases as a place to collect data, helping us to develope a conclusion with the greatest of accuracy and certainty.

While collecting data and Since each birth fact (or any fact or attribute) can have only one date and place, I create multiple fact entries for each event type whenever a date or place is in conflict with another fact entry of the same type. When a new source of information becomes available that corroborates an already entered fact I add that source to the fact instance already entered, or when it disputes the entered fact instance I create a new instance.

In GEDCOM the first instance of the fact type found is considered the most likely or most preferred. The GEDCOM standard states: "The most preferred value being the first with the least preferred data listed in subsequent lines by order of decreasing preference." Thus any report should have an option to only print the "most preferred" when duplicate facts are found or print all facts.

At some point as I move from data collection to conclusion I remove duplicate entries and turn them into supplementary notes from the "most preferred" fact instance. Thus retaining the data. I also make a point to move the lower quality source material from those less preferred instances to the preferred one marking the source with a quality "QUAL" of 0 to indicate that the source is in question or "Unreliable evidence or estimated data".

#8 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 213 posts

Posted 31 August 2016 - 07:20 AM

Dates are also guided by GEDCOM. I use the "BEFore" notation when I find sources that state a person was alive by a certain date, or already dead. If you require a birth date but only have a baptism, the birth can be date "BEFore" the baptism date.

#9 allan1932

allan1932

    Advanced Member

  • Members
  • PipPipPip
  • 37 posts

Posted 31 August 2016 - 08:08 AM

I can only reiterate that Birth Date & Birth Registration Date are TWO separate Facts.



#10 zhangrau

zhangrau

    Advanced Member

  • Members
  • PipPipPip
  • 1520 posts

Posted 31 August 2016 - 09:54 AM

Perhaps, but they refer to the same life event.

 

Both methods of recording (one RM fact or two RM facts) can be considered valid.

 

Each researcher needs to decide how they want reports, etc. to handle the info; as well as whether it may later be desirable to be able to search for those types of info separately, and there are probably other considerations....



#11 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8490 posts

Posted 31 August 2016 - 10:39 AM

I use the birth registration date in my source citation for the birth fact. I can't really see any reason why I would want another fact called birth registration. Same with any other registration date for a fact in their life.


Renee
RootsMagic

#12 allan1932

allan1932

    Advanced Member

  • Members
  • PipPipPip
  • 37 posts

Posted 31 August 2016 - 03:10 PM

Perhaps, but they refer to the same life event.

 

Both methods of recording (one RM fact or two RM facts) can be considered valid.

 

Each researcher needs to decide how they want reports, etc. to handle the info; as well as whether it may later be desirable to be able to search for those types of info separately, and there are probably other considerations....

As you point out, I like to be able to list those in my tree for whom I have a birth registration date but not a birth date. Also, in a few instances, there is a considerable period between the two.

The consensus appears to be that there is no need for RootsMagic Facts for Registrations so I'll create my own Fact Types. Thank you all for your responses.



#13 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 213 posts

Posted 31 August 2016 - 05:38 PM

Sorry for entering this later in the day, work prevents me from updating until work is done.

Yes I agree with Renee. A birth registration is a source document that would be cited on a birth fact. Many data sources including, but not limited to:

Church events that happen at specific ages, baptism, confirmation
Government events that happen at specific ages, like draft registration, voter registration, school enrollment, census

All of these documents can be used to establish an approximate birth date, probably only the year, and until you get additional and more accurate birth information the date would be entered as "EST".

Some sources will say that a person was, for example, the middle child of three, (or give an age of the children at the time of documentation) and you have good evidence of the birth date of the first and third child so you can cite that document and say the birth was BET the first child's birth date AND the third child's birth date.

#14 Trebor22

Trebor22

    Advanced Member

  • Members
  • PipPipPip
  • 192 posts

Posted 02 September 2016 - 02:53 AM

I have found a couple of cases where the registration of a birth was a long time after the actual birth, I have a marriage that is registered a year after the event and a birth where there are 2 register entries several years apart - the 2nd being a correction,  in these cases I think its essential to include the register entry(s) but I tend to include it anyway where I have it, I also note similar entries that are not related to the correct person where it might be helpful.



#15 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3434 posts

Posted 02 September 2016 - 07:33 AM

When all I have is a birth registration indicating a 3-month span, for instance "Jul-Sep 1913", I usually record something like "before Sep 1913".

 

zhangrau, I also did this using the BET approximation but since the acceptance of quarterly dates I would now record this as Q3 1913, apart from anything else it helps me distinguish at a glance that is a registration date rather than some other approximation. Sadly RM does not yet allow users to search on Date containing a particular date approximation like Q, abt, bef, bet etc, maybe version 8 ;)

 

For the OP, I do record the registration date in the source similar to what Renee seems to do, it's another piece of information which deserves recording but I don't believe warranting a custom fact unless you are wanting to compile particular statistical data. As I stated above I record quarterly dates for vitals until the exact date is found, this is not technically correct as before proving this is only the Registration date, but close enough and easily recognizable.


Customers should never be frustrated by things they cannot do.

 

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

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#16 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3459 posts

Posted 02 September 2016 - 10:00 AM

Sadly RM does not yet allow users to search on Date containing a particular date approximation like Q, abt, bef, bet etc, maybe version 8 ;)


My test of this shows that RootsMagic's [Any fact date contains] ...searches for and finds individuals with all of these (abbreviations and whole words ie. Q or Quarter, abt or about) ETC.

---
--- "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


#17 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3434 posts

Posted 02 September 2016 - 02:53 PM

My test of this shows that RootsMagic's [Any fact date contains] ...searches for and finds individuals with all of these (abbreviations and whole words ie. Q or Quarter, abt or about) ETC.

 

I was willing to believe that I was at stage 1 or 2 of losing it but I must have been primarily searching for the "abt" approximation that being closest to being qualified.

 

Despite what Kevin stated searching for Any Fact Date Contains "abt" does not work, whereas "about" does. Bet, Bef, Aft abbreviations all work so the nonsequential character arrangement of "abt" is not catered for despite that being the Rootsmagic abbreviation for "about" and what is displayed.


Customers should never be frustrated by things they cannot do.

 

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

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#18 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3459 posts

Posted 02 September 2016 - 03:38 PM

Despite what Kevin stated searching for Any Fact Date Contains "abt" does not work, whereas "about" does. Bet, Bef, Aft abbreviations all work so the nonsequential character arrangement of "abt" is not catered for despite that being the Rootsmagic abbreviation for "about" and what is displayed.


Alright, I admit I didn't check them all (abt being one). After checking q , bef, aft, and bet (along with their full word counterparts) I ended with about (not abt) and mistakenly typed about and abt as part of my examples given. Small bug but I was trying to unbesmirch RM from Vyger's condemnation and did so pretty much ;-)

---
--- "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


#19 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3434 posts

Posted 02 September 2016 - 05:09 PM

Alright, I admit I didn't check them all (abt being one). After checking q , bef, aft, and bet (along with their full word counterparts) I ended with about (not abt) and mistakenly typed about and abt as part of my examples given. Small bug but I was trying to unbesmirch RM from Vyger's condemnation and did so pretty much ;-)

 

Besmirch is an interesting word and I don't believe applicable in this case, I prefer development and bug identification albeit based on a limited test set but at least I am not unique in making statements based on limited testing :D


Customers should never be frustrated by things they cannot do.

 

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

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#20 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3459 posts

Posted 02 September 2016 - 05:35 PM

Besmirch is an interesting word and I don't believe applicable in this case,


I attributed condemn(ation) to you and besmirch(ment) is what I feel can occur when someone reads things like your statement above ~ I stick by them both.

---
--- "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