OPTIMADE icon indicating copy to clipboard operation
OPTIMADE copied to clipboard

Calculation entry standardization

Open rartino opened this issue 7 years ago • 4 comments

We need to standardize mandatory and optional the fields in the calculation entry type.

rartino avatar Jun 14 '18 09:06 rartino

Here is an attempt at a concrete suggestion:

{
  ... <other response items> ...
  "data": [
    {
      "type": "calculation",
      "id": "example.db:calcs:0001",
      "attributes": {
        "local_id": "example.db:calcs:0001",
        "url": "http://example.db/calcs/0001",
        "immutable_id": "http://example.db/calcs/0001@123",
        "last_modified": "2007-04-05T14:30Z",
        "calculation_description": "relaxation",
        "related_structures_descriptions": ["initial", "final"],
        "related_structure_ids": ["example.db:struct:0042", "example.db:struct:4711"], 
        "workflow_id": "exmpl:relax:42"
      }
    }
  ]
}

Note the inclusion of the "workflow_id", in relation to the discussion in issue #30.

rartino avatar Jun 14 '18 20:06 rartino

It was said during the discussion that this probably cannot be decided without another meeting.

rartino avatar Jun 15 '18 10:06 rartino

Should we think about how we make a query ? For example, if I want to get the data of BAND GAP, should we enter the keyword "band_gap" , or " BandGap" , or "BGap", ... etc. Is it discussed somewhere else ? Or we have already had the specification formulated ?

kxyyang avatar Jul 01 '18 12:07 kxyyang

Looking at other parts of the specification, e.g., #23, makes it seem likely to become band_gap over the other alternatives you suggest. But, we presently have no agreement of a common definition of band_bap. I suspect we will go down the road of, e.g., band_gap_kohn_sham, band_gap_optical, band_gap_fermi_liquid_quasiparticle, etc. But I expect that we'll need a discussion in a meeting to sort this out.

rartino avatar Jul 03 '18 21:07 rartino