Facilitating distributed collaboration in the AEC/FM sector using Semantic Web Technologies

(1)

Facilitating distributed collaboration in the AEC/FM sector

using Semantic Web Technologies

Citation for published version (APA):

Beetz, J. (2009). Facilitating distributed collaboration in the AEC/FM sector using Semantic Web Technologies. Technische Universiteit Eindhoven. https://doi.org/10.6100/IR652808

DOI:

10.6100/IR652808

Document status and date: Published: 01/01/2009 Document Version:

Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers) Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website.

• The final author version and the galley proof are versions of the publication after peer review.

• The final published version features the final layout of the paper including the volume, issue and page numbers.

Link to publication

General rights

Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

• You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement:

www.tue.nl/taverne

Take down policy

If you believe that this document breaches copyright please contact us at:

openaccess@tue.nl

(2)

Facilitating distributed collaboration

in the AEC/FM sector using

Semantic Web Technologies

PROEFSCHRIFT

ter verkrijging van de graad van doctor aan de Technische Universiteit Eindhoven, op gezag van de rector magnicus, prof.dr.ir. C.J. van Duijn, voor een

commissie aangewezen door het College voor Promoties in het openbaar te verdedigen

op maandag 29 juni 2009 om 14.00 uur

door

Jakob Beetz

(3)

Dit proefschrift is goedgekeurd door de promotor: prof.dr.ir. B. de Vries

Copromotor:

(4)

Facilitating distributed collaboration

in the AEC/FM sector using

(5)

A catalogue record is available from the Eindhoven University of Technology Library

ISBN: 978-90-6814-618-9

NUR: 955

Cover design by Ton van Gennip

Printed by the Eindhoven University Press, Eindhoven, The Netherlands Published as issue 134 in the Bouwstenen series by the Faculty of Architec-ture, Building and Planning of the Eindhoven University of Technology © Jakob Beetz, 2009

All rights reserved. No part of this document may be photocopied, repro-duced, stored in a retrieval system, or transmitted in any form or by any means wheter electronic, mechanical or otherwise without the prior written permission of the author.

(6)

Chapter 1 Introduction

The aim of this thesis is to contribute to the ongoing eort to make com-munication among practitioners in the building and construction industry more ecient using computers. While more general forms of communica-tion such as spoken and written natural language have been assisted with modern technologies such as telephone and e-mail, one of the traditional means to transport information between participants in the building and construction industry the drawing has not undergone many changes in the past. The use of computers has added eciency and precision to producing, revising and managing drawings. With the advent of Computer Aided Design (CAD) systems since the days of Sutherlands' Sketchpad the speed and precision of creating blueprints as semiotic devices to commu-nicate future artifacts of the built environment to both oneself and more importantly other stakeholders in the process of their physical creation, use and demolition have been increased dramatically. However, the primary target of all drawings still remains the human interpreter. Only through his interpretation of commonly-agreed denominators is a set of lines be-coming walls, windows and slabs. Many attempts of teaching computers to understand the semantics of two- or three-dimensional drawings have not (yet) led to successful implementations; most software applications for the support of designers and engineers are blind. To leverage the power of computational tools, these otherwise hidden semantics of multi-dimensional building product models have to be made explicit.

Every software tool has an internal model that captures the relation and intended use of varying types of data making it viable for this partic-ular artifact of information technology. The process of transforming such an information model from one system into another is a complex, work-intensive task for both end-user practitioners and software developers. It is this transfer of data from one context to another that creates the high

(11)

friction in information exchange in the building and construction eld.

1.1 Motivation

Many excellent computational methods implemented in computer tools ex-ist that support the multitude of design and planning tasks in the various elds of engineering that have to be orchestrated to design, construct, use and dispose buildings. However sophisticated these tools are in their respec-tive specic domains with regards to modeling, calculation, simulation, the creation of written and drawn information or the support for decision mak-ing, they will ultimately be limited in their scope. There are two reasons for this:

1. Each human domain expert is only able to master a certain eld of expertise. Only from the synergetic eects of collaborative eorts will the larger problem or engineering challenge be solved.

2. Computational tools should be built to support this expertise of a single user to suit his or her specic needs to solve an explicit sub-problem at hand. Large integrated packages that cover all aspects seem not to be feasible for sheer quantitative reasons.

As a result, it is thus imperative for these various small special purpose tools to work together: To take the (intermediate) results of one expert's work supported by a specic application, process them according to their purpose and hand them over to a next expert using yet another tool more often then not in a non-sequential, concurrent mode of operation.

The infamous analogy provided by Hannus et al of the plethora of loosely connected computational tools that stick out in the global sea of building and construction as Islands of Automation has been the reference metaphor for generations of researchers and developers in the eld of interoperability (Hannus et al.,1998). The consequences from this lack of adequate interop-erability among the existing computer support tools are manifold in both qualitative and quantitative aspects:

On the one side, the friction in collaboration amongst the various stake-holders inevitably leads to a loss in the overall quality of the nal result the building. In the worst cases this has very severe impacts such as struc-tural integrity errors. But also less dramatic deciencies such as neglected optimizations for building energy consumption have serious implications on the well-being of individuals, the society and the environment.

(12)

On the quantiable side, the report of the American Institute for Stan-dards and Technology (NIST) by Gallaher and Chapman gives some alarm-ing insight in the nancial consequences of interoperability inadequacies in the building sector: They conservatively estimated the annual costs caused in the U.S. capital construction market alone (institutional, commercial and industrial facilities, and thus not including residential facilities) to be 15.8

billion USD (Gallaher et al., 2004).

To overcome these interoperability problems and their impacts on the sector, one of the most promising approaches in recent years was the cre-ation of a common Building Product Model (BPM) or Building Informcre-ation Model (BIM). The idea behind a common BIM is to unify the way infor-mation on buildings and their life cycle is modeled and stored in order to allow access to it from various parties using dierent software tools. This has the advantage that the mapping of information shifts from a many-to-many problem to a many-to-many-to-one problem. However convincing the idea in overcoming interoperability problems, new problems arise from it: In order to allow the many domains involved in the eld of building and construction to store their specic information aspects in the model, the integrated BIM has to accommodate a wide variety of concepts and their relations. As a consequence, such central BIMs tend to become very large and complex. The complexity and sheer amount of information not only makes it dicult for the creators and maintainers of the model itself to stay in control over its coherency. It also makes the creation of implementations of the model harder. Developers of domain-specic software applications have to nd their way through the model, extract the aspects relevant to their eld and the specic application purposes, and ensure that during the propagation of their information back into the central model, the integrity of seemingly unrelated information is not compromised.

