Jump to content
Guest Michael Dietz

Grouping tags by type of event

Recommended Posts

Guest Michael Dietz

First off, I am a detail freak (of course aren't we all with this type of hobby?). More than that I also am a categorization freak. It has bothered me to enter a bunch of data into an individual's record in TMG and have that data jumbled together. For instance I do not like having the marriage name immediately after the marriage event if the event is dated and having the name at the top of the detail window if the event is not dated. Over the years I tried to control where the tags appeared in the window using the sort date but that was not completely satisfactory for me, especially when I had to redate a number of tags to allow the insertion of a new one. I finally developed a system which works very well for me and also allows anybody who is looking at the detail screen, the Second Site detail, or a printed report to immediately recognize the type of tag(s) associated with the individual.

 

My explanation of the system is rathy lengthy so I have attached a complete description of it to this message. This system is not cast in stone but can be altered in any manner anybody wishes. I present it as a suggestion for your perusal.

 

To view the system under Second Site go to

 

http://freepages.genealogy.rootsweb.ancestry.com/~belldietz/

 

Mike

 

And in keeping with the times: I authorized this message and approve of its contents.

JemimaPurdum.DOC

Share this post


Link to post
Share on other sites

Thanks Michael.

I am picky too. I like the tags to be:

Census Name

Census

CensusIMAGE

 

 

So I sort them:

Census Name-one day before the census enumeration (31 Dec 1899)

Census- day of official enumeration date (01 Jan 1900)

CensusIMAGE- day +1 (01Jan 1900-02 Jan 1900)

 

That way I can see which names I still need to get. But I liked how that read on your website and I am always looking for neat ideas to make it more readable.

 

I don't ever print the names out, but just use them in tags, so my Census Name tag doesn't have a sentence. It's helpful having those names in the PE though since my names are often spelt many different ways.

Share this post


Link to post
Share on other sites

Hi Micheal,

 

I like your idea of organizing the tags and output by sections. The organization makes it easier for family members who are not genealogists to read and understand. However, I have one questions concerning the sort dates you explain in the attached Word document.

 

I understand how to use the sort dates for an individual. I don't understand how to use the sort dates for multiple individuals so that the output for each individual is properly sorted according to birth, marriage, death, etc. What am I missing?

 

Joe LaPointe

Share this post


Link to post
Share on other sites
Guest Michael Dietz
Hi Micheal,

 

I like your idea of organizing the tags and output by sections. The organization makes it easier for family members who are not genealogists to read and understand. However, I have one questions concerning the sort dates you explain in the attached Word document.

 

I understand how to use the sort dates for an individual. I don't understand how to use the sort dates for multiple individuals so that the output for each individual is properly sorted according to birth, marriage, death, etc. What am I missing?

 

Joe LaPointe

 

Joe:

I replyed to you through the message service. If you don't receive it let me know. I was on the cruise and so have not been able to reply before now.

Mike

Share this post


Link to post
Share on other sites

Mike,

 

Why don't you reply here? I find Joe's issue one that seriously interferes with creating well-written narratives for a group of people with lots of interrelationships.

 

I've used two methods, neither totally satisfactory:

 

1. Pick a set of sort dates that works reasonably well for all the individuals involved. That's often hard to do.

 

2. Making duplicate tags with different sort dates - in each exclude the sentence for one of the people so it doesn't appear out of place in the narrative. Not only is this extra work, but it messes up the Person View.

 

In my case I'm not moving BMDB tags because I alway print them in the first paragraph, but generally dealing with getting real estate and occupation tags properly interspersed with census tags and will tags that have "mentions" of others.

Share this post


Link to post
Share on other sites
Guest Michael Dietz
Mike,

 

Why don't you reply here? I find Joe's issue one that seriously interferes with creating well-written narratives for a group of people with lots of interrelationships.

 

I've used two methods, neither totally satisfactory:

 

1. Pick a set of sort dates that works reasonably well for all the individuals involved. That's often hard to do.

 

2. Making duplicate tags with different sort dates - in each exclude the sentence for one of the people so it doesn't appear out of place in the narrative. Not only is this extra work, but it messes up the Person View.

 

In my case I'm not moving BMDB tags because I alway print them in the first paragraph, but generally dealing with getting real estate and occupation tags properly interspersed with census tags and will tags that have "mentions" of others.

 

Terry,

your point is well taken. I had answered to Joe because he had sent me a message in addition to the TMG-L forum, I assume because I had not replied to the forum message since I was on the cruise. I read the message before I saw the same question here and I was basically letting him know how I had replied.

 

I will work up a more detailed explanation of the system and will post it here shortly.

 

Mike

Share this post


Link to post
Share on other sites

This topic reappears regularly in various forms based on a variety of needs. While I find TMG definately the best genealogy package for my purposes, the report generator (in my not-so humble opinion :rolleyes: ) is its weakest area. Yes, you can output to a Word Processor and post-process, so you can ultimately get what you want. However, many of us would like the report writer to get much closer to what we want so any post-processing is greately reduced.

 

You would probably support a WishList enhancement that others have suggested and many of us support:

In the Options for reports, on the Tags tab, you can currently select various tags. Instead of simply a check mark, it has been proposed that this check field allow either a "space" character implying "do not select" or a non-space character, say a number from 1 to 9. The desired result would be that all tags for a person marked with a '1' would output in sort date order first, then all tags marked with a '2' would output in their sort date order, then ...

 

This proposal would allow output of "groups" or "sections" of tags based simply on the tag type.

 

Would such a "wished-for" system fulfill your needs?

 

By the way, there is no indication that Wholly Genes could or even would implement such a proposal. It is just a wish.

Share this post


Link to post
Share on other sites

I like Michael Dietz's approach better because it is more flexible than grouping tags in the report generator as proposed by Michael Hannah. I understand how to apply Michael D.'s approach to an individual.. However, it is not clear how to apply it to multiple individuals so that everyone is properly sorted by BMDB and have everyone's sections properly structured.

 

Joe

Share this post


Link to post
Share on other sites
Guest Michael Dietz
I like Michael Dietz's approach better because it is more flexible than grouping tags in the report generator as proposed by Michael Hannah. I understand how to apply Michael D.'s approach to an individual.. However, it is not clear how to apply it to multiple individuals so that everyone is properly sorted by BMDB and have everyone's sections properly structured.

 

Joe

Thank you for the kind words Joe.

 

I am in the process of preparing a rather detailed document on the system including my reasons for implementing the various parts of it the way I did.

 

I do have one question of you. I don't understand your sorting of everyone by BMDB. Evey individual has the appropriate SECTION tags. And so everybody will have a Life Events group, many will have a Names group, some will have a Commentary group, etc. It depends on the events in each individual's record. If you could explain that a little bit more for me I would appreciate it.

 

There is a problem if you are talking about the Master Event List. My system is based upon the event sort date. The Master Event List does not consider the sort date and so there is no way to sort all the SECTION tags together. Neither is there a way to have many BMDB events together because they will have no event date. Also sorting by event type will help some but since I use many types of roles, the Master List also will not be in a useful order.

 

In the meantime I will continue to work on the document and possibly that will have the explanation you are seeking.

 

Mike

Share this post


Link to post
Share on other sites

Mike,

 

My problem may be that I don't understand your system. So I will state my understanding then explain my problem.

 

According to your document, JemimaPurdum.doc, you assign sort dates to the Section Headings and tags using the sort date ranges mentioned in the document. That way the Sections are properly sorted and the tags within each section are also properly sorted. That means that the sort dates for tags have to be assigned according to your system. It is the user's responsibility to assign the sort dates to maintain the BMDB order for an individual.

 

My problem concerns implementing this approach for many individuals. Don't you have to use the sort dates mentioned in the document above for everyone? If so, won't you run out of sort numbers if you have a large database of people? Don't you have to assign sort dates so that each individual is properly sorted by BMBD and that all individuals are sorted by BMDB relative to each other?

 

Thanks for your patience. I'm sure it is obvious once I understand the system.

 

Joe

Share this post


Link to post
Share on other sites
Guest Michael Dietz
Mike,

 

My problem may be that I don't understand your system. So I will state my understanding then explain my problem.

 

According to your document, JemimaPurdum.doc, you assign sort dates to the Section Headings and tags using the sort date ranges mentioned in the document. That way the Sections are properly sorted and the tags within each section are also properly sorted. That means that the sort dates for tags have to be assigned according to your system. It is the user's responsibility to assign the sort dates to maintain the BMDB order for an individual.

 

My problem concerns implementing this approach for many individuals. Don't you have to use the sort dates mentioned in the document above for everyone? If so, won't you run out of sort numbers if you have a large database of people? Don't you have to assign sort dates so that each individual is properly sorted by BMBD and that all individuals are sorted by BMDB relative to each other?

 

Thanks for your patience. I'm sure it is obvious once I understand the system.

 

Joe

Thank you Joe for the reply.

 

I now think the problem is a misconception that each of SECTION tag has to have a unique sort date for each individual. That is not the case. It is true the researcher has to assign the sort dates for all events which do not have an actual date. But the assignment of those dates has no relationship to the sort dates on any other individual. Each individual's record is independent of everybody else (except for those instances of dual relationship, i.e., marriage, parent/child). So the value of the sort date for a specific tag in one individual (again except for such things as marriage) has no bearing on the same specific tag in another individual. For example I will give a brief listing of two fictional individuals who are married and somebody who one of them remarries.

 

Person 1: Primary name is John Adams Brookes

date = blank, sort date = 0200, tag = SECTION, role = Life

date = Mar 3, 1832, sort date = Mar 3 1832, tag = Birth

date = Jan 1, 1850, sort date = Jan 1, 1850, tag = Marriage to Person 2

date = Oct 20, 1850, sort date = Oct 20 1850, tag = Census

date = Feb 15, 1863, sort date = Feb 15, 1863, tag = Death

date = blank, sort date = 2400, tag = SECTION, role = Names

date = blank, sort date = 2401, tag = Name - Census, name is John A. Brookes

date = blank, sort date = 2600, tag = SECTION, role = Document Sources

date = blank, sort date = 2685, tag = Census Index

 

Person 2: Primary name is Mary Elizabeth Jensen

date = blank, sort date = 0200, tag = SECTION, role = Life

date = 1833, sort date = 1833, tag = Birth

date = Jan 1, 1850, sort date = Jan 1, 1850, tag = Marriage to Person 1

date = Oct 20, 1850, sort date = Oct 20 1850, tag = Census

date = Feb 15, 1863, sort date = Feb 15, 1863, tag = Widow

date = blank, sort date = circa 1880, tag = Marriage to Person 3

date = blank, sort date = 2400, tag = SECTION, role = Names

date = Jan 1, 1850, sort date = 2401, Name - Marriage = Mary Elizabeth Brookes

date = blank, sort date = 2402, Name - Census, name is Mary E. Brookes

date = blank, sort date = 2403, Name - Marriage = Mary Elizabeth Johnson

date = blank, sort date = 2600, tag = SECTION, role = Document Sources

date = blank, sort date = 2685, tag = Census Index

 

Person 3: Primary name is Ralph Johnson

date = blank, sort date = 0200, tag = SECTION, role = Life

date = blank, sort date = circa 1880, tag = Marriage to Person 2

 

Now some comments on these events. As you can gather many of them are custom tags but they do not need to be. However I do use custom tags and numerous roles to control the sentence structures for reports and Second Site.

 

The main point here is there is a great deal of duplicate events among the three individuals. All three have the same SECTION: Life event. Two have the same SECTION: Names and SECTION: Document Sources events. The end result will be a narrative report or narrative Second Site page similar to:

 

John Adams Brookes

 

============================== Life Events ==============================

Mar 3, 1832 Born

Jan 1, 1850 Married Mary Elizabeth Jensen

Oct 20, 1850 Census

Feb 15, 1863 Died

 

============================== Name Variations ==============================

___________ Name on a census was John A. Brookes

 

============================== Documentary Sources ==============================

___________ Census Index done by xxx

 

*********************************** next page *******************************

Mary Elizabeth Jensen

 

============================== Life Events ==============================

_____ 1833 Born

Jan 1, 1850 Married John Adams Brookes

Oct 20, 1850 Census

Feb 15, 1863 Widowed

___________ Married to Ralph Johnson

 

============================== Name Variations ==============================

Jan 1, 1850 Married name was Mary Elizabeth Brookes

__________ Name on a census was Mary E. Brookes

__________ Married name was Mary Elizabeth Johnson

 

============================== Documentary Sources ==============================

___________ Census Index done by xxx

 

*********************************** next page *******************************

Ralph Johnson

 

============================== Life Events ==============================

___________ Married to Mary Elizabeth (Brookes) Jensen

 

 

Of course these were very sparse in details, no locations, no witnesses, no other information, no notes or commentary. But I think you can get the general idea. Also none of the sort dates will appear in either the Person Details window in TMG, any of the reports, and none of the SS pages. Look especially at Elizabeth Jensen. Her marriage to Ralph falls after the death of John because the sort date which I assigned to the event (and is shared between the two since this is a marriage) is after the date of John's death. Her alternative names are grouped rather than spread among the life events. When you have several dozen event tags this simplifies the task of looking for a specific type of event which is the purpose of the system.

 

And I will be the first to admit there are a lot of "extra" tags for each person. But I will again say I think it helps in reading through an individual, especially with a dozen kids, several census and occupations, residences, comments, notes, etc., etc.

 

I hope this clarifies the problem.

 

Mike

Share this post


Link to post
Share on other sites

Hi Mike,

 

Thanks for the explanation. Your example corrected my misunderstanding. In fact, your example also corrected my understanding of how TMG works.

 

Thanks again for your patience!!

 

Joe

Share this post


Link to post
Share on other sites
Guest Michael Dietz
Hi Mike,

 

Thanks for the explanation. Your example corrected my misunderstanding. In fact, your example also corrected my understanding of how TMG works.

 

Thanks again for your patience!!

 

Joe

 

You are welcome Joe. I am glad I could help.

 

Mike

Share this post


Link to post
Share on other sites
You would probably support a WishList enhancement that others have suggested and many of us support:

In the Options for reports, on the Tags tab, you can currently select various tags. Instead of simply a check mark, it has been proposed that this check field allow either a "space" character implying "do not select" or a non-space character, say a number from 1 to 9. The desired result would be that all tags for a person marked with a '1' would output in sort date order first, then all tags marked with a '2' would output in their sort date order, then ...

 

This proposal would allow output of "groups" or "sections" of tags based simply on the tag type.

It wouldn't help my problem for two reasons. :)

 

First, my main interest is in narratives for web pages generated with Second Site, although I do occasionally also produce paper reports for the same people. So, the solution would have to work equally in TMG reports and in SS. One that works in only one of them wouldn't work for me.

 

Second, this idea would seem to be tied to tag types - any given tag type would always be before or after tag of other types. But I don't find that consistency like that works well. Depending on what information I have about a person, I very the order of the various tag types for the best narrative.

 

I believe the only solution to the problem of sorting tags that have multiple participants appropriately is to have some system for applying sort dates separately for each participant. This is especially true when the participants are separated widely in age, like when they are in different generations. This idea has been proposed before, most notably by Donald.

Share this post


Link to post
Share on other sites
Guest Michael Dietz

I must say up front that much of this document and the attendant attachment are based on my personal opinions of how genealogical data should be presented to those who are reading or viewing it. I have three pet peeves with genealogical data and the reporting of that data. The first is lack of sourcing and its converse, excessive sourcing. The second is lack of dates. And the third is the seemingly illogical or haphazard order of events in a list of genealogical data.

 

The first problem is obvious. All data should be supported with a report of where that data was obtained. However does it make much sense to give five citations to a birth event? However I do not advocate dropping four of the sources for the sake of having a simpler source list. Rather I still give credit to the five sources but use only one of them for the detail citation for the event.

 

The second is found throughout genealogical data. The passage of time destroys evidence of the very dates we wish to discover. Burned courthouses, lost Bibles and letters, missing documents all add to the problem. And the problem can never be corrected or fixed. However using rational guidelines I do estimate dates. The potential for somebody to take an estimated date and then claim it is the actual date is very real. I would argue though that if enough safeguards are placed on the estimated date, then anybody who would use that date as actual is just as likely to invent a date as the actual date. It is the same type of problem as using locks to keep honest people honest while criminals will ignore the locks.

 

The third is actually the result of the second. The program preparing the presentation of the data has rules to govern the precedence of that data. The most obvious is in chronological order. But when there is no date available, then the program has to determine where to place the data in relation to the other events which are dated. These rules vary from program to program and even within a program. TMG is no exception. I find it disconcerting to find the children listed in the Person Details window before the birth of the parent. Or to have names scattered throughout the display.

 

As stated earlier these are my personal opinions. You may agree or disagree with them. The important point is I have developed a system to approach in some manner the resolution of these three pet peeves. Again, in my opinion I think it does remove some of the arguments given against the three conditions. I have attached a rather lengthy document explaining the mechanisms I use to overcome these conditions.

 

If you have any question or comments please contact me.

Tag_grouping.doc

Share this post


Link to post
Share on other sites
This proposal would allow output of "groups" or "sections" of tags based simply on the tag type.
It wouldn't help my problem for two reasons. :) ...
And your wish doesn't help my problem :D I think there are two different problems requiring two different solutions. But I believe each solution would add functionality that would also help the other problem. :unsure:

 

So, the solution would have to work equally in TMG reports and in SS.
I totally agree. :thumbsup: And since SS has a nearly identical "select tags" structure I would propose that SS also be enhanced with the group numbers.

 

Second, this idea would seem to be tied to tag types - any given tag type would always be before or after tag of other types. But I don't find that consistency like that works well. Depending on what information I have about a person, I very the order of the various tag types for the best narrative.
Again I agree with the need for aiding a best narrative, and believe this proposal promotes that. But I think you misunderstand the proposal. First, multiple different types of tags could all be assigned the same group. Then within that group they would all be output by sort date so would likely be interspersed just like they are now. Second, if you wanted some tags to be in multiple groups, that could also be accomplished. Creating a new tag type that is a copy of an existing tag type is a simple process. And once these similar types are created switching a specific tag from one type to the other is also simple. So, one type goes in one group, the other in the other. With this flexibility you could order every tag however you wanted for the best narrative.

 

I believe the only solution to the problem of sorting tags that have multiple participants appropriately is to have some system for applying sort dates separately for each participant. This is especially true when the participants are separated widely in age, like when they are in different generations. This idea has been proposed before, most notably by Donald.
I agree that this is a problem, but I believe it is a completely separate problem. I support this proposal, but it does not address my problem. And, of course, if separate sort dates are implemented for TMG they would need to be implemented/recognized by SS as well? ;)

 

