How Owl 2.0 Imports Work

OWL 2.0 Imports

My understanding is that OWL 2.0 imports are based on an import by location scheme. In section 3.2 of the Structural Specification and Functional-Style Syntax, the notion of using an IRI to access an ontology document is introduced:

• "Each ontology document can be accessed from an IRI by means of an appropriate protocol."
• "Each ontology document can be converted in some well-defined way into an ontology (i.e., into an instance of the Ontology class from the structural specification)."

This notion of access has some provisions the idea that tools may redirect access to an ontology to a different location:

"OWL 2 tools will often need to implement functionality such as caching or off-line processing, where ontology documents may be stored at addresses different from the ones dictated by their ontology IRIs and version IRIs. OWL 2 tools may implement a redirection mechanism: when a tool is used to access an ontology document at IRI I, the tool may redirect I to a different IRI DI and access the ontology document from there instead. The result of accessing the ontology document from DI must be the same as if the ontology were accessed from I."

The important part of this quote is the last line where it is indicated that the result of a redirection should be the same as the result that would be obtained from using the IO-scheme indicated by the IRI. Thus the results of performing an IO operation is the final arbiter of the intended meaning of the import.

This scheme essentially views imports as IO-directives. This is a very simple approach to ontology imports when the IO operations behave the same for all users viewing an ontology document. In these days of a highly reliable and accessible internet this assumption will often hold. Most import directives point to the internet and these directives are usually easily resolved. However there are a variety of situations where the IO-directive based approach will not work very well:

• a user is offline for a period. Even in these days there are situations where users do not have reliable access to the internet.
• a application cannot trust the IO operations specified in the imports directives. In particular, many applications must be able to perform even when the internet is not available.
• the IO-mechanism indicated by the imports directive is protected by security mechanisms such as a firewall.
• the IO-mechanism indicated by the imports directive is only applicable in a particular runtime environment. For instance, increasingly users are developing ontologies that are accessible when some local implementation of web container (e.g. tomcat) or agent based environment is running.

Each of these situations creates a challenge for users or developers who want to share ontologies.