Family Historian User Group

Keywords: Import to Ancestry, Citation information, WWW, Web address, GEDCOM extension tag, Address Structure, Template, Uncategorised Data.

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).


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).


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).

I've moved this to the Exporting forum where it fits better.

IMO you have misunderstood the GEDCOM ADDRESS_STRUCTURE definition:
ADDRESS_STRUCTURE:=
n ADDR <ADDRESS_LINE>
+1 CONT <ADDRESS_LINE>
+1 ADR1 <ADDRESS_LINE1>
+1 ADR2 <ADDRESS_LINE2>
+1 ADR3 <ADDRESS_LINE3>
+1 CITY <ADDRESS_CITY>
+1 STAE <ADDRESS_STATE>
+1 POST <ADDRESS_POSTAL_CODE>
+1 CTRY <ADDRESS_COUNTRY>
n PHON <PHONE_NUMBER>
n EMAIL <ADDRESS_EMAIL>
n FAX <ADDRESS_FAX>
n WWW <ADDRESS_WEB_PAGE>

e.g. In a Repository, the ADDR, PHON, EMAIL, FAX & WWW tags are all at level 1 and only the tags inside the ADDR are at level 2, so FH is perfectly correct.

I do not have time just now to investigate, but have you tried the Export Gedcom File plugin that may well handle any custom use of the WWW tag in Ancestry.

dbnut wrote: ↑

12 Aug 2023 00:34

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).

Remember the important caveat here, though - such links generally lead to a paywall, so are only visible to users (including yourself) who have an active subscription to that site with the appropriate level of access (e.g. full global access to see UK records from outside the UK).

You're probably well aware of that constraint and have factored it into your intended use, but I didn't want a new user to find this thread in the future, spend a lot of time setting up the transfer, and then finding it doesn't work for them.

Mark1834 wrote: ↑

12 Aug 2023 12:11

You're probably well aware of that constraint and have factored it into your intended use, but I didn't want a new user to find this thread in the future, spend a lot of time setting up the transfer, and then finding it doesn't work for them.

Plus of course, links are subject to change as providers reorganise their datasets, or lose access to licence datasets, or disappear from the Internet...