Jump to content


Photo

A Proposal for a Better Way to Manage the Living Flag


  • Please log in to reply
10 replies to this topic

#1 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3777 posts

Posted 01 July 2011 - 08:38 PM

I can't remember when the Living Flag was introduced. I'm thinking it was in something like RM2, but it might have been introduced in one of the latter versions of FO. In any case, users have always had lots of problems with the Living Flag, so by no means are problems with the Living Flag new in RM4.

A prime example of a problems with the Living Flag was discussed earlier today on the E-mail list, and that discussion got me to thinking whether there might be a better way to manage the Living Flag that would cause fewer problems for users. I think I've come up with a fairly simple solution - much simpler than the way the Living Flag works today. I'm going to write it up, and if it stands up to scrutiny I'll re-post this proposed solution to the Wish List in a few days.

First of all, I think it's important to rename the flag. A rose by any other name would smell as sweet, but nevertheless names are important. I think that renaming the flag to be the Privatize Flag makes it more clear what the function of the flag is, and will help to frame our thinking about how the flag should work.

Second of all, let's think in terms of throwing out completely the existing logic for Living Flag and start over from scratch. I think the existing logic is just too flawed to be repaired, and sometimes a fresh start can be the best approach. To that end, let's pretend the logic for the Living Flag didn't exist, and let's pretend we were designing a new feature called the Privatize Flag that would appear in RM4 in December 2011. Here is how I think it should work.

We would need a way for users to populate the new Privatize Flag for every individual in our database. There should be an option accessed as Tools->Privatize to bring up a dialog to set the Privatize Flag. The dialog would not use the Find Dialog with RM Explorer at all. Rather it would work as follows. A dialog box would pop up that would say something like the following.

Privatize everyone in the data base except for
      * Individuals with a Death Fact
                      and
      * Individuals with a Birth fact before _____
The only actual option specified by the user would be the year (not the month/day/year) that would be compared against each Birth Fact. The presence of any Death Fact, no matter when the Death Date, no matter if the Death Date is blank, and no matter how malformed the Death Date might be, would prevent the individual from being privatized. The presence of a Birth Fact with a valid date before the date specified by the user would prevent the individual from being privatized. So a Birth Fact with a blank Birth Date or with a malformed Birth Date would have no impact on the privatize decision. In the case of multiple Birth Facts each with a valid date, only the latest date would be used to make the privatization decision.

The logic would specifically use the Birth Fact and the Death Fact and not the Birth and Death dates from the PersonTable. Absent the use of SQL, users can's see the Birth and Death dates from the PersonTable directly except that the Birth date from the PersonTable is visible in the Index Sidebar. The dates from the Index Sidebar can't be trusted to make privatization decisions, so the dates from the Birth Facts and presence of Death Facts must be used instead to make privatization decisions.

Of course, Tools->Privatize could be run at any time, not just once after installing the new feature were delivered by the RootsMagician.

I'm trying to keep this proposal as simple as possible, but there is one useful complication that I want to add. Namely, all of a given individual's ancestors are known to have been born before the individual. Therefore, if a given individual has a birth date that is early enough that the individual need not be privatized, then the same is true of all the individual's ancestors, no matter what the Birth Facts for the ancestors might say. And sometimes ancestors may not even have Birth Facts, but we still don't want to privatize them when one of their descendants has an early enough Birth Date.

Therefore, the internal logic used to implement Tools->Privatize command should be as follows.

  • Set the Privatize Flag on for every individual in the database.
  • Process every individual in the database a second time as follows
  • If the Privatize Flag is off for an individual, perform no additional processing for the individual. The reason the Privatize Flag would be off at this point in the process would be because one of the individual's descendants has already been encountered who has a birth date early enough not to require privatization.
  • If the Privatize Flag is still on for an individual, turn off the Privatize Flag for the individual if there is a Death Fact for the individual or if the latest valid date from the collection of zero or more Birth Dates for the individual is before the date specified by the user; and turn off the Privatize flag for all direct ancestors of the individual if the latest valid date from the collection of zero or more Birth Dates for the individual is before the date specified by the user.
That's it as far as the logic of Tools->Privatize.

As far as the logic of printing reports, creating Web pages, exporting GEDCOM, etc., the logic would remain exactly as it is now except that the Privatize Flag would be tested instead of the Living Flag and the dialog boxes would be adjusted to reflect the "Privatize" terminology instead of the "Living" terminology.

