Family Historian User Group

Citation is not about the way the data is stored! So using term like Source_Record, Citation Detail, etc are storage terms, rather than citation values needed to properly site a specific source for the selected citation style. In the context of Citing Sources: Method 1 and Method 2 it is mainly abo...

But I am seriously concerned that there is potential for confusion among incomers when we use "citation" to mean that intersection entity (aka bit in the middle). Once I found that the UI now refers to it as a Citation-Specific Detail, then it seemed to me that a little clarity was in order. And I ...

The OP actually lead off with questions regarding his interpretation of v5.5.1 GEDCOM and its relationship to "Splitting", and how to use or change his way of entering data to conform to v5.5.1 GEDCOM. I had the feeling that an objective definition of "Splitting" was likely based on the GEDCOM stand...

Evidence Explained is not about splitting or lumping, it is a style of citation. Citation styles take many forms, APA, MLA, Chicago, Turabian, IEEE, each has a place and use. I used Society for American Archaeology (SAA) citation style back in the 1980s for my genealogy projects. Splitting and Lumpi...

Adrian, Unfortunately, not much has change going forward regarding the “required use” of the SURN tag in v7. Any receiving program can drop the tag on import, without prejudice! I use this in my primary GEDCOM to manage individuals without surnames, but that are part of a family group, but this cons...

Adrian, GEDCOM allows for the NAME tag and the SURN tag to be different. The v7.0.12 GEDCOM actually says that the value inside the "/" can be different than the SURN tag to: in particular it is recommended that all name parts in PERSONAL_NAME_PIECES appear within the PersonalName payload in some fo...

Thanks Mike, that makes a big difference!

Based on another issue, and not wanting to step on their thread, I went to look at a few individuals in a tree that I have and I see the same thing. Wang Xiu.jpg The GEDCOM is accurately ordered for this individual: 1 NAME /Wang/ Xiu Mai 2 GIVN Xiu Mai 2 SURN Wang FH correctly identifies the Surname...

ColeValleyGirl wrote: ↑

08 May 2023 15:02

I don't think this discussion (which will never result in agreement) is helping the OP at all. Start a new topic and move the Gedcom discussion there?

You are probably right. My initial comment was to define Lumping vs Splitting which was directly related to the question the OP asked.

GEDCOM is generally a “lumper” recording environment. Sorry, but I totally disagree. GEDCOM fully supports the entire spectrum from extreme 'lumper' to extreme 'splitter'. That is reinforced by almost all the Citation fields and all the Source record fields being optional (i.e. {0:1} or {0:M}) as i...

I'm going try to draw this thread back on track, if possible... What is an objective definition of "Splitting"? If there truly isn't one, then let us close the thread and move on. From Wikipedia: Lumpers and splitters are opposing factions in any discipline that has to place individual examples int...

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, poss...

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 cu...

tatewise wrote: ↑

04 May 2023 22:32

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?

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 f...

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 informatio...

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 a...

The GEDCOM terms are 'attributes' and 'events' and in the early days of FH we always referred to either attributes (e.g. Occupation) or events (e.g. Census) but in a later version of FH (3?) the term 'Fact' was introduced as a convenient word to cover both those terms. But the word Fact in this cas...

The term “fact” (as used in a lot of software) is really a misunderstanding of the process. We are not recording ‘facts’ we are recording ‘events’. We are not ‘concluding’, we are providing ‘evidence’. Based on a the evidence we assert a hypothesis that may become a fact when other collaborative evi...

Sorry, It was me writing too quickly with my one finger on my iPad and not writing more neutrally. I don’t use a keyboard very often unless I’m coding, so typing is slow! I said, “ FH does change the XREF when it imports a GEDCOM!” I should have said, “ FH can change the XREF when it imports a GEDCO...

I understood that rule from the start ... I was not complaining in the least. I was actually stating that GEDCOM specifically states in its v5.5.1 specification. The xref_ID is formed by any arbitrary combination of characters from the pointer_char set. The first character must be an alpha or a dig...

Yes, that is the thing I did. The first item in the GEDCOM is a Family Record. 0 @F8@ FAM 1 CHIL @I4@ 1 CHIL @X4@ 1 CHIL @I769@ 1 CHIL @X49@ 1 CHIL @Hello2@ 1 _UID 8332153D9C8CD7119218444553540000F121 1 HUSB @I49@ 1 WIFE @I48@ The above CHIL links are the only one in the GEDCOM. 1) I assume that the...

KFN claimed that " FH does change the XREF when it imports a GEDCOM! " I think it is true that FH changes the XREF initial letter from say P to I for Individual records on import. However, I believe FH invariably retains the numerical part of the XREF so that the Record Id is maintained. KFN may be...

"KFN"; We speak about our family as a "tree". A "tree" begins at it root, a single point, and "branches out" as it grows. The "root person" of the "tree" in FH7 is the single person from which all others appear to "branch out". If you shared the tree with someone else, your "root" is still the same...

Lorna; I knew about the "set root" option. Having the root person as ID #1 ensures that this happens by default. And; I assume that an export with the root as ID #1 would carry this behaviour forward to another system, if I send the data to someone. It's just something I figured I'd do now, as I ce...