WITNESS statements inserted in TMG generated gedcoms

[TPG 0]

NOTE: This posting was also placed in the "Discontinuation of TMG" topic, where it is also relevant.

 

Witness TMG Program

 

Builds witness entries from TMG propritary project files and includes them in a compatible TMG generated GEDCOM file.

 

The witnessTMG program asks that the TMG project be identified in the form of the core " . . . __.PJC" file of the project. It also asks for the input GEDCOM file to be identified. After the program processes and inserts the witness data, a new GEDCOM file is left in the program's folder as "newGEDCOM.ged".

 

The generated witness statements are inserted as

1 EVEN

2 TYPE Witness: [role] in [eventtype] for [Prin1] and [Prin2] **

2 DATE [date]*

2 PLACE [place]*

 

* entry is omitted when [date] or [place] is blank.

** either or both [prin1] and [prin2] is omitted when blank.

 

It was originally developed to use gedcoms produced by some earlier versions of TMG. It was then revised to handle gedcoms produced by TMG Version 8. Tom Holden, another contributer to this forum, has successfully tested it with gedcoms produced by TMG version 9.

 

You may download the witnessTMG package via www.crestline-enterprises.com/witnessTMG. The WitnessTMG package is in the form of a zip file, whose only content is the "WitnessTMG.exe" program. One should extract the program from the zipped package and store in a convenient folder. You can run it from this folder, which becomes the folder containing the output "newGEDCOM.ged".

 

IMPORTANT NOTE: In order for the WitnessTMG Program to be able to read the internal files of The Master Genealogist, one must first install the Microsoft VFPOLEDB facility before installing the WitnessTMG Program. This can be gotten from: http://www.microsoft.com/en-us/download/details.aspx?id=14839 I believe that one may choose either of the relevant installers to download, although I have used VFPOLEDBSetup.msi. After the VFPOLEDB facility has been installed, one may install the WitnessTMG Program. All that is strictly required is that the GEDCOM file have the same numbering conventions of the TMG file and that the TMG file include all individuals that occur in the GEDCOM file. This requirement is most easily satisfied if the TMG project is the project file itself used to generate the GEDCOM file or is a superset of that project file.

 

 

[Michael Hannah 0]

Excellent contribution, Tom. I have not (yet) downloaded it and tested it, so please forgive some questions which might be answered by testing. I presume this EVEN structure is added as part of the INDI structure of the person who is the witness? And is the Prin1/Prin2 output the names or the INDI numbers of the Principals? Or both? And if a name, is it their Primary name or the TMG selected name for that TMG tag?

Also, note that the GEDCOM standard limits the text following TYPE, which it calls the EVENT_DESCRIPTOR, to a maximum of 90 characters. If the role name, event type, and Principals' names are long there may be a danger of exceeding this limit. I was wondering if also using the GEDCOM subtag CAUS as part of this special EVEN structure might be useful. It also allows (another) 90 characters and might limit the likelihood of exceeding the maximum text length for either tag.

 

Finally, I think the separate TMG Witness Memo also needs to be output, which might be put in a NOTE. Just brainstorming off the top of my head, but perhaps something like the following would work:

 

1 EVEN

2 TYPE Witness: for [Prin1] and [Prin2]

2 CAUS [role] in [eventtype]

2 DATE [date]

2 PLACE [place]

2 NOTE [Witness memo]

[TomH 0]

I guess one should add Sources to that, also, although they might be the most complicated to implement, i.e., referencing an already existing source or creating a new master source.

 

Another wrinkle is PLACE format, given that the TMG Export gives options for formatting places and what levels to include in the GEDCOM. Otherwise just accept that the same place may end up as two places in the destination database for the user to merge there.

 

For RootsMagic, I prefer that the "Witness:" prefix should end up alone on the TYPE line, as:

 

1 EVEN [role] in [eventtype] for [Prin1] and [Prin2]

2 TYPE *Witness

2 DATE [date]

2 PLACE [place]

2 NOTE {[role] in [eventtype] for [Prin1] and [Prin2]} [Witness memo]

...

 

