What is Gigatrees?

Gigatrees is a genealogy application that will build a complete family tree website from your GEDCOM file, creating either static or dynamic web pages for both offline and online viewing. Gigatrees can also be used to generate standalone reports, including a GEDCOM Validation report, a Data Validation report and a non-integrated Blog.

Gigatrees now includes an application interface (AI) built using Fluffy UI. Users no longer have to manually edit their configuration files, although that possibly remains for advanced users. Check out the screenshots below. The AI can be used to setup every available configuration option, launch Gigatrees and view its resulting web pages (as long as they were generated as static HTML pages). The AI also includes detailed descriptions of each option, which can be viewed when clicking on the option name - see the second screenshot. These descriptions replace much of the online documentation.

Gigatrees Main Page Gigatrees Option Page


What are some of its features?

Gigatrees has many unique features. It is mobile friendly, built upon the responsive features of JQuery and Bootstrap 3. Gigatrees will read virtually any GEDCOM 5.5, 5.5.1 or 5.6 file including many vendor specific extensions. It also has built-in support for ANSI, UTF-8 and UTF-16 encoding, as well as ASCII, extended ASCII and UNICODE character sets. Gigatrees is fully configurable. It supports options to allow for full language translations and for data text replacements that together allow family trees to be presented in many written languages. Complete website header and footer substitution is also supported. Additionally, stylesheet overrides, menu bars and plugin extensions allow for creating unique websites, or if you would rather, provide for seamless integration into existing websites and content management systems like WordPress. Gigatrees also has integrated blog support for replacing WordPress when your ready. Gigatrees can be configured to generate pages in either HTML or PHP. PHP pages can be created statically or saved in an SQLite3 database for dynamic page serving reducing the Gigatree footprint to just a few files. Gigatrees supports webpage metadata, autodetects embedded URLs and allows for embedding HTML into almost any data field. Gigatrees has built in support for many popular vendor specific and Gigatrees-only extensions as well. Gigatrees allows for inserting new GEDCOM records and appending existing records via the configuration file, eliminating in many cases the need to modify a GEDCOM file to add new extensions. Gigatrees supports privacy and living flags, automatic living detection and accurate birth year estimation, allowing for both public and private website generation. Gigatrees has built in support for source categorization, source reference quality, defining evidence models, indicating negative evidence and both automatic and overridden certainty assessments ensuring that you and your visitors understand the accuracy of your claims. Gigatrees also supports several methods for assigning sources to parental associations, providing you to ability to finally provide evidence to back up your biological connections. Gigatrees has a number of other general features, such as the handling of both individual profile photos and source record images. It also autodetects and links URLs in your data, calculates consanguinity between spouses, calculates ethnicity estimates, has advanced date handling allowing it to recognize most non-standard unambiguous date formats, including built in support for British monarch dates. It also has advanced location processing, including the ability to automatically determine the coordinates for every location in your database. Among its many unique report pages are location maps, origin and population heatmaps, data alerts, family tree charts, census tables, ancestor, descendant, kinship, immigrant and nobility lists, event timelines, an autogenerated photo album and a fully integrated blog.


Samples, Comments, Blog

If you would like to see an online Gigatree in action, you can visit the author's home page where the latest version of Gigatrees is always in use, and where it implements many of the features available. It runs on an Apache web server and serves its pages dynamically from an SQLite3 database.

There is a comments section located at the bottom of this page where users can ask questions, report bugs or leave feedback. It is also used by the author to post tips and general updates.

There is also a blog where the author posts tutorials and other technical articles.

Details about each configurable option, and there are a lot, can be found in the Gigatrees application by clicking on any of the option headings. Your mouse cursor should display a question mark where help is available.


Where do I download the application?

Gigatrees is available as a downloadable, standalone, cost and ad free, Windows 32-bit or 64-bit application. There is no need to create user accounts or upload GEDCOM files to a server for processing. The application also does not install itself into your registry either.

GIGATREES 4.2.3
x32
  GIGATREES 4.2.3
x64

Revision History


Donate

Registration is not required to use Gigatrees. Gigatrees is a fully functional application right out of the box. However, if you use Gigatrees and find it useful, please consider making a donation.




Registration

By donating, you will not only make me happy, but you will also be able to register as a user. As a registered user you will have early access to new features and access to other more advanced features that are not required for general use. Currently the two features that are restricted to registered users are ethnicity estimates and dynamic page serving. Additional features are in the pipe. You can find your registration id in the header of any build report or log file. Please remember to provide your registration id at the time you make a donation. If you forget, no worries, just let me know later. The registration id is tied to the hardware platform your application is installed on, so if you move to another computer, you'll need to reregister. Upgrading does not affect your id, and they do not expire ... yet. You must have an Internet connection to use the any features associated with registered users. Also, the Gigatrees server must be online in order to verify your registered id. The latest report from Pingdom says the Gigatrees server was up 99.91% of the time.


License Agreements

The Gigatrees applications (gigatrees.exe and gigatrees-cli.exe) are written by Tim Forsythe and are licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License

Creative Commons License

This license agreement states that you cannot use the Gigatrees applications for any commercial purposes, and that when using them for non-commercial purposes, you may not modify them and that you must provide appropriate attribution. Read the full license agreement for more details. The license agreement applies only to the Gigatrees applications, not to the web pages generated by them. The generated web pages may be subject to other third-party end user agreements (See Below).The Gigatrees applications may also be subject to the following third-party license agreements, depending on your configuration.

The application generated web pages may use several third-party libraries, including those loaded by the default header and footer.

Most of the third party license agreements allow you to use them for any reason as long as you don't hold the licensor liable. There are a few things worth noting: mapping and translation services prohibit redistribution of their data, so please do not share your gigatrees.sqlite database or your auto-translated files with others; Disqus prohibits certain types of comments including copyrighted material; and Developer Express does not allow using their charts in commercial applications unless you pay a license fee. This may restrict you from making your Statistics page available only to paid subscribers. If that is your intention, consult their license agreement first. The Statistics page can be disabled, and the ChartJs plugin can be removed from your configuration to avoid potential license conflicts.

Your continued use of this application indicates your acceptance of all applicable license agreements.


Error Reporting and Anonymous Statistics

Gigatrees provides two Maintenance options that when enabled will send anonymous data to the Gigatrees server for processing. The Send Error Reports option enables Gigatrees to send information about critical failures such as crash dumps and processing errors to be used for troubleshooting application errors. This is the primary method by which the developer receives bug reports.

The Send Anonymous Stats option enables Gigatrees to send other types of anonymous data. Each time the application runs, performace data, including module timing and memory usage, is collected and sent and is used in development to optimize future releases. Aggregated GEDCOM tag counts are also collected and are used to discover when new record fields come into usage and which record fields are most commonly used. Information on the GEDCOM file itself, such as its GEDCOM version and revision, encoding and character sets, and exporting application are also collected in order to provide better support for particular versions and vendors. Configuration and feature usage data is also collected in order to understand how the application is being used so that development can procede in the most effective manner. Lastly, general statistics such as those found on a Statistics Page are collected and aggregated with previously collected data.

None of the information collected by the Gigatrees server is personally identifiable. At no point is any GEDCOM data collected or sent.


Upgrading Gigatrees

Gigatrees does not require the previous version to be uninstalled. Users may copy over their previous installation, however doing so may overwrite previously modified configuration and user files. Instead, users should install Gigatrees into a new folder and then copy over any configuration or user files as necessary. Your previous installation can be uninstalled once you've verified the new installation is functioning properly.


Installing Gigatrees

To install Gigatrees, download the latest version and extract the downloaded file into a folder of your choice. The extracted files will be installed into a gigatrees subfolder. Gigatrees is a standalone program and does not require separate installation files nor does it modify the system registry. It should be installed only onto a Windows operating system with the same architecture (x32, x64).


Uninstalling Gigatrees

To uninstall Gigatrees, simply delete the installation folder.


Running Gigatrees

Start the program by double clicking on (gigatrees.exe). Gigatrees can be used to create, edit and save configuration files, run the application, and view the generated web pages and build report. Before you can run the application, you will need to either save the default configuration to a named file, or open your own configuration file. When the application runs, it creates a batch file that includes command line parameters specifying the report type, configuration file, input file, output path, and build report. Gigatrees will then execute the batch file in a separate command window. After execution, the build report and the web pages can be accessed using the "View" menu.


Translating Gigatrees

All of the display text that Gigatrees generates is translatable. International users can use this feature to translate Gigatrees into their native language. English speakers can use this feature to display alternate text. GEDCOM data is not translated. Users needing to translate the data found in their GEDCOM file will need to use the Replace Text option instead. Users can translate their web pages either manually or automatically (using a translation service). The installation folder contains two translation files. The first, lang.txt contains only the default display strings. The second, en.txt contains both the default display strings and their associated English translations. The files are delimited by semi-colons (;) with the first column containing the default display strings and the second column containing the translated strings. Neither file is loaded automatically, but must be specified in the Translation section as discussed below. When no input file is specified, Gigatrees will use its default strings. When an input file is specified in the configuration, Gigatrees will generate an alert in the build log if either a default string or a translated string is not found within the file. If an output file is specified, the input file, along with any newly translated strings, will be saved to the file.

Manual Translations

To translate Gigatrees manually, users should copy the lang.txt file to a new file, add the translated strings to this file, set the Translation Input File option to the disk path of that file and then run the program.

Automatic Translations

