I work on a computer system called IBM Watson – I might have mentioned it once or twice before?
Yesterday, IBM unveiled the progress that we and our partners have made with Watson in healthcare at an event in New York.
I didn’t get to go, but I did keep half an eye on what was happening through twitter. Here are some of the tweets that caught my eye.
IBM Watson is a computer system created to answer questions – questions posed in unstructured, free, natural English language.
It answers using knowledge that it builds for itself by reading and understanding the contents of books and other documents.
It learns how to identify answers by being trained, learning from experience how to interpret the evidence in it’s knowledge.
I wrote a (long and rambling) post in January about work that had been done on Watson since it was unveiled to the world.
Here’s a quick overview of a few things that’s happened since then.
I’ve tried to explain IBM Watson to a lot of people this year. A common theme in questions I’ve had has been comparing it to search engines like Google.
Sometimes people ask why one is “better” than another. Sometimes they just ask how they are different.
It’s not surprising. A natural response to learning about something new is to put it into context of things that we already know.
In addition, we describe Watson as a question answering technology and over the last few years many people have perhaps become a bit conditioned to thinking that if they have a question then they can Google for it.
There are many differences between search engines and Watson, both in what they can do, and in how they try to do it.
Here is one example.
This summer, I was the mentor for a team of interns on an Extreme Blue project. I’ve written about the project, using machine learning and natural language processing to build a smarter screenreader. But I didn’t explain “Extreme Blue”.
Promotional stuff about Extreme Blue is on ibm.com, but aimed at students who could apply to be interns. I want to talk about what it’s like to be a mentor, as it’s one of the best things I’ve done at IBM.
Overview
Extreme Blue is IBM’s summer internship programme. Every year, IBM locations around the world give teams of students projects to work on.
It’s explained on ibm.com but in a nutshell, a team is four students: three with a technical background, one with a business background. Each team are given one project to work on, a challenge they spend their summer trying to solve.
I went to London today to be interviewed for a radio programme on the BBC.
The topic was a project that I’ve been working on over the summer.
I’m not a typical spokesperson, certainly not for something the size of IBM. I’m definitely happier as the behind-the-scenes geek type. The prospect of going on the radio to represent the project, let alone IBM, was more than a little terrifying.
But my best efforts to get someone more able to talk coherently failed horribly, and this afternoon I dutifully got the train up to London to go to Broadcasting House.
I was in London yesterday to give a talk about the work that has been done with Watson in the last year or so. Rather cruelly, the organisers filmed me and put it on the Internet. 😉
If you can ignore my ridiculous voice, some incoherent rambling, an uncomfortable and ill-fitting suit, and a lot of “erm” and “umm”, there was some interesting stuff in there, so I thought I’d share it.
Overview
A side-project I’ve been playing with in the evening: Writing a JMX layer to allow apps written for ActiveMQ to migrate to WebSphere MQ with minimal modifications
Background
This came out of working on something that uses a JMS messaging provider. It uses it internally to allow components to communicate with each other, even when spread across multiple machines.
It uses Apache ActiveMQ – an open-sourced implementation of JMS. I wanted to try and get it working using WebSphere MQ – IBM’s implementation of JMS that I used to work on until five years ago.
As a messaging standard, the fact that both ActiveMQ and WebSphere MQ (WMQ) are JMS providers means that the way it puts and gets messages should just work.
But the JMS standard doesn’t cover administration (how queue managers are created and configured, how they’re started, how queues and topics are created, etc.) or monitoring (getting statistics about how many messages have been put or got, how many messages are on a queue, etc.)
All of this was done in an ActiveMQ-specific ways. This was what needed to be ported if I was going to get this to work with WebSphere MQ.
The project I’m porting is actually a bit of a black box. Rather than make a significant rewrite to get it to go from being ActiveMQ-specific to WMQ-specific, I wanted to see what I could add so that as much of the existing code could just work transparently.
I wanted to write a layer to sit between the ActiveMQ-app and WebSphere MQ, so that the app needn’t realise it’s not talking to the ActiveMQ broker it was written for.