WeRelate:Suggestions/Assertions

Fact Assertion Templates - for Display and Software Use

Contents

Introduction

The ordinary WeRelate data entry fields do not provide a standard or software-recognizable way to encode some types of objective facts and state information. Some of those items have the potential to be extremely useful (both for software and users). The fact assertion templates provide a way to augment the basic family-connection semantics of WeRelate with a few of those items. Template families for speculative, refuted, and no accepted connection have been created, which follow a common theme. A further single template provides the ability to designate that one person or family is not to be confused with another.

Help Page Content for 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).

Name Parameter
string
For use on
page type(s)
Pairs with
Parent-Child Relationships
XxxParents "husband and wife" PERSON XxxChild
XxxMother "person" PERSON XxxChild
XxxFather "person" PERSON XxxChild
XxxChild "person" FAMILY or PERSON XxxParents or XxxMother or XxxFather
Spouse-Family Relationships
XxxWife "person" FAMILY or PERSON XxxHusband or XxxFamily
XxxHusband "person" FAMILY or PERSON XxxWife or XxxFamily
XxxFamily "husband and wife" PERSON XxxWife or XxxHusband

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:

image:Refuted_child_example.png

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.

Asssertion
Name
Parameter
string
For use on
page type(s)
Pairs with
Parent-Child Relationships
RefutedParents "husband and wife" PERSON RefutedChild
RefutedMother "person" PERSON RefutedChild
RefutedFather "person" PERSON RefutedChild
RefutedChild "person" FAMILY or PERSON RefutedParents or RefutedMother or RefutedFather
Spouse-Family Relationships
RefutedWife "person" FAMILY or PERSON RefutedHusband or RefutedFamily
RefutedHusband "person" FAMILY or PERSON RefutedWife or RefutedFamily
RefutedFamily "husband and wife" PERSON RefutedWife or RefutedHusband

Examples

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:

image:Speculative_child_example.png

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.

Asssertion
Name
Parameter
string
For use on
page type(s)
Pairs with
Parent-Child Relationships
SpeculativeParents "husband and wife" PERSON SpeculativeChild
SpeculativeMother "person" PERSON SpeculativeChild
SpeculativeFather "person" PERSON SpeculativeChild
SpeculativeChild "person" FAMILY or PERSON SpeculativeParents or SpeculativeMother or SpeculativeFather
Spouse-Family Relationships
SpeculativeWife "person" FAMILY or PERSON SpeculativeHusband or SpeculativeFamily
SpeculativeHusband "person" FAMILY or PERSON SpeculativeWife or SpeculativeFamily
SpeculativeFamily "husband and wife" PERSON SpeculativeWife or SpeculativeHusband

Examples

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

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

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

Help Page Content for Not To Be Confused With

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

Help Page Content for 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

Help Page Content 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

Help Page Content Combatant

Information on participation in wars and combat is important in family history.

The Combatant fact assertion template has been created to address both the problem of visually establishing the person as a participant in a historical conflict or battle, but also to flag them for inclusion in an appropriate corresponding category. To use it:

  • Create a fact of type of "Military", adding to the description field the syntax:
{{Combatant|BattleName}}

Where the "BattleName" portion should omit "Battle of". Also, if the person in question perished as a result of the particular combat, then use the Combatant template in the description field for the Death fact.

The categories for the battles are further organized by War or Campaign and War, if such is common in the literature. For example, the categories for The Battle of Barnet and The Battle of Bosworth Field are both found as subcategories in The Wars of the Roses.

Examples

Help Page Content Formation

Information on affiliation with particular military units is important in family history.

The Formation fact assertion template has been created to address both the problem of visually establishing the person as a member of a historically recognized military unit, but also to flag them for inclusion in an appropriate corresponding category. To use it:

  • Create a fact of type of "Military", adding to the description field the syntax:
{{Formation|UnitName}}

Where the "UnitName" is the name of the category established for members of that military unit.

The categories for units may be further organized into higher order categories depending upon the time period and military organization.

Examples

  • Col. Robert Gould Shaw, member of both the 2nd and 54th Massachusetts Infantry Regiments in the American Civil War.

Help Page for 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

Help Page for Wikidata Item Reference

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

Use on Person and Family Pages

Added semantic templates could, in principle, appear anywhere on a page. They are however, intended to extend the set of easily recognizable facts relating to a person or family, so they seem to make the most sense as items to be added to the ordinary list of facts. In that way, they can be readily and clearly associated with supporting notes and references.

So fact assertions, of all types, are intended to be entered and appear as "Other" type facts on Person and Family pages, as appropriate.

Future Directions

In the interest of starting with a small and simple set of assertions types, and not requiring any software changes, the initial set of assertions is limited and only meant to be used as ordinary fact items. There are several possible directions for future expansion. In brief:

  • Special output formatting
  • Special input support
  • Added fact types

Special Output Support

Family and Person page output could change the sort order of facts, such that assertions appear after other time and place oriented facts - and without those fields - since they are not used by the assertions.

