Friday, December 31, 2010

Looking at TMG Places through the eyes of GEDCOM

I've used TMG for several years and really like it's approach to organizing place information.

TMG locations are organized by fields that can be customized by creating unique place styles. The user enters location information on the Tag Entry screen, shown below:
The Master Style List can be accessed from the Tag Entry Screen. That Style list is shown in the clip below (you'll note that TMG's Name Styles can also be accessed from this Master Style List screen):
 
In TMG, a place style is defined by labels. The U.S. Standard Place fields, by default, are listed below:
Label 1: Addressee
Label 2: Detail 
Label 3: City
Label 4: County
Label 5: State
Label 6: Country
Label 7: Postal
Label 8: Phone
Label 9: LatLong
Label 10: Temple

New styles can be added to change the names of the labels.

TMG's Master Place List records all the locations that are recorded in a project. It's readily accessible from the program's top tool bar. A clip of TMG's Master Place List follows. Place information can be edited from the Master Place List.
When TMG's place information is exported via GEDCOM, the otherwise field level information in TMG is transferred as a string of entries, with each part of the place entry separated by a comma. As part of the GEDCOM export process, users are given the options of which fields should be exported and how those commas should be handled. Below is the screen view about that part of the GEDCOM export process.
On that export-place specific screen, above, you'll note the user can control which fields are exported and whether or not missing fields should be separated by commas. If the latter option is selected, the user can further chose to trim (not export) leading commas and trailing commas.

Now then, not all programs store place information in the same way. In a test today, transferring information via GEDCOM from TMG to both FTM and RM, we wanted to see how a particular entry would transfer. For this test, we added a phone number to a residence tag of Annie Eliza Alexander:
We created a GEDCOM using the following place specific export options:
So, in addition to the default selections (Detail, City, County, State, Country), we also included Postal Code and Phone; we included "commas when missing" and "trim lead/trail [commas]."

Below is the resulting import to FTM. You'll note the address precedes the city, county and state, followed by added commas for the missing country and postal code. The entry finished with the phone number we had added.
This second clip is the resulting import to RootsMagic. You'll note the whole entry was imported to RootsMagic's "Place" field, despite that RootsMagic has a field for "Details" (it's called Place Details in RootsMagic.)
Neither FTM nor RootsMagic has an obvious field for a phone number. [Correction: Myrt reports the RootsMagic4 field for phone numbers is located in separate data fields. See the RootsMagic menu, "Lists > Address List").]

As part of today's exercise, we also looked at GENBOX place handling. GENBOX comes preloaded with certain place information. Users create place information and use "higher place"/"lower place" designations to identify place parts.

Hope this helps. --GJ

21 comments:

Russ said...

GeneJ,

Just as a follow up, there is the information, in the GEDCOM file:

1 RESI
2 DATE 23 APR 1923
2 PLAC 1114 Windsor Avenue, Bristol, Sullivan County, Tennessee, , , 999-542-7381


Please note, the in information send, was received in the order that both Family Tree Maker, Version 2011, and Roots Magic 4 received.

I wonder, if TMG can put the Phone Number in the PLAC field FIRST. Please resend the file, but this time, do not use the Comma when Missing. I think that the file will transfer properly. However, if the Phone Tab can't be sent first, we will still be OK, but may have to edit the Place field in both RM4 and FTM2011.

Thank you,

Russ

Myrt said...

DearGENEJ,

Thanks for taking the time to document the oddities we discussed via GoToMeeting yesterday.

RootsMagic does have a field for phone numbers, however it is in a separate series of data fields found on the menu bar under "LISTS" then "Address List".

The combining of an event location and an address list (including phone number) is what made V7.5 TMG's GEDCOM file look a little weird when pulling the data into RootsMagic 4.

GeneJ said...

Hi Myrt:

Thank you for correcting the record.

So true! When one program presents things differently than another, it can strike us first as odd.

The "address book" like place information in TMG considered by some users to be a feature of TMG.

TMG users can, indeed many do, use the addresses for holiday greeting cards, birthday cards, and other correspondence.