Otherwise, a new RootsMagic fact type is created for each unique TYPE value. This way, only one "*Witness" type is created. The leading asterisk helps to flag it as a custom fact type and sorts it to the top of the list of fact types. RootsMagic accepts the value on the EVEN line as it does for other standard event and attribute tags but it is a custom GEDCOM extension. Repeating it in the sensitivity/privacy braces in the NOTE ahead of [Witness memo] assures that it will be imported to other software. A multiline regular expression search and replace on the GEDCOM modified by the current witnessTMG can modify it accordingly. Notepad++, among others, is capable of doing so.

 

Without modification, witnessTMG should be useful to the pioneering emigre from TMG as it provides a means of identifying in the destination database those events for which the user needs to refer back to the TMG database to decide what should be done to it in the new system. For example, conversion of the event into some other type, copying notes, citations of imported and unimported sources... Undoubtedly, every migrant will need to do careful comparisons and probable editing in order to be satisfied that all which is needed has been transferred as well as is wanted.

 

Thanks, Tom.

[Helmut Leininger 0]

Tom,

 

For RootsMagic, I prefer that the "Witness:" prefix should end up alone on the TYPE line, as:

 

1 EVEN [role] in [eventtype] for [Prin1] and [Prin2]

2 TYPE *Witness

2 DATE [date]

2 PLACE [place]

2 NOTE {[role] in [eventtype] for [Prin1] and [Prin2]} [Witness memo]

...

 

Otherwise, a new RootsMagic fact type is created for each unique TYPE value. This way, only one "*Witness" type is created. The leading asterisk helps to flag it as a custom fact type and sorts it to the top of the list of fact types. RootsMagic accepts the value on the EVEN line as it does for other standard event and attribute tags but it is a custom GEDCOM extension.

 

Does this mean that the "*eventtype" is a an extension specific to RootsMagic? In this case it would not work for imports to other programs.

Edited August 13, 2014 by Helmut Leininger

[Michael Hannah 0]

I guess one should add Sources to that, also...

I wouldn't. I think the purpose of this custom "Witness" event is to refer back to the Principals' event, where the source(s) would be fully cited. So I don't see a need to duplicate.

Another wrinkle is PLACE format...

This is another example of duplicating what is part of the Principals' event. However, I think duplicating Date and Place is unavoidable to aid in linking this Witnessing to what might be one of many cases of this person Witnessing those Principals' events.

For RootsMagic, I prefer that the "Witness:" prefix should end up alone on the TYPE line...

Otherwise, a new RootsMagic fact type is created for each unique TYPE value. This way, only one "*Witness" type is created...

Interesting what RootsMagic does, and makes sense.

RootsMagic accepts the value on the EVEN line as it does for other standard event and attribute tags but it is a custom GEDCOM extension...

I wonder what RootsMagic would do with a standard CAUS tag? If RootsMagic would deal with it appropriately, other programs may do as well. If it was necessary to modify the GEDCOM this separate subtag would make identifying that data easy. And it might also avoid the need to duplicate that text in the NOTE.

 

Just my random thoughts,

[Michael Hannah 0]

Does this mean that the "*eventtype" is a an extension specific to RootsMagic?

In this case it would not work for imports to other programs.

No, the EVEN/TYPE structure is completely standard GEDCOM. The standard also specifies that the entire text following TYPE defines this specific "type" of event. Beginning such text with an asterisk or any other special character is certainly allowed, although the standard generally recommends a leading underscore character to indicate a custom tag type. This asterisk is simply Tom's way to easily find such tags within a GEDCOM file. Thus RootsMagic's behavior of treating each unique set of text following TYPE as a separate RootsMagic fact type is correctly following the standard. So Tom's idea to always and only have the same text ("*Witness") after TYPE for every such instance is appropriate to avoid the creation by RootsMagic of a separate tag type for each such instance. Due to this RootsMagic behavior it makes sense to find a place on some other GEDCOM subtag than the TYPE subtag to put the specific linkage information for this specific Witness example. That is why I am suggesting the standard CAUS subtag as an alternative to Tom's placement of it on the EVEN tag. I think he chose that location because the RootsMagic program accepts extra text on the EVEN tag. But allowing such extra text is not part of the standard, so one cannot expect other programs to accept or recognize such text there.

