Family Historian User Group

Posted: **21 Dec 2022 10:03**

As a newcomer to FH I do not understand why facts are categorised as Event or Attribute. For example I have added Hobby, which in fact is an event every time you participate in that Hobby, for example go on Bird watching trip, But if I use Event when creating my custom fact, it does not allow me to show what the Hobby is. I have to use Attribute .
Why can't there be one category, with the opportunity to add as many or as few fields as you wish?

Posted: **21 Dec 2022 10:56**

As a newcomer, you may be unaware of the protocol for posting in the New Wish List Requests forum which is stated in Please Read Before Posting Wishes (6176).

So I've moved this posting to the FH General Usage forum to discuss the features and options.
If you still believe a Wish List request is needed then it can be dealt with later.

FH closely follows the GEDCOM specification and by doing so makes migration to and from other products fairly easy.
The more FH strays from the specification the more difficult such migration becomes.

Many other products distinguish between Events and Attributes as defined in GEDCOM.
In practice, there is little to stop you from using an Attribute as both an Event and an Attribute, except that the narrative Sentence Template definition may be a challenge to cope with both scenarios.
You could also define both a custom Event and a custom Attribute with the same or similar name. FH warns against it but it is allowed and fully supported.

There are several extra standard GEDCOM fields available for facts but they are not shown on the Facts tab so the All tab must be used. Adding custom fields would jeopardise migration to other products.
The recommended approach is to add labelled text to the Note field as explained in the FHUG Knowledge Base article Narrative Report Fact Sentence Templates under Custom Fact Fields.

Posted: **21 Dec 2022 11:32**

On a different tangent to Mike's technical reply, the first thing that came to my mind reading your description of bird-watching as an event, was that if you intend recording every single instance of when an ancestor went on a bird-watching trip, I can see a rationale of sorts for recording each trip as an event. But doing that is not going to be a trivial task. How are you going to find out when he or she went bird-watching on each occasion for instance? And is that what you are really aiming to do?

But, if your intention is to record that your relative, throughout his or her life, frequently or occasionally went bird-watching as a hobby, surely that is an attribute, not a single event? If you want to record a few particular instances of the hobby being practised, you could mention them in a note attached to the attribute, or as a note appended to the fact sentence.

I had a great-uncle who was a passionate bell-ringer, both at his local church and by travelling to nearby towns and villages by bicycle to practise his hobby. I have recorded the fact that he practised bell-ringing as an attribute, citing a letter from my uncle sharing his recollections as a child who often accompanied his uncle on those trips, and a couple of newspaper cuttings about his bell-ringing activities in support of the assertion.

Posted: **21 Dec 2022 11:37**

What Mike didn’t say is that GEDCOM 5.5.1 is ambiguous on whether Events can have a value or not. FH interprets it as No, but many other apps permit it. FH follows its interpretation, but it’s a misnomer to talk about “the GEDCOM specification”, as it sometimes feels as though there are as many interpretations as there are family history apps!

Like you, I can find FH unduly restrictive. My solution is to simply use a custom attribute when I need a value. I generally don’t use FH to generate polished prose, so slightly odd wording in standard text is neither here nor there for me, but can be fixed if that’s important for you.

Posted: **21 Dec 2022 12:06**

Mark, I agree GEDCOM 5.5 could be misinterpreted regarding whether Events have a value due to some bad examples.
However, I thought GEDCOM 5.5.1 clarified that. Can you refer me to where the ambiguity exists?

I agree that many applications have different implementations, but in my opinion, that is more due to not following the specification including omitting required features than ambiguity in the specification.
See https://www.gedcomassessment.com/ by John Cardinal which assesses the GEDCOM 5.5.1 compliance of 17 products in which FH V6 is ranked about 3rd and FH V7 would probably do better.

Posted: **21 Dec 2022 14:12**

I agree that many applications have different implementations, but in my opinion, that is more due to not following the specification including omitting required features than ambiguity in the specification.

I agree 100%.

In GEDCOM we think of:

An “attribute” is an assigned property of an individual such as “physical description”, “occupation”, “government ID”, “military rank”.

An “event” is something that occurs, such as “a wedding”, “a job”, “military battle”.

These are generally recorded in GEDCOM a little differently.

Most software lumps all of these thing together and calls them “facts” and treats them the same in their data enter display. GEDCOM v5.5 and v5.5.1 are generally the same except v5.5 did not include a structure for defining a custom attribute, which was added to v5.5.1 of the GEDCOM specification.

In reality, most people don’t see much difference between events and attributes, but in my custom reports I generally don’t list “attributes” in a time line of “events” and don’t list “events” when I describe an individual, (i.e. he was a 5ft tall pressman with a high school education).

