* Ancestry, FTM, FH and workflow

[Nick-V]

Yes quite right, and that's what FH does at the moment. I suppose the co-ordinates are the only difference UNLESS someone has added a "link to frame" note.

For now I would keep it simple and get something working. Tomorrow we might add functions to round trip the fields, later we might improve what FH provides today. Sure, in round-tripping we might just use co-ordinates somehow...will apply more thought later...

[Nick-V]

What might be more useful is:
=== **** tags: known and work fully untranslated ===
and
=== **** tags: known and work after translation ===

New example audit report uploaded to KB Progress Page...

Had to get CONC and CONT working...can now add data to Notes safely.

[tatewise]

Try the attached Export Gedcom File Plugn V1.7.6 with the following features in FTM mode.
It does not yet include everything you asked for, but your feedback would be welcome.

• UTF-16 encoding uses 1 CHAR UNICODE
• Part/Full/All media as either Local Media Objects or Absolute link Media Records
• 1 _PHOTO tag identifies preferred Media Record image in every Record type
  (Should it only be for INDIvidual and maybe FAMily records? - please confirm)
• All Media links use @M...@ instead of @O...@
• 1 CHAN tags removed
• 1 _EMAIL becomes 1 EMAIL
• 2 _USED becomes 1 ALIA
• 2 NICK becomes 1 ALIA
• 2 NPFX becomes 1 TITL
• 2 NSFX appended to 1 NAME
• SOURce ABBR Short Title becomes TITL or a NOTE

The next stage should include:
Place the _ROOT INDIvidual record first
Move INDIvidual whole record Citations to 1 NAME tag
Move ADDRess data to Event value
Move DIV CAUS data to Event value

[Nick-V]

Thanks Mike...I'll load it up and check. Looks like you've gone a lot further than just images!

Please remember my research is "in progress"...I just found my work on citations was mislead and there is another way forward. It's all evolving still...BTW, I don't know how far you want me to go with "asking" or specifying but I'm already and happy to continue trying to identify how data should translate even though my simple data works already...keen to get onto the return trip before we make the outgoing too complete tho!

Initial thoughts:
1) _PHOTO for INDI only. I can't see how FTM might allow attaching anything much (1 OBJE, 1 NOTE, 1 SOUR) to the FAM record. FAM events are attached using the INDI screen.

2) I'm not sure about SOUR, ABBR>TITL, doesn't SOUR already have a TITL? I suppose the options are remove, replace TITL append TITL or move to note (still need to check what can/not have notes). More comments in the posting below.

3) Looking at your next stages the only debate is the use of Value for ADDR or otherwise (e.g. CAUS). I like consistency and am currently thinking that ADDR should be moved to Value for all events but moved to NOTE for all attributes because they have a value. However, possibly this is a bit tricky with standard items (not EVEN or _ATTR) as we would have to list which is which. At FAM level they are all events but at INDI level we'd need to list one or the other (not a major problem I suppose). This is an example of where some thinking (spec) is not yet finalised and where the prototype helps to clear the mind.

Interesting...the clocks didn't change yet but the time of this posting is 1 hour later than reality. I'll check my control panel...EDIT: yep I had to switch off "summer time/DST is in effect".

[Nick-V]

Observations (using UTF-16 with BOM, All-Abs and tab2 simple settings).

1) Imports to FTM no errors (OK). File contains 1 CHAR UNICODE (not UTF-16).

2) Both part and full images visible in INDI window (OK). _PHOTO default applied to first image (OK) - note this should only be created where one doesn't already exist (depending on how we handle round trip).
Note: As mentioned, FTM does not appear to allow attachments (other than events) to FAM therefore any OBJE, SOUR and NOTE records at level 1 are discarded. Indeed, for INDI I suggested demoting 1 SOUR to 2 SOUR under 1 NAME to retain citations to whole record. Unfortunately FAM does not currently have an "event" that is mandatory (it can have no events/attribs) so what should we do with 0 FAM, 1 SOUR?

