Help:Assertions

Experimental Practice - Not yet a Community Standard!
Please add your questions and comments to this talk page

Introduction

Fact assertion templates have been created to extend WeRelate semantics, in ways that we believe will be useful for people and software. WeRelate was designed to permit representation of those semantics which exist in the GEDCOM file standard - so it is able to both import and export information covered by that specficification, without loss of potential understanding. However, information not contemplated by the present GEDCOM standard, has no standard representation. For example, GEDCOM does not provide a standard way to indicate that two people are often confused. Or if there is a family which, while not accepted as the parent of an individual, is never the less the subject of important speculation, there is no particular way that information can be reprsented.

Of course, the situations above can be indicated as notes, and attached to the people in question. Alternatively, they can be indicated as content in the narrative body of a page (a common practice has been to create a section called "Disputed Lineages"), or noted as free-form text added to the description field of "other" type facts. That choice is, sadly, costly in a couple of ways. Since the information is not represented predictably and objectively, supporting software can not make use of it. The practice, while widely used, is not a community standard - so some editors have been free to reject the practice. Further, the lack of consistency in display makes it more likely that any given user/editor will not recognize when one of these situations is present.

The assertion templates then, provide standard ways to handle some additional types of information. There will be a standard way to enter the information into the system - with a corresponding standard display. Since the templates (where appropriate) accept specific parameters relating to the situation being designated - information is objectively understandable and useful to software working with the werelate database.

Family Connection Assertions

These templates establish something respecting a normal family connection. As such, they exhibit a common general form. In the following description, "Xxx" represents a name that designates one of the family connection assertion types, such as "Refuted" or "Speculative" (discussed below).

When the string to which the assertion refers (the string given as a parameter to the template) is an actual family or person, the string should be expressed as the page title without the type prefix (e.g. without "Person:"). Further, the page referred to should contain a corresponding back-linking assertion of one of the kinds shown in "Pairs with" above.

Refuted Family Connection

A "Refuted" fact assertion is used to mark a supposed family connection that has been shown to be incorrect. The connection is one that had formerly been presented on WeRelate or elsewhere as probable or as fact, but the connection is now not generally accepted because there is evidence showing it to be wrong.

The refuted connection is shown on a WeRelate Person or Family page as a "Facts and Events" entry. For instance, placing "{{RefutedChild|Margaret Crassus (1)}}" in the description for an "Other" fact yields:

The name that follows the refuted relationship type is a link to that person's page on WeRelate if a page for that person has been created. If there is no WeRelate page, it is just the person's name. If the relationship is to a family (as for "Refuted Parents"), then the names of the husband and wife appear, which link to their family page if there is one on WeRelate.

On the WeRelate page that a Refuted Family Connection links to there should be another Refuted assertion which is the complement of the first assertion. For instance, in the example shown above from a Family page, the Person page for Margaret Crassus should have a "Refuted Family" entry which links back to the original Family page. Thus, two assertions "pair" to cover the supposed relationship from both ends. Any number of Refuted Family Connection assertions may appear on a page, as needed.

When editing a WeRelate page, a Refuted connection assertion is added by using a "template" of the right kind. The template usage is filled in with a parameter to give the name of the person or family. The following table lists the available Refuted Family Connection template. The template name shown links to the template page, where information on specifically how to use it is shown.

Examples

• Samuel Allen shows use of the "Refuted Parents" assertion when the parents involved do not have WeRelate pages. (The appearance is much the same, and although there is a link, the page linked to does not exist, and of course cannot have a link pointing back.)
• John FitzGilbert and Sibilla De Salisbury indicated by Complete Peerage as parents of Margaret, but refuted by Cawley, who offers William Crassus and Unknown Marshall.
• Betsey Hildreth and Ephraim Hildreth and Elizabeth Ellenwood - Shows a situation where a set of offered parents for a child has been subsequently shown to be untrue.

Speculative Family Connection

A "Speculative" fact assertion is used to express a possible family connection that is now neither generally accepted nor convincingly refuted. It is used to record the possibility and to encourage research to confirm or refute the connection. There may be more than one such value for any given kind of relationship. Also, while it would be unusual, it is possible for there to be a generally accepted value AND one or more speculative values for the same connection.

