Skip to content

Changes

Page history
Update Home authored by Oonagh Mannix's avatar Oonagh Mannix
Show whitespace changes
Inline Side-by-side
Home.md
View page @ b004173f
# 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!
You have questions about how emg.owl is developed, what the community process behind the development is, how you can adopt terminology from the artifact for your own use, or how to align your metadata with this artifact? Here we provide 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 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.
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"
......@@ -17,11 +17,11 @@ The idea behind the EM_Glossary is to offer community accepted, harmonised domai
### 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 things. 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.
OWL is designed to represent rich and complex knowledge about things, groups of things, and relations between things. Resources represented in OWL can be easily integrated and referenced in other semantic resources - below we give recommendations towards technical adoption of our OWL artifacts in metadata schemas, semantic file formats or other OWL based semantic artifacts.
---
# 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.
The EM-Glossary provides stable domain-level semantics for adoption in different forms of application level metadata and semantic artifacts. In addition definitions from the EM-Glossary may be used to ensure clarity in academic work - such when composing scientific texts or 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
......@@ -35,7 +35,7 @@ Irrespective of how you want to technically align metadata and semantics with EM
It is clear that different application cases may require closer or less close semantic alignment. Below we provide suggestions on technical implementation 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 for stability (e.g. in case term labels are altered).
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 artifact. 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 for stability (in case term labels are altered).
_Referencing classes in emg.owl using the designated class IRI is the minimum requirement for adoption of EM-Glossary terminology_
......@@ -48,9 +48,9 @@ For adoption of your application- or domain-level metadata and semantics with te
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.
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>
......@@ -114,23 +114,23 @@ Here is an example how the use of EM Glossary terminology in a JSON-LD document
### 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)
### Semantic artifacts (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.
The current artifact 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.
For release cycle, release management and [semantic versioning](https://semver.org/) we follow generally established best practices for the emg.owl artifact. We intend to keep the semantic artifact 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.
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 artifact. 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 HIFIS Service | Privacy | Imprint | Support | Documentation | Changelog