Citation
Web-based construction document processing through a "malleable frame"

Material Information

Title:
Web-based construction document processing through a "malleable frame"
Creator:
Zhu, Yimin
Publication Date:
Language:
English
Physical Description:
ix, 189 leaves : ill. ; 29 cm.

Subjects

Subjects / Keywords:
Business orders ( jstor )
Civil engineering ( jstor )
Cognitive models ( jstor )
Computer technology ( jstor )
Databases ( jstor )
Information technology ( jstor )
Kaleidoscopes ( jstor )
Malleability ( jstor )
Multimedia materials ( jstor )
XML ( jstor )
Architecture thesis, Ph. D ( lcsh )
Dissertations, Academic -- Architecture -- UF ( lcsh )
City of Gainesville ( local )
Genre:
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )

Notes

Thesis:
Thesis (Ph. D.)--University of Florida, 1999.
Bibliography:
Includes bibliographical references (leaves 178-188).
Additional Physical Form:
Also available online.
General Note:
Printout.
General Note:
Vita.
Statement of Responsibility:
by Yimin Zhu.

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
The University of Florida George A. Smathers Libraries respect the intellectual property rights of others and do not claim any copyright interest in this item. This item may be protected by copyright but is made available here under a claim of fair use (17 U.S.C. §107) for non-profit research and educational purposes. Users of this work have responsibility for determining copyright status prior to reusing, publishing or reproducing this item for purposes other than what is allowed by fair use or other copyright exemptions. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder. The Smathers Libraries would like to learn more about this item and invite individuals or organizations to contact the RDS coordinator (ufdissertations@uflib.ufl.edu) with any additional information they can provide.
Resource Identifier:
021585164 ( ALEPH )
43603457 ( OCLC )

Downloads

This item has the following downloads:


Full Text










WEB-BASED CONSTRUCTION DOCUMENT PROCESSING THROUGH A
"MALLEABLE FRAME"














By

YIMIN ZHU













A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA

1999






























To my wife Li Li














ACKNOWLEDGMENTS

I would like to express my gratitude toward my chair, Dr. Raymond Issa, and co-

chair, Dr. Robert Cox, for their excellent advice, guidance, patience and time, without

which this work would not have been possible. It was a great pleasure and precious

experience working with them. Also I would like to thank Dr. Randy Chow who help me

with my research adventure in a completely different world from construction and served

as chair of my master's degree committee in Computer and Information Science and

Engineering. I also would like to thank Dr. Dennis Fukai and Dr. Ian Flood for serving

on my committee and the excellent advice they gave me for this work.




























11iii














TABLE OF CONTENTS
page


ACKNOWLEDGEMENTS....................................................................................... iii

A B STR A C T ............................................................................................................... viii

C H A PT ER S ................................................................................................................... 1

1. RESEA R CH O V ERV IEW .............................................................................................. 1

1.1 Research O bjectives........................................................................................... 1
1.2 Research H ypothesis.......................................................................................... 2
1.3 R search Scope .................................................................................................... 3
1.3.1 Intended U sers. .......................................................................................... 3
1.3.2 Type of Construction Documents to Be Studied ..........................................3
1.3.3 Local Information Considered for Test Cases.............................................4
1.4 Research Significance........................................................................................ 4
1.5 Research Methodology .................................................................................... 5
1.5.1 Literature Review. .................................................................................. 6
1.5.2 Development of "Malleable Frame"........................................ ...............7
1.5.3 "Malleable Frame" System Design.........................................................7
1.5.4 System Implementation. .........................................................................7
1.5.5 Hypothesis Testing ........................................ ......................................... 8

2. LITERATURE REVIEW ...................................................................................... 10

2.1 Fragmentation of the Construction Industry..................................... ............ 10
2.2 Related Research Studies.................................................................................... 12
2.2.1 Technical Integration.................................................................................14
2.2.2 Managerial Integration.............................................................................23
2.2.3 A Missing Piece between the Technical Integration and the
M anagerial Integration........................................................................................ 24
2.3 Current Web-Based Applications in the Construction Industry..........................27
2.3.1 Major Application Types .........................................................................27
2.3.2 Limitations of the Current Web-based Applications......................... ..........31
2.4 An Alternative Solution Web-Based "Front-End" Integration ........................37
2.4.1 A "Malleable Frame"................................................................................38
2.4.2 A "Malleable Frame" System ..................................................................40
2.4.3 Characteristics of the Web-Based "Front-End" Integration.......................40
2.5 Sum m ary ................................................. .................................................... ..43


iv










3 DEVELOPMENT OF A "MALLEABLE FRAME" ................................................45

3.1 A Brief Introduction to SGML and XML..........................................................45
3.1.1 SGML (Standard Generalized Markup Language)...............................45
3.1.2 XML (eXtended Markup Language) ....................................................46
3.2 A Sample Construction Document ...................................................................50
3.2.1 Construction Change Orders and Change Order Processing......................50
3.2.2 A Request for Change Order Proposal ................................................52
3.3 Methodology for Developing A Document Type Definition (DTD) ..................52
3.3.1 Phases of Development.........................................................................52
3.3.2 Models for Illustrating Document Structure...............................................54
3.3.3 Railroad Model Diagrams..................................................................... 57
3.4 A DTD of A Request for Change Order Proposal (RCOP).................................58
3.4.1 D ocum ent A nalysis.................................................................................. 58
3.4.2 A Document Model for A Request for Change Order Proposal .................60
3.4.3 A DTD for the Request for Change Order Proposal...................................64
3.5 The Request for Change Order Proposal in XML Format.....................................66
3.6 Sum m ary .......................................................................................................... 67

4. "MALLEABLE FRAME" SYSTEM DESIGN...........................................................70

4.1 Methodologies for Hypermedia System Design............................................70
4. 1.1H D M ................................................................. ...................................72
4.1.2 O O H D M .................................................................................................74
4.1.3 R M M ....................................................................................................... 75
4.1.4 Summary of the Design Methodology..................................................77
4.2 Malleability Considerations for the System Design............................................77
4.2.1 Document Preparation and Interpretation....................................................78
4.2.2 User Interactions.......................................... .............. ........................... 78
4.2.3 Inforam tio Binding ...................................... ............... ..........................79
4.2.4 Document Workflow ........................................................................... 80
4.3 A "M alleable Frame" System ................................... ........................................80
4.3.1 System Architecture.............................. .................. ..............................80
4.3.2 The Conceptural Schem a...................................... ......................................81
4.3.3 The Navigational Schema................................... ............... ............... 83
4.3.4 The Presentation Schema...................................................................... 83
4.4 Overview of Construction Information Classification Systems (CICS)...............87
4.4.1 A Brief History of Related Research Studies .............................................87
4.4.2 CSI M asterform at ............................................................ .....................89
4.4.3 Using CSI Masterformat.......................................................................91
4.4.4 The Use of the CICS Masterformat for Malleability..................................93
4.5 Sum m ary.................................................. ....................................................... 94






V









5. SY STEM IM PLEM EN TATION ................................................................................ .. 96

5.1 Overview of Im plem entation Technology................................................. ........96
5.1.1 Document Representations and the Document Object Model (DOM) .........96
5.1.2 XM L Parsers ...........................................................................................97
5.1.3 XM L and W eb Database Integration.............................................. ......98
5.1.4 Java Program m ing Language........................ ...........................................99
5.2 Im plem entation Stategies................................................................................. 99
5.3 A ssum ptions and Lim itations ................................... ........................................102
5.3.1 A ssum ptions.......................................................................................... 102
5.3.2 Lim itations .................................................................................................. 103
5.4 Sum m ary ........................................................................................................ 104

6. HYPOTHESIS TESTIN G ..................................................................................... 105

