Something to think about: No one likes to change. But if we continue to solve the same problems (in slightly different contexts) we will be replaces by others who view the problem differently. As said by Jim Waldo in Thoughts on Change at 35,000 feet
Jim talks about "ubiquitous computing", but I'd like to extend his point to the building industry IT research. Ok, what could be some of the problems we continuously try to solve?
A suggestion? We want to centralise and order information. We made library classification systems (SfB) and extended them to include all project info. We made CAD layering standards and expected them to be used for everything. We made product models (STEP, IFC) to make the information more structured (good), but it turns out to be one, huge system (bad). We expect all project info to be stored in one IFC database. XML came along and we used it to make an XML export of the big central IFC database. Or to make a big, single, end-all taxonomy. No doubt the semantic web will be misunderstood to centralise a bit more or to make existing rigid orderings a bit more open.
Viewing it differently: how? Which shoulder should we look over in order to see the oncoming freight train that's going to run us over? I suggest the internet and the semantic web. But beware of mistaking the real internet for the marketing one. Web services, for instance, are are really helpful for doing the same old thing with a bit of a web sauce on top. Just call an API of some centralised database or so. Don't do that!
Take the "ordering" paradigm with a bucket of salt and look at decentralising instead of centralising. The semantic part of the semantic web allows a lot of decentralised ontology definition; you can weave together multiple smaller ontologies. This also means you don't really need one big agreed-upon widely-deployed classification or ontology: if some ontology for a very specific field is handy, it will get used. The rest is a management/coordination problem, similar to that of a linux distribution: many sources that need to be coordinated. You can make tools to help you. But trust in the basic correctness of a distributed approach.
I would love to be a co-creator of such a system. It is the kind of system I like, also philosophically. Co-creator? Not a very good choice of words, perhaps. I'd like to build tools (open source) for it, open my mouth for it, use it, support it.
Now only finding a job that includes doing this (somewhere around the end of 2004 would be fine!). Or creating a job that means doing this. There is a lot of money in finally cracking the building industry's basic information problem...
What about the 35,000 feet part in the original article? Well: the fun of flying. Which is just the sort of thing that is happening to the airline companies like the one that I'm currently using. They haven't really changed the way they do business for a long time, so the really cheap carriers are undercutting them, and the luxury carriers are siphoning off the specialized runs that are less price sensitive. The ones who can't change make some minor alterations that only irritate their clients, find themselves bankrupt, and try to keep flying anyway. If you don't change, you may find that you are no longer able to survive. I haven't had any unpleasant experience while flying, only some minor disadvantages inherent to flying for a long time (24h Schiphol - New Zealand for example). But then, I don't do it often, so to me it's still fun :-) It helps that KLM is a good airline.
My name is Reinout van Rees and I program in Python, I live in the Netherlands, I cycle recumbent bikes and I have a model railway.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):