To some degree, the reasons for both problem areas the creation and maintenance of a common complex BIM on the one hand, and its practical use in software implementations on the other hand can be found on the technical software-engineering layer used in current practice. Specically, the modeling means described in the ISO 10303, referred to as the STandard for the Exchange of Product data (STEP) including the EXPRESS family of modeling languages seem to be an obstacle in enhancing interoperability further in the eld of building and construction.

Although the eld of interoperability itself has many more aspects then solely software-engineering problems, considerable portions of the problem areas have been identied as problems of the various stakeholders in the eld to collectively adopt methods and technologies from other domains. In some regards, the interoperability approaches taken by software vendors

(13)

for the market of Architecture, Engineering, Construction and Facility Man-agement (AEC/FM) have become an isolated island themselves, detached from developments that were and are being made in other Information and Communication Technology (ICT) sectors.

The research conducted in the context of this thesis was done with the goal to study some of those ndings from other elds, evaluate their ap-plicability to the problems in AEC/FM and to contribute to the potential adoption of those of them, that have been identied as benecial by indicat-ing their advantages, short-comindicat-ings and open research issues to interested readers in both research and development communities.

1.2 Methodology

To approach the interoperability problems that have been identied in lit-erature and are analyzed in this thesis, methods from two main elds of research are evaluated and used in the approaches proposed:

In the broad eld of Articial Intelligence (AI) the specic sub-discipline of Distributed AI including Multi Agent Systems is of particular interest for the context of interoperability. With the aim to create eects of Emergence, small and autonomously operating systems perceive and manipulate an en-vironment using perceptors and eectors. For both their internal structure and the communication with other entities, a limited Universe of Discourse is represented using Knowledge Representation Systems. In this branch of AI, logic and in particular Description Logic, a subset of First Order Logic, can be used as a mathematically rigid method to unambiguously model the semantics of a domain of interest as an ontology. Using strategies such as Tableau algorithms these models can be reasoned about, with the inference of explicit information from implicit sources as its strongest characteris-tic. Of particular interest for the interoperability problems at hand are the new research eorts that use this possibility of reasoning on incomplete knowledge to partly automatize the connection of disparate, heterogeneous information sources referred to as the Open World Assumption in the larger context of the Semantic Web initiative. These eorts draw from well-understood methods of Semantic Networks and Frame Based Systems and combine them with model theoretic aspects to reach an integration of dis-tributed knowledge resources wrapped by services and accessed by software agents.

As a source for the creation of such logical semantic descriptive mod-els of the various engineering domains involved in the eld of building and construction, the research conducted here dwells on the rich ndings in

(14)

the eld of Building Product Modeling. Dierent approaches of structuring information and knowledge as the basis for both internal application mod-els and more importantly the exchange among dierent stakeholders are reviewed and evaluated. Various classications and models that have been conducted using Relational Databases Management Systems, Entity-Relationship-Models and the Object-Oriented Programing paradigm are in-vestigated for their conceptual underpinnings and whether these concep-tual intentions can be captured and transformed into more formal models of knowledge representation.

The synthesis of these two main areas of research is attained by a trans-formation of the currently dominating building product model designed for the exchange of information, the Industry Foundation Classes (IFC). Since this well-understood and established model covers many of the important domains in building and construction and combines conceptual notions from various earlier modeling eorts, the implications, advantages and limitations of shifting its methodological basis can be studied in depth and the ndings thereof can be generalized as a starting point for future research in the area.

1.3 Research questions

The questions that are addressed by the research conducted during this PhD project are:

How can we automate the very process of information exchange and integration among heterogeneous information sources?

How can we maintain a variety of domain sub-models in a distributed, heterogeneous and yet consistent environment?

How can we capture the knowledge necessary for meaningful automa-tized operations on domain-specic information in a machine-readable way?

How can we minimize the development work of integrating existing methods and legacy applications and their internal models and tools into the planning process for buildings?

1.4 Hypotheses

1. The distribution, manipulation, and maintenance of building product models can be facilitated and enhanced by applying methods from

(15)

the paradigms of multi agent systems and service oriented software development.

2. The modularization of complex computational tasks and interoper-ability processes into small, independent units reduces the complexity of and requirements for software development.

3. Complex building product models can be maintained more easily than currently practiced in standardization bodies when using methods from the knowledge representation systems domain that make use of strict logical semantics.

4. Distribution, generation of partial models, versioning and consistency issues that arise in heterogeneous collaboration environments can be addressed by using Semantic Web representations that have built-in networking capabilities such as the Resource Description Framework RDF.

5. Cooperating software agents are able to generate (missing) informa-tion by turning implicit knowledge into explicit knowledge by means of reasoning that otherwise would distract designers and engineers from their main tasks.

6. By relieving design experts from cumbersome interoperability tasks through agent systems, the willingness to make use of higher-level design and decision support systems rises and the overall quality of the designs will improve.

7. The exchange of design-relevant information between human domain experts can be improved by negotiating agent systems that act on their behalf.

8. Open world- modeling methods are more feasible for handling het-erogeneous and often incomplete information typically found in col-laboration in the building and construction sector than traditional closed-world modeling approaches in cases where incomplete infor-mation has to be dealt with.

1.5 Outcomes

The research conducted in this project shows the impacts of applying meth-ods from the elds of the Semantic Web to problems from the eld of BIM-based collaboration. As a proof of concept STEP-BIM-based domain models,

(16)

such as the IFCs and the ISO 12006-3 are transformed into a standard-ized, machine readable formal logic notation, the Ontology Web Language (OWL). The resulting ifcOWL and ifdOWL models cover both the stringent denition of the concepts and their relations amongst each other as well as the instantiated occurrences of these concepts that have been derived from models generated by legacy CA(A)D and building product modeling tools. Dierent conguration approaches for the generation of such models are being discussed and evaluated for their suitability in dierent scenarios.

On top of these models a range of operations for the completion of common tasks in planning and building are being carried out to demonstrate eects of using this approach in interoperability scenarios. They include

The integration of heterogeneous, distributed product catalogs through mapping against upper pivot ontologies;

The integration of legacy domain applications through semantically enhanced wrappers;

The extraction of partial model views through graph pattern matches by means of standardized queries and reasoning algorithms.

During these case studies a number of benecial and problematic aspects of operations with OWL models are investigated.

(17)

1.6 Guide to reading this thesis

The structure of this thesis is as follows:

1. In the second chapter the basic nature of what information and data is examined, followed by an introduction to the content specic to the eld of building and construction (what needs to be communicated) and to the state-of-the-art of how this information is currently cap-tured. In a third section the possible methodological and technical approaches to how this content can be communicated with ICT tools are being introduced.

2. In the third chapter existing approaches of building industry content structuring in the form of Building Product Models are being reviewed and evaluated. The second part of this chapter focuses specically on the conceptual and technological approaches of describing information and knowledge using Knowledge Based Systems.

3. The fourth chapter shows how the structuring of Building Product Models can be synthesized with Knowledge Based System into se-mantically richer information models.

4. The fth chapter demonstrates the use and added value of this synthe-sis in use case scenarios and focuses on specic aspects by providing practical examples.

5. An evaluation of the proposed approach along with outlooks to future work is given in chapter six.

(18)

Chapter 2 Collaboration and

Interoperability

In this chapter a general overview of the problems and existing solutions and research approaches in the eld of collaboration in the AEC industry is given. In a rst part the nature of data, information and knowledge is examined. The second half of this part is dedicated to the exchange of concrete instantiations of either one of them.

2.1 Exchange of information and knowledge

One of the basic problems in the design and manufacturing of complex technical artifacts such as building is the concurrent collaboration among the multitude of stakeholders that are involved in the process: Seen from the perspective of a designer, he or she has to transfer the mental image of a future building to the minds of several other actors involved (see 2.1 on the following page), that all have unique demands regarding the information necessary, e.g.:

The owner of the future building wants to get a general idea about the overall character of a design and some of its key performances (what is it going to cost, how many square meters will my oce have, how long will it take to complete the building?);

A domain expert such as a building energy performance expert needs detailed information about the geometrical and topological arrange-ments of building elearrange-ments and their materials as well as their at-tributes used in the nal design; the primary use of spaces and who the people are that occupy the space and what activities are performed by them;

(19)

???

Figure 2.1: Simple illustration of the the most basic question in collaboration in the building industry: How to transport a conceptualization of a future artifact (a building) in to the minds of other stakeholders involved in the process (such as owner, domain experts, construction workers) and minimize the loss of intended meaning? The traditional method to transport this mental image are plan documents

A construction worker needs information about the concrete size of walls, the type of concrete or brick that has to be used and the point in time his or her work is required within the overall schedule of the building erection;

In all three cases, the necessary information to be communicated be-tween the actors seems to concern the same future physical object

com-posed of tangible matter1_{: the building. However, even without taking into}

consideration that the object of interest does not even exist yet, it is a dif-cult task to come to a shared understanding between the actors, as each of them has their own concept of what a building is: To a bricklayer it is the result of stacking quantities of bricks upon each other. The energy consultant sees a house as a shell around comfortable climatic zones and the owner denes it as the source of monthly revenue from renting it out.

Yet, each one of them has learned to interpret the intended meaning of the word building as it is meant in a specic context during

commu-1_{Even the sheer concept of the existence of things might be interpreted dierently,}

(20)

Informatio n Source Transmitt er Receiver Destination Noise Source Message S ig n a l Message

Figure 2.2: Shannon and Weaver's information transmission model

nication. This knowledge is then used to carry out the tasks assigned in the common goal of transforming the conceptual design ideas into a phys-ical reality. Just like the word building is a signier for the concept it relates to, a wide range of other references to concepts is used through-out the design and planning task. In addition to this semiotic triangle (symbol symbolises

−−−−−−−→ concept refers to−−−−−−→ referent; symbol stands for−−−−−−−→

refer-ent) established by Ogden and Richards (Ogden and Richards, 1923), the

act of communication also involves the specic context and intentions by the speaker, resulting in meta-communication, as Watzlawick puts it:

every communication has a content and relationship aspect such that the latter classies the former and is therefore a meta-communication

which means that it is impossible to communicate without taking into

ac-count what the receiver of the message will make from it (Watzlawick et al.,

1967).

On the level of technical information transmission the problem of the

impossibility of loss-less communication has been shown by (Shannon and

Weaver, 1963): A sender encodes a message into a signal, sends it to the

receiver who in turn decodes the original message. In the process of trans-ferring the signal there will always be a source of noise that will interfere with the signal and hence modify it and therefore the message itself (see gure 2.1).

Another form of interpretation of dierent levels of meaning that is more relevant to facilitation of interaction between humans with ICT is the distinction of what is communicated and processed on the levels of data, information and knowledge.

(21)

Data is a collection of observations without a specic purpose or in-tention. Light being reected from an object in the world into the eye of an observer can be described in form of data, cap-turing its wavelength, location on the retina etc. It has no meaning unless there is a method of interpretation. The bits representing a line in a computer system that have been created by a specic application are not interpretable and identiable as a line by a computer system that does not have the informa-tion about the structure of the data model it has been created in.

Information is data put into a specic context and related with other data. From the data received by the retina and processed by the visual cortex, the source of light reection can be interpreted as an object of some nature. An informed application can interpret a stream of 256 bits as being four 8-byte blocks representing four double values on an axis in a coordinate system to compose a line. This information can be interrelated using systems like natural language or computer languages to form models. Knowledge is the learned ability how to operate with information.

While from an ICT perspective the classic concerns are often on a data level, the domain of interoperability issues is broader. Among the many classications of interoperability that have been suggested in literature, the denitions proposed by the European Interoperability Framework divide interoperability into three dierent aspects:

Organizational Interoperability. This aspect of interoper-ability is concerned with dening business goals, modelling busi-ness processes and bringing about the collaboration of adminis-trations that wish to exchange information and may have dier-ent internal structures and processes. Moreover, organisational interoperability aims at addressing the requirements of the user community by making services available, easily identiable, ac-cessible and user-oriented.

Semantic Interoperability. This aspect of interoperability is concerned with ensuring that the precise meaning of exchanged information is understandable by any other application that was not initially developed for this purpose. Semantic interoperabil-ity enables systems to combine received information with other

(22)

information resources and to process it in a meaningful man-ner. Semantic interoperability is therefore a prerequisite for the front-end multilingual delivery of services to the user.

Technical Interoperability. This aspect of interoperability covers the technical issues of linking computer systems and ser-vices. It includes key aspects such as open interfaces, intercon-nection services, data integration and middleware, data

presen-tation and exchange, accessibility and security services. (

ID-ABC,2004)