6.1 Introduction......................... ........................................................................... 105
6.2 Pilot Study......................................................................................................106
6.3 Test Plans ....................................................................................................... 106
6.4 Test Cases ...................................................................................................... 111
6.5 Test System Design ............................................................................................. 112
6.5.1 Sam ple Testing ........................................................................................... 112
6.5.2 Flow Control ............................................................................................... 113
6.5.3 Tim ing................................................................................................... 113
6.5.4 Survey ................................................................................................... 113
6.6 Data Collection .................................................................................................... 114
6.6.1 Sam pling ..................................................................................................... 114
6.6.2 Sam ple Size...........................................................................................1 14
6.6.3 Collected Data............................................................................................. 115
6.6.4 User Satisfaction within the Same Experience Level............................... 119
6.6.5 User Satisfaction Comparison bewteen Different Experience Groups.......123
6.7 Hypothesis Testing ........................................................................................129
6.7.1 Hypothesis .................................................................................................. 129
6.7.2 Desired Sam ple Size and Selected Sam ple Size....................................... 130
6.7.3 The Standard System vs the "Malleable Frame" System Statistical
Analysis .................................................................................................... 131
6.7.4 N orm alized Com parison Test ................................................................... 131
6.7.5 Sam ple Size Analysis...................................................... .................... 133
6.7.6 The Region of Rejection............................................................................. 134
6.7.7 Statistical Decisions.................................................................................... 134
6.8 Sum m ary........................................................................................................ 135

7. CON CLU SION ............................................................... ....................................... 137

7.1 Technical Feasibility..................................................... ................................. 137
7.1.1 D esign M ethodologies ........................................................................... 137
7.1.2 Im plem entation Tools............................................................................ 139



vi









7.2 H ypothesis Testing ......................................................................................... 142
7.3 U ser Satisfaction ............................................................................................... 143

8. RECOMMENDATIONS FOR FURTHER STUDIES........................................144

8.1 Topics on the Neutral Document Format ....................................................... 144
8.1.1 Document Analysis................................................................................144
8.1.2 Construction Markup Language ...............................................................145
8.2 Topics on System Design ...............................................................................146
8.2.1 Interface .................................................................................................... 146
8.2.2 U ser N eeds................................................................................................ 146
8.2.3 Database................................................................................................146
8.3 Topics on System Testing............................................................................147
8.3.1 T esting ................................................................................................... 147
8.3.2 Testing More Features Quantatively........................................................ 147
8.3.3 Testing the Whole Process of Document Processing ...............................148

APPENDICES

A SAMPLE CONSTRUCTION DOCUMENTS .................................................149

B SCREEN SHOTS OF KALEIDOSCOPE......... ................................................153

C TH E TEST SY STEM ................................................................................................ 160

D G LO SSA R Y ......................................................................................................... 175

LIST OF REFERENCES..........................................................................................178

BIOGRAPHICAL SKETCH ..................................................................................... 189






















vii














Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

WEB-BASED CONSTRUCTION DOCUMENT PROCESSING THROUGH A
"MALLEABLE FRAME"

By

Yimin Zhu

December 1999

Chairman: Raymond Issa
Major Department: College of Architecture

Information management is critical to the success of a construction project.

Because of the fragmentation of the construction industry and the diversity of

construction projects, information sharing and collaboration are important measures to

achieve successful project information management. As Internet based technology, such

as the WWW (World Wide Web), e-mail, e-commerce, e-bid and e-BuilderT, becomes

ubiquitous, many practitioners in the construction industry believe that the Internet is the

way to go for managing and disseminating construction information.

Currently Web-based applications have greatly relieved problems caused by

geographical fragmentation; however these applications are not designed to deal with

problems caused by functional fragmentation. Consequently, documents prepared using a

third-party software tool cannot be directly used to retrieve related information in the

viewer's local system.




viii








This research treats a document as a "malleable frame" that can be adjusted

according to user's needs and shows that a "malleable frame" system is more efficient in

terms of processing construction documents than a standard system.

The research shows that a "malleable frame" system is technically feasible. The

key is to have a neutral data format. Currently XML (eXtended Markup Language)

related technology can be used to build such a neutral data format. In addition, many

kinds of implementation tools, such as Java, DHTML (Dynamic Hypertext Markup

Language) and COM (Component Object Model), are now available. It is inconclusive as

to whether using the "malleable frame" system is more efficient than using the standard

system. If document processing does not require local information or the required

information is not available locally, the "malleable frame" system does not perform

better than the standard system does. Nevertheless, if local information required by

document processing is available, the "malleable frame" system performs at least as good

as the standard system does.























ix















CHAPTER 1
RESEARCH OVERVIEW


1.1 Research Objectives


The goal of this research is to study the feasibility of developing a "malleable

- frame" system by using available computer technologies and to propose methodologies

for developing the "malleable frame" system. Also, the relationship between the

malleability of a system and the efficiency of processing a document needs to be studied

to determine whether the malleability provided by the "malleable frame" system is

superior to a system without malleability.

To achieve the goal, a series of objectives has to be achieved. These objectives

include:

1. Identifying new Web technologies that support the idea of a "malleable frame."

2. Identifying methods for developing the "malleable frame."

3. Applying the identified method to develop a "malleable frame" based on a sample

construction document (a use case).

4. Identifying methods for developing the "malleable frame" system.

5. Applying the identified method to develop the "malleable frame" system based on the

"malleable frame" developed.

6. Testing the idea of malleability.






1






2


1.2 Research Hypothesis


There are many features that a "malleable frame" can provide, while a standard

system cannot. Those features include allowing a user to customize document

presentation and automatically retrieve related local information. This research is focused

on the second feature. It is this feature that makes a "malleable frame" system different

from a standard system in that a standard system usually puts a received document and

related local information in separate windows while a "malleable frame" system can put

local information right beside a related information object of the document. Therefore,

the hypothesis of this research is that (H0): if we allow a document and related local

information be put together (in the same window), the improvement in terms of time for

completing a stage transition will be significant. If tmn and Ps are population means of

time for completing stage transition for the "malleable frame" system and the standard

system respectively, this hypothesis can be represented by a null hypothesis (Ho) and an

alternative hypothesis (H,).

Ho: s rm = 0

H,: ls .m > 0

Ho states "there is no difference between the 'malleable frame' system and the

standard system in terms of time for completing a stage transition." H, states "the

'malleable frame' system is better than the standard system in terms of time for

completing a stage transition."

Construction document processing involves a series of steps. For example, a

complete change order process involves the step from a Request for Change Order

Proposal to a Change Order Proposal. A stage transition is one of those steps.






3


1.3 Research Scope


Theoretically a "malleable frame" system can be used by any construction

professional to deal with any kind of construction document in any kind of construction

project. In order to narrow the scope of this research, the research scope will be defined in

terms of intended users, the type of construction documents, and local information

considered for test cases.

1.3.1 Intended Users

Different project professionals may have different project information needs. The

perspectives of different users towards the same set of information may be different too.

This research is focused only on the needs of construction site managers and site

engineers when dealing with a certain construction document. Since the mechanism of

how to adjust perspectives according to a user is similar, the mechanism used in this

study can be applied to build systems for other project participants.

This research will not try to predict the user's information needs when dealing

with a certain document. Instead, this research will assume that a user may need certain

types of information for dealing with a given construction document.

1.3.2 Type of Construction Documents to Be Studied

Roughly, construction documentation can be divided into three phases, pre-

construction, construction and post-construction (Mincks, & Johnston, 1998). This

research focuses on documents such as change orders, shop drawings and RFIs during the

construction phase in which new information is generated and recorded for project

control and administration. Actually, this research will use the Request for Change Order

Proposals (RCOP) as a test document to develop the "malleable frame" system. This does






4


not mean that the methodology developed based on the Request for Change Order

Proposals cannot apply to other documents. The Request for Change Order Proposals

were selected only because they are common cases that project managers and site

engineers encounter very often. The Request for Change Order Proposals suit the

problem that this research describes very well, because the Request for Change Order

Proposals often refer to certain building components or construction activities and users

information from many sources.

The whole process of dealing with construction change orders involves many

steps. It will be redundant to study all steps of the whole process. Since this research uses

the Request for Change Order Proposals for the development of a "malleable frame"

system, naturally one step of the whole process is selected. Accordingly, a stage transition

between the RCOP (Request for Change Order Proposal) and the COP (Change Order

Proposal), will be studied.

1.3.3 Local Information Considered for Test Cases

For a project manager or a site engineer to properly process a Request for Change

Order Proposal, he/she may need many different types of information that can be found in

schedules, budgets, specifications, drawings, estimates and so on. In this research, only

schedule information will be considered.

1.4 Research Significance


Traditionally, construction information sharing and the document production are

