* Recording the sources for a relationship.

[rakow]

The main goal of genealogy is to figure out the relationships between people.

Is there a good way in Family Historian to record the sources for a given relationship? I'm looking for a way to link the sources that convince me that a person is the child of a particular couple.

For example, I might have an obituary that lists someone's children, without giving birth dates or birth places. On the other hand, I might have a source that gives someone's birth date, but doesn't give their parent - that second source clearly attaches to the birth event. The obituary should attach to some sort of relationship attribute? But I don't see a suitable attribute in the existing list.

In the "Pedigree" DOS program I solved this problem by having a "parentsource" field where I could link sources that tell me someone's parents, and a "fathersource" and "mothersource" field where I could put sources that give me one parent. How would I do something similar in Family Historian? I've upgraded to v7, so customisations are possible.

[tatewise]

That citation case is covered in the FH cunningly entitled Help page How to Cite Sources for Relationships.

[elevator]

This was one of my main problems/complaints with FH when I moved from TMG. Documenting relationships is literally the most important aspect of genealogy and it is baffling that GEDCOM doesn't explicitly allow for this. That said, Mike has linked to a good article, and this is exactly the method I am using now as well. One caveat is that you have to make a habit of always including the witness links (and corresponding citations) for the birth event when adding new people to your database. Since the links themselves are allowed to have their own citations this makes it possible to document those sources that confirm relationships but not necessarily any other information.

[rakow]

That citation case is covered in the FH cunningly entitled Help page How to Cite Sources for Relationships.

Thanks, I'll give it a try - I did suspect that "witnesses" would be part of the answer.

[Chrisv]

I don't understand the need to add citations to the the witness of a birth event. Why do you need to do these extra steps? When I have a child listed in an obituary, I write a citation to the birth event stating the source was from an obituary and if I also found a date for that person through a different source, I would then attach a citation to the birth event stating the source where I found this additional information.
I am not trying to debate using a witness to record a birth relationship, but rather I am concerned that I have been missing something and have been entering this incorrectly. I guess I am not quite grasping the concept of what you are doing, or maybe not the reason for doing so. I was able to follow the instruction of how to enter it into FH, but not the reasoning. Can someone expand on this subject some more so I can understand this better?

[KFN]

This was one of my main problems/complaints with FH when I moved from TMG. Documenting relationships is literally the most important aspect of genealogy and it is baffling that GEDCOM doesn't explicitly allow for this. That said, Mike has linked to a good article, and this is exactly the method I am using now as well. One caveat is that you have to make a habit of always including the witness links (and corresponding citations) for the birth event when adding new people to your database. Since the links themselves are allowed to have their own citations this makes it possible to document those sources that confirm relationships but not necessarily any other information.

im not sure what relationship that you are documenting is not supported by v5.5.1 GEDCOM. If I need to document a “god parent” I could use the ASSO tag as defined in GEDCOM.

ASSOCIATION_STRUCTURE:=

Code: Select all

n ASSO @<XREF:INDI>@
+1 RELA <RELATION_IS_DESCRIPTOR> 
+1 <<SOURCE_CITATION>>
+1 <<NOTE_STRUCTURE>>

In v5.5.1 this is only at the individual level.

In v7.x this structure has been extended to all event/attribute detail.
Many programs have create a custom tag in v5.5.1 that used the _ASSO tag to do this as well!

[cwhermann]

Unread post by Chrisv » 03 May 2023 20:15

I don't understand the need to add citations to the the witness of a birth event. Why do you need to do these extra steps? When I have a child listed in an obituary, I write a citation to the birth event stating the source was from an obituary and if I also found a date for that person through a different source, I would then attach a citation to the birth event stating the source where I found this additional information.

In my mind, it is the distinction between citing the birth event / date and citing the child/parent relationship. Obits, wills, census, etc. might indicate a relationship, but not any information on the birth fact itself. This approach also supports the parent relationship for adopted children. In RM I created a custom fact called “parent/child” so I could create a fact sentence for reports.

I think the approach one takes is dependent on how broad or narrow one defines what the birth fact represents.

Curt

[tatewise]

ChrisV, the objective of this thread is to cite the relationship between parent & child. It is not to do citing the Birth event itself.
The FH Help page How to Cite Sources for Relationships explains how to use a Fact Witness with the Role of Father or Mother.

