Terry Reigel

Associated in what way? As author, editor, complier, or the like? Or do you mean persons who have tags in which the source is cited?

I don't see a way to include the Data Set number in the ID# display, but you can add the "Data Set ID" in a separate column (on the Output Columns tab of Options) to achieve the same thing.

You're welcome. Actually, I think that's a pretty insightful question - I expect many experienced users have never actually thought about it. Thanks - I'm glad you've found it helpful. But don't worry about "dumb questions" -- there are no dumb questions if you don't know the answers. All questions are welcome.

Yes. I'm not sure there's one right answer to this. You could: 1. Cite the certificate - after all, that's what you actually have. Even then, it was issued by some agency, so I think it's reasonable to list them in the source description, and entering them as a repository in the standard source types for a birth record does that, seems to me. You could, if you want, add in the comments section that you hold the certificate. Or, 2. Cite the public record - after all, you have a certified notice from a public agency saying there is such a record. In that case, clearly that agency should be listed as the repository. Don't know that it matters a lot - I'd decide one way or the other to be consistent, then make sure the source notes read consistently with your decision. I don't, but I can see the value in doing so. Among the merits are you have the record easily available for reference any place you have your computer. And you have the ability to include it in websites made with Second Site. I see including images of sources in such websites as a very neat idea, though perhaps a lot of work. Someone whose actually done it could offer some suggestions on the mechanics.

OK, I can understand that. But how do you know it has the same information you have already recorded unless you go through every tag you have and compare the information there to what's in the book? If you don't verify that, I don't see the point in adding the cites - you don't know that the book actually supports what is in your data set. Or have I missed something?

Ray, I suppose the difference is that I can only see one reason to use the current Global citation - to cite a file you have received from someone and just imported. I would only see doing this before merging that imported data set with a working data set, thus everything in it comes from the received file. I can't envison how this can apply to a sub-set of the data set.

Ken, I agree that the source issue is an important one, but not one, in my mind, that requires keeping the data separate. You could record the sources as provided to you and mark the individuals with a flag, but that would not be my recommendation. One issue with this approach is that if you should include some of these people in a report you create, it would appear that you had examined the sources and agree with the interpretation shown. I don't think that's what you would want. There are at least a couple of alternatives. In my view, the "purest" is to cite only the file or other media which you received as the source. Then, in the CD for that citation, include a note showing that your source cited whatever you received. I generally do this by putting something like "..., citing Pawlet town records, vol 1" or whatever the source you are given says. There are a couple of problems with this method. One is that it's a lot of work to do, especially if you are importing a well-sourced file from another researcher. The other is that your source notes can get pretty long and repetitious, especially if the descriptions of your received sources is detailed - you can't very well get a "full footnote" for you indirect source the first time and short one thereafter. There is another approach that I'd think would work especially well if you are importing a file with sources attached. That is to modify each of those sources by adding some sort of disclaimer... maybe something like "cited my Cousin Bob, not seen by author." You could do this after the import, but before merging the imported data with your own. You could put the disclaimer in the Comments field on the Source Definition, and make sure the [COMMENTS] source element is included in each source type you use.

Using the font formatting codes around sentence variables is not recommended because the result varies depending upon where you send the report. I've found you get the result you describe if you send the report to screen or printer, but you get the result you were expecting if you send it to a word processor file.

I'll report it to the developers, Peggy. While what I see isn't as bad as your case, it does seem a bit off, and your experience is clearly non-standard.

I'm hard pressed to understand how adding a few dozen people will "clutter up" the main data set. Yes, you could place them in a separate data set in your main project, or in a separate project. That would keep them entirely separate. Yes, you can disable one or more data sets, which effectively hides them. There won't be any - the whole idea of separate data sets is to keep the data entirely separate. So you can't link people in one data set to those in another. While you could put these lines in a separate data set, I'd strongly urge against it. I see little advantage, and many disadvantages. People in different data sets cannot be linked. Things like sources, repositories, customized tag types, and customized source types all have to be duplicated, and there is no easy way to copy them between data sets. I put everyone in a single data set. I'd only consider separating them if your current project is approaching the limits of your hardware (a consideration at around 50,000 people), and then you need to use separate projects, not datasets, which is even more of a bother. For more on projects and data sets, see my article on that topic on my website - link below.

Ray, I'm finding myself a bit bewildered by this idea. You say you've found a source for several entries in your data set. But entries are tags, not people. How would the focus group get the citations to the right tags? I don't see how you could accurately apply the citations to the new source without comparing what you have already entered with the information in the new found source. Are the relationships, and the dates, and places for each person's birth, marriage, death, and other events, the same as what you already have entered?

I don't understand what this means. Exactly how are you opening it? From what screen? What are you clicking on? From within TMG or from Windows Explorer or something else?