The Speculative connection is shown on a WeRelate Person or Family page as a "Facts and Events" entry. For instance, placing "{{SpeculativeChild|William Sabin (2)}}" in the description for an "Other" fact on a Family page yields:

The name that follows the Speculative relationship type is a link to that person's page on WeRelate if a page for that person has been created. If there is no WeRelate page, it is just the person's name. If the relationship is to a family (as for "Speculative Parents"), then the names of the husband and wife appear, which link to their family page if there is one on WeRelate.

On the WeRelate page to which a Speculative Family Connection links, there should be another Speculative assertion which is the complement of the first assertion. For instance, in the example shown above from a Family page, the Person page for William Sabin should have a "Speculative Family" entry which links back to the original Family page. Thus, two assertions "pair" to cover the supposed relationship from both ends. Any number of Speculative Family Connection assertions may appear on a page, as needed.

When editing a WeRelate page, a Speculative connection assertion is added by using a "template" of the right kind. The template usage is filled in with a parameter to give the name of the person or family. The following table lists the available Speculative Family Connection template. The template name shown links to the template page, where information on specifically how to use it is shown.

Examples

• William Sabin and Richard Sabin and Mary Bushe, Samuel Sabin and Elizabeth or Samuel Sabin and Mary Bushe - show use of the speculative assertion for three sets of potential parents for William Sabin.
• Unknown and Agnes Blewett - Paternity of Richard Edwardes in doubt.

No Accepted Connection

A "No Accepted connection" fact assertion is used to positively assert that there is no person or family for which the indicated connection is generally accepted. An assertion of this kind does not preclude speculative connection assertions of the same relationship type, but it should preclude a normal WeRelate connection of the indicated relationship type.

When editing a WeRelate page, a "No Accepted connection" assertion is added by using a "template" of the right kind. The available templates are NoAcceptedParents, NoAcceptedFamily, NoAcceptedWife, NoAcceptedHusband, NoAcceptedChild, NoAcceptedMother, NoAcceptedFather. These templates take no parameter values. See the specific template page for information on how to use it.

Presence of one of these templates may, in the future, prevent creation of the indicated relationship type (until an editor removes the invocation of the template). For example, the presence of the "NoAcceptedParents" template could preclude the setting of a value for the parents of a Person - or "NoAcceptedMother" would preclude attachment, as a child, to a family page with a defined Mother.

Examples

• Rebecca Hilton - who may not even be a Hilton - but has certainly not been demonstrated to be a member of the Hilton family of William and Edward at Dover Point.

Indicating Adoption

Ordinary family page connections are not a good way to indicate an adoptive relationship, because there are many situations where both birth and adoptive parents are known. This would also create ambiguity over what was a natural birth and what was an adoption.

Person pages already include "Adoption" as a fact type, which is the right way to indicate that person was adopted by another person or family. There is, however, no standard description. We would also like to have symmetric links between parties to an adoption, so that each refers to the other by way of an active link.

• On a family page - AdoptiveChild template as a description in an "Other" type fact. Takes name of child as a parameter.
• On a person page - AdoptiveParents template as a description in the "Adoption" type fact. Takes name of adoptive family page as a parameter.
• On a person page - AdoptiveParent template as a description in the "Adoption" type fact, if adoption by an individual.

Examples

• AdoptiveChild template on family page for adoptive parents, AdoptiveParents template used as Adoption fact description on Child's page (for example, Dorothy Arris by Henry and Dorothy Sanborn).

House of Nobility

Genealogy prior to modern record keeping and surname practices tends to be limited to those with inherited royal or noble rank. While a house or dynasty name is quite similar to a modern surname, neither is it considered to be equivalent. Moreover, WeRelate Person pages automatically add Person pages to a number of categories, by permuting the surname field(s) with life event locations. While useful for people living in the last few hundred years, this creates meaningless content when applied to individuals living in relative antiquity.

The NobleHouse fact assertion template has been created to address both the problem visually establishing membership of a person in a house of nobility, and to flag them for inclusion in an appropriate corresponding category. To use it:

• Leave the Surname field (or fields, if there are alternate names present) entirely empty
• Create a fact of type of "Other", adding to the description field the syntax:

{{NobleHouse|HouseName}}

Examples

• Charles VI, Holy Roman Emperor, a member of the house of Habsburg
• Robert II of France, a member of the House of Capet.

Family Outside Marriage

