| ... | ... | @@ -5,7 +5,7 @@ You have questions about how emg.owl is developed, what the community process be |
|
|
|
Write an email to hmc@fz-juelich.de or hmc-matter@helmholtz-berlin.de or talk to us directly on [HMC public mattermost](https://mattermost.hzdr.de/hmc-public).
|
|
|
|
|
|
|
|
# About the EM Glossary
|
|
|
|
The EM_Glossary groups offers terminology that was harmonised through a community process. The full provenance of this process is documented in our [community repository](https://codebase.helmholtz.cloud/em_glossary/em_glossary) - please feel free to contribute to the development there. The full extend of the current artefact can be conveniently explored in our [webpage](emglossary.helmholtz-metadaten.de).
|
|
|
|
The EM_Glossary groups offers terminology that was harmonised through a community process. The full provenance of this process is documented in our [community repository](https://codebase.helmholtz.cloud/em_glossary/em_glossary) - please feel free to contribute to the development there. The full extend of the current artefact can be conveniently explored in our [webpage](https://emglossary.helmholtz-metadaten.de).
|
|
|
|
|
|
|
|
The idea behind the EM_Glossary is to offer community accepted, harmonised domain-level semantics for adoption to the application level. Using the EM_Glossary as a domain level bridge we intend to facilitate metadata alignment between different application cases such as metadata schemas that are recorded with different instruments or annotated using different dialects.
|
|
|
|
|
| ... | ... | @@ -25,13 +25,13 @@ The EM-Glossary provides stable domain-level semantics for adoption in different |
|
|
|
Here we provide some suggestions and guidance on how use and technical adoption may look like to harmonise re-use.
|
|
|
|
|
|
|
|
## Use in academic writing
|
|
|
|
In order to facilitate exploration and use of information in the EM-Glossary for the use in academic writing we provide the [EM-Glossary Web Explorer](emglossary.helmholtz-metadataten.de). This provides a term-level landing page in which minimally the term label, definition and contributors are shown. Further we also supply a citation suggestion at the bottom of the term-page. This can be conveniently copied to clipboard with the copy-button.
|
|
|
|
In order to facilitate exploration and use of information in the EM-Glossary for the use in academic writing we provide the [EM-Glossary Web Explorer](https://emglossary.helmholtz-metadataten.de). This provides a term-level landing page in which minimally the term label, definition and contributors are shown. Further we also supply a citation suggestion at the bottom of the term-page. This can be conveniently copied to clipboard with the copy-button.
|
|
|
|
|
|
|
|
In the future we are planning to provide bib-tex formatted data of the citation suggestion.
|
|
|
|
|
|
|
|
## Technical adoption in application level metadata & semantics
|
|
|
|
|
|
|
|
Irrespective your how you want to technically align metadata and semantics with EM-Glossary terminology, we look forward for you contact us about your plans. We are happy to discuss your planned way of alignment, compare to other adoption cases and would be happy to highlight you on our [webpage](emglossary.helmholzt-metadaten.de) as an adopter!
|
|
|
|
Irrespective your how you want to technically align metadata and semantics with EM-Glossary terminology, we look forward for you contact us about your plans. We are happy to discuss your planned way of alignment, compare to other adoption cases and would be happy to highlight you on our [webpage](https://emglossary.helmholzt-metadaten.de) as an adopter!
|
|
|
|
|
|
|
|
It is clear that different application cases may require closer or less close semantic alignment. Below we provide suggestions on technical implementation in order to harmonise re-use.
|
|
|
|
|
| ... | ... | @@ -55,11 +55,7 @@ Application level metadata is often collected and validated with metadata schema |
|
|
|
- import of classe from emg.owl with partial annotation properties
|
|
|
|
- alignment of own class
|
|
|
|
- crosswalk with e.g. sssom
|
|
|
|
-
|
|
|
|
keep emg IRI
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- keep emg IRI
|
|
|
|
|
|
|
|
How to adapt and use terminology from emg.owl in your application level artefact metadata
|
|
|
|
- how to technically adopt
|
| ... | ... | @@ -68,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](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
|
|
|
|
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 the our community process we expect at least 3 major releases per year.
|
|
|
|
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](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).
|
|
|
|
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
|
|
|
|
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 number 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 doe 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 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](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 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), 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.
|
|
|
|
|
|
|
|
# other info
|
|
|
|
|
| ... | ... | |
| ... | ... | |