Posted: **21 Dec 2022 15:16**

That’s an interesting example that demonstrates that it’s not worth getting too hung up on the fine distinction. I agree completely that in natural language, a battle is an event not an attribute, but it definitely has a value (Midway, Waterloo, Hastings, etc)!

Posted: **21 Dec 2022 15:35**

Playing devil's advocate ~ does a battle necessarily need a value or would a Place & Address be sufficient?
What else would you put in Place & Address?

Mark, where is the ambiguity in GEDCOM 5.5.1 that you mentioned?

Posted: **21 Dec 2022 17:25**

Life's too short to go ploughing through the turgid language of the formal specs, but my memory of 5.5 was that the event definition was inconsistent with the cited example. You might be right that it was tidied up in 5.5.1 by the simple expedient of removing the examples!

Posted: **21 Dec 2022 17:45**

I agree completely that in natural language, a battle is an event not an attribute, but it definitely has a value (Midway, Waterloo, Hastings, etc)!

In v5.5.1 GEDCOM I would enter the following:

Code: Select all

1 EVEN
2 TYPE Military, Battle of Midway

In v7.0 GEDCOM we will be able to enter the following:

Code: Select all

1 EVEN Battle of Midway
2 TYPE Military

Some software already allow the v7.0 code in a v5.5.1 GEDCOM!

Posted: **21 Dec 2022 20:07**

Mark1834 wrote: ↑
21 Dec 2022 17:25
Life's too short to go ploughing through the turgid language of the formal specs, but my memory of 5.5 was that the event definition was inconsistent with the cited example. You might be right that it was tidied up in 5.5.1 by the simple expedient of removing the examples!

More than that because GEDCOM 5.5.1 explicitly gives the syntax for EVEN without a value and for FACT with a value.
As KFN says, GEDCOM 7.0.1 allows EVEN to have a value, so is syntactically the same as FACT.

Perhaps it was unhelpful to say "that GEDCOM 5.5.1 is ambiguous" if you have no evidence to support that claim.

Posted: **21 Dec 2022 22:02**

So 5.5 was "maybe" ("no" in FH6), 5.5.1 was "no" (and "no" in FH7), and 7.0 is "yes" (and therefore perhaps "yes" in FH8) - no wonder we can't keep up...

Posted: **21 Dec 2022 22:50**

So 5.5 was "maybe" ("no" in FH6), 5.5.1 was "no" (and "no" in FH7), and 7.0 is "yes"

Im not sure what the “5.5 was maybe” means but the structure for the EVEN tag in v5.5 and v5.5.1 are the same!

The change in v7.0 allows for the creation of a custom event with both an event name and an event value as separate text values, so you can have:

1 EVEN Battle of the Bulge
2 TYPE Military
1 EVEN D Day Invasion
2 TYPE Military

Vs. in v5.4 and v5.5 and v5.5.1

1 EVEN
2 TYPE Military, Battle of the Bulge
1 EVEN
2 TYPE Military, D Day Invasion

Posted: **21 Dec 2022 23:00**

Now, all of this being said,

In v5.0 GEDCOM the standard did say:

The EVEN tag must be followed by an <EVENT_DESCRIPTOR> which describes the event. The <EVENT_DESCRIPTOR> is optional for the other types of events.

But this was updated in v5.4 and forward.

At one point a discussion was held to create an Event_Record but that did not move into any release!

Posted: **21 Dec 2022 23:08**

I suspect the GEDCOM 5.0 <EVENT_DESCRIPTOR> is the same as the later GEDCOM definitions of the same name that relate to the subsidiary TYPE tag, so no actual change.

Posted: **22 Dec 2022 00:38**

The initial design of GEDCOM v5.0 and prior was very different than what we see in v5.4 thru v5.5.1 and now beyond.

The design had not yet defined a group called “attributes” and had just started to toy with a group called “events”.

In v5.0 all attributes were defined thusly, with no subtags just the tag and a description:

Code: Select all

RELI <RELIGIOUS_AFFILIATION> 
OCCU <OCCUPATION>
PROP <POSSESSIONS>
DSCR <PHYSICAL_DESCRIPTION>
+1 CONT <PHYSICAL_DESCRIPTION> 
SIGN <SIGNATURE_INFO>
NMR <COUNT_OF_MARRIAGES> 
NCHI <COUNT_OF_CHILDREN> 
NATI <NATIONALITY>
CAST <CASTE_NAME>

