SM: Essentially, you are doing drag-and-drop query-building using graphics. Internally, that query is being translated into some sort of SQL which is processed and transferred back into graphics for the user. Is that a correct assessment?

CC: Yes that’s right. The language from which we are retrieving data could be anything. You can expose any declarative query interface. For example, MDX is another popular option. If you married a description of information graphics with a description of data queries into one formalism, you could then write applications which were fluidly graphic and thus generate queries fluidly. It is a unification of those two worlds into one that is the breakthrough.

SM: Don’t you need a translation layer to accomplish this?

CC: That’s a simple thing and we could write our own. Writing a procedure that retrieves data is a computer science 101 task. That layer can be anything.

SM: I’m not talking about the query interface, I’m talking about going between the query and the graphics interface. That’s your technology, right? Going from graphics to data and back?

CC: Yes but that has to be architected in a way that maps very well to relational algebra. If they didn’t write the formalism that easily compiled to popular query languages, then the task would have been easier. Most analytical applications rely on using their own proprietary data silo where they expose their own custom query interface. That is why virtually any analytical analysis application in the world requires you to import the data from the database into the analytical silo. That’s true of Excel, SAS, Business Objects, and every other one you can name. They are built on that model.

You have to get the data out of the database and into their fancy silo. They’ll never expose the query interface to people. They just build their captive UI to that. If we had architected that way ourselves, then the task would have been much easier. We have written the formalism very elegantly into the data query, which is part of the brilliance of what we have done.

SM: It’s an on-the-fly compiler?

CC: It’s an on-the-fly compiler of optimized data queries which databases can understand. It’s a greater burden than just writing a visual interface to any style you offer yourself.

SM: Was the Polaris technology already finished at Stanford?

CC: I think a fair description is that the landmark papers had been written, the formalism had been invented, and it was a research project. Our idea in 2003 was to spin that project out at Stanford and commercialize it.

SM: Describe what was going on in your head in 2003 when you decided to do that. Why that particular project? Why did the next phase of your life center on that technology?

CC: My first job out of college was a data analyst. If I did not have that job I would not have seen this opportunity. Most of the people we showed it to very early on did not get it. Everyone has seen information graphics before. When they saw it they only recognized it as something else that generated information graphics. It’s only if you had worked as an analyst that you could realize the bridge between where the data is stored and getting it into a useful form that can be manipulated and explored. That is the crucial task.