* Fact Add Descriptor confusion

[jimlad68]

I'm confused! For the Facts I have tried:

=== From the Individual Records Window (or All Tab or Named Lists)
> expand an individual > Right Click for a Standard Fact
an option is Add Descriptor
This is not an option for Custom Facts

The Standard Facts do and do not have attributes (Birth, Occupation), so above seems to contradict the discussion
fact display (18178)

Would that make adding a descriptor to Birth, not standard Gedcom, or does 5.5.1 change things, or perhaps there is more than 1 kind of Descriptor.

Not that important but intriguing.

[tatewise]

You are confusing the 'value' of an Attribute with the fact subsidiary 'Descriptor' or TYPE field.
The rules are the same for GEDCOM 5.5 and 5.5.1.

All Attribute facts, both standard and custom, can have a 'value', but Event facts cannot have a 'value'.
e.g. Occupation 'value' is the actual occupation.
The confuse things further, some products call this the Attribute description.

All standard facts (EVents & Attributes) can have a subsidiary TYPE field (like a subsidiary DATE, PLAC, ADDR fields).
Custom facts cannot because they use the TYPE field to define the name of the custom fact.

In the GEDCOM the tags look like this for a standard Attribute followed by a custom Attribute in GEDCOM 5.5.1:
1 OCCU Doctor
2 TYPE Description
1 FACT Woodworking
2 TYPE Skills

[jimlad68]

Thanks for that, I wasn't sure if it was a Gedcom thing or FH extension.
It just seemed strange that a Custom Fact should be treated differently; apart from not being allowed an attribute, I was under the impression they were the same as Standard Facts.

[tatewise]

Don't understand: "apart from not being allowed an attribute".
Custom facts are allowed to be an Attribute.
It is disputable in GEDCOM 5.5 but definitely allowed in GEDCOM 5.5.1 ~ EVEN tag for Events ~ FACT tag for Attributes.
But custom facts use the TYPE tag to define the custom fact type, so it is only available to standard facts as a Description.

[jimlad68]

I think I am less confused in that it sounds that a Custom Fact acts like a Standard Fact, except it does it in a different way!

The reason I like to get a grip on these things is so I can keep it simple and as portable as practical. So for that reason I will continue to use Custom facts without attributes and just use the Fact Note for any detail.

[tatewise]

Creating custom Attribute facts with values are extremely portable.
Those other products that support GEDCOM 5.5.1 will allow custom Attributes with a value.
Many other facts that support GEDCOM 5.5 allow custom Events to have a value although possibly not strictly compliant.
The Export Gedcom File plugin caters for those cases.
For other products, the plugin moves the attribute value to the local Note field of a custom Event.
Therefore, all the options are covered.

There are far more significant things you should consider to ensure your Project is as portable as practical.
Don't use Fact Witnesses, fact Ages, Sort Dates, Addresses, Media Face/Detail Frames, record Flags, etc.
Even some standard facts are not well supported by some products.

[jimlad68]

Good tips Mike, I have all of those "exclusions" covered mostly by design and partly by chance. I do use ASSOciations which I believe is Gedcom compliant, but as you say is "not well supported by some products", indeed most products including FH.

[Mark1834]

Coincidentally, this thread heavily overlaps with my recent question on Children's marriages in Family Group Sheet reports. There is a very interesting and informative piece at https://genealogytools.com/the-event-st ... com-files/ that gives a bit more background on Event tags in GEDCOM 5.5, and argues that they should have a value, and it was an oversight to omit this in the definition.

I hadn't realised how portable this type of custom event is, and once I had worked out that FH represents a custom Attribute called "Married" internally as "_ATTR-MARRIED" (logically enough), it was a simple matter to add this to my custom FH-RM-Ancestry sync plugin using the following format, which is not strictly GEDCOM 5.5 compliant, but is within the "spirit" of the definition and understood by RM:

1 EVEN Spouse Name
2 TYPE Married

[tatewise]

FYI: Although it should strictly be FACT-MARRIED, note that _ATTR-MARRIED is still used in FH V7 GEDCOM 5.5.1 to be backwards compatible with FH V6 GEDCOM 5.5 that used the FH extension _ATTR tag.

[Mark1834]

