[QUESTION] - How to configure the input directory(owl2oml)? Are all imported relative ontologies in my '.owl' file needed?

[UncleXie123]

Description

I'm trying to transfer the bfo-core.owl into .oml by the owl2oml adapter. I run the source code as CLI in IDEA and had overcame sevel problems:

1. The inputCatalogPath and the outputCatalogPath have to be absolute path in my machine;

2. In Owl2Oml.java there is a visitOntology() method performs important role, inside that the OML type will be checked: So the input bfo-core.owl file must have OML annotations porperties, ie: http://opencaesar.io/oml#namespace, http://opencaesar.io/oml#prefix, and http://opencaesar.io/oml#type (especially this one).

3. As the BFO is set to be oml vocabulary, it invoke visitVocabulary() method like: And in this method, the imports, annotations, and the axioms of BFO will be visit: In visitAnnotations(), the getImportedIri() will be execute: like this: The 'ontologyIri' here may be ontologies like http://purl.org/dc/elements/1.1, http://purl.org/dc/terms/, http://www.w3.org/2004/02/skos/core# and many others which must be put in input directory as .owl files (I try to get them online by manager.loadOntologyFromOntologyDocument(ontologyIri) but obviously I failed). So I tried to use the input directory below and it seems to work. Am I right? Is this a effective way? And where can I get ontologies like http://purl.org/dc/terms/(for annotation properties), http://purl.obolibrary.org/obo/(for axioms), and so on to to transfer the bfo-core.owl into .oml.

Additional Context

My input directory: │ ├─owl │ │ ├─bfo │ │ │ │ bfo-core.owl │ │ │ │ catalog.xml │ │ │ │
│ │ │ └─purl.org │ │ │ └─dc │ │ │ └─elements │ │ │ 1.1.owl

My output directory: │ │ ├─oml │ │ │ ├─bfo │ │ │ │ bfo-core.oml │ │ │ │ catalog.xml

The files I use:

inputs: owl.zip outputs: oml.zip

[melaasar]

The OWL to OML adapter actually supports two levels of conversion:

• Oml2Owl: converts owl ontologies that were produced by Oml2Owl
• Oml2OwlEx: converts owl ontologies that were not produced by Oml2Owl

The first one is used in the current production release, while the other one is still WIP but could be used with a one line change in Owl2OmlApp class from:

var ontologies = new Owl2Oml(manager, builder, outputCatalog, outputFileExtension).run(owlOntology);

to

var ontologies = new Owl2OmlEx(manager, builder, outputCatalog, outputFileExtension).run(owlOntology);

As you have observed, the Owl2Oml adapter assumes that all imported IRIs in the owl files can be resolved to actual files through the input catalog. You either get those from their authoritative online sources (if they exist), or you can create stubs for them directly in your input folder. This should be easy in your case since they are simple annotation properties. For example, this is how you can create a stub for the http://purl.org/dc/terms/ ontology:

Assuming your input catalog input-catalog-folder/catalog.xml has the simple mapping rule:

<rewriteURI uriStartString="http://" rewritePrefix="./" />

You can create the file: input-catalog-folder/purl.org/dc/terms.ttl (in turtle or any other rdf format) with the content:

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

dcterms:abstract a owl:AnnotationProperty  .
dcterms:accessRights a owl:AnnotationProperty .

[UncleXie123]

The OWL to OML adapter actually supports two levels of conversion:

• Oml2Owl: converts owl ontologies that were produced by Oml2Owl
• Oml2OwlEx: converts owl ontologies that were not produced by Oml2Owl

The first one is used in the current production release, while the other one is still WIP but could be used with a one line change in Owl2OmlApp class from:

var ontologies = new Owl2Oml(manager, builder, outputCatalog, outputFileExtension).run(owlOntology);

to

var ontologies = new Owl2OmlEx(manager, builder, outputCatalog, outputFileExtension).run(owlOntology);

As you have observed, the Owl2Oml adapter assumes that all imported IRIs in the owl files can be resolved to actual files through the input catalog. You either get those from their authoritative online sources (if they exist), or you can create stubs for them directly in your input folder. This should be easy in your case since they are simple annotation properties. For example, this is how you can create a stub for the http://purl.org/dc/terms/ ontology:

Assuming your input catalog input-catalog-folder/catalog.xml has the simple mapping rule:

<rewriteURI uriStartString="http://" rewritePrefix="./" />

You can create the file: input-catalog-folder/purl.org/dc/terms.ttl (in turtle or any other rdf format) with the content:

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

dcterms:abstract a owl:AnnotationProperty  .
dcterms:accessRights a owl:AnnotationProperty .

Yes. I've solved this by creating some OML projects only for "skos, dectrms..." and federating them to my bfo-core project. It works well, but the oml-to-owl adapter still seems to be hard-use for solving sematic inconsistence problems while turing the bfo-core in Manchester syntax into OML syntax. For example, I found the Manchester syntax "Disjointwith" in certain concepts and relations can not be repesent in OML directly, so may be some OML "rules" will solve this issue?