* Emigration Fact - Copying and Using Both Copies

[KFN]

OK, that makes an even stronger case.
However, the GEDCOM 5.5.1 specification only associates Date Periods with Attribute states and Date Ranges with Event single dates, which is why some aggressive GEDCOM compliance checkers complain if used the other way round.
In general though, most software does not care.

I disagree with the statement.

All Individual tags for Events and Attributes are built using the same substructures.
First using the INDIVIDUAL_EVENT_DETAIL with the substructure of EVENT_DETAIL which contains the DATE structure containing all possible DATE combinations:

Code: Select all

DATE_VALUE:
[<DATE> | <DATE_PERIOD> | <DATE_RANGE>| <DATE_APPROXIMATED> | INT <DATE> (<DATE_PHRASE>) | (<DATE_PHRASE>) ] 

I suppose that some example may indicate that an Event happens on a given date and an attribute happens over a range but the specification allows both events and attributes to have all Date Type.

[tatewise]

From a purely GEDCOM standpoint I don't understand where a FROM and TO location can be entered! I only see one place to enter a location that makes sense!
In GEDCOM v5.5.1 the EMIG tag (old domicile) and IMMI tag (new domicile) would have a single PLAC and DATE tags.

The 2nd EMIG/IMMI location is saved in a user-defined custom _PLAC tag that is almost certainly unique to FH.
That is perfectly valid GEDCOM but usually does not migrate intact to other products, so the FH GEDCOM needs converting to add that 2nd location as such as a labelled Note, c.f. Export Gedcom File plugin.

[tatewise]

All Individual tags for Events and Attributes are built using the same substructures.
First using the INDIVIDUAL_EVENT_DETAIL with the substructure of EVENT_DETAIL which contains the DATE structure containing all possible DATE combinations:

Code: Select all

DATE_VALUE:
[<DATE> | <DATE_PERIOD> | <DATE_RANGE>| <DATE_APPROXIMATED> | INT <DATE> (<DATE_PHRASE>) | (<DATE_PHRASE>) ] 

I suppose that some example may indicate that an Event happens on a given date and an attribute happens over a range but the specification allows both events and attributes to have all Date Type.

It depends on how much significance you give to the <DATE_PERIOD> and <DATE_RANGE> definitions that associate them with Attributes and Events respectively. They are not even examples but "Where:" definitions. So there is some ambiguity.

[KFN]

It depends on how much significance you give to the <DATE_PERIOD> and <DATE_RANGE> definitions that associate them with Attributes and Events respectively. They are not even examples but "Where:" definitions. So there is some ambiguity.

I see your point! In v7.0 they maintain the distinction/ambiguity with this statement, although still some what fluid!

As a general rule, events are things that happen on a specific date. Use the dateRange form to indicate that an event took place at some time between 2 dates. In most cases, a DatePeriod is inappropriate for an event; if the subject of your recording occurred over a period of time, then it is probably not an event, but rather an attribute.

It is a fine line between the event of doing something and that something becoming an a longer term addition to the individual. So the event of changing a hair color occurred on a given day or “date range”, but the hair color becomes an attribute when the color in her hair for several months or years a “date period”. If a person changed their hair color for Halloween that’s an event, but changed it for two years that an attribute!

[ColeValleyGirl]

I would like to reassure people that I do not actually record all the instances when my family members changed their hair colour. Life is too short when you have/had 4 sisters and a mother with a penchant for the dye bottle...

[KFN]

I would like to reassure people that I do not actually record all the instances when my family members changed their hair colour. Life is too short when you have/had 4 sisters and a mother with a penchant for the dye bottle...

Or hair style

[AdrianBruce]

... It is a fine line between the event of doing something and that something becoming an a longer term addition to the individual. So the event of changing a hair color occurred on a given day or “date range”, but the hair color becomes an attribute when the color in her hair for several months or years a “date period”. If a person changed their hair color for Halloween that’s an event, but changed it for two years that an attribute!

Well, if you're careful enough (or pedantic enough), there shouldn't be any ambiguity over what the data recorded on file actually means. The key is to use one term for the ongoing state, and another for the event of changing that ongoing state.

Thus "Haircolour" might be the attribute for the ongoing, err, colour of someone's hair. "DyeHair" might be the event that changes the colour of someone's hair. That way you don't absolutely need to decide how long the hair stayed one colour - it's "Haircolour" whether it's for two years or for Halloween.

If you go on to be still more pedantic, then you could claim that any "Haircolour" attribute could be both preceded and terminated by the "Dyehair" event. Or it might also be terminated by the multi-day event "EmulateGeorgeClooney".

Of course, there's no reason to expect anyone to actually top and tail the "Haircolour" attribute by "Dyehair" events - it does seem fairly pointless - and you might also decide that Halloween could indeed be described by a "Dyehair" event, with a note explaining that this was just as a one-off. But, if you get your head round the different names and definitions, then I would suggest that any ambiguity or confusion, disappears and the Fine Line becomes simply a matter of style. I hope.

[KFN]

Adrian,

This is where I think the ColeValleyGirl is missing out on a great way to pad her families history book, with pages of photos and events/attributes where her sisters change hair color. Call the new book, ‘The history of hair color in my family”, could sell millions! Maybe even make a BBC Docudrama.

[KFN]

But seriously….

In Genealogy, events tend to happen at a point in time (birth, death, burial, Adoption, emigration, immigration) rather than over a period in time. Where attributes tend to be a lifetime or long term quality, feature or characteristic of a person.

BUT…

In family history, we start adding things like participating in a war, or traveling, or working at a job, which seam to be be events rather than attributes. “Burning Man” is a multi day event where participation is by a person, not an attribute of a person. And very short term features of a person that are not an event but still occur at a point in time. This is where the fine line occurs. It is in the use of the term, feature or characteristic, in our recording of the history of a person!

[AdrianBruce]

... “Burning Man” is a multi day event where participation is by a person, not an attribute of a person. ...

Ah - I like that and will definitely pinch it in the future as an example of a real-world event that lasts for several days. It's pretty certain the vast majority of people would see it as an event.

Of course, if you turn to recording that in FH, it's one of those where I'd probably turn it into an Attribute in order to use the value of the Attribute for the name of the festival... Confused? Me?

[tatewise]

Mike, would it be worth an KB article on these options?

I've posted a draft KB article on Custom Fact Fields (21400) for comments. I hope it is what is expected.

[tatewise]

The FHUG KB article Entering Standard and Custom Fields for Facts summarises the points raised in this discussion thread.