Although these three aspects cannot be separated to achieve full integra-tion of business processes in the building and construcintegra-tion industry and their related information exchange acts, the focus of this thesis lies on the Semantic Interoperability aspect of this denition. This specically con-cerns for example the multilingual, transnational, extendable and dynamic aspects of building product catalogues. For these, semantic interoperability means, that the context in which e.g. the attributes of a specic building component are interpreted might not be known beforehand (i.e. the name or the building regulations that apply in the country of its desired use). In the case of ifcOWL which is the main topic of chapter 4, semantic in-teroperability also enables the dynamic extension and more importantly its interpretation by applications of a BIM with new concepts and their properties that are more meaningful in the sense that other applications are being enabled to construct the propositional meaning of the representation

(Euzenat,2001) than the existing extension mechanism of IfcProxies and

IfcPropertySets (see 3.2.2 on page 42) which work only on the lexical and syntactic interoperability levels.

One of the most established denitions of interoperability is dened in

(ISO14258:1998, 1998) consisting of three main avors:

1. Integration all aspects of all participating systems are covered in a common model.

2. Unication a common meta-level structure exists that bridges and maps aspects of all participating systems

3. Federation without a common meta-level structure individual mod-els co-exist (possibly in dierent formats and languages) which cannot be bridged by a single meta-model, but rather mappings have to be made ad hoc.

Today, most interoperability scenarios in the building and construction do-main do-mainly consist of the federated (each application has its own model

(23)

and format and implements im- and exporters for other applications) and the integrated (e.g. the common model of the Industry Foundation Classes) approaches. For the existing federated interoperability solutions, the sheer amount of specialized domain-depended models and their software imple-mentations that play a role in AEC/FM makes n-n mappings unfeasible. This scale-related problem along with the current standardization process also constitutes a serious limitation in monolithic, integrated common

models (Katranuschkov and Scherer, 1996), as is discussed in section 3.2.2

on page 42. On the other hand, the IFC model can also be regarded as unifying pivot model that lays out a base structure and gathers commonly agreed parts such as units, relationship types and a generalized specializa-tion structure. What is missing from it in order fulll such a unifying role in interoperability scenarios are semantically rich extension mechanisms, that allow ner grained domain models that are not covered in an inte-grated sense to connect to existing structures and allows this connection in a modular, dynamic fashion. The aim of the transformation process illus-trated in chapter 4 is to ll this gap, by harnessing the semantic rigidnis of Description Logic modeling that can be distributed over interconnected sub-models.

By trying to transfer information from one internal representation model to another the meaning changes: The transformation process has to be formalized.

Capturing information and knowledge for the purpose of interoperability between dierent communication partners or ITC artifacts used by them can be done in dierent forms that vary in purpose and complexity. These are:

Dictionary Dictionaries provide at, ordered, non-hierarchical denitions for the use and context of natural language terms. Bilingual or multilingual dictionaries provide mappings of signiers of con-cepts from one language and culture system into another. The disambiguation of the terms in dierent contexts and their map-ping into another system are provided only by means of informal natural languages descriptions. Specialized dictionaries are

lim-ited to a specic domain (Mansum, 1959;Harris,2005; Wallnig

and Evered, 1978).

Taxonomy Taxonomies, also referred to as classications, are hierarchical inventarizations and categorization of a particular eld of in-terest most often along specialization/generalization axis, such as e.g. sliding door is-a door is-a opening cover is-a building element. Concepts are related amongst each other using is-a

(24)

relations. Brachman identies a range of dierent interpreta-tions of such is-a links that often have an ambiguous meaning

other than specialization/generalization (Brachman, 1983).

Partonomy While the hierarchical structure in a taxonomy is based on generalization/specialization relations of concepts, concepts in a partonomy are related using dierent part-whole relations. Examples of large-scale partonomies are medical models like

GALEN (Rector et al., 1994) that store structural anatomic

information e.g. ngernail partOf

−−−−→ nger partOf−−−−→ hand.

Ontology Ontologies are formal rigid descriptions of concepts in dierent contexts using a range of relations (or roles) including but not limited to generalization/specialization (or set/subset), mereonomic relations and quantications of variables. More-over, these relations are often specied further by restrictions, rules and constraints that are applied to the relations. Gruber provided the most well-established denition of an ontology as

an explicit specication of a conceptualization (Gruber,1993).

2.1.1 Communicating data, information and

knowledge in AEC/FM

The organizational form of building and construction projects is designed to be short-lived: A one-of-a-kind product (the building) is designed, engi-neered, constructed, used, managed and demolished by a number of dier-ent actors and stakeholders. Given the high numbers of parties involved in building projects, it is very unlikely, that the same constellation of actors will come together for a second project and even then, working conditions and (intermediate) results will dier from the previous time. To describe the character of such kinds of large-scale temporary business networks, the notion of Virtual Teams and Virtual Organization (VO) has been estab-lished in the mid-90's in the eld of economic research. It has received increasing interest in the building and construction industry and a number of works have been dedicated to feasibility studies, prototype architectures

and the identication of crucial factors for the domain (Mowshowitz, 1997;

Zarli et al., 2002; Lai et al., 2003; Gehre et al., 2005,2007).

The importance of eective Computer Supported Cooperative Work (CSCW) in engineering in general and specically in the building and con-struction industry cannot be underestimated.

(25)

1:I would like to change the size of this room Will your HVAC unit still fit in?

PDB 3:

Yes but +10dB

2: Query: Same Specs but max size 2x3x4m ? 4:

Yes but it’s +10 dB

Regulations DB 6: No 5: Sound insulation satisfactory? 7:

Ok, we leave it unchanged Architect

HVAC Mech. Engineer

Figure 2.3: Motivating example of assisted collaboration

Following the classic taxonomy of groupware provided by Ellis et al.(Ellis

et al.,1991), two dierent categories of collaboration can be identied: 1. Asynchronous collaboration, where persistent information is captured

and encoded as text, drawings, images, video and multi-media mix-tures thereof. This information is distributed among the relevant stakeholders in project teams for consumption and processing in a larger time frame. Often the disseminated documents have a legal status attached to it, rubber-stamping a certain stage in a project's baseline.

2. Synchronous collaboration, where members of project teams discuss and decide issues immediately. Such meetings may either be

co-located, taking place in traditional meeting room facilities con-necting team-members through shared physical spaces and may be supported by technical equipments such as electronic white-boards;

(26)

distributed connecting participants through technical means such as telephone, instant messaging, teleconferencing or virtual col-laboration rooms.