I can't figure out how to do it with List of People or List of Events reports, but you can with the Individual Narrative. Make the sentence for the Principal of the researcher tag something like just: [:CR:][M] Use the Individual Narrative, with a filter that finds all the progenitors. You might set a custom flag to do this, and filter on the flag. In the IN, under Tags in Options, set to "Selected" and select only your researcher tag. The result is the name of each progenitor, followed by the names of the researchers. You could "fancy up" the sentence structure of the tag to get more elaborate results if you like.

Ray, trying to better define your request... Focus groups contain people, and citations are attached to tags, not to people. The existing "Cite Globally" feature allows you to attach citations (for everyone in the data set) to names, events, and/or relationships. Are you suggesting an enhancement to that feature, which would permit the same choices but apply them only to people in the Focus Group rather than to everyone in the data set?

I can replicate this when starting with an embedded citation, but not from a regular tag citation. I'll report it to the developers.

That's the way the default source templates are designed. Using it that way allows the child's name to appear at the beginning of the footnote, which is the suggested style in Ms. Mills' book, which is the basis on which the templates are designed. Used this way, there may be nothing needed in the Citation Detail. However, when I have several sources for an event, and they do not match perfectly, I show in the CD what that source said to support this tag. For example, for a birth tag a citation to a census would say "shows age 13 and state" while a citation to a birth certificate would say "shows date, address, city and state." Some users don't like all the sources that result from making each certificate and individual source. So them make the source more generic, and put more details in the CD. They might, for example make one source for all certificates issued in one county or state, or just one for all of them. Note that this requires considerable modification to the standard templates, since they expect the child's name to appear in the source definition itself. It also means that you can't get the elements in the order shown in the style guides, unless you use the more advanced technique of "split CDs" - see the article on Customizing Sources on my website for details - link shown below. In my view the date in the source definition should be the date the certificate was issued, or the date the original record was filed. However, looking at Mills' examples, it's not clear which was intended. Citations are linked to events, as you note, and thus would be added to each event that you intend to use that source to support. F3 when used in either the source number or CD field will recall both of them. If you use the memo and reference fields, they are recalled separately by F3.

It's not dumb if you don't know what it means. CD means Citation Detail - the area on the Citation screen where you would enter any details about how this source supports this tag. The idea she is describing is to create a Source that is very general, then put all the details, like in this case the name of the newspaper, in the Citation Detail when you cite this source. It's a way of avoiding a long list of similiar sources in the Master Source List.

Can you open the Sample project?

I've never seen a problem with that drop-down. If I click on the name of the role itself, it opens, as it does if I click on the down-arrow. I do find it a bit touchy if I click on the far right edge of the little button with the down arrow - it sometimes fails to open then. But as long as I click somewhere near the center of the button it works fine for me.

Create a combination role of "executor and heir" - it will also read better in the narratives than two separate statements back to back would. For an example, see my article on Will Tags.

All the parent/child tags are really the same thing. The different labels are only for your use in the Person View. If any of the parent/child tags are marked as Primary, they will behave as if the relationship is a blood relationship. In my view the godparent tags are a poor way to record this relationship. Rather, I'd suggest adding the godparents as witnesses to the child's baptism tag as suggested by dadempsey. Probably the best way to do this is to create godparent roles in that tag type, so you can more easily reflect the roles they played, both in their own narratives and those of the child.

Yes. Do that by entering one of the parents, then attach both children to that parent. In cultures that had children using the father's surname, it's easiest to add the father, giving him the surname of the children, if known. Other options are: 1. Enter the father (or mother) with any name, then delete that name after the parent is added. 2. Enter the father or mother, using a "placeholder" name, like "Parent." 3. Don't enter the parent at all, but "connect" the siblings with a note or custom tag.This will not cause them to appear as siblings in reports or screen views, but will cause the name of the other to appear in the tag list for each.

My article on Sentence Structures may help with the mechanics. The sentence I use is: [P] never married The Memo variable allows you to add comments at the end if you want, by entering them in the Memo field.

You can add a Note tag, and enter something like "never married" in the Memo field. If you use the advanced data entry mode, you can enter a sort date to position that tag whereever you want it. Or, you could enter a Anecdote tag, and enter something like "He never married" in the Memo field. Since the date does not print in enter a date in Anecdote tags, you can put a date in the date field to position that tag if you want, and it will not appear in reports. Or, you can create a custom "NeverMarried" tag, with a suitable sentence. That's what I do.

As Vera pointed out, you can select the way dates are displayed in preferences. If you enter dates as all numbers, TMG assumes you are entering days and months in the same order as the display format you selected, and interprets them accordingly. However, if the one number is greater than 12 and the other less, it assumes that is the larger number is the day, regardless of the format you have selected. Your choices are: 1. Select a display format with the same day/month order as the way you prefer to enter your dates, or 2. Enter months as alpha characters rather than numbers. Three characters are always sufficient, and fewer can be used but are some times ambigous - "J" will be interpreted as January, not June or July.