Upper class males historically have often maintained family relationships outside of one with a formally married wife. WeRelate observes the practice of creating a family page to indicate such a relationship (particularly if it results in children) regardless. There is, however, no standard way to indicate that the relationship is not simply a marriage where the date of ceremonies is unknown. Worse - the woman is sometimes given a title of concubine or mistress. While strictly correct, in common use such terms carry inadvertent (and probably unfair) value judgements.

Instead of using the terms "mistress" or "concubine" for the woman, a more objective and accurate approach is to create a standard fact template to apply to the Family page. The template, CohabitationWithoutFormalities, is applied to a non-marital relationship by being placed in the description field for the Family "Marriage" event. The woman in such relationships is not indicated as a mistress or concubine, but simply in the ordinary way by name. If the woman's name is unknown, then she is simply an unknown person.

Examples

• Pepin of Herstal and Alpaide, James IV of Scotland and Janet Kennedy - Both parties are known and named, the relationship is simply indicated as not involving a formal marriage.
• Robert II of Scotland and Unknown, Stephen II, Count of Blois and Unknown - Instead of creating a useless page carrying a name such as "Unknown Mistress", the person (of whom nothing is known) is simply omitted.

Assertion of pages Not To Be Confused

When there are individual people or families that are confused in the literature or elsewhere, this concretely establishes the people or families confused. The target page should contain the same assertion, pointing back.

Used on PERSON or FAMILY pages

• NotToBeConfusedWith - when used on a person page, indicates person not to be confused with this person page. When used on a family page, indicates family not to be confused with this family page.

This could be used instead of, or in addition to, the current WeRelate practice of adding a do not merge template to the talk page.

Examples

• Family:Anders Andersson and Anna Larsdotter (2) and Family:Anders Andersson and Anna Larsdotter (4) shows symmetric use of the "Not To Be Confused With" assertion.

Assertion of Wikidata Item

The Wikidata project was created to establish a common set of unique object identities, relationships, and other properties within the scope of the various projects supported by the Wikimedia Foundation.

For example, Wikidata is used, by the various language versions of Wikipedia, to associate pages for a common item.

The Wikidata fact assertion template has been created to provide an active and easily identifiable association between a Person page and a corresponding Wikidata item identifier.

• Create a Reference Number fact, leaving the date field empty.
• Place a reference to the Wikidata template in the description field:

{{Wikidata|Q712580}}

Examples

• Person:Geoffrey I of Anjou, a medieval French nobleman from the medieval house of Ingelger
• Henry Fonda, 20th century American actor.

Assertion of Ancestral File Number (AFN)

The Ancestral File project was created by the Church of Jesus Christ of Latter-day Saints as a collated collection of genealogies submitted as GEDCOM files. Submissions were accepted in the period from 1979 until January of 2003. Individuals in the collection are labelled with an Ancestral File Number (AFN) which has subsequently become a common fact item in GEDCOM files. Ancestral file information for the pre-1500 period was handled with particular care, so is believed to be relatively more trustworthy.

Even though the Ancetral File project has been succeeded by the Pedigree Resource File (PRF), AFN numbers have become common in many of the GEDCOM files exchanged around the internet.

The AFN fact assertion template was created to take advantage of the fact that the last edition of the Ancestral File remains available for on-line query. Person page AFN facts can therefore appear as useful active links. Such facts are created thus:

• Create an Ancestral File Number fact, leaving the date field empty.
• Place a reference to the AFN template in the description field:

{{AFN|4LBC-XQ}}

Examples

• Person:William Bradford (9) - Early immigrant to New England via the Mayflower.

Assertion of FamilySearch ID Number (FSID)

FamilySearch, historically known as the Genealogical Society of Utah, founded in 1894, is a nonprofit family history organization dedicated to connecting families across generations. As the primary benefactor for FamilySearch services, the Church of Jesus Christ of Latter-day Saints (LDS) has made FamilySearch the largest genealogy organization in the world and is "dedicated to preserving the records of the family of mankind."

The FamilySearch Family Tree project was created in phases by the LDS between 2007 and 2013 by combining their collections of genealogies originally submitted to the LDS as GEDCOM files, which formed the basis of the Personal Ancestral File (PAF) and Pedigree Resource Files (PRF), and other vast collections of microfilmed and digitized records containing facts and events on individuals worldwide obtained by the church in support of their genealogical mission from about 1963 to 2003 (formerly known as the International Genealogical Index), including a recent integration with BYU Family History Archive. Like WeRelate, the Family Tree section allows users to collaborate on a single, shared, worldwide family tree (the difference, however, is that the FamilySearch Family Tree claims a population of about a billion names in it).