tied together (Abou-Zeid, Russell, Hanna, & Park 1995, Finch, Flanagan, & March,

1996). Such approaches limit the participant's ability to interact with the information

source and thus also limit the possibility of improving information sharing. This research






5


offers a profound change in the way that project participants share information. It

essentially cuts the link between data and information presentation. The new approach

allows a user centered approach in which users can tailor the information, rather than just

passively use the information whose content and format are out of their control.

This research treats construction documents as media rather than end products.

Usually, documents represent the end of a document production process. Other processes

are treated separately. If other processes need information, normally another

interpretation process, either by man or by machine, is necessary. This interpretation is a

waste (Porter, 1980, Betts, 1995, Turk, 1997). In this research, documents are treated as

vehicles of extendible objects, which can quickly integrate with other objects in an

appropriate way and directly support other processes without any intermediate processes.

1.5 Research Methodology


Many computer-related studies find that it is very difficult to quantify the

performance or results of information technology (IT) because of two reasons (Li, 1996).

First IT usually adds value to other activities rather than delivering benefits directly.

Second IT often gradually accrues to a construction organization as a whole and is not

always visible as improvements in a short term. This makes it very difficult for

quantitative hypothesis testing of academic research studies. In fact some even argue that

since there are so many methods to develop computer-based applications and there are

already so many computer tools out there, it really depends on users to decide if a new

approach is better than the others and proper to them. Such arguments indicate that it will

be enough for a computer application research study to just present a technically feasible

solution. However, there is another completely different view emphasizing the






6


importance of classic scientific research methodology even for the computer application

research (Harriss, 1998, Wing, Raftery, & Walker, 1998). For this research, a

compromise is made, which means that this research will develop a prototype system to

show the technical feasibility and also develop a test system to test the hypothesis.

The research methodology employed in this dissertation consists of several major

phases including literature review, development of a "malleable frame," the "malleable

frame" system design and implementation, system testing, and conclusions and

recommendations. Figure 1.1 is a flowchart illustrating the methodology of this research.

The phases are briefly discussed below.

1.5.1 Literature Review

This phase of the research is mainly focused on gathering information generated

by previous studies in order to identify new Web technologies that support the idea of a

"malleable frame", identify methods for developing a "malleable frame" and identify

methods for developing "malleable frame" systems. In addition, other related subjects are

also looked into. Following is a list of areas that the literature review covers

* Construction information and information management

* Current computer applications in construction practice

* Computer mediated communication and computer supported collaborative work

* Construction documentation

* Web-based systems

* SGML and XML

* Hypermedia Design

* Statistical Analysis






7


It needs to be pointed out that this dissertation puts the results of the literature

study in related chapters and sections rather in one chapter.

1.5.2 Development of "Malleable Frame"

In the technical sense, a "malleable frame" is equivalent to a document type

definition (DTD) or document schema. The DTD defines the structure of a document, and

what and how information should be included in the document. Such a DTD is a generic

document template from which document instances can be generated. Therefore,

developing a DTD for a Request for Change Order Proposal is the very first step of this

research. Major steps of this phase include

* Define the goal for developing a DTD

* Analyze document needs

* Design document type requirements

* Complete the design of a DTD

1.5.3 "Malleable Frame" System Design

During this phase, focus is given to the architecture of the "malleable frame"

system. Major activities involved in this phase include

* Identify major hypermedia development methodologies and tools

* Define requirements of a hypermedia system to be developed

* Define the overall architecture of the "malleable frame" system

1.5.4 System Implementation

A prototype "malleable frame" system is implemented during this phase. The

system shows how current Web technologies can be used to build such a "malleable






8


frame" system. The major tasks of this phase are to implement the system by using the

Java programming language.

1.5.5 Hypothesis Testing

In this phase, focus is given to prove the hypothesis stated previously. Two types

of test systems, a standard test system and a "malleable frame" system are built in order

to test the hypothesis. It should be noticed here that it is very difficult to test the

"malleable frame" itself. Rather tests will be about one of the effects of malleability. The

tests are to find the time difference between the two systems, the standard system (SS)

and the "malleable frame" system (MFS). For the testing purpose, schedule information

will be used. In the standard system, users need to synthesize information to find out what

decision to make. In the "malleable frame" system, related local information is put in the

same window with the Request for Change Order Proposal therefore users do not need to

find and synthesize information. For both systems, a built-in timer is used to keep track of

time. Please refer to the chapter, "Hypothesis Testing," for details. The main steps of this

phase are

* Define test plans

* Select test cases

* Set up test systems

* Define sample and sample size

* Collect data and information

* Statistical analysis







9






RESEARCH GOAL / HYOTHESIS New Web technologies

E iMethodology for developing a "Malleable
LITERATURE REVIEW Frame"

Methodology for developing a "Malleable
-- Frame" system

Implementation tools

Statistical analysis

-- Others



DEVELOPMENT OF A "MALLEABLE Collect sample construction documents
FRAME"
Define document requirements

--F- Define document structure

--- Develop document models

Develop DTD for the document



"MALLEABLE FRAME" SYSTEM DESIGN Define development methodology

Define system requirements

Define system architecture



SYSTEM IMPLEMENTATION


S--- Design test systems
HYPOTHESIS TESTING
--Select test cases

Identify population and samples

-Define sample size

-Conduct tests

-Collect / compile/ analyze data

-- Hypothesis evaluation
CONCLUSION AND RCOMMENDATIONS

Figure 1.1 A flowchart illustrating research process

















CHAPTER 2
LITERATURE REVIEW


2.1 Fragmentation of the Construction Industry


Fragmentation is one of the distinct characteristics of the construction industry

(Howard, Levitt, Paulson, Pohl, & Tatum, 1989). According to Porter, any production

process can be viewed as a value chain. Each time a product is worked on in some way or

another, not only are resources consumed in that operation but also value is added to the

product (Porter, 1980). "These processes include not only the direct processes which

cause a physical alteration of the product but also such processes as moving the product

from one place to another "(O'Brien, 1993, p. 446). To be as efficient and effective as

possible, intermediary processes that do not add value to the entire process, such as

moving the product should be reduced to the minimum level.

However, the value chain of a construction process is fragmented by at least two

factors in general, geographic fragmentation and functional fragmentation (O'Brien, &

Al-Soufi, 1993). The geographic fragmentation is caused by the fact that most of the

construction projects are based on temporary collaborations of owners, architects,

contractors, subcontractors and suppliers. In addition the locations of the projects and the

locations of these partners are usually geographically different, sometimes thousands of

miles apart. The functional fragmentation can be noticed when project partners take

different roles throughout the entire construction process. For instance, architects,


10





11


engineers, contractors, subcontractors, suppliers and so on may join the team at different

stages of a construction process. Even within a construction company, the functional

fragmentation exists because of different roles of schedulers, estimators, superintendents

and project managers. It is thus obvious that fragmentation permeates every aspect of the

construction industry and segments an entire construction process, construction

operations and management, and project partners into different phases, various functional

