TL;DR: This post suggests a Family Historian (FH) GEDCOM extension tag to store web page URLs, motivated (in part) by Ancestry tree Citation information item "Web address" that cannot be filled by a standard export from FH.
BACKGROUND
With care, transferring a Family Historian GED file to Ancestry can work well. One area that caused me problems is filling "Citation information": "Web address". That is shown on the Ancestry screenshot below of a fictitious citation detail.
My intended use is to capture and record the Ancestry (or other) URL of a website page displaying the content referenced in a citation (for future review and for easy access by others).
- FHUG Image.png (29.59 KiB) Viewed 1231 times
PROBLEM
"Web address" is the only Ancestry citation field that cannot be populated via direct import from FH - for me, a serious limitation.
A GED file exported from Ancestry shows this field is stored as:
4 WWW https://www.domain.com/page
where "WWW" is an illegal tag (at GEDCOM Version 5.5.1) in this context.
BACKGROUD
GEDCOM 5.5.1 grammar allows the WWW tag (Web home page address), but only in <<ADDRESS_STRUCTURE>>. Disappointingly, but perhaps not surprisingly?
ADDRESS_STRUCTURE is valid only within Header, Repository, Submitter, and Event records.
FAMILY HISTORIAN V.7 SUPPORT FOR WWW
Header: NO; Repository: YES, Submitter: YES, Event: YES
Thanks to Mike for pointing out my silly error:
BUT in every case, as a direct subordinate of the record's top level instead of (properly) via ADDRESS_STRUCTURE.
So in all three "supported" contexts, Calico's implementation apparently breaks GEDCOM grammar. However, IMO Calico's logic is more sensible than the GEDCOM authors'.
WORK-AROUNDS
Family Historian's "Citation: Where In Source" (PAGE) field should be reserved for its intended purpose. However, a website link logically belongs in a related area and a Note field could be used. But Notes (sensibly) import automatically to Ancestry as lines of "Citation information:Other information".
Possible work-arounds:
1. Use an extension tag "_SENT" ("Sentence", designed for individual events/attributes), but Family Historian allows no such extension for citations (or sources).
2. An alternative might have been to use Templates, but this is complicated, requires a user-defined "special", is a nightmare to add into a Diagram Text Scheme, and anyway will not import to Ancestry.
3. "Somehow" in Family Historian, create a new field within Source:Data called "_WWW". This is treated by FH as "Uncategorised Data", but can still be edited from the "Properties" "All" tab. An example is shown below (note the distinctive icon).
- Property Window.png (50.55 KiB) Viewed 1231 times
It cannot afterwards be created directly in any other event record's Source:Data, but can be copy/pasted from another. These are "uncategorised data" and appear to persist (unless removed deliberately via Tools). So that solves providing a field to hold arbitrary source citation website links.
But how to create this in the first place?
One approach is to edit the FH GEDCOM manually, inserting a line "4 _WWW Sample URL" below a suitable "3 DATA" within a suitable "2 SOUR" pointer (say, in an otherwise bare sample-individual's record created for that purpose).
As a precaution, the live FH .ged should be checked for previous use of a "_WWW" tag. Or some safer fake tag name can be invented (but see next).
Ancestry import seems to be perfectly happy to interpret "_WWW" as its preferred "WWW", so the Family Historian .ged needs no further editing before an upload to Ancestry. It works.
REVIEW
a) To my mind, there is no doubt that an equivalent to Ancestry's citation "WWW" field would be useful.
b) Family Historian could provide an extension tag such as "_WWW" to be available within Citation:Data. It need not be accessible in the source-citation window, being always available in the Properties All tab, so interface changes would not be necessary.
c) As far as I can tell, this would be a valid GEDCOM extension and grammatically correct (unlike FH's provision of "WWW" outside address structures).
d) Any corrections or alternatives would be appreciated, as well as reaction to creating this as a Wish List item .
RELATED
Very similar remarks may apply to Email and Phone number which (IMO) could usefully be added directly to an individual (rather than to e.g. Residence).