3) ADDresses moved to note however see thoughts above.
Note: Whilst FTM does something unique with DEAT, CAUS (makes CAUS at event) it appears to merge DEAT and CAUS back to normal on export. Probably done for hint matching reasons.

4) When coming later to citations, 3 OBJE links need to be added under 2 SOUR (for INDI and FAM) so they appear alongside citations. Existing links directly to SOUR should stay as is, therefore such objects are linked to from BOTH INDI, SOUR and SOUR. Places and repositories can't have objects.

5) CHAN tags removed (OK). Actually they are ignored on FTM import as are certain other tags so I'm not sure we need to be explicit (unless we are explicit about all tags to delete). The only tag that causes an error/issue so far is place records and of course these can be removed already. Personally I choose the Remove option whenever possible just to remind me that such data is not used (in my case).

6) _EMAIL>EMAIL tested on REPO only (OK). Not tested elsewhere.

7) Name handling: No comma is required to separate NAME from NSFX when appending NSFX to NAME (required: "John /Smith/ OBE") (NOT OK). Interestingly tho, it works with and without the comma but no comma is consistent with what FTM exports. NPFX, _USED, NICK all tested with two NAME entries (OK). To complete Name handling, a comma in the NICK should be replaced with " or " otherwise "Kat, Kitty" get imported as "Kitty Kat".

8) Source data handling: As mentioned above, I am unclear why one might want to move SOUR, ABBR to SOUR, TITL when there is already a TITL (unless you want to provide an option). I note that the Plugin already moves all other orphaned data (by lack of FTM fields) to the NOTE and this works well (example below).

0 @S79@ SOUR
1 AUTH Gustav Nathan
1 TITL Paul Dessau's Stammbaum
1 PUBL 1910-1912
1 REPO @R27@
1 NOTE Text From Source: Text from source
2 CONT Source Type: Family Book
2 CONT Short Title: Short Title
2 CONT Note it here
2 CONT Custom Id: Cust ID

So pretty nearly all good and certainly an excellent forward step. I think with the KB we need to refer to your latest release (however beta it is). In this way WE have a current record of "preferred" or "proven" runtime options and can delete/simplify notes where matters have been addressed...will get to it shortly...

[tatewise]

Following your advice, I am not very focussed on round-trip issues, until we understand better what gets into and out of FTM.

1. 1 CHAR UNICODE is the GEDCOM standard for UTF-16.
2. _PHOTO only for INDI records in next version.
   Note: Status of 0 FAM ~ 1 NOTE is has changed from unsupported, to supported, and now back to unsupported, so I cannot focus on solutions until that status is certain. Most records (not OBJE) appear to support 1 NOTE, which is my preferred vehicle for tags not supported by FTM. An alternative for INDI & FAM records may be a custom 1 EVENt.
3. 2 ADDRess data to Standard Event value is specific, no list needed, because Standard Events are defined by GEDCOM specification. The only exception is 1 DIV with a CAUSe value.
4. Understood, but tricky. The Plugin uses a 2 pass technique. The 1st pass collects details needed for 2nd pass. For example, 1st pass saves details from OBJEct Media records held near end of file, so 2nd pass can handle OBJEct links in INDI & FAM records, etc, earlier in file. So SOURce record OBJEct links must be logged in 1st pass, and inserted into correct Citations on 2nd pass.
5. 1 CHAN tags OK. 0 @P%d@ _PLAC records are removed by default.
6. 1 _EMAIL only allowed in REPOsitry records, nowhere else.
7. Next version will eliminate comma for NSFX after NAME.
   Must a comma in NICK become or even tho it has moved to ALIA?
   Does the same apply to a comma in _USED moved to ALIA?
   Does the same apply to a comma in NPFX moved to TITL?
   All the above have round-trip problems as the NAME suffix to NSFX, and ALIA to NICK/_USED, and TITLE to NPFX/TITL reverse mappings are indeterminate.
