cwpk-17-choosing-installing-owl-api.ipynb

{
 "cells": [
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "<h1 id=\"CWPK-#17:-Choosing-and-Installing-an-OWL-API\">CWPK #17: Choosing and Installing an OWL API</h1>\n",
    "<h2 id=\"owlready2-Appears-to-be-a-Capable-Option\">owlready2 Appears to be a Capable Option</h2>\n",
    "<div style=\"float: left; width: 305px; margin-right: 10px;\"><img title=\"Cooking with KBpedia\" src=\"http://kbpedia.org/cwpk-files/cooking-with-kbpedia-305.png\" width=\"305\" /></div>\n",
    "<p>In the <a href=\"https://www.mkbergman.com/2327/cwpk-2-what-to-expect/\"><strong>CWPK #2</strong></a> and <a href=\"https://www.mkbergman.com/2329/cwpk-4-the-baseline-architecture/\"><strong>#4</strong></a> installments to this <a href=\"https://www.mkbergman.com/cooking-with-python-and-kbpedia/\" target=\"_blank\" rel=\"noopener\"><em>Cooking with Python and KBpedia</em></a> series, we noted that we would reach a decision point when we needed to determine how we will manipulate our knowledge graphs (ontologies) using the <a href=\"https://en.wikipedia.org/wiki/Python_%28programming_language%29\" target=\"_blank\" rel=\"noopener\">Python</a> language. We have now reached that point. Our basic Python environment is set (at least in an initial specification) and we need to begin inputting and accessing <a href=\"https://kbpedia.org/\" target=\"_blank\" rel=\"noopener\">KBpedia</a> to develop and test our needed management and build functions.</p>\n",
    "<p>In our own efforts over the past five years or more, we have used the <a href=\"https://en.wikipedia.org/wiki/Java_%28programming_language%29\" target=\"_blank\" rel=\"noopener\">Java</a> <a href=\"https://github.com/owlcs/owlapi/\" target=\"_blank\" rel=\"noopener\">OWL API</a> initially developed by the University of Manchester. The OWL API is an integral part of the <a href=\"https://en.wikipedia.org/wiki/Prot%C3%A9g%C3%A9_%28software%29\" target=\"_blank\" rel=\"noopener\">Prot&eacute;g&eacute;</a> <a href=\"https://en.wikipedia.org/wiki/Integrated_development_environment\" target=\"_blank\" rel=\"noopener\">IDE</a> (see <a href=\"https://www.mkbergman.com/2331/cwpk-5-overview-and-installation-of-protege/\"><strong>CWPK #5</strong></a>) and supports <a href=\"https://en.wikipedia.org/wiki/Web_Ontology_Language\" target=\"_blank\" rel=\"noopener\">OWL2</a>. The API is actively maintained. We have been very pleased with the API's performance and stability in our earlier KBpedia (and other ontology) efforts. In our own <a href=\"https://en.wikipedia.org/wiki/Clojure\" target=\"_blank\" rel=\"noopener\">Clojure</a>-based work we have used a wrapper around the OWL API. A wrapper using Python is certainly a viable (perhaps even best) approach to our current project.</p>\n",
    "<p>We still may return to this approach for reasons of performance or capabilities, but I decided to first explore a more direct approach using a Python language option. This decision is in keeping with this series' Python education objectives. I prefer for these lessons to use a consistent Python style and naming conventions, rather than those in Java. I was also curious to evaluate and test what presently exists in the marketplace. We may gain some advantages from a more direct approach; we may also discover some gotchas or deadends that initial due diligence missed. We can always return to Plan B with a wrapper around the existing OWL API.</p>\n",
    "<p>If we do need to revert and take the wrapper approach, the leading candidate for the wrapper is <a href=\"https://www.py4j.org/\" target=\"_blank\" rel=\"noopener\">py4j</a>. Initial research suggests other Python bridges to Java such as <a href=\"https://en.wikipedia.org/wiki/Jython\" target=\"_blank\" rel=\"noopener\">Jython</a> or <a href=\"https://jpype.readthedocs.io/en/latest/\" target=\"_blank\" rel=\"noopener\">JPype</a> are less efficient and less popular than py4j. <a href=\"https://pyjnius.readthedocs.io/en/stable/\" target=\"_blank\" rel=\"noopener\">pyJNIus</a> had a similar objective to py4j but has seen no development activity for 4-6 years. The <a href=\"http://robot.obolibrary.org/\">ROBOT</a> tool for biomedical ontologies points the way to how Python can <a href=\"https://robot.obolibrary.org/python\" target=\"_blank\" rel=\"noopener\">link through py4j</a>. Even if our Python-based approach herein works great, we still may want to embrace py4j as we move forward given the wealth of ontology-related applications written in Java. But I digress.</p>\n",
    "<p>There is no acclaimed direct competitor to the OWL API in Python, though there are pieces that may approximate its capabilities. Frankly, I was surprised after beginning my due diligence with the relative dearth of Python tools for working with OWL. Many of the Python projects that do or did exist harken back years. There was a bulge of tool-making in the mid-2000s using Python that has since cooled substantially, with two notable exceptions I discuss below.</p>\n",
    "<p>One of those exceptions is <a href=\"https://github.com/RDFLib/rdflib\" target=\"_blank\" rel=\"noopener\">RDFLib</a>, a Python library for working with <a href=\"https://en.wikipedia.org/wiki/Resource_Description_Framework\" target=\"_blank\" rel=\"noopener\">RDF</a>. RDFLib provides a useful set of parsers and serializers and a plug-in architecture, but directly lacks OWL 2 support. <a href=\"https://github.com/RDFLib/FuXi\" target=\"_blank\" rel=\"noopener\">FuXi</a> was an OWL reasoner based on RDFLib that used a subset of OWL, but is now abandoned. <a class=\"external text\" href=\"http://packages.python.org/SuRF/\" target=\"_blank\" rel=\"noopener\">SuRF</a> is an object-RDF mapper based on RDFlib that enables manipulations of RDF triples, but is somewhat dated. <a class=\"external text\" href=\"https://github.com/cosminbasca/rdftools\" target=\"_blank\" rel=\"noopener\">rdftools</a> had a similar objective to RDFLib, but has been abandoned from about 5-7 yrs ago. <a href=\"https://pydoc.net/owllib/0.1.0/\" target=\"_blank\" rel=\"noopener\">owlib</a> is a 5-yr old API to OWL built using RDFLib to simplify working with OWL constructs; it has not been updated and is inactive. More currently, <a href=\"https://rdflib.readthedocs.io/en/stable/apidocs/rdflib.extras.html#module-rdflib.extras.infixowl\" target=\"_blank\" rel=\"noopener\">infixowl</a> is a RDFLib Python binding for the OWL abstract syntax, which makes it more like the wrapper alternative. Though not immediately applicable to our OWL needs, we may later embrace RDFLib for parsers and serializers or as a useful library for the typologies in KBpedia.</p>\n",
    "<p>Then there are a number of tools independent of RDFLib. <a href=\"http://seth-scripting.sourceforge.net/\" target=\"_blank\" rel=\"noopener\">SETH</a> was an attempt at a Python OWL API that still required the <a href=\"https://en.wikipedia.org/wiki/Java_virtual_machine\">JVM</a> from about a dozen years back, and is now largely abandoned (though available via <a href=\"http://sourceforge.net/projects/seth-scripting/\" target=\"_blank\" rel=\"noopener\">CVS repository</a>). <a href=\"https://github.com/hsolbrig/funowl\" target=\"_blank\" rel=\"noopener\">funowl</a> is a pythonic API that follows the OWL functional model for constructing OWL and it provides a <a href=\"https://www.py4j.org/\" target=\"_blank\" rel=\"noopener\">py4j</a> or equivalent wrapper to the standard Java OWL libraries. It appears to be active and is worth keeping an eye on. The <a href=\"https://github.com/biolink/ontobio/\" target=\"_blank\" rel=\"noopener\">ontobio</a> Python module is a library for working with ontologies and associations to outside entities, though it is not an ontology manager.</p>\n",
    "<p>Fortunately, the second exception is <a href=\"http://www.lesfleursdunormal.fr/static/informatique/owlready/index_en.html\" target=\"_blank\" rel=\"noopener\">owlready2</a>, a module for ontology-oriented programming in Python 3, including an optimized RDF quadstore. A number of things impressed me about owlready2 in my due diligence. First, its functionality fit the bill for what I wanted to see in an ontology manager dealing with all <a href=\"https://en.wikipedia.org/wiki/Create,_read,_update_and_delete\" target=\"_blank\" rel=\"noopener\">CRUD</a> (<span style=\"font-style: italic;\">create-read-update-delete</span>) aspects of an ontology and its components. Second, I liked the intent and philosophy behind the system as expressed in its original academic paper and home Web site (see <strong>Additional Documentation</strong> below). Third, the project is being actively maintained with many releases over the past two years. Fourth, the documentation level was comparatively high for an open-source project and clearly written and understandable. And, last, there is an <a href=\"https://github.com/dwintergruen/Owlready-rdflib\" target=\"_blank\" rel=\"noopener\">existing extension</a> to owlready2 that adds support for RDFLib, should we also decide to add that route.</p>\n",
    "<p>One concern arising from my diligence is the lack of direct Notation3 (<a href=\"https://en.wikipedia.org/wiki/Notation3\" target=\"_blank\" rel=\"noopener\">N3</a>) file support in owlready2, since all of KBpedia's current ontology files are in N3. According to owlready2's developer, Jean-Baptiste Lamy, <a href=\"https://en.wikipedia.org/wiki/N-Triples\" target=\"_blank\" rel=\"noopener\">N-Triples</a>, which are a subset of N3, are presently supported by owlready2. We can test and see if our N3 constructs load or not. If they do not, we can save out our ontology files in RDF/XML, which owlready2 does support. (Indeed, use of the RDF/XML format has proven to be the better approach.) Alternatively, we can do file conversions with RDFLib or the Java OWL API. File format conversions and compatibility will be a constant theme in our work, and this potential hurdle is not unlike others we may face.</p>\n",
    "<p>Thus, while the pickings were surprisingly thin for off-the-shelf OWL tools in Python, owlready2 appears to have the requisite functionality and currentness and to be a reasonable initial choice. Should this choice prove frustrating, we will likely fall back onto the py4j wrapper to the OWL API or funowl.</p>\n",
    "<p>So, now with the choice made, it is time to set up our directory structure and install owlready2.</p>\n",
    "<p>Here is our standard main directory structure with the owlready2 additions noted:</p>\n",
    "<pre>|-- PythonProject                                             \n",
    "     |-- Python                                               \n",
    "          |-- [Anaconda3 distribution]                        \n",
    "     |-- Notebooks                                           \n",
    "          |-- CWPKNotebook                                    \n",
    "     |-- owlready2                         # place it at top level of project\n",
    "          |-- kg                           # for knowledge graphs (kgs) and ontologies\n",
    "          |-- scripts                      # for related Python scripts\n",
    "     |-- TBA\n",
    "</pre>\n",
    "<p>After making these changes on disk, it is time to install, which is easy:</p>\n",
    "<pre>    conda install -c conda-forge owlready2\n",
    "</pre>\n",
    "<p>You will see the reports to the screen terminal as we noted before, and you will need to agree to proceed. Assuming no errors are encountered, you will be returned to the command window prompt. You can then invoke '<code>Jupyter Notebook</code>' again.</p>"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "<h3 id=\"Finding-and-Opening-Files\">Finding and Opening Files</h3>\n",
    "<p>Let's begin working with <code>owlready2</code> by loading and reading an ontology/knowledge graph file. Let's start with the smallest of our KBpedia ontology files,<code> kko.owl</code> (per the instructions above this is the <code>kko.n3</code> file converted to RDF/XML in Prot&eacute;g&eacute;). (You may <a href=\"https://raw.githubusercontent.com/Cognonto/CWPK/master/sandbox/builds/ontologies/kko.owl\">download this converted file from here</a>.) I will also assume you stored this file under the <code>owlready2/kg</code> directory noted above.</p>\n",
    "\n",
    "<div style=\"background-color:#eee; border:1px dotted #aaa; vertical-align:middle; margin:15px 60px; padding:8px;\"><strong>Important Note</strong>: You may be working with these interactive notebooks either online with <a href=\"https://mybinder.org/\">MyBinder</a> or from your own local file system. In the first case, the files you will be using will be downloaded from <a href=\"https://github.com/Cognonto/CWPK/\">GitHub</a>; in the second case, you will be reading directly from your local directory structure. In the instructions below, and in <strong>ALL</strong> cases where external files are used, we will show you the different Python commands associated with each of these options.</div>\n",
    "\n",
    "<p>As you begin to work with files in Python on Windows, here are some initial considerations:</p>\n",
    "<ul>\n",
    "<li>In Windows, a full file directory path starts with a drive letter (<code>C:, D:</code>. etc.). In Linux and OS-X, it starts with \"<code>/</code>\"</li>\n",
    "<li>Python lets you use OS-X/Linux style slashes \"<code>/</code>\" in Windows. Recommended is to use a format such as '<code>C:/Main/FirstDirectory/second-directory/my-file.txt</code>'</li>\n",
    "<li>Relative addressing is allowed, with the current directory understood to be the one where you started your interpreter (Jupyter Notebook in our case). However, that is generally not best practice. Python embraces the concept of Current Working Directory. CWD is the folder your Python is operating from, which might vary by application, such as Jupyter Notebook. The CWD is the <code>'root</code>' for your current session. What this means is that relative file addresses can be tricky to use. You are best off using the absolute reference to all of your files.</li>\n",
    "</ul>\n",
    "<p>When you work with online file documents, you will need to use different Python commands and conventions, as the examples below show. We will offer more explanation on this specific option when the code below is presented.</p>\n",
    "<p>Here are some general references that can explain files and paths further:</p>\n",
    "<ul>\n",
    "<li><a href=\"https://www.pitt.edu/~naraehan/python2/file_path_cwd.html\" target=\"_blank\" rel=\"noopener\">https://www.pitt.edu/~naraehan/python2/file_path_cwd.html</a></li>\n",
    "<li><a href=\"https://docs.python.org/3/library/pathlib.html\" target=\"_blank\" rel=\"noopener\">https://docs.python.org/3/library/pathlib.html</a></li>\n",
    "<li><a href=\"https://realpython.com/working-with-files-in-python/#pythons-with-open-as-pattern\" target=\"_blank\" rel=\"noopener\">https://realpython.com/working-with-files-in-python/#pythons-with-open-as-pattern</a></li>\n",
    "<li><a href=\"https://automatetheboringstuff.com/chapter8/\" target=\"_blank\" rel=\"noopener\">https://automatetheboringstuff.com/chapter8/</a>.</li>\n",
    "</ul>\n",
    "<p>To find what your CWD is for your current session:</p>"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "import os\n",
    "dir(os)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Note there are a couple of things going on in this snippet. First, we have imported the Python built-in module called '<code>os</code>'. Not all commands are brought into memory when you first invoke Python. In this case, we are invoking (or 'importing') the <code>os</code> module. \n",
    "\n",
    "Second, we have invoked the <code>dir</code> command to get a listing of the various functions within the <code>os</code> module. So, go ahead and <code>shift+enter</code> this cell or Run it from the Jupyter Notebook menu to see what <code>os</code> contains.\n",
    "\n",
    "We can invoke other functions with a similar syntax. Another option besides <code>dir</code> is to get <code>help</code> on the current module:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "help(os)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Note these same <code>dir</code> and <code>help</code> commands can be applied to any <code>(module)</code> active in the system.\n",
    "\n",
    "This next example shows another function in <code>os</code> called '<code>walk</code>'. We invoke this function by calling the combined module and function notation using the dot (.) syntax ('<code>os.walk</code>'). We will add a couple more statements to get our directory listing to display ('<code>print()</code>') the directory file names to screen:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "for dirpath, dirnames, files in os.walk('.'):\n",
    "    print(f'Found directory: {dirpath}')\n",
    "    for file_name in files:\n",
    "        print(file_name)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "\n",
    "One of the first things you will learn about Python is that there are often multiple modules, and modules within external libraries, that may be invoked for a given task. It takes time to discover and learn these options, but that is also one of the fun parts of the language.\n",
    "\n",
    "Our next example shows just this, using a new package, <code>pathlib</code>, useful for local files, that has some great path management functions. (This library will be one of our stalwarts moving forward.) \n",
    "\n",
    "Remember we can <code>import</code> functions from add-ons beyond the Python built-ins. We do so via modules again using the import statement, but we now need to identify the library (or 'package') where that module resides. We do so via the '<code>from</code>' statement. Remember, external libraries need to be downloaded and registered via Anaconda (<code>conda</code> or <code>conda-forge</code>) prior to use if they are not already installed on your system. (Recall  that our installed packages are at <code>C:\\1-PythonProjects\\Python\\pkgs</code> based on my own configuration.\n",
    "\n",
    "In this next example we are using the <code>home</code> command within the <code>Path</code> module in the <code>pathlib</code> package. The <code>home</code> command tells us where the '<code>root</code>' is for our current notebook:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 4,
   "metadata": {},
   "outputs": [
    {
     "name": "stdout",
     "output_type": "stream",
     "text": [
      "C:\\Users\\Michael\n"
     ]
    }
   ],
   "source": [
    "from pathlib import Path\n",
    "home = Path.home()\n",
    "print(home)"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Windows is a tricky environment for handling file names, since the native operating system (OS) requires back-clashes ('<code>\\\\</code>') rather than forward-slashes ('<code>/</code>') and also requires the drive designation for absolute paths. We also have the issue of relative paths, which because of CWD (common working directory) can get confused in Python (or rather, in our use of Python).\n",
    "\n",
    "One habit is to adopt the convention of declaring your file targets as a variable (say, '<code>path</code>'), make sure the reference is good, and then refer to the '<code>path</code>' object in the rest of the code to prevent confusion. One code approach to this, including a print of the referenced file is:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "path = r'C:\\1-PythonProjects\\owlready2\\kg\\kko.owl'         # see (A)\n",
    "# path = 'https://raw.githubusercontent.com/Cognonto/CWPK/master/sandbox/builds/ontologies/kko.owl'      # see (A)\n",
    "with open(path) as fobj:                                   # see (B)\n",
    "    for line in fobj:\n",
    "        print (line, end='')"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Note, this example may not work unless you are using local files.\n",
    "\n",
    "We get the absolute file name (<strong>A</strong>) on Windows by going to its location within Windows Explorer, highlighting our desired file in the right panel, and then right-clicking on the path listing shown above the pane and choosing 'Copy address as text'; that is the information placed between the quotes on (<strong>A</strong>). Note also the '<code>r</code>' switch on this line (<strong>A</strong>) (no space after '<code>r</code>'!), which means 'raw' and enables the Windows backslashes to be interpreted properly. Go ahead and <code>shift+enter</code> this file and see the listing (which is also useful to surface any encoding issues, which will appear at the end of the file listing should they exist).\n",
    "\n",
    "Now, the example above is for local files. If you are using the system via MyBinder, we need to load and view our files from online. Here is a different format for accessing such information:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "import urllib.request \n",
    "\n",
    "path = 'https://raw.githubusercontent.com/Cognonto/CWPK/master/sandbox/builds/ontologies/kko.owl'\n",
    "for line in urllib.request.urlopen(path):\n",
    "    print(line.decode('utf-8'), end='')"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "A couple of items for this format deserve comment. First, we need to import a new package, <code>urllib</code>, that carries with it the functions and commands necessary for accessing URLs. There are multiple options available in Python for doing so. This particular one presents, IMO, one of the better formats for viewing text files. Second, we declare the UTF-8 encoding, a constant requirement and theme through the rest of this **CWPK** series. And, third, we add the attribute option of <code>end=''</code> in our <code>print</code> statement to eliminate the extral lines in the printout that occur without it. Python functions often have many similar options or switches available.\n",
    "\n",
    "In any case, the above gives us the basis to load the upper ontology of KBpedia called KKO. We now turn to how we begin to manage our knowledge graphs."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### Import an Ontology\n",
    "So, let's load our first ontology into <code>owlready2</code> applying some of these concepts (note to replace 'target_url' if using the local file option):"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "from owlready2 import *\n",
    "# the local file option\n",
    "# onto = get_ontology(path).load()\n",
    "\n",
    "# the remote file (URL) option\n",
    "onto = get_ontology(target_url).load()\n"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### Inspect Ontology Contents\n",
    "We do not get a confirmation that the file loaded OK, the object name of which is <code>onto</code>, except no error messages appeared (which is good!). Just to test if everything proceeded OK, let's ask the system to return (<code>print</code> to screen) a known class from our kko.owl ontology called '<code>Generals</code>':."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "print(onto.Generals)\n",
    "        "
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Can apply to all of the ontology components (in this case the class, 'Generals').\n",
    "\n",
    "We can also list all of the classes in the ontology:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "list(onto.classes())"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "list(onto.disjoint_classes())"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Armed with these basics we can begin to manipulate the components in our knowleldge graph, the topic for our next installment.\n",
    "\n",
    "### Additional Documentation\n",
    "\n",
    "Here is additional documentation on\n",
    "[owlready2](http://www.lesfleursdunormal.fr/static/informatique/owlready/index_en.html):\n",
    "\n",
    "-   The original [academic\n",
    "    paper](http://www.lesfleursdunormal.fr/_downloads/article_owlready_aim_2017.pdf)\n",
    "-   [owlready2 documentation](https://owlready2.readthedocs.io/)\n",
    "-   owlready2 [PyPl project](https://pypi.org/project/Owlready2/)\n",
    "-   owlready2 [conda-forge\n",
    "    project](https://github.com/conda-forge/owlready2-feedstock)\n",
    "-   <span id=\"Semantic_Technology_Support\" class=\"mw-headline\">[Source\n",
    "    files.](https://bitbucket.org/jibalamy/owlready2/)</span>\n",
    "-   [owlready2 .load() function](https://owlready2.readthedocs.io/en/latest/onto.html#loading-an-ontology-from-owl-files)  \n",
    "-   [Mailing list](http://owlready.8326.n8.nabble.com/).\n",
    "\n",
    "  \n",
    " <div style=\"background-color:#efefff; border:1px dotted #ceceff; vertical-align:middle; margin:15px 60px; padding:8px;\"> \n",
    "  <span style=\"font-weight: bold;\">NOTE:</span> This article is part of the <a href=\"https://www.mkbergman.com/cooking-with-python-and-kbpedia/\" style=\"font-style: italic;\">Cooking with Python and KBpedia</a> series. See the <a href=\"https://www.mkbergman.com/cooking-with-python-and-kbpedia/\"><strong>CWPK</strong> listing</a> for other articles in the series. <a href=\"http://kbpedia.org/\">KBpedia</a> has its own Web site.\n",
    "  </div>\n",
    "\n",
    "<div style=\"background-color:#ebf8e2; border:1px dotted #71c837; vertical-align:middle; margin:15px 60px; padding:8px;\"> \n",
    "\n",
    "<span style=\"font-weight: bold;\">NOTE:</span> This <strong>CWPK \n",
    "installment</strong> is available both as an online interactive\n",
    "file <a href=\"https://mybinder.org/v2/gh/Cognonto/CWPK/master\" ><img src=\"https://mybinder.org/badge_logo.svg\" style=\"display:inline-block; vertical-align: middle;\" /></a> or as a <a href=\"https://github.com/Cognonto/CWPK\" title=\"CWPK notebook\" alt=\"CWPK notebook\">direct download</a> to use locally. Make sure and pick the correct installment number. For the online interactive option, pick the <code>*.ipynb</code> file. It may take a bit of time for the interactive option to load.</div>\n",
    "\n",
    "<div style=\"background-color:#feeedc; border:1px dotted #f7941d; vertical-align:middle; margin:15px 60px; padding:8px;\"> \n",
    "<div style=\"float: left; margin-right: 5px;\"><img src=\"http://kbpedia.org/cwpk-files/warning.png\" title=\"Caution!\" width=\"32\" /></div>I am at best an amateur with Python. There are likely more efficient methods for coding these steps than what I provide. I encourage you to experiment -- which is part of the fun of Python -- and to <a href=\"mailto:mike@mkbergman.com\">notify me</a> should you make improvements.    \n",
    "\n",
    "</div>"
   ]
  }
 ],
 "metadata": {
  "kernelspec": {
   "display_name": "Python 3",
   "language": "python",
   "name": "python3"
  },
  "language_info": {
   "codemirror_mode": {
    "name": "ipython",
    "version": 3
   },
   "file_extension": ".py",
   "mimetype": "text/x-python",
   "name": "python",
   "nbconvert_exporter": "python",
   "pygments_lexer": "ipython3",
   "version": "3.8.5"
  }
 },
 "nbformat": 4,
 "nbformat_minor": 5
}