1 of 34

Getting started with OCDS publication

July 2020

2 of 34

Getting started

Discuss the key users and use cases for your OCDS project
Identify the data and documents you will publish from your contracting process
Map your data against the OCDS building blocks
Present the data in JSON releases and records
Publish your data on the web using the publication patterns
Check the validation of your data
Encourage and facilitate stakeholder use of the data

3 of 34

OCDS: the basics

4 of 34

OPEN

CONTRACTING

DATA

STANDARD

5 of 34

OPEN

CONTRACTING

DATA

STANDARD

6 of 34

OPEN

CONTRACTING

DATA

STANDARD

7 of 34

Schema

Documentation

Governance

+

Technical schema documentation

Implementation guidance

OCDS components

8 of 34

https://standard.open-contracting.org/1.1.5-dev/en/getting_started/

9 of 34

The procurement process

Planning

Tender

Award

Implementation

Contract

OCDS is about describing procurement processes:

Definition:

All the planning, tendering information, awards, contracts and contract implementation information related to a single initiation process.

10 of 34

The procurement process�Open Contracting Data Standard

Planning

Tender

Award

Implementation

Contract

Unique identifier

to track the full process

11 of 34

OCDS: the data

12 of 34

✔

The only thing that can be truly called ‘OCDS data’ is a JSON document that validates against the official OCDS schema.

What is OCDS data?

13 of 34

Quality

Assurance

checks

evaluation

compliance

tools

automation

Reuseable

Tools

visualization

checks

analysis

exploration

conversion

Publisher and user guidance

documentation

schema

formats

templates

support

Comparable Data

research

analysis

fraud detection

value for money

International standard

best practice

sharing

community

learning

Why use OCDS?

14 of 34

Often very limited data on contracting
Contracting data published but only about one stage
Difficult to join up data from different stages of the contracting process
Published data is hard to interpret
Mismatch between the data governments publish and the data users need

What problems was OCDS developed to address?

Whilst some contracting data is already published, there are some common blockers to using that data to understand public contracting in many countries:

Contracting processes in some countries still take place on paper and some governments have no central source of contracting data�
Some governments publish data but only about tenders or only about awards and very few governments publish data on implementation�
In many countries linking data between tenders and awards is difficult and harder still to join up planning and implementation data�
The meaning of fields in published data is unclear, e.g. do values relate to the tender or award, where are company numbers drawn from�
Data is published based on what’s available or what was included on historic paper notices, rather than on what users of contracting data need

15 of 34

OCDS connects supply and demand by:

Proving a ready made data model based on user needs�
Supporting implementations that contain ‘feedback loops’ between publishers and users

How does OCDS address those problems?

OCDS is about connecting up data publishers and data users to create feedback - ultimately resulting in positive change in public contracting.

Governments might tend to focus on a specific problem or use case when deciding what contracting data to publish and how to publish it.

OCDS tries to address a broad range of problems and user needs, it does the thinking for governments in terms of how to structure data and publish data in a way that encourages use and provides a set of recommended information to disclose across the whole contracting process.

It’s not just about the structure and content of the data standard though, through supporting governments to publish OCDS we promote engagement with users, feedback loops and iterative development, to ensure contracting data is useful, useable and in use.

16 of 34

OCDS was designed around four distinct use cases:��


Value for money	Detecting fraud and corruption	Competing for contracts	Monitoring service delivery

What are the uses of OCDS data?

Regardless of which use case is most important to you, OCDS was designed to meet a broad spectrum of user needs, including:

Understanding value for money - achieving better value for money in new contracts and understanding the value achieved in previous contracts.�
Detecting fraud and corruption - OCDS data can be used to scrutinize procurement documents and data for ‘red flags’ that might indicate public monies are being misused�
Competing for contracts - OCDS data can be used by private firms to understand the potential pipeline of procurement opportunities and more competition results in better value for money too.�
Monitoring service delivery - monitoring groups want to ensure that public contracting delivers value to citizens in terms of quality of goods, works, and services provided and OCDS data can be used to join up data on budgets, contracts and implementation.

And we often talk of a 5th use case - improving internal efficiency

17 of 34

Different fields
Different documents
Different publication frequencies
Different data quantities

OCDS provides a common framework to maximise the number of user needs that can be met with data and document disclosure.

Each use case has different data needs:

18 of 34

use cases: essential features

Even though each use case has different data needs, the following features are essential to get the benefits of OCDS data:�

Unique identifiers
Globally unique ocid
ocid prefix
Codelists

Even though each use case has different data needs, the following features are essential to get the benefits of OCDS data:

