From 84e7a9ef40e8199e52cbf83006915d20a41395b8 Mon Sep 17 00:00:00 2001 From: odscjen Date: Mon, 18 Nov 2024 10:30:04 +0000 Subject: [PATCH] release-schema: update tag description and reference doc --- docs/guidance/map/contracting_planning_processes.md | 2 +- docs/schema/reference.md | 12 +++++++++++- schema/dereferenced-release-schema.json | 2 +- schema/release-schema.json | 2 +- 4 files changed, 14 insertions(+), 4 deletions(-) diff --git a/docs/guidance/map/contracting_planning_processes.md b/docs/guidance/map/contracting_planning_processes.md index 0ab6e8af1..4024c01cf 100644 --- a/docs/guidance/map/contracting_planning_processes.md +++ b/docs/guidance/map/contracting_planning_processes.md @@ -24,7 +24,7 @@ OCDS defines a planning process as: ![Contracting Process](../../_static/png/contracting_process.png) -A planning process ought to have its `releaseTag` set to 'planning' (or 'planningUpdate'). A contracting process can have `releaseTag` set to [any other value from the codelist](../../schema/codelists.md#release-tag). A planning process should not contain the `releaseTag` 'tender' even if it contains a `tender` object. The two processes ought to be linked together using the `relatedProcesses` array in the releases for the contracting process, with the 'planning' code in the related process' `relationship` array. +A planning process needs to have 'planning' (or 'planningUpdate') added to its `tag` array. A contracting process can have [any other value from the codelist](../../schema/codelists.md#release-tag) in its `tag` array. A planning process must not contain the code 'tender' in its `tag` array even if it contains a `tender` object. The two processes ought to be linked together using the `relatedProcesses` array in the releases for the contracting process, with the 'planning' code in the related process' `relationship` array. ```{note} We recommend publishing data about planning and contracting processes under separate `ocid`s, following the definitions above. That said, publications that combine planning and contracting data under a single `ocid` remain conformant in OCDS 1.2. A required separation can be considered for OCDS 2.0. diff --git a/docs/schema/reference.md b/docs/schema/reference.md index af0be2b9c..ee7303a4b 100644 --- a/docs/schema/reference.md +++ b/docs/schema/reference.md @@ -16,7 +16,7 @@ This page presents the release schema in tables, with additional information in ## Contracting and planning processes -OCDS recognizes two types of processes: contracting processes and planning processes. In OCDS, a given process is uniquely identified by an [open contracting process identifier](identifiers.md#open-contracting-process-identifier-ocid) (`ocid`). +OCDS recognizes two types of processes: contracting processes and planning processes. OCDS defines a contracting process as: @@ -34,6 +34,16 @@ OCDS defines a planning process as: > > Planning processes are often less structured than contracting processes, so one or more planning processes may lead to one or more contracting processes. +Planning and contracting processes should be linked using the [`relatedProcesses`](#relatedprocess) array. + +```{note} +We recommend publishing data about planning and contracting processes under separate `ocid`s, following the definitions above. That said, publications that combine planning and contracting data under a single `ocid` remain conformant in OCDS 1.2. A required separation can be considered for OCDS 2.0. +``` + +```{note} +In OCDS 1.2 and earlier, it is not possible to publish all information about multi-stage procedures under a single `ocid`. There is guidance on how to deal with this for [framework agreements](../guidance/map/framework_agreements) and for [pre-qualification and pre-selection](../guidance/map/pre-qualification). If you want to disclose this type of information (including other types of multi-stage procedures, such as competitive dialogues and innovation partnerships), [contact the Data Support Team](../../support/index). The approach to modelling multi-stage procedures in a future, backwards-incompatible version of the standard is under discussion on [GitHub](https://github.com/open-contracting/standard/issues/440). +``` + ## Release handling The full OCDS data model is based on the idea of publishing a new release every time information about a [contracting (or planning) process](#contracting-and-planning-processes) changes. This way, users can gain a full view of change over time, and third-parties can understand what needs to be updated in any system that is tracking the progress of a contracting (or planning) process. diff --git a/schema/dereferenced-release-schema.json b/schema/dereferenced-release-schema.json index f71c5592f..d0a1767c0 100644 --- a/schema/dereferenced-release-schema.json +++ b/schema/dereferenced-release-schema.json @@ -69,7 +69,7 @@ }, "tag": { "title": "Release Tag", - "description": "A tag labeling the release, using the the open [releaseTag](https://standard.open-contracting.org/{{version}}/{{lang}}/schema/codelists/#release-tag) codelist. Tags distinguish, for example, planning and contracting processes and the stages of contracting processes. Codes outside the releaseTag codelist might indicate, for example, the notice or form to which the release corresponds, or the event that triggered the publication of the release. Planning processes must not use the 'tender' code, even if they use `tender` fields.", + "description": "A tag labeling the release, using the the open [releaseTag](https://standard.open-contracting.org/{{version}}/{{lang}}/schema/codelists/#release-tag) codelist. Tags distinguish, for example, planning and contracting processes and the stages of contracting processes. Codes outside the releaseTag codelist may indicate, for example, the notice or form to which the release corresponds, or the event that triggered the publication of the release. A planning process must use either the 'planning' or 'planningUpdate' code, and must not use any other code from the releaseTag codelist. A contracting process should not use the 'planning' or 'planningUpdate' codes.", "type": "array", "items": { "type": "string" diff --git a/schema/release-schema.json b/schema/release-schema.json index 46f3ea6d8..efb5b1d78 100644 --- a/schema/release-schema.json +++ b/schema/release-schema.json @@ -33,7 +33,7 @@ }, "tag": { "title": "Release Tag", - "description": "A tag labeling the release, using the the open [releaseTag](https://standard.open-contracting.org/{{version}}/{{lang}}/schema/codelists/#release-tag) codelist. Tags distinguish, for example, planning and contracting processes and the stages of contracting processes. Codes outside the releaseTag codelist might indicate, for example, the notice or form to which the release corresponds, or the event that triggered the publication of the release. Planning processes must not use the 'tender' code, even if they use `tender` fields.", + "description": "A tag labeling the release, using the the open [releaseTag](https://standard.open-contracting.org/{{version}}/{{lang}}/schema/codelists/#release-tag) codelist. Tags distinguish, for example, planning and contracting processes and the stages of contracting processes. Codes outside the releaseTag codelist may indicate, for example, the notice or form to which the release corresponds, or the event that triggered the publication of the release. A planning process must use either the 'planning' or 'planningUpdate' code, and must not use any other code from the releaseTag codelist. A contracting process should not use the 'planning' or 'planningUpdate' codes.", "type": "array", "items": { "type": "string"