Family Historian User Group

A while ago I posted a query (Entering Evidence! Style citations) asking how other folks entered citations into FH using Evidence Explained styling. This is a follow-up to that asking if you see a need for any enhancements to better support EE citations.

One area where I would welcome improvement, is adding support for entering the three forms of citations: full footnote (the only kind I now enter), short footnote, and source list entry. Here is an example...

Full Footnote
Pope County, Illinois, Marriage Book D: 26, license 994, William P. Washer and Ida B. Sharp, 1876, marriage affidavit, license and certification; Pope County Clerk's Office, Golconda.

Short Footnote
Pope Co., Ill., Marriage Book D:26, Washer-Sharp.

Source List Entry
Illinois. Pope County. Marriage Books. Pope County Clerk's Office, Golconda.

(Additional examples can be found at Sample QuickCheck Models).

In the previous program I used, I could enter all three forms using text edit boxes (no templates). I would like to be able to do the same thing in FH. Having the citation in different forms is handy for cutting and pasting into blog posts or other publications.

Is there anyone else who would benefit from this sort of enhancement?

Thanks,
-Stan

I get by with just using the long title for the full footnote, and the short title for the source list entry. (I ignore author, publication and repository). If I wanted to store the short footnote, I'd probably just add a note field to the source.

I'm wary of modifying the program to support a specific citation format (even if it is the one I use). How do you decide which format to support (EE may be quite widely used in the States, but not in the UK, for example). If there was to be any modification, I'd give priority to a template-based approach to source naming/citation creating, but with the users left to determine how simple or complicated they want their own templates to be. (If there was a facility to import and export templates, that would allow template sets to be shared by users for a variety of approaches.)

The other modification I'd like to see that would help improve citations (and a host of other things) is formatted text.

I like your idea of a generic source template scheme that is citation style agnostic. That is a more substantial development effort than I had in mind. Also, supporting formatted text throughout FH is probably a wish for most users.

I was considering adding some small enhancements with a plugin. It wouldn't impact users who don't use EE citations. Since some additional information is collected, issues arise about where is the best place to store it (in the GEDCOM Source record). I wonder if using an embedded Note might interfere with some FH reports.

Another idea that has not been discussed is labelled Notes.
So each style of Citation entry is labelled appropriately in the Note field.
e.g.

Mike, yes, labelled notes look promising. Do you know if they will work if the field spans multiple lines (using GEDCOM's CONC)?

There is another NOTE field at SOUR.DATA.NOTE2[1] that works nicely as a Data Reference. With appropriate mapping in the Property Box, it can be used without adding a plugin. The Data Reference Assistant describes this field as "Additional information provided by the submitter for understanding the enclosing data." It doesn't seem to show up in FH reports. Perhaps that is another candidate.

Yes, labelled text in any long text field supports CONCatenation tags, and the next CONTinuation tag delimits the end of the labelled text.
Long text fields include: Note, Address, Source Title, Author, Publication Info, and Text From Source.

Labelled text is supported by the =GetLabelledText() function.

Yes, SOUR.DATA.NOTE2[1] is a rarely used standard field associated with SOUR.DATA.EVEN that is meant to enumerate the different kinds of events recorded in a particular source. I agree it does not appear in Reports.

It is also feasible to have multiple instances SOUR.DATA.NOTE2[2] and SOUR.DATA.NOTE2[3], et seq, but earlier you said you were not keen on using unidentified NOTE2 tags in the All tab, so I have steered away from them.

This is my modified Property Box, with Full Reference Note = SOUR.TITL, Short Reference Note = SOUR.DATA.NOTE2[1], and Source List Entry = SOUR.DATA.NOTE2[2].


Before I was concerned that the citation entries would get listed here, but by using SOUR.DATA.NOTE2, they are not:


Normally the citation info is tucked away under Data, but expanded in this view.


I'll try entering a bunch of citations to make sure there aren't any unexpected surprises.
-Stan

That looks neat, and should export reliably to any software that fully implements standard Gedcom.

We can't guarantee that in future FH will always omit those Data Notes from the Notes tab, and omit them from Reports, especially as such omissions have been pointed out to Calico Pie. However, I would expect backward compatible options would be provided to perpetuate the omission.

I can't vouch for how external Gedcom reporting software might handle those tags.

I had some time to do further testing. Using SOUR.DATA.NOTE2 for citation data, does create issues with third party applications. Generally, notes under the Source Data section are combined with those in the general Source notes section. So although, it looks good in FH, it is not so good elsewhere.

I'm looking again at the custom tag approach. In that regard, I have one "last" question ...

If a custom tag is used instead of the SOUR.DATA.NOTE2 field, can it be displayed as "long text" in the Source property box? It seems fhGetDataClass consistently returns "text" for custom tags, whether or not they are followed by CONC, in the initializing GEDCOM.

Thanks,
-Stan

The Gedcom spec is silent on the type of non-standard custom tags. It seems that only the tags specifically defined as supporting CONC/CONT that are long text. I suspect it is up to each application to decide how to implement custom tags and it seems that FH only offers short text.

So if you want long text it will have to be a standard NOTE2 or other long text tag. Perhaps SOUR.NOTE2[2] et seq.