Kay didn't just invent classes. He also advocated the idea of message passing. Message passing is how data gets between one class and another class. Ideally, in Kay's world, you don't call a method with parameters so much as you pass a message with data to a class. Messaging provides an explicit place for state changes. It also provides a role for thinking about data and data structures as entities in their own right, aside from any implementation details.

You could argue that most software is concerned with managing data, but this is only true in the vaguest possible sense. Most software deals with business domain objects, and the use of raw data objects is not usually done between interfaces. This is a pity, because there are only really a few basic data structures of note: graphs, trees, lists, and maps. But it took decades to agree on the definitions of those structures.

One of the benefits of Java was that integers, doubles, reals and Strings were well defined. Even then, odd bits of double-point arithmetic, BigNums and signed bytes stuck out all over the place, which gives an indication of how tricksy defining the basics of data can be. The fact is that there are very few standardized way of dealing with complex data in Java. Using the Collections interface will give you half of the picture in terms of List and Maps, but the Collections API has no concept of trees and graphs, and may never do so.

Data is still a very large problem. Complex data structures are almost impossible to translate appropriately between disparate systems. The WS-I group have explicitly given up and recommended dealing with raw XML data in document literal terms rather than try to cope with different methods of access.

There has been headway. Interaction with databases has been standardized, but only to a very limited degree. Most applications will encapsulate data from a RecordSet as fast as they can, and justifiably so. Some business domain objects encompass data from a dozen different tables. Who wants to be tied to the underlying implementation? Considering the whole point of encapsulation is to prevent tight coupling to the implementation, it's no surprise that data is abstracted away to data (or domain) objects as soon as possible.

Except in Mozilla. Mozilla's central interface for dealing with data is RDF. RDF datasources can have any implementation they like behind them. However, they must provide the information through the nsIRDFDataSource interface that specifies a graph API of nodes and edges. Once this is done, any client can operate with the datasource without reference to the domain objects, methods, or underlying implementation. You just need to know how to manipulate a graph, and you're set.

This is the true potential of RDF. It's not a substitute for databases or XML. RDF is a directed labelled graph. It hides information and provides a data interface which can be used to aggregate multiple datasources that can be themselves RDF datasources. This is the purest data abstraction. Theoretically, if you weren't worried about performance you could access an RDF datasource and not know or care whether you're accessing a database, a web service, or both. The RDF datasource might even optimize its data structures based on what your queries or iteration patterns have been, in much the same way as hotspot compilation optimizes algorithms in the JVM.

A good question at this point is whether RDF is as powerful an API as JDBC. The answer is yes, or not quite. RDF is only a data structure, and there are several APIs for manipulating that data structure. The most well known implementation is Jena. Jena's API for manipulating RDF graphs is very powerful, and encompasses most things you would find in JDBC, such as transactions, a query language, and prepared statements.

I've heard the arguments about RDF serialization, and the use of RDF in web services. I'm not very interested, because I think that the XML serialization is the least interesting part. You can take RDF and serialize it as any format you want. If you're dealing with a well defined set of attributes, you can export it as XML and import as XML, and the data structure is just as valid as it ever was.