Map

This phase is about documenting your sources of contracting data, and documenting how that data “maps” to OCDS – that is, identifying which data elements within your data sources match which OCDS fields and codes. The mapping phase is one of the longest and most important steps in the implementation process.

Mapping data to OCDS is not always easy. Before writing any software, this phase is an opportunity to:

The documentation you produce can also later be included in your Data User Guide.

As you make progress through this phase, we encourage you to update your publication plan, in order to help set priorities and ease communication within your team, with your stakeholders, and with the OCDS Helpdesk. You can start by filling in the Goals (design) section.

Involve the right people

As described in the Field-Level Mapping Template Guidance (introduced below), you will need at least:

  • A technical expert who is familiar with the IT systems that capture and store contracting data and related documents, to identify the data elements within those systems.

  • A policy expert who is familiar with procurement legislation and procurement processes, to help identify which data elements match which OCDS fields, at a semantic level.

  • A technical expert who understands the data structures in OCDS, to help identify which data elements match which OCDS fields, at a technical level.

Identify your data sources

To implement OCDS you need to first identify which IT systems capture and store contracting data and related documents. You also need to identify how to connect data held in different systems, to get a complete picture of the contracting process. The Technical Assessment Template guides you through this process.

Once complete, you can:

  • Ask the OCDS Helpdesk to review your Technical Assessment.

  • Fill in the Source systems sub-section of your Publication Plan.

  • Fill in the Systems sheet of your Field-Level Mapping (introduced below).

Map your data to OCDS

To make this step easier we provide templates to list the data elements within your data sources, and map them to either:

Mapping organization identifiers

Organization identifiers in OCDS are made up of two parts:

  • An org-id code, identifying the register from the which the identifier is drawn

  • The identifier for the organization, drawn from the register

The organization identifiers worked example shows how this works in practice.

Use org-id.guide to find the code for the register your identifiers are drawn from. If no code exists for the register, contact the OCDS Helpdesk.

Working in parallel

Working in parallel on the map and build phases can be useful, because the choices you make at the build stage might affect how you need to map your data. For example, your choice of architecture might determine whether you are able to publish a change history using releases and records.

Splitting up the work

You can complete this step in parts. For example, you might choose to split your mapping by any of the following:

  • data source (e-procurement system, contract management system, financial management information system, etc.)

  • contracting process type (open procedure, selective procedure, concession contract, framework agreement, etc.)

  • contracting process stage (planning, tender, award, contract, implementation)

  • public notice (tender notice, award notice, etc.)

The preferred approach is to eventually list all the data elements within your data sources in your Field-Level Mapping, decide whether to publish each, and then map each. The decision to publish a data element is up to you; it isn’t necessary to map all your contracting data.

It is also important to focus on the data elements whose disclosure was prioritized by users during the design phase. If you have not determined which data elements are a priority, you ought to do this now, based on your user needs.

Whichever approach you take, it’s important that your eventual OCDS publication contain at least as much information as your other public datasets of contracting data; otherwise, users are less likely to use your OCDS publication.

Extensions

Some data elements might not match any field or code in OCDS. To cover such cases, you can add fields and codes to OCDS using extensions.

Resource: Localizing OCDS: Translations, Terminology & Extensions

Resource: What to do when fields don’t map?

Resource OCDS Glossary

Action: Contact the OCDS Helpdesk to get help with mapping data or authoring extensions.

Action: If you are stuck on a particular concept and are concerned about how it is modelled in OCDS, search the issues in our Github tracker to see what others in the community are saying about the topic. If you do not see your issue, create a new one!

Wrapping up

Once complete, you can:

  • Fill in the Priority data (map) and Priority documents sections of your Publication Plan.

  • Ask the OCDS Helpdesk to review your Field-Level Mapping and Publication Plan.

Next phase: Build