Fix markdown rendering issues

schemas/src/defs/v1.2/properties/optimade/common/chemical_symbol.yaml

@@ -15,8 +15,8 @@ description: |-
 
  - Must be one of the following:
 
- - a valid chemical-element symbol, or
- - the special value `"X"` to represent a non-chemical element.
+  - a valid chemical-element symbol, or
+  - the special value `"X"` to represent a non-chemical element.
 x-optimade-unit: inapplicable
 examples:
  - "He"

schemas/src/defs/v1.2/properties/optimade/common/chemical_symbol_or_vacancy.yaml

@@ -15,9 +15,9 @@ description: |-
 
  - Must be one of the following:
 
- - a valid chemical-element symbol, or
- - the special value `"X"` to represent a non-chemical element, or
- - the special value `"vacancy"` to represent that this site has a non-zero probability of having a vacancy.
+  - a valid chemical-element symbol, or
+  - the special value `"X"` to represent a non-chemical element, or
+  - the special value `"vacancy"` to represent that this site has a non-zero probability of having a vacancy.
 x-optimade-unit: inapplicable
 examples:
  - "He"

schemas/src/defs/v1.2/properties/optimade/common/person.yaml

@@ -18,8 +18,8 @@ description: |-
 
  - The dictionary MUST adhere to the following format:
 
- - **name**: Full name of the person, REQUIRED.
- - **firstname**, **lastname**: Parts of the person's name, OPTIONAL.
+  - **name**: Full name of the person, REQUIRED.
+  - **firstname**, **lastname**: Parts of the person's name, OPTIONAL.
 required: ["name"]
 properties:
  name:

schemas/src/defs/v1.2/properties/optimade/references/authors.yaml

@@ -20,8 +20,8 @@ description: |-
 
  - Each list member MUST be a dictionary with the following keys:
 
- - **name**: Full name of the person, REQUIRED.
- - **firstname**, **lastname**: Parts of the person's name, OPTIONAL.
+  - **name**: Full name of the person, REQUIRED.
+  - **firstname**, **lastname**: Parts of the person's name, OPTIONAL.
 items:
  $$inherit: "/v1.2/properties/optimade/common/person"
 examples:

schemas/src/defs/v1.2/properties/optimade/references/editors.yaml

@@ -20,8 +20,8 @@ description: |-
 
  - Each list member MUST be a dictionary with the following keys:
 
- - **name**: Full name of the person, REQUIRED.
- - **firstname**, **lastname**: Parts of the person's name, OPTIONAL.
+  - **name**: Full name of the person, REQUIRED.
+  - **firstname**, **lastname**: Parts of the person's name, OPTIONAL.
 items:
  $$inherit: "/v1.2/properties/optimade/common/person"
 examples:

schemas/src/defs/v1.2/properties/optimade/structures/assemblies.yaml

@@ -21,15 +21,15 @@ description: |-
  - Client implementations MUST check its presence (as its presence changes the interpretation of the structure).
  - If present, it MUST be a list of dictionaries, each of which represents an assembly and MUST have the following two keys:
 
- - **sites_in_groups**: Index of the sites (0-based) that belong to each group for each assembly.
+  - **sites_in_groups**: Index of the sites (0-based) that belong to each group for each assembly.
 
- Example: `[[1], [2]]`: two groups, one with the second site, one with the third.
- Example: `[[1,2], [3]]`: one group with the second and third site, one with the fourth.
+  Example: `[[1], [2]]`: two groups, one with the second site, one with the third.
+  Example: `[[1,2], [3]]`: one group with the second and third site, one with the fourth.
 
- - **group_probabilities**: Statistical probability of each group. It MUST have the same length as `sites_in_groups`.
- It SHOULD sum to one.
- See below for examples of how to specify the probability of the occurrence of a vacancy.
- The possible reasons for the values not to sum to one are the same as already specified above for the `concentration` of each `species`, see property `species`.
+  - **group_probabilities**: Statistical probability of each group. It MUST have the same length as `sites_in_groups`.
+  It SHOULD sum to one.
+  See below for examples of how to specify the probability of the occurrence of a vacancy.
+  The possible reasons for the values not to sum to one are the same as already specified above for the `concentration` of each `species`, see property `species`.
 
  - If a site is not present in any group, it means that it is present with 100 % probability (as if no assembly was specified).
  - A site MUST NOT appear in more than one group.
@@ -43,60 +43,53 @@ description: |-
  Sites of the first group (the second and the third) are never present at the same time as the fourth site.
  30 % of times sites 1 and 2 are present (and site 3 is absent); 70 % of times site 3 is present (and sites 1 and 2 are absent).
 
- - **Notes**:
+ **Notes**:
 
-  - Assemblies are essential to represent, for instance, the situation where an atom can statistically occupy two different positions (sites).
-  - By defining groups, it is possible to represent, e.g., the case where a functional molecule (and not just one atom) is either present or absent (or the case where it is present in two conformations).
-  - Considerations on virtual alloys and on vacancies: In the special case of a virtual alloy, these specifications allow two different, equivalent ways of specifying them.
-  For instance, for a site at the origin with 30 % probability of being occupied by Si, 50 % probability of being occupied by Ge, and 20 % of being a vacancy, the following two representations are possible:
+ - Assemblies are essential to represent, for instance, the situation where an atom can statistically occupy two different positions (sites).
+ - By defining groups, it is possible to represent, e.g., the case where a functional molecule (and not just one atom) is either present or absent (or the case where it is present in two conformations).
+ - Considerations on virtual alloys and on vacancies: In the special case of a virtual alloy, these specifications allow two different, equivalent ways of specifying them.
+ For instance, for a site at the origin with 30 % probability of being occupied by Si, 50 % probability of being occupied by Ge, and 20 % of being a vacancy, the following two representations are possible:
 
  - Using a single species:
 
