Field checks: Display values in the quality failure samples table

[duncandewhurst]

For fields which aren't objects or arrays it would be useful to see the actual value for each of the examples in the samples of successes/failures table, so we don't have to open multiple JSON previews to view the individually.

Basically, I mean adding a 'value' column to this table:

[jpmckinney]

This could work for field-level checks.

[hrubyjan]

@duncandewhurst @jpmckinney
Is this still relevant or how this should work?

I mean this make sense to me basically only for field level quality checks.

Filed level - is set? - nothing can be displayed when it's not set as the key is missing. When it's set then it's some random value
Field level - is null or empty? - either null or empty string. Or again some random value
Field level - quality? - make sense for failures. But even here imagine for example description longer then 250 characters that should nicely fit into the table

Resource level - there is always more information that needs to be displayed no simple value

Collection level - it can make sense to display the values for Value distribution checks but not for the rest. And here is no need to open multiple jsons as the the examples are in the metadata which are static for each check or even the values are headers of tables (for distribution checks like currency, status, 'procurememntCategory' , ...)

[jpmckinney]

I think the idea was to display something for field-level quality failures. If the description is too long, we can truncate it in the table - so in that case, the user might still need to open the example. For numbers, etc., it is fine.

The issue description also mentions examples for quality successes, but I am not sure in what scenario we want to look at good values.

[duncandewhurst]

I think the idea was to display something for field-level quality failures.

Yes, that's correct.

The issue description also mentions examples for quality successes, but I am not sure in what scenario we want to look at good values.

In general, it might help to put the failures in context and give some insight into whether the cause is a mapping error or a quality issue in the data source. However, looking at the list of field-level quality checks, I'm not sure it's relevant to the checks we have right now.

[jpmckinney]

Sibling issue for compiled release checks: #49

[jpmckinney]

Merging #51:

Title: Show/export list of unrecognized party identifier schemes

It would be helpful to get a deduplicated list of the identifier schemes which failed the check, so we can report these to the publisher.

Note that #51 also discusses whether to add this as a dataset-level check in order to get a comprehensive list of invalid schems, but we can first report the values in the samples at the field-level.