Jurisdictions in Organization Dossiers

[badapplesdatabase]

Example url: http://ffctn.com/clients/on/sfm/0.9.0/#country/ng/o/92bb9d0c-7c71-488d-9e71-80cf0069b635!date=2014-01-01&focus=map&overlay=organization-dossier

There are two different lists for the Jurisdictions in the right hand column --- this is confusing for users and not necessarily. One of the lists has dates, which is good, but those start and end dates don't have citations and the areas themselves have N/A-N/A after them - I'm not sure why that is.

[badapplesdatabase]

Sebestien noted that this was a backend issue, not a UI issue.

[jpmckinney]

@sebastien will have to be more specific. Looks like a presentation issue to me. If the admin_level_1 and admin_level_2 are unknown, it seems weird to display "N/A" instead of just displaying nothing. I think it's a data issue - not a backend issue.

[jpmckinney]

Also, as far as I can tell, the UI is in fact displaying the same data twice. Both lists are using details from the organization's areas.

[sebastien]

I think we did not have a good understanding of how locations should be displayed. Right now the application is not working (backend connection seems down) so I cannot see exactly what the problem is. If you have a screenshot, that would be super helpful!

[badapplesdatabase]

Here is a screenshot from 81 Division

[sebastien]

Oh right, thanks. I think we had problems with understanding the location data structure and how the fields were used. In that case, I think we assumed the data was incomplete but would be completed later on. Could you describe the location object, and the role of each field, and wether they're optional or not? We can then work on having a clearer representation.

[badapplesdatabase]

Each Organization has two geographies related to it:

1. It's Site(s) - which includes the data fields:
   • Headquarters (Barracks, Base, Physical Asset)
   • Source: Headquarters
   • Confidence: Headquarters
   • Headquarters GPS Latitude (if these exist this would inform the Site location on the Map)
   • Headquarters GPS Longitude (if these exist this would inform the Site location on the Map)
   • Source: Headquarters GPS
   • Confidence: Headquarters GPS
   • and
   • City or smallest administrative unit GeoName
   • City of smallest administrative unit GeonameID
   • Source: City of smallest administrative unit
   • Confidence: City of smallest administrative unit
   • ADMIN1 (state, province, governorate, or other largest administrative unit) Geoname
   • ADMIN1 (state, province, governorate, or other largest administrative unit) GeonameID
   • Source: ADMIN1
   • Confidence: ADMIN1
   • and the dates for the Site are tied to:
   • Date of first citation
   • Source: Date of first citation
   • Confidence: Date of first citation
   • Is this the founding date? (Y/N)
   • Date of last citation
   • Source: Date of last citation
   • Confidence: Date of last citation
   • Is this the dissolution date? (Y/N)
2. It's Area(s) of Operations (as noted in Google Docs - we should use this term in the UI in place of Jurisdictions or Areas of Responsibilities both of which convey a more legal/formal responsibility over an area that we can't always assume --- using the lowest common denominator of Area(s) of Operations avoids confusion and still gets the necessary information to the users) - which includes the data fields:
   • Area of Operations (Area of Responsibility Jurisdiction) Geoname (to be renamed in Google Sheets)
   • Area of Operations (Area of Responsibility, Jurisdiction) GeonameID (to be renamed in Google Sheets)
   • Source: Area of Operations (to be renamed in Google Sheets)
   • Confidence: Area of Operations (to be renamed in Google Sheets)
   • Date of first citation for area of operations (to be renamed in Google Sheets)
   • Source: Date of first citation for area of operations (to be renamed in Google Sheets)
   • Confidence: Date of first citation for area of operations (to be renamed in Google Sheets)
   • Date of last citation for area of operations (to be renamed in Google Sheets)
   • Source: Date of last citation for area of operations (to be renamed in Google Sheets)
   • Confidence: Date of last citation for area of operations (to be renamed in Google Sheets)
   • Area of Operations assumed to current date? Y/N (addition as discussed in separate thread with James) https://github.com/opennorth/sfm-proxy/issues/11

[badapplesdatabase]

Site(s) are currently displayed in the dossier like this:

url : http://ffctn.com/clients/on/sfm/0.9.0/#country/ng/o/92bb9d0c-7c71-488d-9e71-80cf0069b635!date=2014-01-01&focus=map&overlay=organization-dossier

Or when there is a Headquarters (Barracks, Base, Physical Asset) field like this:

url: http://ffctn.com/clients/on/sfm/0.9.0/#country/ng/o/278c27c9-b3e4-4800-93e2-855324e0b423!date=2014-01-01&focus=map&overlay=organization-dossier

[badapplesdatabase]

And the Date of first citation and Date of last citation are displayed in a separate location here:

url : http://ffctn.com/clients/on/sfm/0.9.0/#country/ng/o/92bb9d0c-7c71-488d-9e71-80cf0069b635!date=2014-01-01&focus=map&overlay=organization-dossier (same url as first example above)

[sebastien]

I think it would be much easier if there was a field location with a human-readable value for the location, as the root of the problem (on the UI) is complicated logic (to me) of creating a presentable location from the city/admin_area_1/admin_area_2 fields.

And yes, we should make it clear (in the interface) the distinction between sites and jurisdictions/areas of operations. The presentation will be clearer if be have the human-readable location field for both.

[badapplesdatabase]

Hi Sebastien --- I think we can do both while keeping the current data model. We are pretty close already.

For the section Headquarters (which we should rename to Bases since some Organizations have multiple bases and determining which one is truly the "headquarters" would complicate things unnecessarily, and not be that helpful to users) the logic for the UI should be:

Headquarters (Barracks, Base, Physical Asset) - City or smallest administrative unit GeoName - ADMIN1 (state, province, governorate, or other largest administrative unit) Geoname

It seems like the UI is already doing that as shown here:

When Headquarters is blank we'd just use "Name's base in" so it would be something like this:

[badapplesdatabase]

For Area(s) of Operations we'd just use Area of Operations (Area of Responsibility Jurisdiction) Geoname

Geonames are always human readable so it should be easy to have them display in the UI

[badapplesdatabase]

The reason I want to keep the current data model is it relies on Geonames which forces standardization for data entry AND has external data model that other projects can use to quickly plug the Monitor's data into their work.

Also - in terms of UI if we just used location (which I'm assuming would be the smallest Geoname possible) we'd lose the valuable nuance of: we have High Confidence this Organization is based in Lagos State, but Low Confidence that its based in the city of Lagos. Additionally - many countries have states/provinces and cities with the same name so for instance if we just had a location of Lagos it wouldn't be clear if that meant the city of Lagos or the state of Lagos. A user would have to consult the Map or otherwise complicate their workflow.

[sebastien]

Thanks for the clarification, I think I meant location in addition to the other fields. The logic you described is still quite complex for formatting, and it's common practice for object to have machine-processable fields (lat/lng, admin1, admin2, etc) in addition to human-readable fields (location).

It's technically possible to implement it on the front-end, but anyone using the SFM API will have the same trouble of finding how to present the location in human-readable form, which is why I think it's better to do that on the back-end and let the front-end display location verbatim.

[badapplesdatabase]

Ok so you're proposing that the location for

would be Dalet Barracks - Kaduna - Kaduna State, right? That's what would be in that field on the backend. Or basically whatever we decide to put would be what is displayed in the UI text.

[badapplesdatabase]

@jpmckinney does this defeat the purpose of using Geonames as the gazetter?

[jpmckinney]

I think we can just have the API calculate what the location text should be based on the other fields, if it’s too much trouble for the UI to do it.

On Sep 30, 2015, at 2:58 PM, badapplesdatabase notifications@github.com wrote:

@jpmckinney https://github.com/jpmckinney does this defeat the purpose of using Geonames as the gazetter?

— Reply to this email directly or view it on GitHub https://github.com/opennorth/sfm-proxy/issues/17#issuecomment-144507089.

[badapplesdatabase]

@jpmckinney does it complicate the API to have to do this? If adding location would simplify things for everyone AND still make the geocoding through Geonames work for other projects wanting to use SFM data that could work. We'd need several location columns for different languages, but that could work....

[jpmckinney]

It won't be too complicated.

[badapplesdatabase]

Ok great!

[sebastien]

What we do in that case (i18n) is to do the following: location:{en:"English location...", fr:"French location", ...}

[badapplesdatabase]

At this point I'm planning for the Monitor to have/expand to the following languages:

English, Spanish, Arabic, French, Portuguese, Russian, Indonesian

It could expand outside of that, but I think that's already plenty ambitious/realistic given target user base.

[jpmckinney]

The location field is specified in this issue as a concatenation of other fields. Those fields are (to date) not translated. So, for the time being, let's leave location as one simple field.

[jpmckinney]

UI can be updated to use the new location field. See #23 for new issue.