Designing data around user needs

The Open Contract ing Data Standard

1

overview

● An introduct ion to open contract ing and OCDS

● Mapping, extensions and serializat ions

● Designing around user needs ○ Fields ○ Contents ○ Packaging & presentat ion

2

what is open contract ing?

3

what is OCDS?

✔ A model for providing joined up informat ion on all stages of the cont ract ing process (planning to implementat ion)

✔ An open schema based on JSON schema - updated through a mult i-stakeholder governance process

✔ Designed around user need and global interoperability

✔ An act ive user community, building tools, extensions and applicat ions

✔ A developing data quality framework - and free help-desk service to support data validat ion

4

a brief history

OCDS was developed based on analysis of supply and demand for contract ing data.

The data published from procurement systems was often not aligned with what users wanted, or the meaning of fields was unclear (e.g. ‘value’).

The design of the standard aims to maximise the number of user needs met from the same dataset.

Example visualisation from http://ocds.open-contracting.org/opendatacomparison/ created during the development of OCDS (2013/14) to map relative coverage of data elements by different existing datasets.

5

OCDS around the world today

6

standard, schema and guidance

✔ A standard for what to publish and how to publish it as open data; Focusing on what users need.

✔ A data schema for validat ion of published data; Ensuring the technical interoperability of data.

✔ Collected guidance on publishing and using data; To maximise effective use.

7

Mapping, extensions and serializat ion

8

mapping

Source system

s U

ser n

eeds

9

extensions

A library of exist ing extensions that provide addit ional fields and data structures.

A process for creat ing new extensions: engaging with potent ial users, and other suppliers, of this kind of data.

A technical model support ing validat ion and interpretat ion of data

10

serializat ion

Contract ing data is complex

→ we use nested (one-many) data structures

Many use cases need simple data

→ we support simple serializat ions of data

11

OCDS validator

12

summary

● Mapping uses the OCDS to support discussion of data supply, and user needs: priorit ising data collect ion and publicat ion

● Extensions can be used to represent addit ional important fields of data

● Different serializat ions may be important for different users

13

Designing around user needs

14

Worked examples

Procurement monitoring

Business intelligence and report ing;

Trade agreement report ing.

15

objects and fields

Procurement monitoring

Business intelligence and report ing

Trade agreement report ing

buyer identity | budget values | award values | key dates

supplier identity | supplier country of origin | item classifications | tender process details

contract process identifier | planning | tender | award | contract | implementation

16

contents

Procurement monitoring

Business intelligence and report ing

Trade agreement report ing

A buyer identifier that can be cross-mapped to budget

Organisation identifiers that reveal country of registration

Clear tender description text; Exact coordinates for delivery location.

17

packaging and presentat ion

Procurement monitoring

Business intelligence and report ing

Trade agreement report ing

Daily JSON and CSV export → loaded into dashboard tool

Queryable API with JSON and CSV output

JSON releases (for tracking change); Bulk CSV download of key details; Feed of updates

18

Recap

19

summary

● Different users have different data needs

● Standards give a head-start for meet ing many needs

● Engaging with users helps priorit ise the detail and presentat ion of data

● OCDS has mapping tools, extensions and mult iple serializat ions to support creat ion of usable data

20

Quest ions?

21