Family Historian User Group

In my initial posting in GEDCOM 5.5.1 Standard Release Nov 2019 (17327) I asked:
"So where will that put FH with respect to be 100% GEDCOM compliant?"
If Calico Pie would comprehensively answer that, then our future options might become clearer.
A comprehensive answer would deal with these discrepancies between 5.5 and 5.5.1 and how they will be handled.

I am still a little confused as well.

Just to clarify, are we talking about impacts to Note boxes for Facts, or, Note boxes for Citations? Sounds like it only impacts Citation Note boxes, but I would like to know for sure.

I have attached a screenshot showing the 2 boxes in question.

Bob, neither in normal operation.

In the 5.5 spec you could also add sources to the notes. This could be done on any notes anywhere in FH, using the All tab.

The 5.5.1 spec does not allow you to add sources to notes so you would need to add them to the item the note is attached to. In normal practice in FH this only applies to Notes entered on the Notes tab directly, those with blue or red dots or a note record icon.

If FH adopts 5.5.1 in the next release, I suspect it will still support sources against notes using one method or another as the standard allows programs to add their own extensions and it's already announced that source links will be allowed within notes.

I'm not sure Jane saying "neither in normal operation" helps clarify things, as her next statement talks about "any notes".

Note fields themselves are NOT affected. You will still be able to use all the Note fields in 5.5.1 the same as now in 5.5.

What changes is the ability to add a Source Citation to a Note field, and that impacts every Note field.

It is only record level Note fields (those on the Main tab of most Property Boxes and on the Notes tab) that can easily have a Source Citation added via the yellow Sources For pane, and that is what most of this thread discusses.

The fact and citation Note fields (such as you highlighted) can only have Source Citations added via the All tab, so very few users would have done that.

Bob - a picture is worth 1,000 words so... The sort of Note that is the real problem under a correct implementation of 5.5.1 is the one starting "Constance's father..." (The "Lottie Cowsill" note is also affected)

It's on the Notes tab for an Individual (it could also be on the Note tab for a family), so it's not subsidiary to a fact or to a citation. Nor is it a free-standing Notes record (which can be shared).

You'll note that I have actually recorded a Source against this particular note to show that the information comes from Constance's marriage record. Why not record it against the chap in question? Because I don't tend to record parents of people who marry into my family - it just adds extra branches for people who I'm not going to research properly.

The problem with a correct implementation of 5.5.1 (with no extensions) is that I wouldn't be able to cite that source in the yellow pane as I have done. Sure, to answer others, I can get round recording the source in the future by writing it in free form text but what do I do about the ones that I already have? That's why I would hope that Calico Pie if, if, IF, they intend to go for 5.5.1 compatibility (and we have no reason to assume that they will) will do some sort of conjuring trick to not wipe out my citations at this level.

(As is said above, other types of Notes are also affected but very few people will, we believe, ever have entered data that will be affected. Note Records (Shared Notes) are not affected by the possible change.).

I have quite a few notes like these that I use to place contextual information, for example, to help explain apparent discrepancies between a fact and the supporting source citation. This may occur, for example, in situations where name changes take place and a fact may relate to an individual with one name, but where the source citation might refer to the same individual, but using a different name.

mezentia, Notes in themselves are NOT a problem.
The potential problem is only if there is Source Citation linked directly to the Note as shown in Adrian's screenshot.
i.e. The Sources For pane says Note* or perhaps something like (<fact> Note*)

Like this?
If there were source citations attached to the notes with the red dot or calendar icon, would they also be affected in the same way?

Yes, like that for blue dot Individual record Notes, and red dot Family record Notes.
i.e. The Sources For: box ends with Note* or Note[n]* to show it is a Note field Citation.

But NOT the calendar icon Notes as in those cases the Sources For: pane shows the Fact Citation.
i.e. The Sources For: box doe NOT end with Note*.

Also NOT for yellow folder icon Note Record entries that are still allowed Sources For: Note Record citations in 5.5.1.

Thanks for the clarification, Mike. Now, as we all await the general availability of V7, it thus becomes of considerable interest to know if V7 conforms to the 5.5 or 5.5.1 standard. As V7 will offer the long anticipated text formatting capabilities, I for one will be eager to move to the new version as soon as possible. But, if V7 implements the 5.5.1 amendments to the NOTE structures, a solution to the problems discussed earlier is clearly needed.

best practice

The general guideline for obsolete features is that they should not be used. Applications should
not use obsolete features in the GEDCOM files they export. The general guideline for import
of obsolete features is that developers should not add support for obsolete features, but need
not remove any existing support either.

I found the above towards the beginning of the Release 5.5.1 standard which seems to imply that support for the 5.5 NOTE structure does not have to be removed.

The case for changing the definition of the NOTE structure is that it could lead to the creation of an infinite loop. However, in most standards definitions I have worked with (notably ODETTE and EDIFACT) this is often covered by defining a limit on the number of repetitions/recursions allowed, and although I have not studied the GEDCOM syntax in detail (life is too short) I would be surprised if a construct could not be made that allows notes a note to be added to a source citation, and where a limit to the degree of nesting of this is defined within the syntax. With de jure standards, one knows where representations may be made to influence changes to standards specifications, but in the case of a de facto standard, then this becomes less clear.

