Relation

The relation claim type describes how a Unit relates to another Unit. This can be used to model a hierarchical “tree” where one Unit is subordinate to another, or it can also be used to model joint-task force or other multi-unit grouping where the grouping is comprised of members from multiple different units.

Relation: Summary of claim attributes

The table below summarizes the following dimensions of relation claims:

Attribute label: a human readable label for the attribute

Status: whether the attribute is optional or required in a claim

Data type: the sort of data that can be entered into the attribute

Key name: a standardized name that simplifies attribute use in SFM databases

Attribute label	Status	Data type	Key name
type:claim	required	string	`:claim/type`
status:meta	required	string	`:claim/statuses`
researcher:meta	required	string	`:meta/researchers`
internal_comments:meta	optional	string	`:meta/internal-comments`
citation:refs:claim	required	strings<->uuids	`:claim/citation:refs`
about_entity:ref:claim	required	string<->uuid	`:claim/about-entity:ref`
about_entity:name:qa	optional	string	`:claim/about-entity:ref`
relation:unit:refs:assertion	required	uuid-string	`:assertion/relation:unit:refs`
relation:unit:names:qa	optional	string	`:assertion/relation:unit:refs`
relation:types:assertion	required	string	`:assertion/relation:types`
relation:related_unit:refs:assertion	required	string<->uuid	`:assertion/relation:related-unit:refs`
relation:related_unit:names:qa	optional	string	`:assertion/relation:related-unit:refs`
relation:related_unit_classes:assertion	optional	string	`:assertion/relation:related-unit-classes`
first_precise:range	optional	string-date	`:range-precise/first`
last_precise:range	optional	string-date	`:range-precise/last`
first_imprecise:range	optional	string-date	`:range-imprecise/first`
last_imprecise:range	optional	string-date	`:range-imprecise/last`
starting:range	required	YN<->bool	`:range/starting?`
ending:range	required	YN<->bool	`:range/ending?`
starting_context:range	optional	string	`:range/starting-context`
ending_context:range	optional	string	`:range/ending-context`
public_notes:meta	optional	string	`:meta/public-notes`
type:entity	required	string	`:entity/type`

Relation: Details of claim attributes

This section contains further information about each attribute, including descriptions, examples of use, and guidance on use.

type:claim

Description

A field that defines what type of claim is being made.

Attribute type

Text string

Status

This attribute is required.

Key name

:claim/type

Example of use

unit, positioning, relation, person, posting, incident

Guidance on use

Entering relation defines the claim and defines the relevant fields to be used in further data entry about a relation. For quality assurance purposes, entering relation should create an error if there is any entry for fields tied to other claim types, such as Unit or Positioning.

status:meta

Description

A field that classifies the data in the claim.

Attribute type

Text string

Status

This attribute is required.

Key name

:claim/statuses

Example of use

accepted, conflict, work_needed, issue

Guidance on use

Claims are marked accepted when all of the data can be entered in accordance with the guidance of this handbook. The conflict flag is used whenever a claim conflicts with another claim (or claims) and a review of citations show it to be the incorrect or false claim. A public_notes:meta should always accompany any conflict claim.

Example

Citations reference a unit 757 Light Infantry Battalion in 2008 and again in 2019 as part of the Myanmar Army. This conflicts with other citations before and after these dates which list all light infantry battalions of the army and do not include this unit. Further citations establish a general numbering practices of the army which provides further evidence that no such battalion exists. The unit and other claims related to the 757 Light Infantry Battalion should still be entered into the dataset, flagged with status:meta of the conflict, and have the status fully explained in a public_notes:meta.

If the data itself cannot be brought into the SFM standard the flag issue should be used. Finally, if the current citations cannot establish whether a claim should be flagged as accepted or conflict then the flag work_needed should be used as additional research is needed.

researcher:meta

Description

Field for initials or other identifier of researcher who last entered data for the claim.

Attribute type

Text string

Status

This attribute is required.

Key name

:meta/researchers

Example of use

TW, Jane_Doe, G1

Guidance on use

Every researcher should use this field to mark the claims that they have entered. Anytime a researcher modifies any data for an existing claim they should update this field so that any questions can be directed to the right person and the flow of work can be better tracked.

internal_comments:meta

Description

A field for temporary comments or notes for the researcher or research team working on the claim.

Attribute type

Text string

Status

This attribute is optional.

Key name

:meta/internal-comments

Example of use

Come back to this to determine date for claim

Guidance on use

Researchers may use this field to make temporary notes or leave temporary comments intended for others in the research team about a claim. These should eventually be addressed and the field cleared by the researcher or research team. If the claim needs an explanatory note or comment to be better understood, then that should be entered in the public_notes:meta field.

citation:refs:claim

Description

Field unique 32 character code assigned to citation(s) evidencing the claim.

Attribute type

String in UUID format.

Status

This attribute is required.

Key name

:claim/citation:refs

Example of use

69dba35b-2b70-47cf-bfda-f80225f652c6, 4e99308c-f9c0-49e8-b97b-14c1e7bcb99d;bedf57b2-c20b-41e3-9dcf-b7b065eaa3b7

Guidance on use

Every claim must have at least one citation to evidence the data in the claim. When two or more citations are needed to evidence a claim then a corresponding explanatory note should be entered in the public_notes:meta field. This field is for the Universally Unique Identifier (UUID) for each citation, found in the ref:source:access_point_id:admin field in the Sources sheet. When multiple citations are needed every UUID should be semi-colon separated.