8. 0 SOUR ~ 1 ABBR is only changed to 1 TITL if there is no TITL as explained in plugins:help:export_gedcom_file:output_formats#family_tree_maker_2014|> Export Gedcom File ~ Output Formats ~ Family Tree Maker 2014. The 1 NOTE technique used here and elsewhere is my preferred solution to retaining round-trip data.

[Nick-V]

Yes, round trip can come later...just sharing.

Also yes, things are still evolving as new info comes to light. We are both mindful of trying to avoid development until there is sufficient certainty. That said, this is new to me, and I am "testing" alone, incompletely and at speed - the objective remains to see if the high level concept might fly...I have to avoid some detail for now to get to that point. I'm trying to be sensible - there's a balance to be found!

1) OK

2) Yes understood. A "Person Note" (INDI, 1 NOTE) is allowed but attachments to FAM don't appear to exist. I like the idea of a custom event to circumvent this indeed this would be a better way of dealing with 1 SOUR (citations) at INDI and FAM level.

3) OK perhaps my thoughts can work. All events send ADDR to Value and other data (_PLAC, CAUS) to NOTE. All attributes use Value and send ADDR to NOTE.

4) Yes, starting from scratch I took a slightly different approach to moving records about. On the first pass I store in level 0 arrays (INDI, SOUR etc) data that I may need to known in advance of doing a second sequential read/process of the file. Thus, when I encounter an INDI, event, SOUR (and its children) I simply lookup and create the arrayed OBJE records connected to that source. Your routine was developed with multiple uses in mind, the prototype looks at just one problem...not easy.

5) Yes all works fine...just saying that deletion of SOME records that don't need deleting is inconsistent and might be avoided if it simplifies things - really not an issue.

6) Thanks for confirming.

7) Good questions. NICK: a single comma causes the field content to be reversed and comma removed. I've not tried with multiple commas but yes I have replaced it with " or " and some trimming to manage odd spaces. _USER: yes you must be right that a comma would cause the same issue - I hadn't envisaged or tested that. NPFX: this raises concerns about what circumstances FTM does its comma thing...what about ANY field? I'll check some...Yes I am aware of the round-trip issues - options include reporting with "tough luck" for the few it might affect or something more elaborate if necessary.

8) I see that 1 NOTE worked fine with ABBR (all of my data had TITL). I didn't know that no title was an option so providing ABBR in it's absence is good (except for the round trip). I don't understand why users would have an ABBR and no TITL.

I've attempted to update the KB based on your latest version in an effort to simplify as we go.

[Nick-V]

Commas handling is a little inconsistent.