and management groups, and different professional roles (O'Brien, & Al-Soufi, 1993).

Therefore, some intermediary processes such as effective and efficient communication

between project partners are necessary and essential for the success of a construction

project (Brandon, & Betts, 1995).

One of the main purposes of communication between construction partners is to

share information. However, information sharing in the project construction context is a

necessary evil. On the one hand fragmentation requires information sharing. On the other

hand fragmentation itself is the major obstacle for information sharing. Research has

already shown that, in the construction industry, data provided by one value-adding

process is rarely in a format suitable for subsequent downstream processes (Ndekurgi, &

McCaffer, 1988, Scott, 1995). This can be viewed as data fragmentation in general. A

classic example of such problems is the WBS (Work Breakdown System) for scheduling

and the CBS (Cost Breakdown System) for estimating. Because of different levels of

details, the two systems cannot communicate with each other without some intermediary

processes (Abudayyeh, & Rasdorf, 1991). Generally, data fragmentation is a derivative

of geographic fragmentation and functional fragmentation.





12


Data fragmentation is a focus of CIC (Computer Integrated Construction)

research (Brandon, & Betts, 1995). Electronic information sharing holds the promise to

overcome the inefficiencies caused by fragmentation. Research suggests that benefits

from electronic information sharing include a reduction in time requirements and errors

for data input and output, accelerated communication among participants, and improved

completeness of information received by each team member (Teicholz, & Fischer 1994).

However, most current software solutions for drafting, scheduling, estimating and project

document management can only expedite the particular functionalities for which they

were designed. They barely solve the problem of data fragmentation that leads to what is

called "Islands of Information" as shown in Figure 2.1 (Hunnas, & Silen, 1995).

In summary, the construction industry has been experiencing problems of

information sharing at different phases of construction due to fragmentation of this

industry. Many researchers also suggest that information technology will help to solve

problems caused by fragmentation. In the following sections, related research studies and

applications are discussed in order to propose an alternative approach.

2.2 Related Research Studies


Integration is suggested as the best approach to overcome difficulties caused by

fragmentation of the construction industry (Anderson, 1981, Ndekugi, & McCaffer,

1988). A general term to describe such research activities is called CIC (Computer

Integrated Construction). CIC can be defined as "a business process that links the project

participants in a facility project into a collaborative team through all phases of a project"

(Teicholz, & Fischer, 1994, p121).






13



Isfands of Automation
in Construction
After thie iceperiodsome I 0
years ago the ladis stifrisiing Di.tstructural
andeqosing new terrain never analys
Steel & Concret
iSmt 6ny =ax PomtMdlt

Accounting
& Data




Reduct
dat a basee
12D DraugMhtin

C Q 9,4 lp Materal & com

Quantity
Calculatio




'IS
C e Ca







Source: Hunnas, & Silen, 1995

Figure 2.1 Islands of information





14




There are two types of integration strategies, technical and managerial (Fischer, &

Kunz, 1995). Technical integration strategy focuses on data interoperability of software

applications that support different disciplines. Managerial integration strategy puts an

emphasis on the collaboration between a client and various discipline specialists, and

among specialists within project teams or an integrated design-build organization. In fact,

it is argued that the AEC industry is not able to use IT (Information Technology)

strategically yet because companies view IT as a technological issue, rather than a

business issue, and thus delegate it to IT specialists (Betts, 1991). Therefore, most of the

integration research has been focusing on proposing technical solutions to overcome

fragmentation in the AEC industry (Howard, Levitt, Paulson, Pohl, & Tatum, 1989).

However, managerial integration is an equally important aspect that is critical to the

success of IT solutions (Earl 1989, Fischer, & Breuer, 1995). The main push in the AEC

research community is to use IT to "integrate" different parties and phases in the project

life cycle (Aplegat, 1988, Howard, Levitt, Paulson, Pohl, & Tatum, 1989). Thus it is clear

that parallel advancement of technical integration and managerial integration will

eventually be the way to go. In this dissertation, the focus will be on technical integration

but both technical integration and managerial integration will be discussed.

2.2.1 Technical Integration

The purpose of technical integration is to solve the problem of data

fragmentation. Basically there are four approaches to achieve this goal (Rezgui, Brown,

Cooper, Yip, Brandon, & Kirkham, 1996). They are communication between

applications, knowledge-based interfaces linking multiple applications and multiple





15


databases, integration through a shared project model holding all the information relating

to a project according to a common infrastructure model, and integration through

geometry. In the following sections, these approaches will be reviewed to find out

common strategies that this research can apply.

Communication between Applications

Communication between applications resorts to the idea of a neutral data format.

This has been already regarded as an alternative to the shared project model solution

(Ahmad, Russell, & Abou-Zeid, 1995, Abou-Zeid, Russell, Hanna, & Park, 1995). The

neutral data format allows different software systems to share data. Initial Graphics

Exchanges Specifications (IGES) is an example of such a neutral data format for CAD

systems.

The Initial Graphics Exchange Specification (IGES) defines a neutral data format

that allows the digital exchange of information among computer-aided design (CAD)

systems. CAD systems are in use today in increasing numbers for applications in all

phases of the design, analysis, manufacture and testing of products. Since it is a common

practice that a designer uses one type of CAD system and a contractor may use a

different type of CAD system, there is a need for the capability of exchanging data

digitally among all CAD systems. IGES provides a neutral definition and format for the

exchange of specific data. Using IGES, a user can exchange product data models in the

form of wire frame or solid representations, as well as surface representations.

Applications supported by IGES include traditional engineering drawings as well as

models for analysis and/or various manufacturing functions.





16


One such commercial product is the AutoCAD IGES Translator. The AutoCAD

IGES Translator (AIT) is a separately purchased AutoCAD Development System (ADS)-

based application for importing and exporting IGES files. This product supports the

IGES Version 5.2 specification and is compatible with AutoCAD Release 13 and

AutoSurf Release 2.1 software. Figure 2.2 shows how it works.


IGES
Data

CAD Systems CAD Systems

Local IGES IGES Local
Data Translator Translator Data


Figure 2.2 Communication through a neutral data format

Knowledge-Based Interface

This is one of the early strategies for integration. The motivation of this approach

is that "production expert systems for realistic engineering applications must process

large volumes of data and will require access to large distributed databases. The need to

use expert systems when addressing larger problems motivated us to develop an expert

system -- DBMS interface" (Howard, & Rehak, 1989, p65). KADBASSE was a classic

example of such expert systems (Rehak, & Howard, 1985, 1989). The KADBASE, a

knowledge based DBMS prototype, is an interface in which multiple databases and

knowledge-based systems can communicate as independent, self-descriptive components

within a loosely coupled distributed engineering computer system. Figure 2.3 shows an

overview of the KADBASE architecture.





17


The KADBASE is composed of three parts, the Knowledge-Based System

Interface (KBSI), the Knowledge-Based Database Interface (KBDBI) and the Network

Data Access Manager (NDAM). The KBSI formulates queries and updates sent to the

NDAM and processes replies from the NDAM. The KBSI possesses knowledge about the

data space of the whole system and uses that knowledge to perform semantic and

syntactic translations for queries, updates and replies. The KBDBI is designed for

accepting queries and updates from the NDAM and returning appropriate replies. The

KBDBI possesses knowledge about the local database schema and the local language for

data manipulation requests. The KBDBI uses that knowledge to perform semantic and

syntactic translations for queries, updates and replies. The NDAM is the actual interface

between the knowledge-based system and the databases. It receives requests from

knowledge-based systems (through their KBSIs) expressed in terms of the global schema.

Using information associated with the global schema, the NDAM locates sources for data

referenced in a request and decomposes each request into subqueries or updates to

individual target databases. These subrequests are sent to corresponding KBDBIs for

processing. Replies from KBDBIs are combined to form a single reply to the original

request and sent to the requesting application through its KBSI.

The KADBASE is a typical example of this approach. Similarly, this type of

application is applied to construction equipment management as well (Udo-Inyang, &

Chen, 1997).





18












Knowledge based Knowledge based
system system


KBSI I KBSI





Network Data
Access Manager





Knowledge based Knowledge based Knowledge based
database interface database interface database interface
KBDBI KBDBI KBDBI

Database Database Database

Source: Howard, & Rehak, 1989

Figure 2.3 The KADBASE architecture






19


In summary, the basic idea of the knowledge-based interface approach is that it

uses knowledge systems to manipulate data that may be located in different databases

and maintains a global schema to manage such data. In this way, different databases for

drafting, scheduling or estimating can be integrated and data from different databases can

be presented jointly.

A Shared Project Information Model

The idea of a shared project information model can be traced back at least to

Wright. In his paper "Computer Integrated Construction" (Wright, 1988) he discussed the

idea of an integrated project information system, which he defined as a dynamic

repository for project-specific information that can be appropriately accessible to all

project participants. He also discussed how this idea could be implemented in the context

of construction industry. He suggested that "the technologies for integrated project

information systems may themselves be proprietary. Software packages and the host

hardware may be commercial products. The provision of a project information service

also can be a private or professional activity. The services can belong to and be operated

by the owner if the owner regularly builds and operates facilities; it can be provided by

the contractor or by a service bureau specializing in integrated project information

system service" (Wright, 1988). Now, more than ten years later, one can see that many

things that Wright "predicted" in1988 have been implemented in the construction

industry.

Ever since then, the idea of the shared project information model was spinning

around among the academicians. Figure 2.4 shows the typical shared project information

model by project participants. This model can also be represented by different functional





20

groups in the construction industry, such as designing, planning, scheduling, estimating

and accounting, shown in Figure 2.5. The arrows in the diagram represent

communication channels. They used to be only paper-based documents. Now paper-

based documents are more and more replaced by electronic media such as disk, CD-

ROM and Web pages.

One of the major advantages of the model-based approach is that a model is

independent of any particular implementation and any particular application. Therefore

different applications may eventually be able to share the same information model and

communicate with each other via a shared information model (Rezgui, Brown, Cooper,

Yip, Brandon and Kirkham, 1996). Figure 2.5 illustrates the idea of a shared project

information model by applications. Examples of the model-based approach include

COKE (COnstruction Knowledge Expert), OPIS (Object-model based Project

Information System), ATLAS (Architectures Methodologies and Tools for Computer

Integrated Large Scale Engineering), COMMIT (COMputer Models for the Building

Industry in Europe), RATAS, ICON (Integration of Construction Information) and STEP

(Standard for the Exchange of Product Model Data).


Architect Engineer




Shared
Contractor -Project Owner
Model I


/u S
Sub-contractor Supplier





21


Source: Fischer, & Froese, 1996

Figure 2.4 The conceptual shared project information model


Scheduling Estimating Drafting Others

Shared Project Model


Source: Fischer, & Froese, 1996

Figure 2.5 Shared project model

One of achievements in this area is the IFC (Industrial Foundation Classes) by

IAI (International Alliance for Interoperability). Providing a foundation for the shared

project model, IFC serves as an industrial standard for the ACE/FM industry. There are

three possible ways to share data using IFC (Wix, & See, 1999).

By creating a physical file of information that may be shared across a

network, by email or on a physical medium such as a floppy disk. Presently,

most software applications share information using physical files.

By placing information in a database that has an interface defined according

to the ISO 10303 part 22 (Standard Data Access Interface) for putting in and

getting out data. A number of software applications are using this approach at

present.

By using software interfaces that can expose the information content of

defined groups of attributes within an object. Software interfaces allow for

direct communication between applications without the need for an

intermediate file or database.





22


Integration through Geometry

Since this is often the case in CAD packages where integration is based on and

only limited to geometrical information (Rezgui, Brown, Cooper, Yip, Brandon and

Kirkham, 1996), this type of integration will not be elaborated here.

Summary of Technical Integration

It is clear that the technical integration approaches discussed above can be

generalized into two categories. One category represented by the knowledge-based

interface approach features that different systems share information at a low system level.

The second category represented by communication between applications does not

require different systems sharing anything at system level. Instead, different systems

communicate with each other through a third party. Although according to different

implementations the shared project information model approach can fall into both

categories, those implementations don't represent any new category.

Philosophically, such generalization about technical integration is reasonable

because the problem is similar to human communication using two different languages. If

two people need to communicate and they speak different languages, they either find a

translator or learn to use a common language. The communication between two computer

systems is a similar problem in this sense.

Furthermore, in this research, the approach of the first category, i.e. the shared

project information model approach (using database and using programming interfaces)

and the knowledge-based interface, is called "back-end" integration. It is called "back-

end" integration because the integration actually happens at a low system level and

applications are simply different views to the same database. For example, COMMIT,





23


ICON, and RATAS are implemented in such a way so that data and information

generated within the same package do not have the data fragmentation problem at all.

The second type is called "front-end" integration since integration happens at the "front"

of different system that do not share anything at the system level. "Front-end" integration

is based on sharing a neutral data format that is independent of any system.

2.2.2 Managerial Integration

As discussed earlier, managerial integration is as important as technical

integration. Currently managerial integration is focused on using technology, such as

email, EDI, conferencing tools and so on to bring project participants together (Anumba,

& Evbuomwan, 1997). Technically, managerial integration is intensively and extensively

under the subject of Computer Supported Collaborative Work (CSCW). The construction

industry is starting to pick up this technology to support its business and operation.

More than ten years ago, Paul Cashman and Irene Grief organized a workshop of

people from various disciplines who shared an interest in how people work, with an eye

to understanding how technology could support them. They coined the term "Computer-

Supported Cooperative Work" to describe this common interest.

In 1997, Collaboration StrategiesT conducted research to examine how large

companies are using IP networks (internet protocol, i.e. internet and intranets) to support

electronic collaboration. Out of 100 interviews, 85% of those interviewed responded that

the internet-based collaboration is critical to the functions of their business (electronic

collaboration on the internet and intranets, 1997). Among them 56% felt that

collaboration was necessary to support a distributed workforce by increasing

communication, coordination, facilitation and planning. It seems that the CSCW and the






24


problems that this technology tries to solve decide that the internet will play a significant

role.

Actually the internet and intranets related CSCW applications, especially the

Web-related applications, are one of the major concerns of CSCW research. Typical

Web-related CSCW applications includes collaborative agent approaches (Jin, & Ohira,

1996, McGraw, Lawrence, Morton, & Heckel, 1996, Knapik, & Johnson, 1998), shared

work-space approaches and work flow approaches, i.e. Alliance (Salcedo, & Decouchant,

1997), BSCW (Bentley, Horstmann, & Trevor, 1997) and WebFlow (Grasso, Menunier,

Pagani, & Pareschi, 1997).

Typical research studies in the construction industry include the virtual

engineering team (Line, 1997), collaborative environment for resolving conflicts and

disputes due to the complexity of large-scale project construction (Pena-Mora, & Wang,

1998), collaborative system for managing design changes (Mokhtar, Bedard, & Fazio,

1998), collaborative engineering for project field inspection (Rojas, 1997) and so on.

2.2.3 A Missing Piece between the Technical Integration and the Managerial Integration

If technical integration is regarded as a tool to deal with data and managerial

integration as another tool to deal with people, there is still a gap between the data and

the people who use the data. The gap is how the data can be accessed. This is not an

active research area because most companies simply use standard documents for storing,

retrieving and disseminating data and information. Even electronically, the gap is filled

by different kinds of electronic documents that are very much similar in format to their

paper-based counterparts. However, if documents are treated as ways for access to other





25


related information rather than final presentations of data and information, there are more

things to do with the documents.

To understand what else can be done with documents, we should take a look at

how documents are used and what purpose they serve during project construction. During

the construction phase, information is shared and disseminated through multiple bi-

directional communication channels (O'Brien, & Al-Soufi, 1993, Fischer, & Kunz, 1995,

Andrew, & Teicholz, 1996, Tierfelder, Webollek, WillenBacher, & Grosche, 1997). The

media are different kinds of documents, which are produced, stored and used at separate

locations, such as change orders, shop drawings, payroll reports, invoice and so on

(Abou-Aeid, Russell, Hanna, & Park, 1995, Ahmad, Russell, & Abou-Zeid, 1995,

Edwards, Shaw, & Holt, 1996, Finch, Flanagan, & March, 1996). According to a survey

(Edwards, Shaw, & Holt, 1996), as much as 80% of corporate information is processed

through documents. It has also been estimated that the total number of documents that

relate to a single building structure may typically be in the order of 10,000 (Turk, &

Bjork, 1994). Consequently it is obvious that the construction process demands timely

project documentation that can be easily assimilated. Failure to effectively locate and

manage documents during a project may result in delay and incorrect decisions (Finch,

Flanagan, & March, 1996).

Obviously, the documents are the "things" that are actually shared by different

project participants and are also gateways to the shared or non-shared project information

sources. Unfortunately, not much integration research addresses how construction

documents should be treated in this context.





26


As we know documents are "windows" to the whole process and can evolve as

the process does. No matter whether they are paper-based documents or electronically

generated documents, "documents are interfaces, used to access and navigate through

collections of information" (Haimes, B.,1994, p. 16). If we look at the whole information

source of a project as a reservoir of small information objects, documents provide a way

to show the viewer the semantics of the information objects and the relationships

between the objects. The conventional documents only offer "separated windows" to

viewers, which means it relies on viewers to combine information acquired from the

"separated windows" and generate new knowledge that are not shown by the "separated

windows." The "separated window" is the result of not fully using the capacity of the

computer, since the computer as a mediator has the ability "to process and to alter human

messages and to draw new conclusions regarding human messages" (Chesebro, &

Bonsall, 1989, p. 31). The conventional documents are "fixed windows" as well. The

