Merge pull request #1107 from fredliporace/summaries

Summaries

CHANGELOG.md

@@ -20,6 +20,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 - Clarified that stac_extensions should also list extensions that are used in Collection summaries. ([#1077](https://github.com/radiantearth/stac-spec/issues/1077))
 - The Stats Object for Summaries has been renamed to Range Object (no functional change).
 - `changed`, `created` (common metadata) and temporal extents (collections): Timestamps must be always in UTC ([#1095](https://github.com/radiantearth/stac-spec/issues/1095))
+- Clarified that collection summaries do not require that all property fields are summarized. ([#1106](https://github.com/radiantearth/stac-spec/issues/1106))
 - Clarified that gsd should only be used on an asset to represent the sensor, not just different processing. ([#1105](https://github.com/radiantearth/stac-spec/pull/1105))
 
 ## [v1.0.0-rc.2] - 2021-03-30

collection-spec/collection-spec.md

@@ -91,10 +91,12 @@ and consumers have not been granted any explicit right to use the data.
 
 Collections are *strongly recommended* to provide summaries of the values of fields that they can expect from the `properties` 
 of STAC Items contained in this Collection. This enables users to get a good sense of what the ranges and potential values of 
-different fields in the Collection are, without to inspect a number of Items (or crawl them exhaustively to get a definitive answer). 
-Summaries help to fully define Collections, especially if they don't link to any Items. They also give clients enough information to 
+different fields in the Collection are, without having to inspect a number of Items (or crawl them exhaustively to get a definitive answer). 
+Summaries are often used to give users a sense of the data in [Standalone Collections](#standalone-collections),
+describing the potential values even when it can't be accessed as Items. They also give clients enough information to 
 build tailored user interfaces for querying the data, by presenting the potential values that are available.
-Summaries should summarize all values in every Item underneath the collection, including in any nested sub-Catalogs.
+ Fields selected to be included in summaries should capture all the potential values of the 
+ field that appear in every Item underneath the collection, including in any nested sub-Catalogs.
 
 A summary for a field can be specified in three ways:
 
@@ -108,8 +110,8 @@ A summary for a field can be specified in three ways:
 3. Extensible JSON Schema definitions for fine-grained information, see the [JSON Schema Object](#json-schema-object)
    section for more.
 
-All values must follow the schema of the property they summarize.
-So the values in the array or the values given for `minimum` and `maxmimum` must comply to the original data type
+All values must follow the schema of the property field they summarize, unless the field is an array as described in (1) above.
+So the values in the array or the values given for `minimum` and `maximum` must comply to the original data type
 and any further restrictions that apply for the property they summarize.
 For example, the `minimum` for `gsd` can't be lower than zero and the summaries for `platform` and `instruments`
 must each be an array of strings (or alternatively minimum and maximum values, but that's not very meaningful).