See the thread on the TMG Mailing list (last month) discussing this mailing list feature:

http://archiver.rootsweb.ancestry.com/th/read/TMG/2010-12/1291823419

Hopefully that explains why TMG also includes an "addressee" field in the place list. (FYI, the identical place fields are available in the TMG Repository list, too.)

GeneJ said...

Russ,

I don't think it should be the responsibility of TMG or it's users to move it's phone field.

Consider this, Russ. Do the place databases used by RootsMagic and FTM include the County/Parish, etc. designator?

And if they don't, do RM and FTM place a missing comma where there is a missing intermediate place part?

AND ... how will RM and FTM now handle locations here in the areas where the county jurisdictions are disappearing?

TMG provides great features allowing it's users to do manage their place databases.

Yes, I do include a county/parish designator. If I don't know that county name, the county field is left blank. If there is no county assigned, the county field is left blank.

If I receive information from someone that doesn't contain those designators, then I will have to edit each of those locations to add that information ... which means really, I'll have to perform the research necessary to know that "Washington, Wisconsin" really meant "Washington County, Wisconsin."

Personally, I'm not sure which wizard decided on dropping jurisdictional designators. I believe FamilySearch has adopted that style.

While I'm sure there are debates about legal names, I'm quite certain dropping the designation will blur the record. Unless I perform the necessary due diligence (and how many will), when data is passed for "Washington, Wisconsin," how is one to know if that refers to one of the eight or more towns in Wisconsin named Washington, or the Wisconsin county by the same name?

Russ said...

GeneJ,

Many questions, many comments:

I don't think it should be the responsibility of TMG or it's users to move it's phone field.


I completely agree with you. TMG should NOT. But, the issue here is

What information should be included in a PLACE NAME?

I do not think that a Cemetery Name, A Church Name, a Street Address, or a Phone Number should be included in a PLACE Name.

But, that is my opinion AND I do not think that GEDCOM 5.5 addresses this issue, at this level of detail. THAT is the GEDCOM issue that WE have illustrated.

Russ said...

GeneJ,

Consider this, Russ. Do the place databases used by RootsMagic and FTM include the County/Parish, etc. designator?

I will only speak for Family Tree maker, as I don't know RM as I do Family Tree Maker.

In the past, Family Tree Maker version 16 and earlier, the answer was Yes, as FTM didn't care.

With Version 2008 and the Map Feature with a Place Name Authority, the answer is NO. No Jurisdiction titles are NO included.

As you know, I (and this is just me) WILL add the Term Parish, as appropriate, for those historical place names that are NOT included in the current Place Name Authority. FTM warns me, about this.

Russ

Russ said...

GeneJ,

And if they don't, do RM and FTM place a missing comma where there is a missing intermediate place part?

I am guessing that you are talking about when generating a GEDCOM file. ANSWER: NO.

Reason: as you know is that TMG has Fields for each piece of a Place Name. Family Tree Maker does NOT have Jurisdiction fields.

A Place Name is a string of characters, each having a comma at the end of the Jurisdiction. This is why you don't have a problem importing into TMG.

So, IF I have resolved all of my place names, in Family Tree Maker, the GEDCOM will be opened in TMG, with the Jurisdiction in the correct fields in TMG.

Russ

Russ

Russ said...

GeneJ,

TMG provides great features allowing it's users to do manage their place databases.

Yes, I do include a county/parish designator. If I don't know that county name, the county field is left blank. If there is no county assigned, the county field is left blank.

I am not disagreeing with you about the nice feature of TMG. I have also seen many Family Tree Maker users wishing for the same capability.

The nice feature of Family Tree Maker and the Place Name authority, if I don't know the County, the PNA warning will help me resolve that.

Lets take the example of a Parish indicator, Maryland specifically. I do NOT resolve that Place Name warning message. I will do some research off line, to see where that Parish might be, in the current or historical boundries. I may or may not find it. I handle these 'exceptions' on a case by case basis.