perspective from which the information objects and their relationships are viewed is pre-

set and fixed by the producers of the documents. However, very often viewers need to

look at the information from another perspective based on the viewers' goals or

objectives. Unfortunately, the conventional documents are not user-centered and do not

allow viewers to adjust perspectives for their best understanding without other

intermediary processes.

In a word, the missing piece is the construction document that needs to be more

flexible to user's needs. Furthermore, since it is also a bridge between different systems

and a gateway to different information sources, the construction document can be an

ideal core to build a new integration strategy around.





27


2.3 Current Web-Based Applications in the Construction Industry


The Word Wide Web has taken the AEC (architecture engineering construction)

industry by storm. Although it is still hard to predict how it will grow over the next few

decades, the Web-based technology certainly exerts great influence on the AEC industry.

A three-year study (Cox, 1996 & 1998, Cox, & Hampson, 1998) shows that the

improvement of the internet/Web related computer capabilities reported by project

managers in the USA has increased significantly, shown in Table 2.1.



Table 2.1 Average computer capabilities reported by project managers
1996 1997 1998 Average Rate of Increase
Email 2.9 3.4 40%
Internet 1.8 2.6 3.1 72%
MS Word 2.8 3.5 3.5 25%
Excel 2.8 3.5 3.5 25%
L-Notes 1.7 3.1 3.1 82%
Timberline 1.5 1.5 1.9 27%
P-3 2.1 2.1 2.3 10%
ACAD 1.8 1.5 1.4 -22%
Source: Cox, 1996 & 1998, Cox and Hampson, 1998

