How Owl 2.0 Imports Work - Revision history

Tredmond: /* Building XML Catalogs */

2009-11-30T19:44:11Z

‎Building XML Catalogs

Tredmond: /* Motivation */

2009-11-11T19:18:11Z

‎Motivation

Tredmond at 19:15, November 11, 2009

2009-11-11T19:15:33Z

Tredmond: /* Using XML Base */

2009-11-11T19:01:38Z

‎Using XML Base

Tredmond at 18:53, November 11, 2009

2009-11-11T18:53:58Z

Tredmond: /* Building XML Catalogs */

2009-11-11T18:42:21Z

‎Building XML Catalogs

Tredmond: /* Building XML Catalogs */

2009-10-09T04:19:18Z

‎Building XML Catalogs

Tredmond at 21:51, September 29, 2009

2009-09-29T21:51:13Z

Tredmond: /* Offline Editing and XML Catalogs */ (checkpoint save)

2009-09-29T21:43:55Z

‎Offline Editing and XML Catalogs: (checkpoint save)

Tredmond: /* Motivation */

2009-09-29T21:36:41Z

‎Motivation

@@ Line 72: / Line 72: @@
 == Building XML Catalogs ==
-In this section, we will consider the problem of automatically generating XML catalogs.  The user has  a collection of OWL ontologies that have been downloaded from the internet.  When the owl ontologies lived on the internet, the imported ontologies could be found simply by resolving the import as a URL.  When the ontologies have been downloaded to the disk, the user will want import directives to be remapped to  the location of the ontologies on the disk.  This redirection will be done through xml catalogs that will tell the Protege tool how import statements should be redirected.  The second two algorithms will give a result even if the user has received the ontologies in a zip file and has no access to the internet at the time that the user opens the zip file.   Note that the preferred approach when  users are sharing owl ontologies through e-mail  is that they will provide a xml catalog with the owl files that they share.  This would make the automatic generation of the xml catalog unnecessary.
+In this section, we will consider the problem of automatically generating XML catalogs.  Assuming that a set of files on disk have been downloaded from the internet to a disk, the question we want to ask is
-=== At download ===
+=== Generating XML Catalogs During download ===
 This is the most accurate way of building an xml catalog.  The other methods described here are heuristics and as such are optional and can be overridden by a user. I will describe this process with a simple example.
@@ Line 100: / Line 102: @@
 === Using XML Base ===
-This algorithm is a heuristic and can be turned off or overridden.
+This algorithm is a heuristic and can be turned off or overridden.  This is the recommended algorithm because it is fast and it generally  returns the information that the user needs.
 In the specification of xml base, it is stated that the xml base should represent the location where a file can be found.  Thus if the continuedFractions.owl file is found on disk (in rdf/xml format), it is very  likely that its xml base will be
@@ Line 114: / Line 116: @@
 === Using the Ontology IRI or Version IRI ===
 If an ontology has a version IRI, then it should be the case that this ontology can be retrieved by turning the version IRI into a URL.   Thus if I  have a file on disk called determinants.owl which has  an ontology IRI of
@@ Line 142: / Line 142: @@
 </pre>
 can be safely redirected to the determinants.owl file on the disk.

@@ Line 38: / Line 38: @@
     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).
+should retrieve the latest version of that ontology (which may or may not have a version IRI).  However, it should be noted that the reason OWL 2.0 uses import by name is that it is often the case that ontologies cannot be retrieved by name.
 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.

@@ Line 72: / Line 72: @@
 == Building XML Catalogs ==
-In this section, we will consider the problem of automatically generating XML catalogs.  The user has  a collection of OWL ontologies that have been downloaded from the internet.  When the owl ontologies lived on the internet, the imported ontologies could be found simply by resolving the import as a URL.  When the ontologies have been downloaded to the disk, the user will want import directives to be remapped to  the location of the ontologies on the disk.  This redirection will be done through xml catalogs that will tell the Protege tool how import statements should be redirected.
+In this section, we will consider the problem of automatically generating XML catalogs.  The user has  a collection of OWL ontologies that have been downloaded from the internet.  When the owl ontologies lived on the internet, the imported ontologies could be found simply by resolving the import as a URL.  When the ontologies have been downloaded to the disk, the user will want import directives to be remapped to  the location of the ontologies on the disk.  This redirection will be done through xml catalogs that will tell the Protege tool how import statements should be redirected.  The second two algorithms will give a result even if the user has received the ontologies in a zip file and has no access to the internet at the time that the user opens the zip file.   Note that the preferred approach when  users are sharing owl ontologies through e-mail  is that they will provide a xml catalog with the owl files that they share.  This would make the automatic generation of the xml catalog unnecessary.
 === At download ===
@@ Line 100: / Line 100: @@
 === Using XML Base ===
-In the specification of xml base, it is stated that the xml base should represent the location where a file can be found.
+This algorithm is a heuristic and can be turned off or overridden.
 === Using the Ontology IRI or Version IRI ===

← Older revision		Revision as of 19:01, November 11, 2009
Line 99:		Line 99:

	=== Using XML Base ===		=== Using XML Base ===
		+
		+	In the specification of xml base, it is stated that the xml base should represent the location where a file can be found.

	=== Using the Ontology IRI or Version IRI ===		=== Using the Ontology IRI or Version IRI ===

@@ Line 76: / Line 76: @@
 === At download ===
 === Using XML Base ===
 === Using the Ontology IRI or Version IRI ===

@@ Line 62: / Line 62: @@
      http://www.tigraworld.com/protege/continuedFractions.owl.
 </pre>
-If the user wants to the import of continuedFractions.owl to redirect to the version of the continuedFractions.owl ontology on the users local disk, the user needs to use [http://www.oasis-open.org/committees/entity/spec-2001-08-06.html XML Catalogs].
+If the user wants to the import of continuedFractions.owl to redirect to the version of the continuedFractions.owl ontology on the users local disk, the user needs to use [http://www.oasis-open.org/committees/entity/spec-2001-08-06.html XML Catalogs].  XML Catalogs allow the user to specify that the process of resolving the URL
 <pre>
-      http://www.stanford.edu/junit/pizza-test01.owl.
+    import http://www.tigraworld.com/protege/continuedFractions.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.
+be redirected to a specific location on the local drive.  For users who are familiar with Protege 3.4 ontology repositories, the XML catalog will play a very similar role as the .repository files in Protege 3.4.  The big advantage of XML catalogs is that they are a standard mechanism that can be used by any tool that understands OWL.
 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 ===

@@ Line 46: / Line 46: @@
 === 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
+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 there are two ontologies on the internet which are located on the web at the location
 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

@@ Line 9: / Line 9: @@
 * 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
@@ 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.
-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 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.
-For example, suppose that I am creating an ontology and I give it the name
+=== Offline Editing and XML Catalogs ===
-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
+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
-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:
+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