Find a way to distinguish between fields which are and aren't part of the CoST IDS

[duncandewhurst]

In #154 we decided to hold fire on adding an extensions mechanism to OC4IDS until we see significant demand for additional fields.

In the meantime it would be helpful to be able to distinguish between fields which are needed to comply with the disclosure requirements of the CoST IDS and those which aren't, such as fields we add to the schema based on publisher demand.

Previously we discussed either including this information in the field description, or in another property in each field's definition.

Related issue: CRM-5904

[jpmckinney]

For the CoST IDS reactive disclosure section, I think it makes sense to add fields to OC4IDS itself, rather than create extensions.

The OCDS experience with extensions from my perspective is:

1. There is a high cost to discovery.
   • While improvements can be made to the Extension Explorer, my hypothesis is that there'd be greater adoption of commonly-needed extensions if they were simply part of OCDS.
2. Extensions appear out of context.
   • If included in the standard, the fields can be viewed and documented in the context of other relevant fields. In extensions, that context needs to be re-built.
3. The existence of the extension mechanism suggests to publishers that they have license to add and document new fields without engaging in the standard development process.
   • The desired behavior is for publishers to open issues in the standard repository, to aggregate demand and discuss modelling with OCP and the wider community. Not all do.
4. The ambiguous normative status of extensions suggests to publishers that they can author a new extension if no existing extension perfectly suits their needs.
   • While we try to limit overlap between registered extensions, we don't police local extensions; this leads to a lack of standardization.

The above creates a greater need for helpdesk support to overcome these issues.

There's a discussion here about the (retrospective) decision for OCP to author extensions to OCDS. I don't think the same rationales hold as strongly for OC4IDS (and we might want to reconsider the rationales for OCDS).

We still want to allow publishers to author extensions for fields they add for which there is insufficient demand, and as a means to disclose data while the standardization process is in progress.

However, for the reasons above, I think OCP and CoST should add fields to OC4IDs rather than create their own extensions.

[duncandewhurst]

Thanks @jpmckinney I am happy with that approach for OC4IDS.

Once we have expanded the CoST IDS mapping table in the OC4IDS documentation to include the reactive discIosure items, implementers who are interested in complying with the CoST IDS can use the table to check which OC4IDS fields are recommended for disclosure in the proactive section of the CoST IDS, the reactive section or neither.

I think we can then wait and see if there is demand for checking the coverage of published data against the CoST IDS, in which case we can look at encoding this information in the schema.

@EvelynDinora - does that sound good to you?

[jpmckinney]

Noting that Schema.org decided against extensions after trying two mechanisms: https://schema.org/docs/extension.html

cc @stevenday (apologies for later unrelated notifications, but I think you can unsubscribe if so :))

[ColinMaudry]

There is a high cost to discovery

I think a field database bound to a multilingual glossary of terms would greatly help. Fields could be tagged and categorized according to various properties such as:

• OCDS version compatibility
• core or extension
• update date

Full text search would enable discovery via keywords... especially if synonyms are documented in the glossary for keyword equivalency!

With the EU extensions alone, I think a similar tool would greatly increase the visibility of the semantics and structures available for OCDS adopters.

[duncandewhurst]

I think this issue can be closed in favour of encoding the relationship between the CoST IDS and OC4IDS fields in the mapping CSVs: #311.