Where exactly did you find that quote from the Release 5.5.1 standard?
I have searched the PDF but cannot find that text.
BTW: I also search the 5.5.5 spec with no luck.

Mike, the quote is from page 6 of the file TFG551SAE Rev 1 2018-07-05.pdf downloaded from here:

https://www.tamurajones.net/GEDCOM551An ... tion.xhtml

and under the heading obsolete features. The quote is contained within a comment which gives me the feeling that this is not "offical" LDS guidance.

Ah, but that is NOT the 5.5.1 Specification, but just the opinion of Tamura Jones and 7 technical reviewers in his Annotated Edition.

As the first box says:
annotation
This is the first annotation in this document. It's purpose is to show what annotations look like; a
box with light yellow background and a grey shadow, clearly distinct from the main text.

BTW: I think you posted the wrong link which should be:
https://www.tamurajones.net/DownloadGED ... tion.xhtml
which links to https://www.tamurajones.net/downloads/s ... AERev1.zip for actual download.

How did CP finally implement this in FH 7?

If I remember correctly from beta testing, citations on Individual notes were still being supported in the program. What changes did they make to ensure GEDCOM 5.5.1 compliance?

Thanks!
Bill

CP have gone non-compliant as far as GEDCOM 5.5.1 is concerned.
That causes me a headache with the Export Gedcom File plugin because other products that are 5.5.1 compliant won't accept those Note field Citations.
BTW: The 'temporary' GEDCOM 7.0 specification re-introduced Note field Citations.

The only oddity I spotted is that when using Automatic Source Citations they are not added to new rich text Note fields.

I thank you all for these explanations, to a problem I don't think I have ever had. In my "simplistic" methodology of Sources rule and they create Facts I don't see the need for the extra layer of these, what I think are, unattached notes.

For me I just create a fact for everything, I have facts for Note, ToDo, Event-misc, Surety, Note_common_source (e.g. the repeated fact for various people could be linked to a source that affected them all, say an explanation of a family dispersal), etc.

But, as ever, I might be missing the point.

tatewise wrote: ↑08 Mar 2021 17:46 CP have gone non-compliant as far as GEDCOM 5.5.1 is concerned.
That causes me a headache with the Export Gedcom File plugin because other products that are 5.5.1 compliant won't accept those Note field Citations.
BTW: The 'temporary' GEDCOM 7.0 specification re-introduced Note field Citations.

Mike,

That is good to hear that it was back in GEDCOM 7.0. Now we will just have to wait and see how soon that will be approved and then how much longer for CP to make FH GEDCOM 7.0 compliant. I'm not holding my breath.

Out of curiosity, how did you change the plugin? Where did you put Individual note citations for those products that are 5.5.1 compliant or did you just drop them?

Thanks!
Bill

The Note Citations get repositioned depending on what the target product will allow.
Ideally, the Citation gets moved to the parent of the Note.
e.g.
If it is a local Note on a Fact then the Citation is moved up to the Fact.
If it is a local Note on an Individual then the Citation is moved up to be a <whole record> Citation.

In other scenarios, the Citation is added as Note to the parent, or unfortunately discarded.

jimlad68 wrote: ↑08 Mar 2021 20:20 ... I don't see the need for the extra layer of these, what I think are, unattached notes. ...

For me, one of the things that I want to do is provide sources for things such as free-standing notes containing histories of regiments, etc, or explanations of genealogically relevant processes, such as immigration or military pensions. Probably not a level of detail that everyone wants to go into, of course...

Adrian, I can see that, but for my "simple" methodology I would still add it as a source of info and attached to a fact to those individuals concerned, or if it was so generic/ broad, possibly create a john/Jane Doe so the source/note was not left floating in the "ether".

For instance, I have not used the new v6 place records (due to export incompatibility) and if I want a history of a place I create a stand alone Source for it, this can be for a Town, street, single address. When required this can be added as a source to a fact.

Jim, we are not talking about Notes floating in the "ether".
We are talking about the local Note box on the Individual (or any other) Main tab; the local Note box on each Fact; the local Note box on a Citation; etc. If they contain specific extra details obtained from a Source document then they can/should have their own dedicated Citation.
That is compliant with GEDCOM 5.5 (and 7.0) but not with GEDCOM 5.5.1 specifications.

Mike,

Thanks for the explanation.

Bill

CP have gone non-compliant as far as GEDCOM 5.5.1 is concerned.

That makes sense. They needed a solution that was backwards compatible, as it's customers that pay their salaries, not specification pundits. Perhaps they evaluated the type of custom workaround described here and ruled it out as too complex for automatically upgrading a V6 project to a 100% compliant V7 one.

To be super-critical, FH never was and still is not 100% compliant with GEDCOM specifications.
It is a good 'unique selling point' though and FH is among the best at GEDCOM compliance.
However, as with other products, there are so many compliant custom extensions that migration to other products is still a challenge apart from the core structures.

Am I correct in thinking that FH is the only significant desktop app that saves its data in GEDCOM format? For me, that makes it extremely robust, as data can always be retrieved and manipulated, whatever happens to the core program in the future. You can do the same with products like RM that are based on standard database formats, but it's not nearly as easy.