Yimin Zhu 1
ABSTRACT
Large-scale capital programs, often involving many concurrent projects with huge amount of investment, multiple years of planning, design and construction and thus great social and economic impact, bear many features of dynamic, or ad-hoc, collaboration mainly due to the fact that they have multiple, volatile yet collaborative organizations, as well as heterogeneous supporting information systems. In order to provide an integrated information base for decision support, many previous studies focused on a strategy of sharing a common semantic model among heterogeneous data sources. Such a strategy has many obvious benefits; however, it works only when it is possible for heterogeneous data sources to share the common semantic model. For collaborating systems that cannot share a common semantic model, a different strategy is needed. This paper, based on the theories and the principles developed in the computer science, discusses the concept of context and its potential applications to AEC (Architecture Engineering Construction)-related systems integration, the dichotomy of semantics and context, and a conceptual solution of using context to assist systems integration. Limitations and future studies will also be discussed.
INTRODUCTION
The vision of an e-society and cyberinfrastructure shows a highly integrated human-machine society with advanced machine intelligence to support complicated research, education and other types of activities. In the AEC (Architecture Engineering Construction) industry, concepts, as well as the practice, of virtual teams, e-engineering, collaborative engineering and similar kinds are transforming the fabric of the industry. For a long time, keywords such as “autonomous”, “distributed” and “collaborative” were often used by many studies when describing the future of this industry. On the other hand, those studies also acknowledged that fragmentation, i.e., geographical and functional fragmentation, was one of the major characteristics of this industry.
A typical large-scale capital project, often involving many concurrent sub-projects with huge amount of investment, multiple years of planning, design and construction and thus great social and economic impact as well, bears many features of dynamic collaboration mainly due to the fact that such a project has multiple, volatile yet collaborative organizations and is usually transient. Such business requirements put additional constraints on the information systems, which require the systems to be adaptive and scalable in many cases in order to deal with unexpected requirements from different participants of different projects (Zhu and Chen 2004). Similar observations are reported in the FIATECH Roadmap
1 Department of Construction Management, College of Engineering, Florida International University, Miami,
Florida, 33174; PH (305) 348-3517; FAX (305) 348 6255; email: zhuy@fiu.edu