A new unique FamilySearch ID number (formerly called the person identifier) was created for every person in the system. (There is no correlation between the FamilySearch ID number assigned to a person and possible "membership" in the LDS Church.) The number appears next to or beneath the name on individual person pages in FamilySearch. A method for inputting sources and substantiating information for vital statistics, not present in its forerunner programs, was fully integrated and supported within the new FamilySearch application. Information contained within these family trees may uncover not only very useful genealogical data but may also identify supporting sources not on your subject WeRelate person page.

Here at WeRelate the FSID fact assertion template was created to take advantage of the fact that the FamilySearch Family Tree is available for on-line query. Person page FSID numbers can appear as an individual fact link to the FamilySearch page. It can also be annotated as a useful active link within WeRelate person page for referencing and linking the FamilySearch Family Tree data as a source citation to the individual's WeRelate page. Conversely, a link to WeRelate can be added to the FamilySearch page as well. Step by step methods for creating and/or annotating these fact references and source citations on a WeRelate Person Page are shown in detail in first and second instructional references below, and the reverse source citation (from FamilySearch to WeRelate) is shown in the third.

Using the FSID as a Reference Number

1. Create a Reference Number fact, leave the date field empty, and add the FamilySearch Family Tree ID Number for the individual as shown below.
2. Place a reference to the FSID template in the description field:

• {{FSID|ABCD-XYZ}}

- To clarify the host of the Reference Number (or to differentiate it from a Wikidata number or old Ancestral File number), you may want to add "(FamilySearch ID Number)" or "(FSID)" behind the entry. (This identification is not necessary if you also provide a "Source Citation" for the same FSID, as that will be identified by the "S#" link.)

- If you add the source citation below, then be sure to add the appropriate "S#" in the Source field

Using the FSID as a Source Citation

If the FamilySearch Family Tree page adds new data or provides additional information for the subject WeRelate page, then you can also reference the FamilySearch Family Tree ID Number in the source citation block as follows:

1. Source: Select "Source"
2. Title: Add (or find and select) "FamilySearch Family Tree"
3. Record Name: {{FSID|ABCD-XYZ|Firstname Surname}} (example)
4. Volume/Pages: Copy and paste the link for connecting family tree page within FamilySearch for that individual
5. Date: Annotate the date you retrieved or accessed the information
6. Text/Transcription: Annotate the information transcribed from FamilySearch page that supports the fact events used in that person's WeRelate page

Adding the Subject WeRelate Page as a FamilySearch Family Tree Source

You can take advantage of the potential larger audience that FamilySearch boasts by adding the subject WeRelate page as a source to the FamilySearch Family Tree page. This is especially appropriate and useful if the WeRelate page has better data or contains a larger number of fact events and source references than the FamilySearch page.

1. Scroll down the FS page to the Source block.
2. Add the WeRelate page for the individual as follows.

• Select Sources on the top tab, or scorll down to section
• Select Add Source and add the following descriptive entries:

• Source Title: Type subject person's name within WeRelate (Joe Smith in WeRelate)
• Web Page: Enter the WeRelate web page URL
• Where the Record Is Found (Citation): WeRelate.org
• Describe the Record (Notes): Transcribe extract of pertinent data from WeRelate person page
• Reason to Attach Source: Enter pertinent supporting reasons
• Select the Information or Events in this Source: Select events source substantiates

• Select Save and this source now directs visitors to the subject WeRelate person page
• You may want to fill in the "Watch" star on the FamilySearch Family Tree page to keep abreast of future changes in that page.

Examples

• Person:Irmgard Schoennauer (1) - In this case, both Wikidata and FamilySearch Family Tree reference numbers were used, side by side.
• Person:August Schmidtke (1) - FSID template used both as a Reference Number fact and as a Source Citation for new fact event data added.

Use on Person and Family Pages

The current set of assertions is only appropriate for use on Person and Family pages. Further, they are intended to be entered as ordinary facts, of type "other", with nothing in the date or place fields.

For More Information

For information on the development and possible future directions of fact assertions, see this specification.