I wish that the definition of the report itself should contain a mechanism to group tags so that different reports can group tags differently. Using the Sort Date to group tags results in all reports grouping the tags the same way. That method does not help with my problem, regardless of whether each participant has their own sort date or not. The proposal I outlined addresses my problem, your addresses yours, I think we need both.

Share this post


Link to post
Share on other sites
Again I agree with the need for aiding a best narrative, and believe this proposal promotes that. But I think you misunderstand the proposal. First, multiple different types of tags could all be assigned the same group. Then within that group they would all be output by sort date so would likely be interspersed just like they are now.

Yes, I understood that point, but that still means any given tag type is always in one group - so I can't have a Census tag first for one person and an Occupation tag first for another.

Second, if you wanted some tags to be in multiple groups, that could also be accomplished. Creating a new tag type that is a copy of an existing tag type is a simple process. And once these similar types are created switching a specific tag from one type to the other is also simple. So, one type goes in one group, the other in the other.

I had thought of that, but don't agree that having multiple versions of each tag is a simple solution. First, there is just the number of tag types one would have to deal with. And, I don't find changing tag types to be simple at all, once you customize the local sentence to work well in that person's narrative - if you change the tag type you lose the local sentence. I find local sentences are essential for getting good narratives, which is the very reason we need more control over sorting of tags. :)