KFN, I agree that Fact Witnesses (_SHAR) are not part of GEDCOM 5.5.1
However, that tag is a widely supported de facto standard used by at least Family Tree Analyzer, GedSite, Heredis, Legacy, My Family Tree, RootsMagic, and TNG.
Years ago Heredis used ASSO but now uses _SHAR. I'm not aware of any product that uses _ASSO.

Yes, GEDCOM 7.0 has formalised the ASSO tag at the fact level (in place of _SHAR) but the format of the ROLE subsidiary tag is not compatible with most current products.

[LornaCraig]

Some people prefer to use a custom fact to record the evidence for the parent/child relationship. See this topic
suppress select witness facts in property box (21841)

[KFN]

Tatewise, You are probably right that it is an _SHAR rather than _ASSO! It has been a lot of years since I worked with them!

When adding a BIRT “fact” it has two potential states.

1) the common and most used, “I have a source that indicates a birth date and/or a birth place” with citation information.

Code: Select all

1 BIRT
2 DATE …
2 PLACE …
2 SOUR @S…@

2) the little used, “this individual was born to a family consisting of one or two other individuals” with citation information.

Code: Select all

1 BIRT Y
2 FAMC @F…@
2 SOUR @S…@

If you know a person was born to individual(s) but have no additional information, this is the way I document that relationship and source.

[tatewise]

KFN, yes, that is an alternative method that is GEDCOM 5.5.1 compatible.
However, it is not well supported in FH or most other genealogy products.
e.g. In FH, you must use the All tab to manage that feature. Also, I don't think it is included in any Reports, so its Source Citation is also missing from the Report.

Whereas the Fact Witness method is much more familiar to most users, does appear in Reports, and is supported by many popular products.

[KFN]

KFN, yes, that is an alternative method that is GEDCOM 5.5.1 compatible.
However, it is not well supported in FH or most other genealogy products.
e.g. In FH, you must use the All tab to manage that feature. Also, I don't think it is included in any Reports, so its Source Citation is also missing from the Report.

Whereas the Fact Witness method is much more familiar to most users, does appear in Reports, and is supported by many popular products.

I can’t argue against using “fact witness” for some events like marriages where the event actually has a component called witness. I just find it so sad to hear that most genealogy software, which has had over 15 years to learn and use GEDCOM v5.5.1 has not (and will not) embrace the standard when it does contain a solution for a need! I get that not all needs are supplied in v5.5.1, and some modern concepts have not been updated, but a lot of the things people want to pass between programs is already in the standard, just not used!

One case in point is the lack of use of the TYPE tag to modify the definition of a current tag. Or that the ADOP event can record the “who” in the connected family adopted the child. Or that the FAMC can help to differentiate which family is the adoptive family and which one is the birth family.

I’m off my rant now!

[tatewise]

I agree with you completely that the extent of implementation of the GEDCOM 5.5.1 definition is poor.
Most of the features you mention existed in the previous GEDCOM 5.5 which is over 27 years old!
John Cardinal has attempted to assess products and inform users via his https://www.gedcomassessment.com/ website.
Let's hope that GEDCOM 7.0 gets wider & better support.

[KFN]

Let's hope that GEDCOM 7.0 gets wider & better support.

I get pushback already when I want to implement better use of TYPE because “no-one uses it now”!

I think earlier you said GEDCOM v7 did not implement FACT.ASSO in a way that would make _SHAR (use of ROLE) transition to it, can you elaborate?

[tatewise]

I think earlier you said GEDCOM v7 did not implement FACT.ASSO in a way that would make _SHAR (use of ROLE) transition to it, can you elaborate?

Dare I suggest you read the GEDCOM 7.0 specification? See https://gedcom.io/specifications/Family ... DCOMv7.pdf
See the Association_Structure on Page 46 and the ROLE definitions on Pages 88 and 98.

The ROLE tag is only allowed a strictly defined set of relationships such as CHIL, FRIEND, HUSB, PARENT, OTHER, etc...
So the current free format ROLE used by most products cannot be directly employed. (They are not very portable anyway.)
Any current Role that does not translate to a defined GEDCOM ROLE must use OTHER and put the current Role in the subsidiary PHRASE tag.

Note that Name Only Witnesses are handled by omitting the @<XREF:INDI>@ link from the ASSO tag and putting the Name Only Witness in a subsidiary PHRASE tag.

[KFN]

Dare I suggest you read the GEDCOM 7.0 specification?