Table2.1 shows that the use of email and the internet has increased significantly

when compared with the specialized software such as Primavera Project Planning (P3),

Timberline and general-purpose software such as MS Word and Excel. In reality, the

internet and the Web-related technologies penetrated into the daily operation of project

construction in the early and mid 90s (Wright, 1993, Setzer, 1994, Angelo, 1995,

Schriener, 1995a, b, & c, Shearer, 1995).

2.3.1 Major Application Types

Ever since the internet and the Web have become accessible to the public in the

early 90s, industries and academic institutions have embraced the technology quickly and





28


enthusiastically. After almost a decade of evolvement, three types of Web-based

applications exist for the construction industry. They are "fee-based project management

service," "build it yourself solutions" and "Web-enabled software." These applications

share the same objective, which is to integrate the Web-based technology into project

construction. They are referred to generally as project Website approaches in this

research.

Fee-Based Project Management Service

This type of application is relatively new to the construction industry. However,

theoretical research has already predicted the emergence of such service in the

construction industry (Betts, Cher, Mathur, & Ofori, 1991, Ahmad, Russell, & Abou-

Zeid, 1995, Paulson, 1995). The "Fee-Based Project Management Service" is for

companies that are unwilling or unable to maintain their extranets. There are many such

service providers for example e-BuilderT, e-Project, Emerging Solutions

(ADVANTAGENET), BlueLine/OnLine (ProjectNet), EVOLV (ProjectCenter),

ThePigeonHole Inc. (ThePigeonHole), Cubus Corp. (Reviewlt AEC), and Bid-Com

(BidCom).

Build It Yourself Solutions

Some AEC companies opt to develop their own Web-based project management

sites. For example, engineering/construction firm, Black & Veatch, was piloting the

Aspects Project Server and SiteBuilder collaborative software by Framework

Technologies Corporation. Built specially for the AEC community, SiteBuilder lets users

create and update project web sites while Project Server delivers collaboration and

coordination functionality for project team members. Another example is a software





29


package developed by a general contractor, Vratsinas Construction Company (VCC).

VCC has developed a project management system based on Lotus-Notes. The system

helps professionals at job sites to keep track of every detail of daily construction

operations. A similar system has also been developed by Zimmer Gunsul Frasca (ZGF), a

Portland based company. Although the overall computing, communication and

collaboration environment is improved greatly by deploying such systems, the "Build It

Yourself Solutions" requires lots of commitments that may not be a good idea for many

construction companies (Information Technology, the Internet and You, ENR, June,

1998). Nevertheless, some companies such as VCC prefer this kind of solution because it

allows them to build applications that fit well into their own business environment and

maintain their own business style.

Web-Enabled Software

Companies such as Emerging Solutions Inc. and Blue-Line/On-Line not only

provide information management services but also sell their products to allow

construction companies to maintain their own project Web sites. One of the advantages

for companies administrating their own project Web sites is that they do not need to

outsource information. This type of application is especially good for those companies

who are very careful about letting other service companies control their data and

information. The disadvantage is that initial cost is relative high.

In addition, an increasing number of software tools for estimating, scheduling,

drafting and project management are offering Web ready features. This means that from

within a specific program, the user can access and share information.





30


Comparison of the Three Types of Applications

The differences between the above three types of applications are very obvious.

They can be simply distinguished by who built the tool and who administered the data.

The major common grounds of these software tools in terms of construction

operations supported are that they all focus on establishing an on-line environment in

which project participants can share information via document exchange. Typical

documents that those systems supports include

Correspondence

Daily Report

RFIs

Transmittals

Submittals

Meeting minutes

Document Logs

Various reports

Change Orders

Purchase Orders

To understand how these Web-based applications deal with construction

documents and work with other software tools such as drafting, scheduling and

estimating, phone interviews and a Web search were conducted. The objective was to

find answers two questions:





31


Question 1: If there is an RFI (Request for Information) from a third party

application, can your system automatically retrieve information from sources

both within and outside your computing environment?

Question 2: How will your system deal with other software tools such as

AutoCAD, P3 and Timberline?

The results are shown in Table 2.2.



Table 2.2 A comparison of some of the major tools
Question 1 Question 2
AdvantageNet No. Manual retrieval Build-in Scheduling
Emerging Solutions Inc. Features. Plug-ins to other
tools
ActiveProject No. Manual retrieval Plug--ins to other tools
Framework Technologies
e-BuilderTM No. Manual retrieval Plug-ins to other tools
MP Interactive Corp
e-Project No. Manual retrieval Plug-ins to other tools
AEC Online Inc.
ProjectCenter No. Manual retrieval Plug-ins to other tools
Evolv Inc.
ProjectNet No. Manual retrieval Plug-ins to other tools
Blue-Line/On-Line Inc.
ProjectWise No. Manual retrieval Plug-ins to other tools
WorkPlace System Solutions


As shown in Table 2.2, most of the current Web-based applications are using

plug-ins to work with other software tools and they also tend to work with particular

software tools rather than use vendor independent solutions.

2.3.2 Limitations of the Current Web-Based Applications

One of the advantages of using the Web is that data or information can be

exchanged much more quickly and efficiently. However, the construction software

market has already been well structured and dominated by many well-known brands and





32


numerous small companies. It is very unlikely that one company is able to dominate the

whole market; therefore, establishing a standard for document exchange over the Web is

extremely important.

Table 2.3 shows some major categories of construction drafting and management

software companies and illustrates the large number of players in this market. Figure 2.6

shows the number of software tools by each of the major vendors in each category. Table

2.4 shows the major vendors in each of the categories. Data and information are obtained

from "A/E/C Systems The Magazine of Computer Solutions," autumn 1998.

Figure 2.6 and Table 2.4 may not illustrate the whole picture of the real world

because a lot companies and products may not have been included in the magazine. The

numbers and the tables simply try to show the idea that the construction related software

market has been fragmented by a large number of well-established companies. Therefore

it will be very unusual if one of them will be able to enter into all other AEC areas and

provide a software package that includes all kinds of applications. As long as no software

vendor can monopolize the whole AEC market, there is a chance that user software tools

may not be compatible.




Table 2.3 Categories of software companies
Category Meaning
1 CAD
2 Bidding, Estimating & Job Costing
3 Construction Management
4 Communication Networking
5 Financial & Accounting & Marketing
6 Engineering Document Management
7 Scheduling & Budgeting






33











55

50
50 44
S2 41
5 40 6
E 32
0
'%- 30
0

E 20
z 14

10 -__

0
1 2 3 4 5 6 7
Category

Source: A/E/C Systems The Magazine of Computer Solutions, Autumn 1998

Figure 2.6 Number of software companies in each category






34





Table 2.4 Major developers in each of the major categories
Software Tools Major Developers

