Importing Ontologies in P41 - Revision history

TaniaTudorache at 04:22, May 24, 2016

2016-05-24T04:22:02Z

Tredmond: /* Protege and XML Catalogs */

2012-12-04T02:07:11Z

‎Protege and XML Catalogs

Tredmond at 01:56, December 4, 2012

2012-12-04T01:56:24Z

Tredmond: /* Protege and XML Catalogs */ (checkpoint save)

2012-12-04T01:50:59Z

‎Protege and XML Catalogs: (checkpoint save)

Tredmond: /* Protege and XML Catalogs */

2012-12-04T01:33:28Z

‎Protege and XML Catalogs

Tredmond: /* Protege and XML Catalogs */

2012-12-04T01:28:47Z

‎Protege and XML Catalogs

Tredmond: /* Protege and XML Catalogs */

2012-12-04T01:05:40Z

‎Protege and XML Catalogs

Tredmond: /* Protege and XML Catalogs */

2012-12-04T00:58:55Z

‎Protege and XML Catalogs

Tredmond: /* Protege and XML Catalogs */

2012-12-04T00:53:54Z

‎Protege and XML Catalogs

Tredmond: /* Protege and XML Catalogs */

2012-12-04T00:40:10Z

‎Protege and XML Catalogs

@@ Line 1: / Line 1: @@
 __TOC__
-== Importing Ontologies in Protege 4.1 ==
+== Importing Ontologies in Protege and OWL 2 ==
-In this section, I will walk you through adding an import to an ontology.  The purpose of this page is to illustrate OWL 2.0 imports and explain the design of the Protege 4.1 import mechanism.  Note that there is also another [[How_Owl_2.0_Imports_Work page]] which describes OWL 2.0 imports which as not yet been integrated with this page.  First I will introduce some terminology.
+In this section, I will walk you through adding an import to an ontology.  The purpose of this page is to illustrate OWL 2.0 imports and explain the design of the Protege import mechanism. First I will introduce some terminology.
 == Definitions ==
@@ Line 22: / Line 22: @@
 '''The physical location''' of an ontology is the location where the source for the ontology is found and loaded from.  It may appear from the above definition of the import declaration that the physical location of an imported file should simply be the location indicated by the import declaration.  But often ontology developers want to have imports redirected to a physical location on their local machine.  The OWL 2 specification makes allowances for this:
 : ''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 via DI instead.''
