Closed giacomoronconiobda closed 1 year ago
The problem with changing this is with imports resolution when loading ontologies.
While an ontology has an IRI and a version IRI, the owl:imports feature only allows for an IRI to be specified, and this must match the ontology IRI.
If a manager contains more than one ontology with the same IRI and distinguishes them on the basis of the version IRI, it cannot determine which of the two ontologies are specified when resolving an owl:imports directive from an ontology being loaded. This would force it to download the imported ontology from the IRI specified, rather than using a local copy; this will disable the caching abilities of the manager, as well as the ability to override remote imports, e.g., to work around bugs in upper ontologies.
The only way to work around all three issues (caching; override bugs in imported ontologies; allow multiple ontologies with the same otology IRI in the same manager) would be to amend the OWL specs to have both ontology IRI and version IRI on owl:imports, and a mechanism to determine which version to use when no version is specified. This would be quite a shift in the specs, so it's not likely to happen in the short term. Least worst solution is to leave out the last requirement and have a different ontology manager for each version of an ontology.
I think the
OWLOnotlogyID
should match checking the ontology version iri when it is present (i.e. using the already implementedequals
).I've had some problems loading into the
OWLOntologyManager
multiple "same ontology iri" (e.g.http://example.com/
ontologies with increasing versions (e.g.http://example.com/1.0
,http://example.com/1.1
).More precisely when the
contains(OWLOntologyID)
is called: https://github.com/owlcs/owlapi/blob/3bce72460c87fd20e1ef2479273f375a7cdaae21/impl/src/main/java/uk/ac/manchester/cs/owl/owlapi/OWLOntologyManagerImpl.java#L366