The ROLE tag is only allowed a strictly defined set of relationships such as CHIL, FRIEND, HUSB, PARENT, OTHER, etc...
So the current free format ROLE used by most products cannot be directly employed. (They are not very portable anyway.)
Any current Role that does not translate to a defined GEDCOM ROLE must use OTHER and put the current Role in the subsidiary PHRASE tag.

This works the way we designed it!

1) Enumerating the valid values over a free form value allows for internationalization/translation of the enumerated values.
2) the Other/Phrase allows for quick association type additions that are out of the norm
3) the other/phrase along with a “voidPtr” can be used to list a name of a person not found in the database.
4) enumerations can be added as a minor change to GEDCOM.

What other things are bad about this structure that we can fix?

[tatewise]

KFN, I think you have misunderstood what I said.

I realise GEDCOM 7.0 is working as designed and IMO there is nothing particularly bad about the structure.

I said: "... the format of the ROLE subsidiary tag is not compatible with most current products."
i.e. Some translation will be required from the current free format ROLE values to the GEDCOM 7.0 enumerated format.
e.g. Witness becomes WITN. In future will FH Fact Witness Roles be constrained to the enumerated values or will free form Roles be translated to/from ROLE enumerated values and PHRASE tags? Does that affect FH claimed 100% GEDCOM compatibility?

Try experimenting with the FH File > Import/Export > Export > GEDCOM File... > Destination: GEDCOM 7 option.
FH does not replace _SHAR or _SHAN tags with ASSO and adjusted ROLE & PHRASE tags presumably because it is too tricky.
FH also does not import Fact level ASSO & ROLE tags but converts them to UDF.
I have reported those issues and others to CP who have logged it for evaluation.

[KFN]

Tatewise,

Sorry this got a little long, and probably incomplete, I have a zoom meeting in a few minutes and stopped writing!

