Field coverage visualisation: calculation

[pindec]

The OC4IDS field coverage calculation should align with Pelican's OCDS field coverage calculation to avoid confusing publishers:

• There is one check per field in the project schema. If a field is set, and its value is neither null nor empty (whether it is an object, array or string), then the coverage test passes.

• If a field is on an object in an array, then the coverage test is run for each object in the array. If a field is on an object in an array, then coverage is reported for each object in the array. Example: There are 100 projects, all of which have 5 parties. The check for the parties field will be reported out of 100, but the checks for its child fields (like parties.id) will be reported out of 500.

• Child fields are reported in the context of their parent field. Example: There are 100 projects, 10 of which set publicAuthority. The check for the publicAuthority field will be reported out of 100, but the checks for its child fields (like publicAuthority.id) will be reported out of 10.

See also:

• OC4IDS Coverage calculation colab notebook (internal resource).
• Pelican backend

[pindec]

Noting that there are many ways to calculate coverage.

For example see related discussion on multiple levels of coverage views in OCDS.

• For field level coverage, the above approach above seems to be an appropriate low-level minimum to start with.
• For intermediate coverage, we could explore in future similar calculations around absolute coverage: i.e. proportion of the OC4IDS fields that have coverage in any project.
• For high-level coverage, we could explore coverage at project level and contracting process summary level. CoST members have also mentioned thinking of coverage in terms of whether it helps them meet the disclosure requirements of the IDS (by project stage and by type of disclosure (proactive/reactive)), so that may form part of future work, but is out of scope for now since not all OC4IDS DRT users are CoST members, and it requires further user research.

[jpmckinney]

This issue describes two types of calculation: the indicator (first bullet) and the aggregation (other bullets).

In terms of implementation, the indicator calculation might be what is stored, whereas the aggregation calculation might be performed by the visualization, or stored in a second phase. This would make it easier to change the visualization later (per Charlie's points on intermediate and high-level coverage).

Here is Pelican's indicator calculation (same as described in Charlie's first bullet, but with more specific error messages for Pelican's use case).

The indicator calculations are then aggregated into reports. This is just as FYI as the calculation is straightforward.

And here is part of Pelican's frontend. Pelican uses Vue, whereas I guess CoVE might use Bootstrap accordions. Again, there's nothing fancy. The CSS might be reusable, though, if desired.

[pindec]

@jpmckinney Do you have any preferences on CoVE using Bootstrap and/or Vue?

[jpmckinney]

CoVE already uses Boostrap. I suspect switching to Vue would consume all available time.

[duncandewhurst]

Done in https://github.com/OpenDataServices/lib-cove/pull/89