Alternative formats for reviewing your data
Error Description | Error Count | First 3 Examples | Location of first 3 errors |
---|---|---|---|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
|
1 |
|
|
{} does not have enough properties |
1 |
|
|
{} does not have enough properties |
1 |
|
|
Field | Path to Field | Codelist | Additional Values Used |
---|---|---|---|
status | projects | projectStatus.csv | completed |
Field | Path to Field | Usage Count | Examples (first 3) | Child Fields |
---|---|---|---|---|
test | /projects/social/healthAndSafety/materialTests | 1 |
Field | Path to Field | Codelist | Additional Values Used |
---|---|---|---|
scheme | projects/additionalClassifications | classificationScheme.csv | COFOG |
Check Description | Location of first 3 errors |
---|---|
The data includes fields that are empty or contain only whitespaces. Fields that are not being used, or that have no value, should be excluded in their entirety (key and value) from the data. |
|
This coverage report details which OC4IDS fields are populated in your data.
If a field is on an object in an array, then coverage is reported for each object in the array. For example, in a data file with 100 projects, all of which have 5 parties, the coverage for the parties
field will be calculated out of 100, but coverage for its child fields (like parties.id
) will be calculated out of 500.
Child fields are reported in the context of their parent field. For example, in a data file with 100 projects, 10 of which set publicAuthority
, coverage for the publicAuthority
field will be calculated out of 100, but coverage for its child fields (like publicAuthority.id
) will be calculated out of 10.
It's not expected for all fields to be used (e.g. the source system might not have the data available), or for all fields to be 100% (e.g. a new project will be less complete than a finished project).