IF I can find the current place name, I will double enter that Place. One with the Historical Place Name (with appropriate Citation) and the Current Place Name with a Citation that I have in my file to deal with Current vs Historical Place Names.

That way, when you receive this information you may see the double entry and WHY the double entry.

Hope that helps,

Russ

GeneJ said...

Russ:

Thanks.

While we haven't gotten into the details too much, how TMG STORES information is separate from how the user actually applies that information in programmed sentences, etc.

I am used to seeing the "detail" field (cemetery name, church name, resident address, included in the place property.

It sounds to me as though FTM wants this just added to the front of the location string. RootsMagic has a field for the detail that sets just separate from the place string.

FTM for Mac came with a book. I haven't cracked it open on this topic.

You wrote, "IF I have resolved all of my place names, in Family Tree Maker, the GEDCOM will be opened in TMG, with the Jurisdiction in the correct fields in TMG."

At the end of the day, GEDCOM has no way of knowing IF you have resolved your place names in FTM.

I'm pretty sure you agree with the example in my comment, above, about "Washington, Wisconsin."

Lord help the user with events known only by a single location part, ala "Washington." (XXX was born at "Washington," XXXX)

I record precise place/location information in TMG (and in GENBOX). I think genealogists should want to keep that precision AND access great cool modern features, like sexy maps.

Who among us doesn't agree that mapping IS a primary research methodology? I don't expect the universe of geo-mapping wizards to relate to my family historian needs. I want genealogical technologists to do just that--build GREAT features that allow us to access modern mechanisms while preserving our precise (and usually well documented) record.

Looking back at that example about "Washington" in Wisconsin. How many GEDCOM transfers do you think it will take before the poor fellow born near La Crosse ends up recorded born by one person in the Pacific Northwest and, by another, on the Capital steps? And both of those genealogies might provide a map and both might cite the same "source of the source."

Thanks again. --GJ

Russ said...

GeneJ,

OK, My comments will be included in your comment:

You said:

"While we haven't gotten into the details too much, how TMG STORES information is separate from how the user actually applies that information in programmed sentences, etc."

==> I really don't care how information is stored in any program. Each program has different fields for storing our information. How it is presented to us, is also different, but that doesn't matter for this conversion. The issue is HOW the information is put into a GEDCOM file. Right?


You said:

"I am used to seeing the "detail" field (cemetery name, church name, resident address, included in the place property."

==> You have a Detail field, I have a Description field that does the same thing.

What does GEDCOM 5.5 have to say to what goes into a PLAC tag? What is the format for a Place in a GEDCOM file?


You said:

"It sounds to me as though FTM wants this just added to the front of the location string. RootsMagic has a field for the detail that sets just separate from the place string."

What is "it" that is put in front of the location string? If you are talking about the Address, then please look at the FTM and the RM4 screen shots. You will see that the ADDRESS in both screens is at the beginning of the Place Field. Right?


You said:

You wrote, "IF I have resolved all of my place names, in Family Tree Maker, the GEDCOM will be opened in TMG, with the Jurisdiction in the correct fields in TMG."

At the end of the day, GEDCOM has no way of knowing IF you have resolved your place names in FTM."

==> Resolve or not, you don't see it, nor should you care. BUT, if I do resolve them, TMG will open a Place as it should. Right?


You said:

"I'm pretty sure you agree with the example in my comment, above, about "Washington, Wisconsin."

==> BUT, if the program that the user is using, as or doesn't have a place for the Jurisdiction information, the user won't care. Washington, Wisconsin, to me is Washington County, and the State of Wisconsin.

Just to take this one step further, trying to follow your logic, and again I am not saying who is right or wrong, why wouldn't the correct place statement be

Washington County, State of Wisconsin, Country United States of America.

That is, complete jurisdiction spelled out ALL the way for each jurisdiction.

Your TMG has the jurisdiction in the Field Name, right? I don't see the jurisdiction in the GEDCOM file. So, jurisdiction information really doesn't matter in the current GEDCOM file.

What may be important, in a BetterGEDCOM would be to spell out those Jurisdiction names, either as separate parts of a place name, or some way to separate the jurisdiction in the Place name structure.

Lord help the user with events known only by a single location part, ala "Washington." (XXX was born at "Washington," XXXX)


You said:

"I record precise place/location information in TMG (and in GENBOX). I think genealogists should want to keep that precision AND access great cool modern features, like sexy maps.

Who among us doesn't agree that mapping IS a primary research methodology? I don't expect the universe of geo-mapping wizards to relate to my family historian needs. I want genealogical technologists to do just that--build GREAT features that allow us to access modern mechanisms while preserving our precise (and usually well documented) record.

Looking back at that example about "Washington" in Wisconsin. How many GEDCOM transfers do you think it will take before the poor fellow born near La Crosse ends up recorded born by one person in the Pacific Northwest and, by another, on the Capital steps? And both of those genealogies might provide a map and both might cite the same "source of the source."

==> Sorry, don't understand this last comment or issue.


Russ

GeneJ said...

Hiya:

(1) Russ wrote, "Each program has different fields for storing our information ... The issue is HOW the information is put into a GEDCOM file."
I think it depends on HOW, in this case, BetterGEDCOM is developed. In other words, does it continue to recognize just a string of locations (place parts), does information interface with a template, and, whether it's a string or a template, do those interface with some place authority at the time the information is exported into BetterGEDCOM.
What we discovered yesterday is that none of the programs we looked at store information in the same way. (So that the "strings" each program creates are likely to look a little different.)

P.S. I suppose as more historical phone books become accessible to us, we may find folks record more phone numbers.

(2) Russ wrote: "You have a detail field, I have a description field"
...and RM4 has both fields, detail and description.

(3) Russ wrote: "What does GEDCOM 5.5 have to say to what goes into a PLAC tag? What is the format for a Place in a GEDCOM file?"
I hope we want to communication our best knowledge of a location as it existed at the time the event occurred.
Sometimes, like with my father's WWII movements, our knowledge might begin with only a postal code. For a long, long time, phone numbers were tethered to locations. As above, when phone books become common as genealogical sources, we'll no doubt see more folks associating phone numbers with locations.

(4) Russ asked, "What is "it" that is put in front of the location string?"
The location detail.

(5) Russ wrote, "if the program that the user is using, as or doesn't have a place for the Jurisdiction information, the user won't care. Washington, Wisconsin, to me is Washington County, and the State of Wisconsin."
Yes, and if a FTM user only knows or records a place as "Washington" (may not know yet whether it was city, county, state or DC), I'm pretty certain that data transfers to other programs, as Washington (state of). Which is why I later wrote, "How many GEDCOM transfers do you think it will take before the poor fellow born near La Crosse ends up recorded born by one person in the Pacific Northwest and, by another, on the Capital steps? And both of those genealogies might provide a map and both might cite the same 'source of the source.'"

If the person only knows Washington, ,Wisconsin (added commas here to show the county is not known yet), I understand that location will be entered as Washington, Wisconsin. I'm guessing some programs will recognize that location as Washington County, Wisconsin.

(6) Russ wrote, "That is, complete jurisdiction spelled out ALL the way for each jurisdiction."
Actually, your example was not following the reasoning I use. Genealogical narrative standards provide reasoning.

(7) Russ wrote, "Your TMG has the jurisdiction in the Field Name, right? I don't see the jurisdiction in the GEDCOM file"
The field name labels (which can be customized) are like pointers for the researcher, encouraging place information to be recorded consistently. The Master Place List also encourages consistency.
I can use the field name labels to search the data. For example, I can locate all events that occurred not only at a specific place, but at a specific county, or a state, or even a country.

Russ said...

GeneJ,

You said:

"What we discovered yesterday is that none of the programs we looked at store information in the same way. (So that the "strings" each program creates are likely to look a little different.)"

I am not sure that is true. I can't see inside of the program.

What I CAN see, is that the Place information is pretty much the same, between Roots Magic and Family Tree Maker.

The Place field is ONE field that handles a string of data, starting with the Township or City information, then county, State, and country. BOTH have a place for "other" information, like street address, cemetery or church names.

How WE see it, is NOT important for this discussion. What IS important, is what gets put into the PLAC Tag in a GEDCOM file.

The BetterGEDCOM project, however, MUST address or better define what information gets put into the PLAC Tag. Does it include Co., Twp., State, and in what orders.

Further, what to do with Street Addresses and Phone numbers.

I haven't seen your answer about IF a Cemetery Name is Part of the PLAC Tag.

Russ

Russ said...

GeneJ,

You said: "
(4) Russ asked, "What is "it" that is put in front of the location string?"

The location detail."

OK. The PLAC to be defined by the BetterGEDCOM must address what is appropriate to that Tag.

Does the complete "location string" include or exclude Zip Codes, Phone Numbers, Church Names, Cemetery Names.

Russ

Russ said...

GeneJ,

You said: "Yes, and if a FTM user only knows or records a place as "Washington" (may not know yet whether it was city, county, state or DC), "

Actually, "Washington" entered alone in Family Tree Maker will show up as a Needs to be Resolved place name. FTM doesn't "know" which Washington I am talking about. Could be a State, Could be a County, Could be a Township, Could be a City.

Oh, Washington DC is also NOT an acceptable entry. And, there are 4 Washington Townships in New Jersey. In fact, there are 2 Washington Townships within 10 miles of where I live.

I can Ignore the warning OR I can look into the matter.

If I sent you a file with only Washington in a Place name, you and I both would have to figure out what I am talking about.

Russ

Russ said...

GeneJ,

You said: "(6) Russ wrote, "That is, complete jurisdiction spelled out ALL the way for each jurisdiction."

Actually, your example was not following the reasoning I use. Genealogical narrative standards provide reasoning."

Since I am a "newbie" I don't know what those Narrative Standards are. Sorry.

Perhaps THEY need to be included in the BetterGEDCOM requirements for the PLAC Tag.

Thus, this discussion.

Russ

Russ said...

GeneJ,

You said: "I can use the field name labels to search the data. For example, I can locate all events that occurred not only at a specific place, but at a specific county, or a state, or even a country. "

So can Family Tree Maker, as I have shown before. Its that TMG and Family Tree Maker do this display work or gathering of information and selecting criteria for a report differently. Both end up with the same information.

So, the internal handling of the information is different, that is program to user, but what we are trying to discuss is what MUST be in What format in a BetterGEDCOM file.

Russ

GeneJ said...

Let's just agree to disagree.

Russ said...

GeneJ,

What are we disagreeing about?

Russ

GeneJ said...

Fifth time the page has forwarded and eaten this comment. (Then I decided to clarify a point.)

Believe we disagree mostly about what a "place" is and how information about a place should be communicated, user to user. Said another way, we disagree on whether or not the method TMG outputs it's place data is acceptable, given the way that information imports to FTM.

TMG's place information is organized by fields. GEDCOM wants those fields "dumbs down" so that data is presented as a comma separated "string."

TMG users export GEDCOMs via a wizard that allows the user to choose which place fields should be exported, whether commas should be added for missing place parts and whether leading and/or trailing commas should also then be trimmed.

TMG has been criticized for using a wizard (as opposed to point, click and shoot). Indeed the place options in the wizard lets the user control just how much to dumb-down that place data.

(I posted a comment on the next blog post about how place information is presented in the _Register_.)

I understand that FTM defines it's "resolved" string in accordance with a particular "place authority" that is not based on historical location data. It as least appears that place authority and style is not based on scholarly genealogical presentations, either. Rather, it seems to me FTM's specific "place string" is designed to integrate with geo-coding and "Bing" (some other party's standard).

FTM users enter this place level information as a string of data.

FTM is never going to like my personal data (for example, I try to include the word County or Parish, etc. for what might be called the county designator. FTM considers my entry to be an unresolved place. [FTM for Mac.] As well, I consider the name of a church where someone was baptized to be part of the place; the cemetery is often part of the burial place in my data.

Likewise, if I was porting my project from FTM to TMG, I'd have to clean up the TMG input. I'd have to the county designator, maybe move the detail from notes up to the place template, etc., and I'd check the places in the Master Place List to find place parts that had been improperly identified because there weren't commas inserted for missing place parts.

------

TMG has a template for place information. The template is accessed from the tag entry screen, the repository screen and the Master Place List. All the information entered into the template is reported on the Master Place list.

TMG's place template accommodates the kind of place information a user might want when recording information about event location details and repository details.

The fields in the place template are generally accessible by TMG Utility. So, for example, when I changed from FTM to TMG, and then wanted to change county jurisdiction presentations from the abbreviated "Co." to "County," I used TMG Utility to do a search and replace in that particular field.

Nothing in TMG prevents a user from creating a custom tag, "Phone Number or Private Phone Number" and entering phone data into the memo or other tag fields. Such entries would not be then recorded in the Master Place List.

Russ said...

GeneJ,

The point of this testing and this blog entry has NOTHING to do with what WE want to see nor how the programs handle the data. The issue is What does the GEDCOM standard say.

The GEDCOM says, on this webpage:

http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gctoc.htm

PLACE_HIERARCHY: = {Size=1:120}
This shows the jurisdictional entities that are named in a sequence from the lowest to the highest jurisdiction. The jurisdictions are separated by commas, and any jurisdiction's name that is missing is still accounted for by a comma. When a PLAC.FORM structure is included in the HEADER of a GEDCOM transmission, it implies that all place names follow this jurisdictional format and each jurisdiction is accounted for by a comma, whether the name is known or not. When the PLAC.FORM is subordinate to an event, it temporarily overrides the implications made by the PLAC.FORM structure stated in the HEADER. This usage is not common and, therefore, not encouraged. It should only be used when a system has over-structured its place-names.

and

PLACE_VALUE: = {Size=1:120}
[
|
,
]
The jurisdictional name of the place where the event took place. Jurisdictions are separated by commas, for example, "Cove, Cache, Utah, USA." If the actual jurisdictional names of these places have been identified, they can be shown using a PLAC.FORM structure either in the HEADER or in the event structure. (See .)

So, the format, as defined in this document is Cove, Cache, Utah, USA.

GeneJ said...

(1) "So, the format, as defined in this document is Cove, Cache, Utah, USA."

And I would enter that information in my TMG file in a way that would share it with you it would appear "Cove, Cache County, Utah."

If it was a baptism at a church, I would enter the information so that when shared, you see, "Cove XXXXX Church, Cove, Cache County, Utah."

If, for the latter, you sent me "Cove, Cache, Utah, USA," I'd need to edit your data to add the county designator; more than likely I'd drop the USA, and if I discovered the church in a note somewhere, I'd move it up to the detail field.

(2) "It should only be used when a system has over-structured its place-names."

Since I know and love what is referred to in 1995 as an "over-structured ... place name," it probably comes as no surprise when I refer to the other presentation as "dumbed down."

But heck, with the TMG wizard, I can "dumb down" my place data by taking out the commas for missing place parts.

(3) "The point of this testing and this blog entry has NOTHING to do with what WE want to see nor how the programs handle the data. The issue is What does the GEDCOM standard say."

Since we are working with data, I don't think that issue is quite so black and white. If it is, then maybe it is a GEDCOM problem.

I include the county designator, ala "Columbiana County," because I believe that is genealogical best practice.

If I enter "First Church, Beverly ...," I believe that too is a genealogical best practice.

If we stick to simple handling for things like detail, lat/long, postal codes, phone numbers and the like, then it maybe GEDCOM can only pull a string of data.

Separately, Board for Certification of Genealogists (BCG), _... Genealogical Standards Manual_ (2000), see p. 25 in "Teaching Standards," as item/standard no. 72, "Database programs accommodate sound data-collection, evidence-evaluation, and compilation standards and do not force or encourage users to leap to premature conclusions about personal identities or relationships, or to tailor their research findings to the input interface."