To clarify in case readers are confused, FH7 uses the GEDCOM 5.5.1 compliant form of 1 FACT in its GEDCOM data file, but represents it internally in the GEDCOM 5.5 style of _ATTR-MARRIED to keep plugin code compatible with both FH6 and FH7. Sensible programming by CP.

[tatewise]

To clarify further, it is not just in Plugin code, but anywhere data refs are used such as Queries, Text Schemes, Record Window Columns, etc, etc...

[AdrianBruce]

... gives a bit more background on Event tags in GEDCOM 5.5, and argues that they should have a value, and it was an oversight to omit this in the definition. ...

Philosophically, using the English language, an event is something that happens (and changes the status quo). In both philosophy and real life such an event might have an optional value. For instance, arguably, the GRADUATION event (an event in GEDCOM) should have an optional value of what the qualification is that you graduate with. Instead, if we want to record event values in GEDCOM, we need to make them attributes. (Or mess about with Event_Descriptor, which isn't the same thing in my book).

[Mark1834]

Agree - I think this is an example of FH making things unnecessarily complicated by sticking to the letter of the GEDCOM definition, and the practical distinction between the two in FH of an Attribute having a value while Event does not is out of step with normal English usage and the flawed formal definitions within GEDOM.

[tatewise]

It is not just FH, but virtually all other products, that distinguish standard Events with no value from standard Attributes that allow a value. I accept the point made by Adrian regarding Graduation, but what values would standard Events have?

The bigger argument surrounds custom Events (EVEN) defined in all recent GEDCOM versions and custom Attributes (FACT) added in GEDCOM 5.5.1 and which of those allow a value. The proposed GEDCOM 7.0 resolves things by allowing both custom Events (EVEN) and custom Attributes (FACT) to have a value.

Where FH was out of step with other GEDCOM 5.5 products is that most allowed custom Events (EVEN) to have a value rather than having a special extension for custom Attributes (_ATTR).

[Mark1834]

Again, agree. The conventional distinction is that an event is associated with a particular point in time (similar to the normal English language meaning of the word), while an attribute is a state that is true for a longer period (but is not necessarily permanent).

Coming back to my example of the Married fact that I use to capture a marriage without adding the spouse to the database, it is undoubtedly an event in normal language use, not an attribute. Assigning the name of the spouse as the value of the fact is an arbitrary choice on my part, and is a pragmatic way of capturing the information within the confines of what is permitted within the software. This is completely analogous to Adrian's arbitrary choice of the degree awarded as the value of the Graduation event.

What we all seem to agree on, although with different wording and emphasis, is that FH is probably unique in forcing us to call these events attributes rather than making the pragmatic compromise of allowing custom events to have a value. IMO, user-friendliness and an intuitive structure are stronger selling points than strict GEDCOM compliance.

[tatewise]

Surely FH is trying to implement your first paragraph to differentiate between an event and an attribute.
The GEDCOM specification even advises that Events should use Simple Dates and Date Ranges where the exact date is only known within a range, whereas Attributes should use Simple Dates and Date Periods to define the duration.

You have chosen Married as the name of your fact which to me sounds like an Attribute.
i.e. In normal English, Married is a state that lasts for a period of time, as opposed to a Marriage Event.

[Mark1834]

Exactly - it’s trying to maintain a sensible distinction, but just not doing it very well due to the ambiguity in the GEDCOM spec that they interpret by requiring an event with an EVENT_DESCRIPTOR field (the “value” of the event) to be recorded as an attribute.

Maybe I need a better thesaurus to find an alternative name to Marriage, but what I choose to call it is hardly relevant to the debate.

[tatewise]

Sorry Mark, but you are making the same mistake as the OP and confusing the EVENT_DESCRIPTOR (TYPE) field with the Attribute 'value' field.
If a custom Event were allowed a 'value' it would follow the EVEN tag.
The EVENT_DESCRIPTOR (TYPE) field is on the following line as I explained earlier.
e.g.
1 OCCU Doctor where Doctor is the 'value'
2 TYPE Medical is the TYPE <EVENT_DESCRIPTOR> that refines the fact ~ yes it applies to Attributes too
1 EVEN Woodworking where Woodworking is the 'value'
2 TYPE Skills is the TYPE <EVENT_DESCRIPTOR> that defines the custom fact

See GEDCOM 5.5 Pages 29 - 32 & 43 and GEDCOM 5.5.1 Pages 32 - 35 & 48 - 49 and also ATTRIBUTE_DESCRIPTOR Page 43 which clarifies that Events have no value and Attributes do.

I think you are missing my point.
The Married state (you chose the name Married) is an Attribute that lasts for a period of time so your use is perfect.
The Marriage ceremony is a standard Event that occurs at a single point in time and cannot have a 'value'.

[Mark1834]

I’ll be the first to admit I don’t carry every detail of the GEDCOM spec in my head (or have the inclination to wade through the rather turgid text of the formal definitions) so I probably do use terms and definitions imprecisely at times. If we have to describe an event as an attribute in order to store extra information (the spouse name, or degree awarded), so be it. In the real world, it doesn’t really matter. I can record what I need to capture in a portable and robust form, and it looks neat and tidy in reports and diagrams. That’s good enough for me, and debates about the fine print of the specs is just an entertaining diversion for a lockdown evening...

[Mark1834]

It's worth trying to summarise this thread and clarify where necessary for the benefit of those coming across it in the future and thinking "what on earth is this all about?", or words to that effect...

Facts about individuals and families can divided into Attributes and Events.

Attributes are the simpler to deal with, so I will summarise those first. Attributes tell us something about an individual or family that is true over a period of time (but not necessarily permanent). "Best practice" recommends that if a qualifying date is used, it is either a specific date (to whatever precision is appropriate) or a date period (from x to y), but this is not enforced either in GEDCOM or in FH.

Attributes can have values, but don't have to (for the avoidance of doubt, I define "value" as data that is associated with the fact as a whole, and stored at the top level of the corresponding GEDCOM tag). An example of a pre-defined attribute is Occupation, as in 1 OCCU Labourer to define the occupation, with optional qualifiers such as date and place. A user-defined attribute (a FACT in GEDCOM 5.5.1) would typically be recorded over two lines, describing what the fact is and its value, as in the following for a specific attribute capturing eye colour. Blue is the ATTRIBUTE_DESCRIPTOR, colloquially the "value" of the attribute.
1 FACT Blue
2 TYPE Eye Colour

Events are slightly more complicated. Pre-defined events, such as Birth (BIRT), Census (CENS), etc, do not have any values associated with them directly, and data are stored only against qualifiers such as date and place. In GEDCOM the corresponding tag stands alone with no associated data, as in 1 BIRT. "Best practice" recommends that events dates are recorded as either a specific date (to the appropriate precision) or a date range (between x and y), but again this is not enforced.

User-defined Events (EVEN in GEDCOM 5.5.1) are more complex. and the strict definition differs between Individual events and Family Events. For Family events, the EVENT_DESCRIPTOR (colloquially, the "value") is explicitly permitted, with the definition n EVEN [<EVENT_DESCRIPTOR> | <NULL>]. However, the optional EVENT_DESCRIPTOR is omitted for the custom Individual event, and the formal definition is simply n EVEN, a similar form to pre-defined events. This definition is contradicted by an example given in the specification that contains a specific value associated directly with the EVEN tag:
1 EVEN Appointed Zoning Committee Chairperson
2 TYPE Civic Appointments

So is the definition correct, or the example? FH assumes it is the definition, and it is not possible in FH to reproduce this example as a custom event, it has to be defined as an attribute. By contrast, the majority of other apps assume the example is correct, and permit this custom event to be created. The draft GEDCOM 7.0 specification has followed the market rather than the FH interpretation, so will formalise the rather odd position whereby pre-defined events cannot have a value, but custom ones can.

FH also prevents a custom Family event from having a value, even though it is specifically permitted within the definition of GEDCOM 5.5.1.

For apps that assume the example is correct, "Appointed Zoning Committee Chairperson" is the EVENT_DESCRIPTOR, colloquially the event "value". In FH, custom events cannot have a value, so EVENT_DESCRIPTOR cannot apply directly to the n EVEN tag, only to the following n+1 TYPE tag.

Defining an custom event in FH as a custom attribute in order to use a value field is a pragmatic workaround, which conflicts with the normal definitions of event and attribute, but enables more data to be stored in a convenient and portable format.