documents, (e.g., http://www.fiatech.com). It is thus reasonable for this paper to assume that dynamic, or even ad-hoc, collaboration of autonomous systems with different types of heterogeneity is one of many collaboration forms that the AEC industry will adopt in the future.
MOTIVATION
Central to the integration problem is to resolve heterogeneity among data sources. Previous technical integration studies in the AEC domain focused more on sharing the semantics of data or processes, which was clearly reflected in existing literature on computer integrated construction (e.g., Fischer and Froese 1992 and 1996, Augenbroe 1994, Bjork 1994, Froese and Paulson 1994, Rezgui 1998). A natural step forward was the establishment of industry standards, such as IFC (Industry Foundation Classes) (e.g., http://www.iai-na.org). With such a strategy, heterogeneity among data sources was resolved prior to the occurrence of any integration instance.
However, if knowledge of heterogeneity is not available until the occurrence of integration, sharing a common semantic model becomes implausible. In those cases, heterogeneity needs to be resolved at run-time with an incremental process. Schema mapping, or schema matching, is one of the many techniques that have been well studied, reported and applied.
Motivated by the theories and the concepts of context in multi-databases and other related areas, this paper, looking away from sharing data/process semantic models or the mapping approach, will discuss the idea of a dichotomy of semantics and context so that heterogeneous applications can share context, as well as semantics. With semantic models supporting business applications and context models describing semantic models for integration, it is reasonable to infer that context models can be more sharable than semantic models. Furthermore, if sharing happens at the terminological level (Kashyap and Sheth
1996) rather than the entire context model, the idea becomes even more irresistible to integration studies.
NOTION OF CONTEXT
Context information may not be critical until interaction happens because context, as an additional constraint to data used in integration, becomes indispensable for other systems to correctly understand and interpret the data of another system. Although recently there have been some studies using the concept of context in AEC-related applications for various purposes (e.g., applying individual and team context to facilitate knowledge elicitation and sharing during design (Brézillon, 2003), a high-level context model associated with a workflow task (Zhu and Augenbroe 2004), and the application of context-aware system in
AEC (Menzel et al. 2004)), the concept is still in its infancy and has not been fully investigated or understood in the area of supporting integration for AEC systems.
On the other hand, the concept of context is well studied and established (Brézillon and
Pomerol 2001) in many areas of computer science. A review of existing literature shows that context has played an important role in a number of domains for a long time such as NLP
2

(Natural Language Processing) (e.g., Moore1995), database integration (e.g., Goh et al. 1999;
Firat et al. 2002), communication (e.g., Mittal and Paris 1995), electronic documents (Boy
1995) and so on. Recent studies on pervasive computing have also extensively used the concept of context (e.g., Dey et al. 2001).
According to the notions of context in multi-databases, context, a possibility to describe data semantics, is defined as “meta-data related to its (data) meaning, properties (such as its source, quality and precision), or organization” (Sciore et al. 1994); “the key component in capturing the semantics related to an object’s definition and its relationship to other objects”
(Kashyap and Sheth 1996); or “additional constraints or assertions with reference to the domain model (Goh et al. 1999).”
POTENTIAL APPLICATIONS OF CONTEXT FOR SYSTEMS INTEGRATION
In the following section, this paper will discuss a conceptual solution of applying context to solve integration problems. However, this paper will assume that context knowledge is known. Mechanisms of generating and managing context knowledge will not be discussed in detail in this paper.
T ECHNICAL I NTEGRATION
As discussed in previous sections, integration is to resolve heterogeneity in different databases. In general, heterogeneity has two different types, i.e. structural heterogeneity and semantic heterogeneity (e.g., Kashyap and Sheth 1996). Structural heterogeneity means that different information systems store their data in different structures. Semantic heterogeneity refers to the contents of an information item and its intended meaning. Semantic heterogeneity is caused by mainly three factors (Goh et al. 1999), including

Confounding conflicts - occurring when information items seem to have the same meaning, but differ in reality, e.g., owing to different temporal contexts;

Scaling conflicts - occurring when different reference systems are used to measure a value. Examples are different currencies; and

Naming conflicts - occurring when naming schemes of information differ significantly. A frequent phenomenon is the presence of homonyms and synonyms.
More specifically, research (Friat et al. 2002) on financial systems reported that there existed three types of heterogeneity:

Data level heterogeneity – This type of heterogeneity occurs when the same entity uses different representation format in different data sources. For example, two different systems may use different units, scales, or format for the same entity with the same definition, i.e. a project budget of $3,000,000.00 in one system and $3 M or $3 M (2004) in another.

Ontological heterogeneity - This type of heterogeneity happens when databases differ in entity type definitions or relationships between entities. In addition, other types of ontological heterogeneity have also been identified such as using different ontology languages.
3


Temporal heterogeneity – This type of heterogeneity is subject to the fact that some types of entity values are related to time or time intervals. For example, cost and financial data may be collected and reported based on different time intervals, weekly vs. monthly or quarterly. In addition, the definition of an entity may change over time.
A context model needs to be able to describe those different types of heterogeneity associated with application specific semantic models.
C ASE S TUDY
Figure 1 illustrates a simple but typical integration problem. There are three heterogeneous data sources, Product, Schedule and Cost. In the example, we see naming problems, e.g.,
“Address” in the Schedule vs. “Add” in Product, and ontological heterogeneity, e.g.,
“Company” in Schedule vs. in Product. The most challenging part is to infer that there are, for example, relationships among “Product”, “CostItems” and “Activities” of different data sources, which may not be explicitly defined in any of those data sources.
Figure 1: An Example of Heterogeneity in AEC-Related Data Sources
The example also shows that each of the data model can sufficiently support its own domain of application. However, during the process of integration the heterogeneity needs to be detected and resolved. Context then provides a mechanism to describe such heterogeneity during the process of integration. For example, context can be used to describe semantic
4

equivalence between “Address” and “Add” in two different data sources, or the structural relationship between a product item in one data source and related schedule, or cost, information in another.
CONTEXT ONTOLOGY
Ontology as “agreements about shared conceptualizations” (Gruber 1994) plays a significant role in supporting semantic web and systems integration. Consequently, many forms of ontology languages, e.g., XOL (XML-based Ontology Exchange Language), OIL (Ontology
Interchange Language), DAML +OIL, OWL, have been developed to support ontological representations.
In addition, ontology has been used to represent context by many other studies. Some uses ontology to represent context, e.g., an OWL encoded context ontology, called CONON
(an extensible CONtext ONtology) (Wang et al. 2004); while others seek extensions to existing ontology language for specific purposes, e.g., ORL (OWL Rules Language)
(Horrock and Patel-Schneider 2004).
OWL becomes a W3C (World Wide Web Consortium) recommendation in the February of 2004. OWL, designed to support the vision of semantic web, is intended to enable applications to process information contained in documents. OWL supports the explicit representation of the meaning of terminologies and the relationships between those terminologies. OWL, as a revision of the DAML+OIL, has more facilities for expressing meaning and semantics than XML Schema, RDF, and RDF-S. Therefore, OWL becomes a more powerful language in its ability to represent machine interpretable content on the Web.
Since context is used for describing heterogeneity, a context model should include definitions of data sources and associated objects (, as well as their attributes) so that the heterogeneity among the objects, or their attributes, of different data sources can be identified during the process of integration. OWL has mechanisms to represent different types of relationships between ontologies, e.g., “equivalentClass” and property. “equivalentClass” can be used to tie a class definition in one ontology to another if their instances are the same but their definitions may be different. A property is a binary relation between two classes. With such mechanisms, we can develop a context model to describe heterogeneity among different types of data sources.
The following is a simple illustration of the concepts discussed above. The author is also aware that there are many other related issues that are not addressed in the example.
In the example, three classes, “Schedule”, “Cost” and “Product” are defined first. Then the relationship of two classes, “Add” and “Address”, in different data sources are defined by using the “equivalentClass” definition; and the relationship between “CostItem” and
“Activities” is also defined. It needs to be stressed that the actual relationship between cost and schedule is much more complicated and yet to be elaborated. The example simple illustrates a concept.
5

…
< owl:Class rdf:ID
=“
Schedule
”/>
< owl:Class rdf:ID
=“
Cost
”/>
< owl:Class rdf:ID =“ Product ”/>
...
< owl:Class rdf:ID
=“
&Product; Add
”>
< owl:equivalentClass rdf:resource
=“
&Schedule;Address
”/>
</ owl:Class >
...
< owl:ObjectProperty rdf:ID
=“
RelatedCostScheduleitems
”>
< rdfs:domain rdf:resource
=“
#CostItem
”/>
< rdfs:range rdf:resource =“ #Activities ”/>
</ owl:ObjectProperty >
..
Figure 2: A Simple Illustration of a Context Model
Figure 3: A High-Level Architecture of a Conceptual Solution
CONCEPTUAL SOLUTION
Figure 3 shows a high-level architecture of a conceptual solution. As illustrated, the architecture allows each individual data source to maintain its autonomy while resolving their heterogeneity by establishing and using context models during an integration process.
Although this paper does not discuss at all the generation of context knowledge, based on
6

training data sets (issued queries), it is possible to utilize data mining processes (Shyu et al.
1999 and 2000) to generate parts of a context model; while other parts can be generated by using expert domain knowledge.
One of the major components of the architecture is the context services, which provide a set of access points to the context knowledge base. If a context model is defined for the purpose of systems integration for capital projects in AEC, the context knowledge is accessible via context services similar to those defined by using Web Services, or software components. A broker, a software agent, takes a query from a user application, determines the sources where data/information can be retrieved, as well as associated context knowledge, retrieves the data/information from various sources, and provides answers to the user application. The architecture shown by Figure 3 only includes some major elements for the purpose of this discussion. Further studies are needed to elaborate the details of the architecture.
CONCLUSION
This paper argues that dynamic, or ad-hoc, collaboration is one of the many collaboration forms that the AEC industry may adopt in the future, which further indicates that the information systems supporting such collaboration are very likely to remain their autonomy throughout the collaboration process. Consequently, resolving heterogeneity among different data sources of those systems at “run-time” becomes a critical issue.
According to the strategy of sharing a common semantic model strategy, heterogeneity is resolved during design time, such as using the IFC model. This paper follows a different strategy in that heterogeneity among data sources are detected and resolved progressively. In this way, dynamically collaborating systems, which may be difficult to follow standards at design time, can still enjoy the benefits of having integrated product information with associated cost and schedule data in a manageable and controllable fashion.
REFERENCES
Augenbroe, G. (1994). “Integrated Building Design Systems in Context of Product Data
Technology.” Journal of Computing in Civil Engineering . 8 (4) 420-435.
Björk, B.C. (1994). “RATAS Project – Developing an Infrastructure for Computer-Integrated
Construction.” Journal of Computing in Civil Engineering , 8 (4) 401-419.
Boy, G. (1995). “Design Rationale and Supportability: An Agent-Oriented Corporate
Memory Approach.” Proc. Intl. Workshop on the Design of Cooperative Systems .
Brézillon, P. and Pomerol J.-Ch. (2001). “Modeling and Using Context for System
Development: Lessons from Experience.” Journal of Decision Systems . Humphreys,
P. and Brézillon, P. (Eds.): Decision Systems in Actions, Vol. 10, No. 2, pp. 264-288.
Brézillon, P. (2003). “Individual and Team Contexts in a Design Process.”
Proceedings of the 36th Hawaii International Conference on System Science .
Dye, A.K., Salber, D. and Abowd, G.D. (2001). “A Conceptual Framework and a Toolkit for
Supporting the Rapid Prototyping of Context-Aware Applications.” Human-
Computer Interaction , 16 (2-4) 97-166.
Fischer, M. and Froese, T. (1992). “Integration through Standard Project Models.” CIB 78
Workshop , Montreal, Canada.
7

Fischer, M. and Froese, T. (1996). “Examples and Characteristics of Shared Project Models.”
Journal of Computing in Civil Engineering , 10 (3) 147-182.
Firat, A., Madnick, S. and Grosof, B.N. (2002). “Knowledge Integration to Overcome
Ontological Heterogeneity: Challenges from Financial Info. Systems.” Proc. ICIS-
2002 .
Froese, T. and Paulson, B. (1994). “OPIS, an Object-Model-Based Project Information
System.” Microcomp. in Civil Engrg.
, 9:13-28.
Goh, C.H., Bressan, S., Madnick, S. and Siegel, M. (1999). “Context Interchange: New
Features and Formalism for the Intelligent Integration of Information.” Journal of
ACM Transactions on Information System . 17 (3) 270-291.
Gruber, T. (1994). “Toward Principles for the Design of Ontologies Used for Knowledge
Sharing.” IJHCS , 43 (5/6) 907-928.
Horrocks, I. and Patel-Schneider, P. (2004) “A Proposal for an OWL Rules Language.”
Proceedings of the 13 th
International World Wide Web Conference , ACM.
Kashyap, V. and Sheth, A. (1996). “Semantic and Schematic Similarities between Database
Objects: A Context­Based Approach.” VLDB Journal , 5 (4) 276-304.
Menzel, K., Keller, M. and Eisenblätter, K. (2004). “Context Sensitive Mobile Devices in
Architecture, Engineering and Construction.” ITCon , 9: 389-407.
Mittal, V. O. and Paris, C. L. (1995). “Use of Context in Explanations Systems.” Intl. J. of
Expert Systems with Applications , 8 (4) 491-504.
Moore, J. D. (1995). “Participating in Explanatory Dialogues. Interpreting and Responding to
Questions in Context”, A Bradford Book, The MIT Press, Cambridge, MA, USA,
Series Natural Language Processing.
Rezgui, Y., Cooper, G., and Brandon, P. (1998). “Information Management in a
Collaborative Multi-actor Environment: The COMMIT approach.” J. of Computing in
Civil Engineering , 12 (3) 136-144.
Sciore, E, Siegel, M and Rosenthal, A. (1994). “Using Semantic Values to Facilitate
Interoperability among Heterogeneous Information Systems.” ACM Transactions on
Database Systems , pp. 254-290.
Shyu, M.-L., Chen, S.-C., and Kashyap, R. L. (1999). “Discovering Quasi-Equivalence
Relationships From Database Systems,” Proc. ACM 8 th
Intl. Conf. on Information and
Knowledge Management (CIKM'99), pp. 102-108, Kansas City, MO, USA.
Shyu, M.-L., Chen, S.-C., and Kashyap, R. L. (2000). “A Probabilistic-Based Mechanism for
Video Database Management Systems,” Proc. of IEEE Intl. Conf. on Multimedia and
Expo (ICME'00), New York City, USA.
Wang, X.H., Tao, G., Zhang, D.Q. and Pung, K.H. (2004). “Ontology Based Context
Modeling and Reasoning Using OWL.” Context Modeling and Reasoning Workshop at PerCOM .
Zhu, Y. and Chen, S. (2004) “A Conceptual Framework of Ontology-based Scope
Alignment.” Proc. 2 nd LACCEI Intl. Latin American and Caribbean Conference for
Engineering and Technology (LACCET’2004), “Challenges and Opportunities for
Engineering Education, Research and Development” Miami, Florida, USA.
Zhu, Y. and Augenbroe, G. (2004). “A Reference Model for Supporting Inter-Organizational
Information Process Integration”, under review by Automation in Construction .
8