I wish that the definition of the report itself should contain a mechanism to group tags so that different reports can group tags differently.

That is a separate issue, I agree. It's not one I've heard mentioned before.

Share this post


Link to post
Share on other sites
..but that still means any given tag type is always in one group - so I can't have a Census tag first for one person and an Occupation tag first for another.
Sure you can. Either you could ignore the grouping capability and just put them both in the same group and set their sort dates. Or you could define a "Census1" tag type for whenever you wanted a census tag in group one and an "Occupation1" tag type for occupation tags you wanted in group one. Select all "something1" tag types in group 1 and all "standard" tag types to be in group 2. Thus "standard" tags would sort as normal by sort date after whatever tags you selected for that individual to output first. One person would have their census event first, another would have their occupation event first, whatever made their narrative better.

 

And notice that if all selected tags are in only one single group then the output will be exactly as it is now, by sort date. So the proposal would be completely backwards compatible. Users would only use the feature if they wanted/needed to.

 

I wish that the definition of the report itself should contain a mechanism to group tags so that different reports can group tags differently.
That is a separate issue, I agree. It's not one I've heard mentioned before.
But notice the title of this thread: "Grouping tags by type of event". To me type of event means type of tag. That is the issue I believe is being raised here, and that is the issue that was attempting to be addressed previously by the proposal I restated.