NAME: gets imported stripped of the comma into NAME
NSFX: gets imported stripped of the comma into a separate NAME (but we're appending it to an existing NAME to avoid this).
NICK: gets imported to ALIA with its comma (however we're using ALIA to work around the index no-show problem).
_USER does not get imported (but we're using ALIA to cater for this)
ALIA: gets imported to ALIA stripped of the comma and field reversed
NPFX: gets imported to TITL with its comma
TITL: gets imported to TITL with its comma

I suspect the NAME field gets processed so the comma gets stripped. The ALIA field also has some processing that causes reversal, could be to do with its normal use. The couple of normal fields took what they were provided.

At present I think we can just sit with the NICK>ALIA processing I mentioned: replace comma with rtrim(leftbit) & " or " & ltrim(rightbit)

[tatewise]

There is no problem replacing the comma (,) with or but how is semicolon (;) handled?
Perhaps also try some other symbols such as colon (:) and tilda (~) and hypen (-) that might legitimately appear in hypenated names.
If these are allowed, they might work better in more cases than or and might help with round-trip conversion back to original FH names.

FYI: Having been caught out by VERY large Projects before, my Plugin two pass process minimises what is stored and makes data retrieval run-time efficient. So it only ever holds one GEDCOM record at a time, and structures the data saved on 1st Pass for fast retrieval on 2nd Pass, especially since the same OBJEct data is retrieved for every Part Frame based on the same OBJEct record.

[Nick-V]

Yes we can look at other fields and characters in due course. I'm certain we can handle all that detail adequately. Indeed, FTM has its own way of delimiting/identifying data and I'm certain we can wrap things uniquely with a little thought.

Right now I am less certain about the big stuff (round trip, note records, citations etc)...I will try to keep myself to the main concept and the big questions first then work down.

Yes, your approach is memory efficient. I presume FH and FTM both hold the entire GEDCOM in memory.

[Nick-V]

Mike, I know we have quite a bit yet to do but I must say the data in FTM really looks quite good now.

Getting the part and full images in with _ROOT (plugin) and getting OBJE attached to citations (prototype) really make it start to feel more rounded!

The list of other issues and the detail behind them can continue to evolve. Indeed, it will certainly grow as I start to investigate the trip back. Already I've logged some reports with FTM including:

1. it would be nice if their own output file didn't error on import!
2. it would be nice if the citation data didn't depend upon the content of 0 HEAD, 1 SOUR (that one took a while to trace).

Good progress, thanks.

[tatewise]

FYI:
In the next Plugin version I hope to add the following features (in addition to those discussed) in an attempt to help preserve round-trip values.

1. Move all 1 NAME subsidiary tags to 0 INDI ~ 1 NOTE local labelled Notes that will also identify whether they belong to the 1st Primary Name instance or 2nd or subsequent instances.
   e.g.
   1~Given Name: Tony
   1~Nickname: Ant
   2~Nickname: Dec
   3~Name Prefix: Master
   This is in addition to agreed translations to 1 ALIA and 1 TITL and appending to 1 NAME.
2. Move all Fact 2 ADDRess data to Fact 2 NOTE local Notes labelled Address Data:
   To include all 3 CONC/CONT lines, and all subsidiary tags 3 ADR1, 3 ADR2, 3 CITY, etc.
   This is in addition to agreed appending of 1st line of 2 ADDR to some Event values.
3. Copy all Fact 2 PLACe details to Fact 2 NOTE local Notes labelled Place Details:
   This will include any subsidiary text tags.

[Nick-V]

Thanks for the info...only one matter really:

Moving ADDR (etc.) to the note works, however, the way FTM presents data makes the Description field (Value) an ideal place for it where possible.

Conversely, I support the desire to store perhaps ALL necessary FH fields in a note and in manner that can be reconstructed later.

I wonder if both matters can be satisfied...certainly if the ADDR was ALSO put in the Value where possible it would help although this then leads to the problem that the two could get out of step. Any thoughts on this?

[tatewise]

ADDResses are potentially quite complex beasts.
Firstly, the 2 ADDRess field can be multi-line extremely long text with 3 CONC/3 CONT tags (like NOTEs).
Secondly, it can have several subsidiary tags such as 3 ADR1, 3 ADR2, 3 CITY, etc, each with a short text value.
These will all migrate to the local Fact 2 NOTE for round-trip survival.

As agreed, and as confirmed in 2. below, some/most Standard Events will also have their Value set to the ADDRess, but I propose just the first line of the 2 ADDRess tag.

The import to FH process (Plugin?) would review the NOTE Address and the Event Value Address, and report/resolve any differences. If there is no NOTE Address then simply set the 2 ADDRess from the Event Value, but if they differ then an option could decide which takes precedence.

The problem of getting out of synch could apply to many fields. But if the orginal data is preserved in a NOTE (or elsewhere), then if associated data is returned to FH, the Plugin can compare the NOTE with the associated data to identify what has changed.

[Nick-V]

Ah ha so you are still moving ADDR (1st line) to value...and also dealing with complex addresses, indeed all data using a note...

Best of both...thanks.

[tatewise]

I have attached Export Gedcom File Plugn V1.7.6 and new V1.7.7 to how_to:exchange_with_ftm:step_2_create_a_gedcom_using_the_fh_export_plugin|> Step 2 Create a GEDCOM using the FH Export Plugin v1.7.6.

V1.7.7 has the following features in FTM mode, which I think covers almost everything discussed so far, except adjustments for Citations.

• 1 SOUR FTM instead of 1 SOUR FAMILY _HISTORIAN with its subsidiary tags removed
• UTF-16 encoding uses 1 CHAR UNICODE
• Part/Full/All media as either Local Media Objects or Absolute link Media Records
• File _ROOT INDIvidual record is placed first
• 1 _PHOTO tag for preferred Media image in INDIvidual Records
• All Media links use @M...@ instead of @O...@
• 2 _USED becomes 1 ALIA and comma becomes or
• 2 NICK becomes 1 ALIA and comma becomes or
• 2 NPFX becomes 1 TITL
• 2 NSFX appended to 1 NAME
• All subsidiary NAME tag values moved to a local NOTE with label prefixed with NAME instance, e.g.
  1~Nickname: Tony for 1 NAME 2 NICK Tony
  2~Name Prefix: Sir for 2 NAME 2 NPFX Sir
• SOURce ABBR Short Title becomes TITL or a NOTE
• 1 _EMAIL becomes 1 EMAIL
• 1 CHAN tags removed
• All PLACe details with subsidiary tags moved to a local NOTE
• Just the main PLACe tag and value is retained
• All ADDRess data with subsidiary tags moved to a local NOTE
• 1st line of ADDRess value copied to Standard Event value (if any)
• 1 DIV 2 CAUS data moved to Event value
• Temporarily, any Citation local NOTE is deleted

That leaves outstanding the Citation adjustments:
Move INDIvidual & FAMily whole record Citations to Custom Event
Copy SOURe record Media to each of its Citations
Move Citation local NOTE to Text From Source

[Nick-V]

Wow! A lot of enhancements. I've been buried in dealing with hints and am winning slowly. In the process I've learnt a little more about citations which I will write up soon. Give me a little time and I'll run thru all your hard work and comment properly. Its sounding good !

[Nick-V]

I'm building up this test list with a few comments so it's a WIP.

1. OK:FTM does not like files without BOM - a matter for user instructions
2. ?:Line 1251: error 8 : "CONT" subordinated to wrong item. Line ignored. It appeared 24 times against the same line so in one place only. Investigating what this is...
3. OK: _ROOT assigns home person
4. OK: " or " in NICK works under various conditions - other tags not tested
5. OK: ALL~ABS option for images works fine
6. OK 1 _PHOTO tag sets preferred Media
7. OK: both @M...@ and @O...@ work although M used on export
8. OK: 2 _USED, 2 NICK, 2 NPFX, 2 NSFX translated as expected
9. OK: 1~Surname:, 1~Given Name: etc. appear in Person Note (nicely tabbed)
10. ?: Into/From Place:, Place Details:, Address Data: appear in Fact Note. Should it be To/From rather than "Into"?
11. ?: Picture Note: (multiple times), Media Date:, Keywords: appear in Media Note. Need to consider where to put _ASID, _AREA etc.
12. OK: Short Title:, Source Type:, Text From Source: Custom Id: appear in Source Comments (tabbed)
13. ?: SOUR, ABBR did not become TITL in my data - perhaps it only occurs when TITL is null. Perhaps it should always be a note not "or"
14. OK: CHAN etc gone.
15. ?: Address Data:, Place Details: appear in INDI and FAM Fact Note. Why "Place Details" when there is a specific field for it?
16. ?: Address line 1 copied to Fact Description for all standard FAM facts (which are events) and some INDI Facts. Is it not reasonable to also copy EVEN (custom event) ADDResses too (if not already)?
17. OK: _STAT value put in _STAT value (perhaps by FTM) - we need to avoid _STAT for display cursor issues - discuss
18. ?: "cause: div cause;" (note ";" and lower case) appears in Divorce event value (FTM or Plugin?). Probably better if CAUS was put into the note like other data and Value left for ADDR to be consistent.
19. OK: 1 SOUR FTM allows OBJE, NOTE to work correctly
20. ?: REPO, EMAIL imports correctly. There is no REPO, NOTE so WWW could be appended to EMAIL or possible use made of the large address field instead of NOTE

Other notes:

1. I'm uncertain why citation notes are deleted temporarily - will apply thought later.
2. I lied: Census events ARE imported (and ADDR etc work as expected).
3. Other minor thoughts marked "?" above.
4. KB updated although work continues identifying issues...

[tatewise]

1) That is quite normal. Many programs require the BOM.
2) Awaiting your investigations.
10) Uses From: for IMMIgration & Into: for EMIGration.
I prefer Into: over To: because the tabulation works better.
11) _ASID & _AREA could go in Media Note now it works OK.
Although _ASID already in image filename prefix, and isn't needed to recreate part frames.
13) Yes, as said before, SOUR _ABBR Short Title becomes Title only if no TITL.
Thought it better to give SOURce a Title than leave untitled. Some users don't use Title at all.
15) Place Details include main PLACe field & subsidiary tags:
3 FORM Place Hierarchy, 3 SOUR Citation, 3 NOTE Record &/or local Note.
The main PLACe field is also retained for normalisation in FTM.
Then when returned to FH both FTM PLACe and Place Details in Note can be reconciled.
16) ADDRess line copied to value of ALL Standard Gedcom Events (i.e. not Attributes) (except DIVorce) as requested in KB Step 2.
Custom EVENts derived from FH custom _ATTRibutes take attribute value.
Those derived from FH custom EVENts could take ADDRess value.
BUT how does FTM differentiate these two different types of value for the same EVEN tag? Investigate.
17) _STAT currently retained by Plugin as no clear requirement.
At one stage FAM local NOTE was thought unavailable.
The existing Move to Record Note option could be FTM default.
18) KB Step 2 requested DIV value to be CAUS but format unclear.
Plugin can do what you request, but I though FTM took DIV value as CAUS not ADDR?
20) OK. REPO, ADDRess field could already be in use.
But can append labelled line similar to labelled Notes for _WEB address.
Or can append to PHONe tag (existing option) if FTM supports PHON?
If PHONe not supported, then it also needs appending to ADDRess.
As do NOTE tags and their subsidiary tags.

