Home.md

@@ -47,9 +47,9 @@ However for adoption of your application- or domain-level metadata and semantics
 ### Metadata schemas
 Application level metadata is often collected and validated with metadata schemas. Different formats may be used for this, such as xml or JSON-Schema. We here highlight the latter as a very commonly used way of defining schemas, but envision similar implementations also in other formats or serialisation. 
 
-### semantic file formats
+### Semantic file formats
 
-### semantic artefacts (RDF, RDFs, OWL)
+### Semantic artefacts (RDF, RDFs, OWL)
 - import of emg.owl
 - import of classes from emg.owl with annotation properties
 - import of classe from emg.owl with partial annotation properties
@@ -64,24 +64,24 @@ How to adapt and use terminology from emg.owl in your application level artefact
 ----
 
 # Releases of emg.owl
-The current artefact is documented in our [Glossary specification page](https://owl.emglossary.helmholtz-metadaten.de). Here we provide additional info on planned release cycle, file management during releases and versioning applied to our releases.
+The current artefact is documented in our [glossary specification page](https://owl.emglossary.helmholtz-metadaten.de). Here we provide additional info on planned release cycle, file management during releases and versioning applied to our releases.
 
-### emg.owl release cycle & management
+### Release cycle & management
 For release cycle, release management and [semantic versioning](https://semver.org/) we follow generally established best practices for the emg.owl artefact. We intend to keep the semantic artefact stable through short release cycles. Depending on our community process we expect at least 3 major releases per year. 
 
 Prior release, changes are accumulated in [emg-edit.owl](https://codebase.helmholtz.cloud/em_glossary/em_glossary_owl/-/blob/main/development/emg-edit.owl) which is assembled in this repository. Every merge to main in our [community repository](https://codebase.helmholtz.cloud/em_glossary/em_glossary) triggers an automated update of emg-edit.owl through a CI/CD pipeline (see below). When a release is made, version information is included in the OWL header and [emg.owl](https://codebase.helmholtz.cloud/em_glossary/em_glossary_owl/-/blob/main/emg.owl) and its [documentation](https://owl.emglossary.helmholtz-metadaten.de) is updated. Previous versions of emg.owl are archived within [this repository](https://codebase.helmholtz.cloud/em_glossary/em_glossary_owl/-/tree/main/previous-versions). 
 
 In the future we intend to handle file changes and semantic versioning during releases automatically through a separate script.
 
-### emg.owl versioning
+### Versioning
 Version number is indicated in the OWL header. Further we generate versions IRIs consisting of base URI and version number, that deference to the respective version of the artefact. Previous versions are archived in this repository. 
 
 Our version numbers are in the form of _X.Y.Z_ . _X_ indicates _major version_ - related changes may include the addition or removal of classes or substantial changes to the hierarchy or relations. _Y_ indicates _minor versions_ - related changes can include content changes e.g. of definitions or annotation properties that may adjust semantic meaning of a class. _Z_ indicates _patches_ which may include changes in spelling, changes of annotation properties that does not change semantic meaning.
 
-A list of all changes compared to previous version is given in our [Glossary specification page](https://owl.emglossary.helmholtz-metadaten.de).
+A list of all changes compared to previous version is given in our [glossary specification page](https://owl.emglossary.helmholtz-metadaten.de).
 
 ### OWL build pipeline
-The classes, class hierarchy and annotation properties are all sourced from the [yaml files](https://codebase.helmholtz.cloud/em_glossary/em_glossary/-/tree/main/terms) that are the output of our community process. Every merge to main in our [community repository](https://codebase.helmholtz.cloud/em_glossary/em_glossary) triggers a CI/CD pipeline that automatically assembles [emg-edit.owl](https://codebase.helmholtz.cloud/em_glossary/em_glossary_owl/-/blob/main/development/emg-edit.owl). Keys for annotation properties are sourced from external well-established vocabularies which are set up in [empty.owl](https://codebase.helmholtz.cloud/em_glossary/em_glossary_owl/-/blob/main/development/empty.owl), mappings are defined in [yaml_to_owl.py](https://codebase.helmholtz.cloud/em_glossary/em_glossary_owl/-/blob/main/development/yaml_to_owl.py) which is also the routine which carries out parsing.
+The classes, class hierarchy and annotation properties are all sourced from the [yaml files](https://codebase.helmholtz.cloud/em_glossary/em_glossary/-/tree/main/terms) that are the output of our community process. Every merge to main in our [community repository](https://codebase.helmholtz.cloud/em_glossary/em_glossary) triggers a CI/CD pipeline that automatically assembles [emg-edit.owl](https://codebase.helmholtz.cloud/em_glossary/em_glossary_owl/-/blob/main/development/emg-edit.owl). Keys for annotation properties are sourced from external well-established vocabularies which are set up in [empty.owl](https://codebase.helmholtz.cloud/em_glossary/em_glossary_owl/-/blob/main/development/empty.owl). The empty.owl is the input for the parsing routine in [yaml_to_owl.py](https://codebase.helmholtz.cloud/em_glossary/em_glossary_owl/-/blob/main/development/yaml_to_owl.py).
 
 # Other info