Special Input Support

Family and Person input pages could offer active support for creation of the different types of fact assertions. For example, special support for the creation of assertion facts - instead of forcing them to be handled through ordinary facts. Such support might include a drop-down list of the different types (and only of those appropriate to person or family pages respectively). Since the facts do not use date or place fields, they could be omitted from the input screen.

GEDCOM

Since the assertions augment GEDCOM semantics, by definition, there's no way to recognize unrepresented information when importing a GEDCOM.

When exporting a GEDCOM, however, there are choices. It would be hard to say what would be most useful for an arbitrary GEDCOM consumer, but perhaps the GEDCOM output could be tuned such that a user could make requests regarding how it is done. In any case, the alternatives for dealing with assertion fact information include at least the following:

  • Do nothing. The template will appear as an "Other" type fact with the same syntax as the user (or system) placed in the fact description field. That may, on its own, be useful. So a description field for an "Other" fact might simply appear as:
{{SpeculativeParents|Samuel Sabin and Elizabeth Unknown (1)}}
  • Translate the templates into standard bits of more readable text in the fact description. For example, the template string above becomes:
"Speculative parents: Samuel Sabin and Elizabeth Unknown (1)".
  • Translate the templates into readable text, but also reference family and person ids of the GEDCOM. So:
"Speculative parents: @F123@ (Samuel Sabin and Elizabeth Unknown)".

Added Fact Types

Multiple Birth

Allow designation of the children who were part of a multiple birth.

Used on PERSON pages
  • Twin - designates the other member of a twin birth born with this person
  • BirthMate - designates other members of a multiple birth with this person
Used on FAMILY pages
  • Multiple - designates two or more children of that page, that are party to a particular multiple birth

FACTS Found in LDS GEDCOMS

Several LDS-sanctioned GEDCOMs have been uploaded over time, and have been found to include additional fact types in the page field of the various resulting person pages. Where these directly correspond to existing WeRelate fact tags, those should be used. When another tag is available but sufficiently appropriate, that is to be preferred. For other types, we can provide templates that mark these (in the event that handling of such tags is added or modified in the future).

Tags that directly correspond: BIRTH, BURIAL, DEATH/ALT DEATH, LIVING, MARRIAGE, MILITARY, PROBATE, PROPERTY, RESIDENCE, STATE OF HEALTH (Medical), TITLES (Title (Nobility)).

Tags that potentially correspond: CHURCH (Religion), OFFICE (Occupation)

Failing in the above, templates can designate the other fact types found:

 ASSIGNMENTS - {{Assignments|description}}
 CHURCH - ?Religion - {{Church|description}}
 CONDITION - {{Condition|description}}
 DISTINCTION - 
 FINANCES - {{Finances|description}}
 HONORS - {{Honors|description}}
 IDENTITY - {{Identity|description}}
 INHERITANCE - {{Inheritance|description}}
 INVESTIGATE - {{Investigate|description}}}}
 INQUISITION POST MORTEM - {{InquisitionPostMortem|description}}
 KINSHIP - {{Kinship|description}}
 MONUMENTAL INSCRIPTION - {{MonumentalInscription|description}}
 OFFICE - ?Occupation - {{Office|description}}
 POLITICS - 
 PUNISHMENT - {{Punishment|description}}

Uncertainty

Family connections appear in the ordinary way when they meet a subjective standard of being generally accepted by the genealogical community. The actual certainty (again, by subjective estimation) can range from near absolute to merely probable. While there is not apt to be value in a quality rating for any given connection - it seems like it would be helpful to know when concerns exist.

Referring to family connections, this set of templates would have the established forms: UncertainParents, UncertainFamily, UncertainWife, UncertainHusband, UncertainChild, UncertainMother, UncertainFather.

These templates would appear only when a normal connection of the indicated type exists. They would still reproduce the connection information, since uncertainty about a person, who was a parent in more than one family, could not be attributed. There might however, be cases where the parameter is strictly redundant, so we should try to create templates that treat the parameter as optional.

Non-traditional Family Relationships

  • Spousal relationships beyond the simple heterosexual form of the current Family page - spousalRelationship - symmetric use in each of the parties to such a relationship.

Counts of things

Assertions about the count of something. Each takes either a single integer (which may be 0) or an integer range "<n>..<m>" parameter.

Used only on PERSON pages
  • CountRelationships - Number of separate marriages or relationships that resulted in children.
Used on either PERSON or FAMILY pages
  • CountChildren - Total number of children for a person or a family.
  • CountSons - Same as "CountChildren", but only for sons.
  • CountDaughters - Same as "CountChildren", but only for daughters

Concluding Remarks

Assertions are templates that are meant to allow specification of information that is not normally present in a GEDCOM. Implemented as templates, they are a type of property that adds both human and program-readable information, extending the genealogical semantics of WeRelate. We expect them to be added in the description field of an "Other" type fact, where the date and place portions of the fact should be left empty.