Review initiative properties, core vs custom, and implications for open-data

[wu-lee]

Currently sea-map's model of an "initiative" is an object with a fixed set of properties. We've recently added / modified this set for the ICA, adding territoryId, regionId, and superRegionId, and replacing country with countryId.

However, these fields don't make sense for all data sets, and would ideally be absent. And some may need their own custom definition of these fields. For example, the above fields may not make sense for Oxford or Newbridge data, or at least need to be reinterpreted.

The code has been refactored almost (but not quite) to the point where custom fields could be defined in the config. So what I was wondering is, should we review the list of fields, and their relationship to the columns in standard.csv, and work out which of them are "core" and must always be present, and which should be custom fields, specific to a dataset.

Then maybe we should implement a way to define these custom fields only in the projects which need them.

[wu-lee]

See the file 2021-10-04_sea-map-data-fields-review.ods on the SEA nextcloud share, which maps sea-map initiative properties to query parameters to standard.csv fields. It tries to identify which are core (mandatory or optional), and which should be custom.

Possibly we should make only ID and name mandatory, and all other fields custom? This would allow sea-map to become a more generic mapping app, potentially able to show other categories of things like other kinds of location data, or even events,

[ColmMassey]

This has been resolved by supporting local vocabularies that do not need to be mapped to a linked data concept.