In synchronous collaboration forms, human factors such as discourse strategies play a much bigger role and have been studied extensively. The goal of all collaboration support is to pool knowledge existing on three dierent levels ((a) individual, (b) group, i.e design team, company, (c) expert domain) to reach a common goal: the solution of a specic problem somewhere at some stage in the life cycle of a building. To support this knowledge sharing task with computer applications, a number of problem areas have to be tackled:

The knowledge has to be captured in a machine-readable way. On more general levels such as a complete domain of expertise in an engineering eld, or a fraction thereof this seems partially feasible using knowledge representation methods focused upon in later sec-tions of this thesis.

From this captured machine-readable knowledge, partial subsets have to be generated. Just like in human communication between speakers with dierent knowledge background, the amount of knowledge to be transferred has to be restricted to a bare minimum level that allows the achievement of a goal (To bring an argument forward, getting onto the same page is essential). The most dicult task here is to anticipate the knowledgeability of the receiver in order to avoid overhead or underspecication. In this early phase before any data actually travels between the participants a rst mapping of what the sender of a message believes to be the level of knowledgeability of the receiver has to be made.

The extracted knowledge has to be encoded in messages that are decodable by the receiving party, i.e. a mutual syntax and grammar have to be found.

One of the essential obstacles common to all these forms of collaboration are the various issues in human communication identied in the eld of general communication theory. One crucial dimension identied is the an-ticipation of the dierent views and aspects of information that needs to be transferred, and the according adaption of the communication initiator to choose the information intended for transfer. Practical approaches to solve this will be discussed in chapters 5 and 6.

(27)

* * * * * * * * * *

Figure 2.4: Decentralized project communication based on the exchange of information artifacts in les

2.2 ICT supported communication in the

Building and Construction Industry

2.2.1 Document-based methods

In traditional collaboration settings in design and engineering most infor-mation is captured and distributed among stakeholders in the form of docu-ments. Many of these documents are of the usual kind that are exchanged in most other business areas as well: text-centered documents (letters, ten-der documents, contracts, invoices etc.); number-centered documents such as spreadsheets; illustrative documents such as owcharts, photos of prod-ucts etc. In addition to these usual set of information conveyors special kinds of documents play a central role in Building and Construction (B&C) and other engineering elds that are rarely met in other domains:

Sketches Manually crafted, brief and often coarse depictions of some

aspects of planning with dierent levels of abstraction rang-ing from schematic room layouts to three-dimensional ren-derings of building element details. They are most often used in early design and planning stages or in meetings as quick informal communication devices.

Line drawings Orthogonal projections of future artifacts using a set of well-established symbols for simplication (double-line = win-dow, quarter circle = door etc.). Additional information

(28)

such as the precise dimensioning, qualitative aspects of ma-terials etc. are often included in form of legends embedded into the line drawings. The complexity and impact of the unique role of technical drawings (or conscription devices

(Henderson, 1995)) play in all stages of design and

engi-neering have been thoroughly studied by (Ferguson, 1992),

(Henderson,1999), (Belofsky,1991).

3D geometry Rather new in B&C practice (but well established in other engineering elds), is the exchange of documents that in-stead of (or in addition to) the canonical set of two-dimensional projections and sections carry a three dimensional represen-tation of the information to be communicated. Today the majority of geometric models is still created after and on basis of the two-dimensional line-drawings to fulll special purposes such as the creation of visualizations. However, a slow shift of the industry towards giving such models a more central role can be observed. It is important to notice that this use of three-dimensional geometric and topological data is not to be confused with full-edged BPMs, which are discussed more in-depth in Chapter 3.

Of these document types, a vast number is produced during building projects. Not too long ago, all of these documents where generated using computer systems and were then distributed among the actors in the project as hard-copies via regular physical mailings. But even with electronic mail as a streamlined method of document distribution, the organizational form of the collaboration just switched its medium: In Building projects ICT helps organizing e-mail distribution lists, calendaring and scheduling, but in the end, despite all these advances, the same amount of printed paper is

gen-erated as 20 years ago2_.

An additional dimension of document-base information exchange in col-laboration settings are the temporal aspects of documents: Dierent ver-sions of the same documents may oat around in the virtual collaboration space without a clear overview of who has which version. Although mile-stones in the planning processes are scheduled to establish common grounds, it are often the changes that occur between these milestones and have not been communicated to important stakeholders that lead to mistakes.

2_{Two major technological decits are left out of the consideration here: The}

mo-mentary lack of adequate replacements for paper as a device for reading and the lack of technological equivalents for signatures in the legal scope.

(29)

Groupware

Addressing these two latter issues the transfer of documents among actors and versioning control collaboration tools have been developed, that put central document repositories at the disposal of project participants. These groupware systems ensure that current and past versions of documents are available to all relevant stakeholders. As the dissemination of documents is no longer controlled by simple inclusion of relevant stakeholders into distri-bution lists, the control of information ow is regulated by rights manage-ment to the access of les in the repository. Commercial implemanage-mentation

of such systems targeted at the building and planning sector3 _{dier only}

slightly from the general purpose solutions by adding e.g. visual mark ups in documents or assistance in cross-referenced drawing documents. Most importantly they are often specialized on proprietary formats that enforce the use of specic software products among all actors, preventing their use in heterogeneous VOs and are thereby often only feasible for in-house teams. Most of these documents directly of indirectly refer to the same future physical artifacts. These references however only exist in the realm of hu-man interpretation. Only very little of these references are made explicit enough to be processed in a semi-automatic fashion by computer applica-tions: To a computer system, a statement about windows type W31 in bathrooms on oor three in building section C made in a tender document has no relation what so ever to the two lines representing it in a drawing.

2.2.2 Central Product Model Servers

To overcome some of the obvious shortcomings of le-based interaction among practitioners using BPMs, the idea of central repositories has come up. Instead of repeatedly sending large model populations to multiple par-ticipants, the information is kept at a central place. Moreover, it is not distributed in various proprietary, application-specic les from the soft-ware packages involved in the process, but stored in open standard BPMs that facilitate the storage of all information required and produced by the various stakeholders. The actors in a building project are then able to ac-cess the current state of a project (check-out), modify and extend it and sent back (check-in) their contributions to be share with others. For the building and construction domain such a model server tailored for the use

of IFC models has been created in the SABLE project (Kiviniemi et al.,

2005; SABLE, 2002), and a few commercial implementations of general

purpose product model servers are available. Providing interfaces like the

(30)

Figure 2.5: Centralized project information communication, e.g. via model-servers.

Standard Data Access Interface (SDAI) specied in the STEP initiative or

the EXPRESS query language (ISO 10303-22:1998, 1998), model servers

