Difference between revisions of "How Owl 2.0 Imports Work"
(→Motivation) |
|||
| Line 9: | Line 9: | ||
* added support for versions of an ontology | * added support for versions of an ontology | ||
* using import by location rather than import by name. | * using import by location rather than import by name. | ||
| − | The first of these changes is | + | |
| + | The motivation for the first of these changes is pretty clear. OWL 2.0 supports versions by allowing 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 | Thus for example, I might have an ontology that I am working on which I call | ||
| Line 41: | Line 42: | ||
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. | 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 | + | The second change to OWL 2.0 imports is the main subject of this note. OWL 2.0 uses an import by location scheme rather than the [[How Owl Imports Work|import by name]] scheme used in OWL 1.0. This simply means that an import declaration is a directive to import the ontology that can be found at the physical location represented by the imported IRI. The reason that OWL 2.0 changed to import by location is that in many cases ontologies cannot be found by name. This meant that many owl ontologies could not use the import by name scheme to do their imports because then there would be no way for applications or users to find the imported ontology. With import by location, the importing ontology always states where the imported ontology can be found. |
| − | |||
| − | |||
| − | |||
| − | + | === Offline Editing and XML Catalogs === | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | The disadvantage of the import by location scheme is that it adds a bit of complexity when a user wants to download some ontologies from the internet and either edit them on the hard drive or work with them while offline. To make this concrete | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | Suppose that the user invokves an ontology editing tool on an ontology on the local drive that has imports from the internet. If an import declaration is resolved in the standard manner it will tell the ontology tool to obtain the imported ontology from its network location. If the | |
| − | |||
| − | |||
| − | |||
| − | |||
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 | 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 | ||
Revision as of 14:36, September 29, 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 motivation for the first of these changes is pretty clear. OWL 2.0 supports versions by allowing 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 the main subject of this note. OWL 2.0 uses an import by location scheme rather than the import by name scheme used in OWL 1.0. This simply means that an import declaration is a directive to import the ontology that can be found at the physical location represented by the imported IRI. The reason that OWL 2.0 changed to import by location is that in many cases ontologies cannot be found by name. This meant that many owl ontologies could not use the import by name scheme to do their imports because then there would be no way for applications or users to find the imported ontology. With import by location, the importing ontology always states where the imported ontology can be found.
Offline Editing and XML Catalogs
The disadvantage of the import by location scheme is that it adds a bit of complexity when a user wants to download some ontologies from the internet and either edit them on the hard drive or work with them while offline. To make this concrete
Suppose that the user invokves an ontology editing tool on an ontology on the local drive that has imports from the internet. If an import declaration is resolved in the standard manner it will tell the ontology tool to obtain the imported ontology from its network location. If the
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.