1. Plugin deletes Citation NOTEs as I thought they upset FTM imports.
Will also be deleted in next version, when moved to Text From Source.

[Nick-V]

Mike...not been through your response yet because struggling with number 2, the import errors. Looking for clues...

1. I get: Line 1251: error 8 : "CONT" subordinated to wrong item. Line ignored.
2. It occurs 24 times.
3. I presumed it found 24 items together at that file position however when it runs it quickly finds 16 then another 8. There is nothing onerous at line 1251.
4. The end summary reports 12 sources where there are 9...not even 12 links to sources! Interesting that 12x2 = 24 but no dice.
5. There happen to be 24 0 REPO, 1 NAME and 1 EMAIL tags but I see nothing obvious and even tried removing an entire REPO.
6. I see nothing obviously wrong with the imported data.
7. I'm now chopping out chunks of the file to see what changes!

Any good ideas?

[Nick-V]

If I am correct, it's because the NAME details being moved to the 1 NOTE need to be written before any citation for that 1 NOTE?

The issue lies in these lines for an INDI:

Code: Select all

1 NOTE Studied under Schradieck (Hamburg and Leipzig), Joachim and Wieniawski (Berlin). Gave Paul Dessau his first violin when age 6. One of his old violins sold for £70-90k at Sotherbys (Nicola Gagliano Filius Alexandri fecit. Neap. 1738). Taught Marl
2 CONC ene Dietrich Piano and Violin. Taught others also in Rotterdam. One of the three leaders of the Berlin Royal Orchestra. Member of famous trio: Heinrich Grünfeld (cello), Bernhard Dessau (violin), Moritz Mayer-Mahr (piano).Possible derivation Des
2 CONC soux.
2 CONT 
2 CONT Bis 1918 besucht Marlene Dietrich die Auguste-Victoria-Schule in Charlottenburg und macht dort das Abitur. Neben der Schule erlernt sie das Violinspiel bei Professor Dessau.
2 CONT 
2 CONT Schiller-Theater Charlottenburg
2 CONT 30 January 1921: Sonntag-Mittags-Konzerte. Zweites Konzert, given by a string quartet of Waldemar Lütschg, Bernhard Dessau, Robert Könecke and Fritz Becker, with Claire Huth (vocal), accompanied by Max von Schillings [42]
2 SOUR @S1@
3 PAGE Where
3 DATA
4 DATE 1 JAN 2001
4 TEXT Text
3 QUAY 3
2 CONT 1~Given Name:	given
2 CONT 1~Name Prefix:	Prof
2 CONT 1~Nickname:	Baer
2 CONT 1~Name Suffix:	suffix
2 CONT 2~Given Name:	alt given
2 CONT 2~Name Prefix:	alt npfx
2 CONT 2~Nickname:	alt nick
2 CONT 2~Name Suffix:	alt nsfx
1 RFN 36534016