allow the persistent storage and retrieval of product model data in a cen-tral repository. The low-level access provided by general purpose model servers however demands a high amount of development work to access do-main specic content or views (extract all walls with their material information) in the building an construction industry. The contribution specically valuable in the SABLE project was to provide a higher-level interface that directly related to the information needs of specic actors in all stages of the building model life cycle by providing a wrapping layer above generic model-servers and providing RPC and SOAP interfaces to it (see 2.2.4).

However useful the approach of centralized model servers, a number of issues remain unsolved:

The quality of information stored in the repository is depended on the underlying BPM.

Versioning of huge and complex building models with a number of dierent contributors in concurrent settings is a dicult task. Con-tributions in the eld of version management for STEP based model

have been made by Weise (Weise et al., 2004; Weise, 2006)), and

(31)

Data repositories of model servers are only a part in a complex chain of interaction between project participants.

2.2.3 Information exchange as a process

In complex network settings, information infrastructures are needed for the ecient use and maintenance of a multitude of interdependent software components. Several approaches have been developed and implemented that will be introduced in the following sections.

2.2.4 SOA

Service Oriented Architectures (SOA) have surfaced in the software engi-neering domain especially in large enterprise environements to address the needs of exible, interoperable and just-in-time composable, networked IT infrastructures. The central idea is to provide interfaces to small re-usable modular software units that can be addressed by external modules using common standards. The connection of software entities across network structures and hardware platform boundaries has been designed and used by software engineers from the mid-70's already.

The simple idea is to nd a communication channel from an applica-tion A to an applicaapplica-tion B (that listens to that particular communicaapplica-tion channel) in order to have A call for some program code from B has made public via an interface. In order to specify which functions (or procedures in the case of applications that follow the Object-Oriented paradigm) are provided, how the calls are made and what kind of parameters have to be provided in order to receive a certain result, protocols have to be speci-ed. Over the years, a number of such protocols both proprietary (Remote

Method Invocation (RMI) in SUN's Java (Waldo, 1998), Microsoft's

Dis-tributed Component Object Model (DCOM) (Brown and Kindel, 1998))

and open (the CORBA specication by the Object Modeling Group (

Vi-noski, Feb 1997)) have been specied.

Prominent research projects in the building and construction domain that harnessed these technologies for distributed object models were the

series of projects starting with the COMBI eort (Scherer,1995) (see 3.2.1.6

for more detailed descriptions), the WISPER project (Faraj et al., 2000),

the OSMOS intitiative (Rezgui et al., 2001) and the SEMPER-II (Lam

et al.,2004) project.

One of these protocol standards, Dave Winer's XML-RPC (Winer,1999)

interface, wrapping procedure calls in simple XML tags evolved into the Simple Object Access Protocol SOAP. It received enormous attention from

(32)

developers, because it is relatively simple to implement and its messages are transported via the HTTP protocol. It has been standardized by the W3C, has a wide range of ready-to-use implementations in almost all popular programming languages and is the basis of many common day production-level enterprise systems in various areas.

SOAP has been criticized for its large XML content wrappers, the re-quired sophistication level and complexity of the necessary parsers and per-formance issues including the relatively small amount of data that can be

transported with it (Elfwing, 2002).

However, a standardized protocol to access functionality of another ap-plication or system of apap-plication still leaves a lot of manual work by human experts. In order to further minimize this manual work necessary for in-terconnection of inhomogeneous applications a mechanism is needed that documents the available functionality to a human expert and even better so in such a way, that the generation of code that allows the access to the external application can be automatized to some degree. For such de-scriptions of the functionality of the providing application, another layer of structured information is needed. In case of applications that provide their

functionality as a service over the Internet4_{, the Web Service Description}

Language (WSDL) has been developed. In a WSDL le, developers of web services capture information about:

the datatypes used as parameters and return values, dened as

arbi-trary XML Schema denitions5_;

the messages exchanged including their parameters typed in before; the operation I/O: either

receive a message and do nothing;

receive a message and send a res(VO)ponse as a result of an internal operation;

receive a message and send a standardized acknowledgment no-tication without specic contents

send out a request and wait for an answer

the binding, which species the concrete technical implementation.

4_{They can also be used in other kinds of network infrastructures based on http,}

including intranets and special purpose inter-enterprise networks.

5_{These are either wrapped inline in the interface le itself or at another location}

(33)

Today many helper applications (in form of IDE plug-ins, wizards etc.) exist that help developers to generate the necessary WSDL document from the existing source code of a service.

A service written and documented to the outside world using WSDL can then be registered in central telephone books using the Universal De-scription Discovery and Integration (UDDI). Adhering to the decentralized organization architecture of the Internet, special servers providing UDDI services gather these descriptions, categorized into white (contact), yellow (business) and green (technical specication) pages and make them search-able for other services. The vision behind these central registers is to ensearch-able software applications to discover and connect to new services spontaneously. In complex interoperability scenarios often more than a single bidirec-tional communication between a service provider and client is necessary. In-terconnecting several dierent services and managing their particular order of the invocation, the handling and forwarding of the required and gener-ated information is referred to as orchestration. Special modeling methods and languages exist to harmonize and standardize such orchestration. The most popular one in complex enterprise environements is the Business Pro-cessing Execution Language for Web Services (BPEL4WS). It consists of both an XML-based concrete syntax for the chaining, management and or-ganization of web services and of a specication for a graphical notation to facilitate easier composition and documentation of service orchestration. BPEL has been developed by the research labs of IBM and Microsoft and has been standardized by the OASIS group.

Even though (Web)Service Oriented Architectures are popular and suc-cessful there are a number of issues they are being criticized for:

The amount of human work necessary to make client applications connect to services is still high: In the current WSDL and UDDI im-plementations, there are no ways of describing the semantics of the information and the operations upon them: Using XML Schema to describe the datatypes the mere syntax of the information that enters and exits an application is dened, but not its meaning. The same issue applies to the UDDI, where the nature of the service advertised in the registry can only be interpreted by the natural language de-scription provided alongside the service or even worse by guessing the provided service by interpretation of the undocumented interface descriptions.

They are founded on pragmatic business needs and lack a sound the-oretic basis.

(34)

Agent

Environment

Effector Perceptor Reasoning

Figure 2.6: Model of an intelligent agent

2.2.5 The notion of agents

The interconnection of modular, intelligent applications has been a main area of research in the Articial Intelligence (AI) community for several years. In a sub branch referred to as Distributed Articial Intelligence (DAI), small modular software entities that inter-operate are considered to be Agents, which when working together form Multi Agent Sys-tems (MAS). They are distinguished from other forms of modular, object-oriented pieces of software by exhibiting degrees of autonomy and proac-tiveness. To characterize MAS and DAI systems, Weiss suggests:

DAI is the study, construction and application of multi-agent systems, that is, systems in which several interacting, in-telligent agents pursue some set of goals or perform some set of

tasks (Weiss, 1999, pg. 1)

Among the many denitions that have been suggested for agents over time

in literature (for an overview and classication see (Franklin and Graesser,

1997)), the denition provided by (Huhns and Singh,1998) is probably one

of the most agreed upon (albeit very broad) :

[Intelligent Agents are] active, persistent (software) compo-nents that perceive, reason, act, and communicate

The said autonomy of agents refers to the notion of entities that are designed to have a certain control over their own actions that is independent from other modules or human intervention. While classic programs and more specically services such as web services and their counterpart clients described in earlier sections, can be considered purely reactive artifacts software applications with a limited lifespan that are invoked by a triggering

(35)

mechanism, execute a task and wait for further calls autonomous agents act on a set of predened or dynamically generated goals.

In order to facilitate the communication among agents in larger agent societies a number of pre-requisites have to be met:

1. Single agents must be provided with a habitat, a software and hard-ware platform that allows them to execute their code.

2. Agents must be able to communicate among each other. A stan-dardized form of interaction must not only provide the syntactical, grammatical and semantic means to initiate and perform the commu-nication acts themselves (addressing, asking, answering, negotiating etc.). In addition specic languages for the content of the communi-cation must be dened.

3. Agents must be able to transform (parts of) their internal knowledge model to a common-ground language prole to be shared with other agents.

4. Some agent systems furthermore require the ability to physically travel from context to context, i.e. enabling them to move their code from one processing machine to another.

To provide an infrastructure for a standardized communication amongst agents, the Foundation of Intelligent Physical Agents (FIPA), now an IEEE standards committee was founded in 1995. Under its roof, existing MAS technologies where inspected, developed further and standardized. Its most important contributions to R&D are:

the development of a standardized Agent Communication Language (FIPA-ACL) that provides a set of basic communication acts including performatives (ask, query, inform, request, propose, agree, reject etc.); the development and standardization of a content language (FIPA-SL) and the integration of other existing languages such as KIF. Additionally the integration of ontology languages such as DAML, OIL, and OWL have been achieved;

the provision of a common, open source software framework and plat-form (FIPA-OS);

the provision of an interconnected network of machines providing FIPA-OS environments to be freely used among researchers (Agent-Cities).

(36)

Web services Multi Agent Systems

behavior reactive pro-active

orchestration /

choreography predened, BPEL agent-internal planning anddynamic through

goal acquisition strategies

environment Internet, WWW specialized, proprietary

platform

content models XML Schema KIF, FIPA-SL, OWL

communication

protocolls RPC, SOAP, WSDL KQML, FIPA-ACL

Registry UDDI DF

Table 2.1: comparison between Web Services and agents

Since the FIPA initiative is decoupled from other networks and constitutes some sort of parallel universe, a number of research and industry contribu-tions have been made to connect the platform to the outside world, such as (semantic) web services. Although the edges between the two worlds of web services and agent platforms begin to blur, there are a number of dif-ferences to keep in mind. A short overview of the main dierences is listed in table 2.1.

(37)

(38)

Chapter 3 Building Product Modeling

In this chapter dierent means of modeling buildings for the use in ICT systems are discussed and evaluated. The rst part is an evaluation of the methods, mechanisms and languages that have been used in dierent approaches and frameworks in the area of software engineering, product modeling and more specif-ically building product models. In this rst part the focus is on the methodological underpinnings of the tools (i.e. languages) and the consequences on the possible capabilities and shortcom-ings on the conceptual modeling process itself. The second part examines and evaluates the dierent approaches and initiatives of concrete formulation of models that have been documented in literature such as COMBINE, GARM, CIS, the STEP AEC do-main model and IFC. The third part introduces the reader to the notion of knowledge representation systems. This part will be more in-depth on the underlying techniques since it stems from research domains outside the traditional (building) product modeling community.

3.1 Means of product information modeling

In this section dierent languages and their underlying concepts are exam-ined. Their potential use, their advantages and shortcomings for distribu-tion in heterogeneous environments are evaluated.

3.1.1 The advent of modeling languages and

techniques in ICT history

In some regards one might say that the roots of many contemporary data modeling concepts, theories and practices go back to engineering problems.

(39)

The rst language to conceptualize the basics of Object Oriented Program-ming (OOP), Simula was introduced by Dahl and Nygaard sparked by the

necessity to do complex simulations for (military) ships (Holmevik, 1994),

(Dahl and Nygaard, 1966). In their work they coined the basic notions

of an object as a self-contained program (block instance), having its own local data and actions dened by a 'class declaration'" , and that of a class that denes a program (data and action) pattern, and object conforming

to that pattern are said 'to belong to the same class'" (Dahl et al., 1968),

subclasses and procedures which have since been used in many later OOP languages such as ADA, Smalltalk, C, C++ and Java.

Albeit much more focused on the practical application, one of

Suther-land's revolutionary ideas included in his Sketchpad development (

Suther-land, 1964), was the introduction of generosity and typed objects

The big power of the clear-cut separation of the general and the specic is that it is easy to change the details of specic parts of the program to get quite dierent results or to expand the system without any need to change the general parts.[. . . ] In the data storage structure the separation of general and specic is accomplished by collecting all things of one type together as chickens which belong to a generic hen. The generic hen con-tains all the information which makes this type of thing dierent from all other types of things. Thus the data storage structure itself contains all the specic information, leaving only general

programs for the rest of the system. (Sutherland, 1963, pp.

49-50)

Even though Sutherlands ideas of an object oriented CAD system was only a little more than a side-note on his specic implementation it is recognized as one of the earliest works to apply the notion of conceptual categorizations -here in the form of geometric gures and constraints applied to their layouts - to computer programming.

3.1.2 Database design and Entity-Relationship

Models

A separate stream of ideas for high-level data modeling stems from database theory, where the ever growing complexity of databases in the early years called for sophisticated abstraction mechanisms and modeling techniques. Codd's idea of a mathematical model of information by grouping sets of n-tuples and relating them among each other using unique keys as identiers

(40)

(and hence making them members of sets without duplications while the rest of the tuple could be arbitrary) allowed the creation of fast and ecient information storage and retrieval on a large scale using relational algebra

(Codd,1970). Values - called attributes - stored in the body of a table could

