Clarify requirements around bodsVersion

[kd-ods]

At the moment, there is nothing in the documentation about whether all statements in a BODS release/array should have the same BODS version. There is nothing about it in:

• the bodsVersion description
• the serialization info
• the conformance and validation statement

The data review tool has to take a line on this - the line is that all statements in the submitted data should conform to the same BODS version. Recent work provides better handling of instances where this is not the case.

Is there any reason why - for the next BODS release - we shouldn't update the docs to specify that all statements in a BODS release/array must have the same BODS version?

(@StephenAbbott @kindly @ScatteredInk @siwhitehouse)

[StephenAbbott]

Is there a future risk here that BODS publishers who are early adopters of BODS v0.2 would move to BODS v0.3 once that is released and then the BODS release that they publish could contain a mixture of newer statements with bodsVersion 0.3 and older statements with bodsVersion 0.2? Or would all those historical statements likely be updated to bodsVersion 0.3?

[kd-ods]

I think that historically-made statements which were still true/active should be updated to 0.3. That is: our advice to publishers would be that a data snapshot of current BO information SHOULD all use the same version of BODS.

This is where we need to pin down our use of semantic versioning, I think. After, v1.0, it should be the case that: data published in conformance with a particular version of the standard will ALSO conform with future minor updates to the standard. So data published to v1.2 would also conform with v1.4.1 of the standard. There is a nice, work-in-progress description of what this means wrt the open contracting data standard.

It makes sense therefore to specify that in a BODS data release (= an array of BODS statements) all statements MUST have the same major version number. This is so that BODS-handling platforms can handle all statements in a release as if they conformed to the most recent BODS version referenced from a statement in the release. It also allows publishing platforms to adopt newer minor versions of BODS and publish to them, without having to convert or repackage older data.

[kd-ods]

This can be addressed by editing the bodsVersion field description to read:

The version of the Beneficial Ownership Data Standard to which this statement conforms, expressed as major.minor. For example: 0.2 or 1.0. In a published BODS dataset, all statements MUST have the same major version number.

And by editing the Serialization page of the docs to add:

The major version number in bodsVersion MUST be the same for all statements in the array.

[kd-ods]

Assigning to @kathryn-ods for the field description edit which can be picked up with #480

Assigning to me for the docs edit.

[kathryn-ods]

Edited the field in the #480 spreadsheet

[kd-ods]

Actually, we don't want to put the same normative requirements on the Serialization page and in the property description. We'll just put them in the property description.