diff --git a/docs/_static/png/contracting_process.png b/docs/_static/png/contracting_process.png index 9ba64dfe1..7c4fd3aee 100644 Binary files a/docs/_static/png/contracting_process.png and b/docs/_static/png/contracting_process.png differ diff --git a/docs/getting_started/quality.md b/docs/getting_started/quality.md index 1d6c2822c..cff6a937c 100644 --- a/docs/getting_started/quality.md +++ b/docs/getting_started/quality.md @@ -29,7 +29,7 @@ Understanding all of the challenges above, we understand that increasing the tra All OCDS publications ought to meet the following criteria: -1. **Registered**: The data uses a [registered OCID prefix](../schema/identifiers.md#contracting-process-identifier-ocid). +1. **Registered**: The data uses a [registered OCID prefix](../schema/identifiers.md#open-contracting-process-identifier-ocid). 1. **Discoverable**: It is possible to discover the data by navigating a website whose homepage is indexed by popular web search engines. 1. **Retrievable**: It is possible to automate the download of all the data, either using an HTML page listing bulk download URLs, or using only machine-readable data as input. 1. **Reviewable**: The [OCDS Data Review Tool](https://standard.open-contracting.org/review/) is able to report results on the data. diff --git a/docs/getting_started/releases_and_records.md b/docs/getting_started/releases_and_records.md index beb80e336..d2d1e8083 100644 --- a/docs/getting_started/releases_and_records.md +++ b/docs/getting_started/releases_and_records.md @@ -47,7 +47,7 @@ Releases follow the [release schema](../schema/reference). The schema covers the #### Identifiers -Each release contains an [ocid](../schema/identifiers.md#contracting-process-identifier-ocid) to identify the contracting process it relates to. An ocid is composed of a prefix and an unique process identifier chosen by the publisher. +Each release contains an [ocid](../schema/identifiers.md#open-contracting-process-identifier-ocid) to identify the contracting process it relates to. An ocid is composed of a prefix and an unique process identifier chosen by the publisher. A release also needs a release identifier, unique in the scope of the contracting process. A release id can be built in several ways. Publishers can use any generation strategy, as long as the ids don’t collide within the same process. diff --git a/docs/guidance/build.md b/docs/guidance/build.md index 50aa8c2fe..8190360ee 100644 --- a/docs/guidance/build.md +++ b/docs/guidance/build.md @@ -16,7 +16,7 @@ As you complete this phase, you can: ## Register an OCID prefix -The [identifiers](../../schema/identifiers) reference page describes the contracting process identifier (`ocid`) and how ocid prefixes are used to ensure `ocid`s are globally unique. +The [identifiers](../../schema/identifiers) reference page describes the open contracting process identifier (`ocid`) and how ocid prefixes are used to ensure `ocid`s are globally unique. To publish OCDS data, you need to register an ocid prefix. diff --git a/docs/guidance/build/change_history.md b/docs/guidance/build/change_history.md index ca81addb1..37f0b7f0a 100644 --- a/docs/guidance/build/change_history.md +++ b/docs/guidance/build/change_history.md @@ -128,7 +128,7 @@ So far, the council used a single procurement system to manage the process. The The council now uses a separate financial system to manage payments. The financial system publishes the new OCDS release. -The procurement system and the financial system share a common contracting process identifier. This means that the two systems can publish releases using the same `ocid`. +The procurement system and the financial system share a common identifier for contracting processes. This means that the two systems can publish releases using the same `ocid`. The new release uses the 'implementation' tag. The `contracts.implementation.transactions` section includes the details of the payment. diff --git a/docs/guidance/build/hosting.md b/docs/guidance/build/hosting.md index 97c512439..4acce1e5a 100644 --- a/docs/guidance/build/hosting.md +++ b/docs/guidance/build/hosting.md @@ -34,9 +34,9 @@ When the suggested limits entail publication of multiple files, publishers ought For releases, publishers can: 1. Segment by **release date** - placing all the releases from a given day, month or year in the same file; -1. Segment by **contracting process identifier** - placing all the releases related to a given set of contract process identifiers together in the same package; +1. Segment by **open contracting process identifier** - placing all the releases related to a given set of process identifiers together in the same package; -For records, publishers can segment by the first **release date** associated with a contracting process, or by **contracting process identifier.** +For records, publishers can segment by the first **release date** associated with a contracting process, or by **open contracting process identifier.** Following these approaches will avoid release and records 'jumping' between files when the bulk files are updated. diff --git a/docs/guidance/map.md b/docs/guidance/map.md index 8b2998e52..750db2e25 100644 --- a/docs/guidance/map.md +++ b/docs/guidance/map.md @@ -80,6 +80,7 @@ Mapping data to OCDS is not always obvious. Please refer to our how-to guides an :maxdepth: 2 :titlesonly: +map/contracting_planning_processes map/unsuccessful_processes map/related_processes map/pre-qualification diff --git a/docs/guidance/map/contracting_planning_processes.md b/docs/guidance/map/contracting_planning_processes.md new file mode 100644 index 000000000..289f4416b --- /dev/null +++ b/docs/guidance/map/contracting_planning_processes.md @@ -0,0 +1,29 @@ +# Contracting processes 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](../../schema/identifiers.md#open-contracting-process-identifier-ocid) (`ocid`). This section helps map your contracting activities (most often procurement procedures) to their OCDS representation. + +OCDS defines a contracting process as: + +> All the actions aimed at implementing one or more contracts. This covers tendering, awarding, contracting and implementation. It does not include actions linked to planning, as these are often less structured and may be linked to multiple contracting processes. In multiple stage procedures (e.g. framework agreements with reopening of competition), each round of competition is treated as a separate contracting process. + +> Procedures that failed and were restarted are considered new processes. + +> Boundaries between processes (e.g. whether two contracts result from a single process or from two processes) are set by buyers depending on their needs (e.g. efficient division of labor, clear communication with the market) and legislation (e.g. rules on using procedures and lots). + +OCDS defines a planning process as: + +> All the actions aimed at planning one or more contracting processes. This covers, for example, establishing the rationale for the procurement, giving the market a general description of the purchase, getting the necessary budget, forecasting and conducting market research. + +> Planning processes are often less structured than contracting processes, so one or more planning processes may lead to one or more contracting processes. + +![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. + +```{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](related_processes) and for [pre-qualification and pre-selection](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 OCDS Helpdesk](../../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). +``` diff --git a/docs/guidance/map/pre-qualification.md b/docs/guidance/map/pre-qualification.md index d7799772f..1d01b668a 100644 --- a/docs/guidance/map/pre-qualification.md +++ b/docs/guidance/map/pre-qualification.md @@ -1,4 +1,4 @@ -# Pre-qualification and pre-selection +# Processes with pre-qualification and pre-selection In single-stage procedures, procuring entities invite suppliers to bid without submitting any prior information. Such procedures are straightforward to model in OCDS. diff --git a/docs/guidance/map/related_processes.md b/docs/guidance/map/related_processes.md index d44eb0403..b23347ab9 100644 --- a/docs/guidance/map/related_processes.md +++ b/docs/guidance/map/related_processes.md @@ -54,10 +54,7 @@ In OCDS, a contracting process brings together, under a single identifier, the i * What was the total value of spending that resulted from this award? * Was a renewal of this contract signed? -In some cases, complex contracting processes cannot be represented under a single identifier under OCDS' model, because: - -* There are multiple competitive stages: for example, when a framework agreement involves second-stage competitions. -* The procurement systems used at different stages of the process are managed by different bodies, and cannot be integrated. +In some cases, complex contracting processes cannot be represented under a single identifier, because there are multiple stages. For example, this is the case when a framework is set up, and then mini-competitions are used for purchases from the framework. OCDS models the first and second stages of framework agreement procedures as separate contracting processes, linked together using the `relatedProcesses` array. The `tender.techniques.hasFrameworkAgreement` field, from the [Techniques](https://extensions.open-contracting.org/en/extensions/techniques/master/) extension, is used to identify contracting processes that represent the first stage of a framework agreement procedure. The presence of a related process with a `.relationship` set to 'framework' is used to identify contracting processes that represent the second stage of a framework agreement procedure. diff --git a/docs/guidance/map/unsuccessful_processes.md b/docs/guidance/map/unsuccessful_processes.md index f926e2c5e..6b182ea16 100644 --- a/docs/guidance/map/unsuccessful_processes.md +++ b/docs/guidance/map/unsuccessful_processes.md @@ -1,22 +1,8 @@ # Unsuccessful processes -In the case of procurement, a contracting process can be defined as a procurement procedure. There is a one-to-one correspondence between the first stage of a procurement procedure (tender) and a contracting process. - -In OCDS, at a conceptual level, a contracting process is intended to match each concrete attempt to start a procedure that leads to one or more contracts. Attempts can include: an invitation to tender (in open procedure); an invitation to request to participate; a competition for a concession; a direct award, etc. - -![Contracting Process](../../_static/png/contracting_process.png) - -In OCDS, the `ocid` is the unique identifier for a contracting process. As the initiation of the procurement process is the tender, normally the identifier for a tender can be used as the `ocid`. - In most jurisdictions, if a procedure is cancelled or unsuccessful, and a **new procedure** is started to procure the same items, the two procedures are considered two **different** contracting processes. This is in keeping with the OCDS definition of a contracting process. -But in other jurisdictions, such as Paraguay, the planning stage is considered as the initiation of the process. In these jurisdictions when a tender fails and a new tender is started, the two tenders are considered part of the same contracting process. This differs from the OCDS definition of a contracting process. - -In OCDS, it is relevant and desirable to include the planning information that relates to the process, but the contracting process is not interpreted as ‘starting’ with the planning stage. In OCDS, the planning stage is something that comes **before** the initiation of a contracting process. The initiation of the procedure is not the planning stage, because at least one of the following is true of a planning stage: it is not a concrete attempt to award one or more contracts like a request for tender, etc.; it is not a concrete opportunity for potential suppliers to participate in; it does not describe the competitive conditions. - -However a jurisdiction treats unsuccessful tenders and subsequent tenders, in OCDS they are considered separate but related contracting processes. - -This relationship can be modelled using the `relatedProcess` array at the release level, with the ‘unsuccessfulProcess’ relationship type. +However, in some jurisdictions, such as Paraguay, the planning stage is considered as the initiation of the process. In these jurisdictions, when a tender fails and a new tender is started, the two tenders are considered part of the same contracting process. This differs from the OCDS definition of a contracting process. OCDS, instead, records the cancelled procedure in the `relatedProcesses` array of the new procedure, with the 'unsuccessfulProcess' code in the related process' `relationship` array. ![Unsuccessful Tender](../../_static/png/unsuccessful-tender.png) @@ -48,7 +34,7 @@ To construct an `ocid` for the second contracting process, Paraguay adds a conse Paraguay could also have used the identifier for the second tender as the `ocid` for the second contracting process. -The `relatedProcess` block links the two processes, with the relationship set to ‘unsuccessfulProcess’. +The `relatedProcesses` block links the two processes, with the relationship set to ‘unsuccessfulProcess’. ```{jsoninclude} ../../examples/unsuccessful-tender-related-process.json :jsonpointer: diff --git a/docs/history/changelog.md b/docs/history/changelog.md index 7d2468463..80e66d156 100644 --- a/docs/history/changelog.md +++ b/docs/history/changelog.md @@ -14,7 +14,7 @@ Per the [normative and non-normative content and changes policy](https://docs.go * Guidance section: * [#986](https://github.com/open-contracting/standard/pull/986) Add implementation guidance from OCP website. - * Add worked examples for the Map phase [#947](https://github.com/open-contracting/standard/pull/947) [#948](https://github.com/open-contracting/standard/pull/948) [#950](https://github.com/open-contracting/standard/pull/950) [#974](https://github.com/open-contracting/standard/pull/974) [#990](https://github.com/open-contracting/standard/pull/990) [#999](https://github.com/open-contracting/standard/pull/999) [#1007](https://github.com/open-contracting/standard/pull/1007) [#1123](https://github.com/open-contracting/standard/pull/1123). + * Add worked examples for the Map phase [#947](https://github.com/open-contracting/standard/pull/947) [#948](https://github.com/open-contracting/standard/pull/948) [#950](https://github.com/open-contracting/standard/pull/950) [#974](https://github.com/open-contracting/standard/pull/974) [#990](https://github.com/open-contracting/standard/pull/990) [#999](https://github.com/open-contracting/standard/pull/999) [#1007](https://github.com/open-contracting/standard/pull/1007) [#1123](https://github.com/open-contracting/standard/pull/1123) [#1216](https://github.com/open-contracting/standard/pull/1216). * Add worked examples for the Build phase [#951](https://github.com/open-contracting/standard/pull/951) [#997](https://github.com/open-contracting/standard/pull/997). * [#963](https://github.com/open-contracting/standard/pull/963) Remove guidance on web discovery. * [#986](https://github.com/open-contracting/standard/pull/986) Merge Registration page into Build page. @@ -101,6 +101,13 @@ Per the [normative and non-normative content and changes policy](https://docs.go ### Schema +* Clarify core concepts: + * [#1216](https://github.com/open-contracting/standard/pull/1216) Define contracting process and planning process in the schema description. Update definition of release, record and ocid. Update references to contracting process so that it takes take the planning process into account. + * [#1182](https://github.com/open-contracting/standard/pull/1182) `buyer` + * [#1163](https://github.com/open-contracting/standard/pull/1163) `tender.procuringEntity` + * [#1232](https://github.com/open-contracting/standard/pull/1232) `awards.suppliers` + * [#1208](https://github.com/open-contracting/standard/pull/1208) `contracts` and its fields + * Add new fields: * [#1125](https://github.com/open-contracting/standard/pull/1125) `Item.unit.weight` * [#1165](https://github.com/open-contracting/standard/pull/1165) `statusDetails` to `Tender`, `Award` and `Contract` @@ -117,17 +124,6 @@ Per the [normative and non-normative content and changes policy](https://docs.go * [#1200](https://github.com/open-contracting/standard/pull/1200) `tender.submissionMethod`, because all codes from the `submissionMethod` codelist are deprecated. * [#1296](https://github.com/open-contracting/standard/pull/1296) `tender.eligibilityCriteria` in favor of the new `tender.exclusionGrounds` field, in order to use more common terminology and improve semantics. -* Clarify core concepts: - * [#1182](https://github.com/open-contracting/standard/pull/1182) `buyer` - * [#1163](https://github.com/open-contracting/standard/pull/1163) `tender.procuringEntity` - * [#1232](https://github.com/open-contracting/standard/pull/1232) `awards.suppliers` - * [#1208](https://github.com/open-contracting/standard/pull/1208) `contracts` and its fields - -* Clarify merging behavior: - * [#1242](https://github.com/open-contracting/standard/pull/1242) Clarify that the releases to merge must use the same version of OCDS. - * [#1242](https://github.com/open-contracting/standard/pull/1242) Narrow the uniqueness scope of a release's `id` to its `ocid` and OCDS version (was `ocid` only), to allow the publication of the same release for different versions of OCDS. - * [#1315](https://github.com/open-contracting/standard/pull/1315) Update the descriptions of `id` and `date`, to add rules for compiled releases. - * Update and clarify field descriptions: * [#1094](https://github.com/open-contracting/standard/pull/1094) `Organization.id`, to clarify its uniqueness. * [#1113](https://github.com/open-contracting/standard/pull/1113) `ocid`, to recommend a hyphen after the ocid prefix. @@ -145,6 +141,11 @@ Per the [normative and non-normative content and changes policy](https://docs.go * [#1112](https://github.com/open-contracting/standard/pull/1112) `Period.durationInDays`: "If a startDate and endDate are set, this field, if used, **must** be equal to the difference between startDate and endDate. Otherwise, if a startDate and maxExtentDate are set, this field, if used, **must** be equal to the difference between startDate and maxExtentDate." ("should" replaced with "must") * [#1112](https://github.com/open-contracting/standard/pull/1112) `Contract.items`: "If the items contracted are identical to the items awarded, this field **should** be omitted." (rephrased) +* Clarify merging behavior: + * [#1242](https://github.com/open-contracting/standard/pull/1242) Clarify that the releases to merge must use the same version of OCDS. + * [#1242](https://github.com/open-contracting/standard/pull/1242) Narrow the uniqueness scope of a release's `id` to its `ocid` and OCDS version (was `ocid` only), to allow the publication of the same release for different versions of OCDS. + * [#1315](https://github.com/open-contracting/standard/pull/1315) Update the descriptions of `id` and `date`, to add rules for compiled releases. + * Make minor changes to the schema's organization: * [#1240](https://github.com/open-contracting/standard/pull/1240) Move `Unit` from `Item.unit` to the schema definitions. * [#1354](https://github.com/open-contracting/standard/pull/1354) Switch the positions of `contract.dateSigned` and `contract.period` to correspond with the order in `Award`. @@ -169,6 +170,7 @@ Per the [normative and non-normative content and changes policy](https://docs.go * [#1161](https://github.com/open-contracting/standard/pull/1161) Change recommendation for unknown time component. * [#1189](https://github.com/open-contracting/standard/pull/1189) Add recommendations about publishing and referencing documents in the document reference section. * [#1208](https://github.com/open-contracting/standard/pull/1208) Update guidance with new field definitions. +* [#1216](https://github.com/open-contracting/standard/pull/1216) Update definitions of contracting process, record, and ocid. Introduce definition of planning process. * [#1307](https://github.com/open-contracting/standard/pull/1307) Clarify uniqueness rules for records. * [#1315](https://github.com/open-contracting/standard/pull/1315) Add rules on setting `id` and `date` for compiled releases to the merging specification. diff --git a/docs/schema/identifiers.md b/docs/schema/identifiers.md index cf0db2216..2fdf09f08 100644 --- a/docs/schema/identifiers.md +++ b/docs/schema/identifiers.md @@ -2,7 +2,7 @@ Consistent identifiers are essential to help join up open contracting data. -* The Open Contracting ID (ocid) is a globally unique identifier used to join up data on all stages of a contracting process; +* The open contracting process identifier (ocid) is a globally unique identifier used to join up all the data about a single contracting or planning process; * Organization identifiers are important to know who is involved in each contract; * Release, award and contract identifiers are important to help cross-reference information. @@ -12,9 +12,9 @@ In OCDS there are two kinds of identifiers: globally unique and local. ### Globally unique identifiers -Across the whole universe of OCDS publishers these identifiers refer to one specific contracting process or organization. +Across the whole universe of OCDS publishers these identifiers refer to one specific process or organization. -We create globally unique contracting process identifiers by adding a prefix to the internal identifiers held by publishers. +We create globally unique process identifiers by adding a prefix to the internal identifiers held by publishers. ```{admonition} Worked Example :class: hint @@ -40,26 +40,29 @@ You can read more about the OCDS approach to identify organizations below. Not all the identifiers in OCDS need to be globally unique. Most only need to be unique among the identifiers used for the same type of object within the same scope. For example: -* A release ID must be unique within the scope of the contracting process of which it is a part; -* Award and contract identifiers must be unique within the scope of the contracting process of which they are a part; +* A release ID must be unique within the scope of the process of which it is a part; +* Award and contract identifiers must be unique within the scope of the process of which they are a part; * An item, milestone or document ID must be unique within the array it is part of. Local identifiers must be used consistently. For example, if the `id` of an award is "22" in one release, then the `id` of the same award in another release must also be "22". -## Contracting Process Identifier (ocid) +## Open contracting process identifier (ocid) -An Open Contracting ID (ocid) is a **globally unique identifier** for a contracting process. Every OCDS release has an `ocid`. +An open contracting process identifier (ocid) is a **globally unique identifier**. Every release has an `ocid`. OCDS defines an `ocid` as: -It can be used to join up information published at different times, and in different places. +```{field-description} ../../build/current_lang/release-schema.json /properties/ocid +``` + +It can be used to join up information published at different times and in different places. Setting the `ocid` is usually a simple two step process: -1. Identify the best **internal identifier** recorded against the contracting processes being disclosed; +1. Identify the best **internal identifier** recorded against the processes being disclosed; 2. Register an `ocid` prefix to prepend to this internal identifier. -In some cases, you might need to consider changes to existing systems to ensure that different systems handling information about your contracting processes have a common internal identifier to draw upon. +In some cases, you might need to consider changes to existing systems to ensure that different systems handling information about your contracting and planning processes have a common internal identifier to draw upon. ```{admonition} Worked Example :class: hint @@ -161,13 +164,13 @@ See the [guidance](../guidance/map/organization_identifiers.md#party-ids) for mo ## Release ID -A release identifier must be unique within the scope of the contracting process of which it is a part. In other words, across all OCDS releases with the same `ocid` value, each release identifier refers to exactly one release; no two releases use the same release identifier. +A release identifier must be unique within the scope of the contracting process of which it is a part. In other words, across all releases with the same `ocid` value, each release identifier refers to exactly one release; no two releases use the same release identifier. A release identifier must also be consistent within this scope. For example, if the `id` of a release is "12345" in one release package, then the `id` of the same release in another release package must also be "12345". ## Award and Contract IDs -Award and contract identifiers must be unique within the scope of the contracting process of which they are a part. In other words, across all OCDS releases with the same `ocid` value, each contract identifier refers to exactly one contract; no two contracts use the same contract identifier. +Award and contract identifiers must be unique within the scope of the contracting process of which they are a part. In other words, across all releases with the same `ocid` value, each contract identifier refers to exactly one contract; no two contracts use the same contract identifier. Award and contract identifiers must also be consistent within this scope. For example, if the `id` of an award is "22" in one release, then the `id` of the same award in another release must also be "22". diff --git a/docs/schema/records_reference.md b/docs/schema/records_reference.md index fda5fe420..b6ea30f40 100644 --- a/docs/schema/records_reference.md +++ b/docs/schema/records_reference.md @@ -1,6 +1,8 @@ # Record Reference -A record aggregates the releases about a contracting process. There should be a single record per contracting process per [distribution](https://www.w3.org/TR/vocab-dcat-2/#Class:Distribution), where a distribution might be a specific API endpoint or a specific bulk download file. +A record aggregates releases with the same [open contracting process identifier (ocid)](identifiers.md#open-contracting-process-identifier-ocid). + +There should be a single record per ocid per [distribution](https://www.w3.org/TR/vocab-dcat-2/#Class:Distribution), where a distribution might be a specific API endpoint or a specific bulk download file. **Note: If any conflicts are found between this text, and the text within the schema, the schema takes precedence.** @@ -34,7 +36,7 @@ The following example demonstrates the package metadata and record fields. ## Record structure -A record **must** contain an [ocid](identifiers.md#contracting-process-identifier-ocid) and all [releases](#releases) about the contracting process at the time of the record's publication. As such, a record functions as an index of releases about a contracting process. +A record **must** contain an [ocid](identifiers.md#open-contracting-process-identifier-ocid) and all [releases](#releases) about the contracting process at the time of the record's publication. As such, a record functions as an index of releases about a contracting process. A record **should** contain a [compiledRelease](#compiled-release) object, which represents the state of the contracting process at the time of the record's publication. diff --git a/schema/codelists/relatedProcessScheme.csv b/schema/codelists/relatedProcessScheme.csv index b76da5862..af907237e 100644 --- a/schema/codelists/relatedProcessScheme.csv +++ b/schema/codelists/relatedProcessScheme.csv @@ -1,2 +1,2 @@ Code,Title,Description -ocid,Open Contracting ID,An open contracting process identifier (ocid). +ocid,Open contracting process identifier,An open contracting process identifier (ocid). diff --git a/schema/dereferenced-release-schema.json b/schema/dereferenced-release-schema.json index 0a24df07b..a4921c8c0 100644 --- a/schema/dereferenced-release-schema.json +++ b/schema/dereferenced-release-schema.json @@ -2,18 +2,18 @@ "id": "https://standard.open-contracting.org/schema/1__1__5/release-schema.json", "$schema": "http://json-schema.org/draft-04/schema#", "title": "Schema for an Open Contracting Release", - "description": "Each release provides data about a single contracting process at a particular point in time. Releases can be used to notify users of new tenders, awards, contracts and other updates. Releases may repeat or update information provided previously in this contracting process. One contracting process may have many releases. A 'record' of a contracting process follows the same structure as a release, but combines information from multiple points in time into a single summary.", + "description": "OCDS is used for contracts in public procurement (including design contests), concessions, public-private partnerships, government asset sales and other contexts. A \"release\" describes a single contracting or planning process at a particular point in time. One process may be described by many releases. A release may repeat or update the information provided in previous releases about the process.\\n\\nA \"compiled release\" follows the same structure as a release, but combines information about a contracting or planning process from multiple points in time into a single summary.\\n\\nOCDS defines a \"contracting process\" as: \"All the actions aimed at implementing one or more contracts. This covers tendering, awarding, contracting and implementation. It does not include actions linked to planning, as these are often less structured and may be linked to multiple contracting processes. In multiple stage procedures (e.g. framework agreements with reopening of competition), each round of competition is treated as a separate contracting process.\\n\\nProcedures that failed and were restarted are considered new processes.\\n\\nBoundaries between processes (e.g. whether two contracts result from a single process or from two processes) are set by buyers depending on their needs (e.g. efficient division of labor, clear communication with the market) and legislation (e.g. rules on using procedures and lots).\"\\n\\nOCDS defines a \"planning process\" as: \"All the actions aimed at planning one or more contracting processes. This covers, for example, establishing the rationale for the procurement, giving the market a general description of the purchase, getting the necessary budget, forecasting and conducting market research.\\n\\nPlanning processes are often less structured than contracting processes, so one or more planning processes may lead to one or more contracting processes.\"", "type": "object", "properties": { "ocid": { - "title": "Open Contracting ID", - "description": "A globally unique identifier for this Open Contracting Process. Composed of an ocid prefix and an identifier for the contracting process. It is encouraged to separate the ocds prefix and the internal identifier with a hyphen (`-`). For more information see the [Open Contracting Identifier guidance](https://standard.open-contracting.org/{{version}}/{{lang}}/schema/identifiers/)", + "title": "Open contracting process identifier", + "description": "A globally unique identifier for the contracting process that the release describes. Alternatively, this identifier can refer to a planning process or a single stage of a multiple stage procedure. It is composed of an ocid prefix and an internal identifier. It is encouraged to separate the ocds prefix and the internal identifier with a hyphen (`-`). For more information, see the [identifiers](https://standard.open-contracting.org/{{version}}/{{lang}}/schema/identifiers/) reference.", "type": "string", "minLength": 1 }, "id": { "title": "Release ID", - "description": "The identifier of the release. The release ID must be unique within the scope of the contracting process identified by the Open Contracting ID (ocid), for a given version of OCDS. In other words, a publisher may publish datasets for different versions of OCDS, and repeat releases within each dataset. The release ID must not contain the number sign (#). For a compiled release, the `ocid` and the maximum `date` among the individual releases used to create the compiled release, separated by a hyphen: {ocid}-{date}.", + "description": "The identifier of the release. The release ID must be unique within the scope of the contracting process (identified by the ocid), for a given version of OCDS. In other words, a publisher may publish datasets for different versions of OCDS, and repeat releases within each dataset. The release ID must not contain the number sign (#). For a compiled release, the `ocid` and the maximum `date` among the individual releases used to create the compiled release, separated by a hyphen: {ocid}-{date}.", "type": "string", "minLength": 1, "omitWhenMerged": true @@ -10131,7 +10131,7 @@ "openCodelist": true }, "identifier": { - "description": "The identifier of the related process. If the scheme is 'ocid', this must be an Open Contracting ID (ocid).", + "description": "The identifier of the related process. If the scheme is 'ocid', this must be an open contracting process identifier (ocid).", "title": "Identifier", "type": [ "string", @@ -10149,7 +10149,7 @@ } } }, - "description": "The details of related processes: for example, if this process is followed by one or more contracting processes, represented under a separate open contracting identifier (ocid). This is commonly used to refer to subcontracts and to renewal or replacement processes for this contract.", + "description": "The details of related processes: for example, if this process is followed by one or more contracting processes, represented under a separate ocid. This is commonly used to refer to subcontracts and to renewal or replacement processes for this contract.", "title": "Related processes", "type": "array" }, @@ -10652,7 +10652,7 @@ "openCodelist": true }, "identifier": { - "description": "The identifier of the related process. If the scheme is 'ocid', this must be an Open Contracting ID (ocid).", + "description": "The identifier of the related process. If the scheme is 'ocid', this must be an open contracting process identifier (ocid).", "title": "Identifier", "type": [ "string", @@ -10670,7 +10670,7 @@ } } }, - "description": "The details of related processes: for example, if this process follows on from one or more other processes, represented under a separate open contracting identifier (ocid). This is commonly used to relate mini-competitions to their parent frameworks or individual tenders to a broader planning process.", + "description": "The details of related processes: for example, if this process follows on from one or more other processes, represented under a separate ocid. This is commonly used to relate mini-competitions to their parent frameworks or individual tenders to a broader planning process.", "title": "Related processes", "type": "array" }, @@ -20269,7 +20269,7 @@ "openCodelist": true }, "identifier": { - "description": "The identifier of the related process. If the scheme is 'ocid', this must be an Open Contracting ID (ocid).", + "description": "The identifier of the related process. If the scheme is 'ocid', this must be an open contracting process identifier (ocid).", "title": "Identifier", "type": [ "string", @@ -20287,7 +20287,7 @@ } } }, - "description": "The details of related processes: for example, if this process is followed by one or more contracting processes, represented under a separate open contracting identifier (ocid). This is commonly used to refer to subcontracts and to renewal or replacement processes for this contract.", + "description": "The details of related processes: for example, if this process is followed by one or more contracting processes, represented under a separate ocid. This is commonly used to refer to subcontracts and to renewal or replacement processes for this contract.", "title": "Related processes", "type": "array" }, @@ -26248,7 +26248,7 @@ "openCodelist": true }, "identifier": { - "description": "The identifier of the related process. If the scheme is 'ocid', this must be an Open Contracting ID (ocid).", + "description": "The identifier of the related process. If the scheme is 'ocid', this must be an open contracting process identifier (ocid).", "title": "Identifier", "type": [ "string", diff --git a/schema/record-package-schema.json b/schema/record-package-schema.json index d9eac55ff..50d842102 100644 --- a/schema/record-package-schema.json +++ b/schema/record-package-schema.json @@ -126,12 +126,12 @@ "definitions": { "Record": { "title": "Record", - "description": "A record aggregates the releases about a contracting process. There should be a single record per contracting process per [distribution](https://www.w3.org/TR/vocab-dcat-2/#Class:Distribution), where a distribution might be a specific API endpoint or a specific bulk download file.", + "description": "A record aggregates releases with the same open contracting process identifier (ocid). There should be a single record per ocid per [distribution](https://www.w3.org/TR/vocab-dcat-2/#Class:Distribution), where a distribution might be a specific API endpoint or a specific bulk download file.", "type": "object", "properties": { "ocid": { - "title": "Open Contracting ID", - "description": "A unique identifier that identifies the unique Open Contracting Process. For more information see: https://standard.open-contracting.org/{{version}}/{{lang}}/getting_started/contracting_process/", + "title": "Open contracting process identifier", + "description": "A globally unique identifier for the contracting process that the record describes. Alternatively, this identifier can refer to a planning process or a single stage of a multiple stage procedure. It is composed of an ocid prefix and an internal identifier. It is encouraged to separate the ocds prefix and the internal identifier with a hyphen (`-`). For more information, see the [identifiers](https://standard.open-contracting.org/{{version}}/{{lang}}/schema/identifiers/) reference.", "type": "string" }, "releases": { diff --git a/schema/release-schema.json b/schema/release-schema.json index 456f5cf52..d770e58c8 100644 --- a/schema/release-schema.json +++ b/schema/release-schema.json @@ -2,18 +2,18 @@ "id": "https://standard.open-contracting.org/schema/1__1__5/release-schema.json", "$schema": "http://json-schema.org/draft-04/schema#", "title": "Schema for an Open Contracting Release", - "description": "Each release provides data about a single contracting process at a particular point in time. Releases can be used to notify users of new tenders, awards, contracts and other updates. Releases may repeat or update information provided previously in this contracting process. One contracting process may have many releases. A 'record' of a contracting process follows the same structure as a release, but combines information from multiple points in time into a single summary.", + "description": "OCDS is used for contracts in public procurement (including design contests), concessions, public-private partnerships, government asset sales and other contexts. A \"release\" describes a single contracting or planning process at a particular point in time. One process may be described by many releases. A release may repeat or update the information provided in previous releases about the process.\\n\\nA \"compiled release\" follows the same structure as a release, but combines information about a contracting or planning process from multiple points in time into a single summary.\\n\\nOCDS defines a \"contracting process\" as: \"All the actions aimed at implementing one or more contracts. This covers tendering, awarding, contracting and implementation. It does not include actions linked to planning, as these are often less structured and may be linked to multiple contracting processes. In multiple stage procedures (e.g. framework agreements with reopening of competition), each round of competition is treated as a separate contracting process.\\n\\nProcedures that failed and were restarted are considered new processes.\\n\\nBoundaries between processes (e.g. whether two contracts result from a single process or from two processes) are set by buyers depending on their needs (e.g. efficient division of labor, clear communication with the market) and legislation (e.g. rules on using procedures and lots).\"\\n\\nOCDS defines a \"planning process\" as: \"All the actions aimed at planning one or more contracting processes. This covers, for example, establishing the rationale for the procurement, giving the market a general description of the purchase, getting the necessary budget, forecasting and conducting market research.\\n\\nPlanning processes are often less structured than contracting processes, so one or more planning processes may lead to one or more contracting processes.\"", "type": "object", "properties": { "ocid": { - "title": "Open Contracting ID", - "description": "A globally unique identifier for this Open Contracting Process. Composed of an ocid prefix and an identifier for the contracting process. It is encouraged to separate the ocds prefix and the internal identifier with a hyphen (`-`). For more information see the [Open Contracting Identifier guidance](https://standard.open-contracting.org/{{version}}/{{lang}}/schema/identifiers/)", + "title": "Open contracting process identifier", + "description": "A globally unique identifier for the contracting process that the release describes. Alternatively, this identifier can refer to a planning process or a single stage of a multiple stage procedure. It is composed of an ocid prefix and an internal identifier. It is encouraged to separate the ocds prefix and the internal identifier with a hyphen (`-`). For more information, see the [identifiers](https://standard.open-contracting.org/{{version}}/{{lang}}/schema/identifiers/) reference.", "type": "string", "minLength": 1 }, "id": { "title": "Release ID", - "description": "The identifier of the release. The release ID must be unique within the scope of the contracting process identified by the Open Contracting ID (ocid), for a given version of OCDS. In other words, a publisher may publish datasets for different versions of OCDS, and repeat releases within each dataset. The release ID must not contain the number sign (#). For a compiled release, the `ocid` and the maximum `date` among the individual releases used to create the compiled release, separated by a hyphen: {ocid}-{date}.", + "description": "The identifier of the release. The release ID must be unique within the scope of the contracting process (identified by the ocid), for a given version of OCDS. In other words, a publisher may publish datasets for different versions of OCDS, and repeat releases within each dataset. The release ID must not contain the number sign (#). For a compiled release, the `ocid` and the maximum `date` among the individual releases used to create the compiled release, separated by a hyphen: {ocid}-{date}.", "type": "string", "minLength": 1, "omitWhenMerged": true @@ -104,7 +104,7 @@ "items": { "$ref": "#/definitions/RelatedProcess" }, - "description": "The details of related processes: for example, if this process follows on from one or more other processes, represented under a separate open contracting identifier (ocid). This is commonly used to relate mini-competitions to their parent frameworks or individual tenders to a broader planning process.", + "description": "The details of related processes: for example, if this process follows on from one or more other processes, represented under a separate ocid. This is commonly used to relate mini-competitions to their parent frameworks or individual tenders to a broader planning process.", "title": "Related processes", "type": "array" }, @@ -803,7 +803,7 @@ "items": { "$ref": "#/definitions/RelatedProcess" }, - "description": "The details of related processes: for example, if this process is followed by one or more contracting processes, represented under a separate open contracting identifier (ocid). This is commonly used to refer to subcontracts and to renewal or replacement processes for this contract.", + "description": "The details of related processes: for example, if this process is followed by one or more contracting processes, represented under a separate ocid. This is commonly used to refer to subcontracts and to renewal or replacement processes for this contract.", "title": "Related processes", "type": "array" }, @@ -2235,7 +2235,7 @@ "openCodelist": true }, "identifier": { - "description": "The identifier of the related process. If the scheme is 'ocid', this must be an Open Contracting ID (ocid).", + "description": "The identifier of the related process. If the scheme is 'ocid', this must be an open contracting process identifier (ocid).", "title": "Identifier", "type": [ "string", diff --git a/schema/versioned-release-validation-schema.json b/schema/versioned-release-validation-schema.json index 35ecff9b1..ffb01d330 100644 --- a/schema/versioned-release-validation-schema.json +++ b/schema/versioned-release-validation-schema.json @@ -2,7 +2,7 @@ "id": "https://standard.open-contracting.org/schema/1__1__5/versioned-release-validation-schema.json", "$schema": "http://json-schema.org/draft-04/schema#", "title": "Schema for a compiled, versioned Open Contracting Release.", - "description": "Each release provides data about a single contracting process at a particular point in time. Releases can be used to notify users of new tenders, awards, contracts and other updates. Releases may repeat or update information provided previously in this contracting process. One contracting process may have many releases. A 'record' of a contracting process follows the same structure as a release, but combines information from multiple points in time into a single summary.", + "description": "OCDS is used for contracts in public procurement (including design contests), concessions, public-private partnerships, government asset sales and other contexts. A \"release\" describes a single contracting or planning process at a particular point in time. One process may be described by many releases. A release may repeat or update the information provided in previous releases about the process.\\n\\nA \"compiled release\" follows the same structure as a release, but combines information about a contracting or planning process from multiple points in time into a single summary.\\n\\nOCDS defines a \"contracting process\" as: \"All the actions aimed at implementing one or more contracts. This covers tendering, awarding, contracting and implementation. It does not include actions linked to planning, as these are often less structured and may be linked to multiple contracting processes. In multiple stage procedures (e.g. framework agreements with reopening of competition), each round of competition is treated as a separate contracting process.\\n\\nProcedures that failed and were restarted are considered new processes.\\n\\nBoundaries between processes (e.g. whether two contracts result from a single process or from two processes) are set by buyers depending on their needs (e.g. efficient division of labor, clear communication with the market) and legislation (e.g. rules on using procedures and lots).\"\\n\\nOCDS defines a \"planning process\" as: \"All the actions aimed at planning one or more contracting processes. This covers, for example, establishing the rationale for the procurement, giving the market a general description of the purchase, getting the necessary budget, forecasting and conducting market research.\\n\\nPlanning processes are often less structured than contracting processes, so one or more planning processes may lead to one or more contracting processes.\"", "type": "object", "properties": { "initiationType": {