RDF and other monkey wrenches
By Sean Mc Grath
Somebody, I think it was Adam Bosworth of BEA, once said that every layer of abstraction costs you 50% of your audience. Or words to that effect.
Let's do the math. You are presenting on the subject of a new business IT architecture to an audience of 100 people. You start with people and business processes at the bottom of your diagram. You add layers of abstraction on top so that everything fits neatly into some nice three letter acronym-emblazoned box at the top. Let's call the top level box XYZ for the sake of argument. The XYZ acronym becomes a strategy buzzword of the enterprise. All new systems have to be XYZ-enabled or XYZ compliant. Board members start to talk about XYZ as a vision. A group is established to care and feed XYZ and get the all important mouse mats printed.
Let's say there are five layers of abstraction in the architecture. If every layer costs you 50% of the initial audience of 100 people, by the time you reach the last one, only four people in the room have one iota of what you are talking about.
It's the same over in the IT department by the way, where the technical underpinnings of the XYZ corporate vision are spelled out. The IT architect takes the podium on front of an audience of 100 IT people. She explains how the chosen J2EE patterns are implemented in terms of XML interfaces conforming to the chosen e-commerce meta-model in which all meta-data conforms to an ontology managed as a set of RDF triples.
By the time you hit the RDF triples (working from the top down), all but four people in the room are tidying the hard disks of their laptops or updating their blogs.
Sobering stuff. Abstraction extracts such a terrible price in return for the benefits of complexity management it bestows on the chosen few. Abstraction creates a high priest environment in which only a few can ever hope to really understand the "vision" buried in all the abstraction. In the hands of the chosen few, the abstractions are a precision tool wielded to powerful effect. In the hands of the other 94%, the tool is more like a monkey wrench. A tool that can be used for every job but is the *wrong* tool for every job.
I fear that RDF - the uber-abstraction that underlies the Semantic Web - is one such monkey wrench. Given the undoubted benefits to all of us, if Tim Berners Lee's vision of the Semantic Web becomes a reality, how can we make the abstractions it depends on, usable by the 94% of the world's system developers? The population for whom the abstractions are a step too far for them to comfortably follow?
I think the answer lies in what I call semantic shadows. Let's say I am working with XML and want to have customers and products in my data model. I want to think in terms of plain vanilla customer tags and product tags - stuff specific to my problem. I don't want to have to think in a more abstract model than necessary to get my job done. At this point 94% of the IT people are happy. To keep the other 6% happy, we get them to create an up-translation from the domain-specific model of customers and products into whatever ontology is required for the purposes of the Semantic Web vision. Generate the semantic shadow files from the domain specific files. That way, we can have chocolate on both sides.
I think it's time for the Semantic Web proponents to stop trying to teach us all to think at their level of abstraction. We can't (or won't). Instead, the Semantic Web proponents should look at mapping transparently from the RSS 0.91, XFML 1.0 specifications that 94% of us are happy with, into the more abstract, generalized models that the other 6% need, for the applications they are all dying to take advantage of.
In RSS in particular, we have seen how attempting to make the more abstract model a core part of the specification (in RSS 1.0) has led to significant unrest among the natives. There is a lesson there to be learned.
The route to the Semantic Web lies in letting a thousand flowers bloom, not forcing us all to instantiate multicellular organisms based on a gene pool ontology.