The road to trajectories

[rartino]

This issue duplicates #428 and #34. It is meant to be a short checklist of our current agreed path to get "trajectories" into the OPTIMADE standard.

People listed as trajectory stakeholders: @rartino @sauliusg @giovannipizzi @gmrigna @JPBergsma @merkys

Checklist:

• Finalize and merge the latest PR for partial data Partial data #467.
• Slightly update and then merge the first version of the metadata proposal Add per entry and per property meta data field. #463.
• Make sure that the ongoing PRs related to updating the property definitions Add machine-readable property definitions to repository #445 defines and supplies the x-optimade-dimension keyword for lists. Done.
• Rework / replace the old Add ranged properties #452 into a PR that only implements the property_ranges query parameters and defines the semantics (property_ranges=dimname:start:stop:step,dimname2:start:stop:step) using the dimension names: @JPBergsma has created Adding the property_ranges query parameter and associated metadata #481 for this
• Update/rework the trajectories PR Adding the trajectories endpoint to OPTIMADE #377 to define the entry type/endpoint "trajectories" with actual standardized properties, waiting on action by someone (@JPBergsma ?)

Note: people marked with (*) above "own" the respective PRs and can thus not formally approve them. Nevertheless, since these PRs undergo change requests/discussions, lets try to keep track above when also the owner feels a PR is ok to merge.

Any necessary step I've forgotten? Comment below and I'll edit this list to integrate it.

[rartino]

Trying to organize things here, since I understand it, getting trajectories into v1.2.0 is desired and somewhat urgent: @JPBergsma, are you available and want to take on point 4 for a PR with a stand-alone definition of the property_ranges query parameter, preferably ready and merge:able for the web meeting next Thursday?

[JPBergsma]

For me, it is not that important that it goes into the 1.2 version. I do not know what Giovanni and Gian-Marco have communicated with you, perhaps they want to have it merged in if it was a deliverable in a proposal. The most important, for me, is that I have a draft version for which everyone agrees on the mechanism that will be used.
I think we should also build a trial implementation before we merge the partial data PR with the 1.2 version, as we now wrote it rather quickly, and I suspect there are still some hidden issues. (I had not finished my review when it got merged.)

I'll start working on the "property_ranges" parameter next week.
It may be better if you message me directly if you want me to do something, as mentions on GitHub can easily get drowned in the large number of messages I get from GitHub.

[gmrigna]

I think that having trajectories in v1.2 is important for CECAM and for the MD community. @JPBergsma Does that sound feasible?

[JPBergsma]

I think we should first make an implementation of the partial data PR. I think it is mainly important that there is a clear draft version, so I and other groups, if they want, can start with implementing it, so we see what is practical and what not.
Whether we make it for version 1.2 depends on when you want to release it. I thought version 1.2 was close to finished. So I think that waiting for a proper implementation may delay the release of 1.2 for several months. For what is the most important for CECAM, I should first consult with Sara and perhaps also Andrea.
Would it be problematic to release a 1.3 version later on with the trajectory changes and not delay version 1.2 ?

[gmrigna]

It would definitely help if you could discuss this with Sara...

[JPBergsma]

I have not slept properly for about one and a half week and have therefore not yet been able to finish the PR for the property ranges. I'll try to finish it tomorrow, but I do not know how I will feel by then.