v1.3.0

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 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 additional v1.3.x releases.

New features

• Trajectories endpoint (#377, #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): 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, #562, #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): 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.
  This format is already in-use by several tools in the ecosystem and is RECOMMENDED for interoperability.
• Extended filtering on relationships (#524, #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.