One single PhD research project is by nature restricted to what can be accomplished in four years time. An important result of such a project is a set of new questions that can be used as ideas for further research, as detailed research always unearths further questions.
One target for additional research is the knowledge component. This thesis showed an attractive approach for improving the data and information handling capacity of BC. Some suggestions have been given on how this approach also makes BC a more knowledge-driven industry. There are however many opportunities for much more detailed research in this area.
Though keeping a constant eye on the needs and uses of Specifications, there hasn't been much attention to the inner details of a Specification. Possible attention areas include the knowledge-intensive links to regulations and laws which are probably worth a couple of years of research. How to handle the differences between the generic properties attached to bcoWeb objects and the probably partly different properties as preferred by the Specification. This thesis showed some technical possibilities for multiple Classifications per Specification: what are the organisational, juridical and practical possibilities or difficulties to bring this to practice and to perhaps take it somewhat further by having different Specifications for different kinds of projects?
Additionally, a Specification can be seen as a model that describes the transformation from design to materialisation for a given project. The traditional (paper based or electronic) Specification will be a representation of this future model, just like the 3D geometry or 2D geometry is a representation of an IFC model.
ISO 12006-2 is partially FU-based [87]. There was no time to investigate the possible connections with bcoWeb's GARM-like development. 12006-2 is quite formal and well-defined, so looking at both from a likewise well-defined OWL-viewpoint seems worthwhile.
Something that did not receive enough attention is the use of the subclass relation. Are catalog items subclasses or instances of bcoWeb TSs, for instance? For the prototype development, the subclass relation was used (which worked), but much more thought should go into this. Also the suitability of Ontologies for multiple viewpoints should receive more attention. Do you need multiple Ontologies or not?
In this thesis, bcoWeb was only filled with objects directly. There are, however, possibilities to mine catalogs and object trees automatically for data. Catalogs and object trees could have a local set of objects, which might be considered potential candidates for inclusion in the core bcoWeb. There is a lot of research to be done on this terrain. Perhaps revisiting neural networks and fuzzy logic is a worthy research target.
With an initial--and needed--focus on a national bcoWeb, there remains a desire for international cooperation, with many larger projects being international in nature and with many suppliers working internationally. Perhaps these international suppliers can be an important link in connecting various national bcoWebs. At the least, this is an area that can use further research.
Something that did not receive much attention in this thesis is the coupling between bcoWeb and geometry. Some work was done in eConstruct, demonstrating possibilities. This, too, is a worthwhile research target.
Web services themselves are also a potential research target. How can they be made acceptable? What are the limitations? Are certain areas more suited for web services than others? Can a strength calculation be reliably performed? What is the effect on financing and billing structures?
Reinout van Rees 2006-12-13