It was not that I misunderstood, more about my problem with the "direct compatibility with custom structures" that so many software programs (I'm talking in generalities, possibly unfairly) want to implement in future versions of GEDCOM.

As you said: "Some translation will be required from the current free format ROLE values to the GEDCOM 7.0 enumerated format".

Yes "conversion" will be the case for all programs.

You said: "Witness becomes WITN. In future will FH Fact Witness Roles be constrained to the enumerated values or will free form Roles be translated to/from ROLE enumerated values and PHRASE tags?

I'm not 100% sure I understand! The ROLE of an association is not restricted because FH can use the Other/PHRASE payload. I don't know what FH will do when Importing/Exporting/Displaying/Storing enumerated values where other/phrase is an option.

I would suspect that:

Importing v7 will first require compliance that the values sent will actually contain the enumerated values rather than something else. Being GEDCOM v7 compliant has meaning here. This concept is important, both conversion of the data, and for translation of the term. I separate the two concepts (conversion vs translation), conversion dealing with converting the GEDCOM enumerated value to a proper display value, while translation deals with using the language/local custom term and translate it to other language/local custom term.

Exporting should be easy if FH maintains good v7 GEDCOM compliance, and the receiving program does the same. Round-Tripping to other programs could be an issue if either one is not GEDCOM v7 compliant.

Displaying should be easy with a drop-down list of values (in local language) which gets converted to the GEDCOM enumeration. If "other" is selected the screen would open a new field for entry of the PHRASE. Data entry of "voidPtr" would need a new entry container.

The database for FH could be harder to support being that it is a reflection of the GEDCOM itself. If the import is GEDCOM v7 compliant then a conversion would be easy for display of the enumerated value and very simple for an other/PHRASE


You asked: "Does that affect FH claimed 100% GEDCOM compatibility?"

I'm not up to speed on FH and I probably will never be! One of the reasons I have been using FH is because it uses GEDCOM as part of its core database, in hopes that my strict GEDCOM v5.5.1 data does not get lost on import, BUT some of the structures (by your own admission) in GEDCOM v5.5.1 are not supported very well in FH. So while FH says they are 100% GEDCOM compatible, this is not true if a structure or concept is not supported in display or use!

You said: "Try experimenting with the FH File > Import/Export > Export > GEDCOM File... > Destination: GEDCOM 7 option. FH does not replace _SHAR or _SHAN tags with ASSO and adjusted ROLE & PHRASE tags presumably because it is too tricky."

Technically FH is still GEDCOM v7 compliant because including _SHAR is allowed as a "custom tag", "compatible in the law, but not in the spirit", it should be converted to GEDCOM v7 coding,

2 ASSO @I3@
3 ROLE WITN

or

1 ASSO @I3@
2 ROLE OTHER
3 PHRASE <value>

It may not be a perfect conversion but would be "in the spirit" of the v7 standard rather than perpetuating an old concept.

[tatewise]

I agree with everything you say about FH and GEDCOM 7 compliance, especially the technical compliance but not the spirit of GEDCOM 7 which would hinder migration to another product.
In FH user dialogues, enumerated values defined in GEDCOM 5.5.1 are presented to the user with 100% compatibility.
e.g.
Name_Type = aka, birth, immigrant, maiden, married
Restriction_Notice = confidential, locked, privacy
Source_Media_Type = audio, book, card, electronic, fiche, film, magazine, manuscript, map, newspaper, photo, tombstone, video
Multimedia_Format = bmp, gif, jpg, ole, pcx, tif, wav

Although, it does map Role_In_Event: CHIL, HUSB, WIFE, MOTH, FATH, SPOU to Child, Husband, Wife, Mother, Father, Spouse

It is not clear how that might work with ASSO ROLE enumerated values and PHRASE tags while retaining 100% compatibility.

[Gowermick]

Is it an anomaly in GEDCOM, but it seems parents cannot be a witness to a christening (at least according to FH) despite their names appearing in the Parish Register, doesn't seem to make sense!
Yet father can be a witness to a birth, when most likely he wasn't actually in attendance

[tatewise]

Mike, please clarify what you are referring to.

Are you talking about the ability to add a subsidiary Family link to a Birth event?
That kind of subsidiary Family link can be added to a Christening event although it is disallowed in GEDCOM.
That kind of subsidiary link is not allowed with a Baptism event.

Alternatively, perhaps you are talking about Fact Witnesses, which are not defined in GEDCOM at all for any facts.
However, in FH you can define whatever Roles you like for any fact.

[Gowermick]

Mike,
I was trying to add a Witness role to a Christening fact. I added an Individual, selected mother's recordname, but when I tried to define her role, Mother was not in drop-down list, only Godparent Minister Priest (or create a new Role).

Whereas if you add a witness to a birth fact you get Father Mother Parent Informant (or create a new Role).

My question is why are Mother Father or Parent not in drop down list for Christening by default?

Notwithstanding the above, I took the plunge and created a new role of mother for the christening fact, but screwed up the default sentence!

How do I edit the various roles, once they have been created, so I can amend the default sentence?

[RS3100]

I would question adding a parent as a witness unless you have specific evidence that they were present at the Christening.

One of my great uncles was baptised at a church in Darenth, Kent. His mother and father with whom he had lived in Canning Town were recorded as his parents in the register. But by the date of the Christening both of his parents were dead, and he had apparently been taken in by his aunt's family. He continued to be raised by his aunt and her husband, and would later change his name by deed poll to that of his "adopting" family.

I have another Gx5 uncle in Lincolnshire whose parents were both named in the baptism register, but I have separate evidence that his father had died and been buried prior to the event, and no mention of that fact in the baptism entry, whereas I have other relatives whose baptism entries refer to e.g., "son of the widow..." or "the son of [...] a posthumous baptism".

Granted, more usually the parents of a child being Christened would be expected to be present at the ceremony, but the church register only records the parents' names, not the fact that they were necessarily present at the event, or that the child had been presented by proxy.

[Gowermick]

RS3100
Your point is well made, but pre 1837, the only evidence we normally have of a child's parentage is the christening entry, so I was merely trying to tie the parents to the child via the witness fact, it is the only evidence we have.

It is more likely they were both present at the christening, than the father was at the birth!

[tatewise]

RS3100, you misunderstand the purpose of the Fact Witness Roles of Mother and Father.
It is a common mistake to think that a Fact Witness must actually be present and witness the event.
Most products call them Shared Fact Roles.
Fact Witness Roles of Mother and Father for Birth, Baptism & Christening events are identifying relationships not saying they were present at the event. They allow source citation evidence of the relationship to be recorded.

Mike, yes, you must add Role definitions of Mother and Father to the Christening (or Baptism) event.
Use the Tools > Fact Types... dialogue to Edit... the Christening event Sentence Template and the Role templates.
Use the Roles for the other Roles as a model for your new Roles.

If you get stuck then please post the templates that you having problems with so we can see the issues.