I'm tempted to stop at this point, and simply declare that users need to do a Tools->Privatize occasionally, and in particular before any report they run. The following logic gets a little more complicated to describe, but it also would probably be useful for RM4 to run a Privatize operation internally and automatically on any individual when that individual is added to the database or edited. To that end, the date specified in the most recent Tools->Privatize for the entire database would need to be saved for the use of the internal and automatic Privatize operation. And in addition, the internal and automatic Privatize operation for an individual would need to process all the direct ancestors of that individual as described above.

Jerry

#2 Ludlow Bay

Ludlow Bay

    Advanced Member

  • Members
  • PipPipPip
  • 868 posts

Posted 01 July 2011 - 11:46 PM


Perhaps I'm missing some fine point, but it seems much simpler to keep the current living check box; then, if the program does not specifically detect the user manually checking (or unchecking) the living check box while the edit screen is open, the program will, upon closing the edit screen, and depending on the current value of the living check box, ask: "do you want to mark this person as living?" or "do you want to mark this person as deceased?"

A better system of query and reporting is still needed, however.

#3 landbrake

landbrake

    Advanced Member

  • Members
  • PipPipPip
  • 341 posts

Posted 02 July 2011 - 07:36 AM

Privatize everyone in the data base except for
* Individuals with a Death Fact
and
* Individuals with a Birth fact before _____


Jerry,

One simplification to your logic that I might suggest: instead of triggering on "Birth" fact before ______, why not trigger on any fact before that year? Since birth would (presumably) be the earliest specified fact for any person, any later fact specified would apply in the same way (i.e. if someone born before 1900 is too old to worry about being privatized then someone baptized before 1900, or married, or worked at a job, or whatever, would even more so be too old to worry about). This would then cover those individuals with no birth fact (many, in most genealogies) but who do have at least some dated information.

A slight variation on your proposal would be to "un-privatize" every individual with any fact older than a certain number of years, rather than a specific date. That way you wouldn't have to change the specified year periodically, and it would make it easier for this logic to be included to run automatically in RM. So, for example, if you specify 100 years as the "statute of limitations" on being privatized, then the first time you open your database after January 1, 2012, RM could automatically un-privatize everyone with any dated fact prior to 1912 (who had not already been thusly marked).

And finally, one small addition: there should probably remain a manual override for the "privatize" flag. There could easily be instances where (for example) someone is already dead, but their immediate family is still living, and there are enough sensitive issues surrounding the deceased person that the family would rather the person him/herself remain private, rather than only specific facts.

Just my two cents worth!

#4 Brenda Hare

Brenda Hare

    Advanced Member

  • Members
  • PipPipPip
  • 92 posts

Posted 02 July 2011 - 08:08 AM

A prime example of a problems with the Living Flag was discussed earlier today on the E-mail list.....


Is there an email list we can sign up for, so we would get emails directly to us?

Thank you,
Brenda

#5 Nettie

Nettie

    Advanced Member

  • Members
  • PipPipPip
  • 1680 posts

Posted 02 July 2011 - 09:39 AM

Is there an email list we can sign up for, so we would get emails directly to us?

Thank you,
Brenda


Go to RootsMagic.com and look for the page to signup or go to Rootsweb.com and look at the email lists for it. At least it used to be on Rootsweb.com

Flags are all in my notes field from early FO time frame and right now a nuisance. :o I have been deleting them when I find them. Many times more than one copy per person. Personally I do not see a valid functional reason for have a Flag of any sort. I used to use them to id a military or medical doctor, now we have the facts that work with those choices.

My 2 cents worth. :)

Genealogy:
"I work on genealogy only on days that end in "Y"." [Grin!!!]
from www.GenealogyDaily.com.
"Documentation....The hardest part of genealogy"
"Genealogy is like Hide & Seek: They Hide & I Seek!"
" Genealogists: People helping people.....that's what it's all about!"
from http://www.rootsweb....nry/gentags.htm
Using FO and RM since FO2.0 


#6 Renee Zamora

Renee Zamora

    Advanced Member

  • Admin
  • PipPipPip
  • 8622 posts

Posted 05 July 2011 - 11:49 AM

I solved my issue with the living flag by giving everyone in my database an estimated birth date, if no death date is known. I use genealogical standards for estimating the date. Cite myself as the source and what the estimate was based on (person & date).
Renee
RootsMagic

