Cib 2004: friday’s w78 workshop (updated)¶

As the icing on the CIB conference's cake, some 25 people from w78 gathered on friday (and saturday) for an "extra" workshop. The format was to have 6 position papers, followed by discussion. Afterwards, three breakout sessions will help us to draft sort of a roadmap for the future.

update 2004-05-17: updated with the doc and the ppt from Vanier's talk (which he kindly send to me). Zipped here Tamer El-Diraby (Toronto): Opening talk

There are winds of change, which are an opportunity for us to take our research into action:

• Buildings versus infrastructure
• IT versus knowledge management. There is more interest in the more advanced technologies, going more from "plain" it to, for instance, the semantic web.
• Privatisation (some parts of the industry are now out of government hands and have more interest in new practices)
• Integration

The objective of this workshop is to draft a space map of the interactions between sustainable construction and e-construction research:

• Basic definitions and scope
• Gaps/opportunities
• Research and implementation agenda
• Execution models.

Ah, a space map. Well, there is a very well-known map: The Islands Of Information... We need to think beyond that, look a bit further. How will we handle grid computing, the semantic web, etc. Do we want a common ontology, for instance.

Dana Vanier: opportunities for integrated ICT in the management of sustainable municipal infrastructure (position paper)

Note: .doc and .ppt at the bottom of the page.

Municipal infrastructure: these are guys that have big problems, but also big amounts of money to solve it. It is related to current research of this group, the Municipal infrastructure investment planning project.

His idea is that municipal infrastructure can only be sustainable through the use of ICT for data integration. "Sustainable construction" is development that meets the need of the present without compromising the capability of future generations of doing the same.

One of the problems is the bid structure, which goes straight for lowest costs, which normally isn't that sustainable. Another problem is that there are no workflow processes in municipalities that favour integration. The road people don't talk to the school people. The traffic planners don't talk to the road engineers.

A interesting statistic is the confidence level of the maintainers in their data. If you ask them how much km of road they own, they'll answer confidently. Ask them how much it's worth, they start to get less confident. Ask them the expected lifetime of a certain road, they'll squirm and won't really know the answer. What is needed for this is some sort of integrated ICT-based system.

He thinks that the time is ripe for ICT opportunities for municipal infrastructure.

• Computers are mature
• Support applications are in place
• Databases are robust
• The internet is ubiquitous
• Trained personell is available
• Large portion of municipalities (at least in the USA and Canada) are using GIS (Geographic information systems).

What he thinks is needed as research developments:

• 3D capability that meets municipal engineering needs
• Time dimension to store differences in time (roads being build, maintenance that is planned)
• Object orientated relationships between the objects in the GIS database

One of the standards he looked at that looked most promissing is SDSFIE from the US army corps of engineers, which is open source.

Robert Amor: facilitator of the discussion

A nice comparison that Robert made was with the aircraft industry. For every aircraft, especially the commercial jetliners, you can get a complete listing of all the parts, the list of refitted parts (when, serviced by who, procured from which firm), service being done, etc. Down to the individual components.