The input file looked like:

Code: Select all

1 NOTE Studied under Schradieck (Hamburg and Leipzig), Joachim and Wieniawski (Berlin). Gave Paul Dessau his first violin when age 6. One of his old violins sold for £70-90k at Sotherbys (Nicola Gagliano Filius Alexandri fecit. Neap. 1738). Taught Marl
2 CONC ene Dietrich Piano and Violin. Taught others also in Rotterdam. One of the three leaders of the Berlin Royal Orchestra. Member of famous trio: Heinrich Grünfeld (cello), Bernhard Dessau (violin), Moritz Mayer-Mahr (piano).Possible derivation Des
2 CONC soux.
2 CONT 
2 CONT Bis 1918 besucht Marlene Dietrich die Auguste-Victoria-Schule in Charlottenburg und macht dort das Abitur. Neben der Schule erlernt sie das Violinspiel bei Professor Dessau.
2 CONT 
2 CONT Schiller-Theater Charlottenburg
2 CONT 30 January 1921: Sonntag-Mittags-Konzerte. Zweites Konzert, given by a string quartet of Waldemar Lütschg, Bernhard Dessau, Robert Könecke and Fritz Becker, with Claire Huth (vocal), accompanied by Max von Schillings [42]
2 SOUR @S1@
3 PAGE Where
3 DATA
4 DATE 1 JAN 2001
4 TEXT Text
3 QUAY 3
3 NOTE Note
1 RFN 36534016
1 CHAN
2 DATE 22 MAR 2015
3 TIME 20:36:56

