* Do TMG Custom Tags go to FH Attributes or Events?

[MartinR]

Planning/Trialing TMG (8.08) direct import to FH ...

How does FH 6.2 choose between importing a TMG Custom Tag as an Attribute or as an Event? Or does it? I have a number of TMG Custom Tags (including Anecdote, Event-Misc, and, confusingly, Note) which would ideally be imported as Attribute Facts, with their Attribute Values derived from their associated Memos. To that end I select the appropriate (first) Custom Option on the Direct Import Wizard.

However, all these Custom Tags seem to come across as Event Facts (or at least without editable Attribute Value Fields). The Memos come across as Notes attached to the Facts, but the consequence is essentially uninformative row entries on Property Box Facts-tab Data Panes.

I've tried predefining the anticipated target Fact Types as Attributes, but those seemed to be ignored on Import, with the tags still going to Event Fact Types of the same name.

Standard Tags (e.g. Occupation, Residence) do seem to work as intended. I have to admit that, atm, I can't actually see how FH is supposed to choose. The Import Guide sort of implies that there could be a choice, but maybe that only applies to Standard Tags?

[tatewise]

Whether a custom fact is an Event or an Attribute is determined by their GEDCOM definition in the TMG Master Tag Type List.
All the standard facts have standard GEDCOM tags that are automatically either an Event or Attribute.

A custom event has the tag EVEN and in View > Tag Type Definition its General tab Label is applied to a subsidiary TYPE tag, so if it were represented in GEDCOM it would look like:
1 EVEN
2 TYPE Event-Misc

In FH a custom attribute has the tag _ATTR because GEDCOM v5.5 does not allow custom attributes.
In GEDCOM v5.5.1 a custom attribute has the FACT tag that can have a value.
Does TMG allow the GEDCOM tag to be either _ATTR or FACT instead of EVEN?
I suspect not and so does not support custom attributes, and it puts the 'value' in the Memo which is imported to FH as the fact Note field as for an Event.
Occupation, Education, Religion and other standard Attributes import the Memo as the value, but that is a special case for known standard Attributes. However, that goes wrong for Education as TMG puts the establishment in the Place and the Memo really should be a Note

So a solution involves using the Change Any Fact Tag plugin to convert each imported custom Event to be a custom Attribute with the same name and use another plugin to move the Note text to the Attribute value.

[Ron Melby]

if you want to know all tags in your gedcom, and how many copy this making a plugin:

standard tags have no prefix.
EVEN tags prefixed by EVEN-
ATTR tags prefixed by _ATTR-

Code: Select all

local tTAG = {}

function rtvTAGS(ptr)
  local ptrTAG  = fhNewItemPtr()
  local ptrENT  = fhNewItemPtr()

  ptrENT:MoveToFirstChildItem(ptr)
  while ptrENT:IsNotNull() do
    ptrTAG:MoveTo(ptrENT)
    local TAG = fhGetTag(ptrTAG)
    if tTAG[TAG] then
      tTAG[TAG].NBR = tTAG[TAG].NBR + 1
    else
      tTAG[TAG] = {NBR = 1}
    end
    ptrENT:MoveNext()
  end
  return
end

function matDOC()
local tblTAG = {}
local tblNBR = {}

for k, v in pairs(tTAG) do
  table.insert(tblTAG, k)
  table.insert(tblNBR, v.NBR)
end

