Difference between revisions of "How Owl 2.0 Imports Work"
(→OWL 2.0 Imports) |
|||
| Line 42: | Line 42: | ||
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 | 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 | + | * ontologies are moved to reside on a different server and can no longer be found by using the old server, |
| − | longer be found by using the old server, | ||
* purls are not maintained. | * purls are not maintained. | ||
Even the w3c is unable to keep urls permanent (e.g. the SWRL vocabulary declarations). | Even the w3c is unable to keep urls permanent (e.g. the SWRL vocabulary declarations). | ||
| − | + | For example, suppose that I am creating an ontology and I give it the name | |
<pre> | <pre> | ||
http://www.tigraworld.com/protege/determinants.owl. | http://www.tigraworld.com/protege/determinants.owl. | ||
Revision as of 10:11, September 28, 2009
Contents
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).
For example, 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.
