This release contains the following changes:
- Added explicit checks of
round_id
format through a regexpattern
check to theround.round_id
property whenround.round_id_from_variable
isfalse
. This provides upfront validation of the expected format of manual round IDs (i.e. those not source from a task ID) (#112). - BREAKING CHANGE: Restricted the
target_keys
object to contain only a single key value pair (if notnull
). This means that target keys can now only consist of a single value from a single task ID (#117). - BREAKING CHANGE: Removed
target_variable
andtarget_outcome
from standard task ID properties.
- BREAKING CHANGE: Introduction of
is_required
boolean property at theoutput_type
level to configure whether the output type is required for submissions to be considered valid (#99). - BREAKING CHANGE: Disallowed
optional
property inoutput_type_id
objects. As such, when a given output type is submitted, values for all output type IDs much be submitted (#100,#101, #102). - BREAKING CHANGE: To improve cross-platform interoperability, expectation of missing values in point estimate
output_type_id
required
properties now encoded withnull
instead of["NA"]
(#109). - Introduction of optional
derived_task_ids
properties to enable hub administrators to define derived task IDs (i.e. task IDs whose values depend on the values of other task IDs). The higher levelderived_task_ids
property sets the property globally at the hub level but can be overriden by the round levelderived_task_ids
property. The property allows for primarily validation functionality to ignore such task IDs when appropriate which can significantly improve validation efficency (#96). For more information seehubValidations
documentation on ignoring derived task IDs. - Added more specific schema for
target_keys
to ensure onlystring
properties are allowed (#97) - Removed the requirement for a minimum value of zero in
cdf
numericoutput_type_id
s (#113). - Ensured that additional properties are not allowed in lower level properties (e.g. individual task IDs,
output_type
objects etc). Custom additional properties are only allowed at theround
level, while additional task ID objects that match the expected task ID schema are allowed in thetask_ids
object (#114).
- Introduction of optional
output_type_id_datatype
property to enable hub administrators to configure and communicate theoutput_type_id
column data type at a hub level. This will allow hubs to override default behaviour of automatically determinining the simplest data type that can accomodate output type IDs across all output types when creating hub schema. The setting is also useful for administrators to future proof theoutput_type_id
column from potential issues arising by changes in data type, introduced by new output types after submissions have begun, by settingoutput_type_id_datatype
to the simplest data type from the start, i.e. character (#87). - Removed restrictive epidemic week formatting requirements for CDF
output_type_id
values. Character output type IDs no longer need to conform to the regex pattern^EW[0-9]{6}
(e.g."EW202240"
) (#80).
- Breaking change: introduction of new
sample
output type id schema specification intasks.json
. The main breaking change is the removal of theoutput_type_id
property insample
. Instead, the collection of samples is defined through a newoutput_type_id_params
object (#70). - Breaking change: The
repository_url
andrepository_host
properties inadmin.json
have been deprecated in favour of a siglerepository
object with separatehost
,owner
andname
properties (#67). - Breaking change: The optional
hub_models
property inadmin.json
has been removed as it's schema could create conflicts with themodel_abbr
andteam_abbr
schema specification in the hub administered `model-metadata-schema.json (#77). - Additional properties are now allowed at the round item property level (#74).
- Host organisation name changed in schema
id
properties tohubverse-org
throughout all schema versions.
- Non-breaking change: introduced an optional
cloud
group toadmin-schema.json
to support cloud-enabled Hubs:cloud
group includes a booleanenabled
property to indicate whether or not the hub will store data in the cloud.cloud.host
is an object with properties that describe the cloud storage provider and location. It is required whencloud.enabled
istrue
.
- Major breaking change: Output type property
type_id
renamed tooutput_type_id
for consistency in with changes in model output data. - Added
uniqueItem
checks to alloptional
andrequired
arrays. - Added a schema to
task_ids
additionalProperty
property instead of just setting it totrue
. This schema ensures that any custom task IDs added by hub administrators at least checked for being objects and havingoptional
andrequired
properties that are either arrays or null. - Added standard task IDs
forecast_date
(equivalent toorigin_date
),target_end_date
(equivalent totarget_date
) andtarget_variable
&target_outcome
which can be used to split targets across two task IDs.
- Major breaking change:
categorical
output type renamed topmf
for consistency in terminology. - Target type
"categorical"
also renamed to"nominal"
. - Minor bug fixes and consistency improvements.
- Added NEWS.md for recording changes to schema.
- First stable version of schema for use with Hubs
- Important properties introduced:
schema_version
(required) to link a given congif file to a specific config file schema.target_metadata
(required) objects to append metadata about targets to model tasks.file_format
(required inadmin-schema.json
and optional withintasks-schema.json
rounds) to specify accepted file formats of model output file submissions.
- Removed
model-schema.json
. Examples of these will live inhubTemplate
repositories and defined by hub administrators.