open-contracting / european-union-support

Support scripts for TED mapping
BSD 3-Clause "New" or "Revised" License
9 stars 3 forks source link

Additional fields to proposed extension mapping #167

Closed duncandewhurst closed 1 year ago

duncandewhurst commented 1 year ago

I've mapped the additional OCDS fields reported by the lint command to extensions in a spreadsheet.

Most additional fields map to existing extensions. I've proposed new extensions for some fields.

@jpmckinney do you want to review the mapping and check that you're happy with it? In particular, whether any of the proposed new extensions can be bundled into the European Union extension

If you prefer not to review yet, we can move fields between extensions as needed as part of the PR review process. Either way, in the meantime, we can start working on updating extensions for which the mappings are clear.

cc @odscjen

jpmckinney commented 1 year ago

I think the new extensions related to 1.2 fields can perhaps be bundled into a "futures" extension. These are:

The following can probably go into the EU extension, as not yet sure whether they can be reused:

Then:

duncandewhurst commented 1 year ago

Sounds good! I've made those updates.

To avoid confusion with futures, I wonder if we should choose a different name for that extension. We could just call it the OCDS 1.2 extension or perhaps 'Future fields' would be sufficient.

odscjen commented 1 year ago

@jpmckinney we've mapped out the additional codes reported by the lint now as well, do you want to check that you're happy with these?

jpmckinney commented 1 year ago

To avoid confusion with futures, I wonder if we should choose a different name for that extension. We could just call it the OCDS 1.2 extension or perhaps 'Future fields' would be sufficient.

Maybe ocds_1_2_draft_extension, to clearly suggest it's not stable.

jpmckinney commented 1 year ago

@jpmckinney we've mapped out the additional codes reported by the lint now as well, do you want to check that you're happy with these?

Looks good. I left some comments. I assume some of the values in the "Additional code" column might change in our codelists, to match our style guide.

odscjen commented 1 year ago

I assume some of the values in the "Additional code" column might change in our codelists, to match our style guide.

I think the only ones that aren't currently changed in either a mapping table or the guidance are "vehicle-category" and "cvd-contract-type" both of which need added to the ClassificationScheme.csv. So yes it makes sense to change those types as that codelist will still link out to the originals and we'll update the guidance to use the OCDS style versions of these codes. Which I have now done.

odscjen commented 1 year ago

I realised the spreadsheet didn't contain any of the new codes that we've added to mapping tables so I've added a sheet in with that.

@duncandewhurst I added the new codes to the bottom of the Additional code mapping sheet but I couldn't work out how to get the Sustainability new codes to show up in the Summary by extension sheet?

duncandewhurst commented 1 year ago

Thanks! The new codes should be showing up in that sheet now. The issue was that the sustainability extension was identified by its URL in some sheets and by its name elsewhere.

odscjen commented 1 year ago

@jpmckinney just wanting to double check if we're still wanting to map documents.unofficialTranslation to the EU extension rather than the Documentation details extension? As an additional bit of information about a document it does feel like it would be a good fit to that extension unless we're sure the EU will be the only users of it?

jpmckinney commented 1 year ago

Documentation details sounds fine to me!

odscjen commented 1 year ago

great, thanks, I'll update the extension tracking spreadsheet and the guidance.yaml

duncandewhurst commented 1 year ago

I think that this issue can be closed now as we're using the spreadsheet to keep a track of authoring and updating extensions.