MiWoEx Onthologie

[eriktamsen]

This issue is related to the added concrete onthologies. We discussed this in the last Knowledge Graph meeting.
I am creating this to organize our branches, issues, etc.

This is the comment in the related PR from Jörg.

There are a couple of problems.

1. One is related to the fact that in the mapping procedure some of the deleted ontologies are still imported e.g. MergedAllCoreOntology.owl , EM.xml, ...
2. There is also the mseo_mid that is loaded, but owlready requires this in owl format (not in ttl as given here).

Could you please discuss with @AidaZt or (@soudehMasoudian @alFrie) to fix this. Currently, the tests are not working and thus I can't merge into the main branch.

[eriktamsen]

@mattheokru: we discussed the files in the ConcreteOntologie directory.
Two comments: 1) please move the data file, even if it is just for testing purposes to a relevant usecase, or even a new testing usecase.
2) it would be nice to rename the files to something understandable. So instead of CPTO, rather ConcreteProcess........, instead of EM or youngs_modulus_ontologie or something.

[alFrie]

@mattheokru
Renaming of the ontologies would be great, it also caused some confusion for me (as mentioned in #71 ).

For writing the mapping script for your ontology, we (@soudehMasoudian and I) need the ontology in .xml format. We could do that using Yue's drawio add-on, but if I got Stephan's mail correctly, then he'd rather have a "script for automatically converting into some consistent format".

So what should we do about the formatting? Using Yue's script? @eriktamsen @joergfunger

[alFrie]

@joergfunger @eriktamsen

I don't want to open a new issue since I guess this belongs here.
Mattheo, Aida, Soudeh and I had a meeting earlier. Thanks to Mattheo's manual mapping via Protege, we have now an example of what the mapped result should look like. But there are now some questions regarding how to proceed:

1. We wanted to agree on using turtle instead of RDF-format, since it's easier human-readable. Unfortunately turtle causes problems when being reopened in Protogege. Do you have any Preference? Because if ttl is no option for you, then we don't need to bother with it further.

2. The example data contains only three specimen, and all of them are inside the one resulted mapped file. Is this the goal or should later multiple maps be created, one per specimen/experiement? Because I remember that there was originally an issue opened for the topic of merging different knowledge graphs, I guess in order for older experiments not having to be redone once new experiments are added.

3. It seems to me now that the new way of mapping is taking the original RDF-file and making a copy of it, where all the placeholder-values are replaced with the actual data, correct? This means the mapping script is no longer hardcoded and fully dependend on the structure of the ontology. If I'm correct we then also don't need anymore the library OwlReady

4. Should we still continue for now Ilias mapping scripts (emodule and mixture) or wait with that task until we figured out how to properly map in the new way? It feels weird to continue working on a script that doesn't work well, while a much better new option is being developed.

[joergfunger]

1. Turtle is fine with me when working with the mapping. Not sure though why we would have to reopen it in protege. For me, the way to work with that would be to create all new classes and properties in protege (using owl). Once this is done, we would use the diagrams.net approach with the ontodocker to generate the T-Box and use the export with placeholders to generate the file (ttl) which we could use for the mapping (which then is just replace placeholder $author by the name that we have in the yaml file.
2. I don't see how we could put these all together. I think we agreed to have first the mixture being mapped, then the compression tests, and then the Young's modulus test. They are referring to each other (all are related to the mix), that's why the identifier to link them together is important but they should not be mapped together. Also in the future, people would generate the mix and upload it, and only afterwards there will be the compression test (also uploaded) and based on that result they would know what is the load to be applied to the Youngs modulus test. As such, at the end there is one KG. But each mapping introduces a subgraph is generated from the A-Box mapping, which then have to be joined/uploaded to the global triple store.
3. yes
4. From my point of view no, I would suggest focusing only on the new way. But please discuss that also with @AidaZt and Thilo.
   Happy holidays and happy new year :)

[alFrie]

1. I think this might be about editing the ontology, but I am not sure. Maybe @mattheokru can give some more details about this problem.
2. I ment combining multiple specimen (all mixture specimen f.e.) into one file - not different experiments (emodule, mixture and so on). In Mattheo's example there is probe1, probe2, probe3 all within the same RDF file. But from your answer I guess that it would be better to have one seperate graph for probe1, one for probe2 and so on.

Great, I'll ask Aida and Thilo! Update: Thilo agrees on focusing on a script for the MiWoEx-Ontology mapping.

Thank you! Happy Holidays!

[joergfunger]

All the different tests should finally be in the same graph (otherwise you can't query them jointly). But in order to get there, I think we would have to decompose the problem into first creating the sub graph related to one step of an experiment (so e.g. mix, compression, elasticity) and then upload that to the joint KG.