#7 Alfred

Alfred

    Advanced Member

  • Members
  • PipPipPip
  • 5734 posts

Posted 05 July 2011 - 02:28 PM

You could give them a death fact, no date or place and it would toggle the living flag.
I like the estimated birth date better, as long as it is made clear that it is an estimate with the "est" prefix. (like "est 1860" or something)
It helps to establish some sort of a timeline.
Alfred

#8 Nettie

Nettie

    Advanced Member

  • Members
  • PipPipPip
  • 1680 posts

Posted 05 July 2011 - 06:18 PM

You could give them a death fact, no date or place and it would toggle the living flag.
I like the estimated birth date better, as long as it is made clear that it is an estimate with the "est" prefix. (like "est 1860" or something)
It helps to establish some sort of a timeline.


If I have a census record, I use abt or probably before the possible year. I also have used the 'calcuated' before a year and then state in the note field, that this date was calculated form a source, whether primary or secondary.

Genealogy:
"I work on genealogy only on days that end in "Y"." [Grin!!!]
from www.GenealogyDaily.com.
"Documentation....The hardest part of genealogy"
"Genealogy is like Hide & Seek: They Hide & I Seek!"
" Genealogists: People helping people.....that's what it's all about!"
from http://www.rootsweb....nry/gentags.htm
Using FO and RM since FO2.0 


#9 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3777 posts

Posted 06 July 2011 - 10:00 PM

I think I've come up with a fairly simple solution - much simpler than the way the Living Flag works today.


Both TomH and I have written SQL scripts to set the Living Flag more or less as described in my proposal, using SQLite to update the RM4 database directly and without using the RM4 program. I really intend the SQL script as a proof of concept, although I have actually run it successfully against my database. Here is the process I have implemented.

  • Turn on the Living Flag for everybody in the database. This has the effect of privatizing everybody to start with.
  • Turn off the Living Flag for everybody in the database who was born before 1906. 1906 was an arbitrary, but conservative choice. Tom's version of the script checks for every fact date, not just the birth fact date. I'll soon be making that improvement in my version of the script. MY SCRIPT DOES NOT TURN OFF THE LIVING FLAG FOR INDIVIDUALS WITH A DEATH FACT JUST YET. DOING SO MUST BE DEFERRED UNTIL STEP #4. Well, it's ok to run off the Living Flag for a death date before 1906 at this point in the process - based on the death date, but it's not yet ok to do so simply because of the presence of the death fact without regard to the death date.
  • Turn off the Living Flag for the parents of everybody in the database whose Living Flag is off. In other words, if an individual was born before 1906, then so too were their parents, even if their parents do not have a birth fact. Turn off the Living Flag for all ancestors of individuals born before 1906 by repeating this step until it does not turn off any more Living Flags.
  • Turn off the Living Flag for any remaining individuals who have a Death Fact, irrespective of their data of death. If this action is not deferred until step #4, then step #3 will not work correctly because the death of an individual, for example in 2007, is not alone sufficient evidence that the parents of the individual are also deceased.
Since this procedure is relatively easy to run from SQLite and is not very many lines of SQL code, it ought to be fairly straightforward for the RM4 development team to include such a procedure that could be run from within RM4 itself.

Jerry

#10 Ludlow Bay

Ludlow Bay

    Advanced Member

  • Members
  • PipPipPip
  • 868 posts

Posted 06 July 2011 - 10:29 PM

[*]Turn off the Living Flag for any remaining individuals who have a Death Fact ...


Even if that is a "blank" death fact, with no death date? What about those with an invalid death date?

#11 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3777 posts

Posted 07 July 2011 - 01:26 PM

Even if that is a "blank" death fact, with no death date? What about those with an invalid death date?

Yes, that's the way I wrote the SQL, on the theory that a death fact is a death fact is a death fact. Obviously, it might depend on exactly how you manage your particular database, for example if you know a person is deceased but you don't know when, etc., how do you reflect that in in your database. The SQL could easily be written to check for these conditions if you so preferred.

Also, some people might well prefer to privatize individuals who have died recently, say in the last five years or so. If so, the logic would need to look at the death date, not just at the existence of a death fact. This is another argument for calling it the "Privatize Flag" rather than the "Living Flag". Again, the SQL could easily be written to take this condition into account.

Jerry