[Nick-V]

Sorry when things change along the way...its not a straight path...trying to avoid frustrations...

16 and 18) I'll try to clarify ADDR and FTM's use of CAUS. For DEAT it creates a CAUS event which on export it puts back as a sub tag of the DEAT event - no action required. On DIV, CAUS it does nothing special. At some point I mentioned using Value for DIV, CAUS however the latest thinking is a) put all event (not attr) addresses in values b) put everything else in notes formatted for reconstruction - a more complete and consistent approach. Sound sensible?

20) REPO supports NAME, ADDR, PHON and EMAIL...no notes...that's it. NOTE, CONC, CONT, REFN and putting "Website Address:" in a NOTE will not work. On screen the ADDR is a multi-line field so MIGHT support notes. I'll throw data at this and edit here with results.

1) Yes, thanks for reminding me about citation notes...mental overload !

All the rest good and understood, thanks.

Still clarifying Citations in another thread...

[Nick-V]

REPO data is maximised as follows (both export and reimport checked):

NAME 388 chars of data
ADDR 945 chars
EMAIL 566 chars
PHON 496 chars

Will try CrLf in the address: results, separate lines can be entered but on export CrLf do not exist, CONT records do not exist and on reimport the field displays one long string. This means ADDR can be used for data but it will not format properly (separate lines and tab will not work).

