I'm mapping a remote ontology to a local copy as following:
OWLOntologyManager manager = OWLManager.createOWLOntologyManager();
IRI documentIRI = IRI.create(new File("ontologies/localOntology.owl"));
IRI remoteIRI=IRI.create("https://protege.stanford.edu/ontologies/pizza/pizza.owl");
SimpleIRIMapper mapper = new SimpleIRIMapper(remoteIRI, documentIRI);
manager.getIRIMappers().add(mapper);
OWLOntology ontology = manager.loadOntology(remoteIRI);
manager.saveOntology(ontology, new OWLXMLDocumentFormat());
Is this the correct way to use IRIMap? What if localOntology.owl contains something different from the remote ontology? It seems that I'm manipulating the local ontology regardless the content of the remote ontology, since, for example, if we use ontology.getAxiomCount() with localOntology.owl an empty ontology, we get "0", coherently with the content of localOntology but not with the remote ontology. Should "ontology" be aligned with the remote ontology but stored in localOntology.owl after the mapping? Thank you.
The purpose of IRI mapping is just to redirect from one IRI to another - the most common use case is to avoid downloading a remote ontology multiple times. However, ensuring the local copy is in sync with the remote one (assuming the remote one is the 'master' ontology, the one other users will be using in their systems) is a task that no IRI mapper implementation undertakes.
There is no universal strategy for resolving diffs between local and remote ontology - for example, in some situations synchronizing the remote and local ontology will always be the right thing to do; when the local copy is used as a cache, losing remote updates is a bug.
In other situations, updating from the remote ontology is wrong - for example, when testing the performance of different reasoners on an ontology, if the ontology imports remote ontologies that might change during the experiment, then using an unchanging local copy is better than picking the latest updates; a change might affect the comparison results in undetectable ways, and break repeatability.
Therefore, OWL API leaves the implementation of the correct strategy to the calling code, rather than take decisions which might cause issues that are difficult to detect.