To translate Gigatrees automatically, users will need to use one of the suppported translation services. Gigatrees supports both the for-FREE Microsoft translation service and the for-FEE Google translation service. To use the Microsoft translation service, users must sign-up for a free account at https://datamarket.azure.com and register a dummy application at https://datamarket.azure.com/developer/applications to obtain a valid Client Id and Client Secret. To use the Google translation service, users must sign up for an account at https://cloud.google.com/translate and follow the instructions there to create a dummy application and obtain a valid API Key.

To configure Gigatrees for automatic translations, users will need to first enable the service in the Translation options. They must then set the Service Provider to either "Microsoft" or "Google", set the Service Id to the dummy application id (Microsoft only) and the Service Key to the dummy application key/secret. Users will also need to set the Language Code to their preferred language. For a list of Microsoft supported languages and codes see: http://msdn.microsoft.com/en-us/library/hh456380.aspx. To get a list of supported languages and codes from Google see: https://cloud.google.com/translate/v2/translate-reference#supported_languages.

Users will also need make a copy of the lang.txt file and add the disk path of this new file to both the Translation Input File and the Output File.

When Gigatree runs, it will read in the default strings from the Input File file and for any (initially, all) missing translations it will query the translation service requesting a translation string using the Language Code specified. When finished, it will save the results to the Output File. On any error, it will stop querying the service and log an error. Automatic translations, especially on incomplete sentences, can be wonky at times. Users may want to make additional manual modifications to translated strings.


Integrating Gigatrees

The following settings can be used to integrate Gigatrees into a self hosted WordPress blog. Other blogs should work similarly. The Extension must be set to PHP and Linked Extension must be unchecked. If not using a Menu Bar, it will need to be disabled. If using a Menu Bar, the Fixed option should be unchecked so that the menu bar does not interfere with the blog's header. The Metadata option's Header and Footer will also need to be modified to load the blog's header and footer. This can be done directly in the configuration file or added as plugins. In addition, all existing plugins should be removed so that they do not interfere with the existing blog's functionality. For WordPress,

The Header should be set to:
<?php
  require_once($_SERVER['DOCUMENT_ROOT'].'/wordpress/wp-load.php');
  get_header();
?>
The Footer should be set to:
<?php
  get_footer();
?> 

Plugins

Gigatrees supports using external plugins. Gigatrees comes preinstalled with several.

Installing Plugins

To install additional plugins, add them to the install's plugin folder to have them copied automatically to the Output Path's plugin folder when running the application, or add them to the Output Path's plugin folder directly.

Once a plugin folder has been copied, use the Plugin option to add the plugin to your configuration. Plugins will be processed in the order they are listed. Unfortunately, the Gigatrees application interface does not allow reordering of plugins. To re-order, users will need to edit the configuration file manually.

Creating Plugins

To create a new plugin, create a folder using the name of your plugin. Inside that folder create a plugin.xml file and include any necessary configuration options. Generally, plugins make use of the Metadata DropHeader and DropFooter options to insert scripts and stylesheets associated with the plugin into the configured Header and Footer. Specialized PHP code can also be dropped into these places. Additional support files can be put anywhere inside the plugin folder or in subfolders. The %PluginsPath% substitution macro can be used to access the relative path of the plugin folder. Review the default configuration file and existing plugins for examples.


GEDCOM Extensions

Gigatrees supports a number of vendor specific GEDCOM extensions that can be used to extended the capabilities of that provided by the GEDCOM standard. Extensions include many of those found in Ancestry.com trees, Family Tree Maker, RootsWeb and other genealogical applications as well as those supported by Gigatrees only. The following sections detail the extensions currently supported.

Handling Privacy

When publishing family trees, privacy is an important consideration. Information about living persons and source material that might still be under copyright are two examples of sensitive information that should not be published online. The most common method for keeping this information private is to use a genealogy application to strip private data before building a family tree. This is generally overkill and may hide more data than is necessary. It also might not capture all private data when doing so. A more secure method is to use privatization flags that indicate exactly which records and fields should be privatized.

Gigatrees supports several methods for adding privatization flags to your database. The flags take effect when either the Security HideLiving or Security Privatize options have been enabled. The first method uses a generic set of GEDCOM tags that can be added as a record field, but in most cases require users to be able to add these to their GEDCOM file directly. This is great for Family Historian users, but users of other applications may not be able to add these. The second method is to use the Append Records option in the configuration file to append privacy flags to logical records. This method does not modify the users' file, however it only works on logical records, and cannot be used the add privacy flags to logical record fields. The third method allows privacy flags to be added to any record or field, by embedding the flag into record data. This method is supported by virtually all genealogy editors, but requires users to add Gigatrees specific text to their database, which might not be recognized and/or stripped by other applications. Users will need to decide which method works best for them.

Adding GEDCOM Extensions

Gigatrees supports four different flags (and their vendor specific alternates): _LIVE, _SHOW, _HIDE and _PRIV..

The first of these, _LIVE allows you to add a living flag to living person in your database

0 @I1@ INDI
1 _LIVE true

As shown in the example, privacy flags must be added as subfields to the records where they apply. In this case, the living flag is applied to the individual's logical record. When a person is flagged as living, Gigatrees will change their name to HIDDEN _____ and all claims and source references associated with that person are deleted, with the exception of their parental links. This ensures your tree will retain the placeholders for living persons, while keeping their data private. If you have configured Gigatrees to estimate birthdates, adding living flags will generally not be necessary. When missing birthdates have been estimated, Gigatrees is very effective in determining whether or not a person is living based on the vital statistics of their family members. In those rare instances when Gigatrees cannot calculate a birth date, having manually entered a living flag will ensure that the individual is privatized.

Vendor Specific Alternates: LVG, LVNG, _FLGS.__LIVING, ATTR Living, _LIVING Y.

If, on the other hand, you explicitly want to show details for a living person, such as yourself, you must force them to be displayed. To do this, simply add a _SHOW flag to those individuals

0 @I1@ INDI
1 _SHOW true

This will result in the living flag and any calculated living states to be ignored so that the flagged person's details are included in the tree. It is likely that you will only want to do this for a very few persons.

It is also likely that when you force a living person's details to be shown, there will be some details that should still be kept private, their birth date comes to mind. To do this you must add a private flag.

0 @I1@ INDI
1 _LIVE true
1 BIRT
2 DATE 1 JAN 2000
2 PLAC Chicago, IL
2 _PRIV Sensitive

All private records and their fields are completely stripped when generating a tree. In the case of this example, the entire birth record is omitted. Private flags can be added to any record or field, so, for instance, in the next example, only the date is stripped, not the location.

0 @I1@ INDI
1 BIRT
2 DATE 1 JAN 2000
3 _PRIV Sensitive
2 PLAC Chicago, IL

The privacy flag can be used to hide other types of data as well such as copyrighted material.

0 @S1@ SOUR
1 TITL Title Goes Here
1 TEXT Copyrighted text goes here
2 _PRIV Copyrighted

The privatization qualifiers, "true", "Sensitive" and "Copyrighted" are ignored by Gigatrees.

Vendor Specific Alternates: _FLGS.__PRIVATE, _CONF_FLAG.

Lastly, Gigatrees supports a hidden flag that can be placed, like the private flag, in any record or field to hide it under all circumstances, even if the Security.Privatize option is not enabled. This is useful if you have todo lists, research notes, or private claims that you never want displayed anywhere.

0 @I1@ INDI
1 SSN 123-456-7890
2 _HIDE true

Vendor Specific Alternates: _EXCLUDE

Configuring Privacy Flags

Gigatrees supports configuring privacy flags using the Append Records option for those users whose genealogy applications do not allow for adding GEDCOM extensions.

Embedding Privacy Flags

Configuring privacy flags only works on logical records directly. It does not work on subfields. To support this, Gigatrees allows embedding the _PRIV. and _HIDE. flags as {gigatrees:private} or {gigatrees:hide} in the data text associated with the field. For instance, the flag could be added to a NOTE record or a custom EVEN record. When an embedded flag is found, it is stripped from the data text so that it does not appear in your family tree.

Ancestry.com trees do not allow for adding GEDCOM extensions, so it is useful here to describe how embedded privacy flags can be used with an Ancestry.com tree for individual events. The easiest way to add the privacy flag to a fact or event is to put it in the Description field. The will be exported as

1 BIRT {gigatrees:private}

Since the flag appears as a field of the Individual record and not of the Birth subfield, and since there is no reason to add a privacy flag to the individual (a living flag is better served for individuals) an exception has been added for Ancestry.com trees, to hide the Birth record instead.


Defining Parental Associations

By far, the most important claims in genealogy, and the ones needing the most documentation, are the biological links between children and their parents. Gigatrees uses parental association records and their source references to determine the certainty status for biological links. Unfortunately, the GEDCOM standard does not provide a good method for handling these claims. The only supported record types they provide are the Pedigree Linkage Type (PEDI), which provides built in predefined relationship fields, but does not allow you to link a source to the record, and the ASSO record, which does allow for referencing sources, but does not have built in predefined relationship types such as "mother" or "father". Several vendors support other relationship records such as Family Tree Maker's _FREL and _MREL tags, but like the Pedigree Linkage Type record, these do not allow for source references.

Gigatrees supports parental associations using all these methods. The Pedigree Linkage Type must be set to birth for it to be treated as a biological relationship of both parents.

0 @I1@ INDI
1 FAMC @F1@
2 PEDI birth

The _FREL and _MREL tags must have values of Natural or Biological.

0 @I1@ INDI
1 FAMC @F1@
2 _FREL Natural
2 _MREL Natural

The ASSO record must set its RELA field to either "AssociatedFather" or "AssociatedMother". The translating option can be used to change these strings to something more preferrable, such as "father" and "mother".

