sippycup-unit-0.ipynb

{
 "cells": [
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "<img src=\"img/sippycup-small.jpg\" align=\"left\" style=\"padding-right: 30px\"/>\n",
    "\n",
    "<h1 style=\"line-height: 125%\">\n",
    "  SippyCup<br />\n",
    "  Unit 0: Introduction to semantic parsing\n",
    "</h1>\n",
    "\n",
    "<p>\n",
    "  <a href=\"http://nlp.stanford.edu/~wcmac/\">Bill MacCartney</a><br/>\n",
    "  Spring 2015\n",
    "  <!-- <a href=\"mailto:wcmac@cs.stanford.edu\">wcmac@cs.stanford.edu</a> -->\n",
    "</p>"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "<div style=\"margin: 0px 0px; padding: 10px; background-color: #ddddff; border-style: solid; border-color: #aaaacc; border-width: 1px\">\n",
    "This is Unit 0 of the <a href=\"./sippycup-unit-0.ipynb\">SippyCup codelab</a>.\n",
    "</div>"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "SippyCup is a simple semantic parser, written in Python, created purely for didactic purposes. The design favors simplicity and readability over efficiency and performance.  The goal is to make semantic parsing look easy!\n",
    "\n",
    "SippyCup demonstrates an approach to semantic parsing based around:\n",
    "  - a context-free grammar with semantic attachments,\n",
    "  - a chart-parsing algorithm,\n",
    "  - a linear, feature-based scoring function for ranking candidate parses,\n",
    "  - learning of scoring parameters using stochastic gradient descent, and\n",
    "  - limited forms of grammar induction.\n",
    "\n",
    "We present applications of SippyCup to three different domains:\n",
    "  - natural language arithmetic: \"two times three plus four\"\n",
    "  - travel queries: \"driving directions to williamsburg virginia\"\n",
    "  - geographical queries: \"how many states border the largest state\"\n",
    "\n",
    "SippyCup was inspired by, and partly adapted from, the [demonstration code][] published as a companion to [Liang & Potts 2015][], \"Bringing machine learning and compositional semantics together\".  It was developed primarily for the benefit of students in Stanford's [CS224U: Natural Language Understanding], and therefore contains exercises (without solutions) for use in the class.  However, it should be of use to anyone interested in learning about semantic parsing.\n",
    "\n",
    "  [demonstration code]: https://github.com/cgpotts/annualreview-complearning\n",
    "  [Liang & Potts 2015]: http://www.annualreviews.org/doi/pdf/10.1146/annurev-linguist-030514-125312\n",
    "  [CS224U: Natural Language Understanding]: http://www.stanford.edu/class/cs224u/\n",
    "  \n",
    "SippyCup remains a work in progress, and you will find a number of TODOs throughout this codelab and the accompanying Python codebase.  You will likely also find errors!  You can help to contribute to SippyCup by sending corrections to [the author](mailto:wcmac@cs.stanford.edu) or by sending a pull request to the SippyCup [GitHub repository][].\n",
    "\n",
    "  [GitHub repository]: https://github.com/wcmac/sippycup"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### Table of contents"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "- [Unit 0: Introduction to semantic parsing](./sippycup-unit-0.ipynb)\n",
    "  - Task definition\n",
    "  - Example applications\n",
    "  - Why is semantic parsing hard?\n",
    "  - Designing a semantic representation\n",
    "    - Ambiguity resolution\n",
    "    - Canonicalization\n",
    "    - One representation to rule them all?\n",
    "  - Semantic parsing vs. machine translation\n",
    "  - The SippyCup codebase\n",
    "- [Unit 1: Natural language arithmetic](./sippycup-unit-1.ipynb)\n",
    "  - Example inputs\n",
    "  - Semantic representation\n",
    "  - Example data\n",
    "  - Syntactic parsing\n",
    "    - Grammars and rules\n",
    "    - Chart parsing\n",
    "  - Adding semantics\n",
    "  - Scoring candidate parses\n",
    "  - Learning the scoring model\n",
    "    - Learning with stochastic gradient descent (SGD)\n",
    "    - Learning from semantics\n",
    "    - Learning from denotations\n",
    "  - Inducing the lexicon\n",
    "  - Exercises\n",
    "- [Unit 2: Travel queries](./sippycup-unit-2.ipynb)\n",
    "  - Example inputs\n",
    "  - Semantic representation\n",
    "  - Example data\n",
    "  - Enriching the `Grammar` class\n",
    "    - Annotators\n",
    "    - N-ary lexical rules\n",
    "    - Unary compositional rules\n",
    "    - N-ary compositional rules\n",
    "    - Optional elements\n",
    "    - The start symbol\n",
    "  - Grammar engineering\n",
    "    - Phrase-bag grammars\n",
    "    - Travel locations\n",
    "    - The `GeoNamesAnnotator`\n",
    "    - Travel modes\n",
    "    - Travel triggers\n",
    "    - Request types\n",
    "    - Optionals\n",
    "    - Negative examples\n",
    "<!-- - (TODO: Overtriggering and undertriggering ?) -->\n",
    "  - Exercises\n",
    "- [Unit 3: Geography queries](./sippycup-unit-3.ipynb)\n",
    "  - The Geo880 dataset\n",
    "  - The Geobase knowledge base\n",
    "  - Semantic representation\n",
    "    - The `GraphKB` class\n",
    "    - The `GraphKBExecutor` class\n",
    "    - Using `GraphKBExecutor` with Geobase\n",
    "  - Grammar engineering\n",
    "    - Optionals\n",
    "    - Entities and collections\n",
    "    - Types\n",
    "    - Relations and joins\n",
    "    - Intersections\n",
    "    - Superlatives\n",
    "    - Reverse joins\n",
    "  - Feature engineering\n",
    "  - Exercises"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Task definition"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Semantic parsing is a computation which takes a linguistic input and returns as output a structured, machine-readable representation of its meaning, known as the *semantic representation* (or, informally, \"the semantics\").  The semantic representation is a computational object that captures key elements of the meaning of the input and enables the machine to respond appropriately.  Depending upon the application, it can be a simple string, a tree, a nested map, an XML document, an SQL query, or a real-valued vector.  In many cases, the semantic representation can be viewed as a little program, or as a parameterized request to a backend service.\n",
    "\n",
    "For example, in a question-answering application, we may want to map a linguistic input such as\n",
    "\n",
    "    \"how tall is obama\"\n",
    "\n",
    "into a semantic representation such as\n",
    "\n",
    "    (/person/height /m/02mjmr)\n",
    "\n",
    "Of course, this is useful only if there exists some other component that can make sense of this semantic representation and take appropriate action — for example, by interpreting it as a query against [Freebase][] and retrieving the answer, namely 1.85 meters.\n",
    "\n",
    "[Freebase]: http://www.freebase.com/m/02mjmr\n",
    "\n",
    "The downstream component which consumes the output of the semantic parser is known as the *executor*.  It is a function which takes a semantic representation as input and performs some computation specified by the semantics.  If it returns an output, the output is known as the _denotation_.\n",
    "\n",
    "<img src=\"img/sippycup-figure-1.svg\" />\n",
    "    \n",
    "The idea is to achieve a [separation of concerns][].  We wish to endow the overall system with the ability to respond to linguistic inputs.  The semantic parser focuses on dealing with the complexities of human language: [polysemy][], [syntactic ambiguity][], [indexicality][] and other forms of context-dependence, [ellipsis][], and so on.  It emits an output which captures the key elements of the user's intent in a clear, unambiguous, fully-grounded, machine-readable representation.  The executor is thereby freed of the burden of interpreting language, and can focus on its application-specific business.\n",
    "\n",
    "  [separation of concerns]: http://en.wikipedia.org/wiki/Separation_of_concerns\n",
    "  [polysemy]: http://en.wikipedia.org/wiki/Polysemy\n",
    "  [syntactic ambiguity]: http://en.wikipedia.org/wiki/Syntactic_ambiguity\n",
    "  [indexicality]: http://en.wikipedia.org/wiki/Indexicality\n",
    "  [ellipsis]: http://en.wikipedia.org/wiki/Ellipsis\n",
    "    \n",
    "Of course, semantic representations need not look like the example shown here.  As we'll see in a moment, different problem settings may demand quite different semantic representations."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Example applications"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "In this codelab, we'll take a close look at three example applications of semantic parsing: one rather artificial, the others more realistic.\n",
    "\n",
    "Our [first case study][] will follow [Liang & Potts 2015][] in considering the problem of interpreting natural language arithmetic expressions, such as:\n",
    "\n",
    "  [first case study]: ./sippycup-unit-1.ipynb\n",
    "  [Liang & Potts 2015]: http://www.annualreviews.org/doi/pdf/10.1146/annurev-linguist-030514-125312\n",
    "\n",
    "    \"one plus one\"\n",
    "    \"minus three minus two\"\n",
    "    \"three plus three minus two\"\n",
    "    \"two times two plus three\"\n",
    "\n",
    "In this problem setting, we may wish to produce semantic representations which are [binary expression trees][]:\n",
    "\n",
    "  [binary expression trees]: http://en.wikipedia.org/wiki/Binary_expression_tree\n",
    "\n",
    "    (+ 1 1)\n",
    "    (- (- 3) 2)\n",
    "    (- (+ 3 3) 2)\n",
    "    (+ (* 2 2) 3)\n",
    "\n",
    "These representations fully resolve the ambiguity present in the linguistic inputs, and can be evaluated by a simple, deterministic executor to produce a numeric answer.\n",
    "\n",
    "In our [second case study][], we'll examine a more realistic application: the domain of queries about travel and transportation, such as:\n",
    "\n",
    "  [second case study]: ./sippycup-unit-2.ipynb\n",
    "\n",
    "    \"birmingham al distance from indianapolish in\"\n",
    "    \"directions from washington to canada\"\n",
    "    \"discount travel flights to austin texas\"\n",
    "\n",
    "A possible style of semantic representation (described further in [Unit 2](./sippycup-unit-2.ipynb#A-semantic-representation-for-travel-queries)) for this domain is:\n",
    "\n",
    "    {domain: travel, type: distance,\n",
    "       origin: {id: 4259418, name: \"Indianapolis, IN, US\"},\n",
    "       destination: {id: 4049979, name: \"Birmingham, AL, US\"}}\n",
    "    {domain: travel, type: directions,\n",
    "       origin: {id: 4140963, name: \"Washington, DC, US\"},\n",
    "       destination: {id: 6251999, name: \"Canada\"}}\n",
    "    {domain: travel, mode: air,\n",
    "       destination: {id: 4671654, name: \"Austin, TX, US\"}}\n",
    "\n",
    "Here the request types and transportation modes have been resolved to canonical values, and the locations have been resolved to unique identifiers in the [GeoNames][] geographical database.  It's easy to imagine passing representations like these to a backend API, such a route-planning service, for execution.\n",
    "\n",
    "  [GeoNames]: http://www.geonames.org/\n",
    "\n",
    "Our [third case study][] will focus on the [Geo880][] corpus developed in Ray Mooney's group at UT Austin, which has for many years served as a standard evaluation for semantic parsing systems.  (See, for example, [Zelle & Mooney 1996][], [Tang & Mooney 2001][], [Zettlemoyer & Collins 2005][], and [Liang et al. 2011][].)  The Geo880 corpus contains 880 questions about U.S. geography, often with complex compositional structure.  Examples include:\n",
    "\n",
    "  [third case study]: ./sippycup-unit-3.ipynb\n",
    "  [Geo880]: http://www.cs.utexas.edu/users/ml/geo.html\n",
    "  [Zelle & Mooney 1996]: http://www.aaai.org/Papers/AAAI/1996/AAAI96-156.pdf\n",
    "  [Tang & Mooney 2001]: http://www.cs.utexas.edu/~ai-lab/pubs/cocktail-ecml-01.pdf\n",
    "  [Zettlemoyer & Collins 2005]: http://people.csail.mit.edu/lsz/papers/zc-uai05.pdf\n",
    "  [Liang et al. 2011]: http://www.cs.berkeley.edu/~jordan/papers/liang-jordan-klein-acl2011.pdf\n",
    "\n",
    "    \"which states border texas?\"\n",
    "    \"how many states border the largest state?\"\n",
    "    \"what is the size of the capital of texas?\"\n",
    "\n",
    "Here again, many styles of semantic representation are possible.  One possibility (described further in [Unit 3](./sippycup-unit-3.ipynb#geoquery-semantic-representation)) is:\n",
    "\n",
    "    (.and state (borders /state/texas))\n",
    "    (.count (.and state (borders (.argmax area state))))\n",
    "    ((/state/texas capital) population)\n",
    "\n",
    "The Geo880 corpus is a paired with a simple geographical database known as [Geobase][].  A suitable executor can evaluate these semantic representations against Geobase to return answers.\n",
    "\n",
    "  [Geobase]: http://www.cs.utexas.edu/users/ml/nldata/geoquery.html\n",
    "\n",
    "Academic researchers have explored many other potential applications for semantic parsing, including:\n",
    "\n",
    "- robot control ([Matuszek et al. 2012][])\n",
    "  - `\"go to the third junction and take a right\"`\n",
    "- question answering against Freebase ([Cai & Yates 2013][], [Kwiatkowski et al. 2013][], [Berant et al. 2013][])\n",
    "  - `\"how many countries use the euro\"`\n",
    "- 3D scene generation ([Chang et al. 2014][])\n",
    "  - `\"there is a room with a desk and a red chair\"`\n",
    "- teaching computers to play games ([Branavan et al. 2012][])\n",
    "  - `\"phalanxes are twice as effective at defending cities as warriors\"`\n",
    "- solving algebra word problems ([Kushman et al. 2014][])\n",
    "  - `\"an amusement park sells two kinds of tickets ...\"`\n",
    "\n",
    "[Matuszek et al. 2012]: http://www.csee.umbc.edu/~cmat/Pubs/MatuszekISER2012.pdf\n",
    "[Cai & Yates 2013]: http://www.cis.temple.edu/~yates/papers/textual-schema-matching.pdf\n",
    "[Kwiatkowski et al. 2013]: http://yoavartzi.com/pub/kcaz-emnlp.2013.pdf\n",
    "[Berant et al. 2013]: http://cs.stanford.edu/~pliang/papers/freebase-emnlp2013.pdf\n",
    "[Chang et al. 2014]: http://nlp.stanford.edu/pubs/scenegen-sp2014.pdf\n",
    "[Branavan et al. 2012]: https://jair.org/media/3484/live-3484-6254-jair.pdf\n",
    "[Kushman et al. 2014]: http://homes.cs.washington.edu/~lsz/papers/kazb-acl14.pdf\n",
    " \n",
    "\n",
    "In each case, the task is to map a linguistic input into a structured, machine-readable representation of meaning, on which some downstream component can take action."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Why is semantic parsing hard?"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "(TODO: flesh out a section explaining the key challenges of semantic parsing.)\n",
    "\n",
    "- the mind-boggling variability of linguistic expression: many expressions, one meaning\n",
    "- ambiguity: one expression, many meanings\n",
    "- context-dependence\n",
    "- messy inputs: typos, misspellings, loose or mangled syntax\n",
    "- scalability: don't want to have to manually engineer everything — automated learning instead\n",
    "- internationalization"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Designing a semantic representation"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "When developing a semantic parsing system for a new domain, one of the first tasks must be to choose a good semantic representation.  After all, this representation is the target output of the system, so its design will drive many other design decisions.  We can't control the form of the linguistic inputs, but we *can* control the design of the semantic outputs.\n",
    "\n",
    "(Actually, in some problem settings, we have to work with a downstream executor over whose request language we have no control.  For example, the executor may be an API provided by a third party, or it may be a relational database which only responds to SQL queries.  However, even in such situations, we have the opportunity to control the design of our semantic representation, by inserting into the stack an *adapter* which performs a deterministic conversion from our semantic representation into the request language of the executor.)\n",
    "\n",
    "So what constitutes a good semantic representation?  We can't make rigid generalizations, but we can identify some guiding principles.  Above all, in order to achieve a separation of concerns between the semantic parsing system and the executor, the semantic representation must be straightforwardly machine-readable by the executor.  Machine-readability means that executor can immediately understand what it needs to do, and get straight to work.  (Actually, machine-*interpretable* would be a more accurate term.  In some limited sense, any ASCII-encoded text is machine-readable, but it is usually not machine-interpretable.  But we'll stick with the standard term.)  With consideration, two hallmarks of machine-readability emerge: *ambiguity resolution* and *canonicalization*.  <!-- (TODO: rewrite this paragraph.) -->"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### Ambiguity resolution"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Ambiguity resolution means that if an input has two different meanings, it should have two different semantic representations.  For example, consider the input \"how big is new york\".  This has at least four different meanings, depending on whether we take \"big\" to refer to population or area, and on whether we take \"new york\" to refer to the city or the state.  If all four interpretations are valid, then our semantic parser should generate four semantic representations, perhaps along with some kind of scores.  But when the executor receives one of these semantic representations as input, it has no decisions to make — it can take action immediately without having to do further interpretation.\n",
    "\n",
    "<img src=\"img/sippycup-figure-2.svg\" />"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### Canonicalization"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Canonicalization is the obverse of ambiguity resolution: it means that if two inputs have the same meaning, they should have the same semantic representation.  For example, consider the inputs \"nyc population\" and \"how many people live in new york city\".  These have the same meaning, so they should have the same representation — a *canonical* representation.  Or consider the inputs \"next thanksgiving\" and \"november 26\".  As of this writing (in early 2015), these phrases refer to the same date, so they should have the same representation — perhaps the [ISO 8601][] representation \"2015-11-26\".  Canonicalization thus means using unique identifiers for entities, and fully grounding expressions whose meaning depends on context.\n",
    "\n",
    "  [ISO 8601]: http://xkcd.com/1179/\n",
    "  \n",
    "<img src=\"img/sippycup-figure-3.svg\" />\n",
    "\n",
    "In some problem settings, canonicalization is less critical than ambiguity resolution, because some downstream executors can tolerate two different ways of saying the same thing.  But the great virtue of canonicalization is that it makes checking semantic *equivalence* as easy as checking *equality* of the semantic representations.  For example, the semantic equivalence of \"two forty five pm\" and \"quarter of three in the afternoon\" may not be immediately obvious (to a machine), but becomes trivial if both are represented by 14:45."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "### One representation to rule them all?"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "In the example applications above, we showed three quite different styles of semantic representation.  Indeed, most academic research in semantic parsing has used application-specific semantic representations, although many of these share some common elements (such as the use of the [simply typed lambda calculus][]).\n",
    "\n",
    "  [simply typed lambda calculus]: http://en.wikipedia.org/wiki/Simply_typed_lambda_calculus\n",
    "\n",
    "But a natural question is: couldn't we design a single, universal semantic representation, capable of representing in machine-readable form all meanings which can be expressed in natural language?  Such a representation would not only spare us the trouble of inventing a new representation for each application; it would also open the door to effortlessly combining semantic parsing models which had been developed for different domains.  For example, we can imagine combining an arithmetic model with a travel model to interpret inputs like \"four times the distance from boston to miami\".\n",
    "\n",
    "It's a tempting idea, and an old one.  [Leibniz][], for example, dreamed of creating a [*characteristica universalis*][] which would serve as a sort of algebra of ideas and thereby endow all thought with the exactitude of arithmetic.  Since Leibniz's time, there have been [many attempts][] to construct universal logical languages for human use, such as [Lojban][].  However, such languages fail the test of true machine-readability.  The ideal representation should enable a machine to take appropriate action, for example, by testing equivalence or performing simple inferences.\n",
    "\n",
    "  [Leibniz]: http://en.wikipedia.org/wiki/Gottfried_Wilhelm_Leibniz\n",
    "  [*characteristica universalis*]: http://en.wikipedia.org/wiki/Characteristica_universalis\n",
    "  [many attempts]: http://en.wikipedia.org/wiki/Characteristica_universalis#More_recent_projects\n",
    "  [Lojban]: http://en.wikipedia.org/wiki/Lojban\n",
    "  [recognizing textual entailment]: http://en.wikipedia.org/wiki/Textual_entailment\n",
    "\n",
    "One recent creation that might seem like a better candidate is the [Abstract Meaning Representation][] (AMR) being developed at [ISI][].  As a simple example, all of these inputs:\n",
    "\n",
    "  [Abstract Meaning Representation]: http://amr.isi.edu/\n",
    "  [ISI]: http://www.isi.edu/home\n",
    "\n",
    "    the boy wants the girl to believe him\n",
    "    the boy wants to be believed by the girl\n",
    "    the boy has a desire to be believed by the girl\n",
    "    the boy's desire is for the girl to believe him\n",
    "    the boy is desirous of the girl believing him \n",
    "\n",
    "are represented by the same AMR:\n",
    "\n",
    "    (w / want-01\n",
    "       :ARG0 (b / boy)\n",
    "       :ARG1 (b2 / believe-01\n",
    "                 :ARG0 (g / girl)\n",
    "                 :ARG1 b))\n",
    "\n",
    "(Note that the variable `b` appears twice, once as the `:ARG0` of `want-01`, and once as the `:ARG1` of `believe-01`.  You can learn more about how AMR works by reading the [AMR specification][].)\n",
    "\n",
    "  [AMR specification]: https://github.com/amrisi/amr-guidelines/blob/master/amr.md\n",
    "\n",
    "These examples might give us hope that AMR can satisfy our goals for a semantic representation.  By abstracting away from certain lexical choices (\"want\" vs. \"desire\") and syntactic choices (active vs. passive), AMR canonicalizes these inputs to a common representation, and thus renders obvious their semantic equivalence.\n",
    "\n",
    "But as Hal Daumé III argues in a persuasive [blog post][], AMR doesn't go nearly far enough in this direction to serve as a representation over which we can reliably perform automated reasoning.  It resolves some kinds of ambiguity, but not others.  It achieves some canonicalization, but not all.  There are many kinds of semantically equivalent transformations — lexical, compositional, logical — whose AMR formulations are not obviously equivalent.  In fact, AMR seems to be a bit of a hodge-podge, reflecting some information about lexical choice, some about syntactic structure, and some about semantic content.  In many ways, it looks like a souped-up version of [semantic role labeling][].  Like SRL, AMR may be useful for some purposes, but it can't reliably be used as a vehicle for inference.  (To be fair, the creators of AMR never promised this — they have been motivated rather by the goals of machine translation.)\n",
    "\n",
    "  [blog post]: http://nlpers.blogspot.com/2014/09/amr-not-semantics-but-close-maybe.html\n",
    "  [semantic role labeling]: http://en.wikipedia.org/wiki/Semantic_role_labeling\n",
    "\n",
    "(Note that if AMR *could* be used for automated reasoning, then a good AMR parser would provide a simple solution to the problem of [recognizing textual entailment][] (RTE), that is, recognizing whether one natural-language sentence can be inferred from another.  One would simply parse both sentences into AMR, and then apply an automated reasoner to check entailment.  To my knowledge, no one has demonstrated that this is possible.)\n",
    "\n",
    "  [recognizing textual entailment]: http://en.wikipedia.org/wiki/Textual_entailment\n",
    "\n",
    "In short, my view is that AMR is not a suitable target representation for semantic parsing.  Indeed, after decades (or even centuries!) of failures, I'm skeptical of any attempt to define a universal, machine-readable semantic representation, and prefer instead to develop application-specific representations as needed."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Semantic parsing vs. machine translation"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "(TODO)\n",
    "- Both tasks involve translating from one semantic representation into another.\n",
    "- In both tasks, the semantic representations often have complex structures which are related in complex ways.\n",
    "- But in machine translation, the target semantic representation is NOT machine-readable!  Rather, it is _human_-readable."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## The SippyCup codebase"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "The codelab you're reading has been published as an [IPython Notebook][], which makes it easy to combine text and interactive Python code.  If you're new to Python, you might find this [Python tutorial][] useful.\n",
    "\n",
    "  [IPython Notebook]: http://ipython.org/notebook.html\n",
    "  [Python tutorial]: http://cs231n.github.io/python-numpy-tutorial/\n",
    "\n",
    "However, SippyCup is more than this codelab.  First and foremost, it is a library of Python source files, which should be found in the [same directory](./) as the codelab you're reading.  If not, you can find the codelab and the source files together in the [SippyCup GitHub repository][].  Note that this codelab uses `import` statements to pull in definitions of certain utility classes and functions from the accompanying source files.  If the source files are missing, running the codelab code interactively will cause those imports to fail.\n",
    "\n",
    "  [SippyCup GitHub repository]: https://github.com/wcmac/sippycup\n",
    "\n",
    "You will observe that the SippyCup code architecture does not always adhere to the principles of object-oriented design.  Functionality which might naturally be captured by instance methods of classes will in some cases appear instead in standalone static functions.  This is in order to facilitate an incremental presentation in this codelab format.\n",
    "\n",
    "Let's get started with [Unit 1](./sippycup-unit-1.ipynb)!"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    " "
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Copyright (C) 2015 Bill MacCartney"
   ]
  }
 ],
 "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.5.1"
  }
 },
 "nbformat": 4,
 "nbformat_minor": 0
}