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
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
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
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
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.