Building a Mini Portal
In the first part in this series we looked at Drupal and the
Amplify module. We saw how these two could be easily paired.
Part 2 takes our attention from installation of the basic
pieces to configuration of a mini portal. We are going to take a single piece
of content and, drawing on OpenAmplfy's analysis of the content, bring in a
broad array of related information from the analysis, from existing data, and
from several remote web services.
Creating Content
In part 1 of this series we configured Drupal for using
OpenAmplify's web service to analyze Drupal's content. As you may recall, the
Amplify module can be used to perform an analysis on any Drupal content type.
In my previous example, I used a type called "Amplified Page." Its definition
looks like this:
That's it - name, type, and description. An "Amplified Page" will only have a
title and a body. There are no CCK fields or anything of the sort. Our type is
very basic. Yet we will build something surprisingly detailed from such a
simple page.
The first step in building our mini portal is to add a new
piece of content that uses this type. Here I have copied and pasted the
editor's summary of my book Learning Drupal 6 Module Development
(http://www.packtpub.com/drupal-6-module-development/book). As we will see a
little later, a piece of text like this is a gold mine of data when analyzed
using OpenAmplify.
We will add the new content by going to Create content
> Amplified page and entering our text:
As soon as we create this new node the Amplify module will submit it to
OpenAmplify for analysis, and then store the resulting XML document in Drupal's
database for later use.
Now that we have a piece of content, we need to do a little
additional configuration to transform OpenAmplify's analysis into a mini portal
of information.
Configuring the QP Services Module
In Part 1 we installed the QP Services (http://drupal.org/project/qpservices)
module. This module is a demonstration of how QueryPath, OpenAmplify, and other
web APIs can be used in conjunction to create powerful applications. In Part 3,
we will be taking a look under the hood of this example module to learn how to
use the API.
But for now, we will merely be configuring it through
Drupal's Administration interface.
Based on feedback I received on the first article, I
have released a new version of QP Services since the first part of this series
was published. You may want to double-check to make sure you have the newest version
of this module. And thanks for the feedback!
To configure QP Services, we will go to Administer >
Site configuration > QP Services. This screen has a handful of settings
- mostly regarding API keys for supported web services.
QP Services supports several Web Service APIs out of the
box, including these:
-
Twitter
-
Shopping.Com
-
Bloglines
-
Amazon AWS
-
Technorati (whose API is currently offline)
-
Flickr
Some of these web services require API keys. The screen
shown above provides a place to enter these keys. Only two of the four APIs
that we will use require keys: Flickr and Shopping.Com. In this example, we
will not be using Technorati or Amazon, so no keys are entered.
Flickr API keys can be obtained at Code.Flickr
(http://code.flickr.com/), and Shopping.Com API keys can be obtained at their
developer site (http://developer.shopping.com).
Again, the QP Services module is intended to be a
demonstration of the possibilities. Adding support for new Web APIs is
generally an easy thing, as we will see next time. However, a more robust
module would also contain more configuration options for controlling the
details of these APIs.
With our module configured, the next thing to do is build
out our mini-portal.
Configuring Blocks
In Drupal parlance, a piece of content is a node.
Earlier, we created an Amplified Page node. When a page is displayed on
a Drupal site, generally there are smaller pieces of content surround the node.
These appear in the right- and left-hand sides, as well as in the top or bottom
parts of the page. Navigation, ads, and lists of related content may all be
displayed in this small chunks. In Drupal parlance, these chunks are called blocks.
To build our mini portal, we are going to begin with our
node, and we are going to surround it with blocks that begin with the
OpenAmplify data and use the information therein to pull in related content
from other websites.
More specifically, we are going to do the following:
-
Use Flickr to pull in related images.
-
Create dynamic SVG images based on rating information.
-
Build a "mood cloud" (or "sentiment cloud")
representing the author's disposition regarding certain topics.
-
Bring in related products from Shopping.Com.
-
Display a list of topics discussed in the
article.
-
Show some related tweets from Twitter.
-
Create a list of related content from Bloglines.
So from one small piece of text, we will show a variety of
related content. Before we take a look at the configuration of the blocks,
let's get a glimpse of what the end result will look like:
The screenshot above identifies the various parts of our mini portal page.
These are all Drupal blocks provided by the QP Services module.
Adding these blocks is done through the Administer >
Site building > Blocks page. For the most part, assinging blocks to a
Drupal site is a matter of dragging and dropping. In general Drupal
configurations, such as the one above, blocks are assigned site-wide. Here's
what our site-wide block settings look like for the site above:
Note that a few (User Login and Amplify SPARQL)
are not directly used on the page we saw above. However, since they are used
elsewhere on the site, they are displayed in the block settings. The other
blocks are all displayed in the screenshot above. Note that we don't have to do
any special configuration of these blocks. They will appear when content is
amplified, and will be hidden otherwise.
By creating our piece of content and configuring these
blocks, we have assembled a mini portal without having to write a line of
custom code, and without having to go out hunting for related content. By
coupling OpenAmplify and a handful of web services, we let the application do
the work for us. In the last section of this article, let's take a closer look
at a few of these blocks.
Details of the QP Services Blocks
In this final section, we will look in detail at a few of
the blocks shown in the large screenshot above.
Sentiment and Mood Clouds
The first block to look at is the Mood Cloud. This is a
simple tool for displaying sentiment information. By taking OpenAmplify's Top
Topics and looking at polarity and guidance, we can easily
organize the topics list along three axes.
To give a graphic example, let me pull sentiment clouds
from two similar articles:
In 2009, the Denver Broncos football team traded quarterbacks with the Chicago
Bears. Kyle Orton went from Chicago to Denver, while Jay Cutler turned the
opposite way.
On the left is a mood cloud from the Denver Post that
week.
On the right is an article from the same day's Chicago
Tribune.
The terms appear in order of frequency. The most
frequently appearing terms float to the top of the list. The relative size of
the link reflects OpenAmplify's rating of the extent to which the author is offering
guidance on the topic. Often, this seems to couple well with the degree of
authority an author seems to be representing on the topic.
Finally, the color of the term indicates sentiment. Green
is positive sentiment. Blue is neutral. Red is negative. It gives some idea of
how Denver felt about Chicago that week - and vice versa.
Bloglines, Flickr, Shopping.Com, and Twitter
Our mini portal used a handful of web services to pull in
external content. For example, we pulled some related articles from Bloglines:
To get this data, the QP Services module merely selects a couple of the top
topics and uses them to search Bloglines' RSS feed search. The returned RSS
data can then be easily parsed and formatted into a list of related articles.
Note that Bloglines does the excerpting and highlighting for us! On our side,
we merely pull and display.
This trick of taking terms identified by OpenAmplify -
topics, domains, etc. - and turning them into queries against other web
services is a highly effective method of retrieving related content. A similar
strategy is used to retrieve a list of related images from Flickr, and a list
of related products from Shopping.com:
The Flickr montage is made up entirely of photos tagged "Drupal", and the list
of books was generated from the topics "Matt" and "Drupal." Thus, with a simple
heuristic, we have managed to retrieve some very compelling visual content.
About This Page
The last block to look at is the "About This Page" block.
This uses information from OpenAmplify in a more direct way.
Above, the same block is shown for two different articles. On the left is the
block from the "Learning Drupal 6" page. On the right is a block from one of
the football articles mentioned earlier.
As you may notice, we have made direct use of some of the
information OpenAmplify uncovered during analysis:
-
Domain and Subdomain
-
Domain topics
-
Locations
-
Flamboyance
-
Slang
-
Education level
As you can see in the comparison above, not all of these
may be identified for every given text. But the accuracy level of these items
is generally very high.
The last three, flamboyance, slang, and education, have
been transformed into simple line graphs. These graphs were assembled on the
fly using Scalable Vector Graphics files (an XML format). They could also have
been built using other image formats, or even using CSS and HTML. Be that as it
may, the goal in presenting the data this way is to exhibit how basic
information returned from OpenAmplify can be portrayed in eye-catching ways.
Conclusion of
Part 2
In the first part of this series, we took a look at Drupal
and the modules that support OpenAmplify. This second part has focused on
building a mini portal with just those modules. To create this mini portal, we
did only a little configuration and created only one piece of content. Thus, it
is easy to see how sophisticated sites can be built by combining OpenAmplify's
analysis with other freely available web services.
In the next part, we will change focus a bit. We will take
a look at some code, learning to make use of the Amplify module's API to build
our own tools.
Posted
22 Jan 2010 12:52 PM
by
DaveW