- ```
+ {
+ "cartesian_site_positions": [[0,0,0]],
+ "species_at_sites": ["SiGe-vac"],
+ "species": [
+ {
+ "name": "SiGe-vac",
+ "chemical_symbols": ["Si", "Ge", "vacancy"],
+ "concentration": [0.3, 0.5, 0.2]
+ }
+ ]
+ // ...
+ }
 
- {
- "cartesian_site_positions": [[0,0,0]],
- "species_at_sites": ["SiGe-vac"],
- "species": [
- {
- "name": "SiGe-vac",
- "chemical_symbols": ["Si", "Ge", "vacancy"],
- "concentration": [0.3, 0.5, 0.2]
- }
- ]
- // ...
- }
- ```
 
 
  - Using multiple species and the assemblies:
 
- ```
-
- {
- "cartesian_site_positions": [ [0,0,0], [0,0,0], [0,0,0] ],
- "species_at_sites": ["Si", "Ge", "vac"],
- "species": [
- { "name": "Si", "chemical_symbols": ["Si"], "concentration": [1.0] },
- { "name": "Ge", "chemical_symbols": ["Ge"], "concentration": [1.0] },
- { "name": "vac", "chemical_symbols": ["vacancy"], "concentration": [1.0] }
- ],
- "assemblies": [
- {
- "sites_in_groups": [ [0], [1], [2] ],
- "group_probabilities": [0.3, 0.5, 0.2]
- }
- ]
- // ...
- }
- ```
-
- - It is up to the database provider to decide which representation to use, typically depending on the internal format in which the structure is stored.
- However, given a structure identified by a unique ID, the API implementation MUST always provide the same representation for it.
- - The probabilities of occurrence of different assemblies are uncorrelated.
- So, for instance in the following case with two assemblies:
-
- ```
+ {
+ "cartesian_site_positions": [ [0,0,0], [0,0,0], [0,0,0] ],
+ "species_at_sites": ["Si", "Ge", "vac"],
+ "species": [
+ { "name": "Si", "chemical_symbols": ["Si"], "concentration": [1.0] },
+ { "name": "Ge", "chemical_symbols": ["Ge"], "concentration": [1.0] },
+ { "name": "vac", "chemical_symbols": ["vacancy"], "concentration": [1.0] }
+ ],
+ "assemblies": [
+ {
+ "sites_in_groups": [ [0], [1], [2] ],
+ "group_probabilities": [0.3, 0.5, 0.2]
+ }
+ ]
+ // ...
+ }
+
+ - It is up to the database provider to decide which representation to use, typically depending on the internal format in which the structure is stored.
+ However, given a structure identified by a unique ID, the API implementation MUST always provide the same representation for it.
+ - The probabilities of occurrence of different assemblies are uncorrelated.
+ So, for instance in the following case with two assemblies:
 
  {
  "assemblies": [
@@ -110,11 +103,10 @@ description: |-
  }
  ]
  }
- ```
 
  Site 0 is present with a probability of 20 % and site 1 with a probability of 80 %. These two sites are correlated (either site 0 or 1 is present). Similarly, site 2 is present with a probability of 30 % and site 3 with a probability of 70 %.
  These two sites are correlated (either site 2 or 3 is present).
- However, the presence or absence of sites 0 and 1 is not correlated with the presence or absence of sites 2 and 3 (in the specific example, the pair of sites (0, 2) can occur with 0.2*0.3 = 6 % probability; the pair (0, 3) with 0.2*0.7 = 14 % probability; the pair (1, 2) with 0.8*0.3 = 24 % probability; and the pair (1, 3) with 0.8*0.7 = 56 % probability).
+ However, the presence or absence of sites 0 and 1 is not correlated with the presence or absence of sites 2 and 3 (in the specific example, the pair of sites (0, 2) can occur with 0.2·0.3 = 6% probability; the pair (0, 3) with 0.2·0.7 = 14% probability; the pair (1, 2) with 0.8·0.3 = 24 % probability; and the pair (1, 3) with 0.8·0.7 = 56 % probability).
 examples:
  - {"sites_in_groups": [[0], [1]], "group_probabilities": [0.3, 0.7]}
  - {"sites_in_groups": [[1,2], [3]], "group_probabilities": [0.3, 0.7]}

schemas/src/defs/v1.2/properties/optimade/structures/space_group_symbol_hermann_mauguin.yaml

@@ -21,10 +21,10 @@ description: |-
  - The H-M symbol does not unambiguously communicate the axis, cell, and origin choice, and the given symbol SHOULD NOT be amended to convey this information.
  - To encode as character strings, the following adaptations MUST be made when representing H-M symbols given in their typesetted form:
 
- - the overbar above the numbers MUST be changed to the minus sign in front of the digit (e.g. `-2`);
- - subscripts that denote screw axes are written as digits immediately after the axis designator without a space (e.g. `P 32`);
- - the space group generators MUST be separated by a single space (e.g. `P 21 21 2`);
- - there MUST be no spaces in the space group generator designation (i.e. use `P 21/m`, not the `P 21 / m`);
+  - the overbar above the numbers MUST be changed to the minus sign in front of the digit (e.g. `-2`);
+  - subscripts that denote screw axes are written as digits immediately after the axis designator without a space (e.g. `P 32`);
+  - the space group generators MUST be separated by a single space (e.g. `P 21 21 2`);
+  - there MUST be no spaces in the space group generator designation (i.e. use `P 21/m`, not the `P 21 / m`);
 
  **Bibliographic References**