CAD Argos Systems, IncAutodesk, Inc., Bentley System, Inc.,
Building Blocks, Inc., CADMAX Corp, DataCAD LLC
Bidding, Estimating & Bidtek, Building Systems Design, Inc., Computer Guidance
Job Costing Corp., Construction Data Control, Inc., Dexter + Chaney,
Grantlun Corp., ICARUS, Management Computer Controls,
Inc., McCosker Corp., Meridian Project Systems, Inc., Prosoft
Inc., The American Contractor, The Construction Link, Inc.,
Timberline Software Corp.
Construction Construction Data Control, Inc., Computer Guidance Corp.,,
Management J.D. Edwards World Solutions Co., Management Computer
Control, Inc., Merdian Project System, Inc, Shaker Computer
& Management Service, Inc.
Communication AEC Online, Inc., Blue-Line/On-Line Inc.,
Networking Emerging Solutions, Inc., Framework Technologies,
MP Interactive Corp.
Financial & Bidtek, Dexter + Chaney, Deltek Systems, Inc.
Accounting & McCosker Corp, Shaker Computer & Management Services,
Marketing Inc., Solomon Software, Inc., Timberline Software Corp., The
American Contractor
Engineering ACS Software, Inc., Altris Software, CYCO Intl.
Document Computerized Facility Integration, Inc., NMT Corp
Management
Scheduling & AEC Software, Inc., Data-Maxx Software System, Inc.,
Budgeting Emerging Solutions, Inc., Gcon, Inc., The Paragon Co.,
Primavera Systems, Inc.
Source: A/E/C Systems The Magazine of Computer Solutions, Autumn 1998





35




Put into the context discussed above, one of the limitations of the current project

management Web site approach is that most systems do not effectively solve the data

interoperability issue (See Table 2.2). Since different vendors may use different data

models, automation of document processing is still impossible even if everybody is on

the Web. For example, to process construction documents, a construction professional

usually needs to use non-shared project information as well. The non-shared project

information is often stored at least logically in different sources. Most of the current

project Web site approaches cannot handle this situation (see Table 2.2). Thus in this

case, the information fragmentation still exists because of the different locations of the

shared and the non-shared project information. In this research, the non-shared source is

also referred to as a local information source. Figure 2.7 shows the existence of such

fragmentation.

From Figure 2.7, one can see that once a document is received via the Internet

and opened by a Web browser, that document cannot be used directly to retrieve

information in the local information sources because the document received may be

prepared by another third-party system. Thus, in many cases, the document viewer has to

manually interpret the document and then go to local information system to retrieve

related information. This extra process is caused by the gap between the document

prepared by the third party application and the local information as shown in Figure 2.7.





36









Local Information -'
System Local
V ~ Information



Scr e ocue it GAP




Web Browser ocume t






TCP/IP




L ocurnme it




Figure 2.7 The existence of information fragmentation in the project specific Web site
systems





37




2.4 An Alternative Solution--Web-Based "Front-End" Integration


Based on the above discussion, it seems that an alternative strategy can be

achieved by focusing on two things, namely construction documents and "front-end"

integration, over the Web. Construction documents are not only the media for

presentation of construction information but also bridges for communication between

construction participants. Effective management of project documents is critical to the

success of any construction project. It is important to notice here that as far as integration

is concerned construction documents should be an integral part of the whole integration

strategy. Moreover, the use of construction documents as the core around which the new

integration strategy can be built will naturally lead to "front-end" integration. By doing

so, the alternative approach uses system-independent and vendor-independent neutral

information models at the "front-end" (at the input/output level). By using this alternative

strategy, it is possible to provide construction professionals with a more integrated

computing environment that the current project specific Web site approach cannot. This

alternative strategy is called Web-based "front-end" integration. Figure 2.8 shows the

concept of the Web-based "front-end" integration.

Comparing the difference between Figure 2.7 and Figure 2.8, it is apparent that

the system shown in Figure 2.8 has an additional piece dealing with the document and

related local information before the document is shown to a user in a Web browser. This

additional piece, called a "malleable frame," makes a construction document adjustable

according to the user's needs. Any system with a "malleable frame" will be called a





38


"malleable frame" system. The "malleable frame" is actually what the Web-based "front-

end" integration is all about.

2.4.1 A "Malleable Frame"

A "malleable frame" is a dynamic document template. Such a template will define

a generic structure of a particular type of documents so that document instances can be

generated according to different situations. In the Web environment, a "malleable frame"

differs from a traditional document representation in such a way that the components of

the documents are organized and represented in forms of various information objects that

are active, interactive and standardized. In other words, those information objects are

operable by different systems. For example, a change order may have information objects

such as the initiator(s), the recipient(s), the contents, the signatures, etc. To be operable

by different systems, the semantics of those information objects are known to all

involved computer systems so that they are able to respond directly to users' interactions

no matter where the systems are. For example, if a change order received changes the

size of a door, the content object of this change order may only have some text about

"XXX door," which is static. However, the "malleable frame" has the capability of

understanding the text "XXX door" appearing on this change order and relating it to all

other information objects related to this "XXX door" such as its drawings, its cost

information, its material information and so on. In this way, the user can manipulate

objects of a document effectively.






39






Local Information _--
System Local
Information


Malleable /
Scr e elated local
Frame .
e information
ocume t

I / / ocume it
Web
Browser J




STCP/IPnt




Eocumen it



Figure 2.8 The concept of the Web-based "front-end" integration





40




Such a dynamic document template has already existed in PC systems where the

computing environment is relative closed. In the Web environment, such a template has

to be standardized in terms of object semantics and it has to be system independent as

well so that a document instance generated by the template can be portable to another

system. Therefore such a template can also be regarded as a neutral document format.

2.4.2 A "Malleable Frame" System

Any system that incorporates a "malleable frame" to generate document instances

and interpret document instances is called a "malleable frame" system. There are two

types of malleability that a "malleable frame" system supports, namely vertical

malleability and horizontal malleability. Vertical malleability exists when a document

flows from one stage to the next stage i.e. a stage transition, the information objects

contained in the document are evolving and are getting re-organized. Vertical

malleability supports this change by automatically identifying, changing, managing and

juxtaposing information objects for the next stage. Horizontal malleability means that

information objects of a document can be used directly by users in order to produce other

information objects for the document of the next stage. For any document processing,

vertical malleability and horizontal malleability are complementary to each other.

2.4.3 Characteristics of the Web-Based "Front-End" Integration

Data Granularity

A "malleable frame" is based on the idea that it is more efficient and more

flexible if information can be accessed at a lower level of data granularity than the level

of a document. Traditionally, construction information is shared and accessed at the level





41


of a whole document rather than any level with smaller data granularity. This method of

sharing and accessing construction information results in some inconvenience when the

document user's real interests may be in the integration of pieces of information from two

or more documents. A better way is to look at a document from a different perspective. If

we look at a document as a container of different kinds of information objects, the

conventional documents can be generated dynamically in a real-time fashion by those

information objects. For example, a request for change order proposal (RCOP) is

composed of information objects such as the document title, the sender(s), the

recipient(s), the date, the content of document, attachments, and signatures. The change

order proposal (COP) contains additional information about pricing and scheduling while

most information objects remain the same as in the RCOP. Thus if the sharing occurs at

the information object level rather than the document, many information objects

contained in the RCOP and the COP such as the sender(s) can be reused to generate

RCOP or COP. Such reusability also indicates a low semantic level, meaning a system is

now able to understand each information object.

Effectiveness and Efficiency of Information Perception

The "malleable frame" is also based on the idea that if information can be

presented in a way that a viewer can easily relate the information to his or her

knowledge, experience, background and so on, the information can be understood more

easily.

As construction work progresses, as-built information is generated and stockpiled.

All information, as-designed information, as-built information, non-shared or any of the

combinations, is referenced frequently by different participants to support their decision-





42


making processes. The incentive for reference is triggered when uncertainty rises