about_entity:ref:claim

Description

A unique 32 character code assigned to each entity in the dataset.

Attribute type

String in UUID format.

Status

This attribute is required.

Key name

:claim/about-entity:ref

Example of use

0ab0e3c3-4bd6-4607-8cc5-1cfce9502c57

Guidance on use

Every claim has a Universally Unique Identifier (UUID) to distinguish it from any other claim. For a relation this UUID distinguishes them from any other relation in the dataset.

Every relation between the same two units is always treated as a contiguous, meaning it has the same UUID, unless citations establish it should be treated as non-contiguous.

Example

The 33 Light Infantry Division has multiple citations establishing that it is a mobile unit which can change relation to whatever regional military command controls the area where it is operating. One citation puts the division in an area under Northeastern Regional Military Command as of 2016-11-13 which establishes a relation between the division and the regional command for the same time-range. Another citation places the division in an area under Northeastern Regional Military Command on 2016-12-05. Even though the related units are the same, because citations establish the division is a mobile unit that can change relation these two claims are coded as separate, non-contiguous relations.

Two or more relation claims should always be treated as contiguous if there is an overlap in the time range of the two claims, or if the time-ranges of the claims fall within 1 day of each other.

Example

The 33 Light Infantry Division has multiple citations establishing that it is a mobile unit which can change relation to whatever regional military command controls the area where it is operating. One citation puts the division in an area under Northeastern Regional Military Command from at least 2016-03-10 to at least 2016-03-11, which establishes a relation between the division and the regional command for the same time-range. Another citation places the division in an area under Northeastern Regional Military Command on 2016-03-12, which again establishes a relation between the division and the regional command for the same time-range. These two claims are coded as the same relation given that they fall within 1 day of each other.

A Unit may have multiple, overlapping relations.

Example

Citations establish that regional military commands in the Myanmar Army control units that operate in their area of operations. Citations establish through time that the 290 Infantry Battalion is under command of the Northeastern Regional Military Command and also based in areas under Northeastern Regional Military Command through time. Combined these citations evidence a contiguous relation between the battalion and ultimately the Northeastern Regional Military Command. Other citations, however, evidence the battalion also operated in areas controlled by different regional military commands. These establish additional relations for the battalion during the time ranges it was operating in areas under the Eastern Central Regional Military Command, Northern Regional Military Command, Southeastern Regional Military Command or Triangle Regional Military Command.

about_entity:name:qa

Description

Field that provides human readable name for entity.

Attribute type

Text string.

Status

This attribute is optional.

Key name

:claim/about-entity:ref

Example of use

21 Military Operations Command Northern Regional Military Command, Unknown Tactical Operations Command (77 Light Infantry Division) 77 Light Infantry Division

Guidance on use

This field provides a human readable counterpart to the about_entity:ref:claim which combines the various elements of the claim into a single text field. This field can be manually added by a researcher or automatically populated by the system after import.

relation:unit:refs:assertion

Description

The unique 32 character code assigned to the unit with the relation which is the focus of the claim.

Attribute type

String in UUID format.

Status

This attribute is required.

Key name

:assertion/relation:unit:refs

Example of use

a407be6a-28e6-4237-b4e9-307f27b1202e

Guidance on use

The UUID used in relation:unit:refs:assertion must be for a Unit which already exists in the dataset. The nature of the relationship is clarified further using the relation:types:assertion and relation:related_unit_classes:assertion fields.

relation:unit:names:qa

Description

The human readable name of the unit that is a child or member of another unit.

Attribute type

Text string.

Status

This attribute is optional.

Key name

:assertion/relation:unit:refs

Example of use

Groupement de Forces pour la Sécurisation du Nord, Moriones Tondo Police Station 2

Guidance on use

This field provides a human readable counterpart to the relation:unit:refs:assertion. This field can be manually added by a researcher or automatically populated by the system after import. Best practice for this field is to use the name:annotation of the Unit.

relation:types:assertion

Description

The type of relationship that exists between two units.

Attribute type

String from controlled list.

Status

This attribute is required.

Key name

:assertion/relation:types

Example of use

child-of, member-of

Guidance on use

We use this field to define the nature of the relationship between the Unit that is the subject of the claim (as described in relation:unit:refs:assertion) and the other Unit described in relation:related_unit:refs:assertion. There are only two values that can be used by the researcher in this attribute:

child-of to define a hierarchic relationship. The unit specified in relation:unit:refs:assertion is the parent of the unit in relation:related_unit:refs:assertion.

member-of to define a membership relationship. The unit specified in relation:unit:refs:assertion has some personnel who are members of the unit noted in relation:related_unit:refs:assertion.

A member-of Relation is used to capture instances where personnel of one unit become personnel of another unit, such as a joint task force or peacekeeping mission, that has a distinct chain of command and geographic footprint. This is important to capture in the data model as the personnel in joint task force or peacekeeping mission are no longer under the command of their “home” unit or at the minimum have an altered relation with their “home” chain of command.

Example

Many units of the Mexican Army sent personnel to serve as part of Operación Conjunta Chihuahua, a joint task force which conducted operations in and around Ciudad Juárez in northern Mexico. While these personnel were serving as part of the operation they were part of the chain of command for that operation, and not their “home” unit which may have been across the country. Similarly, personnel of the “home” unit were not in a hierarchical relation, or under the command of, Operación Conjunta Chihuahua.