Replace Recommonmark by MyST (#188)

Fix leftover tags in admonitions

Author: create-issue-branch[bot]

docs/source/contribute.md

@@ -44,18 +44,18 @@ All wrappers and OSP-core are part of a common directory structure:
   The changes should be clearly explained in the issue/Pull Request.
 ```{warning}
    If the issue is a critical software bug detected in the stable release, a 
-   :code:`hotfix branch` should be created from the :code:`master/main` branch 
+   `hotfix branch` should be created from the `master/main` branch 
    instead. 
    
    After committing to such branch, a new Pull/Merge request (targeting 
-   :code:`dev`) should be created. If the fix is correct, the project owner 
-   will merge the PR to :code:`dev`, additionally merge the 
-   :code:`hotfix branch` to :code:`master/main`, and then delete the 
-   :code:`hotfix branch`.
+   `dev`) should be created. If the fix is correct, the project owner 
+   will merge the PR to `dev`, additionally merge the 
+   `hotfix branch` to `master/main`, and then delete the 
+   `hotfix branch`.
 ```
 - Once the features for a release have been reached, `dev` will be merged to 
   `master/main`. Every new commit in the `master/main` branch generally corresponds 
-  to a new release, which is labeled with a 
+  to a new release, which is labelled with a 
   [git tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) matching its 
   version number. An exception to this rule may apply, for example when several 
   critical hotfixes are applied in a row, as it would then be better to just to 

docs/source/detailed_design.md

@@ -468,7 +468,7 @@ cuds_obj = some_namespace.OntologyClass()
    and then they are yielded like a generator
 
 ```{hint}
-   There is also an :code:`is_a` method for checking oclass inheritance.
+   There is also an `is_a` method for checking oclass inheritance.
 ```
 
 ```{note}
@@ -626,10 +626,10 @@ This will define which methods have to be implemented and `_engine` as the acces
 trigger an action on the backend (`run` and `commit`, respectively).
 
 ```{note}
-   You might have noticed that the semantic layer defines :code:`remove` in the API,
-   but in the session and registry we use :code:`delete`. The different between them
-   is conceptual: :code:`remove` is interpreted as detachment i.e. removal of edges,
-   while :code:`delete` implies the erasure of the note itself.
+   You might have noticed that the semantic layer defines `remove` in the API,
+   but in the session and registry we use `delete`. The different between them
+   is conceptual: `remove` is interpreted as detachment i.e. removal of edges,
+   while `delete` implies the erasure of the node itself.
 ```
 
 #### Buffers

docs/source/general_architecture.md

@@ -114,7 +114,7 @@ For that, a 3 layer schema is used:
    backend -[hidden]-> spe
 ```
 
-- The *Semantic layer* are the classes generated from the ontology and follow the CUDS API.
+- The *Semantic layer* are the classes generated from the ontology with the CUDS API.
 - The *Interoperability layer* maps the changes in the semantic layer to calls in the syntactic layer.
 - The *Syntactic layer* provides access to the backend.