security-force-monitor / sfm-research-handbook-old Goto Github PK

Per TL/TW discussions (25 Jan 2017) on how to organise our understanding of how Region Militar and Zona Militar propagate downwards towards municipios:

Ah I see - the basic workflow is trying to simplify down as much as possible - basically not listing >every municipio if we don't have to

1. RMs or ZMs who have an AOO that covers an entire state would have an AOO row(s) that would be OSM AL4 --
   example: 20 Zona Militar covers Colima state so it would only have 1 row and the AOO would be Colima state
   example: II Region Militar covers Baja California, Baja California Sur, and Sonora states - II Region Militar would have 3 rows - one for Baja California, one for Baja California Sur and one for Sonora.
2. RMs or ZMs which have AOOs that cover parts of a single state or which have AOOs that covers portions of two or more states --- we list every municipio in its own row for the AOO of that organization

example: 4 Zona Militar would have Guaymas on one row, Cajeme on another row, etc, etc

3. RMs or ZMs which have AOOs that covers an entire state and portions of another state - we'd use OSM AL4 for the state and OSM AL6 for any municipios covered outside of that state. Every OSM AL4 and OSM AL6 would have it's own row.

Document shift from Geonames to OSM.

There are quite a few formal-sounding classifications in play for Operation Kpochapu:

• anti-crime task force
• Joint Security Operations Outfit
• joint security task force
• Joint Security Team
• Military Joint Task Force
• state joint security team

They're not aliases; nor are they strong, regularly-used classifications like Joint Task Force. THis is why they they are not used in our classifications.

TL:

Assume Area of Operations to Current Date? (Y/N)

Current guidance is to include a Y value where the analyst can assume AoO continues to current date. The use of N is not specified. Specify it should never be used?

TW:

@tlongers No we should use N if we can't assume AOO continues to current date or when we know it doesn't (ie a unit is relocated and ceases to operate in an area around the unit's Site).

Depending on the structure/level of knowledge of a security force we can be fairly liberal with Y - for example we generally only have 1 source for AOOs for police units in Nigeria, but we know that in general the police force is fairly static (units don't move, rarely stood up or disbanded) thus I'm comfortable usually assuming AOO to current date. Conversely - the Nigerian military can be quite active so using Y needs more context (is the AOO near a long term Site for the unit, or is in the NE which we know units cycle in and out of?)

I see N tied more towards the visual, though useful in the data side of things too (mainly for clearly marking when an organization no longer operates in an area). Given that we use N interchangeably for "not sure about this so playing it safe" and "we have a source to say this organization no longer operates here" we might think about handling this differently.

TL:

A challenge with the use of this method is that a Y designation becomes progressively more inaccurate as time passes. Y looks credible where we have only a little time between the current date, and the last source. I wonder whether the visual should flag something to the effect of "Whilst we consider this situation continues to today, the most recent source for this is 120 days old".

TW:

Agreed - I like the idea of seeing the date of the last source in some way for every Y designation, meaning geography, but also parentage.

TL:

So this needs to be turned into an issue for the CMS initially, to propagate across to the UI?

TW:

That's a good idea of how to tackle it. Perhaps let's create an issue in the shed for data model/CMS issues that in our own view we need to tackle. I'd put some internationalization questions on that issue list as well.

Event: Perpetrator classification is not used when we have an exact value for Event: Perpetrator name.

This should be Parent relationship: date last cited rather than Parent organization: date last cited:

https://help.securityforcemonitor.org/en/datamodel/organizations.html#organization_parent_date_last_cited

Update needed in main content and sidebards, in en and es.

Missing:
https://help.securityforcemonitor.org/en/datamodel/events.html#event_exact_location_longitude_name
https://help.securityforcemonitor.org/en/datamodel/events.html#event_exact_location_latitude_id

Operación Coordinada Chihuahua is listed as an alias of Operación Conjunta Chihuahua. I think this is a correct application of the organization:alias rules, as the two operations have been confused. We need a specific field to note mistaken identities.

TW:

This is a Mexico specific discussion, but has broader implications for most countries where AOO=command and control.

Per law since at least 9 June 1951 Zona Militares command any unit that is within its territorial jurisdiction (area of operations), except those that are subject to a “mando especial” (special command):

Artículos 6o y 9o [SEGUNDA PARTE De las Zonas Militares] de la Reglamento General de Regiones y Zonas Militares, 9 June 1951, derogado por el Reglamento General de Mandos Territoriales, Guarniciones Militares y Servicio Militar de Plaza, 22 April 2013. http://www.sedena.gob.mx/pdf/reglamentos/rgltmo_reg_zon_mils.pdf Internet Archive link: https://web.archive.org/web/20101220233006/http://www.sedena.gob.mx/pdf/reglamentos/rgltmo_reg_zon_mils.pdf ; Artículos 65 y 68 de la Reglamento General de Mandos Territoriales, Guarniciones Militares y Servicio Militar de Plaza, 22 April 2013. http://www.diputados.gob.mx/LeyesBiblio/regla/n373.pdf Internet Archive link: https://web.archive.org/web/20160420090245/http://www.diputados.gob.mx/LeyesBiblio/regla/n373.pdf

The question for us is, how should we handle the parent/child relationship when a Batallon de Infanteria or another unit smaller than a Zona Militar has an AOO that falls under two (or more) Zona Militares? Options:

1. Assume the Batallon has multiple parents
2. Make no parent assumption, regardless of AOO - parent relationships are only determined via source
3. Case-by-case - Assume multiple/overlapping parents if AOO appears to be part of "special" or "temporary" assignment away from the Batallon's "home" Site. This is made more difficult if there is no or limited data on the Site.

Another question - if there are no sources for parent relationship - should we assume parent based on overlapping AOOs, or based on a Batallon's Site being in an AOO for a Zona Militar? My instinct here is to say yes, we should assume.

@tlongers - one municipio Ziracuaretiro (5606676) we have assigned to the 21 Zona Militar from 10 Feb. 2004 to 21 Nov. 2016 based on the SEDENA maps. We also have two sources that put the municipio as part of 21 ZM.

Interestingly that same municipio falls under the AOO of the 62 Batallón de Infantería, at least for an operation in 23 Jan. 2009. That same operation was reported as being carried out under the auspices of the 43 Zona Militar, making the municipio also part of the 43 ZM's AOO, and the parent of the 62 Batallon.

Even more interestingly that Batallon was (and is) based in Irapuato, Guanajuato which would place it inside of the 16 Zona Militar's AOO.

So:

1. Sources have Ziracuretiro as being part of at least 2 ZMs
2. Based on the SEDENA source I would not split the parentage of the 62 Batallon
3. Based on the 62 Batallon having a Site inside of an AOO of another ZM it means we should take a case-by-case approach to assigning parentage
4. Parentage doesn't seem to strictly follow the AOOs of units - contrary to what the law would make us think
5. HOWEVER - I do think in absence of any parent information we should attach batallones to the ZM which has an AOO that cover their Site, or a matching AOO. Our source for this determination would be the law itself with low confidence. The date of this parent relationship would be based on the date of the Site and/or AOO which sparked the connection.

TL:

Good example - this shows the limits of assigning Command by geography, rather than the details of deployment.

Some questions/thoughts:

• This is the difference between describing what we see from the sources in front of us, and understanding how decisions (about deployment, command and so on) are made in reality.
• What are our chances of finding information about the use of "mando especial", which may or may not be a commonplace mechanism used by the Army to frame deployments and clarify chains of command?
• Do we have other precedents or examples of where parentage of a Batallon appears to have shifted ZM as a result of subordinate units being deployed within the terrain of another ZM?
• Do we need a create some kind of "dynamic cluster" to represent operations that are somewhere in between daily run of the mill "militarying" and an Operation Pulo Shield type op? Because operations like the 23 January 2009 on in Ziracuaretiro are probably common.
• For the Ziracuaretiro operation, we don't whether troops/materiel/assets from 21 ZM were also tasked to 62 Bat's command.

On the technical side, the visualisation does not appear to have a way of showing contemporaneous allocation of a administrative area to more and a single organisation. It would be possible to temporarily assign an administration area to an organisation for a specific duration, before reverting it back to "normal" (e.g. its Zona).

TW:

What are our chances of finding information about the use of "mando especial", which may or may not be a commonplace mechanism used by the Army to frame deployments and clarify chains of command?

Good question - it's not clear what "mando especial" really means as there are special forces units (for which the chain of command needs to be clarified). I haven't seen this referenced in any sources yet so it may be difficult simply because of disconnect between official legal language and the language used in sources.

Do we have other precedents or examples of where parentage of a Batallon appears to have shifted ZM as a result of subordinate units being deployed within the terrain of another ZM?

I'll have to dig a bit on this - there are some units that have changed parents multiple times, largely because they have been moved to different Sites (I believe).

Do we need a create some kind of "dynamic cluster" to represent operations that are somewhere in between daily run of the mill "militarying" and an Operation Pulo Shield type op? Because operations like the 23 January 2009 on in Ziracuaretiro are probably common.

Hmmm - not sure - I see the operation in Ziracuaretiro as part of normal "militarying" as it were. I'm trying to think of an example of what you're describing, I guess the best example I can think of is when we know some soldiers from a unit are deployed in a time-bound manner to another place - as described here (link). How I've dealt with this is to add a Site and/or AOO related to the Site or Area of special deployment with a start date and N for "assume to current date?". I think this captures the information well - and is a fairly good example of special deployments like this - we know a portion of a unit moves, the chain of command for those specially deployed forces doesn't appear to be part of any Op Pulo Shield type organization, and there is an implied end date (though we may not know it).

On the technical side, the visualisation does not appear to have a way of showing contemporaneous allocation of a administrative area to more and a single organisation. It would be possible to temporarily assign an administration area to an organisation for a specific duration, before reverting it back to "normal" (e.g. its Zona).

Yes that's something that will need to be fixed one way or another (depends on NGO feedback how we implement). I've been chewing on the idea of having a map that's the OSM base and "blank" - the user would search for a point/area on the map and then the SFM's data would kick in - searching for Ziracuaretiro would bring up all the units that have operated there (or perhaps within a certain time range as selected by the user).

TL:

The main action here is:

• Add into the Handbook some text about the Ziracuaretiro operation, using it as as an example of how to apply the model in cases of complicated parentage.

There are no actions here with respect to the initial incorporation of sfm_structure_geo_final into the Mexico dataset This is because the information relating to the Ziracuaretiro operation is added as an additional, distinct row.

TW:

The Monitor has certain conventions regarding what it uses as the "official" name for organizations:

1. Use Arabic numerals (0, 1, 2, 3, etc.) rather than "One" or "First"
2. Ordinals (1st, 2nd, 3rd, etc) should be listed in aliases
3. Sources for names with the number spelled out "One" or "First" and/or ordinals should be listed only as sources for aliases, if there is no source for the official standardized name the researcher should attach a note explaining the name has been standardized and listing the source(s) (if relevant) for the Monitor's standardization

TL:

In some sources, a date of publication or update is not included at all within the source itself. In these cases, it may be preferable to make use of the date a snapshot of the source was made by the Internet Archive. This needs to be worked through and new guidance included in the Handbook.

My suggestion is that where there is a stated publication date we keep the current citation format. Absent a stated publication, we parse out the crawl date from Internet Archive and include it as a separate field in the raw data. In the human readable source citation, we flag it as such in the date field. For example, this source from the SFM Mexico research:

Ejército Mexicano – Regiones Militares. Secretaría de la Defensa Nacional (Mexico). Date crawled: 8 February 2004. http://sedena.gob.mx/ejercito/comandancias/reg_mil.htm Internet Archive Link: https://web.archive.org/web/20040208205506/http://sedena.gob.mx/ejercito/comandancias/reg_mil.htm

This is a particularly important where over time the content of a web page changes, and there is no publication date on any of the various versions in the Internet Archive.

TW:

Agreed - as an addition to this workflow I suggest that the researcher always capture a snapshot of the page they are on when they first access it. This way even for pages that have been crawled before we can use the crawl date as a substitute for the common "date accessed" formulation.

One issue is with sources that cannot be crawled and have no date. We'd need to 1) develop archiving policy, 2) use the "date accessed" formulation in addition to any other relevant notation (such as "on file with the Monitor")

TL:

We'd need to 1) develop archiving policy

Internet Archive has an offering called Archive It, which allows you to run your own crawling and archiving projects. Given that some of the content we wish to store, in the public interest, is blocked by robot exclusion it's good to know that Archive It enables you to request the crawler to ignore robots.txt. Also, Columbia University Libraries already runs a Human Rights collection on Archive It so there may be something existing infrastructure we can plug into and benefit from here.

If that isn't the path forward, there are (probably) self-hosted tools of various maturity that perform a similar function to the Wayback Machine and can be used as a private version of such.

https://help.securityforcemonitor.org/en/datamodel/persons.html#person_name

Where we only have a value for person:aliases this should be recorded in person:name until information about their real name emerges.

@tonysecurityforcemonitor any issues with that?

Gerardo Rubén Serrano Herrera
Also known as: Rubén Serrano Herrera | Serrano Herrera

Source: http://web.archive.org/web/20170711152120/http://www.zocalo.com.mx/opinion/opi-interna/salvador-rodriguez-orozco-a-la-fiscalia-de-la-sexta-zona-militar

Where a source refers to a person by their surname, we should not include this as an alias. The source's use of a surname is an stylistic decision by the publication's editors.

Update Research Handbook with this good example of looking in the source code to find the date:

URL: http://www.odogwublog.com/2014/04/obiano-launches-operation-kpochapu-with.html

• No publication date stated in the article itself
• Infer April 2014 from URL /2014/04/
• Look at the source and find this in the headers:

<abbr class='published timeago' itemprop='datePublished' title='2014-04-28T20:32:00+01:00'>Monday, April 28, 2014</abbr></a>

https://help.securityforcemonitor.org/en/datamodel/organizations.html#organization_site_date_last_cited_open_ended

Text after : should be capitalized.