Skip to content

Changes

Page history
Update Home authored by Oonagh Mannix's avatar Oonagh Mannix
Hide whitespace changes
Inline Side-by-side
Home.md
View page @ 40dc7413
# Welcome to our Wiki
You have questions about how emg.owl is developed, what the community process behind the development is or how you can adopt terminology from the artefact for your own use or align your metadata with this artefact? Here we are trying to give you the answer!
# Contact
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 group 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 by writing comments and opening issues there. All terms in the current artifact release can be conveniently browsed in our EM Glossary Explorer [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.
<img
src="uploads/606b4c874e7a03be3ffb1d5cef5ec969/EMGlossary_GlueTechnology.png"
width="600"
alt="EM-Glossary interoperabiltiy" />
### Why OWL?
OWL is the [Web ontology language](https://www.w3.org/OWL/). It is the semantic web language and designed as part of the W3C's _semantic web technology_ stack including RDF, RDFS, SPARQL and others.
OWL is designed to represent rich and complex knowledge about things, groups of things, and relations between thing). Resources represented in OWL can be easily integrated and referenced in other semantic resources - below we give recommendations towards technical adoption of our owl artefacts in metadata schemas, semantic file formats or other OWL based semantic artefacts.
---
# How to adopt
The EM-Glossary provides stable domain-level semantics for adoption in different forms of application level metadata and semantic artefacts. Also definitions from the EM-Glossary may be used in academic work, e.g. when composing scientific texts of papers.
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](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](https://emglossary.helmholtz-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.
Every term in the EM-Glossary carries an "international resource identifier" (IRI). The IRIs are assigned to classes within emg.owl and are globally unique and fully persistent. The "IRIs assigned to EM-Glossary classes within emg.owl are globally unique and fully persistent to offer term-level dereferenceability of our artefact. IRIs consist of the base URI `https://purl.helmholtz-metadaten.de/emg/` (protocol + resolver address + name space) and a term specific extension in the form of `EMG_XXXXXXXX`. We use numeric term extensions rather than term labels to provide higher stability (e.g. in case term label are altered).
_Referencing classes in emg.owl using the designated class IRI is the minimum requirement for adoption of EM-Glossary terminology_
However for adoption of your application- or domain-level metadata and semantics with terminology in the EM-Glossary, we recommend:
- align your metadata as close and as in many places as possible with EM-Glossary terminology;
- use the OWL representation of the EM-Glossary, specifically use IRIs (see below) to reference to classes in emg.owl;
- cite the EM-Glossary in appropriate places of your output or publication.
### 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. Embedding links of the EM Glossary classes into a JSON Schema requires incorporating IRIs as references into the schema definitions. This can enhance the semantic richness of the JSON Schema and relate values in the schema to classes in the EM Glossary OWL artifact.
In order to do this you need to:
1. Identify the class in EM Glossary OWL you want to link to & copy its IRI.
2. Define the schema structure including properties that can represent EM Glossary IRIs.
3. Embed the IRIs as links to the respective EM Glossary class in the JSON Schema. For this keywords such as `description`, `examples` or custom annotations (using custom-defined keywords) can be used.
<details open>
Here an example how that could look in an example schema. The link to EM Glossary classes is established by embedding selected IRIs that relate to a data item in the schema by using and object called `ontologyLink`, with the properties `uri` and `label`. These are defined by custom-defined keywords:
```
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "ExampleSchema",
"description": "An example schema representing some imaginary data",
"type": "object",
"properties": {
"dataItem1": {
"type": "string",
"description": "A first data item in the example schema",
"ontologyLink": {
"uri": "https://purls.helmholtz-metadaten.de/emg/EMG_00000009",
"label": "Coherent beam"
}
},
"dataItem2": {
"type": "string",
"description": "Another data item in the example schema",
"ontologyLink": {
"uri": "https://purls.helmholtz-metadaten.de/emg/EMG_00000047",
"label": "Tilt correction"
}
},
},
"required": ["dataItem1", "dataItem2"]
}
```
Note however that a disadvantage of embedding ontology links into JSON-Schema is that the used keywords are not standard JSON Schema keywords and as a consequence might not be processed by tools that are programmed to process JSON schema on the standard keywords only.
</details>
Alternatively, we encourage the use of formats that can make use of linked data principles by design:
- [JSON-LD](https://json-ld.org/) - a lightweight Linked Data format. It is easy for humans to read and write.
- [linkML](https://linkml.io/) a general purpose modeling language that can be used with linked data, JSON, and other formalisms, and
- [YARRRML](https://rml.io/yarrrml/spec/#terminology) a human readable text-based representation for declarative generation rules. It is a subset of [YAML], a widely used data serialization language designed to be human-friendly.
<details open>
Here is an example how the use of EM Glossary terminology in a JSON-LD document could look like:
```
{
"@context": {
"CoherentBeam": "https://purls.helmholtz-metadaten.de/emg/EMG_00000009",
"TiltCorrection": "https://purls.helmholtz-metadaten.de/emg/EMG_00000047"
},
"@type": "ExampleDataSet",
"CoherentBeam": "Value1",
"TiltCorrection": "Value2",
}
```
</details>
### Semantic file formats
In semantic file formats, such as HDF5 based containers or NeXus we propose to introduce cross references as doc-strings or separate fields associated with key that carry emg.owl class IRIs. Stronger integration might be achieved through semantic import and alignment of related ontologies.
### Semantic artefacts (RDF, RDFs, OWL)
:construction: under construction - further content will be added :construction:
----
# 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.
### 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.
### 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 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).
Here we list which yaml keys are mapped to which annotation properties in owl:
| YAML | OWL | IRI |
| -- | -- | -- |
| label | rdfs:label | https://www.w3.org/2000/01/rdf-schema#label |
| definition | IAO:definition | http://purl.obolibrary.org/obo/IAO_0000115 |
| comment | skos:scopeNote | http://www.w3.org/2004/02/skos/core#scopeNote|
| acronym | OMO:acronym | http://purl.obolibrary.org/obo/OMO_0003012 |
| abbreviation | OMO:abbreviation | http://purl.obolibrary.org/obo/OMO_0003000 |
| exact_synonym | GO:hasExactSynonym | http://www.geneontology.org/formats/oboInOwl#hasExactSynonym|
| narrow_synonym | GO:hasNarrowSynonym | http://www.geneontology.org/formats/oboInOwl#hasNarrowSynonym|
| broad_synonym | GO:hasBroadSynonym | http://www.geneontology.org/formats/oboInOwl#hasBroadSynonym|
| related_synonym| GO:hasRelatedSynonym| http://www.geneontology.org/formats/oboInOwl#hasRelatedSynonym|
| sources | IAO:definitionSource| http://purl.obolibrary.org/obo/IAO_0000119|
| subclassOf | rdfs:subClassOf | https://www.w3.org/2000/01/rdf-schema#subClassOf|
| examples | skos:example | http://www.w3.org/2004/02/skos/core#example |
| seeAlso | rdfs:seeAlso | https://www.w3.org/2000/01/rdf-schema#seeAlso|
| contributors | dcterms:contributor | http://purl.org/dc/elements/1.1/contributor|
# Other info
### Cite this repository
Please cite this repository as: Azocar Guzman, A., Brendike-Mannix, O., Hofmann, V. (2024), Electron Microscopy Glossary, https://purls.helmholtz-metadaten.de/emg/
Further citation info can be found in our [CITATION.cff](https://codebase.helmholtz.cloud/em_glossary/em_glossary_owl/-/blob/main/CITATION.cff).
### License
# Welcome to our Wiki
You have questions about how emg.owl is developed, what the community process behind the development is or how you can adopt terminology from the artefact for your own use or align your metadata with this artefact? Here we are trying to give you the answer!
# Contact
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 group 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 by writing comments and opening issues there. All terms in the current artifact release can be conveniently browsed in our EM Glossary Explorer [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.
<img
src="uploads/606b4c874e7a03be3ffb1d5cef5ec969/EMGlossary_GlueTechnology.png"
width="600"
alt="EM-Glossary interoperabiltiy" />
### Why OWL?
OWL is the [Web ontology language](https://www.w3.org/OWL/). It is the semantic web language and designed as part of the W3C's _semantic web technology_ stack including RDF, RDFS, SPARQL and others.
OWL is designed to represent rich and complex knowledge about things, groups of things, and relations between thing). Resources represented in OWL can be easily integrated and referenced in other semantic resources - below we give recommendations towards technical adoption of our owl artefacts in metadata schemas, semantic file formats or other OWL based semantic artefacts.
---
# How to adopt
The EM-Glossary provides stable domain-level semantics for adoption in different forms of application level metadata and semantic artefacts. Also definitions from the EM-Glossary may be used in academic work, e.g. when composing scientific texts of papers.
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](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](https://emglossary.helmholtz-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.
Every term in the EM-Glossary carries an "international resource identifier" (IRI). The IRIs are assigned to classes within emg.owl and are globally unique and fully persistent. The "IRIs assigned to EM-Glossary classes within emg.owl are globally unique and fully persistent to offer term-level dereferenceability of our artefact. IRIs consist of the base URI `https://purl.helmholtz-metadaten.de/emg/` (protocol + resolver address + name space) and a term specific extension in the form of `EMG_XXXXXXXX`. We use numeric term extensions rather than term labels to provide higher stability (e.g. in case term label are altered).
_Referencing classes in emg.owl using the designated class IRI is the minimum requirement for adoption of EM-Glossary terminology_
However for adoption of your application- or domain-level metadata and semantics with terminology in the EM-Glossary, we recommend:
- align your metadata as close and as in many places as possible with EM-Glossary terminology;
- use the OWL representation of the EM-Glossary, specifically use IRIs (see below) to reference to classes in emg.owl;
- cite the EM-Glossary in appropriate places of your output or publication.
### 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. Embedding links of the EM Glossary classes into a JSON Schema requires incorporating IRIs as references into the schema definitions. This can enhance the semantic richness of the JSON Schema and relate values in the schema to classes in the EM Glossary OWL artifact.
In order to do this you need to:
1. Identify the class in EM Glossary OWL you want to link to & copy its IRI.
2. Define the schema structure including properties that can represent EM Glossary IRIs.
3. Embed the IRIs as links to the respective EM Glossary class in the JSON Schema. For this keywords such as `description`, `examples` or custom annotations (using custom-defined keywords) can be used.
<details open>
Here an example how that could look in an example schema. The link to EM Glossary classes is established by embedding selected IRIs that relate to a data item in the schema by using and object called `ontologyLink`, with the properties `uri` and `label`. These are defined by custom-defined keywords:
```
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "ExampleSchema",
"description": "An example schema representing some imaginary data",
"type": "object",
"properties": {
"dataItem1": {
"type": "string",
"description": "A first data item in the example schema",
"ontologyLink": {
"uri": "https://purls.helmholtz-metadaten.de/emg/EMG_00000009",
"label": "Coherent beam"
}
},
"dataItem2": {
"type": "string",
"description": "Another data item in the example schema",
"ontologyLink": {
"uri": "https://purls.helmholtz-metadaten.de/emg/EMG_00000047",
"label": "Tilt correction"
}
},
},
"required": ["dataItem1", "dataItem2"]
}
```
Note however that a disadvantage of embedding ontology links into JSON-Schema is that the used keywords are not standard JSON Schema keywords and as a consequence might not be processed by tools that are programmed to process JSON schema on the standard keywords only.
</details>
Alternatively, we encourage the use of formats that can make use of linked data principles by design:
- [JSON-LD](https://json-ld.org/) - a lightweight Linked Data format. It is easy for humans to read and write.
- [linkML](https://linkml.io/) a general purpose modeling language that can be used with linked data, JSON, and other formalisms, and
- [YARRRML](https://rml.io/yarrrml/spec/#terminology) a human readable text-based representation for declarative generation rules. It is a subset of [YAML], a widely used data serialization language designed to be human-friendly.
<details open>
Here is an example how the use of EM Glossary terminology in a JSON-LD document could look like:
```
{
"@context": {
"CoherentBeam": "https://purls.helmholtz-metadaten.de/emg/EMG_00000009",
"TiltCorrection": "https://purls.helmholtz-metadaten.de/emg/EMG_00000047"
},
"@type": "ExampleDataSet",
"CoherentBeam": "Value1",
"TiltCorrection": "Value2",
}
```
</details>
### Semantic file formats
In semantic file formats, such as HDF5 based containers or NeXus we propose to introduce cross references as doc-strings or separate fields associated with key that carry emg.owl class IRIs. Stronger integration might be achieved through semantic import and alignment of related ontologies.
### Semantic artefacts (RDF, RDFs, OWL)
:construction: under construction - further content will be added :construction:
----
# 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.
### 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.
### 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 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 - 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 change substantially, we will mark this class as obsolete 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).
Here we list which yaml keys are mapped to which annotation properties in owl:
| YAML | OWL | IRI |
| -- | -- | -- |
| label | rdfs:label | https://www.w3.org/2000/01/rdf-schema#label |
| definition | IAO:definition | http://purl.obolibrary.org/obo/IAO_0000115 |
| comment | skos:scopeNote | http://www.w3.org/2004/02/skos/core#scopeNote|
| acronym | OMO:acronym | http://purl.obolibrary.org/obo/OMO_0003012 |
| abbreviation | OMO:abbreviation | http://purl.obolibrary.org/obo/OMO_0003000 |
| exact_synonym | GO:hasExactSynonym | http://www.geneontology.org/formats/oboInOwl#hasExactSynonym|
| narrow_synonym | GO:hasNarrowSynonym | http://www.geneontology.org/formats/oboInOwl#hasNarrowSynonym|
| broad_synonym | GO:hasBroadSynonym | http://www.geneontology.org/formats/oboInOwl#hasBroadSynonym|
| related_synonym| GO:hasRelatedSynonym| http://www.geneontology.org/formats/oboInOwl#hasRelatedSynonym|
| sources | IAO:definitionSource| http://purl.obolibrary.org/obo/IAO_0000119|
| subclassOf | rdfs:subClassOf | https://www.w3.org/2000/01/rdf-schema#subClassOf|
| examples | skos:example | http://www.w3.org/2004/02/skos/core#example |
| seeAlso | rdfs:seeAlso | https://www.w3.org/2000/01/rdf-schema#seeAlso|
| contributors | dcterms:contributor | http://purl.org/dc/elements/1.1/contributor|
# Other info
### Cite this repository
Please cite this repository as: Azocar Guzman, A., Brendike-Mannix, O., Hofmann, V. (2024), Electron Microscopy Glossary, https://purls.helmholtz-metadaten.de/emg/
Further citation info can be found in our [CITATION.cff](https://codebase.helmholtz.cloud/em_glossary/em_glossary_owl/-/blob/main/CITATION.cff).
### License
All content in this repository is licensed under [MIT license](https://codebase.helmholtz.cloud/em_glossary/em_glossary_owl/-/blob/main/LICENSE)
\ No newline at end of file

A HIFIS Service | Privacy | Imprint | Support | Documentation | Changelog