Meeting Notes - 16.09.2022

# Meeting Notes - 16.09.2022 **Participants**: - [x] Casper Welzel Andersen - [ ] Rickard Armiento - [x] Francesca Lønstad Bleken - [ ] Matthias Büschelberger - [ ] Stuart Chalk - [ ] Kathrin Frei - [ ] Jesper Friis - [x] Emanuele Ghedini - [ ] Luca Ghiringhelli - [ ] Gerhard Goldbeck - [ ] Saulius Grazulis - [x] James Hester - [ ] Antanas Vaitkus - [ ] Nathan Daelman ## Overview Looking back at the latest meeting (19/8), we were discussing the `dic2owl` conversion tool, and its usage for other `.dic` files. This was concluded at the time to not be overly worrysome, in terms of execution - it was more to do with the integrity of the `.dic` files themselves. ## Current state of CIF-ontology Casper presented the documentation in its current state from a locally running documentation server, presenting how the CIF Core ontology is auto-generated using `dic2owl` upon building the documentation, and the plans to also auto-generate the table of versions within the documentation, which will link to the respective Turtle files (ontology files). Emanuele mentioned that the generated CIF Core ontology should be published, along with the CIF DDL (top) ontology. It would also be good to start the article describing the general method for developing the generation tool (`dic2owl`) as well as the generation of the CIF DDL ontology to use as a top ontology for further ontology generations. ## Interface between a CIF file and the CIF-ontology The next steps of converting between the CIF file and CIF-ontology was mentioned. The general concept here is outdated and misinterpreted. Misinterpreted because the data of a CIF file should not be represented as RDF triples, but rather, a specific implementation should be able to map the data values or data properties from the CIF file to concepts in the ontology. These mappings will be RDF triples and will define the coupling/interface between CIF files and its data model ontology, i.e., the CIF-ontology. The point of this is to have the CIF-ontology concepts link/map to other ontological concepts in any ontology one wishes to use. Another specific implementation then has its own data model it can map to the chosen "own" ontology, from there the linking/mapping to the CIF-ontology can be utilized to finally utilize the mapping RDF triples to an actual CIF-file, where the data may be retrieved and returned to the user. This general concept is currently being implemented in [OTEAPI](https://github.com/EMMC-ASBL/oteapi-core), a framework built within [the OntoTrans project](https://ontotrans.eu/). The specific implementation we're using at SINTEF is called [SOFT](https://github.com/SINTEF/soft7)/[DLite](https://github.com/SINTEF/dlite), which is centered around its own Data Model ontology. ## Developing the Crystallography domain ontology Emanuele wanted to move into discussing how the Crystallography domain ontology could be populated. He presented slides from an [OntoCommons](https://ontocommons.eu/) context, where they have developed an elegant template for creating new ontology concepts - also describing the different "label" annotations (prefLabel, altLabel, hiddenLabel). James suggested to use this template to start populating the domain ontology based on the generated CIF concepts, giving the individual concepts more "general" names and then moving on from there. Links to the: template: https://github.com/OntoCommons/OntologyFramework/blob/dev/bridge-concept-template.md examples: https://github.com/OntoCommons/OntologyFramework/tree/dev/owl/MRO/doc ## Homework Using the above template, select a concept and fill in the middle and top sections. For example, the "bridge" part of the template for "crystal" would collect together the various ideas we've discussed for defining a crystal, such as "reciprocal space definition" "real-space definition" "pre-1913 definition" "ideal infinite lattice" "lattice with physical boundaries". Then the top part of the template would include a definition that covered some (probably not all) of those concepts - any items left out would just be the subject of a separate definition which could also be found by searching for "crystal". If we select the same concept no big issue as comparing and contrasting will help produce a better definition.