So, what is the best way to preserve NOTE, CONC, CONT, REFN and _WEB (or whatever) ?

Code: Select all

0 @R9@ REPO
1 NAME London Library (for Berlin Jews books etc.) more name more name more 
2 CONC name more name more name more name more name more name more name more 
2 CONC name more name more name more name more name more name more name more 
2 CONC name more name more name more name more name more name more name more 
2 CONC name more name more name more name more name more name more name more 
2 CONC name more name more name more nEND
1 ADDR 14 St James's Square, London SW1Y 4LG More address More address More 
2 CONC address More address More address More address More address More 
2 CONC address More address More address More address More address More 
2 CONC address More address More address More address More address More 
2 CONC address More address More address More address More address More 
2 CONC address More address More address More address More address More 
2 CONC address More address More address More address More address More 
2 CONC address More address More address More address More address More 
2 CONC address More address More address More address More address More 
2 CONC address More address More address More address More address More 
2 CONC address More address More address More address More address More 
2 CONC address More address More address More address More address More 
2 CONC address More address More address More address More address More 
2 CONC address More address More address More address More address More 
2 CONC address More aEND
1 EMAIL http://www.londonlibrary.co.uk more email more email more email more 
2 CONC email more email more email more email more email more email more 
2 CONC email more email more email more email more email more email more 
2 CONC email more email more email more email more email more email more 
2 CONC email more email more email more email more email more email more 
2 CONC email more email more email more email more email more email more 
2 CONC email more email more email more email more email more email more 
2 CONC email more email more email more email more email more email more 
2 CONC email more email more emEND
1 PHON +44 20 7930 7705 more phone more phone more phone more phone more 
2 CONC phone more phone more phone more phone more phone more phone more 
2 CONC phone more phone more phone more phone more phone more phone more 
2 CONC phone more phone more phone more phone more phone more phone more 
2 CONC phone more phone more phone more phone more phone more phone more 
2 CONC phone more phone more phone more phone more phone more phone more 
2 CONC phone more phone more phone more phone more phone more phone more 
2 CONC phone more phone more phEND

[tatewise]

2) CONT problem with NAME details in NOTE.
Perfectly legal Gedcom that imports OK into FH.
If FTM does not support such basic Gedcom we could be in for more problems.
Will see if Plugin can workaround this particular case.

16) & 18) I certainly prefer are more consistent approach.
Simply thought that FTM demanded DIV CAUS.
Are you saying every CAUS value should move to NOTE or kept in CAUS?
Theoretically, every Fact can have a CAUS value, but is only popular with DEATh.
What about custom EVENts derived from both FH custom EVENts and also FH custom _ATTRibutes with a value?
Are you saying always put ADDRess value in EVENt value and move _ATTRibute value to NOTE?

20) REPO could impose limitations on round-trip success.
Other things to try:
1 NOTE @N99@ link to NOTE Record?
Multiple instances of 1 EMAIL and 1 PHON and perhaps 1 ADDR?
If so, then how many instances allowed?
i.e.

Code: Select all

0 @R99@ REPO
1 NOTE @N99@
1 NAME Repo Name
1 EMAIL abc@internet.net
1 EMAIL xyz@yahoo.com
1 PHON 01234 56789
1 PHON 09876 54321
1 ADDR Address1
1 ADDR Address2

[Nick-V]

2) I haven't seen other problems and don't know the spec but I do understand why a 2 SOUR and children would be odd appearing in the middle of a NOTE and its CONC/CONTs. I'd don't want to bash the FTM guys too much

16/18) Yes in a word. The exception (which we ignore) is DEAT, CAUS which FTM does things with and undoes later. I do agree that always moving event, ADDR to Value (even custom events) and moving their other flags to a note is best. Alongside that always moving attribute, Value to Value (even custom attributes) and moving their other flags to a note is best. It seems a reasonable rule with no exceptions?

20) I'll play with it and get back...