Suites - An overview
We call “Suites” sets of sources which either (a) describe repeatedly a same phenomenon at regular chronological intervals, such as yearbooks, population census, taxpayers rolls, accounts, etc.; or (b) provide unique pieces of information organized on a regular way for many items, such as the Spanish Nomenclator of 1788 which lists all populated places in 'Spain and adjacent islands', all of them assigned to the civil district they belonged to at that time.
. Suites provide a huge volume of highly significant information for the study of many fundamental and controversial historical issues, such as urban demography, social history of lower classes, the economic basis of public organizations, etc., the solution of which would probably change in depth our views of past societies. . Social scientists nevertheless never used their full potential because (a) their bulk or because (b) the fact that their content is sheer repetition from one year to another with few changes, make them practically unmanageable without a huge previous processing. . Moreover, suites are self-significant, which means that any item of the same is unintelligible outside the context of the whole set. They must consequently be embraced in their entirety for a correct interpretation; which makes them still more unwieldy. . The Suites subsystem, as described hereunder, purposes (a) to reduce information to non-redundant items; (b) to make explicit in the preserved entries the contextual information carried by the rest of the information set, so as to reduce the number of items to be handled.
Fichoz had long ago explored various strategies to achieve this aim. All of them nevertheless met with an insuperable bottleneck: the extreme slowness and time-consuming character of raw data loading from the sources to the database. This bottleneck was made more distressing still by the fact that our first explorations of the Suites object made clear that sources had to be exhaustively loaded and that selecting in the source a collection of unique unrepeated data before loading them to the database was a totally unrealistic view. The quality of Freizo OCR files and its capacity to split entries in accordance to pre-defined criteria resolved the problem and opened the way to a final elaboration of the processing strategy. Not the least so because Freizo team immediately provided various ready-for-loading full sources which made possible full-size experiments. Freizo also resolved a strategic problem, which did not affect the technical side of the business, but had a great impact on the social utility to be expected from our work. We quickly understood that to achieve our aim we needed specialized tools for which users had to pay, not only in the financial meaning of the world, but also in the form of a time-consuming training. No freeware current database package matches our needs, for instance. The only package really able to cope with the bulk and fuzzy character of our data is FileMaker. The cost of it can be assumed by a specialized team; not by casual users. This drastically reduced the number of potential users; and consequently also reduced the capacity of the program to attract collaborators. Indeed, the volume of sources belonging to the Suites class is so great, and the necessity of their previous processing so imperative, that forming a collectivity of active collaborators is of fundamental importance. Moreover, given the scale of our ambitions, it looks sensible to produce intermediary results which would preserve their value independently of the final results to be achieved. The basic idea consists in starting from raw data, such as sources provide them; to subject them to a refining process, divided in three stages, each of them producing and upgraded, more serviceable version of the same data. The last version being fully integrated into the Fichoz database system which we developed for the study of huge sets of historical actors.
Vocabulary remark: In the following text we call “Suite” a series of formally identical documents which describe a same universe at different moments; from a document to another content changes, but the formal structure remains fundamentally the same. For instance, the series of the Guias de Forasteros which from the second half of the XVIIIth century to the beginning of the XXth century give a yearly directory of the agents of the Spanish monarchy, arranged in accordance to the government branch they belong to. We call “Suite documentary item” each one of the items provided by the sources, which together make the suite. In the previous example, each one of the yearly directories.
I. Local suites The first step consists in loading each Freizo OCR suite item into a FileMaker file named Local suite. Local means that this is an independent file. It works without being linked to any other; so that as many independent copies as needed can be implemented in independent numeric devices, allowing a number of independent operators to work at the same time on various local suites. Freizo OCR data have been split inside Freizo into blocks which grossly match the main articulations if the data. In a directory of persons, for instance, one line for every individual entry, one block for the name, another for the first name, another for the residence, another for the occupation, another for the employer or/and the function. Freizo splits data on the basis either of typographic marks or of vocabulary lists. The variability and unpredictability of sources is such that a percentage of entries simply do not fit into the programmed splitting scheme; either because they could not be detected without an unacceptably time-consuming perusing of the source; either because programming Freizo for rare occurrences would be longer than manual correction. We know by experience that details change from one suite item to another, even from one year to another inside the same yearly suite. The splitting of each suite item must be programmed independently. The general sketch of the same must be provided by the operator in charge of the local suite processing, in close cooperation of course with the operator in charge of the Freizo OCR. Further versions of the present document will provide more detailed guidelines on this point. The first and main purpose of the Local suites process consists in upgrading the distribution of the information into consistent blocks, so as to allow reliable and ergonomic queries to be formulated to retrieve sets of consistent data. Operators must master the fundamentals of FileMaker editing to benefit from the huge potential of FileMaker on that point. General guidelines will be formulated in a further release of the present text. Operators must possess a good general knowledge of the context the data belong to. Many micro-decisions must in fact be made, which are quite unproblematic for him who knows, but would probably be erroneous from one who does not. We feel necessary to insist on that point, which many deciders tend to ignore: the smooth and regular appearance of suites document is highly misleading; they are in fact full of interpretative traps. Resolving them is also part of the editorial process local suites undergo. Various items of a same suite can profitably be loaded to a same Local suite file. Another important purpose, although a secondary one compared with the distribution upgrading, consists in adding to the data handles which would make easier and more secure consulting the same, specially for untrained users. The first and more important point to be stressed is that original data must not be changed. Some obvious abbreviations may and must be developed, some kind of structuring may and must be introduced to make queries easier, nothing more:
Example: Roberts Rev. Maurice Missionary ⇒ Roberts Maurice [Reverend] Missionary Specially, operators must resist the temptation to make formulation uniform. A medical practitioner may look the same as a doctor. Sorry, it is not. So, refrain. Harry Smith Johnson may be or may not be the same a H.S. Johnson. Please, refrain. If something we consider useful for final users must be added which does not appear in the source, either because we know it from another source (another suite item of the same suite, for instance) or because we deduce it from the current data, it must be placed between square brackets, in accordance to well-known conventions of scientific editing. Actors and places may also profitably be identified by means of independent identifiers, stored in independent fields. The Local suite files systematically provide such fields in which to load the relevant identifiers. Place identifiers must be drawn from Fichoz Geo_general geographic file, which can be accessed on-line at https:\\actoz.db.huma-num.fr. This identifier is a unique identifier which univocally defines the place. It will not further be changed. Identifying actors, be they persons, corporations or artefacts, is far more difficult and demands contextual elements that suite documents do not usually provide. For this reason, identifiers set in local files are provisional, and only valid inside the current local file. They mean that the identified actor is the same as others with the same identifier mentioned in the current file, and different for all those who do not have the same identifier in the current file. It does not mean that the current actor is the same or different from any other mentioned in any other file. This local identifier must be the record identifier of the record in which the actor is first mentioned in the current local file. It is good practice to set actors and place identifiers after various suites documentary items of the same suite have been loaded to the same local file. Not only does it help identification, but it also saves time. Local suites files allow the edition of ordered and partially enhanced specific volumes of suites data under Freizo.
II Formal suites
We call formal suites, files into which all the local suites file belonging to a same suite have been merged. Nothing changes in relation to the local suites file, except on two points. First, every actor must be now equipped with an identifier which makes him unique inside the suite, and not inside the local documentary item, or inside the set of local documentary items loaded into the same local suites file. This identifier will be the record identifier of the record which first mentions the actor in the formal suite file. Strategies will be further developed to make the change automatic. Second every record must be marked with a status marker indicating if the data it contains merely repeat an item previously mentioned by another entry of the same suite (e. g. the same actor repeating in 1902 and 1903 directories as French resident general in Tunisia); if it is the first occurrence of a new information; or the last instance of a repeated information, inside the same suite; or the last known instance of the same (without being sure that additional information would not change this qualification). Formal suites files in fact serve a tactical purpose. They aggregate local independent suite files, previously distributed among various operators for upgrading purposes and, by giving every actor a unique identifier inside the suite, they make possible appending the data belonging to the suite to the Fichoz Suite file. Formal suites files allow the edition either of coordinated volumes (each one being a suite item) of suites data, in which a same actor would be identified by a same identifier all over the various volumes; either a combined edition all the volumes (items) of the suite, in which each actor, for each function, would be mentioned only once, with an initial and a final date, using the status markers to achieve such a result.
III. Fichoz Suite file
The formal suites file univocally identifies each actor by a combination of the identifier of the suite and of the formal identifier of the actor. The data it contains can thus be aggregated to Fichoz Suites file without inconvenience. Once they physically belong to this file, formal suites data can be linked to all the data which Fichoz files provide about actors. For that, they must meet two conditions: 1) Every actor must be assigned a unique identifier, which must be the same as the identifier which identifies the actor all over Fichoz subsystem, without any further qualification. This step is necessary to create the physical connection between all data referred to the same actor. 2) The actor concerned by the Suites entry must be mentioned by at least one entry of the Fichoz Actions file. If this Fichoz entry existed previously to the creation of the Suites entry, the identifier which had been previously assigned to the actor in the same by Fichoz becomes the unique identifier of the Suites entry. If not, the Actions entry must be created, and the identifier assigned in the process becomes the unique identifier. This condition is unnecessary as far as physical connexions are concerned, but essential to make data manageable. This operation provides many interesting opportunities. Fichoz aggregates, on all known actors, all kind of data which suites documents do not use to provide. Any kind of information about the actor's lifecourse, any kind of social relational data (the people he uses to meet and work with, for instance) can be aggregated after extracting them of all kinds of document. Being able to access the actor's whole lifecourse, among other benefits, solves a problem of identification. One of the main back drawback of suites documents is that we cannot clearly identify individuals. Librarians tried to overcome the obstacle by elaborating authority control processes. They do not work well, not even for contemporary authors, about whom every kind of information are available, because they leave out data which do not belong to their limited field of interest. Making Suites and Fichoz work together would marshal Fichoz data in favour of the Suites. And, the other way around, would enrich Fichoz with the content of Suites. Routines will be later elaborated to transfer automatically Suites information to Fichoz and to query Suites using Fichoz as a backstage search engine.
Note for Peter: we are presently working on phase I. Slicing - Light and full version The slicing routine transforms Freizo OCR'ized directories entries into Fichoz entries.
. The light version breaks the directory entries into a number of strings, stores each string into a specific field of the [Fichoz]_Suites file, corrects reading errors left by Freizo and structures the content of the Name and Surname fields in a minimal way so as to make easier queries based on these identification items. The purpose is to make easier consulting directories in a traditional way, that is using the name as a main entry. The process is acceptably fast: one day, and not such a long one, for the 1919 directory (somewhat more than 10.000 entries), the Freizo OCR'zed text of which was reasonably good. The time needed is in fact hugely dependent on the quality of the Freizo delivery, and can probably be further reduced by improving this last factor. A light slicing of all the Foreigners in East Asia directories for a collective use of the same looks feasible. . The full version is based on the light version and, moreover, makes explicit an impressive volume of information which in the directories remain implicit, about employers, firms, occupations and institutions. It assigns a provisional identifier to every corporation and geographical identifiers to places. In such a way it allows queries based not only on names, but also on occupations, relations with firms, administrations and places, independently of each other, or on a mix of all of them. It paves the way for the setting of local identifiers to the mentioned actors, and later for the setting of social identifiers, which will make possible the inclusion of directories data into Fichoz lifecourses (see the text Suites_description, which I previously sent, on these points). It sets the necessary basis for the building global views of the universes described by the directory, that is for a full scientific use of the same. Elaborating a full version, in spite of FileMaker's query routines invaluable help, in spite of the priceless acceleration of validations on the original provided by Freizo, is nevertheless highly time-consuming and demands an expert knowledge of the institutional context. A high variability of formulations, countless inconsistencies in the arrangement of the content of the source, an inconsistent management of abbreviations, apparently bar any systematic intent of automatic adjustment of the data. Creating full versions cannot be, for the time being, envisioned for every directory. The frequency of the upgrade will depend on the result of the evaluation of the potential for research of the source Christian and myself plan to realize from the five directories upgraded to a full version at this moment: 1863, 1874, 1903, 1919 and 1934.
I. Light version.
See the first part of the present text for a global overview of the process. At this stage, work will best be done on the Suites_data_directories layout. The text of the Freizo entry must be downloaded to the AA field.
a) Redressing errors
1) Line splitting
Errors in line splitting must first be redressed. For that I must have a look at all the lines of the files. I easily detect the abnormally short ones. I find to what entry they belonged in the source and paste the fragment at the proper place. This step took around two hours in the 1919 file. Any progress by Freizo on that point would directly speed up the process.
2) OCR readings
To redress OCR reading errors, the FileMaker index is a great help. It provides a list of all the different entries found in a same field, sorted alphabetically. A visual inspection of the list detects suspicious items. Each faulty item can then be automatically retrieved and corrected. One at the time only, which demand many repeated loops. The duration of the process is a function of the number of entries and of the frequency of errors. The Name, Surname, Occupation and Employer fields are successively subjected to this process. Reducing OCR errors has consequently an immediate effect on the reduction of the time needed for such corrections, which make the longer part of the light upgrade process. Hereunder is a list of the most frequent repeated errors detected:
Freizo delivery True value .fc & § ç <fe &
Al M AV W BL M Id H if M ifc & Iv K JE R ld hi li h TL H TV W VV W XL M Xl M XV W
To process the Foreigners in Far East directories are concerned, Freizo must activate the French and Spanish OCR dictionaries: many entries are formulated in these languages. Any user's dictionary based on the light versions of the slicing file (light to preserve abbreviation) would also probably be efficient on that point for the whole Far East foreigners directories set.
b) Structuring the data
The light version only minimally structures data. It keeps most of them in the form in which the source provides them, and stops short of any further upgrade, given the time consuming character of data structuring. The light version addresses the two following points:
1) Structuring the "Name" field.
The name field, when sliced from the original data-block, includes, besides the name proper, titles, such as “Miss”, “Doctor”, “Honorable”, etc.; nobility titles, or qualifications such as “Junior”. Such mentions must be manually extracted and set after the name between brackets.
Example: Mark (Dr) Example: J. C. (Jr) Example: Arturo (Baron)
The fastest procedure comprises three stages:
. Selection (query) of all the entries to be transformed . Appending the qualification string at the end of the existing string, either manually or through systematic change (election depends on the number of cases). . Erasing the original mention.
All three steps can be executed as batch processes by FileMaker.
2) Processing educational titles and decorations
Explicit educational titles, such as BA, DD, PhD and the same, must be manually transfered from the “Name” field to the “Remarks” field, with the label “/Title:”
Example: /Title: MD Example: /Title: BA
The same procedures apply to medals and orders:
Example: /Title: OBE Example: /Title: DSO
And to membership of religious orders:
Example: /Also: Jesuit
II. Full version
The full version assumes that all changes required by the light version have been done. It makes further changes to the same.
a) Structuring the “Actor_occupation”, “Employer” and “Actor_occupation_branch” fields
1) Addressing OCR reading issues
The light version scanned the “Surname and “Name” field through FileMaker index. The full version might do the same for the “Actor_occupation” and the “Employer” fields, although given the complexity of the changes to be made in these two fields and given that, as exposed below, they require a close examination for other reasons, this steps may also be passed over.
2) Structuring records mentioning public employment
Record concerning civil and military servants of sovereign entities, that is of actors endowed with public civilian or military functions, must be processed in a rather complex way so as to allow retrieving the data in accordance to the sovereign entity they represent. See appendix (I), “Formalizing the notation of public entities” for a description of these transformations.
3) Structuring records mentioning religious employment
Records mentioning service in any standing church, be it as a clergyman or a lay auxiliary, must mention two kinds of information in the “Employer” field. A first leg, between square brackets, must mention the denomination of the church when this information is available, either through an explicit or implicit mention of the source, either through external sources (many parishes mentioned in the source still exist and have Internet portals). A second leg, between round brackets, mentions the organization patronized by the denomination.
Example: [Roman Catholic Church] (Saint Ignatius church)
By service of a standing church we mean, not only direct service in organization immediately relevant of the church, such as parishes, seminaries and monasteries; but also service in derived organizations and charities officially or notoriously dependent of the church, such as colleges, schools, hospital and the like.
Example: [Church of England] (Saint Thomas School)
Determining the denomination may be difficult or tricky, especially in an area as the Far East in which inter-denominational missions are usual. When unknown or insecure, the name of the church must be set to “Unknown Church” until more information has been provided.
4) Processing multi-occupational data
In a number of entries, a same directory entry assigns two occupations to a same actor; the most usual case being a consular charge besides a commercial function; or the representation of various countries by a same consular agent. Such cases cannot be detected but through a careful reading of the entry, given that no external features distinguishes them. Most of them will be detected when occupations and employers are carefully scanned in the process of setting identifiers (see further). Manual changes must be made. One of the occupations must be processed as usual. The other one must be transformed into a note of the “Remarks” field, with the label: ”/Also:“
Example: /Also: consul for Norway Example: /Also: president of Avondo Motor cars SA
We conventionally pass to the Remark field the occupation which denotes a more public character. A mention of both occupations must be recorded into the “Actor_occupation_branch” field, each one as a different paragraph of the same record.
Employer Actor occupation branch Remarks Morris Cigarettes Cy. Tobacco industry /Also: consul for Denmark
Danish foreign service
Note: we noticed various cases in which an actor is assigned two occupations by means of two different entries in a same Directory. At first view, such cases do not look numerous enough to significantly bias statistical results based on a global study of the directories.
5) Processing the "Actor_ occupation" field
The content of the “Actor_occupation” field must be reduced to the function of the actor within the firm or the organization, without mentioning the name of the same; although the slicing process often delivers both results together. This transformation must be made manually through a visual reading of the entries once sorted on the “Employer” field. It is a time-consuming process, which takes place at the same time as the setting of identifiers, so that both merge together and do not look so long.
6) Processing the "Employers" field
The content of the “Employers” field must be made homogeneous by expelling from the same mentions of occupations (point 5) and of multi-occupational data (point 4). Abbreviations, some of which may be really hard to understand, must be developed. Identifiers must be assigned to every employer. All these tasks can best be executed at the same time as we explain here below.
b) Global processing of the “Employers” field; assignation of identifiers.
1) The Suites_data_directories_main layout
The global processing of the “Employers” field must take place in the “Suites_data_directories_main” layout. This layout provides an access to all fields which this operation demands, place, name, surname, occupation, employer, branch, remarks, as well as the corresponding local and social identifiers (see the Help file). Moreover, small blueish triggers allow retrieving all records with a same field value as the current one. A special routine allows user to declare any query using the FileMaker syntax in a specific field located in the header of the layout, and to make good this query on the “Employer” and “Surname”, so as to display in one move all the entries concerned by the query.
2) Management of the Suites_data_directories_main layout
A query must first be made to select an employer who has not been processed still. This non-processed condition is denoted by the fact that the “Employer_id” field remains empty. A permanent query allowing such a retrieval has been stored as a saved query under the name “ToBeIdentified”. All selected records must then be sorted on the Employer's name. Abbreviations can then be resolved, either manually or through batch processing, and a local identifier assigned to the selected set of Employers, as well in the “Employer_id” field as in the “Actor_id” field. The loop must be repeated until exhaustion of the stock to be identified. The first passes look highly efficient, as statistically the employers with most records appear first. The last stages are really boring and very highly time-consuming.
3) Assigning identifiers
Given the time-consuming character of the process and contrary to our expectations, we resolved to limit the setting of local identifiers to the Employers, leaving alone, except when data were obviously at hand, the actors. We remind that the local identifier is the record identifier of one of the records in which the concerned party features; that for individual parties this record identifier is taken as such; that when firms or corporations are concerned, the first position of the identifier is changed to E. In the header of the Suites_data_directories_main layout, two red triggers allow to create and assign automatically local identifiers either to the selected actor or to the employer. Such a feature notably speeds up the process. Appendix I
Formalizing the notation of public entities in the Foreigners Eastern directories
a) Governing bodies, “Employer” field The “Employer” field of the entries referred to members and officers of governing bodies and public institutions, once upgraded to the full Fichoz version, is composed of two legs:
1) First leg [a label introduced by the user, describing the authority which empowered the public servant]
- Sovereign regional entity: [Name of the territory “Government”]
Example: [Japanese Government] Example: [Siamese Government]
- Dependency from outside powers: [Name of the territory “Authority”]
Example: [Singapore Authority] Example: [Sarawak Authority] Example: [Shanghai French Authority]
In the Far East area, at the time concerned by the currently downloaded directories, we use the following geographic division (non-exhaustive list):
Chinese government Japanese government Korean government Russian government Siamese government Brunei authority Dutch Indies authority Federated Malay States authority Hankow British authority Hankow French authority Hongkong authority Indochina authority Johor authority Kedah authority Kelantan authority Kiaochau authority Kwangchauw authority Macao authority Newchwang British authority Newchwang Russian authority Ningpo British authority North Borneo authority Perlis authority Philippines US authority Phlippines Spanish authority Port Arthur authority Sarawak authority Shameen concession authority Shanghai authority Shanghai French authority Straits Settlements authority (Singapore, Penang, Malacca, and Dinding) Terengganu authority Tientsin authority Weihaiwei authority Yokohama authority
2) Second leg (description of the governing body, as given by the source)
Example: [Singapore Authority] (Public Works Office) Example: [Shanghai French Authority] (Conseil municipal) Example: [Kuala Lumpur Authority] (Health Office)
Note: square brackets must be set only if the source does not explicitly mention the content of the first leg. The second leg is always written between round brackets. If the source does not mention the organization, the position must be left blank.
Note: no attempt must be made, at taht stage, at distinguishing further among the governing bodies (municipality vs State institutions; police vs health institutions, etc.). The great variety of local situations and the vagueness of the information provided by the sources would necessarily induce errors.
b) Armed forces, “Employer” field
1) Army - First leg:
. Sovereign entity: [Name of the territory "armed forces"] Example: [Siamese armed forces] (Military band) . Dependency: [Name of the territory "garrison"] Example: [Indochina garrison] "Garde volontaire" . The list of geographic entities is the same as that of governing bodies.
- Second leg: (Description of the military unit as given by the source)
Example: [Shanghai French garrison] (Fourth company) Example: [Shanghai garrison] (H.M. Works) Example: [Singapore garrison] (Shanghai and Singapore second Battalion)
2) Naval forces - First leg: [Name of the territory, “naval garrison” - Second leg: (Description of the unit given by the source)
Example: [Vladivostock naval garrison] (Russian Pacific squadron)
Note: fixed installations, as welle as army and navy units are ascribed to the territory in which they are stationed or attached to, as described in the Place field. If no such attachment is mentioned, a frequent case with ships, they must be assigned to the main base possessed by their country in the area
Example: all British ships of the China squadron have been assigned to Hongkong. Example: all Russian ships mentioned in 1903 have been ascribed to Port Arthur.
Note: marine infantry has been processed as army troops, given that it is in fact used as such in overseas contexts. Note: navies who have no possession in the area used to benefit from facilities provided by other countries who have. Their units have adscribed in the data base to such a facility. Note: in some few cases (Weihaiwei garrison in 1903, Shanghai garrison in 1863), some highly autonomous Chinese corps have been processed as independent garrisons.
c) Public economic concerns, “Employer” field Huge public-owned concerns for the production of electricity and the management of railways, form a specific class. The database describes them in the same way as governing bodies, using the same label to describe the public authority concerned. The name of the entity as given by the source forms the second leg. The database distinguishes electricity producers from railway companies.
d) Consular and diplomatic services, “Actor_occupation”, “Employer” and “Actor_occupation_branch” fields.
1) "Actor_occupation" field
The “Actor_occupation” field stores the position of the actor within the current diplomatic or consular post, as described by the source, but deprived of any national character.
Example: "Consul for France" => "Consul" Example: "Italian acting secretary" => "Acting secretary"
2) "Employer_id" field
The “Employer_id” field stores the name of the diplomatic or consular post, including the name of the sovereign entity whose agent are described. These data must in most cases be extracted from the information left apart when upgrading the “Actor_occupation” field (see above). In which case, the information must be set between brackets. In fact, all mentioned diplomatic posts are reduced to the following classes: embassies, legations and consulates.
Example: French consulate Example: US legation Example: German embassy
d) “Employer_id” field - Each specific first leg's wording must be characterized by a different identifier. - A same first leg wording featuring in various different classes must be characterized by different identifier. - If forces of two different countries assume together a same first leg's wording, the identifiers must be different;,and the name of the country concerned mentioned in the first leg of the same.
e) “Actor_occupation_branch” field As a rule, when describing public positions, the “Actor_occupation_branch” field always:
. Mentions the name of the sovereign entity (not the colonial authority) which empowered the actor as a public servant. . Defines the branch concerned using the limited set of annotations listed here under: For consular and diplomatic services: [Sovereign entity] foreign services Example: French foreign services Example: British foreign services
For agent of colonial authorities of any category whatever: [Sovereign entity] colonial agent Example: German colonial agent Example: US colonial agent For navies: [Sovereign entity] Navy Example: Russian Navy
For land forces: [Sovereign entities] Army Example: British Army