Can you describe what Antarctica is doing and how XML fits in?
The premise of Antarctica is that enterprises are typically really good at collecting information, but Wall Street doesn't reward you for collecting information. Many people in chief information officer and chief technology officer roles would share the perception that the enterprise world in general is not doing a good enough job in getting value out of the large inventory of information that's built up.
So I became interested in mining -- getting more value out of all this data that's built up. I concluded that one of the main pain points that's preventing people from getting adequate return on investment from data inventories is the user interface. There's an analogy with the advent of the graphical user interface for PCs. Before that, computers were something of a very small minority of the population. Once everybody got a GUI (graphical user iterface) with a desktop metaphor, the use of the computer became much more widespread.
It's Antarctica's hypothesis that by putting a graphic interface somewhat in the spirit of the desktop metaphor on complex information spaces, we can open up the value in there. In our case, the metaphor isn't a desktop -- it's a map.
On the XML front, we're using it on the periphery. Our back end consists of either an SQL database you can talk to directly, or send us an XML input file and we'll read that. Interestingly, in our actual deployments, there's been only one case in which somebody's elected to talk to the database. Everyone else has been happy with XML.
There's a lot of business interest in search now. Do you think companies would be better off focusing on user interface issues than algorithms?
Absolutely. There's no reason to expect that search is going to get that much better.
The basic algorithms by which search is done have not improved much since about 1975. The only way to improve the situation is by enhancing search engines with more deterministic metadata, essentially adding knowledge management techniques that give you more information from which to draw connections. If you look at the victory of Google in the search engine business, it wasn't because they had better search techniques. It's because they deployed one key metadata value -- how many pages are linked to this one -- to enhance the relevancy of their results. The same concepts need to be applied to the enterprise.
There are really two ways to get information: search and browse. And browse has a lot of potential. But to work, the drill down has to be intuitive. It cannot be stupid. You have to be really aggressive about bringing the relevant stuff to the top. You can't force the person to go through multiple levels to get to what they want.
And visual representation plays a big role in that?
Right. It turns out that the display technique that returns the most amount of data per square inch is cartography. That's why we're using a map metaphor. The whole notion of the search engine results list, for which I'm partly responsible, is terribly information-thin. Google creates the illusion that the results list is somewhat one-dimensional: this is the most interesting; this is less so.
But if I type "bicycle" into Google, it doesn't know what I'm looking for. I may be looking for bicycle racing results, or I may be interested in that song by Queen. With a map, I get started off right away: Here are the matches for bicycle in music; here are the matches for outdoor sports; here are the ones for shopping.
You've been a major contributor to the W3C. What's your view of the standards process? It seems that in some cases, like XML, it works very well, but there are others like SVG (Scalable Vector Graphics) where it's been quite slow.
Standards processes don't do well in dealing with new technologies, so I disagree that being ahead of the market is a good thing. The standards process works best when you've got a problem that's already been solved, and we have a consensus on what the right way to go is, and you just need to write down the rules.
That's totally what XML was. There had been 15 years of SGML, so there was a really good set of knowledge as to how markup and text should work. And the Web had been around for five years, so we knew how URLs (Uniform Resource Locators) worked, and Unicode had been around, so we knew how to do internationalisation. XML just took those solved problems, packaged them up neatly and got consensus on it all.
SVG is a different thing. I haven't given up on SVG; I think it has a bright future, because it really is better than the alternatives. And they didn't invent much stuff. People from Adobe and Microsoft know this stuff.
XML probably couldn't be done anymore at W3C. The reason XML was so successful is that nobody noticed -- we came in low, fast and under the radar, and it was already finished by the time the big vendors noticed it. Now, any time there's a new initiative around XML, there are instantly 75 vendors who want to go on the working group.
