OCDS 1.2: What we’ll be working on

Two weeks ago, we kicked off development of the next minor release of the Open Contracting Data Standard, OCDS 1.2, and we explained what kinds of issues can be resolved in a minor release.

In this blog post, we’ll go into more detail on the priorities for OCDS 1.2.

Thematic priorities

All existing issues that can be resolved in a minor release have been collected into a milestone, and have been organized into themes on this board.

In our last update, we identified the major themes. We’ll expand on those here.

Semantic issues

Many terms in OCDS are defined from the perspective of single-stage procurement procedures. However, OCDS is intended to support two-stage procurement procedures, as well as other processes like design contests, public-private partnerships, and so on. The definitions need to be refined so that their meaning is clear in different contexts.

Notably, we will look at a few fundamental terms:

• “Contracting process”: What is the nature and boundary of a contracting process? For example: Are the specific contracts that result from a framework agreement part of the same process that established the framework agreement? If a procuring entity creates a supplier list of pre-qualified vendors for IT services, is that a contracting process?
• “Award”: Is an award an announcement, a decision, or a specific result of a procedure (which might include not concluding any contracts)? Does establishing a framework agreement with specific suppliers count as a specific result, or do only the specific contracts that result from a framework agreement count?
• “Contract”: There are many types of legal contracts in public contracting, and one contracting process might involve multiple types: contracts with definite and indefinite quantities, purchase orders, e-catalogue purchases, contracts establishing framework agreements, and so on. Which contracts belong in the contracts array in OCDS? Which contracts are better modeled as implementation details of those contracts (for example, purchase orders under a contact with definite quantities)?
• “Initiation type”: OCDS presently allows one initiation type, “tender,” which is itself poorly defined. What, if anything, should be the purpose of this field? Is it relevant to supporting a variety of contracting processes, like the sale of government assets?
• “Buyer”: Who is the buyer in a contracting process? What relationship does the buyer have to funding or benefiting from the procedure? Should the concept of a buyer be separable into more discrete roles?

Another major area of work is to compare OCDS’ definitions against others’ definitions, including:

• Glossary of procurement-related terms used in the 2011 UNCITRAL Model Law on Public Procurement
• Glossary of the eProcurement Ontology of the Publications Office of the European Union
• Definitions in the Revised Agreement on Government Procurement (GPA) of the World Trade Organization

Adding fields

There are several concepts to consider adding to OCDS that are common to multiple jurisdictions. These include new fields for:

• The details of a status, to supplement the codes used for the status of an opportunity, award or contract
• The date on which an opportunity was published
• The date on which a monetary value was set, to assist with currency conversion
• Links to non-OCDS data published by older or parallel systems, to assist in migrating between data formats
• The code for a country in an address, rather than its name, to ease identification and assist internationalization
• The value of a milestone, relevant to payment schedules
• Additional identifiers for plans, opportunities and contracts

Some broader issues include:

• Ensuring that the semantics of a field are not conditional on the values of other fields, and adding new fields if necessary;
• Considering which extensions to merge into OCDS, notably the division of a procedure into lots.
• Changing how specific events within a contracting process are communicated, for which the tag field is presently used

Finally, there are a few codes to consider deprecating, due to their being unclear or insufficiently distinct.

Packaging formats

With each version of OCDS, we consider how to make OCDS data easier to publish and use. The way in which OCDS data is packaged has been a common source of challenges and confusion, as we’ve learned from support requests to the OCDS Helpdesk and through our training program.

In OCDS 1.2, the following steps are being considered to simplify packages:

• Add a bulk data format, to make it easier to publish and use large JSON files using common tools such as
• Deprecate all package metadata fields, which includes the OCDS version and extension used, and links to data licenses and publication policies
• Move publisher identification from package metadata to individual releases, to identify the provenance of information
• Use JSON Schema’s $schema property for identifying the OCDS version and extensions used – which also enables better integration with JSON Schema tools

Other issues

OCDS data is checked for structural errors using schema files. We are considering a ‘strict’ version of the schema files, to allow publishers to opt-in to new checks, and thereby improve their data quality.

Extensions allow publishers to disclose more data than is covered by OCDS. The bids, enquiries, location, lots and participation fees extensions are versioned along with OCDS, and many specific changes to these extensions are being considered.

Finally, there are several issues for which we especially need further discussion, to better understand the specific issues and to assess support for different proposals, including:

• How multilingual content is published
• Whether to move other blocks to the top level, to reduce repetition
• How to correct earlier data by removing an entry from an array

How to contribute?

This marks the second step of the governance process, initiating a two-week period in which anyone can discuss whether to include issues that were left out, or remove issues that were added in, by 11 November.

The next step will be to solicit input on and propose solutions for the prioritized issues. To contribute to any of the topics listed above, please follow the hyperlinks to comment on the GitHub issue. We need expert input from the community of OCDS publishers and users to ensure that the proposed changes will improve the OCDS for everyone.

If you are new to GitHub, you can watch a recording of our introduction to GitHub, review the slides, use this handout, or read GitHub’s own documentation to create a username and password to add your comments and suggestions.

Over the coming months, we will organize calls to share progress and solicit input. To get updates throughout the OCDS 1.2 process, please subscribe to the standard-discuss mailing list.