0 @I1@ INDI
1 ASSO @I2@
2 RELA father
2 SOUR @S1@
1 ASSO @I3@
2 RELA mother
2 SOUR @S1@

Gigatrees also supports leaving the RELA field blank, or leaving it off altogether, which in either case will assume a parental association. Any other text in the RELA field will indicate a non-parental association.

Configuring Parental Associations

Users must rely on vendor support to use any of the above methods to define parental associations, and only the ASSO.RELA option allows for adding sources. Unfortunately, most vendors do not support this option. Gigatrees provides a method that will work for everyone, no matter which application they use. Gigatrees defines new parental association source reference and source reference certainty GEDCOM tags that can be set via the configuration file to provide evidence for the linked primary parents. The new tags, 1 _MREL_SOUR, 1 _MREL_CERT, 1 _FREL_SOUR, 1 _FREL_CERT can be added to any existing individual record by using the Append Records option. If you have defined your source categories, then the 1 _MREL_CERT and 1 _FREL_CERT tags are only necessary if you need to override your certainty assessments.


Defining Source Categories

Gigatrees supports a number of different options for categorizing your sources. When defined, source categories are shown with the meta data for each source page, as well as in the tooltips for every source reference. They are also shown on the sortable source index page. The purpose of defining source categories is to help determine the possible types of bias that may overshadow the claims the source makes. Source categories are used internally by Gigatrees to help calculate certainty assessments. The Genealogy Proof Standard (GPS) defines two types of source categories, referred to here as 'concurrency' and 'authority'. Source concurrency includes primary and secondary, where primary represents that the document was created at the time of the recorded events (such as a birth certificate), and secondary represents that the document was created some significant amount of time after the events occurred (such as a transcription of a birth certificate). Source authority includes both original and derivative, where original represents a document in its original form (such as a birth certificate) and derivative is a collection of claims derived from multiple primary and secondary sources (such as a town history). Claims that are both primary and original are generally considered to be unbiased, though not necessarily without error. Secondary sources may suffer memory bias due to a time lapse occurring between the event and the recording as well as from copy errors. Derivative sources may also suffer from these as well as author bias, intentional or otherwise. All sources may contain lies. From experience we know that certain type of records are more accurate and have less bias than others. For instance, birth certificates (original, primary) almost never have incorrect birth dates. Baptism records (original, secondary), even those recorded within just a few months of birth, may contain incorrect birth dates caused by memory lapses of the mother, as astounding as that seems. Death certificates and tombstones (original, secondary), which usually occur many years after birth and the informant is generally not the mother, often contain incorrect birth dates. Census records (original, primary) are notorious for having inaccurate ages due to the fact that the informant was more than likely a spouse of the head of household, and who, especially early on, had little formal education resulting in subtraction errors or simply guesswork. Had the census authorities required birth years instead of ages, they would probably be much more accurate. Census records, however, are very accurate for documenting parental relationships, so there you go. Categorizing sources can be very tricky and is sometimes more art than it is science. Gigatrees therefore allows users to not only categorize their sources, but to also override those source categories for individual claims when necessary. The following section explain the different methods that are supported by Gigatrees for adding source categories.

RootsWeb Support

Gigatrees supports source categories for those who use RootsWeb to enter their GPS fields. In RootsWeb, GPS fields are entered as part of the source reference and only use the capitalized first letter of the category, for instance, in the following example, "O" is an abbreviation for original and "P" is an abbreviation for primary

0 @I1@ INDI
1 BIRT
2 DATE 7 FEB 2014
2 SOUR @S1@
3 _QUAL
4 _SOUR O
4 _INFO P

Gigatrees will use the first reference for a source found with a _QUAL field to define the source's category, and ignore all other GPS fields in all other source references to the same source. It is assumed that they are all identical.

Adding GEDCOM Extensions

For all users, Gigatrees supports adding user defined source categorization fields to each source record using the vendor specific source quality (_QUAL) tag. The tag can be used to add either or both a source authority and a source concurrency category. Gigatrees also allows users to use the source type field (@SOUR.TYPE or @SOUR._TYPE) instead. The source quality tag supports several string values that extend the GPS categories to provide better bias resolution

Source Authority: "dna", "original", "transcript", "copy", "abstract", "research", "memoir", "derivative" and "unknown"

Source Concurrency: "primary", "secondary" and "unreliable"

The source category strings are translatable so that users can use strings in their own language.

When adding a source containing yDNA or mtDNA test results that prove a biological relationship, the dna category should be used. It would be inappropriate to use this for autosomal DNA test results unless those results were combined with an in-depth analysis showing why they could be used as proof. original represents a document in its original form. primary represents that the original document was created at the time the event occurred, and secondary is anything otherwise. transcript is a direct unaltered transcription of an original source. copy is a subsequent copy of a transcription or of another copy (i.e. copy of a copy). abstract is any abstraction or summary of the original source (not in its original form). research is an authoritative collection of claims derived from multiple sources. In order for the collection to be considered authoritative, the researcher or genealogist should have included the relevant source citations. memoir is a collection of authoritative claims taken from memory, such as an autobiography, letters, notes, etc. derivative is a non-authoritative collection of claims derived from multiple sources. This will include most books, town histories, etc. unknown is a source from which no information as to its authority can be determined, and Finally, unreliable is a source that is known to be non-authoritative and error prone.

For many sources, multiple source categories might apply. When determining the appropriate source category to use, you should choose the least authoritative category that applies to the claims being extracted from it. For instance, if you have a source that includes scans of original documents, along with some memoirs and derivatives, but you are only using the images of the original documents from that source, they you can rightfully choose original as your source category. If however you include claims from the other areas of the source, then you should choose a different source category. A serious genealogist might, in this case, split their single source up into several source entries, each with their own category.

0 @S1@ SOUR
1 _QUAL original

Configuring Source Categorization Flags

Gigatrees also supports configuring source categories using the Append Records option for those users whose genealogy applications do not allow for adding GEDCOM extensions. These work similarly to the flags described above.


Handling Source Metadata

Gigatrees supports three methods for capturing source metadata, including RootsWeb's template field for both source records and source reference fields, and other standalone GEDCOM and vendor specific source record fields.

Source Record Templates

RootsWeb implements a vendor specific source template field to define free-form name/value pairs. Users can implement these manually as well. Gigatrees will read these pairs and display them in the source header of the source page. Source templates display layouts are not supported. Virtually any name/value pair can be used. For instance, RootsWeb's uses many, including Bibliography, Footnote, ShortFootnote, Author, SuplAuthor, SuplRole, Title, SubTitle, PubPlace, Publisher, PubDate, OrigPubPlace, OrigPublisher, OrigDate, Creator, Periodical, SocietyInfo, Volume, Edition, PageRange, Remarks, Jurisdiction, County, District, Volume, Folder_Box, Series, AgencyRecords, Collection, Repository, RepositoryLoc, DatabaseTitle, ItemType, WebsiteOwner, WebsiteTitle and URL. URLs are automatically hyperlinked.

A typical name value pair might look something like the following:

0 @S1@ SOUR
1 _TMPLT
2 FIELD
3 NAME Bibliography
3 VALUE "United States Census, 1930," index and images, <i>FamilySearch</i> (ht
2 CONC tps://familysearch.org/pal:/MM9.1.1/XSG2-SRJ : accessed 28 Dec 2013), C
2 CONC hicago (Districts 0751-10020), Cook, Illinois, United States; citing en
2 CONC umeration district (ED) 0972, sheet , family 53, NARA microfilm publica
2 CONC tion.

Source Reference Field Templates

RootsWeb implements the same template field for source references as well, including Page, Author, Title, PostDate, AccessType, AccessDate, SpanRead, Annotation and ItemOfInterest. When Gigatrees discovers the Page item, it will use it value for the source reference page number if not otherwise defined. Source reference items are shown only in source reference tooltips.

A typical name value pair might look something like the following:

1 SOUR @S1@
2 _TMPLT
3 FIELD
4 NAME Page
4 VALUE p. 108

Source Record Fields

Gigatrees also recognizes several GEDCOM and vendor specific source record fields that can also be used to define source metadata. These include the GEDCOM TITL, ABBR and PUBL fields, as well as the vendor specific _SUBQ, _BIBL, EDTN, LOCA, TYPE, _TYPE, MEDI, _MEDI, DETA, and _OTHER fields.


Certainty Assessments

When publishing a family tree it is useful for visitors to be able to quickly and accurately assess the validity of the claims being made. Gigatrees automatically calculates the certainty assessment for every claim using several pieces of data including, the source category defined for the referenced sources, the source reference quality (QUAY) defined within the source references for the claim, and the Source Type defined within the source itself. Gigatrees will display the calculated certainty assessment alongside each claim. Gigatrees also supports manually setting the certainty assessment for claims.

Gigatrees defines numerous levels of certainty.

"unsupported", "estimated", "unreliable", "uncertain", "proposed", "reported", "supported", "probable", "certain", "questionable", "proven" and "impossible".

When multiple sources are referenced for a claim, the source with the best quality is used. If no source reference is found for a claim, the certainty assessment will be set to unsupported. If a source reference is found for a claim, but no source or source reference quality is defined, the certainty assessment will be set to uncertain. If the claim is an estimated (calculated) birth year, the certainty assessment will be set to estimated.

Overriding Certainty Assessments

On occasion, the calculated certainty assessment may be inappropriate for the claim being made. This can be caused by improper source categorization or failure to reference all the available sources. It can also be caused by a reliable source making a unreliable claim. To override these, Gigatrees supports setting the certainty assessment manually by adding the _CERT tag to any claim.

Vendor Specific Alternates: _PROOF

0 @I1@ INDI
1 BIRT
2 DATE 1 JAN 1900
2 _CERT proven

Overriding certainty assessments is the only method for directly indicating impossible claims, a term referred to by the GPS as negative evidence.

The certainty assessment strings are translatable so that users can use strings in their own language.

Order of Precedence

When displayed, claims always show to "best" assessment, which implies an order of precedence. In general the order of precedence always degrades from the most certain to the least certain. As shown in the table below, the are four GEDCOM data fields that affect order, the certainty assessment override field (_PROOF) described above, the presence of a source reference (SOUR@) for the claim, the source category (_QUAL), and the source reference quality (QUAY) as defined in the GEDCOM standard. Note that not all of the defined certainty assessment strings described above will be automatically determined, but can still be set using the certainty assessment override tag.

To prevent Gigatrees from making exaggerated certainty assessment determinations, sources that contain multiple types of evidence, should be set the source category to the quality associated with the least reliable evidence. Users can also break up their source into multiple sources, one for each type of evidence.

An "x" indicates that a field must be present. An empty field indicates the the value of the field has less precedence or does not matter.

_PROOF      SOUR@  _QUAL       QUAY  certainty
------      ----   -----       ----  ---------
                                     estimated [calculated]
impossible                           impossible
[value]                              [value]
            x                  0     questionable
            x      dna               proven
            x                  3     certain
            x      primary           certain
            x      original          certain
            x                  2     probable
            x      secondary         probable
            x      transcript        probable
            x      copy              probable
            x      abstract          probable
            x      research          supported
            x      memoir            reported
            x                  1     proposed
            x      derivative        proposed
            x      unknown           uncertain
            x      unreliable        unreliable
            x                        [see Source Types]
            x                        uncertain 
                                     unsupported

Source Types

When there is no other information available to determine the certainty assessment, Gigatrees makes one last ditch effort by looking at source's type (@SOUR.TYPE or @SOUR._TYPE) field. This is a non-standard GEDCOM field, but is used by several popular genealogy applications. This is also the preferred method for some users. The SourceType configuration option can be used to define source types, and which source category will be associated with which type of source. Valid source categories names must be used.


Defining Evidence Models

When using a source as evidence for a claim, it is useful to distinguish whether the source is making a direct claim or is indirectly supporting a conclusion. The Genealogy Proof Standard refers to these two models respectively as "direct" and "indirect". By default, source references indicating direct evidence are displayed in green with "Direct evidence for claim" shown in its tooltip. References indicating indirect evidence are displayed in purple and show "Indirect evidence supports this conclusion" in its tooltip. As with source categories, Gigatrees supports three options for defining evidence models.

Gigatrees supports the _EVID tag for every source reference. String values of direct and indirect are supported. Additionally, the abbreviations D and I are supported. For example, a source that makes a direct claim would be

0 @I1@ INDI
1 BIRT
2 DATE 7 FEB 2014
3 SOUR @S1@
4 _EVID direct

Gigatrees also supports RootsWeb version of the same flag, but located under the quality field

0 @I1@ INDI
1 BIRT
2 DATE 7 FEB 2014
3 SOUR @S1@
4 _QUAL
5 _EVID D

Gigatrees also supports embedding the evidence model into the source reference's NOTE or PAGE field to hold the GPS evidence model fields {gps:direct} or {gps:indirect}.

0 @I1@ INDI
1 BIRT
2 DATE 7 FEB 2014
3 SOUR @S1@
4 NOTE {gps:direct}

As with source category fields, the field is stripped from the note or page so that it is not shown in family trees.

Defining Negative Evidence

The Genealogy Proof Standard refers to evidence that has been disproved or that is impossible as "negative" evidence. Impossible claims are no longer considered when calculating birth date estimates, and improbabilities. Impossible claims are also highlighted on profile pages making it clear to all visitors that the claim is known to be false. Most genealogy programs have no way of indicating that a claim has been disproved, so genealogists are usually forced to delete disproved claims from their databases. This is an unfortunate practice that should not be necessary. Disproved claims should be accompanied by source references and text explaining why the claim is not to be false.

Gigatrees supports two methods for defining negative evidence. Users can override any calculated certainty assessment using the n _PROOF impossible tag as described earlier.

0 @I1@ INDI
1 BIRT
2 DATE 1 JAN 1900
2 SOUR @S1@
2 _PROOF impossible

Users can also use the built in GEDCOM tag for source reference quality (QUAY) and set it to 0. Some users may set their source reference quality to 0 for other than impossible claims, so Gigatrees will display a questionable certainty assessment. Users who only use this tag for impossible claims may want to use the translate feature to manually replace the questionable display text with impossible.

0 @I1@ INDI
1 BIRT
2 DATE 1 JAN 1900
2 SOUR @S1@
3 QUAY 0


Photo and Image Handling

Gigatrees includes special handling of profile photos for individuals as well as other images for sources, source references and events. Profile photos will be included on both the Photos page and on individual profile pages when the path to the photo is browsable. Other types of images are included on the source pages if they are defined or referenced by a source, and appear elsewhere otherwise. Details for photos and images are included on their tooltips. On the Photos page hover over an image to view the tooltips. Click on any of the links that appear in the tooltips to view the photo on the person's profile page, and click on any photo to view it using the FancyBox plugin that is loaded in the default Header.

Gigatrees recognizes several methods for defining photos and images along with vendor specific GEDCOM extensions for each.

Multimedia Records

Profile photos are defined by configuring a multimedia logical record (OBJE) and then referencing that record by an individual or family, or by defining an embedded multimedia record (OBJE) as part of an individual or family. When multimedia records are defined or referenced as part of a family, they will be included in the profile photos for the family's husband and wife only, not their children. Multimedia records support the GEDCOM tags: "FILE", "FILE.TITL" and "TITL". The file path can be set using either an absolute disk path, an absolute web path or a relative path. If the path does not end in a browsable photo extension ("png", "jpg", etc.) it will be interpreted as a URL instead.

Gigatrees supports several optional vendor specific mutlimedia record fields including:
_PHOTO - used instead of the "OBJE" when embedding photos or images
_FILE - used instead of the "FILE" field to include the path to the photo image
_TITL - used instead of the "TITL" field to include a photo title
_PIC - used to include the path to the thumbnail image if there is one
_CAP or _CMNT - used to include a caption
_SUBM - used to include submitter information
_NOTE - used instead of the "NOTE" field to include photo notes
_PLAC - used to include photo location information
_DATE - used to include photo date information.

The above tags can also be added to your GEDCOM file, or if you prefer, without modifying your GEDCOM file by using the Append Records option.

Custom Event Records

When using a genealogy editor, like Ancestry.com, that does not include extensions for their photo and image links, profile photos can be defined by creating a custom event with the event description ("TYPE") set to "Photo". A thumbnail can be optionally be included in the "PLAC" field. Ancestry.com adds a thumbnail automatically when creating a custom event where a photo is linked. The example shown uses an absolute web path.

0 @I1@ INDI	
1 EVEN http://domain.com/pics/walt.png
2 TYPE Photo
1 PLAC http://domain.com/thumbs/walt-thumb.png

In the above example, the vendor specific _PLAC field can be used instead of the PLAC field.

URLs

Source images can be defined using a multimedia record as described above or by using a "URL" tag with a path having an image browsable extension. Other types of extensions are treated as URLs. The vendor specific "_PIC" and "_TITL" fields are supported. The example shown uses relative paths.

0 @S1@ SOUR	
1 URL /folder/pics/1790-census-ny-ny-ny.png
2 _PIC /folder/pics/thumbs/1790-census-ny-ny-ny-thumb.png
2 _TITL 1790 U.S. Federal Census, New York City, New York, New York

In the above example, "WWW", "_URL", "_WEB", and "_LINK" tags can be used in place of the "URL" tag.

Web Tags

The _WEBTAG record is also supported for defining source images. Web tags use the "NAME" field for the image title, and the "URL" field as described above.

0 @S1@ SOUR
1 _WEBTAG
2 NAME Photo of my Uncle Walt
2 URL c:/folder/pics/walt.png
3 _PIC c:/folder/pics/thumbs/walt-thumb.png

Adjusting the Path

Gigatrees includes in the configuration three separate path fields, Profile Photos, Source Images and Thumbnails. The strings you configure in these path fields will be prepended to paths found in your GEDCOM file. So for instance if you wanted to view the images containing an absolute disk path ( c: ) in an offline tree, you would add file:// to each of these path options. This would allow your absolute paths to be viewed in a browser. You will need to make sure that the Hide Local Links option is disabled, it comes pre-enabled in the default configuration file. If your GEDCOM file uses relative paths like "/folder/pics/walt.png", and they were included in an adjacent folder, for example, then you could add file://.. to the paths to make them viewable offline. If you were using relative paths and were viewing your images in an online tree, then http://domain.com/path/to/photos could be used in the path options to remap them for viewing. If, on the otherhand, you need to remap absolute paths, then you would need to use the Replace Text option to strip your absolute path making your paths relative. i.e.

Depending on how unique the absolute paths in your GEDCOM file are, you may be able to leave the path options empty and do all the remapping using the Replace Text option. If you are publishing your tree online and cannot or do not want to remap your local photos, then you can enable the Hide Local Links option to remove all absolute links to both photos and URLs. Relative paths will not be affected by this option. It may be best to use absolute paths in your GEDCOM file so that you can more easily decide to later to either remap them or hide them.

Forcing Thumbnails

When thumbnails are not provided, default images are used instead. The default images are located in the installation's assets folder. Users can replace these if desired. Gigatrees provides a Force Thumbnails option that will, when enabled, hotlink the original image as its own thumbnail. No thumbnail files are created, the original images is simply shown with reduced dimensions. If you have many images on a page, this can result in slow page load speeds since each original photo must be loaded. This option does not effect profile photos as they are always hotlinked to forced thumbnails when no thumbnail is present.


Defining Articles

Whenever the vendor specific "_TITL" field if found under a "NOTE" or _BLOG logical record, Gigatrees will treat it as an Article or blog post. By default, article filenames are automatically generated from the title to create seo friendly URLs. The default filename can be overridden by defining an optional "_SLUG" field. Standard NOTE record fields are supported. Here is a complete lists of Article extensions.
_TITL - allows you to specify a title for your article.
_SLUG - allows you to override the default filename.
_DATE - allows you to specify a publication date.
_TIME - allows you to specify a publication time.

_MOD - allows you to specify a modified date.

_MODT - allows you to specify a modified time.

_AUTH - allows you to specify an article author. Only 1 author is permitted.
_ABST - allows you to include an abstract to display on the index page along with the Article's title.
_FEAT - allows you to define a featured image for each Article.
_PIC - allows you to define a thumbnail for the featured image.
_SUBM - allows you to provide credit for the featured image.
_CAT - allows you to specify a category for the article. Only 1 category is permitted.
_KEY - allows you to specify meta keywords for the article. These will be used to replace the %Keywords% in the header. Multiple keywords should be delimited by commas.
_TAG - allows you to specify a hash tag outside of article content. When doing so, spaces are allowed. Multiple _TAG elements are allowed.
_FLAG - allows you to specify article specific flags. The following flags are supported: SkipFeed (excludes post from feed), SkipFeedContent (excludes post content from feed), and HidePostImage (hides post image on post page)

When articles are defined, Gigatrees will create index pages in the form of a typical and simple blog. Gigatrees supports pagination on the index pages, and allows embedding HTML tags into the text of articles. It will also auto hotlink all URLs it finds in the text. For complete traceability, source references ("NOTE.SOUR@") are linked to their sources, and the referenced source pages link back to the article pages referencing them. Gigatrees also support tagging. Whenever Gigatrees finds a pound sign (#) followed by text, it will flag it as a hash tag. Dashes in hash tags are converted to spaces when displayed. Separate index pages are created for each hash tag, category and author found in your Blog. Hash tags in your text are automatically hotlinked to their index pages. The category and author are also linked at the top of your article pages and on the index pages, and the hash tags are linked at the bottom. In addition, the author, category and hash tag index pages are listed and linked at the bottom of the main index below the pagination element. When Disqus is enabled, your Article pages will also include at the bottom of the page a complete commenting system.

By default, article indexes are sorted by reverse publication date. Gigatrees also supports a Sort Order option to sort indexes by reverse modified date, and to sort indexes by reverse record id. Since record ids are generally assigned in numerical order, sorting by id is the same as publication date with the added benefit that you can manually adjust your record id to force a particular sorting order. You can for instance set an article that you want to be sticky a record much larger than all the others.

By default, publication and modified dates are shown in long format (i.e. January 12, 2001). Gigatrees supports a ShortDates option to force showing the dates in short format (i.e. Jan 12, 2001).

Gigatrees allows users to specify an abstract to display on the index page along with the Article's title. When no abstract is specified, one will be created automatically from post content. The length of the auto generated abstract is controlled by the AutoFeedAbstractLength option. HTML tags are stripped from all abstracts.

Users can also control the filename prefixes and suffixes for article, author, category and tag index lists and pages using the CategoryFilenamePrefix, TagFilenamePrefix, AuthorFilenamePrefix and ListFilenmeSuffix. Users can also append the category to the article title on page headers and filenames when setting the PrependCategoryToTitle option.

Gigatrees supports featured images for articles, however sometimes it is inconvenient to find an locate an appropriate image for out articles. Gigatrees supports adding multiple generic featured images using the Featured Images options that will be assigned randomly when none is defined so that you never have a missing image.

Gigatrees does not require GEDCOM concatenation tags to extend data lines nor GEDCOM continuation tag to add line breaks. Gigatrees does not put limits on line length, and it treats all carriage returns (or newlines) found in article text, as well as anywhere else in GEDCOM data as HTML break characters. This allows users to create stand alone blogs by adding GEDCOM _BLOG records to an empty text file and then loading the file as their GedcomFile. This is exactly how the Gigatrees Blog was built. Stand alone blogs can also be created by adding _BLOG records during configuration using the InsertRecord option. Although this method requires all HTML tags to be converted to using double brackets. Unexpected line breaks can occur in articles when GEDCOM continuation tags are not present because when embedding HTML tags within GEDCOM data, many such as header, page, and blockquotes have implied line breaks built into their opening and close elements. To minimize these unexpected breaks, users generally need to butt their HTML tags up against one another rather than putting them on separate lines. Gigatrees has a new CleanLineBreaks option that will convert multiple breaks to single breaks, and remove extra breaks around some of the more common HTML opening and closing tags. When this option is enabled, users can still force extra breaks by adding the HTML non-breaking space characacter entity (&nbsp;) to a blank line. Also when not using GEDCOM continuation tags, lines cannot begin with a "1", because they may be treated as a level 1 subfield of the record and then discarded because the line's arbitrary tag will not be supported. In those rare cases, the "1" should be preceded by a non-breaking space characacter entity as well. Using the Misc.CleanLineBreaks option allows large complex articles embedding HTML to add extra blank lines between HTML sections for improved readability.

Having built in Blog support has several advantages. Firstly, it allows you to include in your GEDCOM file all your genealogy research and proof arguments so that they remain affixed to your genealogy data at all times so can never be lost. Secondly, Gigatrees will include at the bottom of your article all referenced sources so that your visitors can follow along with your research.

Below is the typical format for an Article

0 @N1@ NOTE In the days of yore, ...
1 _TITL The Jones' Family History
1 _AUTH Jackie Jones
1 _DATE 1 Jan 2001
1 _SLUG the-jones-family-history
1 _ABST The article discusses the history of the Jones Family of Bohemia.
1 _FEAT /photos/n1.jpg
1 _PIC  /photos/n1-thumb.jpg
1 _SUBM Photo provided by <a href="http://jeffjones.com">Jeff Jones</a>
1 _CAT  Family History
1 SOUR  @S1@

Users whose Genealogy applications do not allow adding vendor specific fields to NOTE records can use the Append Records option to insert them on the fly.

Users whose Genealogy applications do not allow adding NOTE records can use the Insert Records option to insert them on the fly.


Census Record Handling

Census tables are included on a person's profile page if they have ancestors who were possibly living during the range of years specified by the CensusYears configuration option. Users can also create a standalone Census Table Report page by enabling the Census Page and setting a person's record id in the DescendantId option.

Census tables are composed of a rows showing every applicable ancestor and columns showing every configured census year. Then for each census record found, the state abbreviation is placed in the table cell associated with the record's ancestor and year. If no state abbreviation is found, then an 'X' is used instead. If the census record is missing, an "m" is used, and if the year does not apply to an individual, a "-" is used. The state abbreviation is linked back to the applicable source record if found. Hovering over the state abbreviation displays a tooltip with the source title. Gigatrees supports special text that can be entered into the GEDCOM CENS.CAUS field to indicate if an ancestor's first and last name were listed "Full Name", such as a head-of-household or unmarried children, only the given name was listed "Given Name Only", such as a spouse, or they were only counted "Counted Only", no name was listed. When this feature is used, the tooltip will reflect this information and the state abbreviation will either appear in bold (full name), underlined (given name) or in italics (counted). The special text used can be translated as needed to something more prefereable, such as "Named", "Given" and "Counted".

When a GEDCOM event description (CENS.TYPE) field is present, it will be used in place of the display string associated with the CENS tag in all timelines and event lists.

0 @I1@ INDI
1 CENS
2 TYPE Census (US Federal)
2 DATE 1 JAN 1920
2 PLAC 147 W. Knox St., Galesburg, Knox County, Illinois
2 AGE 5m
2 CAUS Named

Gigatrees also supports embedding a special flag {gigatrees:ignore} into any of the CENS record fields (with the exception of the date field) that will indicate that the person should be removed from all census tables for the year of that census record. An ancestor will be completely removed from a census table when it has been removed from every year for which they are applicable. This is useful for removing the early and immigrant ancestors from your tables who were living in areas where there were no censuses taken.

0 @I1@ INDI
1 CENS
2 DATE 1810
2 NOTE [ignore]

Ancestry.com uses the RESI tag instead of CENS tag to indicate census records. Gigatrees will recognize these when the source for the residence claim indicates that it is a census source record.


Defining Ships Names

A common need for immigrants is to show the name of the ship on which they arrived. Gigatrees supports adding a GEDCOM event description (INDI.EVEN.TYPE) field with the string "Vessel" to indicate when a ship's name is present in the record. The string can be translated as needed to something more prefereable, such as "Ship". When a matching event description is found, the ship's name will be searched for first as the value of the INDI.EVEN record itself, and if it is not found there, as the value of the INDI.EVEN.CAUS field and then lastly as the value of the first INDI.EVEN.NOTE field. This gives you several options for adding ship names. When found, the ship's name will be included with the emigration and immigration events on a person's event list, as well as a separate attribute and will be listed on the Immigrants Page.

1 EVEN H.M.S. Beagle
2 TYPE Ship		
2 NOTE The ship they sailed on

1 EVEN
2 TYPE Ship
2 CAUS H.M.S. Beagle
2 NOTE The ship they sailed on

1 EVEN
2 TYPE Ship
2 NOTE H.M.S. Beagle
2 CAUS The ship they sailed on

1 EVEN
2 TYPE Ship
2 NOTE H.M.S. Beagle
2 NOTE The ship they sailed on


Date Handling

Gigatrees recognizes dates in almost any unambiguous format. It also supports all GEDCOM calendars and their date formats including Gregorian (the default), Julian, Hebrew and French Republic. Non-Gregorian calendar dates will be shown in their original format as well as in Gregorian format for readability. Gigatrees also supports British Monarch dates such as 10 Hen II representing the year 1164. This is valuable to Medieval genealogists who may want to enter dates in the format they appear in the original records. Monarch dates can even be combined with Gregorian dates when entering date ranges or date periods, such as bet 10 Hen II and 6 Dec 1173. Whenever Monarch dates are shown, both the original Monarch date and the Gregorian date are shown for readability.

When displaying Gregorian dates, the month name abbreviations are translated using the appropriate translation string (Jan, Feb, Mar ... ). When displaying date qualifiers (abt, aft, and, bef, bet, cal, est, from, int, prob, to), their translations are also shown. The vendor specific qualifier, prob is an abbreviation for "probably". Gigatrees also accepts date qualifiers of about, after, before, between, by, circa, ca, ca., calc and near. Gigatrees recognizes Gregorian months in both abbreviated and full forms (Jan, January). It will also recognize months in their translated string formats. So for instance if you are French, and enter your month names as Janvier you could enter this as your translation string for January to have it recognized by Gigatrees. It will always be displayed using the translation string for Jan, which you could also set to Janvier if your like. Unrecognized dates are flagged and included in your data alerts.


Defining Marriage Order

Gigatrees supports several two special strings, "He Married" and "She Married", that can be configured in the GEDCOM family event description (FAMS.EVEN.TYPE) to indicate a husband's marriage order and a wife's marriage order. The strings can be translated as needed to something more prefereable. The marriage order should be defined using the GEDCOM FAMS.EVEN.CAUS record and set to a natural number: 1, 2, 3, etc. If defined, a person's marriages will display the ordinal (1st, 2nd, 3rd, etc.) for their marriage in their event lists. The following is an example of how the new event should be structured to indicate a husband's second marriage.

1 EVEN
2 TYPE He Married
2 CAUS 2


Page Number Handling

GEDCOM does not provide a method for adding multiple citations or citation page numbers to source records. Gigatrees allows this by providing the ability to add page numbers to source note fields (@SOUR.NOTE._PAGE) fields. Users can use this mechanism to add multiple citations using the @SOUR.NOTE fields.

Page numbers are treated as strings so may be defined however you choose, for instance you might find it necessary to define a page number to include a volume number like vol. II, pg 1-3. The advantage of defining page numbers is several fold. You can define multiple page numbers for the same source note field. These defined page numbers will then be listed on the source page in the heading of each note. If you use these same page numbers in your source reference's page field (SOUR@.PAGE), your source reference links will include the page numbers and link directly to that page in the source. Pages should be limited to 10 characters each or they will not be displayed in the source references.

0 @I1@ INDI
1 BIRT				
1 SOUR @S1@
2 PAGE 49,100-105

0 @S1@ SOUR
1 NOTE Page 49-50: yada yada yada
2 _PAGE 49
2 _PAGE 50
1 NOTE Page 100-105: yada yada yada
2 _PAGE 100
2 _PAGE 100-105

Ancestry.com requires when editing source information, to fill in the "Detail" field. This field is exported to the GEDCOM SOUR@.PAGE field. Often times, however, you do not have a page number that you want to include, however, Ancestry.com will not allow you to save your edits until you do. Gigatrees allows embedding the {gigatrees:pagenone} flag into the "Detail" field. When found, it will satisfy Ancestry.com and be stripped and ignored from your Gigatree.

1 BIRT				
1 SOUR @S1@
2 PAGE {gigatrees:pagenone}


Embedding HTML

Gigatrees allows you to embed HTML tags in virtually any GEDCOM field value. This feature can be used to embed preformatted text into notes and source citation fields. For instance you can include Census data like following so that it is more readable.

<pre>
     Line:                 22          23           24          25
     Name:                 Carl Jones  Sally Jones  Buck Jones  Starman Jones
     Relation:             Head        Wife H       Son         Son
     Home:                 Owned
     Mortgage:             Mortgaged
     Gender:               Male       Female        Male        Male
     Race:                 White      White         White       White
     Age:                  26         25            1 7/12      5/12
     Status:               Married    Married       Single      Single
</pre>

Ancestry.com, however, strips HTML tags from text fields. To get around this, Gigatrees treats {{ as the start of an HTML tag. It also treats {{nl}} as a new-line or carriage return ( \n ). You can embed the same preformatted text as above into Ancestry.com's text fields by using these tags like

{{pre>     Line:                 22          23           24          25
{{nl}}     Name:                 Carl Jones  Sally Jones  Buck Jones  Starman Jones
{{nl}}     Relation:             Head        Wife H       Son         Son
{{nl}}     Home:                 Owned
{{nl}}     Mortgage:             Mortgaged
{{nl}}     Gender:               Male       Female        Male        Male
{{nl}}     Race:                 White      White         White       White
{{nl}}     Age:                  26         25            1 7/12      5/12
{{nl}}     Status:               Married    Married       Single      Single
{{/pre>

In addition, absolute URLs, those including an HTML scheme (http://), are linked automatically. HTML anchor tag do not need to be added.


Appendix


GEDCOM Validator Description

GEDCOM Validation, in general, requires that a GEDCOM file meets the specification requirements of both the GEDCOM Grammar (line and file syntax) and the GEDCOM Dictionary (record format, data types, data formats and data values). Data consistency is not part of a GEDCOM Validation. The Gigatrees GEDCOM Validator is only a partial validator in that it does not in all cases, validate data formats or data values. It also does not have 100% coverage of the validation tests listed below.

The GEDCOM Validator will validate that files meet the GEDCOM 5.5 grammar specification and whichever GEDCOM dictionary is appropriate. The following dictionaries are currently supported:

  • GEDCOM 5.5 Rev. 1 (January 2, 1996)
  • GEDCOM 5.5 Rev. 2 (January 10, 1996)
  • GEDCOM 5.5.1
  • GEDCOM 5.6

The following sections provide technical details on how Gigatrees performs GEDCOM Validation.

Validation Legend

Symbols

() parentheses  = grouped components
[] brackets     = optional components
*  astricks     = multiple occurrences of a component
-  dash         = range of values of a component
|  pipe         = component or

Characters

Character               ASCII value
=========               ===========
tab                     = 0x09
line feed               = 0x0A
carriage return         = 0x0D
space                   = 0x20
exclamation point (!)   = 0x21
cross hatch (#)         = 0x23
colon (:)               = 0x3A
ampersand (@)           = 0x40
underscore (_)          = 0x5F

Character Sets

Character set           ASCII range
=============           ===========
number digit (0-9)      = (0x30 - 0x39)
alpha char (a-zA-Z_)    = (0x41 - 0x5A) | (0x61 - 0x7A) | 0x5F
non-alpha char          = (0x21 - 0x2F) | (0x3A - 0x3F) | (0x5B - 0x5E) | (0x7B - 0x7E) | (0x80 - 0xFE) | 0x60

Character Groups

alphanum                = (alpha char | number digit)	
printable character     = alphanum | non-alpha char | space | cross hatch

Strings

double-at string (@@)   = ampersand + ampersand
number string           = number digit + [number digit]*
alphanum string         = alphanum + [alphanum]*
pointer id              = (alphanum | exclamation point) + [printable character]*						
pointer string          = ampersand + pointer id + ampersand 
embedded id string      = ampersand + [pointer id +] exclamation point + pointer_id + ampersand 
escape string           = ampersand + cross hatch + (printable character | double-at string)* + ampersand + [space] + (printable character)* 
value string            = printable character + [printable character]*
data string             = (value string | escape string) [+ (value string | escape string)]*
delimiter               = space
terminator              = carriage return | line feed | (carriage return + line feed) | (line feed + carriage return)
whitespace              = ([tab]* + [space]* + [terminator]*)* 

Validation Tests

GEDCOM Validation testing includes two types of tests, GEDCOM Grammar and the GEDCOM Dictionary.

Grammar Line Syntax

All of the supported GEDCOM Dictionaries use the same GEDCOM 5.5 Grammar, which defines a line as having the following syntax:

line = [whitespace +] level + [delim + record_id +] delim + tag + [delim + reference_id +] terminator

or

line = [whitespace +] level + [delim + record_id +] delim + tag + [delim + line_value +] terminator

Grammar Tests

The following is a list of requirements of the GEDCOM 5.5 Grammar. Unsupported tests will be noted. String lengths are measured in characters, not bytes.

  1. The level is a number string.
  2. Level numbers should not contain leading zeroes.
  3. The minimum level number is 0.
  4. The maximum level number is 99.
  5. The maximum level number increment is 1.
  6. The level must be followed by a delimiter.

  7. A record_id can be a pointer string or an embedded id string.
  8. The length of a record_id is between 3 and 22 characters
  9. The record_id must be followed by a delimiter.
  10. The record_id must be unique to the file.

  11. for example:

    0 @I1@ INDI
    1 @!O1@ OBJE (I1 is implied)
    1 @I1!O1@ OBJE (duplicates not allowed)

    0 @I1@ INDI (duplicates not allowed)

  12. The tag is a alphanum string.
  13. The length of the tag is between 1 and 31 characters.
  14. The first 15 characters of the tag must be unique.

  15. A reference_id is a pointer string.
  16. The length of a reference_id is between 3 and 22 characters
  17. The reference_id must be preceded by a delimiter.
  18. The reference_id must be followed by a terminator.
  19. The presence of a reference_id implies that the record_id exists in the file unless a colon is present.
  20. If the reference_id contains an exclamation point, the record_id must exist in an embedded record contained within the same logical record.

    for example:

    0 @I1@ INDI
    1 @I1!O1@ OBJE
    1 OBJE @I1!O1@
    1 OBJE @!O1@ (I1 is implied)

    0 @I2@ INDI
    1 OBJE @I1!O1@ (not allowed)

  21. A line_value is a data string.
  22. The line_value must be preceded by a delimiter.
  23. The line_value must be followed by a terminator.
  24. If an ampersand is desired as part of the line_value, it must be included as a double-at string (i.e. name@@school.edu).

  25. The maximum length of a line is 255 characters.
  26. The maximum length of a logical record is 32 kilobytes. Logical records are delineated by level numbers equal to 0 (zero). [NOT SUPPORTED]

Dictionary Tests

To validate the dictionary, Gigatrees compares the structure of the logical records to the dictionary template associated with its GEDCOM version. It also validates general dictionary constructs common to all supported GEDCOM versions.

  1. The GEDCOM version must be either "5.5", "5.5.1" or "5.6".
  2. Each line should match the dictionary template unless the line has a user defined tag beginning with an underscore.
  3. Each record_id should be referenced from within the same file.
  4. If the template expects a record_id, then the line must have a record_id of the same type.
  5. If the template expects no record_id, then the line must not have a record_id.
  6. If the template expects a reference_id, then the line must have a reference_id of the same type.
  7. If the template expects no reference_id, then the line must not have a reference_id.
  8. If the template defines a minimum number of record occurrences, then the record should not have fewer.
  9. If the template defines a maximum number of record occurrences, then the record should not have more.
  10. If the template defines a minimum line_value length, then the line_value should not be shorter.
  11. If the template defines a maximum line_value length, then the line_value should not be longer.

Validation Statuses

Gigatrees somewhat arbitrarily, divides its validation statuses into three categories, Errors, Warnings, and Alerts. Errors are critical line failures that will more than likely prevent the line from being usable by importing applications. Warnings violate the letter of the specification, but are likely to not interfere with their usability by importing applications. Alerts are not violations and are provided for information purposes only. All warnings and alerts can be easily ignored by disabling the ShowValidationWarnings and ShowValidationAlerts options. Additional options are available for controlling how and which statuses are provided in a Validation Report.

Errors

  • Unsupported GEDCOM version detected
  • Level number expected
  • Level number gap
  • Invalid ID length
  • ID missing
  • Invalid ID reference length
  • Tag Expected
  • Data contains non-printable characters
  • ID reference missing
  • Unexpected ID reference
  • Invalid ID reference type
  • ID reference substitution
  • Duplicate record found
  • Referenced record not found

Warnings

  • Level number exceeds limit
  • Level has leading zero
  • ID delimiter missing
  • Invalid ID length
  • Invalid ID character
  • Invalid ID reference length
  • Invalid ID reference character
  • Invalid tag length
  • Invalid tag character
  • Too few occurrences of tag
  • Too many occurrences of tag
  • Data contains tabs
  • Maximum line length exceeded
  • Data missing
  • Insufficient data
  • Maximum data length exceeded
  • Data not expected
  • Trailing spaces not expected
  • Trailing data not expected
  • Unpaired ampersand (@)
  • Undefined record found
  • Record not referenced

Alerts

  • User defined record found


Data Validation

Data Validation is the process of attempting to validate some of the data in your GEDCOM file looking for impossible, improbable, inconsistent and missing data. The validator makes use of the configurable age parameters to set the thresholds it needs for some of the tests. The default age parameters can be modified to suit each user's needs. Gigatrees calculates average ages for death, marriage and generation span, which the validator will also use in its calculations. The calculated average can be viewed on the Statistics Page. Estimated birthdates are not used when calculating data alerts. Defining negative evidence is also useful to the Data Validator, which will ignore any event specified as impossible.

The following data consistency tests are performed during Data Validation and shown on your Data Alerts page.

  • Persons born after they were baptized
  • Persons born after they were married
  • Persons born after their children
  • Persons born after they died
  • Persons born after being buried
  • Persons born after one of their parents died
  • Persons born after one of their parents was buried
  • Persons baptized after being buried
  • Persons baptized after being married
  • Persons married after being buried
  • Persons baptized after they died
  • Persons married after they died
  • Parents died before having children
  • Persons died after being buried
  • Persons buried before having children
  • Persons with multiple parents
  • Persons having an ancestral loop
  • Persons baptized after a certain age
  • Persons married before a certain age
  • Wives married after a certain age
  • Persons living past a certain age
  • Persons who are much older than their spouse
  • Persons having children before a certain age
  • Mothers having children past a certain age
  • Persons having similarly named children
  • Persons having a prohibited kinship
  • Persons having a non-biological parent
  • Persons with unknown genders
  • Families having swapped spouses
  • Persons whose birth dates could not be estimated
  • Persons with unsupported claims
  • Persons with undocumented parents
  • Persons with no parents
  • Persons missing one parent
  • Persons with date phrases
  • Unmappable locations

Data Validation Short Codes

When the Estimate Birthdates> option is enabled, Gigatrees uses the events associated with a person's nearest relatives to help determine a range of probable birthdates. When a person's birthdate cannot be estimated it is because there is an inconsistency between these claims, or between one or more of these claims and the configuration. The inconsistency may be too deep to have been detected otherwise. A list of persons whose birthdates could not be estimated will automatically be included in the Data Alerts page. For each person the following short codes will also be shown to help users track down these inconsistencies:

  • fb = father's birth
  • mb = mother's birth
  • pm = parent's marriage
  • b = birth
  • bp = baptism
  • sb = earliest spouse's birth
  • xb = latest sibling's birth
  • m = earliest marriage
  • cb = child's birth (range)
  • cm = earliest child's marriage
  • pd = latest parents death
  • d = death
  • bu = burial
  • le = living event (range)
  • fe = flourishing event (range)


Date Formats

Gigatrees recognizes a wide variety of date formats, beyond those specified by the GEDCOM specification. The following testing results from the date module list both the original and the converted dates. When a date is not recognized, it will show "(not valid)". Although this is not a complete list of every possible combination, it should provide enough coverage so that users should be able to figure out if a date will be recognized and how it will be interpreted. Ambiguous dates may be interpreted in a way other than what the user intended. If that is the case, users should change the date in their file accordingly. Unrecognized dates are listed on the Data Alerts page.

FAILURE: 30/8/1850 (not valid)
FAILURE: 8/30/1850 (not valid)
FAILURE: 8.30.1850 (not valid)
FAILURE: 30.8.1850 (not valid)
FAILURE: 8-30-1850 (not valid)
FAILURE: 30-8-1850 (not valid)
FAILURE: 1850/30/8 (not valid)
FAILURE: 1850/8/30 (not valid)
FAILURE: 1850.8.30 (not valid)
FAILURE: 1850.30.8 (not valid)
FAILURE: 1850-8-30 (not valid)
FAILURE: 1850-30-8 (not valid)
FAILURE: 3 1952 (not valid)
FAILURE: 3/1952 (not valid)
FAILURE: 3-1952 (not valid)
FAILURE: >= 3 JAN 1850 (not valid)
FAILURE: 18/19 Oct 1216 (not valid)
FAILURE: JAN/FEB/MAR 1850 (not valid)
FAILURE: Q3 1850 (not valid)
FAILURE: Winter 1850 (not valid)
Pass: 1850 => 1850
Pass: 1688/89 => 1688/89
Pass: 1689/90 => 1689/90
Pass: 1699/00 => 1699/00
Pass: 1699/1700 => 1699/00
Pass: 1700/1701 => 1700/01
Pass: 1700/01 => 1700/01
Pass: 1700/1702 => bet 1700 and 1702
Pass: 1700/02 => bet 1700 and 1702
Pass: 1700/10 => bet 1700 and 1710
Pass: 1688-1689 => from 1688 to 1689
Pass: 1688 / 89 => 1688/89
Pass: 1688 \ 89 => 1688/89
Pass: 1688\89 => 1688/89
Pass: 1688 - 1689 => from 1688 to 1689
Pass: 1688 1689 => bet 1688 and 1689
Pass: 1688, 1689 => bet 1688 and 1689
Pass: 1688 1689 1690 1691 => bet 1688 and 1691
Pass: 1688, 1689, 1690, 1691 => bet 1688 and 1691
Pass: 1688, 1689, 1690, 1701 => bet 1688 and 1701
Pass: 1699 1700 1701 => bet 1699 and 1701
Pass: 1699 1700 32 => bet 1699 and 1732
Pass: 1631 32 33 => bet 1631 and 1633
Pass: 1631 and 1632 => bet 1631 and 1632
Pass: 1631 or 1632 =>  1631 or 1632
Pass: 1631, 1633 or 1632 => bet 1631 and 1633
Pass: JAN 1850 => Jan of 1850
Pass: 1850 JAN => Jan of 1850
Pass: 3 JAN 1850 => Jan 3, 1850
Pass: 3 1850 JAN => Jan 3, 1850
Pass: 1850 JAN 3 => Jan 3, 1850
Pass: 1850 3 JAN => Jan 3, 1850
Pass: JAN 1850 3 => Jan 3, 1850
Pass: JAN 3 1850 => Jan 3, 1850
Pass: 3 JAN 1850/51 => Jan 3, 1850/51
Pass: 3 JAN 1850/1 => Jan 3, 1850/51
Pass: 1850/51 JAN 3 => Jan 3, 1850/51
Pass: 1850/1 JAN 3 => Jan 3, 1850/51
Pass: 1850/51 3 JAN => Jan 3, 1850/51
Pass: 1850/1 3 JAN => Jan 3, 1850/51
Pass: January 3, 1850 => Jan 3, 1850
Pass: 1850 MARS => Mar of 1850
Pass: (1850 MARS) => Mar of 1850
Pass: abt 3 JAN 1850 => abt Jan 3, 1850
Pass: (abt) 3 JAN 1850 => abt Jan 3, 1850
Pass: abt. 3 JAN 1850 => abt Jan 3, 1850
Pass: about 3 JAN 1850 => abt Jan 3, 1850
Pass: circa 3 JAN 1850 => abt Jan 3, 1850
Pass: ca 3 JAN 1850 => abt Jan 3, 1850
Pass: ca. 3 JAN 1850 => abt Jan 3, 1850
Pass: near 3 JAN 1850 => abt Jan 3, 1850
Pass: approx 3 JAN 1850 => abt Jan 3, 1850
Pass: (approx) 3 JAN 1850 => abt Jan 3, 1850
Pass: 3 JAN 1850 abt => abt Jan 3, 1850
Pass: 3 JAN 1850 approx => abt Jan 3, 1850
Pass: 3 JAN 1850 (approx) => Jan 3, 1850 (approx)
Pass: bet 3 JAN 1850 and 1850 JAN 5 => bet Jan 3, 1850 and Jan 5, 1850
Pass: between 3 JAN 1850 and 1850 JAN 5 => bet Jan 3, 1850 and Jan 5, 1850
Pass: betw 3 JAN 1850 and 1850 JAN 5 => bet Jan 3, 1850 and Jan 5, 1850
Pass: bet 3 JAN 1850/1 and 1850/1 JAN 5 => bet Jan 3, 1850/51 and Jan 5, 1850/51
Pass: bet 3 JAN 1850/1 and 1850/2 JAN 5 => bet Jan 3, 1850/51 and Jan 5, 1852
Pass: bet 3 JAN 1850 1853 and 1850 1852 1854 JAN 5 => bet Jan 3, 1850 and Jan 5, 1854
Pass: from 3 JAN 1850 => from Jan 3, 1850
Pass: from 3 JAN 1850 to 1850 JAN 5 => from Jan 3, 1850 to Jan 5, 1850
Pass: bef 3 JAN 1850 => bef Jan 3, 1850
Pass: bef. 3 JAN 1850 => bef Jan 3, 1850
Pass: before 3 JAN 1850 => bef Jan 3, 1850
Pass: by 3 JAN 1850 => by Jan 3, 1850
Pass: <= 3 JAN 1850 => by Jan 3, 1850
Pass: aft 3 JAN 1850 => aft Jan 3, 1850
Pass: after 3 JAN 1850 => aft Jan 3, 1850
Pass: aft. 3 JAN 1850 => aft Jan 3, 1850
Pass: cal 3 JAN 1850 => cal Jan 3, 1850
Pass: calc 3 JAN 1850 => cal Jan 3, 1850
Pass: prob 3 JAN 1850 => prob Jan 3, 1850
Pass: est 3 JAN 1850 => est Jan 3, 1850
Pass: int 3 JAN 1850 => int Jan 3, 1850
Pass: int 3 JAN 1850 (found in record) => int Jan 3, 1850 (found in record)
Pass: @#DGREGORIAN@ 3 JAN 1850 => Jan 3, 1850
Pass: @#DJULIAN@ 3 JAN 1850 => Jan 3, 1850 [Julian] 
Pass: @#DHEBREW@ 3 JAN 1850 => Jan 3, 1850
Pass: bet 1689/90 and 1699/00 => bet 1689/90 and 1699/00
Pass: bet 1689/91 and 1699/01 => bet 1689 and 1701
Pass: 3 HEN I => cal 1102 (3 HEN I)
Pass: 53 HEN I => cal 1152 (53 HEN I)
Pass: 3 HEN II => cal 1156 (3 HEN II)
Pass: 3 GEO VI => cal 1938 (3 GEO VI)
Pass: 3 George VI => cal 1938 (3 George VI) [cal 1938 (3 Geo VI)]
Pass: bet 3 HEN I and 4 HEN I => bet 1102 and 1103 (bet 3 HEN I and 4 HEN I)
Pass: bet 3 HEN I and 53 HEN I => bet 1102 and 1152 (bet 3 HEN I and 53 HEN I)
Pass: bet 3 JAN 1000 and 3 HEN I => bet Jan 3, 1000 and 1102 (bet 3 JAN 1000 and 3 HEN I)
Pass: bet 3 JAN 1000 and 53 HEN I => bet Jan 3, 1000 and 1152 (bet 3 JAN 1000 and 53 HEN I)
Pass: bet 3 HEN I and 3 JAN 1200 => bet 1102 and Jan 3, 1200 (bet 3 HEN I and 3 JAN 1200)
Pass: bet 53 HEN I and 3 JAN 1200 => bet 1152 and Jan 3, 1200 (bet 53 HEN I and 3 JAN 1200)
Pass: < 3 JAN 1850 => bef Jan 3, 1850
Pass: > 3 JAN 1850 => aft Jan 3, 1850
Pass: <3 JAN 1850 => bef Jan 3, 1850
Pass:  bef Jan of 1850
Pass: <1850 => bef 1850
Pass: >3 JAN 1850 => aft Jan 3, 1850
Pass: >JAN 1850 => aft Jan of 1850
Pass: >1850 => aft 1850
Pass: ~ 3 JAN 1850 => abt Jan 3, 1850
Pass: ~3 JAN 1850 => abt Jan 3, 1850
Pass: ~1850 JAN 3 => abt Jan 3, 1850
Pass: ~JAN 3 1850 => abt Jan 3, 1850
Pass: Sept 1939 => Sep of 1939
Pass: 13 Sept 1945 => Sep 13, 1945
Pass: Feb 3, 1926 => Feb 3, 1926
Pass: c 1977 => abt 1977
Pass: c1977 => abt 1977
Pass: 1949? => maybe 1949
Pass: ?1949 => maybe 1949
Pass: maybe 1949 => maybe 1949
Pass: poss 1949 => maybe 1949
Pass: poss. 1949 => maybe 1949
Pass: possibly 1949 => maybe 1949
Pass: bet 1879 and 1949? => bet 1879 and 1949 (?)
Pass: 1879-1949? => from 1879 to 1949 (?)
Pass: 1879?-1949 => from 1879 to 1949 (?)
Pass: 1879?-1949? => from 1879 to 1949 (?)
Pass: Bet. 1851-1857 => bet 1851 and 1857
Pass: Bet. 1851&1857 => bet 1851 and 1857
Pass: Bet. 1851&1857/8 => bet 1851 and 1857/58
Pass: 11 Jul 1861 or 1868 =>  Jul 11, 1861 or 1868
Pass: 11 Jul 1861|1868 =>  Jul 11, 1861 or 1868
Pass: 1775 or 1751 =>  1751 or 1775
Pass: 1775|1751 =>  1751 or 1775
Pass: 1550/1490 => bet 1490 and 1550
Pass: 10 Jun 1633/16 => bet Jun 10, 1633 and 1716
Pass: 23 Sep 1903 or 3 Sep 1899 =>  Sep 3, 1899 or Sep 23, 1903
Pass: 11th Feb 1902 => Feb 11, 1902
Pass: 2005, 8 June 2009 - 2 may 2013 => bet Jun 8, 2005 and May 2, 2013
Pass: 12 or 17 Oct 1812 =>  Oct 12, 1812 or Oct 17, 1812
Pass: bet 6 Mar and 1812 12 JAN => bet Jan 12, 1812 and Mar 6, 1812
Pass: bet Mar 6 and 1812 12 JAN => bet Jan 12, 1812 and Mar 6, 1812
Pass: 1952 comment1 comment2 comment3 => 1952 (comment1 comment2 comment3)
Pass: 1952 (comment1 comment2 comment3) => 1952 (comment1 comment2 comment3)
Pass: Before 679 He was Murdered => bef 679 (He was Murdered)
Pass: 10 Jun 1633-16 Jun 1633 Christening => from Jun 10, 1633 to Jun 16, 1633 (Christening)
Pass: 10 Jun 1633 to 16 Jun 1633 Christening => from Jun 10, 1633 to Jun 16, 1633 (Christening)
Pass: 21 mai 1984, comment => May 21, 1984 (comment)
Pass: 23 sep 1972, comment => Sep 23, 1972 (comment)
Pass: BET APR AND JUN 1895 => bet Apr of 1895 and Jun of 1895
Pass: Bet. 1978-1994 => bet 1978 and 1994
Pass: Bet. Apr-Jun 1895 => bet Apr of 1895 and Jun of 1895
Pass: Jan-Feb-Mar 1939 => from Jan of 1939 to Mar of 1939
Pass: JAN FEB MAR 1850 => bet Jan of 1850 and Mar of 1850
Pass: 1990s => bet 1990 and 1999
Pass: 1990's => bet 1990 and 1999



Yet Another Genealogy Numbering System

See Blog

Commments