Events were defined as a list of tags, followed by a description and two subtags DATE and PLAC, so at this time, yes the only thing the <descriptor> did was later taken by the EVEN.TYPE tag, hence the design as seen in v5.4 and later. The EVEN.TYPE tag becomes the tag description, and why I write my GEDCOM entry as:

Code: Select all

1 EVEN
2 TYPE Military, Battle of the Bulge

Posted: **22 Dec 2022 11:12**

Thanks for that - it's good to get some background into how features came to evolve, rather than just learning by rope what can appear to be arbitrary differences.

If there is appetite in CP for an FH 8 based on GEDCOM 7, it's an interesting design challenge for them how to implement new features that contradict earlier versions of GEDCOM. They will have to support it to maintain their claim of GEDCOM compliance, but they have a choice over how easy or difficult it is to use.

Posted: **22 Dec 2022 11:20**

KFN wrote: ↑
22 Dec 2022 00:38
The EVEN.TYPE tag becomes the tag description, and why I write my GEDCOM entry as:
Code: Select all
1 EVEN
2 TYPE Military, Battle of the Bulge

So in FH, you must have to create a new custom event for every one of those military battles.
Otherwise, you cannot enter an event with that TYPE code.

Wouldn't be easier to create a single custom attribute for Military Battle and use:

Code: Select all

1 FACT Battle of the Bulge
2 TYPE Military Battle

Posted: **22 Dec 2022 11:34**

That's exactly the point I made isn't it - the first example is perfectly valid GEDCOM 5.5.1, but CP steer you towards their preferred implementation by the design of the FH interface.

Posted: **22 Dec 2022 12:07**

Mark, are you suggesting that FH should allow a Military custom event to have a value that is appended to the TYPE tag with a comma separator? i.e. Custom Event Name/Label = Military and its Value = Battle of the Bulge

A snag with that is when exported to another product it will assume the GEDCOM definition and treat it as custom event with the Name/Label = Military, Battle of the Bulge. i.e. Not a Military event with value Battle of the Bulge

What advantages does that offer over a Military custom attribute that FH has provided forever?

Posted: **22 Dec 2022 13:11**

Where did I suggest that the alternative was a better solution? All I said was that CP steer you to their preferred solution, based on GEDCOM compliance, ease of use, consistency with their previous practice, and compatibility with other apps.

You’ve provided more detail about why that’s the better approach here (but not the only GEDCOM-compliant one) so you are actually violently agreeing with me

.

Posted: **22 Dec 2022 13:33**

Sorry, I must have misinterpreted your point. You seemed to be saying that the CP interface was not very good, whereas you were saying the opposite.

Posted: **22 Dec 2022 13:57**

tatewise wrote: ↑
22 Dec 2022 11:20
KFN wrote: ↑
22 Dec 2022 00:38
The EVEN.TYPE tag becomes the tag description, and why I write my GEDCOM entry as:
Code: Select all
1 EVEN
2 TYPE Military, Battle of the Bulge
So in FH, you must have to create a new custom event for every one of those military battles.
Otherwise, you cannot enter an event with that TYPE code.

Wouldn't be easier to create a single custom attribute for Military Battle and use:
Code: Select all
1 FACT Battle of the Bulge
2 TYPE Military Battle

Technically using a FACT over an EVEN would be wrong, but no harm would occur except as I noted that, if you were listing all events an attribute (signified by a “FACT” tag) would not be listed. In my opinion, I would embrace the v7 design even if data was lost on import to another program for a short period and hope that software embraces the v7 architecture soon. Using the v7 design would not force you to potentially change a custom attribute (FACT tag) to a custom event (EVEN tag)! Some software already allows for EVEN tags to have a description.

Posted: **27 Dec 2022 16:10**

It has been amusing to watch you youngsters.
First, turning an example fact into a definite Hobby that an ancestor of mine actually did.
Then converting my original question into a debate about various gedcom structures.
All you have achieved is demonstrate a weakness in Family Historian. If the gedcom can't do it, neither can the program.
So the simple answer to my original question was it can't be done in Family Historian.
Derek Heritage

Posted: **27 Dec 2022 16:40**

ergo wrote: ↑
27 Dec 2022 16:10
So the simple answer to my original question was it can't be done in Family Historian.

But your original post included an example of how to do it! Just create a custom Attribute rather than an Event if you need a single extra field. If you need more fields, Mike explained that:

The recommended approach is to add labelled text to the Note field as explained in the FHUG Knowledge Base article Narrative Report Fact Sentence Templates under Custom Fact Fields.

So FH can do it; and very many of us exploit the ability already.

Family Historian User Group

Facts

Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts

Re: Facts