SEMANTICS: THE NEXT FRONTIER IN SYSTEMS AND DATABASES

by Ken Orr, Fellow, Cutter Business Technology Council

IT needs a breakthrough. With the increasing complexity of our hardware and software technologies and the increasing demands of our application systems, we desperately need "smarter" systems. For 30 or 40 years now, we have built systems around a number of primitive concepts about data and the meaning of data. In the 1960s, we built systems around "data files" containing various organized sets of "data fields." In the 1970s, we moved to talking about "databases" containing organized sets of "data elements." Since the 1990s, we have been building almost all of our significant business systems using "databases" made up of simple "tables" composed of "attributes."

Despite talk about an object database revolution, nearly all of our current databases are built around RDBMSs. The good news is that these databases are reliable, efficient, and easy to deal with. Moreover, because of the simplicity of the relational algebra pioneered by Ted Codd, Chris Date, and their colleagues back in the 1970s, it is possible to mix and match data from multiple databases in the same application.

But the real world, a world populated with very intelligent human beings, wants application systems that are much more sophisticated. Much of the current database technology, which includes database organization along with updating and querying protocols, is primitive; it depends heavily upon complex naming and programming conventions that, despite our best efforts, fail to get at the heart of many problems.

Let me give you a couple of examples. Over the years, I have worked with a variety of large and small organizations. I have found that they are frustrated repeatedly in trying to deal with some of their most basic problems. Statements like "This company is so screwed up, it doesn't even have a simple definition of customer!" or "We probably have a dozen definitions of product around here!" are common.

If you examine these situations, you learn that they are symptomatic of deeper problems. For example, the most common reason it is so difficult to define "product" is that the company sells multiple kinds of products that are often quite different from one another. Because the company has different classes of products, it also sells to different sets (classes) of customers. Conceptually, we have a hard time understanding the problem; operationally, we have even more difficulty putting this information into our solutions and giving customers even primitive tools to use to take advantage of this information.

Object and data modelers are good at modeling "subtypes"; I'm not arguing that point. But programmers and users hardly ever use the concept of subtyping. For most programmers fussing with subtypes, even normalizing is a nuisance. They want to make things easy on themselves and they don't care about the larger systems environment. And users don't understand what they don't understand.

There is a great deal of talk about a Semantic Web, but my work suggests that the current work is not much of an advance. Mostly, it doesn't deal with the principal semantic problem -- linguistic context. We need methods and tools that keep track of the context of the discussion and recognize what kind of customer we're talking about; and if the system doesn't know, it needs to ask. As I do enterprise data models, I face this problem more and more.

If I had to guess, I would bet that future solutions will leverage on ideas like "conceptual graphs." My friend and fellow Cutter Senior Consultant Arun Majumdar has been working with one of the leading figures in the conceptual graph world, John Sowa, and they have been making important discoveries. But there is still a long way to go before we can create "semantic" databases.

But there's no doubt about it: semantics is the next great frontier in computer systems. Like the sound barrier in the 1940s, we must get past semantics to get to the next level.

-- Ken Orr, Fellow, Cutter Business Technology Council