Fixes to property definitions

[rartino]

While completing the changes for the trajectory property definitions a number of smaller issues with the property definitions already in the repository has come up. This PR separates those changes out, to avoid merging the discussion about these adjustments and the trajectory-related ones.

One interesting note is that our schemas are unable to validate the special values of x-optimade-unit since the unit specification can itself be any string. So it is easy for incorrectly written versions of the standard values to slip trough. I'm not sure what to do about that.

Also, I'm adding a dimension name to the Wyckoff list of symmetry operations (space_group_symmetry_operations_xyz.yaml). I'm not 100% it absolutely is required by the specification, but it also seems reasonable given that, as far as I know, we name all our other dimensions. (This enters when I have to create a list of the Wyckoff symops lists for the trajectories endpoint...)

Edit: I also see that the compactable definition of the meta-schema made it in here. I guess it is correct that this is a fix since the description of compactable is already in the specification.

[merkys]

@rartino

One interesting note is that our schemas are unable to validate the special values of x-optimade-unit since the unit specification can itself be any string. So it is easy for incorrectly written versions of the standard values to slip trough. I'm not sure what to do about that.

Fair point. We cannot just give OPTIMADE unit pointers, as OPTIMADE units would not cover compound units (1/Angstrom and stuff like that).

Also, I'm adding a dimension name to the Wyckoff list. I'm not 100% it absolutely is required by the specification, but it also seems reasonable given that, as far as I know, we name all our other dimensions. (This enters when I have to create a list of the Wyckoff lists for the trajectories endpoint...)

Diff does not show this - maybe you had in mind the size constraint?

[ml-evs]

I guess the make schemas task used in #577 should also be hardened to catch some of these? (inapplicable vs unapplicable is not encoded at the schema level but extra keys must be?)

Maybe not, these were all valid schema constructs, just wrong values

[rartino]

@merkys

Diff does not show this - maybe you had in mind the size constraint?

Sorry, it was a typo, I meant the symmetry operations list (space_group_symmetry_operations_xyz), now corrected above.

[rartino]

Sorry for updating a few more issues after your first reviews; but this should be it for this PR.