-In a separate [http://lists.w3.org/Archives/Public/public-owl-wg/2009Feb/0172.html email discussion], it appears that the working group recommends the use of xml catalogs as a redirection mechanism and the xml catalog specification is at the core of the Protege 4.1 import redirection mechanism.
+In a separate [http://lists.w3.org/Archives/Public/public-owl-wg/2009Feb/0172.html email discussion], it appears that the working group recommends the use of xml catalogs as a redirection mechanism and the xml catalog specification is at the core of the Protege import redirection mechanism.
 Finally every ontology has an '''ontology name''' and '''ontology version'''.  These are described [http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Ontology_IRI_and_Version_IRI here].  There is no direct connection between import declarations and the name of the ontology being imported.  However, the owl 2 specifications do indicate that physical locations for an ontology can be determined by the name or version of the ontology:
@@ Line 28: / Line 28: @@
 # ''If O contains an ontology IRI OI and a version IRI VI, then the ontology document of O SHOULD be accessible via the IRI VI; furthermore, if O is the current version of the ontology series with the IRI OI, then the ontology document of O SHOULD also be accessible via the IRI OI.''
 These statements suggest the possibility that the import declaration can use the imported ontology name or version to do the import.  I personally believe that this is the best way to do imports as it makes it easier to share ontologies when the user does not have access to the ontologies home network (e.g. the user is offline).
-== Importing an ontology with Protege 4.1+ ==
+Here we will describe the steps involved in adding an import from the web.  We assume that you have some ontology already loaded in Protege.  Go to the Active Ontologies tab and click on the plus sign beside the Direct Imports text.  This will pull up the following dialog box.
 [[File:Protege41ImportWizardChooseType.png]]
@@ Line 44: / Line 43: @@
 [[File:Protege41ImportWizardURL.png]]
-Now when you click "continue" Protege 4.1 will calculate the name and version of the ontology at the http://protege.cim3.net/file/pub/ontologies/travel/travel.owl location.  The purpose of this step is two-fold.  First it provides some reasonable verification that a real owl ontology can be found at the location provided.  Second it will be used to provide some possibilities of the way in which the desired ontology can be imported.  The calculation of the ontology name can take a bit of time so you may see a transitory import verification page come up while the ontology name and version is calculated.  When the ontology name calculation is complete a new page will come up which will allow you to specify the import declaration.
+Now when you click "continue" Protege will calculate the name and version of the ontology at the http://protege.cim3.net/file/pub/ontologies/travel/travel.owl location.  The purpose of this step is two-fold.  First it provides some reasonable verification that a real owl ontology can be found at the location provided.  Second it will be used to provide some possibilities of the way in which the desired ontology can be imported.  The calculation of the ontology name can take a bit of time so you may see a transitory import verification page come up while the ontology name and version is calculated.  When the ontology name calculation is complete a new page will come up which will allow you to specify the import declaration.
 [[File:Protege41ImportWizardChooseDeclaration.png]]
@@ Line 85: / Line 84: @@
 = Protege and XML Catalogs =
-At some point after the OWL 2 specification became final, Protege 4.1 adopted the [https://www.oasis-open.org/committees/entity/spec-2001-08-06.html XML Catalog] standard as a way of recording and controlling how it redirects imports while loading an ontology.  The goals of the Protege 4.1 XML Catalog implementation are as follows:
+At some point after the OWL 2 specification became final, Protege adopted the [https://www.oasis-open.org/committees/entity/spec-2001-08-06.html XML Catalog] standard as a way of recording and controlling how it redirects imports while loading an ontology.  The goals of the Protege 4.1 XML Catalog implementation are as follows:
-* The implementation must have transparent compatibility with Protege 4.0 import mechanism that seems to have been well liked.
+* The implementation must have transparent compatibility with previous Protege (versions 4.0 and earlier) import mechanism that seems to have been well liked.
 * After opening an OWL file from a filesystem, there will be an XML catalog file that can be used by any xml catalog aware application to replicate the imports that were performed by Protege.  In particular, the [https://smi-protege.stanford.edu/repos/protege/protege4/libraries/xmlcatalog/trunk XML Catalog library] can be used to enable the [http://owlapi.sourceforge.net OWL api] to use XML Catalogs.
-* There must be a clear path by which the the Protege 4.0 import mechanism can be enhanced.  For example Protege 4.2 allows OWL ontologies in a directory, A, to import ontologies in a directory, B, where B is not a direct or indirect child of A.  Also Protege 4.2 supports import-by-name.  Neither of these features were supported in Protege 4.0.
+* There must be a clear path by which the the Protege 4.0 import mechanism can be enhanced.  For example Protege, allows OWL ontologies in a directory, A, to import ontologies in a directory, B, where B is not a direct or indirect child of A.  Also Protege, supports import-by-name.  Neither of these features were supported in Protege 4.0.
 * The implementation must provide a means by which a user can over-ride redirects calculated by Protege and provide their own declaration of how import declarations should be redirected.  For example, as of this reading, the obi ontology does exactly this with their [https://obi.svn.sourceforge.net/svnroot/obi/trunk/src/ontology/branches/catalog-v001.xml catalog].
 * The implementation must provide a means by which a user can prevent Protege from doing any automatic redirection (by emptying the catalog).
@@ Line 97: / Line 96: @@
 Since the Protege 4.0 mechanism would not write any configuration data to any local configuration file this technique had some disadvantages.  In particular, it was not possible in Protege 4.0 to change or disable how the import redirection occurred for the ontologies in a particular directory.  Thus for instance some users would have directories containing several ontologies with the same name.  In this situation, the user would have to manually configure the import redirection at each load.  Other projects, e.g., obi, would put imported ontologies in a directory that was not a child directory.  As such the Protege 4.0 mechanism would never find the on-disk location for the imports and would always go to the web.
-For these and other reasons, Protege 4.1+ uses a configuration file called catalog-v001.xml, to describe how imports are redirected.  We chose the XML Catalog format for this file because it is an industry standard format for specifying URL redirection.
+For these and other reasons, Protege uses a configuration file called catalog-v001.xml, to describe how imports are redirected.  We chose the XML Catalog format for this file because it is an industry standard format for specifying URL redirection.
-To mimic the Protege 4.0 mechanism, we defined a type of plugin, a repository plugin, that is allowed to update certain constrained portions of the catalog.  Just before loading an ontology from the disk, Protege 4.1+ will give each repository a chance to update a field in the appropriate XML catalog.
+To mimic the Protege 4.0 mechanism, we defined a type of plugin, a repository plugin, that is allowed to update certain constrained portions of the catalog.  Just before loading an ontology from the disk, Protege will give each repository a chance to update a field in the appropriate XML catalog.
 Thus for instance, a typical XML catalog generated by Protege will contain a group entry that looks something like the following:
 <pre>
@@ Line 105: / Line 104: @@
          <uri id="Automatically generated entry, Timestamp=1330383331040" name="...
 </pre>
-When Protege 4.1+ loads an ontology in the same directory as this catalog, the "Folder Group Manager" plugin will recognize that it needs to update this group entry because
+When Protege, loads an ontology in the same directory as this catalog, the "Folder Group Manager" plugin will recognize that it needs to update this group entry because
 # it recognizes that the first part of the name of the group "Folder Repository" indicates that it is the creator and manager of this particular group entry.
 # it sees that the Auto-Update flag is set to true, allowing this group entry to be modified.
@@ Line 141: / Line 140: @@
 This catalog can be read and understood by any XML Catalog program to precisely mirror how Protege does the import redirects for ontologies in this directory.  Thus for instance, if Protege gets some unexpected inference results for an ontology, the unexpected inference may depend on the way in which import directives were resolved.  Providing the xml catalog will allow an OWL reasoner - outside the Protege context - to replicated the import redirection that Protege performed to achieve the result.
-By choosing the XML catalog mechanism, there is a clear path to enhancing the import redirection mechanism.  For example, in Protege 4.1, if a user interactively adds an import to an ontology and the import would not be found by the existing catalog, Protege will update the catalog to include an entry that indicates how the import should be redirected.  Thus for instance, if I edit an ontology in one directory and then interactively use the Protege imports wizard to successfully import an ontology from another directory, Protege will add the following uri-entry to a catalog:
+By choosing the XML catalog mechanism, there is a clear path to enhancing the import redirection mechanism.  For example, in Protege, if a user interactively adds an import to an ontology and the import would not be found by the existing catalog, Protege will update the catalog to include an entry that indicates how the import should be redirected.  Thus for instance, if I edit an ontology in one directory and then interactively use the Protege imports wizard to successfully import an ontology from another directory, Protege will add the following uri-entry to a catalog:
 <pre>
      <uri id="Imports Wizard Entry" name="http://www.co-ode.org/ontologies/pizza/pizza.owl" uri="file:/Volumes/Shared/ontologies/simple/pizza.owl"/>
@@ Line 156: / Line 155: @@
 </catalog>
 </pre>

@@ Line 146: / Line 146: @@
 </pre>
-By constraining when repository plugins will modify an XML, Protege makes it possible for users to create custom catalogs without worrying about them getting altered.  The obi ontology contains an example of just such a [https://obi.svn.sourceforge.net/svnroot/obi/trunk/src/ontology/branches/catalog-v001.xml catalog].
+The only way in which Protege will alter an existing catalog are
 == Import By Name ==

@@ Line 146: / Line 146: @@
 </pre>
-By constraining when plugins will modify an XM
+By constraining when repository plugins will modify an XML, Protege makes it possible for users to create custom catalogs without worrying about them getting altered.  The obi ontology contains an example of just such a [https://obi.svn.sourceforge.net/svnroot/obi/trunk/src/ontology/branches/catalog-v001.xml catalog].
 '''Under Construction'''
-Things to cover - motivation, catalog-v001.xml, when Protege modifies the catalog
+Things to cover - motivation, catalog-v001.xml, when Protege modifies the catalog.  T
 == Import By Name ==

@@ Line 85: / Line 85: @@
 = Protege and XML Catalogs =
-At some point after the OWL 2 specification became final, Protege 4.1 adopted the [https://www.oasis-open.org/committees/entity/spec-2001-08-06.html XML Catalog] standard as a way of recording how it redirects imports while loading an ontology.  The goals of the Protege 4.1 XML Catalog implementation is as follows:
+At some point after the OWL 2 specification became final, Protege 4.1 adopted the [https://www.oasis-open.org/committees/entity/spec-2001-08-06.html XML Catalog] standard as a way of recording and controlling how it redirects imports while loading an ontology.  The goals of the Protege 4.1 XML Catalog implementation are as follows:
 * The implementation must have transparent compatibility with Protege 4.0 import mechanism that seems to have been well liked.

@@ Line 145: / Line 145: @@
      <uri id="Imports Wizard Entry" name="http://www.co-ode.org/ontologies/pizza/pizza.owl" uri="file:/Volumes/Shared/ontologies/simple/pizza.owl"/>
 </pre>
 '''Under Construction'''

@@ Line 111: / Line 111: @@
 # scanning the disk to associate files with the names by which they could be imported,
 # writing each of these associations to a uri-entry underneath the group entry indicating that a particular import should be redirected to a particular ontology file.
-After all the repository plugins had their say, Protege would load the ontology and use the updated XML catalog to resolve any imports.
+After all the repository plugins had their say, Protege would load the ontology and use the updated XML catalog to resolve any imports.   A typical example of a real-life xml catalog generated by Protege would look something like the following
 '''Under Construction'''