Unique identifiers - for example, organization identifiers are important to know who is involved in each contracting process
Globally unique ocid - globally unique identifier for a contracting process. It can be used to join up information published at different stages of a contracting process and is unique across the whole universe of OCDS publishers.
ocid prefix - these prefixes are randomly generated lowercase alpha-numeric strings. A unique prefix is assigned to each OCDS publisher to make sure that they are globally unique across all publishers. Currently, publishers register prefixes with the OCDS Helpdesk purely with the aim of keeping it easy for the publishers to obtain a unique prefix and to keep a single centralised repository of all prefixes. They are randomly generated. These registered prefixes are dumb identifiers, meaning that they are not intended to carry any semantics, and their sole purpose is to turn internal identifiers into globally unique identifiers which can be cross-referenced between systems.
Codelists - are suggested or mandatory codes for certain OCDS fields. Oftentimes local value for certain fields need to be mapped to OCDS codelists to ensure interoperability and consistency of data across different publishers.

The Open Contracting Data Standard helpdesk provide a technical assessment template that can be used to identify the different systems involved in managing data on each stage of the contracting process.

19 of 34

OCDS building blocks

20 of 34

The schema provides:

the authoritative definition of each field in OCDS
how OCDS data should be structured
how each field should be formatted

The OCDS schema

21 of 34

Sections and structures

An OCDS document is made up of a number of sections. These are:

release metadata - contextual information about each release of data;

parties - information about the organizations and other participants involved in the contracting process;
planning - information about the goals, budgets and projects a contracting process relates to;
tender - information about how a tender will take place, or has taken place;
awards - information on awards made as part of a contracting process;
contract - information on contracts signed as part of a contracting process;

implementation - information on the progress of each contract towards completion

These are represented in a JSON document as follows.

Extensions

In some cases, publishers or users need building blocks and fields which are not provided in the core OCDS schema.

We maintain a list of extensions that provide additional building blocks and fields.

22 of 34

OCDS releases and records

23 of 34

The release and records model

24 of 34

Releases

25 of 34

Records

Records are JSON documents that act as an index of all releases for a single contracting process. While releases are never updated, records are updated each time there is a change. A record is updated by adding a new release to this index.

Records can also contain:

A compiled release, which uses the same structure as an OCDS release. It represents the latest state of each field.

A versioned release, that contains a history of changes for each individual field.

These structures are designed to help users to access:

The current state of the contracting process

The detailed history of changes for individual fields

In accounting terms, releases are analogous to individual transactions in an account. A record represents both the ledger of all transactions and the closing balance. The ledger is the releases list, and the closing balance is the compiled release.

26 of 34

Publication patterns

When publishing releases and records, they need to be provided within a release package or record package. These act as an envelope for the data.

A package provides information on:

Where the data can be accessed (a URI)
The publisher of the data
The date of publication
The license the data is provided under
Links to a publication policy and further documentation

A package can contain one or more releases or records.

Consult the release package and record package schemas to package up your data.

Bulk and individual files

You are encouraged to:

Ensure all documents referenced in OCDS releases are available online;

Publish each release and record at its own persistent URL;

Additionally, produce bulk packages of releases and records for users to download;

Additionally, produce ‘flat’ versions of the data for users to access in CSV for Excel formats

You will need to make decisions about how to segment the data in bulk files, so that files are easy for users to work with.

27 of 34

OCDS: the bigger picture

28 of 34

OCDS data is important...

‘OCDS inside’

Joined up data across the whole contracting process�
Data supports many use cases�
The meaning of each field is clear

29 of 34

...but it’s just the foundation

OCDS is ‘inside’, on the ‘outside’ we need:

Interfaces�
Tools�
Services�
Engagement with users

30 of 34

Open Contracting and OCDS

OCDS provides a mechanism to disclose contracting data and documents to support analysis, monitoring and engagement around public contracting.

31 of 34

OCDS tools

32 of 34

OCDS Data Review Tool

http://standard.open-contracting.org/review/

OCP provides a Data Review Tool

“buyer”: {

“name”: “ABCDEF123”,

…

“items”: [{

“description”: “n/a”,

✓

structurally correct

You can validate your OCDS documents at standard.open-contracting.org/review/.

This tool will help you to check whether the JSON files you are producing are technically valid. The Data Review Tool provides technical check of format and structure of data for compliance with schema.

Structural checks are important for interoperability, without which data cannot be compared and tools cannot be reused

Structural checks do not include checks for meaningless or missing data (so other aspects such as data conformance, completeness and utility also need to be considered).

However, this is just one step of checking your data. The OCDS helpdesk team can provide additional support to check the quality of the data you are producing, and to check for other common errors and omissions.

We also have a tools directory where you can find all of the resources mentioned during the webianr https://www.open-contracting.org/resources/#data-tool

33 of 34

OCDS Helpdesk

Global support from UK and Latin America based helpdesks
Draft bespoke scoping notes
Facilitate conceptual understanding
Assist in system and field level mapping
Discuss extension requirements
Provide feedback on draft files
Offer support for structural checks
Produce evaluation reports and feedback

34 of 34

Questions?