Difference between revisions of "How Owl 2.0 Imports Work"

From Protege Wiki
Jump to: navigation, search
(→‎OWL 2.0 Imports)
(→‎OWL 2.0 Imports)
Line 1: Line 1:
 
= OWL 2.0 Imports =
 
= OWL 2.0 Imports =
  
−
[http://www.w3.org/TR/owl2-syntax/#Imports OWL 2.0 imports] work through import by location. This means that imports work just like an html link. - it views the imported resource as a URL and follows it.  Sometimes users will want to redirect the import statements however.  Here are some examples:
+
'''Under Construction!'''
−
# the imports point to the internet but the user wants to edit the ontologies on his disk,
 
−
# the imports point to one users local file system and the person reading the ontology does not have access to those file locations (this is probably not recommended practice),
 
−
# the imports statements assume that some web container such as tomcat is running on the local machine.
 
−
In these cases the recommended practice is to use an  [http://www.oasis-open.org/committees/entity/spec-2001-08-06.html XML Catalog] that defines how the imported URL's should be redirected.  But as far as I know, none of the tools have yet implemented this mechanism.
 
  
−
This page will be expanded as new developments arise.
+
 
 +
== Motivation ==
 +
 
 +
In OWL 2, imports are handled differently than they are in OWL 1.0. There have been two main changes
 +
* added support for versions of an ontology
 +
* using import by location rather than import by name.
 +
The first of these changes is easily explained.  In the OWL 2.0 scheme, an ontology can have two IRI's in its name.  The first IRI is the ontology IRI.  The second name is the version IRI for the ontology.  In many cases the version IRI will be null. But when the version IRI is not null, this will mean that the ontology is a specific version of the ontology.
 +
 
 +
Thus for example, I might have an ontology that I am working on which I call
 +
<pre>
 +
  http://www.tigraworld.com/protege/determinants.owl.
 +
</pre>
 +
After a while I start needing versions of this ontology, so I create an ontology with an ontology IRI
 +
<pre>
 +
  http://www.tigraworld.com/protege/determinants.owl
 +
</pre>
 +
and a version IRI
 +
<pre>
 +
  http://www.tigraworld.com/protege/determinants-1.0.owl.
 +
</pre>
 +
A later published verion of this ontology might have the version IRI
 +
<pre>
 +
  http://www.tigraworld.com/protege/determinants-2.0.owl.
 +
</pre>
 +
The scheme by which these versions are named is not defined by the OWL 2.0 specification.
 +
 
 +
The intent is that these IRI's can be used to look up an ontology.  If an ontology has a version IRI then following the version IRI using specified protocol should retrieve the ontology with that version. Thus version 1.0 of the determinants ontology can be found at the web location
 +
<pre>
 +
  http://www.tigraworld.com/protege/determinants-1.0.owl.
 +
</pre>
 +
Following the ontology IRI, e.g.
 +
<pre>
 +
  http://www.tigraworld.com/protege/determinants.owl.
 +
</pre>
 +
should retrieve the latest version of that ontology (which may or may not have a version IRI).
 +
 
 +
When importing, these two names allow ontology developers to specify which version of an ontology they want to import.  The can specify a version of an ontology by importing the ontology version IRI.  They can specify the latest version of an ontology by importing the ontology IRI.
 +
 
 +
The second change to OWL 2.0 imports is more difficult to explain.  The reason that OWL 2.0 changed to import by location is that in many cases ontologies cannot be found by name.  Usually when an ontology is first created, it can be found by its name.  But over time the name stops working because either
 +
* ontologies are moved to reside on a different server and can no
 +
longer be found by using the old server,
 +
* purls are not maintained.
 +
Even the w3c is unable to keep urls permanent (e.g. the SWRL vocabulary declarations).
 +
 
 +
When this happend the import by name scheme becomes awkward.  Suppose that I am creating an ontology and I give it the name
 +
<pre>
 +
  http://www.tigraworld.com/protege/determinants.owl.
 +
</pre>
 +
Initially I am the developer of this ontolgy and I place the ontology at that site.  Unfortunately, for some reason this site no longer exists and if I wrote a really good ontology other people want to continue using it.  So the ontology is then placed at a new location
 +
<pre>
 +
  http://www.stanford.edu/junit/determinants-test01.owl.
 +
</pre>
 +
With the import by name scheme, ontology developers wishing to access this ontology are in a awkward situation.  They can either disobey the OWL 1.0 specification and import by location or they can import by name.  If they import by location, things work well when users are online. When a user is online, tools will follow and import the desired ontology.  The import will be found but the tool will generate a warning that the import is malformed.  If the ontology developer has no control over the determinants ontology, then this is the best he can do in this case.
 +
 
 +
But this method works badly if users download the ontology and then try to work offline. The OWL repository mechansims simply can't link the import statement
 +
<pre>
 +
  import http://www.stanford.edu/junit/pizza-test01.owl
 +
</pre>
 +
to the ontology with the name
 +
<pre>
 +
  http://www.tigraworld.com/protege/pizza.owl.
 +
</pre>
 +
The OWL 1.0 answer to this is that the import should import by name. But importing by name makes it impossible for tools to find the imported ontology when users are online and don't have access to some searchable repository of ontologies.
 +
 
 +
The OWL 2.0 solution to this problem is to use import by location and XML catalogs.  The recommended import statement would look like this:
 +
<pre>
 +
      import http://www.stanford.edu/junit/pizza-test01.owl.
 +
</pre>
 +
When users are online and want to access the ontologies through their web addresses, they can easily find the desired pizza ontology. 
 +
 
 +
When ontology developers want to work offline, they must find or generate an xml catalog.  XML Catalogs are an industry standard language allowing users to specify (among other things) redirection of IRI addresses to alternative addresses.  Thus in this case the ontology developer must create an XML catalog that redirects the IRI
 +
<pre>
 +
      http://www.stanford.edu/junit/pizza-test01.owl.
 +
</pre>
 +
found in the import statement to a different (possibly relative from the XML Catalog location) IRI containing  the desired ontology. Once this XML Catalog has been created it can be shared by users wishing to access ontologies offline.  Thus when a user sends me a collection of ontologies in a zip file, the user can include an XML Catalog that will allow my ontology development tools to interpret the import statements in the appropriate way.
 +
 
 +
Thus XML Catalogs will become an essential part of sharing ontologies.  It is therefore important that tools support a variety of mechanisms for generating XML Catalogs.
 +
 
 +
== Building XML Catalogs ==
 +
 
 +
=== At download ===
 +
 
 +
=== Using XML Base ===
 +
 
 +
=== Using the Ontology IRI or Version IRI ===
 +
 
 +
=== Using a quick guess for the Ontology IRI or Version IRI ===
 +
 
 +
=== Comparing offline ontologies with their online version ===

Revision as of 09:50, September 28, 2009

OWL 2.0 Imports

Under Construction!


Motivation

In OWL 2, imports are handled differently than they are in OWL 1.0. There have been two main changes

  • added support for versions of an ontology
  • using import by location rather than import by name.

The first of these changes is easily explained. In the OWL 2.0 scheme, an ontology can have two IRI's in its name. The first IRI is the ontology IRI. The second name is the version IRI for the ontology. In many cases the version IRI will be null. But when the version IRI is not null, this will mean that the ontology is a specific version of the ontology.

Thus for example, I might have an ontology that I am working on which I call 

   http://www.tigraworld.com/protege/determinants.owl.

After a while I start needing versions of this ontology, so I create an ontology with an ontology IRI 

   http://www.tigraworld.com/protege/determinants.owl

and a version IRI 

   http://www.tigraworld.com/protege/determinants-1.0.owl.

A later published verion of this ontology might have the version IRI 

   http://www.tigraworld.com/protege/determinants-2.0.owl.

The scheme by which these versions are named is not defined by the OWL 2.0 specification.

The intent is that these IRI's can be used to look up an ontology. If an ontology has a version IRI then following the version IRI using specified protocol should retrieve the ontology with that version. Thus version 1.0 of the determinants ontology can be found at the web location 

   http://www.tigraworld.com/protege/determinants-1.0.owl.

Following the ontology IRI, e.g. 

   http://www.tigraworld.com/protege/determinants.owl.

should retrieve the latest version of that ontology (which may or may not have a version IRI).

When importing, these two names allow ontology developers to specify which version of an ontology they want to import. The can specify a version of an ontology by importing the ontology version IRI. They can specify the latest version of an ontology by importing the ontology IRI.

The second change to OWL 2.0 imports is more difficult to explain. The reason that OWL 2.0 changed to import by location is that in many cases ontologies cannot be found by name. Usually when an ontology is first created, it can be found by its name. But over time the name stops working because either

  • ontologies are moved to reside on a different server and can no

longer be found by using the old server,

  • purls are not maintained.

Even the w3c is unable to keep urls permanent (e.g. the SWRL vocabulary declarations).

When this happend the import by name scheme becomes awkward. Suppose that I am creating an ontology and I give it the name 

   http://www.tigraworld.com/protege/determinants.owl.

Initially I am the developer of this ontolgy and I place the ontology at that site. Unfortunately, for some reason this site no longer exists and if I wrote a really good ontology other people want to continue using it. So the ontology is then placed at a new location 

   http://www.stanford.edu/junit/determinants-test01.owl.

With the import by name scheme, ontology developers wishing to access this ontology are in a awkward situation. They can either disobey the OWL 1.0 specification and import by location or they can import by name. If they import by location, things work well when users are online. When a user is online, tools will follow and import the desired ontology. The import will be found but the tool will generate a warning that the import is malformed. If the ontology developer has no control over the determinants ontology, then this is the best he can do in this case.

But this method works badly if users download the ontology and then try to work offline. The OWL repository mechansims simply can't link the import statement 

   import http://www.stanford.edu/junit/pizza-test01.owl

to the ontology with the name 

   http://www.tigraworld.com/protege/pizza.owl.

The OWL 1.0 answer to this is that the import should import by name. But importing by name makes it impossible for tools to find the imported ontology when users are online and don't have access to some searchable repository of ontologies.

The OWL 2.0 solution to this problem is to use import by location and XML catalogs. The recommended import statement would look like this: 

       import http://www.stanford.edu/junit/pizza-test01.owl.

When users are online and want to access the ontologies through their web addresses, they can easily find the desired pizza ontology.

When ontology developers want to work offline, they must find or generate an xml catalog. XML Catalogs are an industry standard language allowing users to specify (among other things) redirection of IRI addresses to alternative addresses. Thus in this case the ontology developer must create an XML catalog that redirects the IRI 

      http://www.stanford.edu/junit/pizza-test01.owl.

found in the import statement to a different (possibly relative from the XML Catalog location) IRI containing the desired ontology. Once this XML Catalog has been created it can be shared by users wishing to access ontologies offline. Thus when a user sends me a collection of ontologies in a zip file, the user can include an XML Catalog that will allow my ontology development tools to interpret the import statements in the appropriate way.

Thus XML Catalogs will become an essential part of sharing ontologies. It is therefore important that tools support a variety of mechanisms for generating XML Catalogs.

Building XML Catalogs

At download

Using XML Base

Using the Ontology IRI or Version IRI

Using a quick guess for the Ontology IRI or Version IRI

Comparing offline ontologies with their online version

Retrieved from "https://protegewiki.stanford.edu/index.php?title=How_Owl_2.0_Imports_Work&oldid=6544"