Share this post


Link to post
Share on other sites

Sometimes wishes come true! :clap:

 

I have been experimenting with the new "Tag Groups" feature in the new Version 4 of Second Site. For me this feature goes a long way to produce a report that "groups tags by type of event" (which is the title of this topic). While that new Second Site feature does not solve Terry's wish above (only special sort dates would seem to do that), I think it goes a long way towards providing what the two Michaels asked for, although only in Second Site. Since that is my primary output media, that goes a long way to granting my wish.

 

The user can define as many SS tag groups as they want, define which tag types are in each group, and the order that these groups output. After very little effort my first try at this now has most tag types in a main section, then a section for all that person's census record tags, then a section of tags of lengthy transcripts about this person from other sources, next a section of the tag types that document all my research issues about this person, and finally a section about family and lineage information which comes just before the list of children. I can easily see how it would be simple for Michael to create a "Life" section, a "Names" section, and a "Document Sources" section such as he described above. I expect that I will be experimenting a lot with this. I REALLY like this new feature. Thanks, John!! :thumbsup:

 

For more information about this new V4 feature, see the Second Site Help pages about Tag Groups as well as Terry Reigel's Tips page about Second Site Tag Groups.

Share this post


Link to post
Share on other sites

Michael, I agree with your assessment of the Tag Groups in SS. But that does not provide a solution for reports printed from TMG. So I use both, my original idea for the reports I print and then group those "groups" into the Tag Groups for SS. Best of both worlds in my opinion. In SS I do not include the header tags for the TMG groups the way I do in the TMG reports. That is the one accommodation I make for the Tag Groups.

Michael from the other side of the mountains.

Share this post


Link to post
Share on other sites

We are in complete agreement. As I said: "it goes a long way towards providing what the two Michaels asked for, although only in Second Site."

 

You said: "In SS I do not include the header tags." Yep there is no need, since in Second Site you can appropriately name and choose to print that name of the group, which provides a header.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×