Merge pull request #112 from kbss-cvut/openmic-2023-12-15

one more fix

_posts/2023-12-15-open-mic-widoco-and-co.markdown

@@ -6,7 +6,8 @@ excerpt: "The presentation discussed the documentation generators and visualizat
 
 On Friday 15th December speaker [Michal Med](https://kbss.felk.cvut.cz/web/team#michal-med) was discussing the documentation generators and visualization tools for RDF data and ontologies.
 
-![Widoco and co](/assets/images/openmics/2023-12-15-widoco-and-co.png)
+
+{% include figure image_path="assets/images/openmics/2023-12-15-widoco-and-co.png" alt="Widoco & co" %}{: .post-image }
 
 At the Knowlegde-based and Software Systems Group, we often design and create ontologies and RDF data. The main problem with graph data is usually visualization and documentation -- data are basically well described for machine reading, but humans may have problems with interpretation of interlinked graphs determined by persistent IRIs and all attributes in the form of triples.
 
@@ -16,7 +17,7 @@ Presentation sums up the usage of both tools. What is missing in the presentatio
 
 Ontospy is simpler solution, allowing to generate documentation by one command entirely from the ontology itself. It supports generating of documentation in the form of one- or multi-page HTML, Markdown or generation of visualization of graphs using D3.js [3] library. Unlike Widoco, all the content is generated from the ontologies, adding no description text. As the generated otput is html file(s), it is no real problem to add anything needed straight into the HTML. Moreover, Ontospy has some features, that are not available in Widoco. The most important is probably filtering option and building tree structure of all concepts, or divided by the OWL stereotypes. On the other hand, Widoco allows users to edit the content of the ontology in a very simple way (by including predefined sections) and supports multilinguality (at least for some languages). Downside of the Widoco tool is the need of filling the selected parts of the web sections by hand (e.g. they are not generated by the tool automatically from the ontology).
 
-![Graph visualization generated by Ontospy](/assets/images/posts/ontospy.png)
+{% include figure image_path="assets/images/posts/ontospy.png" alt="Graph visualization generated by Ontospy" %}{: .post-image }
 
 Documentation is perfect for human readability of the understanding of the meaning of the ontology and its concepts, but we also need to dereference IRIs of the concepts in order to be machine-readable. For the machine readability we know about a few tools, that are mentioned in the presentation. A lot of those tools are dead, so the listed tools are mainly those still alive in the development, with one exception, which is Pubby [4]. The goal of those tools is to identifiy the IRI and return some information about the resource, mainly in the machine readable form. The available tools diverge mainly in the type of the data store of the original resource. For our usecase it is important NOT to use SPARQL endpoint. Our resources are uploaded to the server and available there in the form of RDF file serialization. For this usecase we may use LodView [5], another suitable solution limited by the SPARQL endpoint is RhizomerEye [6].