diff --git a/AUTHORS b/AUTHORS index 93223d3a7..f3b29def4 100644 --- a/AUTHORS +++ b/AUTHORS @@ -6,6 +6,8 @@ The OPTIMADE API has been developed with contributions by the participants of th - the CECAM in Lausanne, Switzerland (virtually) 2021-06-07 to 2021-06-11 - the CECAM in Lausanne, Switzerland 2022-05-30 to 2022-06-03 - the CECAM in Lausanne, Switzerland 2023-06-05 to 2023-06-09 +- the CECAM in Lausanne, Switzerland 2024-06-10 to 2024-06-14 +- the Vilnius University Life Sciences Center in Vilnius, Lithuania 2025-09-15 to 2025-09-19 Initial and major contributors to the development of the OPTIMADE specification and implementation in alphabetical order: Casper Andersen @@ -23,6 +25,7 @@ Pauline Colinet Gareth Conduit Stefano Curtarolo Davide Di Stefano +Nathan Daelman Alexander Dorsk Claudia Draxl Shyam Dwaraknath @@ -36,6 +39,7 @@ Matteo Giantomassi Abhijith Gopakumar Marco Govoni Saulius Gražulis +Algirdas Grybauskas Geoffroy Hautier Vinay Hegde Matthew Horton diff --git a/CHANGELOG.md b/CHANGELOG.md index b49d02a72..397f7fa5e 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,36 @@ # Changelog +## v1.3.0-rc.1 (November 2025) + +This release extends the OPTIMADE specification with new entry types and properties with an emphasis on applying the partial data protocol from v1.2 to the new trajectories endpoint, for which each resource is likely to be too large to be served in a single response. + +As part of this release, the OPTIMADE consortium also adopts the Contributor Covenant (3.0) Code of Conduct for all community interactions. +Please see [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) for details of the contributor expectations, as well as reporting and enforcement procedures. + +Minor OPTIMADE releases are always intended to be backwards-compatible for clients, meaning that any client code written for v1.x should continue to work, and any breaking changes should be reported as bugs to be fixed in a patch v1.3.x release. + +## New features + +- **Trajectories endpoint** ([#377](https://github.com/Materials-Consortia/OPTIMADE/pull/377), [#481](https://github.com/Materials-Consortia/OPTIMADE/pull/481)) +): A new trajectories entry type has been added to the specification to share data belonging to ordered sequences of structures, such as those arising from molecular dynamics simulations or geometry optimizations. + In order to handle large individual entries, this endpoint makes use of the partial data protocol introduced in v1.2, with additional specialisations for slicing (e.g., the `dimension_slices` URL parameter) and representing dimensions that remain constant throughout a trajectory, whilst retaining the ability to filter using the normal OPTIMADE syntax via the `reference_frame` field. +- **Provider-specific data types** ([#560](https://github.com/Materials-Consortia/OPTIMADE/pull/560)): Providers and namespaces can now define custom data types for their properties that let them use specific query semantics that differ from the standard OPTIMADE data types. + For example, a provider could define a field that uses a string format for a field, but a custom data type that allows for e.g., `CONTAINS` queries to do something other than pure substring matching. +- **New fields for structures entries (`fractional_site_positions`, `site_coordinate_span`, `site_coordinate_span_description`, `optimization_type`, `wyckoff_positions`)** + ([#539](https://github.com/Materials-Consortia/OPTIMADE/pull/539), [#562](https://github.com/Materials-Consortia/OPTIMADE/pull/562), [#570](https://github.com/Materials-Consortia/OPTIMADE/pull/570)): Several new fields have been added to the structures entry type to improve symmetry representation and to provide information about the provenance of the structure: + - `fractional_site_positions`, `site_coordinate_span`, `site_coordinate_span_description`: New fields that can be used to describe positions of atoms as an alternative to `cartesian_site_positions`, to be used in conjunction with `space_group_symmetry_operations_xyz` when providing only the asymmetric unit of a structure. + The additional `site_coordinate_span` and `site_coordinate_span_description` fields can be used to describe the extent of the atoms that have been provided as fractional coordinates and can take values such as `asymmetric_unit`, `unit_cell`, `molecular_entities`, etc. + - `wyckoff_positions`: This field can be used to provide the Wyckoff positions of each site in the structure, if known, following the IUCr definitions of labelling. + - `optimization_type`: This field can be used to describer the type of optimization that has been performed on a structure, if any. + For example, the optimization could be relative to experimental evidence (`experimental`) (e.g., minimising discrepancy with a diffraction pattern), relative to some kind of Hamiltonian (e.g., density-functional theory or a force-field), and whether the optimisation scope was `local` or in some sense `global` (minimised relative to a global energy surface of possible decompositions and other structural configurations). +- **JSONLines standardization for serializing OPTIMADE APIs to disk** ([#531](https://github.com/Materials-Consortia/OPTIMADE/pull/531)): An appendix has been added to the specification with a suggestion for how to serialize OPTIMADE entries, or full APIs (including e.g., info endpoints) to a single file using the [JSONLines format](https://jsonlines.org/). + This format is already in-use by several tools in the ecosystem and is RECOMMENDED for interoperability. +- **Extended filtering on relationships** ([#524](https://github.com/Materials-Consortia/OPTIMADE/pulls/524), [#523](https://github.com/Materials-Consortia/OPTIMADE/pull/523)): + Additional metadata fields describing relationships between entries (`description` and `role`) have been added between all entry types. + An additional dummy field `target` has been added to enable direct querying (i.e., without requiring a join) on properties of the target of a relationship, for example: `/structures?filter=references.target.doi="10.1234/56789"`. + In addition, relationships specifically between `files` and `calculations` entries can now specify a `role` that describes whether the file is an `input`, `output`. + + ## v1.2.0 (June 2024) diff --git a/optimade.rst b/optimade.rst index c0833184b..45c5443c6 100644 --- a/optimade.rst +++ b/optimade.rst @@ -1,6 +1,6 @@ -========================================= -OPTIMADE API specification v1.3.0~develop -========================================= +====================================== +OPTIMADE API specification v1.3.0-rc.1 +====================================== .. comment