The TypeOntologyHandler and the TPVersionIRIHandler combined have some strange behaviour with respect to the current ontology ID when importing an RDF/XML ontology multiple times.
My use case is to be able to import the same ontology multiple times, with the system intelligently modifying the version IRI to be unique each time before the import, but calling the following code twice with the same documentSource fails the second time when the uniqueOWLOntologyID has a different version IRI.
The ontology document in each case is identical, but that should not hamper the ability of the system to store a new version with a unique ontologyID if the ontologyVersionIRI is setup to be unique before the parse occurs. The first time through the code, the ontologyIRI and the ontologyVersionIRI both match the InputStream in the documentSource that is being parsed, while the second time through, the ontologyIRI matches, but the ontologyVersionIRI is setup to be unique. The ontologyManager is created fresh before the test, so it does not contain any other ontologies.
The ontology document (written in RDF/XML, so uses RDFXMLParser and OWLRDFConsumer) contains both ontology IRI in the form "<ontologyIRI> rdf:type owl:Ontology" and ontology version in the form <ontologyIRI> owl:versionIRI <ontologyVersionIRI>" The raw RDF/XML is as follows (if it doesn't get clobbered by SourceForge)
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Ontology" />
<owl:versionIRI rdf:resource="http://test.example.org/ontology/0139/version:1" />
The exceptions stack trace, before my patch was applied (using https://github.com/ansell/owlapi/tree/ansellpatches so the line numbers will not match up exactly) is:
OWLOntologyManagerImpl.checkForOntologyIDChange\(OWLOntologyChange\) line: 488 OWLOntologyManagerImpl.enactChangeApplication\(OWLOntologyChange\) line: 379 OWLOntologyManagerImpl.applyChanges\(List<OWLOntologyChange>\) line: 398 OWLOntologyManagerImpl.applyChange\(OWLOntologyChange\) line: 435 OWLRDFConsumer.applyChange\(OWLOntologyChange\) line: 959 OWLRDFConsumer.setOntologyID\(OWLOntologyID\) line: 963 TPVersionIRIHandler.handleTriple\(IRI, IRI, IRI\) line: 68 OWLRDFConsumer.handle\(IRI, IRI, IRI\) line: 1315 OWLRDFConsumer$1.handleResourceTriple\(IRI, IRI, IRI\) line: 1454 OWLRDFConsumer.iterateResourceTriples\(ResourceTripleIterator<E>\) line: 2434 OWLRDFConsumer.endModel\(\) line: 1452 RDFXMLParser$1\(RDFParser\).parse\(InputSource, RDFConsumer\) line: 175 RDFXMLParser.parse\(OWLOntologyDocumentSource, OWLOntology, OWLOntologyLoaderConfiguration\) line: 120 RDFXMLParser.parse\(OWLOntologyDocumentSource, OWLOntology\) line: 74
The issue seems to have two causes. Firstly, the handleTriple method in TypeOntologyHandler is executed before TPVersionIRIHandler and removes the ontologyVersionIRI, and then the ontologyVersionIRI is also overwritten without verifying that the versionIRI is null in TPVersionIRIHandler anyway, so it looks like it would require both classes to be modified to fix the bug and preserve existing OntologyID's during parsing.
I am attaching a patch that fixed both of these issues for me, including tests to verify the desired behaviour in different scenarios.
Log in to post a comment.