Additional check: Party organization references resolve

[duncandewhurst]

Looking at some draft data from a publisher recently I noticed that they had omitted the parties section from the data, whilst still providing organization references in buyer, award/suppliers etc.

It would be good to a check to CoVE to address this, i.e. for any organizationReference check that:

1. There is a corresponding entry in the parties section
2. An appropriate value is used in parties/role, based on where the organization is referenced from

[pindec]

+1 for this.

I noticed a bit late that a publisher had organization references in buyer, but no parties section.

Would be very helpful to have CoVE flag it up.

[jpmckinney]

On today's call, this was mentioned as a candidate for the Apr-May 2019 sprint.

[jpmckinney]

Right now the docs state "Each of the parties (organizations or other participants) referenced in a release must be included in the parties section."

In norms review spreadsheet, it was noted about this that: "Need to be clear on whether the parties section must be populated in the same release, or just in at least one release with the same ocid"

I don't see a lot of value in forcing the repetition of a (potentially large) party object in every release that has an OrganizationReference to that party. Whether we perform this check on each release or only on a compiled release depends on what we think the rule ought to be.

[duncandewhurst]

We should also consider that most publishers don't publish a full change history or records/compiled releases, instead they publish a single release per contracting process, updating it when information about the contracting process changes (and hopefully updating the release identifier too.)

In which case, the party information should (and likely would) be repeated each time the release is updated, since historic releases aren't available, so the information would otherwise be lost for any users which don't regularly scrape the data.

So even if the rule is only that the parties section must be populated in at least one release with the same ocid, then we should:

• Provide guidance in the documentation for publishers using the model described above (explaining they should repeat the information)

• Perform the check on individual releases, but with feedback to the user to address both cases, e.g.

We found an organization reference without an associated entry in the parties section, if you are publishing a full change history using OCDS releases then the parties section must be populated in at least one release with the same ocid, however if you are publishing only one release per contracting process then the parties section should be populated in this release.

[jpmckinney]

This is perhaps becoming an OCDS documentation issue ;) but we have 'updating a single release file' as a priority example for 1.1.5, where we can explain that data shouldn't be removed in general (including parties) when updating that single file.