style adjustments re use of field/array/object/subschema consistently

docs/examples/organizations/organizational_units/ocds_divisionCode_extension/extension.json

@@ -3,7 +3,7 @@
     "en": "Division codes"
   },
   "description": {
-    "en": "Adds a divisionCode field to the Organization sub-schema"
+    "en": "Adds a divisionCode field to the Organization subschema"
   },
   "documentationUrl": {
     "en": "http://github.com/example_publisher/ocds_division_code_extension"

docs/guidance/build/system_architectures.md

@@ -74,7 +74,7 @@ This approach puts the burden of data conversion on data sources. Yet it might b
 
 This approach might also be suitable to combine data from many data sources. Each source becomes an OCDS publisher. The middleware becomes less complex since it only ingests data in a single format.
 
-The [OpenProcurement](http://openprocurement.org/en/) system adopted a similar approach. This system was developed in Ukraine and it's the base for the [Prozorro](https://prozorro.gov.ua/en/) platform. Prozorro uses OCDS sub-schema as the foundation for data sources' data models.
+The [OpenProcurement](http://openprocurement.org/en/) system adopted a similar approach. This system was developed in Ukraine and it's the base for the [Prozorro](https://prozorro.gov.ua/en/) platform. Prozorro uses OCDS subschema as the foundation for data sources' data models.
 
 A variant in this scenario is to store files in a web-accessible file system, as shown below. A periodical invocation of the conversion module updates the file system.
 

docs/guidance/map/amendments.md

@@ -96,7 +96,7 @@ See the JSON release below.
 
 #### Contract Amendment
 
-A few days after the contract release, its scope is increased to include the purchase of one additional appliance. A new 'contractAmendment' release is built, where a single item is added in the `contracts/items` array and the value of the contract is increased. A `amendments` array is included to explain the rationale of the changes.
+A few days after the contract release, its scope is increased to include the purchase of one additional appliance. A new 'contractAmendment' release is built, where a single item is added in the `contracts.items` array and the value of the contract is increased. An `amendments` array is included to explain the rationale of the changes.
 
 See the example release below.
 
@@ -149,7 +149,7 @@ This can be modelled as the separate releases in OCDS as shown below. The origin
 :title: ContractAmendment
 ```
 
-Note that the mapping of the fields remains the same for the contract amendments, except for the `description` column. When a row in the contract signature notices table is identified as an original contract, the description is included in the `contracts/description` field, and when the row represents a contract amendment, it is mapped to the `contracts/amendments/description` field. This aligns with the use of the `description` column, because for contract amendments it is used to include an explanation of the change.
+Note that the mapping of the fields remains the same for the contract amendments, except for the `description` column. When a row in the contract signature notices table is identified as an original contract, the description is included in the `contracts.description` field, and when the row represents a contract amendment, it is mapped to the `contracts.amendments.description` field. This aligns with the use of the `description` column, because for contract amendments it is used to include an explanation of the change.
 
 The advantage of this approach, in contrast with the Easy releases proposal, is that the users have access to the details of each amendment instead of the latest values only without any additional effort of their end.
 

docs/guidance/map/extensions.md

@@ -1,6 +1,6 @@
 # Extensions
 
-OCDS provides a common core of [sections](../../schema/reference.md#release-structure) and [sub-schemas](../../schema/reference.md#sub-schema-reference) for describing contracting (or planning) processes.
+OCDS provides a common core of [sections](../../schema/reference.md#release-structure) and [subschemas](../../schema/reference.md#subschema-reference) for describing contracting (or planning) processes.
 
 Many publishers will have additional data that they could publish. Instead of ignoring this data and leaving it unpublished, OCDS encourages publishers to collaborate on the creation of **extensions** to the standard.
 

docs/guidance/map/organization_classifications.md

@@ -11,7 +11,7 @@ Some organization classifications, such as organization scale, can be published
 There are therefore two options that are encouraged for publishing organization classifications.
 
 1. For classifications that have become standardized, there are specific OCDS fields and codes that ought to be used. At present, this only applies to organization scale, which ought to be disclosed using the `parties.details.scale` field, using a code from the [party scale codelist](../../schema/codelists.md#party-scale).
-1. For non-standardized options, such as classifying forms of organization ownership, publishers ought to use the [organization classification extension](https://extensions.open-contracting.org/en/extensions/organizationClassification/1.1/). This extension adds a [`classifications`](../../schema/reference.md#classification) array to `parties.details` to enable the categorization of organizations. Each `classification.id` field ought to contain a code from the particular scheme given in the `classification.scheme` field. Details about the particular organization characteristic that is being disclosed ought to be provided in the `classification.description` field. The given `classification.scheme` can be an existing scheme (drawn from the open [classificationScheme codelist](../../schema/codelists.md#classification-scheme)), or a local scheme for a particular publisher. In both cases, we encourage publishers to provide details of all schemes and classification codes used in their [publication policy](../publish.md#finalize-your-publication-policy), to help users understand the data.
+1. For non-standardized options, such as classifying forms of organization ownership, publishers ought to use the [organization classification extension](https://extensions.open-contracting.org/en/extensions/organizationClassification/1.1/). This extension adds a [`classifications`](../../schema/reference.md#classification) array to the `parties.details` object to enable the categorization of organizations. Each `classification.id` field ought to contain a code from the particular scheme given in the `classification.scheme` field. Details about the particular organization characteristic that is being disclosed ought to be provided in the `classification.description` field. The given `classification.scheme` can be an existing scheme (drawn from the open [classificationScheme codelist](../../schema/codelists.md#classification-scheme)), or a local scheme for a particular publisher. In both cases, we encourage publishers to provide details of all schemes and classification codes used in their [publication policy](../publish.md#finalize-your-publication-policy), to help users understand the data.
 
 As fields become standardized through the use of option 2, the information can be migrated to _also_ be published via OCDS fields and codes as in option 1. Publishers can continue to publish the information in the organization classification extension to preserve backwards compatibility in data sets.
 
@@ -43,7 +43,7 @@ In the examples below, two different publishers have disclosed information about
 
 #### Classification schemes
 
-A classification object can set the fields: `description` (a textual description or title for the classification code), `id` (the classification code), `uri` (to uniquely identify the classification code) and `scheme`. The `scheme` value can be drawn from the open [classificationScheme codelist](../../schema/codelists.md#classification-scheme) (where the `Category` value is "organization"), or it can be a local scheme. Schemes are given to classify the activities of procuring authorities (i.e. procuring entities and/or buyers).
+A `classification` object can set the fields: `description` (a textual description or title for the classification code), `id` (the classification code), `uri` (to uniquely identify the classification code) and `scheme`. The `scheme` value can be drawn from the open [classificationScheme codelist](../../schema/codelists.md#classification-scheme) (where the `Category` value is "organization"), or it can be a local scheme. Schemes are given to classify the activities of procuring authorities (i.e. procuring entities and/or buyers).
 
 Where an appropriate scheme is not listed in the [classificationScheme codelist](../../schema/codelists.md#classification-scheme), publishers can specify their own scheme. Publishers can either reuse an alternative scheme, or provide their own. Where publishers provide their own local schemes, they ought to prefix their `scheme` code with an [ISO-3166-1 alpha-3 country code](https://en.wikipedia.org/wiki/ISO_3166-1) to preserve its global uniqueness. Details of this local scheme, and a list of possible codes, ought to be described in the [publication policy](../publish.md#finalize-your-publication-policy).
 

docs/guidance/map/organizational_units.md

@@ -8,20 +8,20 @@ For some use cases, publishers might need to disclose the organizational units i
 
 There is more than one approach to model organizational units in OCDS:
 
-1. **Use the fields available in the Organization sub-schema**. This is the preferred approach, when possible. 
+1. **Use the fields available in the Organization subschema**. This is the preferred approach, when possible. 
 
     * Unit names can be included in the `name` field alongside the organization name. 
     * The `additionalIdentifiers` array can be used to provide any unit identifiers. It is important to note that `identifier` and `additionalIdentifiers` need to point toward the *same legal entity*. The main `identifier` ought to belong to the organization and the `legalName` field can be used to provide the organization name alone. 
     * The `address` and `contactPoint` objects can be filled with the unit information. 
     * Unit identifiers can also be appended to `parties/id`.
 
-2. When the first option is not enough to model the publisher's case, **use or create an extension**. Any additional fields can be placed under the `details` field of the `Organization` sub-schema.
+2. When the first option is not enough to model the publisher's case, **use or create an extension**. Any additional fields can be placed under the `details` field of the `Organization` subschema.
 
 Some publishers use the [memberOf](https://github.com/open-contracting-extensions/ocds_memberOf_extension) extension to represent organization hierarchies, including organizational units. This is strongly discouraged unless there is a clear use case to support it, because OCDS is not designed to disclose hierarchical organization information. Ideally, organizational hierarchies would be represented in separate, non-OCDS datasets, and organizational units would be modelled using one of the alternatives described above. 
 
 ## Worked examples
 
-### 1. Using the Organization sub-schema
+### 1. Using the Organization subschema
 
 In Honduras, the Ministry of Health is planning the procurement of food supplies for the San Felipe Hospital. For the purposes of the example, San Felipe Hospital is considered to be a unit belonging to the Ministry of Health, and it is not a legal entity of its own.
 
@@ -63,7 +63,7 @@ The branch name (*Chişinău Branch*) is appended at the end of the name of the
 
 The `extension.json` and `release-schema.json` files for the Division code extension can be displayed using the combo box above the JSON example. Instructions on how to create an OCDS extension can be found [here](https://github.com/open-contracting/standard_extension_template).
 
-### 3. Using the Organization sub-schema with an organizational hierarchy
+### 3. Using the Organization subschema with an organizational hierarchy
 
 The *Hospital de Clínicas* is planning to procure supplies for their Blood Center. The Hospital is part of the Medical School in the National University of Asuncion. Since the hospital is key in the provision of healthcare for low income groups in the community, it is in the interest of many to clearly identify the procurement of the Hospital only. It is also important for the publisher that users can group the data following organizational hierarchies.
 

docs/history/changelog.md

@@ -548,8 +548,8 @@ See the changelogs for:
 #### Schema definition updates
 
 * [#372](https://github.com/open-contracting/standard/issues/372) **[Updates to transactions terminology](../schema/reference.md#transaction)** - We have replaced receiverOrganization and providerOrganization with payee and payer, to align with more familiar terminology, and have replaced 'amount' with 'value' for consistency with other areas of the standard.
-* [#378](https://github.com/open-contracting/standard/issues/378) **[Updates to `Budget` sub-schema](../schema/reference.md#budget)** - We have updated references to the Fiscal Data Package in the schema.
-* [#337](https://github.com/open-contracting/standard/issues/337) **[Definition of "tenderer" to enhance clarity](../schema/reference.md#tender)** - We have updated the definition of tenderer in the `Tender` sub-schema, and cross-referenced the bid extension.
+* [#378](https://github.com/open-contracting/standard/issues/378) **[Updates to `Budget` subschema](../schema/reference.md#budget)** - We have updated references to the Fiscal Data Package in the schema.
+* [#337](https://github.com/open-contracting/standard/issues/337) **[Definition of "tenderer" to enhance clarity](../schema/reference.md#tender)** - We have updated the definition of tenderer in the `Tender` subschema, and cross-referenced the bid extension.
 * [#259](https://github.com/open-contracting/standard/issues/259) **[Enquiries](https://extensions.open-contracting.org/en/extensions/enquiries/)** - We have updated the definition of hasEnquiries.
 * [#246](https://github.com/open-contracting/standard/issues/246) **[In what scope must a release ID be unique?](../schema/reference.md#release)** - We have updated the definition of release.id to reflect the scope in which it must be unique
 
@@ -570,7 +570,7 @@ See the changelogs for:
 ### Added
 
 * [#371](https://github.com/open-contracting/standard/issues/371) [#439](https://github.com/open-contracting/standard/pull/439) **[Linking related processes](../schema/reference.md#relatedprocess)** - We have introduced a new `relatedProcesses` field at the release and contract level
-* [#374](https://github.com/open-contracting/standard/issues/374) **[Duration in periods](../schema/reference.md#period)** - We have introduced fields for duration in days, and maximum extent, to the `Period` sub-schema
+* [#374](https://github.com/open-contracting/standard/issues/374) **[Duration in periods](../schema/reference.md#period)** - We have introduced fields for duration in days, and maximum extent, to the `Period` subschema
 * [#374](https://github.com/open-contracting/standard/issues/374) **[Contract and Award Periods in Tender](../schema/reference.md#tender)** - We have introduced contract period in tender and updated the definition of award period.
 * [#376](https://github.com/open-contracting/standard/issues/376) **[Contract type (supplies, works and services)](../schema/codelists.md#procurement-category)** - We have introduced a procurementCategory field to specify whether contracts are for supplies, works, services, consultancyServices or mixed
 * [#373](https://github.com/open-contracting/standard/issues/373) **[Milestone types](../schema/codelists.md#milestone-type)** - We have introduced the milestoneType property and codelist
@@ -581,7 +581,7 @@ See the changelogs for:
 * [#335](https://github.com/open-contracting/standard/issues/335) [#411](https://github.com/open-contracting/standard/pull/411) **[Core and community extensions](../guidance/map/extensions)** - We have introduced widespread use of extensions throughout the standard. An extension provides fields and data structures that are optional, either because   (a) they are only relevant in particular contexts or contracting processes; or   (b) they represent a 'stretch goal' for most data publishers, and so are not currently suitable for inclusion in the main standard.   We divide these extensions into 'core extensions' which have wide enough relevance, and technical maturity to be included in the main standard documentation (and which are versioned along with the standard documentation), and 'community extensions' which may have less technical maturity, or which might be versioned independently of the main standard.
 * [#259](https://github.com/open-contracting/standard/issues/259) **[Enquiries](https://extensions.open-contracting.org/en/extensions/enquiries/)** - We have introduced a core enquiries extension for providing information on enquiries received during the tender stage.
 * [#342](https://github.com/open-contracting/standard/issues/342) **[Overall contracting process description](../schema/reference.md#release)** - We have introduced a new top-level title and description for the contracting process as a core extension.
-* [#274](https://github.com/open-contracting/standard/issues/274) **[New property of contract: extendsContractID](../schema/reference.md#contract)** - We have introduced a new field 'extendsContractID' to the `Contract` sub-schema to support contract cross-referencing between contracts.
+* [#274](https://github.com/open-contracting/standard/issues/274) **[New property of contract: extendsContractID](../schema/reference.md#contract)** - We have introduced a new field 'extendsContractID' to the `Contract` subschema to support contract cross-referencing between contracts.
 * [#381](https://github.com/open-contracting/standard/issues/381) **[Lots](https://extensions.open-contracting.org/en/extensions/lots/)** - We have introduced a core extension to provide a model for contracting processes which are divided into lots.
 * [#379](https://github.com/open-contracting/standard/issues/379) **[Bids and Bid Statistics](https://extensions.open-contracting.org/en/extensions/bids/)** - We have introduced a core extension which provides a top-level Bids section, with BidStatistics and Bid sub-schemas for detailed information on individual bids. This supersedes the current tender/tenderers section.
 * [#250](https://github.com/open-contracting/standard/issues/250) **[Location extension](https://extensions.open-contracting.org/en/extensions/location/)** - We have moved the location extensions to become a core extension
@@ -591,7 +591,7 @@ See the changelogs for:
 ### Deprecated
 
 * [#355](https://github.com/open-contracting/standard/issues/355) **[Deprecating milestone documents](../schema/reference.md#milestone)** - We have deprecated milestone documents from core, and added a milestone documents extension for those who wish to continue to use documents at the milestone level.
-* [#368](https://github.com/open-contracting/standard/issues/368) **[Updates to organization handling in OCDS](../schema/reference.md#parties)** - We have deprecated use of the full `Organization` sub-schema at points other than the parties array.
+* [#368](https://github.com/open-contracting/standard/issues/368) **[Updates to organization handling in OCDS](../schema/reference.md#parties)** - We have deprecated use of the full `Organization` subschema at points other than the parties array.
 * [#372](https://github.com/open-contracting/standard/issues/372) **[Updates to transactions terminology](../schema/reference.md#transaction)** - receiverOrganization, providerOrganization and amount properties have been deprecated in favor or other terms.
 
 ## [1.0.3] - 2017-07-31