Posting

The posting claim type holds information about a person’s career. It first defines a relationships between a person and a unit, and can be used to further describe the role the person has in the unit (“Commander”, “Chief of Staff”, etc.), the rank they hold at the time of the posting, and any title they may hold at the time of a posting. Usually, a person has a single posting at any one time. However, there are cases where one person holds multiple postings simultaneously. In rare instances a person may hold one posting which commands a posting they also hold, effectively making them their own superior.

Posting: Summary of claim attributes

The table below summarizes the following dimensions of Posting 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`
posting:person:refs:assertion	required	string<->uuid	`:assertion/posting:person:refs`
posting:person:names:qa	optional	string	`:assertion/posting:person:refs`
posting:unit:refs:assertion	required	string<->uuid	`:assertion/posting:unit:refs`
posting:unit:names:qa	optional	string	`:assertion/posting:unit:refs`
posting:roles:assertion	optional	string	`:assertion/posting:roles`
posting:titles:assertion	optional	string	`:assertion/posting:titles`
posting:ranks:assertion	optional	string	`:assertion/posting:ranks`
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`

Posting: 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 posting defines the claim and defines the relevant fields to be used in further data entry about a posting. For quality assurance purposes, entering posting should create an error if there is any entry for fields tied to other claim types, such as person.

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.

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

a3cb9b5e-316d-4af7-ac2b-87399df067e2

Guidance on use

Every claim has a Universally Unique Identifier (UUID) to distinguish it from any other claim. For a posting this UUID distinguishes them from any other posting in the dataset. This allows a person to have contiguous or non-contiguous posting with the same unit.

For each person their posting is always treated as contiguous, meaning it has the same UUID, unless citations establish it is non-contiguous. For example, citations establish that on 2010-08-27 Hla Min stopped being commander of the Southern Regional Military Command and became commander of the 3 Bureau of Special Operations. One citation also evidences his being commander of the 3 Bureau of Special Operations on 2011-07-05 and another citation states he retired as commander of the 3 Bureau of Special Operations on 2015-08-10. All three of these claims are treated as evidencing the same posting. In contrast, the 2011-07-05 citation also establishes that Hla Min once again became commander of the Southern Regional Military Command on a temporary basis as its commander was removed from the posting. This posting as commander of the Southern Regional Military Command is treated as a separate posting with a different UUID as the previous posting held on 2010-08-27.

Determining whether one person held multiple postings is based on some match of postings among different citations. For example, if one citation stated “John Alfred Smith” was commander of “Police Station 1” and another citation stated “J. Smith” was commander of “Police Station 3” there would be no match and these should be coded as two separate people each with their own about_entity:ref:claim. If a third citation stated that during the career of “John Smith” he was commander of “Police Station 1”, “Police station 15” and “Police Station 3” then all of these would be treated as the same person given the match of at least one posting across all citations and the similar names of the person in each citation.

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

Ni Lin Aung Major General Triangle Regional Military Command

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.

posting:person:refs:assertion

Description

The unique 32 character code assigned to a person posted to a unit.

Attribute type

String in UUID format, selected from existing person records

Status

This attribute is required.

Key name

:assertion/posting:person:refs

Example of use

a848de4e-ebeb-49d6-9099-7e68ca3b57fc

Guidance on use

This is the Universally Unique Identifier (UUID) of the person who is being posted to a unit. A record for the person must already exist in the dataset.

posting:person:names:qa

Description

Name of person posted to a unit.

Attribute type

Text string

Status

This attribute is optional

Key name

:assertion/posting:person:refs

Example of use

Hla Min

Guidance on use

This is a human readable name for the person with the posting to the unit. The field can be manually entered or automatically populated by the system. Best practice for this field is to use the name:annotation for the person.

posting:unit:refs:assertion

Description

The unique 32 character code assigned to a unit to which the person is posted.

Attribute type

String in UUID format, selected from existing unit records

Status

This attribute is required.

Key name

:assertion/posting:unit:refs

Example of use

a848de4e-ebeb-49d6-9099-7e68ca3b57fc

Guidance on use

This is the Universally Unique Identifier (UUID) of the unit to which the person is posted. A record for the unit must already exist in the dataset.

posting:unit:names:qa

Description

Name of unit which has the posted person.

Attribute type

Text string

Status

This attribute is optional.

Key name

:assertion/posting:unit:refs

Example of use

Moriones Tondo Police Station 2, Northeastern Regional Military Command

Guidance on use

This is a human readable name for the unit where the person has a posting. The field can be manually entered or automatically populated by the system. Best practice for this field is to use the name:annotation for the unit.

posting:roles:assertion

Description

The role a person plays in the unit.

Attribute type

Text string.

Status

This attribute is optional.

Key name

:assertion/posting:roles

Example of use

Commander, Chief of Staff, Second in Command

Guidance on use

The most common value we record in this attribute is Commander.

There are a variety of other roles a person can have including Second in Command, Chief of Staff along with other less common entries. They will vary between countries.

In nearly all cases, the value entered in this field is taken verbatim from the source. Commander is coded as the person who is ultimately in charge of the unit. If a person is referred to as “the head”, “chief” or some other variation indicating that they are in charge of a unit, they should be regarded as the Commander for the purposes of entering a value in this attribute. Similarly, the head of government or head of state of a country should have their role recorded as Commander for their posting.

Example

The Président de la transition of Burkina Faso is the head of state, along with the commander-in-chief of the security forces. In our data any person who has been the Président de la transition would have a posting to that unit with a posting:roles:assertion of Commander and a posting:titles:assertion of Président de la transition.

Similarly, heads of academic or other security force institutions will sometimes be referred to as the Commandant. In these cases, Commandant should be recorded in the posting:titles:assertion attribute, and their posting:roles:assertion should be recorded here as Commander.

posting:titles:assertion

Description

A title held by a person that is separate from their rank.

Attribute type

Text string.

Status

This attribute is optional.

Key name

:assertion/posting:titles

Example of use

General Officer Commanding, Jefe Del Estado Mayor, Vice Chairman

Guidance on use

The range of titles will vary from country to country. For example, commanders of army divisions in Nigeria, who usually hold the rank of Major General also hold the title of General Officer Commanding. The value placed in this attribute is taken verbatim from the source and not edited or standardized.

posting:ranks:assertion

Description

The official rank of a person.

Attribute type

Text string.

Status

This attribute is optional.

Key name

:assertion/posting:ranks

Example of use

General de División, Teniente Coronel, Air Vice Marshal, Lieutenant Colonel

Guidance on use

Ranks for security forces are usually established in law or policy or listed on websites of security forces themselves. Best practice is to find this citation first and then use this contextual citation for any other citation referencing a rank with an abbreviation, such as “Lt. Col.” for Lieutenant Colonel. In some countries ranks are refenced with a dash “-” rather than a space between words. Generally, SFM aims to avoid entering dashes or other additional punctuation into data and thus would enter Brigadier General rather than Brigadier-General.