fhOutputResultSetColumn('TAG',    'text', tblTAG, #tblTAG, 128, 'align_left', 1, true)
fhOutputResultSetColumn('NBR', 'integer', tblNBR, #tblNBR,  24, 'align_right')
return
end

local ptr = fhNewItemPtr()
ptr:MoveToFirstRecord('INDI')
while ptr:IsNotNull() do
  rtvTAGS(ptr)
  ptr:MoveNext()           
end  

matDOC()
return

[tatewise]

Ron, I don't think Martin has purchased FH yet, so Plugins are not supported.

[MartinR]

Well, I've experimented with a couple of other angles, such as slipping the TMG Custom Attributes through under the guise of currently unused FH Standard Attributes (such as Religion). That handled one such attribute value correctly, but I don't think there's enough such unused Attributes for the job, and certainly not enough if any unused 2-person (Family) Attributes that I could see.

So, given that, the time has come for me to stump up, so that I can start playing with plug-ins, starting with Ron's code

Oh, and I believe you are right, Mike. TMG wouldn't permit _ATTR as a GEDCOM TAG, and specifying FACT or just ATTR had no effect.

[tatewise]

Using spare standard Attributes as surrogates would have been a neat trick, but there are only about a dozen in total, and there are no standard Family Attributes at all.

I would not expect ATTR to work at all, but what exactly happened with FACT when you say it had no effect?
Did FH not import anything at all for those tags, or did it still import an Event, or what?

[MartinR]

No effect on FH, in that FH still imported both Event-Misc tags and Anecdote tags as Events. On the other hand, TMG no longer exported them in GEDCOM!

Also, earlier today, I modified a TMG Custom Tag Type definition for Note to have label Diary and GEDCOM 1 EVEN 2 TYPE Diary. Although the tags were now listed as Diary tags on TMG's Person View, they still appeared as Note facts on direct import into FH and on export to GEDCOM. IIRC, when created anew, Diary tags ported more as expected as Diary (Event Facts) to FH and GEDCOM.

I'd have to repeat the exercise to be more precise, but, given the above, I have the suspicion that changes to a TMG Tag Type Definition via its Edit menu occur at a level which may be bypassed or ignored by FH direct import and, at least in the case of the custom Note tag, by TMG's GEDCOM export.

All of which leads me to anticipate that trying to modify Tag type definitions at the TMG side of this activity might not contribute anything to this exercise.

[tatewise]

I am not sure how the TMG database files are managed, but it may be necessary to save everything and close TMG before everything gets updated. Remember, FH direct import uses TMG database files which may not be the same as that displayed in TMG while changes are in progress. It would be novel if TMG did not apply Tag Type List changes retrospectively.

The same is true of FH. Its GEDCOM database file is not updated immediately following a change.
You must manually use Save or wait for the AutoSave every 5 minutes.
I think Microsoft Word is similar. Its DOCX file does not update until you perform a Save unless AutoSave is enabled but even then there is a few seconds delay.

[MartinR]

Did I remember to close TMG each time? Well, I thing I did, but I can't be sure, so I thought it might be informative to repeat the tests with rather more rigour. So ...

* Running TMG 8.08, FH 6.2.7
* On TMG, when initially created, GEDCOM codes for Custom Anecdote and Event-Misc tags were defined as 1 EVEN 2 Type <name>, and for the Diary tag as Tag: NOTE
* Prior to the tests, FH Fact Types were checked via a trivial project, and any Custom Fact Types deleted
* On each test, TMG was closed down prior to FH direct import and then reopened for TMG GEDCOM export
* FH direct import was with Custom Options = First Sentence, Memo Always, Incl as Witnesses

Test A/A1.......................TMG Tag Type GEDCOM Def.......FH Fact Types List ........TMG GEDCOM *
........................ Diary ..................... FACT ................................ Note Event ** ................... Missing
........................ Anecdote ............. FACT ................................. Anecdote Event ................ Missing
........................ Event-Misc ............FACT ................................ Event-Misc Event .............. Missing

Test B/B1.......................TMG Tag Type GEDCOM Def.......FH Fact Types List ........TMG GEDCOM *
.........................Diary .............. 1 EVEN 2 TYPE Diary ............. Note Event ** .......1 EVEN 2 TYPE Note
.........................Anecdote ...... 1 EVEN 2 TYPE Anecdote ...... Anecdote Event .....1 EVEN 2 TYPE Anecdote
.........................Event-Misc .... 1 EVEN 2 TYPE Event-Misc ... Event-Misc Event .. 1 EVEN 2 TYPE Event-Misc

* TMG Gedcom Export was for 1 selected Individual using all 3 tags

** On TMG, two other Tags had previously also been created with GEDCOM code Tag: NOTE, and previously these imported into FH as Event Facts with Labels Note1 and Note11. I changed the TMG Tag Def GEDCOM codes for these tags to other unique values (TASK & NOWD), but nevertheless on import by FH they still listed as Note1 and Note11 Event Facts. I've deferred looking more closely at these tags for the time being.

I think these results are consistent with my previous tests. If TMG Tag Type Definition property modifications are not immediately percolated down to Tag records but rather left to be inherited at the time of access, that could imply a data structure capable of being mis-read in the above manner. But that's just a guess. And one which, with the help of FH and Plug-Ins, I will not need to explore further.

[JohnnyCee]

When you make a change to a TMG Tag Type, the effect is immediate. Tags (names and events) keep a pointer to the Tag Type record and so there is no need for TMG to update tag instances due to a change to the Tag Type record.

There may be an exception related to deleting roles, but that's not an issue here. I don't remember if TMG will allow you to delete a role that is in use, but if it does, it would have to update the records that use the deleted role and reset them to Role=Principal or Role=Witness (the two roles you can't delete).

[tatewise]

That is what I thought would be the case, but Martin's experiments suggest differently and cannot explain why.

[DonF]

Martin - closing down TMG and re-starting it will not have the slightest affect on what you're seeing. As you haven't mentioned it, I suspect you are not performing a Maintenance->Reindex, and that is probably the cause of your problem.

And to answer the other question raised by JohnnyCee, no, you cannot delete a Role that is in use.

Don

[tatewise]

Yes, it says that in the Import from TMG advice how_to:import_from_tmg#tmg_tips|> TMG Tips but I forgot to mention it to Martin, and that may make all the difference.

[MartinR]

OK. To test this out,

* I took 3 TMG Tag Types (Note-TMG, NoWorkDone, & Task) which all had TMG GEDCOM export as Tag: NOTE
* I changed all 3 to TMG GEDCOM export 1 EVEN 2 TYPE < Note-TMG, NoWorkDone, Task >
* I exported the GEDCOM from TMG, and reimported the database into FH
* I checked the Tag Types in GEDCOM and they were 1 EVEN 2 TYPE < Note, Note11, Note1 > !!
* I checked the Fact Types in FH, and they were also < Note, Note11, Note1 > !!
.
* I ran TMG Maintenance Reindex + Optimise + VFI and then closed TMG
* I reimported the database into FH, reopened TMG, and reexported the GEDCOM

* I then checked the Tag and Fact Types as above, and they remained the same as above.

Conclusion - In response to a Tag Type definition change, TMG does change its GEDCOM output, for these tags at least, from Tag: Note format to 1 EVEN 2 TYPE tag-name format. That said, for these tags, it generates its own GEDCOM output tag-names based on "Note". FH accesses these same names. TMG Maintenance Reindex made no difference.

That said, I have worked past the OP anyway, ...

1) I have discovered the Advanced Options in FH Fact Type definition! These enable me to get a FH Custom Event Fact Memo/Note displayed as a row entry on a Facts-tab Data Pane, and elsewhere. A couple of little quirks, but essentially this reduces / eliminates my need for Custom Attribute-like functionality.

2) Creating TMG replacement Tag-Type definitions (rather than modifying copies of existing ones) seems to result in as-intended GEDCOM export tag formats names and FH import Fact Event definitions. So this is what I have been doing, and I am taking the "opportunity" to reclassify / rework the affected TMG tag entries at the same time. My "researcher" has been rather "creative" in her use of these tags, and they certainly need the rework. Hopefully they'll all be the better for it.

So my next task will be .. what to do with the "speculative" variants of structural TMG tags that I created (Birth-???, Marr-???, Death-???, etc), and will they also fall foul of the above behaviour? .... Tomorrow's job, I think ...