Add new fields to /api/country_scoring/:country_id and change response format

[thom4parisot]

To implement #307, ideally, new fields would be added to the /api/country_scoring/:country_id route:

• is_existing_txt (Organisation Name)
• is_prov_timely_last (Date of last known dataset update)

@pzwsk mentioned notes but this can be a very large field so I wonder if that's relevant to include in a one liner description. Eg:

Dynamic National Map Relief and Physiography\nThis service has been created specifically for display in the National Map and the chosen symbology may not suit other mapping applications. The Australian Topographic web map service is seamless national dataset coverage for the whole of Australia. These data are best suited to graphical applications. These data may vary greatly in quality depending on the method of capture and digitising specifications in place at the time of capture. The web map service portrays detailed graphic representation of features that appear on the Earth's surface. These features include the relief and physiography themes from the Geoscience Australia 250K Topographic Data. The service contains layer scale dependencies.

I suggest returning a response which looks like this:

{
  "scores": [
    {
      "dataset_id": 170,
      "keydataset_id": 52,
      "name": "Active seismic fault",
      "category": null,
      "score": 85.0,
      "is_existing": true,
      "is_digital_form": true,
      "is_avail_online": true,
      "is_avail_online_meta": true,
      "is_bulk_avail": true,
      "is_machine_read": false,
      "is_pub_available": true,
      "is_avail_for_free": true,
      "is_open_licence": true,
      "is_prov_timely": true,
      "is_existing_txt": "Geoscience Australia Earthquakes",
      "is_prov_timely_last": "Last 7 days",
      "notes": "Interactive maps on Significant earthquakes:\nlast 4 hours\nlast 24 hours\nOlder"
    },
    // ...
  ]
}

Instead of:

{
    "scores": [
        [
            "id",
            "name",
            "category",
            "instance_id",
            "score",
            "Does the data exist?",
            "Is the data available in digital form?",
            "Is the data available online?",
            "Is the metadata available online?",
            "Is the data available in bulk?",
            "Is the data machine-readable?",
            "Is the data publicly available?",
            "Is the data available for free?",
            "Is the data openly licensed?",
            "Is the data provided on a timely and up to date basis?"
        ],
        [
            52,
            "Active seismic fault",
            null,
            170,
            "85.0",
            true,
            true,
            true,
            true,
            true,
            false,
            true,
            true,
            true,
            true
        ],
    // ...
  ]
}

What do you think @nastasi-oq?

[nastasi-oq]

@oncletom the tabular approach was thought to be able to build the FE view based on a fixed number of columns + an arbitrary number of boolean with their proper associated question, using this feature add or remove questions not requires FE changes. If you don' t see value in that we can change it to a more standard view as you suggest. is_ prefix was related to boolean values, probably we can use just title and last_mod of the higher scored dataset of that KeyDataset group.

[thom4parisot]

to build the FE view based on a fixed number of columns + an arbitrary number of boolean with their proper associated question, using this feature add or remove questions not requires FE changes.

I understand. In practice, in the frontend code, there are many areas to deal with when a new question is added.

I find it easier to work everything the same way, as lists of objects.

is_ prefix was related to boolean values, probably we can use just title and last_mod of the higher scored dataset of that KeyDataset group.

Perfect 👍

[pzwsk]

Up as this is relevant for discussion on indicators and performance improvement cc @nastasi-oq @CIMAManuel

[pzwsk]

One remark, we should continue to separate question Y/N and related text fields as those are in the end general metadata for the dataset, providing evidence but not related only to the question.

[thom4parisot]

And #418 scratch the surface that "Yes/No" does not encompass the "I don't know"/"Not applicable"/"Not clear"—at least regarding the license (there is no license but it's still free to (re)use).