Compared to other large industries, the building industry is highly fragmented, with most projects undertaken by temporary, project-based organizations consisting of many small firms and individuals. The client entity may consist of a variety of stakeholders within a company, perhaps including a building committee, groups of end-users and facilities management personnel. The design team may be led by an architect, but will almost certainly include subconsultants such as structural, civil and mechanical engineers, landscape architects, lighting designers and many others. And the general contracting or construction management company will use numerous subcontractors and material suppliers in building the work. Communication and the exchange of data between these firms is crucial to the success of any project.

In many ways, information technology has make communication within this extended enterprise worse rather than better. Incompatible systems used by individual disciplines create artificial barriers that hadn’t existed before. Within the separate domains of design, construction, and operations of buildings, computer tools have been applied to automating specific tasks rather than addressing the overall building process. For example, the design team may use computer-aid design to produce the drawings and other documentation required for bidding and construction, but these digital work products are not necessarily useful for the tasks performed by the contractor: costing and scheduling. To make matters worse, the proprietary file formats used by most CAD programs can’t be read by project management software.

As a result, much exchange of information is still reduced to paper, even when the work is produced on a computer. The floor area of a building, for example, which the architect’s CAD program can easily calculate, will often be recalculated and reentered by an estimator simply because the CAD program can’t easily exchange data with the estimating program. Similarly, the contractors software can often not easily exchange data with tools for energy analysis or facility management, so much additional time and effort is needlessly expended in reentering data into new systems. Whenever these information handoffs occur, the opportunity for delay and error is great. The building process would be much better served if the entire chain of information from design to construction to operations could remain in one seamless digital format.

Data Exchange with XML and the Semantic Web

Hypertext Markup Language or HTML is the underlying technology of the World Wide Web. Embedded instructions in HTML tell Web browsers how to display text and graphic information and make links to other Web pages. It doesn’t tell the Web browser about the content of the information being displayed. As a result, searching the Web is difficult, because Web pages written in HTML do not describe themselves. A new Web language, Extensible Markup Language, or XML will make searching for specific content much easier, with wide-ranging implications for business-to-business communication such as occurs in every building project.

While HTML describes how data should be presented, XML describes the data itself. A number of industries and scientific disciplines—medical records and newspaper publishing among them—are already using XML to exchange information across platforms and applications. XML can be tailored to describe virtually any kind of information in a form that the recipient of the information can use in a variety of ways. It is specifically designed to support information exchange between systems that use fundamentally different forms of data representation, as for example between CAD and scheduling applications.

The success of XML to enable the kind of open information sharing that is needed to integrate the building process hinges on finding away to standardize AEC terminology. For any language to function, there must be agreement on the precise meaning of terms. Semantic integrity means that words used should mean the same to the sender as they do to the receiver. Traditional means of achieving this aim with human languages have included dictionaries and glossaries. If computers are to exchange information with each other without active human intervention, however, a much higher degree of precision is needed. At present, different players within the AEC industry use the same term in somewhat different ways. For example, a door can be, depending on context: (1) an opening in a wall; (2) an assembly consisting of a frame, a leaf, and hardware; (3) a scheduling item; (4) a cost item; (5) a product to be manufactured and delivered; or (6) a building asset to be tracked and managed. An industry-specific implementation of XML will need to be precise enough to clarify these different usages and be flexible enough to grow over time.

Part of the Green Building XML Schema, developed to easily transfer building information stored in CAD models for use in energy analysis software. http://www.gbxml.org/

If XML is widely adopted, it will enable data sharing and electronic commerce in the building industry on a scale not previously imagined. When XML is used to write project specifications, for example, a contractor will be able to extract both quantitative and qualitative data and match it with information from manufacturers’ and subcontractors’ Web sites. A manufacturer will be able to scan a set of contract documents and match specified items with items in its own catalog, take an order, and move it into production and delivery. Once that product arrives at a job site, carrying the same XML code written by the original specifier, a construction worker using a scanner and handheld computer will enter it into the master schedule for the project. XML tags can identify every attribute of products and building components, from bending strength to reflectivity. In fact, XML could be used to describe virtually all the objects, documents, services, and organizations needed to complete a project. Because data about these attributes is divorced from the program used to create it, information is no longer imprisoned by file types and software incompatibility.

The implications for Web-based operation manuals, equipment schedules, and the like are enormous—a maintenance engineer, for example, could easily extract only the specific information needed to service a building component from a mass of data that would otherwise be overwhelmingly complex. One application of XML will allow users to access different aspects of a single database and display them in a customized way. For example, in a shared project database, an architect’s Web browser might be configured to display only geometric data, that is, the physical form of a design. The contractor’s Web browser might display only information about schedules and costs, using exactly the same set of data stored on the same remote server. The architect and contractor would be able to work with the information using Java applets downloaded as needed by their browsers. The architect would not need to have CAD software on her laptop while accessing the database from her hotel room, because all of the functionality needed to work with the model would be supplied by the applet itself. With XML and object-oriented CAD, entire sets of construction documents could be prepared in the form of live Web sites rather than a collection of static documents. The project file is now completely divorced from any paper representation of it; an unlimited variety of context-based views of the same information is now possible. The very notion of discrete types of standalone documents—plans, specifications, correspondence, schedules—becomes obsolete.

The promise of Internet-delivered product data goes far beyond replacing brochures with Web sites. Products could be classified with far richer detail than they are at present. Properties including shape, behavior, performance data, and transport requirements, along with embedded links to relevant code requirements and test results, could all be included in an electronic specification. Java applets could allow a Web site visitor to extract data about products in a variety of useful ways: comparing the price and performance of various models, checking available options and finishes, or studying the energy consumption of a product when used in a particular sun exposure. From there, it isn’t hard to imagine product models also carrying information about life-cycle performance. Instead of serving as a static single-use document, a product specification could actually “learn,” not only during the design and construction process but over the life cycle of all buildings known to contain the product. Performance issues, maintenance, and replacement data could all be integrated into such a “living” specification.

continued...