(Weaver, 1949, Littlejoin, 1983, D'Ambra, & Rice, 1994, Cragan, & Shields, 1998), or

there is simply lack of information since information is a measure of uncertainty. In other

words, information is the number of messages required to completely reduce the

uncertainty in the situation (Littlejohn, 1983). One of the reasons that uncertainty may

rise is because project participants have different goals (Hendrickson, & Tung, 1989 and

Barrie, & Paulson, 1992) and the as-designed, as-built, or non-shared information may

not quite explain the alternatives to achieve their goals. So the project participants will

need extra information that may be from private sources or other sources.

The process to reduce the uncertainty is a series of interactive communication,

according to uncertainty reduction theory (URT) (Cragan, & Shields, 1998). The

communication can be between two people, or people and information sources. The

uncertainty is likely to be reduced more quickly if the information represented can be

related to a person's previous experience, knowledge, or expertise (Littlejoin, 1983,

Devite, 1985).

We can also look at the problem from another point of view, the "purposeful

state" theory (Ackoff, 1972). Information has three levels, the technical level, the

semantic level and the effectiveness level (Weaver, 1949). At the effective level,

"communication via message affects the system if it changes the 'purposeful state' of the

organism" (Littlejoin, 1983, p. 24). In other words, information may not be effective if it

does not support people to determine an alternative to their goals. Therefore, if

information from project information sources cannot support a participant's specific goal,

that information is not effective in this case. Since construction documents are containers





43


and gateways of project information, one way to reduce that possibility of ineffectiveness

is to make construction documents as malleable as possible to support the goals of

different project participants.

A Web-Based Approach

Faster information dissemination requires a better communication infrastructure.

Many studies and applications suggest using the Web as a medium to disseminate

information (Bentley, Horstmann, & Trevor, 1997, Bradbury, 1998, Walch, Leo, &

Antevy, 1998). The method of using the Web as a medium is not new to the construction

industry (Schriener, 1995a, b, & c, Turk, 1995, Fruchter, & Reiner, 1996, Liu, Stumpf, &

Chin, 1996, Brideges, 1997, Rojas, 1997). There are a number of compelling reasons to

use the Web as a communication medium (Lynch, 1996), one of which is that the Web is

a standard computing platform that is an ideal tool for the integration of data from

different systems.

2.5 Summary


Fragmentation of the construction industry in terms of the industry structure and

the construction process has been studied for a long time. Its negative effects on

electronic data exchange and electronic construction document management have also

been noticed and studied under the umbrella of CIC (Computer Integrated Construction).

Integration has been suggested as a way to overcome fragmentation. There are

two types of integration, technical and managerial. It is noticed that there is another layer

between technical integration and managerial integration, which is how data can be

effectively and efficiently accessed. In the construction industry, project participants rely





44


heavily on construction documents to get information. This indicates that construction

documents can be a focus of an alternative integration solution.

Technical integration has two strategies. One is that different systems share a

common model or common knowledge at low system level, which is called "back-end"

integration. The shared project information model approach that is implemented by a

shared database is a typical example. The other strategy, which can be called "front-end,"

is that different systems communicate through a common or neutral data format. They

may not share anything at the low system level. An example of such strategy is the IGES

(Initial Graphics Exchanges Specifications) translator.

In practice, the current project specific Web site approach with three different

types does not support integration of different software tools. This limitation greatly

discounts the advantages of Web-based applications since the Web is designed for

improving data interoperability.

Based on the context discussed above, an alternative integration strategy is

proposed. Relying on a "malleable frame" and accordingly a "malleable frame" system,

the alternative strategy focuses on applying the "front-end" integration to Web-based

construction documents. The following chapters will discuss details on building a

"malleable frame" and a "malleable frame" system, and testing the hypothesis.














CHAPTER 3
DEVELOPMENTOF A "MALLEABLE FRAME"

A "malleable frame" is basically the neutral format of a construction document.

In the Web environment, such a neutral format can be designed by using XML (eXtended

Markup Language) technology. Although it is not required by XML, a DTD (Document

Type Definition) is normally used to define the structure and tags of a document. With a

DTD, a certain type of document is thus defined. This chapter will discuss how to

develop such a neutral format for a Request for Change Order Proposal by using SGML

(Standard Generalized Markup Language) and XML technology.

3.1 A Brief Introduction to SGML and XML


3.1.1 SGML(Standard Generalized Markup Language)

SGML, Standard Generalized Markup Language, is an international information

coding standard. In 1978, an ANSI (American National Standards Institute) working

group (X3 J6) was formed to provide an unambiguous format for text interchange and a

markup language that would be sufficiently rich to permit any processing. In the early

80s this work was moved to ISO under a working group which is part of SC 18

(ISO/IECJTC 1/SC 18/WG8) whose work later resulted in the SGML standard (Van

Herwijnen, 1994).








45





46


One of the major advantages of SGML is the separation of document structure

and document layout. This advantage eventually makes SGML document portable among

different systems.

SGML uses tags to define information contained in a document. There are three

types of tagging schemas, namely format tagging, structure tagging, and content tagging.

HTML (Hypertext Markup Language) and XML apply format tagging and content

tagging respectively.

SGML has developed some formal methods for developing DTDs. This research

will use those methods to develop a DTD for the Request for Change Order Proposal.

3.1.2 XML (eXtened Markup Language)

Currently, most documents on the Web are stored and transmitted in HTML. As

mentioned previously, HTML is a sub-set of SGML (Standard Generalized Markup

Language) and its tags are for presentation purposes mainly. This makes HTML a simple

language that is well suited for hypertext, multimedia, and the display of text documents.

However, the limitations of HTML become obvious as well, where the semantics of a

document's content is concerned. Major limitations are extensibility, structure and

validation (Bosak, 1997, Microsoft Corporation, XML White Paper, 1998). The

limitations may now be removed by a new meta-language, XML, which was designed by

the W3C (World Wide Web Consortium) as the next generation open data format for the

Internet.

XML provides two major services. One is the syntax for document markup and

the other is the syntax for declaring document structure (St. Laurent, 1998). Such

services provide software developers with a neutral layer, or a neutral data format, that






47


can glue together heterogeneous data and applications, and provide end users with a

much richer set of Web applications for browsing, communication and collaboration.

Instead of focusing on the presentation of information like HTML does, XML

focuses on the semantics of information that is displayed, and separates the content of a

document from its presentation (St. Laurent, 1998, Microsoft Corporation, XML White

Paper, 1998, Sail, 1997). In this way, XML provides more user-friendly applications by

allowing users to tailor presentations according to their needs. This research will only

review certain topics that are related to this application. For details about those

specifications, please visit the W3C Web site at http://www.w3c.org/.

XML Specifications

Formally, XML has three specifications (Sall, 1997), XML 1.0, XML linking

language and XML style language (XSL). However, several other specifications related

to XML activities are proposed and recommended as well, such as the Document Object

Model (DOM) specification, XML namespaces, resource description framework (RDF),

XML data and XML vocabularies. Many of the specifications are still under

development. As of writing, the XML 1.0 and the DOM (recommended) are available.

The XML linking language and the XML style language are still at the working draft

stage and the proposal stage respectively.

XML Syntax

XML uses an EBNF (Extend Backus-Naur Form) syntax (XML Specification,

1997). An example of the syntax for the element's content is as follows:





48



content ::= (element I CharData Reference I CDSect I PI Comment)*


Figure 3.1 A sample of XML syntax

XML Document Markup

XML is a subset of SGML therefore the document markup is similar to SGML.

The purpose of the XML markup is to provide a universal method for describing data.

There are six kinds of markup that can occur in an XML document (XML Specification,

1997, Walsh, 1997): elements, entity reference, comments, processing instructions,

marked sections and document type declarations. Following are explanations of those

types of markup.

Elements. Elements are the most common form of markup. They are delimited by

angle brackets and in most cases used for identifying the nature of the content they

surround. Some elements may be empty in which case they have no content. If an

element is not empty, it begins with a start-tag, , and ends with an end-tag,

.

Elements may have attributes. Attributes are name-value pairs occurring inside

tags after the element name, e.g. . In this

example, a projectDocument element has an attribute of "type" with its value assigned to

"project manual."

Entity Reference. Some special characters such as "<" are reserved for markup. In

order to be able to use them in a document as content, there must be alternative ways to

represent them. In XML, entities are used to represent those special characters.





49


Comments. Comments in XML begin with "



& checklist & documentNotice & signature +)>
& others *) ) +>








































Figure 3.18 A DTD for a Request for Change Order Proposal






66