Comment by me: they invented SGML (XML's predecessor) to handle the aircraft information. So you should really be looking at open, future-proof readable formats to store your data in and be careful of using binary data (like perhaps binary GIS data).

The aircraft industry is one end of the scale, a car owner with just a box of some maintenance bills somewhere is the other end. Where do you rate the municipal maintenance? Dana: at the bottom end. Sometimes they store some data, but then they stop such a project for ten years. So it's terribly spotty and not-organised.

Jay Yang (and Martin Betts), Queensland university of technology: the significance and priorities in sustainable development (position paper)

Jay is coordinator of CIB task group 55 "smart and sustainable built environments".

Good talk, but way too fast to write much down, so you should really read the paper for this one.

Priorities of IT in sustainable construction development:

• IT as a simulation and modelling tool
• IT as a scoping and benchmarking tool
• IT as a communication tool
• IT as an integration tool

The way forward:

• Create a IT vision for sustainable construction
• Identify and develop new operational platforms more suited to dealing with sustainable construction
• An international alliance of researches is needed to avoid back pedalling due to regional diversity.

Claude Bédard: discussion facilitator

Lessons learned: there are a lot of initiatives by a lot of people, but we still miss the big, coherent chunk. Also missing is the integration.

"Sustainability" is a big subject, from which end do we want to grab hold of it?

Question: From the isolated initiatives, how can we move forward from that. Jay: we must engage more people. There are also more areas that need to be identified as possible targets for ICT help.

Robert Amor: it's all going so slow, IFC took some 5 years to get a partial model. And your last slide shows "act quickly in response to the challenges". Answer: well, we can chose not do act now, but then there'll still be nothing in 10 years. If we start to do something now we at least have something by then.

Martin Betts: our technology is being accepted in industry if it is needed, not on the basis of it being good technology. Now, sustainability is starting to become an important political issue, so there is (or will be) a real need, speeding up adoption.

Jay: we can't just wait with this. We have to pick up what we've got and get moving.

Intermezzo on sustainability (based on Bo Wang)

Sustainability:

• Natural environment sustainability
• Social sustainability
• Economic sustainability

Breakout session 1

Link IT - sustainability. Priorities from the one to the other.

Ouch, that was a difficult subject. Basic results: sustainability is broad subject. The broad thing w78 can to with regard to sustainability is a focus on integration. Integration sounds a bit threathening, centralising (at least to me) so I suggested calling it "making information available". And therefore integratable :-)

I made the (probably heretical) comment that "sustainability" is a very broad term. And just like you can normally submit a paper to a conference irrespective of the theme, likewise you can put almost all IT offerings under this theme...

Raimar Scherer: Management of the multi-dimensional information space (invited paper)

4D CAD ideas focused on adding the time dimension to 3D CAD info. But, different dimensions can also be handled as "views". Views on a sort of "data warehouse".

• Functional view
• Production view
• Financial view
• Organisational view
• Information logistics view

Raimar thinks integration is not possible, but interoperability is. Integration is centralising everything in one big model, which you'll never pull off. Making different views interoperable, sharing information, is doable.

Important: personalisation. Everybody should/could have a personalised view on the information. Possible contexts to take into account for personalisation are user profile, available hardware, location, job function, etc.

Data warehousing isn't good for dealing with changing information. And the building industry has strongly changing information, especially in time.

Some requirements of an nD info system

• One of a kind project support.
• Most domain views represent systems.
• An actor view is a typical context view.
• Highly asynchronous collaborative working with very long transactions. (The architect works a bit on something, then the engineer calculates on it and a week later the architect looks at it again).
• Highly dynamic, evolving and accumulating information.

A problem that needs to be solved is consistency. For instance when exchanging information from one CAD package to another using IFC, a test showed that you lost 95% of the IDs.

Thomas Froese - facilitated discussion

Ziga Turk complained about the use of the buzzword "nD" for this "normal" research. Raimar agreed, he only used the term because it was on the workshop's list of possible subjects :-)

Report on first breakout sessions

We seem to almost think that "sustainability" is something that wants to be noticed and that we are builders, makers, who have something to offer.

The industry needs something, we can provide something. Industry pull, technology push. But we normally think of our stuff in the terms of "tools". We make tools that are supposed to be nice solutions to problems of the industry. However, we should focus more on frameworks and models to integrate our story, to integrate our offerings, to ensure we fulfill real industry needs.

John Haymaker: tools to signal c2c design intention

Formalising the existence and nature of dependencies.

• Define task specific representations (perspectives)
• Define the existence status and nature of the dependency between these representations (perspectors)
• Compose perspectives and perspectors into "narratives"
• Control the integration of narratives

Hugues Rivard: facilitated discussion

