Volgende: Conclusions Omhoog: Analysis of current information Vorige: PDT: information structuring Inhoudsopgave
This section takes the analysis of the previous two sections and evaluates the suitability for improving information sharing. Any shortcomings are translated into research opportunities.
The Classification and Specification efforts are widely accepted in the market. Their market adoption is an indicator that having a simple structure greatly helps market adoption.
Except purely textual, there are no links to other information sources. You can refer textually to `the doors on the fifth floor' in a Specification, but you cannot link directly to an item in a drawing. This largely prohibits information sharing in any non-textual way. Likewise, information contained in a Specification or Classification cannot be used by other applications, as--apart from numbered chapter headings--no computer-identifiable information is available.
From all PDT efforts discussed above, only IFC was adopted by the market. Mostly because it was started by CAD software vendors, which therefore implemented it in their products. The use of IFC in the market is, however, low. One reason is that only the more elaborate CAD packages include IFC capabilities and that not everybody uses the total functionality offered. A second reason is that only a small portion of the BC companies use the elaborate project databases needed to get the most out of IFC.
One reason the progress is slow is because of committee-based standard development; a new standard is developed in a committee, instead of standardising existing best practices. STEP showed that this does not work well for BC. IFC is a bit better in this regard. The amount and diversity of objects in BC makes it probably unworkable to define those objects inside a formal standardisation process as part of the rest of the model. IFC discovered this and is looking at ways to keep the object definitions (the Semantics) external.
The 12006-3 development provides a way to make object libraries. The idea to store object definitions in a separate object library is probably good. 12006-3, however, has some weaknesses that limit its use for improving information sharing in BC. There is no way to link two object libraries, which means that object definitions have to be concentrated in, preferably, one single object library. As the most important object structuring mechanism is inheritance, a huge tree structure is the result, in which all the various objects have to fit. Also, there is no exploitation follow-up: no data format or application that uses the object library's definitions, so no feedback from real data and no demonstratable use. This has, for example, prompted CROW to take a more pragmatic approach and stop with the top-down tree structure that was permanently in state of revision and that could not show its effectiveness.
As a last point, we can conclude that extensibility is good. IFC can be extended and therefore allowed itself to see experimental use for road construction, an area not originally intended.
In addition to the functionality offered by the technologies discussed in this chapter, further advancements are needed for improved information sharing in BC.