Menu
- Home
- Search▼
- List▼
- Add▼
- My Relate▼
- Admin▼
ViewsWatchersPlease Donate |
Fact Assertion Templates - for Display and Software Use [edit] StatusThis suggestion is considered to be complete and is being archived. Some parts have been implemented and some have been rejected, while a few items may be implemented as part of other future work.--DataAnalyst 14:48, 7 November 2024 (UTC) [edit] Implementation[edit] What has been implementedMuch of this suggestion has been formalized as current practice and documented in the refresh of Help currently underway (see Help:Conventions/Family relationships, Help:Conventions/Cross referencing other sites, Help:Templates (for mention of military templates), and Help:HowTo/Discover duplicates (for mention of template NotToBeConfusedWith - although that might move elsewhere). Template:MultBirth has been created to replace the previous TwinBirth template (which still works because it has been redirected to the new template). The new template handles up to quintuplets (and could be expanded if there was interest in the future). [edit] What is not being implementedOther than the MultBirth template, none of the suggestions under Future Directions has been implemented or is anticipated to be implemented as part of this suggestion. No additional automation has been added or is expected to be added as part of this suggestion.
New "trial" templates to support facts found in LDS-sanctioned GEDCOMs have been removed after consultation with the WeRelate Advisory Council. They were not widely used and some were ill-defined (overlapping use). While identifying the uncertainty of a relationship is a good idea, the suggested use of templates might not be the best implementation. If someone wants to pursue this, a new suggestion should be created. Support for same-sex relationships is on the radar and will likely happen at some time in the future. (It will require a lot of coding work.) "Count of things" facts tend to encourage a lot of redundancy and are discouraged unless the names of spouses/children are unknown. [edit] IntroductionThe 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. [edit] Help Page Content for Family Connection AssertionsThese 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. [edit] Refuted Family ConnectionA "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 " 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.
[edit] Examples
[edit] Speculative Family ConnectionA "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 " 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.
[edit] Examples
[edit] No Accepted ConnectionA "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. [edit] Examples
[edit] Help Page Content for Not To Be Confused WithWhen 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.
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. [edit] Examples
[edit] Help Page Content for AdoptionOrdinary 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.
[edit] Examples
[edit] Help Page Content House of NobilityGenealogy 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:
[edit] Examples
[edit] Help Page Content CombatantInformation 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:
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. [edit] Examples
[edit] Help Page Content FormationInformation 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:
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. [edit] Examples
[edit] Help Page for Family Outside MarriageUpper 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. [edit] Examples
[edit] Help Page for Wikidata Item ReferenceThe 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.
[edit] Examples
[edit] Use on Person and Family PagesAdded 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. [edit] Future DirectionsIn 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:
[edit] Special Output SupportFamily 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. [edit] Special Input SupportFamily 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. [edit] GEDCOMSince 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:
[edit] Added Fact Types[edit] Multiple BirthAllow designation of the children who were part of a multiple birth.
[edit] FACTS Found in LDS GEDCOMSSeveral 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}} [edit] UncertaintyFamily 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. [edit] Non-traditional Family Relationships
[edit] Counts of thingsAssertions about the count of something. Each takes either a single integer (which may be 0) or an integer range "<n>..<m>" parameter.
[edit] Concluding RemarksAssertions 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
