Generating Language – Part 6

Time for a short recap: We’ve now created a set of Java methods using simpleNLG, which take care of surface realisation for individual sentences. Then we created a set of functions in Python, which enable us to do some easier data work than would otherwise be available within Java. The data work we’ll see here in the blog is rather simple, but in real-world practice we do some unsupervised learning and, as a separate module, text mining. More on the text mining in a future post.

Now we’re going to deploy the NLG framework as a RESTful API using Flask. As always, start with an import. We’ll be using just two functions from Flask for the time being:

from flask import Flask, request

Flask() is what we use to create the app itself, while request.get_json() will do the work of receiving POSTed data from the user’s API call. It’s really super easy; first we name our app, then we define a function to be called when a request is made.

app = Flask(__name__)

@app.route('/your_url/', methods = ['POST','GET'])
def run_this():
    data = request.get_json()
    out = sentence1(data) + ' ' + sentence2(data) + ' ' sentence3(data)
    return out

Here, we set the url, specify which REST methods are allowed, and define a function run_this() to be called when a request is made. The user is to post json data with a pre-specified structure, which is retrieved by request.get_json() we then simply concatenate all of the sentences we which to include in the description and return a string.

On the back end, you’re going to run your Java program to open the gateway, then do this in a terminal to start the app running:

$ export
$ flask run
 * Running on

On the front end, any of the normal methods for making requests from RESTful APIs are appropriate. This really concludes the basic architecture of our NLG system, but the project isn’t done yet.

So far, we’ve assumed that data are available and put together into a nice, neat package to flow into the sentence planner functions and realisation engine. In my environment, the engineers take care of the vast majority of this work, but if we want the system to really be smart about what it communicates to the end user, we’re going to need some AI to do the heavy lifting of creating data. Software engineers aren’t generally in the business of writing AI; that falls on the data scientist to work out.

Edit: It’s become difficult to find a way to present later developments of this project in a way that is both sensibly positioned as part of this series and avoids sharing proprietary information, so this will actually be the last post in Generating Language. Other stuff I work on will find it’s way into posts on Breaking Bayes, but I’ll be presenting them as general problems, not connected to this particular project.

Leave a Reply