C2C acronym from the article: cradle to cradle. From the beginning, the cradle, all the way to the offspring, the next cradle. Take the entire lifespan into account.

Lessons learned

Perspectors offer an innovative way to support views of 3D models generated from small computation units.

What about other types of data? Can the perspectors approach be expanded to support this? Answer: that's what he's asking himself at the moment, too.

Comment by Robert Amor: there are multiple geometric models. You need a different model for different usages. So there'll not be one single simple model.

Ziga Turk: migration risks of construction informatics research

There is a gap between research and adoption by the industry. We can blame ourselves or we can blame the industry. But the ICCI project looked at the possible friction on the way from the one to the other.

• Direct knowledge transfer
• Through standardisation
• Through software implementations
• Through education

To find out the friction on these paths, they surveyed several EU project participants and some collegues.

There's a normal order of business

• Emerging technologies
• Research into the technology
• demonstrator in controlled environment
• development/transfer
• deployment/take-up
• proven/tested

EU projects spend about the same amount of time on research as they spend on EU paperwork, writing of EU documents and project management.

A lot of time was spend making prototypes. Also prototypes do not scale up. Ehrm, that's a problem! So we should make sure that we have good success/failure criteria for prototypes and we should make sure that our prototypes do scale up.

Reinout van Rees (me): facilitated discussion

Answers are provided by Ziga.

Lessons learned from the paper

There are four ways in which research knowledge ends up in industry

• Direct transfer (scientists that start working in industry for example)
• Standardisation
• Software development
• Education

Question: on the role of standardisation, there are a lot of competing standards, we seem to standardise in order to achieve our own ends instead of standardising what has proven to work. Answer: there are a lot of standard-because-we-hope-they-accept-it.

Further lessons:

• Results from the survey, industry against research, shows that the industry is less negative about the research results and process than the researchers themselves. Only the software demonstrators are a bit of a problem.
• Big differences in survey results are shown between the EU-funded projects and the non-funded or national projects/companies. The latter complain about lack of funding (duh...), no stakeholder involvement, no clear business case or return on investment, and software demonstrators that do not scale.

Question: national and unfunded, that sounds like software developers. I mean, Autodesk etc. are international companies, but the majority of the developers are small, local companies. Software that doesn't get build seems to be the biggest problem, does this result indicate a reason for this? Answer: well, those national or unfunded parties weren't software developers, so this doesn't really apply. (RR: though they may fit the results well)

Benchmarking, input from other fields

From "the diffusion of innovation" (Rogers, 1980) which, I was assured, was the authority on this field, I collected the five characteristics that help to explain the speed of adoption.

• Relative advantage: how much of an improvement is it over a previous technology?
• Compatibility: is the innovation compatible with existing practices or beliefs or business structures in the industry? For instance, the adoption of 2D CAD packages (drawing lines) wasn't too much of a shock for line-drawing paper-and-pencil professionals. 3D object oriented CAD packages mean a big shift in paradigm, explaining the slow adoption.
• Complexity. This means the perceived complexity. If something looks nice and easy, it helps.
• Triability. Trying a new kind of application on a small project is something different from having to re-structure the company because you just brought in SAP or BAAN to manage all information...
• Observability. Behind-the-scenes excellence doesn't help in the adoption!

Also some predictors for success or failure from the Canadian Tim Bray. He has made a technology predictor success matrix. Good predictors of success or failure are:

• 80/20. If an initial implementation is nice and small, bordering on the "too small", but delivers a lot of functionality, then it has a good chance. The limited set of classes of IFC seems to be good in this respect. (The overall technology seems to be a bit complex, but I haven't looked at it too closely). This is, according to Tim, the best predictor.
• Happy programmers. If you have to force a programmer to work on a certain technology... If he works on it for fun in his free time...
• Good initial implementations. Not a sure-fire predictor, though. But if the program sucks bad in the first implementation... The memory tends to stick.
• Technical elegance. If the design is just right... If it is one big ugly hack...

Question: if software is a major bottleneck, how does our software rate against these criteria? Answer: Looking at Rogers' criteria: bad, bad score, could be good as measurement for our prototypes.

Research needs: what needs to be done?

According to the paper, info exchange between EU projects is OK, to outside it's not. Some suggestions from the paper:

• Greater contribution to education
• Less writing of reports
• Broader dissimination
• Broader availability of results
• Validation of the prototypes

Question: dissimination or diffusion? Rogers calls dissimination the focused one-way-direction sending of information. Diffusion in his vocabulary is the spreading of the information, partly focused, partly "just by itself". Is diffusion a better model than dissimination? Answer: The term doesn't really matter, but we should be much more present on trade shows and for software companies.

Implementation: how to do it, collaborative research and development

• Education: EU example, collaborative curriculum
• Standards: less (competing) standards, social pressure to cooperate?
• Software: Collaboration, sounds like open source?
• Good examples and software documentation
• Eating our own dogfood: using results from other researchers
• Communication: openness, visibility
• W78 mailinglist, news site/weblog: provide better info about what we're all doing?

Question: any comments on this? Answer: open source: not the parts that ar 50% funded by commercial software companies. The parts mostly funded by public funds: YES.

Anders Ekholm: ISO 12006-2 and IFC - could they be harmonised?

ISO 12006-2 and IFC are candidates for ontologies. ISO 12006-2 is a framework for classification, IFC aims for interoperability.

Two main divergent issues:

• The use of classification
• Main classes of relevance

The ontology for the AEC/FM sector must be common to the worlds of classification and product modelling.

A Swedish test of IFC confirmed the validity of the idea of a neutral format for object exchange. But it also showed the need for reformulation of IFC to accommodate the classification need.

In order to enable and to speed up the process towards interoperability, there is an urgent need to harmonise ISO 12006-2 and IFC.

Classification systems are cornerstones in ontologies, as they summarise and organise existing knowledge. Objective of FST (short for ISO 12006-2) is to harmonise national and regional classification systems. Based on the Swedish SfB system.

It is applied to the BSAB96 (Swedish specification system), Uniclass (UK) and OCCS (USA).

An important characteristic of FST is that it has views. A functional-or-user view ("the element view") and a form view.

IFC classes are not based on a specific model. IFC as a whole isn't grounded by a specific theory. (A lot of this is spelled out much clearer in the paper).

In practice, IFC has developed its own classification system which is, sadly, incompatible with the FST.

Some discussion-initiation

"Building classification is out of date, aa new object oriented approach is needed!"

Classification as shown is OO, 50 years of industry practice cannot be ignored, information systems must support industry needs.

I want his sheets

Jeff Rankin: facilitated discussion

Anders agrees that object-property-relationship is the way to build a product model. What he disagrees on with respect to IFC is the rejection of classification as a base.

Jeff was feeling a bit treathened by the attack on IFC, but he got the impression that the analysis of Anders was validated by some other comments earlier in the day.

"How do you suspecct that a focus on e-business will affect the development of an industry ontology?"

"Did both efforts not have their roots in complimentary ISO efforts?" There wasn't a huge overlap in the development teams. And at least not a lot of communication.

Question asked: Harmonisation IFC and 12006-3, CROW was busy with that but stopped due to lack of funding, it was taken over by Kees Woestenenk. Any additional information? Answer by Anders: 12006-3 is separate from 12006-2. The group around Kees Woestenenk went into a different direction. It is a well-known fact that they did not agree with the 12006-2 direction and way of looking at the world. So the 12006-3/IFC work does not help in harmonising IFC with classifications (or at least not the 12006-2 kind, RR).

Mark Fox: lessons learned from the manufacturing industry

He has an ecommerce company. They handle the website for an online flower company and this is a few days before mothers' day... They have some 5 transactions per second at the moment, so he's not venturing far from his company's front door at the moment.

He's going to start out with a few stories.

Story number 1: Westinghouse turbine blades factory scheduling

Question to the managers: "what are the 10 questions you ask yourself every day that you don't get answers to?". The top thing was that they didn't know what was going on at the workfloor.

He tried looking at the factory workflow with operations research. But the mathematics didn't help him. Why? Because scheduling didn't really work the "normal" way. Everybody talked to eachother as there were many variables. somebody's sick, the maintenance status of a certain machine, etc.

At that moment he found out that it wasn't a simple mathematic problem. One local change propagated throughout the whole system. Pull a string here, a machine goes down at the other end. So you had to juggle a lot of things, trying to find a solution that upset the fewest possible persons, satisfied the most important constraints and ignored the lesser constraints.

This changed how people looked at scheduling.

Story 2: Digital

The manager claimed that everything was monitored and steered with computers. He told them that the schedule managers spend 2 or 3 hours a week on the schedule planning. When they asked the schedule managers' boss, he told them that they all ran around like chickens with their heads cut off.

The problem: the computer system couldn't see or represent certain information, so people and goods tended to disappear in black holes as far as the system was concerned.

Story 3: General electric jet engine plant

When asked to research how the design process worked, they found out two ways of designing:

• Design in the large. Lot of people, lot of locations.
• Design in the small.

Creativity represents only a small part of the design, most was satisfying of constraints (just like scheduling...). The problem was to find a design that satisfied the most important constraints, ignore the lesser ones, from all the myriad possibilities.

There is a need of a fundamental skeletal representation to which everything else gets attached.

Story 4: Spar (robot arm of the space shuttle, for instance)

He had a student do a bit of research on the time spend by engineers: most of the time, engineers were looking for information instead of designing...

In the end they lost a few millions of dollars because they used last year's parts book instead of the current one. Information.

Lessons learned: standards and ontologies

We should be careful of thinking we're far down the road and almost ready for standardisation. STEP is still going. Standardisation is slow and it is just getting slower. Because of XML. Now everybody is capable of publishing their schema as a standard. There are LOTS of standards.

Ontologies, to him, is more than object, properties, relations. To him it is a commitment to the semantics in the ontology.

There is a problem with ontology. There is no concept of competency. Nobody tells what his ontology is good for. So mention a set of questions that the ontology should be capable of answering.

People mistake ontologies as central storage models for data instead of something that you communicate (with). You may hope that your ontology will be used for communicating data. Don't expect everybody to change their numerous databases!

Lessons learned: reasoning

Reasoning: look at the constraints. If you flag transgressions of constraints you get already 80% of the benefits. Constraints-based reasoning goes much further, though.

Lessons learned: go back to basics

Go back to basics. what is the basic representation. What is the skeleton. What are the constraints.

If the basics are not there, everything else is not supportable.

Final story: Spar again

Someone demonstrated a central information system. He didn't like it. You had to click three times when one click would be sufficient. He walked away in disgust. Irrespective whether the system itself performs perfectly.

So look at your users!!!

Questions

"What's your thought on a skeleton model?" Well, I don't know if anybody solved that problem already, finding a high-level abstraction.

"Systems theory?" That's something that caresses the technical part of our brain that loves complete, all-encompassing systems. But he hasn't seen it working yet in a good way.

Representations are automatically abstractions. So you're not capturing everything. So when dealing with ontologies, you must take into account you're going to be missing things.

The semantic web to him is a wide-spread adoption of what was going on in the 60's, mainly in A.I. The first web-like system that he built was a library interface in 1977. Hypermedia. So to him, the www was a making-available of hypertext for a large public. It made computers much easier for people.

The semantic web is the re-affirmation that text is not enough. And it is not xml, but owl that does it. It provides semantics. But we still face a morass, not in the least because everybody can make an ontology...

The next day we had a nice trip to the Niagara Falls. Here's a photo (I cannot find the original page where I found it anymore, so I've put it online here (before I lose it on my harddisk)).