[TomH 0]

...

I wonder what RootsMagic would do with a standard CAUS tag? If RootsMagic would deal with it appropriately, other programs may do as well...

RootsMagic ignores it, at least under an EVEN. So NOTE is the only logical place that all software should recognise which is why I suggested it be duplicated there within sensitivity/privacy braces which RootsMagic and TMG both can act on (and therefore probably others) and, for at least RM (and possibly others), have the value on the EVEN line. That said, as long as the output begins:

 

1 EVEN

2 TYPE Witness: [role] in [eventtype] for [Prin1] and [Prin2]

 

it is possible to batch revise the GEDCOM to

 

1 EVEN [role] in [eventtype] for [Prin1] and [Prin2]

2 TYPE *Witness

 

for RM without affecting anything else in the GEDCOM. It's fiddly, but, if this is as far as Tom wants to go with the utility, it is usable.

Edited August 13, 2014 by TomH

[TomH 0]

 

I guess one should add Sources to that, also...

I wouldn't. I think the purpose of this custom "Witness" event is to refer back to the Principals' event, where the source(s) would be fully cited. So I don't see a need to duplicate.

 

Except that TMG allows unique sources for the witness tag and unique citations of sources common to the principal's events, does it not? Those may be written read differently from that of the principal. If reading a report about a person, one would prefer, I suspect, to have a footnote or endnote that is referenced from the sentence or phrase about the person's role in somebody's wedding and not have to look up the principal to find the evidence.

 

That said, this discussion may prove to be just wishful thinking.

[Michael Hannah 0]

Except that TMG allows unique sources for the witness tag and unique citations of sources common to the principal's events, does it not?

Not sure what you mean, Tom, but I don't think so. There are only one set of citations to a TMG tag. These same sources will be identically cited in the Principals narratives as well as the Witnesses narratives. In TMG there is no separate "witness tag" with unique sources. While it might be nice if the citations were different in the different narratives, TMG only provides for the narrative text to be unique to each person. There is only one tag, which has one or two Principals, plus one or more Witnesses, and only one set of citations. Hence I would refer back to citations on the Principals' GEDCOM event of this one tag.

 

That said, this discussion may prove to be just wishful thinking.

Hmmmm... Tom, are you suggesting that Tom Giammo has implied a discontinuation of support for his "Witness TMG Program"

 

P.S. If this is too subtle for viewers of this post, there are two Toms being referred to here. TomH is not the author of Witness, Tom Giammo is. So we (TomH and me) can only "wish" that TomG will enhance his program as we have discussed.

[Michael Hannah 0]

 

I wonder what RootsMagic would do with a standard CAUS tag?

RootsMagic ignores it, at least under an EVEN.

 

Well, so much for abiding by the GEDCOM standard.

[TomH 0]

 

Except that TMG allows unique sources for the witness tag and unique citations of sources common to the principal's events, does it not?

Not sure what you mean, Tom, but I don't think so. There are only one set of citations to a TMG tag.

 

My error, especially given that RootsMagic's "shared events or facts" behave the same way. Forgive me - I am an utter novice with TMG and have no intention of becoming expert.

 

That said, this discussion may prove to be just wishful thinking.

Hmmmm... Tom, are you suggesting that Tom Giammo has implied a discontinuation of support for his "Witness TMG Program"

 

I really should let TPG answer that but he developed it for his own purpose and is sharing it with us.

 

 

I guess one should add Sources to that, also...

I wouldn't. I think the purpose of this custom "Witness" event is to refer back to the Principals' event, where the source(s) would be fully cited. So I don't see a need to duplicate.

 

I will reiterate the other reason and emphasize the convenience for both the author in editing such events within the database into a satisfying shape and for the reader in finding the cited evidence for a non-principal:

If reading a report about a person, one would prefer, I suspect, to have a footnote or endnote that is referenced from the sentence or phrase about the person's role in somebody's wedding and not have to look up the principal to find the evidence.

That said, ...

[TPG 0]

I presume this EVEN structure is added as part of the INDI structure of the person who is the witness? And is the Prin1/Prin2 output the names or the INDI numbers of the Principals? Or both? And if a name, is it their Primary name or the TMG selected name for that TMG tag?

 

Also, note that the GEDCOM standard limits the text following TYPE, which it calls the EVENT_DESCRIPTOR, to a maximum of 90 characters. If the role name, event type, and Principals' names are long there may be a danger of exceeding this limit. I was wondering if also using the GEDCOM subtag CAUS as part of this special EVEN structure might be useful. It also allows (another) 90 characters and might limit the likelihood of exceeding the maximum text length for either tag.

 

Finally, I think the separate TMG Witness Memo also needs to be output, which might be put in a NOTE. Just brainstorming off the top of my head, but perhaps something like the following would work:

 

1 EVEN

2 TYPE Witness: for [Prin1] and [Prin2]

2 CAUS [role] in [eventtype]

2 DATE [date]

2 PLACE [place]

2 NOTE [Witness memo]

 

Let me first establish some context in which witnessTMG was written. I wrote it originally for my own use and it was intended to massage the gedcom input for my own Progenitor 4 program by adding witness statements. Progenitor 4 is an elaborate and sophisticated genealogy display program that is ultimately an evolution of the original Progenitor 2 from the late 1990s. Progenitor 4 takes gedcom input and produces an entire website for uploading, much as Second Site does from TMG file input but without some of the bells and whistles. Some of the more minor design choices in witnessTMG were driven by the need to serve furnish input to Progenitor 4. (If you are interested in seeing the output from Progenitor 4, please go to http://www.crestline-enterprises.com/genealogy/giammoFamily/wg_Advanced.htm. I'd advise you to look at the GUIDE before proceeding to gain some familiarity with its capabilities.) Jim Byram and Tom Holden convinced me to revise and release witnessTMG, Tom Holden was also very helpful in testing the revisions and ascertaining that it ran with TMG version 9 project input files.

 

Now, let me answer your specific questions -

 

* Yes, the WITNESS statements are inserted as part of the INDI structure of the relevant individuals.

 

* [Prin1] and [Prin2] are the "N:srnamedisp" full display names of the individuals.

 

* I was aware of the limit of 90 characters, but did not believe that it would be a serious limitation - at least not in the application for which it was intended. Although the maximum size of each of the fields might cause an overflow of the 90 characters, the "role" and "eventtype" fields are relatively small and shouldn't make that much of a difference. Thus, I am reluctant to make use of the CAUS statement, which is also not how the gedcom standard envisions its use.

 

* Your use of the NOTE field implies that witnessTMG would have to parse the [witness memo] and insert substitutions for the various sentence variables. That is beyond what I am willing to do.

[Michael Hannah 0]

Thanks, Tom, for your explanations. And thanks again for sharing your program.

 

No, I did not mean to imply that the [witness memo] "necessarily" would have to have variable substitution. Although parsing "would be nice", just output of the actual text in the witness memo, complete with variables and split memo characters, might be sufficient for many users purposes. At least that way this separate TMG data would not be completely lost.

 

As for CAUS, the GEDCOM standard says: "Used in special cases to record the reasons which precipitated an event." We would probably both agree that how various GEDCOM tags and fields are used by existing programs often stretch their apparent envisioned use in the standard. Since this "Witness" event is a custom event, I don't see it as much of a stretch to view the person having a specific role in an event being the "cause" of generating this event. While that is a matter of opinion, it is probably moot since I have discovered many programs ignore this CAUS standard GEDCOM tag type on import.

 

Much more valuable is simply to have your program which reads the TMG files and outputs additional valuable data as some form of GEDCOM which would otherwise be lost. As the other Tom has noted, having it as GEDCOM also allows it to be easily parsed and modified to suit a different purpose than as input your Progenitor 4. Thus our appreciation for your sharing it.

 

Thanks for listening,