| ... | ... | @@ -76,10 +76,13 @@ In the future we intend to handle file changes and semantic versioning during re |
|
|
|
### 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.
|
|
|
|
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 any relations. _Y_ indicates _minor versions_ - related changes can include content changes e.g. of definitions or annotation properties that may slightly 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).
|
|
|
|
|
|
|
|
### Change management
|
|
|
|
With emg.owl we intend to provide stable semantics. This is ensured by classes going through a community definition and review process before being added to the artifact and released. IRIs in the artifact will stay stable according to semantic meaning of that class. I.e. minor changes or adjustments of definition, comment and annotation properties may be implemented without issuing a new IRI. Should the meaning of a previously existing class however change substantially, we will mark this class as obolete under the exiting IRI and introduce a new class under a new IRI. This is supposed to prevent unnoticed semantic drift during adoption. All changes to classes will be documented in the release descriptions.
|
|
|
|
|
|
|
|
### 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). 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).
|
|
|
|
|
| ... | ... | |
| ... | ... | |
