How shall we handle geolocations for policies?

[trugwaldsaenger]

Background:

• A location can be attributed directly to persons, organisations, services, projects, events and stories. The basic location section used for this includes a country, a region and a certain address.

• If filled out correctly, the basic location section creates a pin on the map and also counts an entry for certain statistics on countries (e.g.: "How many repositories are located in France?")
• The basic mechanism for the assignment of locations for activities (e.g. services, projects) is, that a location can be added to the service or project directly (using the basic location section) or by inheriting its location from its provider. If a location is attached directly to the service this location will be choosen. If there is no direct location, the location from the provider will be taken. This general mechanism has been critizized for being to complex and currently is under discussion (see Migrate location data #1953)
• Tools, publications and policies do not provide a complete basic location section, so no location can be added to them direclty.
• The solution for tools is unique and does not fit to the other data types, since a tool shows the location of its users ("is used by") and not the adress of its developer (=provider).
• Publications and policies inherit their location from its publisher.
• Additionally the policy template allows to add a reduced location section directly to the policy entry itself. This is made up from the country field from the basic location section and an additional "region" field.
  
• Very confusing is, that there are currently two region fields implemented, one is part of the basic location section and includes a drop down menue (in the following: "geolocation region"). The other is a free text field, which is only available for policies and publications (in the following: "free text region").
• The reason for including the "free text region"-field was that we importet a data-set from the former OER Policy Registry, which included this information. Since we could not map it automatically to the "geo-location-region", but at the same time wanted to keep this information, we created a new field for it.

Problem description

Within our cooperations for the OE Policy Hub we received an request to include a drop down menue (like is available for the geolocation-field to the currently implemented free-text-region-field. Since we are expecting an uptake of policy-editing soon, it has to be cleared:

1. What technical changes have to be implemented to start intensive data collection?
2. What manual editing of existing data sets might be necessary?
3. How should editors be instructed to handle regions for policies?

First ideas for solution

A solution could look like this:

1. Include complete basic location section to policy template
2. Identify policies, which carry both a geo-location-region, as well as a free-text-region.
3. Editorial control of all identified policies to check if the geo-location is identical to the free-text-location
4. Analyse if the field "free-text-location" is needed anylonger (e.g. for showing that a policy is applicable for a certain region)
5. Add geo-location to policies or link to publisher, where missing
6. delete the free-text-location from the template
7. edit all new policies-documents using the geo-location-region

[trugwaldsaenger]

Open to comments! I also assume @st-martin might be interested in this issue!

[literarymachine]

Publications and policies inherit their location from its publisher.

Yes, and they currently always do so even if they are provided with a location of their own. We decided to do so because when importing the CC data, the granularity of location information was only up to the region for policies, but street level for their publishers. In order to show a pin, we need this street level information.

Additionally the policy template allows to add a reduced location section directly to the policy entry itself. This is made up from the country field from the basic location section and an additional "region" field.

Very confusing is, that there are currently two region fields implemented, one is part of the basic location section and includes a drop down menue (in the following: "geolocation region"). The other is a free text field, which is only available for policies and publications (in the following: "free text region").

See #1945 (comment) for some details about this.

A solution could look like this:
Include complete basic location section to policy template

Either this, or stay at the region level but display the region drop down as described in #1945 (comment). The question is if you want to provide location data down to the street level for policies or not. Connected to this the question if you want to continue always showing the location of the publisher on the map.

Identify policies, which carry both a geo-location-region, as well as a free-text-region.
Editorial control of all identified policies to check if the geo-location is identical to the free-text-location

This is never the case, geo-location is currently always brought in via the publisher.

Editorial control of all identified policies to check if the geo-location is identical to the free-text-location

We are only talking about 45 policies that have a region field set independently of their publisher. The current values for policy regions include Latin America and Europe. When moving to country regions, this information would be lost. The question is if it is important.

My suggestion:

1. Make up your mind about the semantics of a Policy.location field. What goes in there? Is this location the location that the policy applies to? Is it just any location that the editors want the policy to show up at?

2. If you want country regions in the policy locations, you can replace the free-text regions by a proper identifier. See here for a mapping that includes all clear cases. I was not able to map all regions to our currently supported regions. You could migrate the data using SPARQL, but it would probably be faster to just review the 45 policies and enter the region code instead of the free-text into the current region field.

3. When done, either use the basic location widget in the policy template or "create a version of the PlaceWidget without the mini map and address lookup and use that wherever we need only country + region granularity." (Add list of state/subnational entities to field "region" for policies #1945 (comment))

[trugwaldsaenger]

Diskussed this issues with @gandalfar today. We came up with following decisions:

1. The location field for policies should have the same functionality like it has for most other datatypes on the map. That means that it should show the location of its origin. E.G. for an institutional policy, the location of the publishing institution should be displayed.
2. The location field should not be used for displaying the "area of application" of the policy. In most cases this will be no problem. A state policy of Colorado will receive its geolocation in Colorado. Also its "area of application" will be in Colorado. So there is no problem. But we expect issues to appear for multinational policies. The UNESCO Recommendation is located in Paris, France, since this is the location of UNESCO HQ. It`s "area of application" is global. Nevertheless in the statistics it will counted to France at the moment. We agreed, that this Issue should not be solved by the location field. A solution could be to separate all policies which carry the level "multinational" and do not count them to the country of its location. This has to be adressed within a separate issue.
3. Instead the currently implemented "free text location field" the standard geolocation widget should be implemented, which includes drop down lists for states.
4. Currently the location for policies is only being taken from the linked publisher. This should be changed to the regular inheriting mechanisms, which gives direct locations priority and takes the location of a linked publisher as a fall back solution.
5. After the standard geolocation widget has been included, the data has to be checked and manually edited if necessary.