be retrieved by calculating the Cartesian product of the sets (columns) of n-tuples (rows).

The modeling means of these early implementations where the design of database tables and their interrelations which quickly grows out of hand when complex real-world systems such as buildings have to be mapped to computer programs. One of the groundbreaking works to overcome parts of the the complexity issues was done by Chen, who suggested an Entity-Relationship Model (ER or ERM) as a design tool to come from the con-ceptualization of real world phenomena to implementable database systems

(Chen, 1976). He suggested to begin the database design with a top-down

approaches beginning with the denition of conceptual 'things' that exist in our minds (the entities) and associations between them (the relation-ships). The method he introduced contained a clear path to come from these conceptual denitions directly to database table implementations that guaranteed consistent data modeling, storage and retrieval very near to the human way of thinking.

3.1.3 Graphical modeling aids: NIAM, IDEF1x,

GARM Hamburger Model

The growing gap between the complexity of information models that could be processed by machines on the one hand and the limited capability of human modelers to think in terms of tables, keys, joins and transaction operators such as INSERT, UPDATE and DELETE fostered the developments of higher level abstractions of these concepts. Apart from the branch of

text-based modeling languages1_{, a number of graphical means were invented to}

assist the developers of large systems. While an important part of Chens ERM work consisted of a graphical diagramming mechanism that allowed the easy depiction of structures to be put into a database, a variety of graphical notations was developed to even further improve the designability and readability of data structure designs.

One of the most widely used graphical modeling tools was Nijssens's

Information Analysis Method" (NIAM)2 ₍_{Nijssen and Halpin}_, ₁₉₈₉₎

intro-1_{Mappings into relational database schemas and operations upon them came much}

later and only recently gained momentum on a larger scale.

(41)

"Nat-duced by Nijssen in 1977, more often referred to as Object Role Modeling

(ORM) in recent literature (Halpin, 1998). Where Chen's diagramming

technique only consisted of a very limited set of symbols (boxes for entity sets, rhombi for relation sets and labeled connectors indicating their roles and arity), NIAM allows the modeling of additional constraints such as uniqueness, equality and exclusiveness.

IDEF1x as a graphical language for data modeling was introduced by the US military and build upon the 3-layer ANSI/SPARC method of infor-mation modeling. It provided a graphical means to model data inforinfor-mation independent of its actual physical representation.

A comparison of these early modeling methods can be found in (Eastman

and Fereshetian, 1994)

3.1.4 EXPRESS

The Standard for the Exchange of Product Model Data (STEP) that is described in the dierent parts of the ISO 10303 has been the key technology in the exchange of data within many large industry domains for a very long time. The denition of objects, their relations to other objects and their

constraints are dened in the EXPRESS (ISO 10303-11:1994,1994;Schenck

and Wilson, 1994) language. This very powerful means of data modeling

was developed in the early 1980s predating UML and XML. It was aimed at being a exible, extensible and scalable modeling language easy to be read by human experts. However successful the language is in some industries, only a limited amount of developers is familiar with it. Simple examples of EXPRESS schemas include classes with primitive types like

ENTITY door; SUBTYPE OF (buildingPart) height: REAL; WHERE WR : height > 0; END_ENTITY;

Describing a class door that in addition to everything inherited from an existing class buildingPart has a property height of the primitive type REAL that is constraint to values greater than zero.

Besides the NIAM and IDEF1x methodologies described earlier, a third powerful graphical method of developing data models was introduced under the umbrella of the STEP initiative. The EXPRESS-G language is an iconic

(42)

language based on a subset of the EXPRESS language3_{. Using EXPRESS-G} editors a user can assemble large data models to have tools derive EXPRESS notations of them.

3.1.5 UML/XMI

The Unied Modeling Language (UML) was introduced by the Object Man-agement Group (OMG) in the early 1990s. Although the initial goal to de-velop a universal information modeling language that would work across the boundaries of dierent implementation platforms, the UML family of lan-guages today is the most accepted and widespread standard for information modeling and software engineering.

Contrary to the languages mentioned earlier, the context of UML is not that of a specic modeling tool for computer aided product modeling or the creation of databases. It is intended to be a general purpose modeling tool for conceptional designing OOP applications. It covers various aspects of software engineering such as the denition of use cases, the specication of sequences and activities, but most importantly it provides a standardized set of symbols to model OO information in classes, their relationships and interfaces.

With the recent eort to come to an XML Metadata Interchange (XMI) format, UML diagrams and their underlying formal specication of models can be exchanged across borders of software engineering applications.

3.2 Concrete Building Product Models

3.2.1 GARM, RATAS, COMBINE, CIS/2 and others

Throughout the history of Building Product Modeling a large number of conceptual upper level meta models have been suggested and developed -often in parallel - aiming to nd a comprehensible methodology to integrate the various kinds of information that are generated in building construc-tions. In the following sections some important milestone projects, their modeling approaches and outcomes are highlighted.

3.2.1.1 RATAS

The RATAS initiative (Björk, 1994) was started in Finland in 1983 and

had large number of participants from all relevant areas including research,

3_{Many of the more advanced constructs such as WHERE rule constraints cannot be}

Facilitating distributed collaboration in the AEC/FM sector using Semantic Web Technologies

Facilitating distributed collaboration in the AEC/FM sector

using Semantic Web Technologies

Facilitating distributed collaboration

in the AEC/FM sector using

Semantic Web Technologies

Facilitating distributed collaboration

in the AEC/FM sector using

Contents

Chapter 1

Introduction

1.1 Motivation

1.2 Methodology

1.3 Research questions

1.4 Hypotheses

1.5 Outcomes

1.6 Guide to reading this thesis

Chapter 2

Collaboration and

Interoperability

2.1 Exchange of information and knowledge

???

2.1.1 Communicating data, information and

knowledge in AEC/FM

2.2 ICT supported communication in the

Building and Construction Industry

2.2.1 Document-based methods

2.2.2 Central Product Model Servers

2.2.3 Information exchange as a process

2.2.4 SOA

2.2.5 The notion of agents

Chapter 3

Building Product Modeling

3.1 Means of product information modeling

3.1.1 The advent of modeling languages and

techniques in ICT history

3.1.2 Database design and Entity-Relationship

Models

3.1.3 Graphical modeling aids: NIAM, IDEF1x,

GARM Hamburger Model

3.1.4 EXPRESS

3.1.5 UML/XMI

3.2 Concrete Building Product Models

3.2.1 GARM, RATAS, COMBINE, CIS/2 and others