- RootsMagic Forums
- → leeirons's Content
There have been 68 items by leeirons (Search limited from 21-January 19)
If they are asking for a new capability, then they must have a reasonable purpose for it. Please treat people like they do. Just because you might not do things the way they do things does not make you right and them wrong.
If you think you have an idea for how existing program functionality could help them accomplish the same thing, then send them a private message, so that you don't risk highjacking their thread and appearing to be rude.
The database design has your AKA value stored quite differently than the names of persons in your database. The AKA in this case belongs to the fact, not to the person. To use it in ways you can use person names requires significant programming and, probably, database redesign.
I don't think this is the issue. This does work for sentence templates of persons with the role of Principal. It just does not work for persons with a witness role. The program does not even allow the name of a witness who actually is in the database to be used in the sentence template of another witness. The Help article on sentence templates does not say that this is a limit. It implies that you can put the name of any witness in any fact sentence template using [Role] or [Role(#)].
And other family facts and notes?
Would the marriage, other family facts and notes be printed for each spouse or the first spouse printed?
I think a Timeline oriented report would be much too confusing. I prefer the narrative report as it is.
I asked for an option checkbox. That means people can use the original report (that you are now on the record as liking) or they can choose to have a report that is generated in a sequence according to the sort date. The latter choice would exclude spouses from the report, so there would not be any issue associated with family facts being listed twice (once under the timeline and once under the spouse). Keep in mind, "standard" descendency narrative reports do not include spouses, since spouses, by definition are not descendents of the person listed as the first person in the report.
Also keep in mind that some people use sort dates to interleave "analysis" facts (user-defined) with event facts in order to create a narrative that makes claims, uses event data to support such claims, and provides analysis of such data in a thesis-style approach.
So my request stands.
I would like to be able to create a narrative report that uses the fact sequence by sort date, so that I can control the narrative completely.
Please provide this capability as an option for the narrative report. You could add a checkbox capability to the Book Options window of the Narrtive Report Settings that is labeled:
"List facts by sequence of sort date. Spouses will not be listed."
This works when the person is a Principal to a Fact.
However, when the person who has the AKA name is not a Principal to the Fact, this is not working. I can't reference the name of one witness in another witness's sentence template. For example, when I add a person to a Fact with a role of "Witness01" and I link this person's AKA name to this same fact with a role of "AKAWitness01", I can't seem to get the variable [AKAWitness01] to work in the "Witness01" sentence template.
I'm not sure whether this is a glitch, a capability that was missed when originally programming the sentence template capabilities, or simply a capability that was purposefully not programmed. I'm guessing one of the first two, for I can't imagine purposfully not enabling one witness sentence template to use the names of other witnesses attached to the same fact. For example, this capability would allow a narrative report for John Smith to have a sentence such as, "John Smith witnessed the marriage of Josiah Miller and Edith Applegate, along with Adam Decker and William Bell."
Renee, could you look into whether this is a glitch, a capability that was missed when originally programming the sentence template capabilities, or simply a capability that was purposefully not programmed?
Yes, other tools are out there that can help. However, the whole idea of being able to do everything in the same software is so that you only have to enter data once in the genealogy software, and then have the genealogy software use that data to do things like map out a road-trip, as Randy requested.
One of the things I am doing at my day job is helping our company transition to a new PLM software suite. One of the things we are trying to accomplish is having all of the functionality that we currently have spread out among a number of different Access Databases and Excel spreadsheets built in to the PLM software, so that all of the data is logically linked to the product structure of the product our company makes. Suffice to say it is one of the largest products in the world. By doing this, we will eliminate lots of duplicate data entry that we used to do in multiple databases and software tools in order for everyone in the company to do their various jobs.
The same principals apply, whether we are talking PLM tools or genealogy tools.
The Alternate name is still a fact which can be listed or not listed by user choice on the name lists and People view in RM. You can get a report for that fact and it exports and imports as a fact.
If RM allowed a fact field to be used in the sentence structure, just how is RM to choose which of the multiple Alternate name facts for that person to print in the sentence. With some women, I have more than one married surname with an Alternate name fact for each married name for some people I have more than one nickname or spellings.
Does Master Genealogist have fields to enable other facts besides the Alternate name fact to be used in their sentences?
I think that the use of Alternate Name Facts do not make that data very useful to me in generating report narratives or in associating those names with actual events, which actually makes the name more meaningful. Alternate (AKA) names have two uses that I can see. The first use is in deriving the complete name of a person. The researcher uses all known alternate (AKA) names to compile a complete name. In this use, these alternate names are coming from source citations, and these source citations should be tied to the Person Fact (open the Edit Person view and click on Person) with each alternate name identified in the Detail Text of each source citation. The second use is in report narratives, in which the person is referred to using the name by which they were known at a given event according to the source citation linked to the Event Fact. For each of these uses, sequestering alternate (aka) names in separate Alternate Name Facts do not help us.
For the second use, I am proposing that the AKA Name would be a separate field in an Event Fact (as opposed to a Person Fact or a Vital Fact) on the right side pane of the Edit Person view. For a family-type Event Fact, there would be two AKA Name fields, one for the husband and one for the wife. For a personal-type Event Fact, there would be just one AKA Name field. For each person that is linked to a shared fact, the Edit Shared Event window for the person would have an AKA Name field. Yes, The Master Genealogist has something like this, but it only allows you to select names from separate AKA facts already listed under the person and the sentence variable for AKA name only pulls the AKA name from the "preferred" AKA Name Fact. What I am proposing is that the AKA Name be entered directly in the field that is in the fact pane and that a sentence for an Event Fact be able to pull the AKA Name variable from that field. I am saying that there is no need to try to pull an AKA Name from a separate AKA Fact to be used in a sentence for an Event Fact, because the AKA Name associated with that Event Fact would come from the single source citation that is linked to that Event Fact.
The Master Genealogist does have the most extensive sentence variable list I have seen in any genealogy program. It also allows the user to parse the Notes field and use different parsed sections of the Notes field in a sentence. However, to me, this latter capability just proves that it has not yet figured out all of the fields that should be in an Event Fact, just like Roots Magic has not yet figured that out.
In an advanced capability maturity model of sentence functionality in genealogy software, the most advanced genealogy software would be able to generate the following sentence by simply pulling data from fields rather than the user having to type a customized sentence for every person in their database,
"John Adam Smith, who would have been age 38, went by the name Adam Smith and was the head of household in a census listing on 23 Oct 1880 in Toms River, Ocean, New Jersey, USA. He was listed as being age 37 and was a farmer.""John Adam Smith" would come from the Person Fact as the complete name that this person is believed to have based upon all name source citations. "Age 38" would be calculated based upon the date of this census Event Fact and the date entered in the birth Vital Fact. "Adam Smith" would be entered in the AKA Name field for this person in the Event Fact. "Head of household" would be entered in the Role field for this person in this Event Fact (yes, even the primary person of a fact would have a selectable role). "23 Oct 1880" would come from the Date field for the Event Fact. "Toms River, Ocean, New Jersey, USA" would come from the Place Name field of the Event Fact. The pronoun "he" would be derived from the Sex field of the Person Fact. "Age 37" would be pulled from an Age field for this person in this Event Fact. "Farmer" would be pulled from the Occupation field for this person in this Event Fact.
So, you can see, we can go beyond just dealing with the AKA Name in the Event Fact, but I am simply asking for the AKA Name for now.
If you have just one branch extending past 32 generations, there is a partial solution.
Do one report for exactly 32 generations. Then start over with another report with the ending person from the first report as the starting person for the second report. The numbers would start over.
The real solution would be double precision arithmetic going to 64 generations. But then someone would ask for 100 generations.
The real solution is using the 32 bits in a different way to calculate the numbers in the report. After all, 2147483647 is the largest integer in a 32-bit system. The programmer just needs to think outside the box. Might require some major reprogramming.
Google has 2 Google Map lab features that you can enable or disable for online Google Map.
On Bing, edit the place in My Place and the latitude and longitude shows in the edit screen.
Google Labs closed in October of 2011. I tried what you said in Google Maps, and it does not work, which means Google did not transition it into Google Maps. If you have figured out specifically how to make it work, please clarify
I am looking at My Places in Bing Maps right now (logged in under my Windows Live account), and I do not see Lat and Long in the edit screen of any of my pinned locations. Perhaps it only makes Lat and Long available for places that Bing Map search recognizes, and not just any pinned location selected by a user.
At any rate, Randy's request still stands on its own merits.
Folks, we need to get beyond the "primary fact" paradigm. Giving every source of every vital event its own fact makes the person much too cluttered and does not allow the user to provide a comparative analysis of the multiple sources that can feed into a vital event (birth, marriage, death). Identifying one such fact for a vital event as primary assumes that it is even possible to use only a single source to come up with all information for a given fact. This is rarely the case. Primary facts are an archaism of the genealogy software of two decades ago and should be left in the past.
There are two different and better ways to handle this with the Roots Magic 5 as it currently stands:
1. The Vital Fact: Using the birth life event as an example, each person has only one birth. All possible source citations of birth information can be tied to a single birth Vital Fact, with each source citation being given its own Quality rating relative to the birth Vital Fact, with the Comments field on the Source Detail tab being used to provide you analysis and opinion as to how you are interpreting the source of the information to obtain information on the fact. You can also use the Notes button associated with each Vital Fact to provide your overall analysis and conclusion on the fact based upon all sources together. Finally, you can use the Proof field to flag whether you have sufficient source citations of sufficient quality to say that you have proven the Vital Fact.
2. The Event Fact: If you still wish to have one source citation per fact, then treat each source as an event in that person's life and document the fact as an event. Then, have only one Vital Fact per vital life event that uses direct and indirect evidence from all of the Event Facts tied to the person. For example, a census source can be tied to a person as a census Event Fact. Then, the information in a census Event Fact that says a person was age 13 in 1850 would allow you to state in the Notes field of the birth Vital Fact that the 1850 census event leads you to believe that the person was born in 1836 or 1837. Any other events that give other direct or indirect evidence on vital life events would also be analyzed in the Notes field of the associated Vital Fact.
Using either of the above approaches, each person would have only one Vital Fact for each major life event (one Vital Fact for one birth per person, one Vital Fact for each marriage of a person, and one Vital Fact for one death per person).
Now, regarding AKA Names ...
The Person Fact: If you are using option 1 above, then you would take the same approach with the Person Fact. If you open the Edit Person view and click on Person, it shows you fields for Given Name, Surname, Prefix, Suffix, and Nickname. It also has a Notes field and the ability to tie multiple sources to it. The Given Names and Surname fields should contain only the final conclusion of the totality of a person's name based upon all sources tied to that Person fact, just like there should only be one birth fact. Each source that is tied to the Person fact identifies that person by some name. This name usually is not the full name. Anything that is not the full name is, by definition, an AKA name, which can be typed in the Detail Text of the Source Citation.
So far, everything I have discussed above can be done with current functionality of Roots Magic 5.
Now comes my wishlist item. For those who use option 2 above, I would like to propose a better way of associating AKA Names with a person. Using the option 2 approach, there is one source citation per Event Fact. That source refers to each person linked to that Event Fact by a name, which is an AKA name for that Event Fact. Thus, each Event Fact (as opposed to a Person Fact or a Vital Fact) should have an AKA Name field in it for each person linked to the Event Fact. For a family-type Event Fact, there should be Husband AKA Name and Wife AKA Name fields in the fact pane on the right of the Edit Person view. For each personal-type Event Fact, there should be just one AKA Name field in the fact pane on the right. For shared Event Facts (both family-type and personal-type), each person with which an Event Fact is shared should have an AKA Name field in the Edit Shared Event window of the person. To top this off, there should be a code to add the AKA Name from the proper AKA Name field to a sentence template for a role of a fact. Thus, role sentences could be customized to refer to the person by their AKA Name and their complete Person Fact name in a narrative report of the given Event Fact, which is really cool.
The Master Genealogist version 8 comes close to doing my recommendation above, but it does not enable the use of the selected AKA Name in a sentence template for a person linked to the Event Fact. If Roots Magic were to do this, it would be one step ahead of The Master Genealogist.
Family Tree Maker 2012 allows users to define a location and place a pin on a Bing Map that automatically populates Lat and Long fields with the coordinates of where the pin was placed, enabling users to get Lat and Long coordinates for cemeteries and other "non-addressed" locations. This also enables the user to pin the old (no longer used) name of a location to a modern map. I have been using Family Tree Maker 2012 to get the coordinates and enter them into the Lat and Long fields for my Place Details. Hopefully RM6 will have a better mapping and pinning feature and include Randy's suggestion of mapping out a road trip. This would put Roots Magic a step ahead of the competing software.
"Academic" would put too fine an approbation on the exercise; "fun" is appropriate.
I would argue for academic. There is no fun in adding 47 generations to your own personal database just because "I found it on the internet, so it must be true." The fun part of this is the academic exercise of finding evidence to support the claim and publishing the evidence in such a way that other people can understand your explanation and either present counter evidence or supporting evidence. It is detective work, and your genealogical peers are the jury. And all of this fun begins pretty much around the Renaissance for the vast majority of ancestral lines for the vast majority of people.
Don might have a good point. How many of us have access to actual records before the year 1500 such that we could do such academic (detective) work. Those who do probably don't use Roots Magic.
However, Tom has a good point in that there is no reason why there should of 32 generations to an automated publication.
Example. In 1840, Ocean County, New Jersey did not exist. However, Ocean City, Monmouth County, New Jersey did exist. So when I type in Ocean, New Jersey, USA, intending it to be Ocean County, and I provide a date of 1840 (before Ocean County existed), County Checker assumes I mean Ocean, Monmouth, New Jersey, USA, and allows it. I confirmed this to be the case. When I use a leading comma and type ", Ocean, New Jersey, USA" in the Place field and "1840" in the date field, County Checker catches the error. But when I type "Ocean, New Jersey, USA" in the Place field and "1840" in the Date field, County Checker allows it.
I also noticed that if I enter ", Ocean, New Jersey, USA" to force the County Checker to assume that Ocean is a county, the County Checker corrects me by insisting that the leading comma be removed. This sets me up for again incorrectly using "Ocean, New Jersey, USA" with a date prior to its founding in another fact.
I also notice that a family group sheet does not show the selected family in either the options window for the family group sheet or in the title of the family group sheet in the Chapters list. This might not be a bug, but the name of the selected individual shows in other report titles or options windows, so it would be helpful for this to also happen for family group sheets.
In todays internet generation the availability of information is greater than it ever has been making the need for more powerful and productive merge utilities more important than ever. I do hope that sometime in the not too distant future some genealogy software supplier produces some much needed utilities to help in this more and more time consuming task. I would prefer it to be Rootsmagic as they are half way there but utilities to manage larger and larger databases and Place Lists is now very much needed from software vendors.
Legacy Family Tree has a really powerful side-by-side merge utility. A person could use it to merge GEDCOMs, and then import the resulting GEDCOM into RM.
Basically, all three of the top software packages (RM, LFT, and FTM) have unique strengths and all have weaknesses. I basically use all three now for different things. Would love to just use one.
Renee is right that this is a little nightmarish. I know because I spent many an hour working up a batch solution in SQLite. FWIW, and to inspire Bruce et al, here it is, warts and all.A user-interactive solution providing greater control over the merge parameters, manual decision making, etc. would require higher-level programming. But for anyone curious to try it on a spare copy of their database, especially one imported from Legacy Family Tree and maybe Family Tree Maker, have a look, test it out and see if it does anything worthwhile for you. On Lee's sample database, some 3200 events were eliminated and replaced by sharing common events, with a corresponding reduction in citations.
Thanks Tom! Fantastic job! Not sure whether a Family Tree Maker file converted into RM5 would produce a bunch of duplicated events that look like my Legacy Family Tree file looked. If so, though, your code should work.
Renee, Just to clarify, because this thread has wandered off-topic a couple of times. The enhancement request that initiated this thread is to move the Family Facts from being listed with the father's individual facts to being listed under its own heading either between the father and mother or after the mother. A related request for the role notes that are printed on Family Group Sheets is to list the Description field of a shared fact inside the parentheses with the Date field to the riught of the role in teh role note, thus making it visually apparent regarding which role notes go with which shared fact notes.
Confirming enhancement request is in our tracking system. Until it is implemented you could always name the father "Unknown" and he will show up on the FGS with the family facts linked to him.
Alfred, this thread was regarding my request.
I have at least one woman in my database who had a child out of wedlock.
I have no idea who the father is, she never said, so it is blank but the child information is filled in.
The Family group sheet shows a blank father area, there is no family information so none is listed but the mother and child areas are filled in.
I don't need an Unknown name for the father.
Even if the two pdeigree publications agreed, it would still be unproven until YOU have sources from which you glean evidence that enables an analysis that leads to a conclusion, with all four documented in your own database and subsequent publications of your data.
So, I agree with Tom, without more information about the source(s) each genealogy was based upon I'd feel it was case unproved and want to check the evidence.
I know you mean well, Nettie, but Don is asking for a solution in Roots Magic that would help him with this. Trying to keep track of things in two or three or ten different places (RM research log, RM to-do list, scratch paper, spiral bound notebook, and an ancient written list of helpful things to remember) is what causes people to miss/forget things. In an ideal world, everything a researcher needs would be at their fingertips through a single software program. We are not in an ideal world yet, but suggestions like the one made by Don is what get us there.
You can create your own, in a word processing software or Excel/Spreadsheet as many of us do. I use WordCat a lot, and enjoy it, but yes there are libraries that do not show up there. Example: In GA Macon Public Library, I found from another researcher, has a lot of MD records, not found at Cobb Library or Atlanta History Museum Library. So yes keep a list outside of RM or any other software package. It works for me.