Computer-Aided Design 38 (2006) 10991112

www.elsevier.com/locate/cad

Semantic interoperability in building design: Methods and tools

Q.Z. Yang a, , Y. Zhang b
a Singapore Institute of Manufacturing Technology, 71 Nanyang Drive, Singapore 638075, Singapore
b Computing and Information Systems, Stansfield College, 11 Penang Lane, Singapore 238485, Singapore

Received 25 November 2005; accepted 8 June 2006

Abstract
Semantic interoperability is a crucial element to make building information models understandable and model data sharable across multiple
design disciplines and heterogeneous computer systems. This paper presents a new approach and its software implementation for the development
of building design objects with semantics of interoperable information to support semantic interoperability in building designs. The novelty
of the approach includes its incorporation of building design domain ontology, object-based CAD information modeling, and interoperability
standard to make building information models and model data semantically interoperable. A set of methods are proposed to address the issues
of object-based building information representation compliant with the Industrial Foundation Classes (IFC); extension of IFC models with the
supplementary information; and semantic annotation of the interoperable and extensible information sets. The prototype implementation of these
methods provides a set of Web-enabled software tools for effectively generating, managing, and reusing the semantically interoperable building
objects in design applications of architectural CAD, structural analysis, and building code conformance checking.
c 2006 Elsevier Ltd. All rights reserved.

Keywords: Building design object; Semantic interoperability; IFC standard; Domain ontology

1. Introduction
Building design can be a highly collaborative process often
involving multi-disciplinary project teams at distributed sites
with heterogeneous computer-support systems. Interoperability
issues arise in such a collaborative design environment
where:
There is a need for sharing semantics of building information
models (BIM) among project participants who do not
necessarily share the same definition of terminologies, share
the same meaning of building information, or share the
same background and perspective about a design (semantic
difference);
Disparate design systems and heterogeneous data sources
with proprietary information model schemas coexist
(structural difference); and
Fundamentally different representation languages and data
formats are used in data interchange processes (syntactic
difference).

Corresponding author. Tel.: +65 6793 8348; fax: +65 6791 6377.

E-mail address: qyang@simtech.a-star.edu.sg (Q.Z. Yang).

c 2006 Elsevier Ltd. All rights reserved.
0010-4485/$ - see front matter
doi:10.1016/j.cad.2006.06.003

The semantic, structural and syntactic differences given

above (which together are termed the BIM and model data
semantic interoperability in this paper) have imposed big
challenges in the architecture, engineering, and construction
(AEC) domain. A number of research and industrial efforts
have been made to address these challenges in AEC.
Different methodologies, software systems, and information
and communication technologies (ICT) are developed to
tackle the interoperability problems, ranging from conformance
to industry-wide standard specifications (e.g. Industrial
Foundation Classes (IFC) [1], aecXML [2]), to implementation
of middleware solutions [3,9] and Web Services [4,5], and to
deployment of ICT for distributed databases, project model
servers [6,7,9], and Semantic Web applications [8].
Although many interoperability problems in AEC can
be addressed by these approaches and technologies above,
achieving semantic interoperability in BIMs and in building
information interchange between AEC applications of multiple
disciplines continues to be a problem. Many of the current
approaches are inappropriate to address the issue. For example,
most of the standard-based schema-level specifications only
provide commonly agreed sets of labels, entity definitions and
relationships for interchanging heterogeneous information or

1100

Q.Z. Yang, Y. Zhang / Computer-Aided Design 38 (2006) 10991112

for defining project models. They usually do not support broad

ranges of explicit definitions for the terminologies and concepts
used in their schemas. As these standard schemas lack rich,
formal and explicit semantic descriptions, they cannot ensure
the consistent interpretation and understanding of application
semantics across disciplines. Simply sharing the common labels
and standard data structures is not sufficient to achieve semantic
interoperability. All the participating teams and applications in
a project must share their semantics, i.e. meanings of their
respective terminologies [10].
Besides the interoperability standardization approach,
ontology engineering is recognized as another key technology
to deal with the semantic interoperability problem. Ontologies
specify the semantics of terminology systems in a welldefined and unambiguous manner [11], by formally and
explicitly representing shared understanding about domain
concepts and relationships between concepts. In the ontologybased approach, intended meanings of terminologies and
logical properties of relations are specified through ontological
definitions and axioms in a formal language, such as OWL
(Web Ontology Language) [12] or RDF (Resource Description
Framework) Schema [13]. At present, there are no common
ontologies existing in the AEC sector, although the IFC
specification, the ISO 12006-2 framework for classification of
information, and the bcXML schemas from the eConstruct [14]
project are considered as implicit ontologies for AEC by
some literature. However, project-specific ontologies are
emerging, such as the e-COGNOS Ontology [15] developed
for unambiguous representation of knowledge sources in the
AEC industry and the inteliGrid [16] project ontology for AEC
components of the IAI-IFC to support shared semantics among
interoperating applications.
In this paper, we argue that ontologies, object-based
CAD representations, and AEC interoperability standards are
needed to enable the semantic interoperability in building
designs: ontologies formalize the semantics of BIM; objectbased design information representations capture the semantics
of supplementary design information in CAD models; and
interoperability standards provide a common foundation
for interoperating design applications. A combination of
ontology engineering, object-based CAD modeling, and AEC
standardization presents promising solutions to semantic
interoperability of BIM and model data.
This paper analyzes how these three areas can be integrated
to support the semantic interoperability of BIMs and project
model data. It focuses on method exploration and software
implementation of a Web-enabled modeling and sharing
environment to capture and retrieve semantically interoperable
building information in design objects. Specifically, the
paper presents a set of methods to address the issues
of object-based building information modeling compliant
with the IFC specification; extension of IFC models with
supplementary design information such as semantic properties,
CAD behaviors, and interdisciplinary relationships; semantic
annotation of the interoperable and extensible information
sets; and the development of domain ontologies in OWL [12]
to enable the shared understanding in retrieving and

utilizing the supplementary design information. The prototype

implementation provides a set of Web-enabled software
tools and add-ons to CAD and non-CAD applications for
effectively generating, managing, and reusing the semantically
interoperable building design objects in the AEC applications
of architectural CAD, structural analysis, and building
code compliance checking. Use scenarios are discussed to
demonstrate how data semantics are captured in design objects
and how the captured semantics are shared across these AEC
applications.
2. Concepts and methods
2.1. Building design object and semantic interoperability
A building design object, in the context of this paper, refers
to a CAD object embedded with explicit data semantics of the
supplementary design information, which is defined to include
semantic properties, CAD behaviors, reference links to external
information sources, interdisciplinary object relationships, and
object constraints. Building design objects with semantics-rich,
interoperable, and extensible supplementary information sets
would effectively support the information needs of diverse
design applications. For example, the semantic properties
with a building design object would provide structural and
M/E (mechanical and electrical) design applications with
meaningful information for structural analysis and M/E design.
The reference links built in a design object would enable
the discovery and invocation of building product information
(e.g. cost and performance criterion, product catalog, or
regulatory standard) and services (e.g. component availability
or delivery schedule), via the Internet or Intranet, from within
a design application where the design object is being used.
The interdisciplinary relationships captured in a design object
would provide the collaborating applications with the capability
to detect inter-disciplinary conflicts such as a duct passing
through a beam or a column being located in the middle of
a space. The scenarios above indicate that building design
objects with relevant supplementary information and semantics
can provide wide ranges of meaningful information to address
the needs from multi-disciplinary design applications. For
the supplementary information, it is essential to ensure the
information carries unambiguous semantics, understandable,
interpretable by other software applications.
Semantic interoperability of BIMs and model data is the
ability of enabling multi-disciplinary design applications to
understand and utilize semantics of BIMs and meanings of
model data, and to map between commonly agreed concepts
to establish a semantically compatible information interchange
and sharing environment. To achieve semantic interoperability,
an IFC compliant, object-CAD based, and OWL ontology
enabled approach is proposed. It consists of three method
components to be elaborated in the following sections.
2.2. Supplementary information modeling compliant with IFC
In our approach, the supplementary design information is
modeled in three steps: object-based CAD property modeling,

Q.Z. Yang, Y. Zhang / Computer-Aided Design 38 (2006) 10991112

Table 1
A window entity property definition
Attributes
Identifier

TypeIndicator

Attribute constraints

PropertyName
Description
Value
Unit
LibRefNo

String
String
Real
Measures
String

>=0
Enum (mm, min, dollar)
Unique string

IFC extensions modeling, and semantic mapping between

CAD and IFC property definitions. Through this modeling
approach, the CAD supplementary information will be made
interoperable and extensible for use in multi-disciplinary
designs.
The modeling process starts from extending traditional CAD
models with supplementary properties to form building design
objects (defined in Section 2.1). The implicit information
from CAD models is made explicit, and the additional design
semantics entered by users are captured in a semantically rich
set of entity property definitions. The entity property [17]
is a basic concept for describing object-based supplementary
data and for precisely representing the intended semantics of
these supplements. An entity property is defined by attributes
and attribute constraints. An attribute has an identifier and
a type indicator. An attribute constraint contains a set of
explicit relations and methods to limit the validity of the
attribute meanings, types and values that a hosting CAD
system can support. All attributes and constraints of an entity
property together describe the supplementary data semantics
being defined. The entity property is configurable and may
contain any number of attributes and constraints, depending on
the needs for semantic description from particular viewpoints.
Table 1 shows a modeling example for a window entity property
with five attributes and three constraints.
Property objects are instantiated from entity property
definitions. During instantiation, attributes of entity properties
will be populated with the information from CAD models
or from user inputs and external programs. However,
attribute constraints cannot be instantiated. They will only
be implemented as constraint algorithms to ensure that the
auto-extracted or user-entered attribute values and types are
compliant with the data scope and type indicator defined in the
entity property. Table 2 shows some instantiation results from
the window entity property definition in Table 1.
The next modeling step is to employ the IFC property
extension mechanisms [18] to define IFC properties and
property sets (Pset). Although the IFC standard has specified a
rich collection of pre-defined Psets, the extension mechanisms
provide more flexibility to application-specific property
definitions. Fig. 1 describes such an extension mechanism in
EXPRESS-G notation [19] for IFC single valued properties.
According to Fig. 1, the properties (shown as IfcProperty)
are defined in an extension model to satisfy the specific
information requirements from individual design applications.
The properties are categorized into Psets (IfcPropertySet in
Fig. 1) to facilitate more flexible and easier association between

1101

IFC objects and a set of properties. The relationship entities

(e.g. IfcRelDefinesByProperties in Fig. 1) are then specified to
assign the relating property definitions (IfcPropertySetDefinition) to the related objects (IfcObject) in an existing IFC model.
In this way, IFC property extensions are defined. In order to
instantiate these property definitions with available CAD information, semantic mappings between CAD and IFC property
definitions are required.
The last step in the modeling process is semantic mapping
to make the CAD property information defined in the first
modeling step, compatible with the extended IFC properties
defined in the second modeling step. Semantically equivalent
property components in the CAD and IFC property definitions
are identified and compared. The semantic mapping knowledge
is then established at both the property and attribute levels.
Table 3 shows an example for a window property mapping
knowledge from CAD (defined in Table 1) to IFC (described
in Fig. 1).
However, one of the CAD property attributes in Table 1,
LibRefNo representing the reference number of the CAD
property in a property database, does not have a semantic
equivalence in the IFC property definition. If an IFC property
does not have a matching component correctly representing
a CAD property component, the identified incompatible
component has to be resolved through defining reconciliation
rules. Because the standard definitions in IFC cannot be
changed, the common approaches of reconciliation are to
aggregate the incompatible CAD property components to match
an IFC property component or to use the IFC enumerated
values property extension mechanism. In the latter case,
incompatible CAD property components are mapped in an
IFC aggregate property as one of its enumeration values. For
example, to resolve the above semantic conflict with LibRefNo,
an IFC window aggregate property is defined, which is of the
IfcPropertyEnuneratedValue type. The following mapping then
applies:
(CAD.WindowProperty.LibRefNo, IFC.WindowAggregateProperty.EnumerationValues.LibRefNo)
The semantic mapping and reconciliation process ensures
that all the semantics-rich information in CAD property
definitions can be recognized and held in an extended IFC
model following the standard schema syntax, so that the
compliance of building design objects with the IFC standard
is controlled.
2.3. Semantics capturing in CAD models
Besides CAD properties discussed in the previous section,
semantics of the supplementary information also include the
followings:
CAD behaviors, such as position, anchor, change color,
explode, etc. for building design object manipulations in a
CAD modeling environment;
Relationships between building objects especially between
components designed by different disciplines, such as an
HVAC (heating, ventilating, air conditioning) component
not passing through a structural element;

1102

Q.Z. Yang, Y. Zhang / Computer-Aided Design 38 (2006) 10991112

Table 2
Property objects of the window
PropertyName

Description

Value

Unit

LibRefNo

NominalHeight
FireRating
Material
Availability

Nominal value of the window height

Fire resistance level of a window
Material of a window
Stock status of a window manufacturer

135
50
CW-0935
Yes

mm
min

Window001
Window003
Window004
Window006

Fig. 1. IFC property extension mechanism.

Table 3
CAD and IFC property mapping example
Property level mapping

Attribute level mapping

(CAD.WindowProperty,
IFC.WindowProperty)

(CAD.WindowProperty.PropertyName, IFC.WindowProperty.Name)
(CAD.WindowProperty.Description, IFC.WindowProperty.Description)
(CAD.WindowProperty.Value, IFC.WindowProperty.NominalValue)
(CAD.WindowProperty.Unit, IFC.WindowProperty.Unit)

Constraints of design objects, such as the setback distance of

a wall in a household shelter not exceeding a specified value;
and
Reference links to external digital information sources
on the Web, such as part classification and specification
systems, online product catalogs, etc.
The selected CAD behaviors, relationships, constraints, and
reference links are termed object behaviors in discussion of
semantics capturing methods below for easy reference.
Two methods are developed by which the object behaviors
can be captured and embedded in CAD models. The first
method embeds the object behaviors through entity behavior
definitions and CAD associations. The concept of entity
behavior is similar to that of entity property described in
Section 2.2. An entity behavior is also defined with attributes
and attribute constraints. Its attributes are usually instantiated
with additional information from users inputs to describe
the CAD manipulations, object relationships, constraints,
and external links, but its attribute constraints will not be
instantiated. Table 4 shows some object behaviors instantiated
from an entity behavior definition for a CAD manipulation of
exploding; a location relationship between a group of household
shelters; and a constraint to the setback distance of a wall.
The CAD behaviors, such as explode in Table 4, can
be embedded to CAD models by establishing associations
between the two. Many commercial CAD systems, such as the
Architectural Desktop (ADT) system, provide native facilities

for constructing such associations. In other words, the CAD

associations and their pointed behavior objects, together with
the embedding CAD models, will be stored in data structures
recognizable and processible by CAD systems. This method
is suitable for embedding CAD behaviors. It is simple and
effective. However, the drawback is that it can complicate
otherwise elegant embedding CAD models.
The second method is used to embed complex object
behaviors in CAD models, such as the LocatedOnTop
relationship and the MaxSetbackDistance constraint in Table 4.
These object behaviors are defined with complicated behavior
information and even external application programs. They are
assigned to the relating CAD models by object links. An object
link is composed of two nodes: a complex behavior object
node and a CAD model node. A CAD add-on tool is needed
to instantiate such object links on a hosting CAD platform.
In the current research, a building design Object Creation
Wizard (details in Section 3.3) has been implemented as a
CAD add-on tool for the ADT platform. When an object link
between a behavior object and a CAD model is instantiated,
this linkage relationship, rather the behavior object itself, will
be embedded into the CAD model, retrievable and editable from
the CAD modeling environment. Object links can also be used,
as pointers to external information sources, for embedding
external reference links into the building design objects.
The second method is suitable for embedding interdisciplinary relationships, object constraints, and reference links

1103

Q.Z. Yang, Y. Zhang / Computer-Aided Design 38 (2006) 10991112

Table 4
Example of object behaviors
BehaviorName

Description

Value

Explode

Auto explosion of an imported building

design object into native CAD objects

dropExplode.dvb!Drop
Module.explode

LocatedOnTop

Household shelter on every storey is

located one on top of the other, to form a
vertical tower with continuous walls

(X i j , Yi j , Z i j ) [k]a ==
(X 0 j , Y0 j , Z 0 j ) [k]a
k = 1, 2, . . .

MaxSetbackDistance

The maximum setback distance of a wall

6000

Unit

Type
dvb

mm

a (X , Y , Z ) [ ] a vertex coordinates array for a household shelter space of jth unit on ith floor. (X , Y , Z ) [ ] a base vertex coordinates array for
ij ij
ij
0j 0j
0j
jth vertical tower.

Fig. 2. Vocabulary classification.

needed for use in CAD and non-CAD applications, such as

in design conflict detection and code compliance checking
systems.
2.4. Semantics annotation and sharing via OWL ontologies
Multi-disciplinary design professionals are involved in
building projects, with various viewpoints, goals, priorities, and
backgrounds. Different terms may be used for representing the
similar concepts or a single term for different concepts. Even,
in some situations, the concepts may not be explicitly defined
or defined with implicit assumptions. A collection of common
vocabulary agreed by design teams would be beneficial in
achieving a common and explicit naming approach to shared
use in different disciplines.
A vocabulary library has been developed to manage
commonly-agreed and sharable terminologies/concepts together with their meanings used in building design. The vocabulary library entries are stored in a server repository in XML
format. The terminologies are mainly used for naming properties, CAD behaviors, object relationships and constraints. Fig. 2
shows a section of the vocabulary for IFC property names.
The library entries are classified into a hierarchical structure
with terminologies interconnected by is-a (subclass) and
part-of (part-whole) relationships as shown in Fig. 2.
The is-a relation exists between domain concepts being
classified, while the part-of relation between attributes

within a concept. For example, each of the Pset DoorCommon,

Pset Chair, and Pset Desk in Fig. 2 is a sub-concept of
the concept IFC Psets, while the attributes for Reference,
Description, IsExterior, Infiltration, etc. listed in Fig. 2 are parts
of the Pset DoorCommon concept.
As the meaning of each concept or attribute in the vocabulary library has been explicitly defined, the supplementary design information named by using these terminologies can then
be readily interpreted and understood by other design applications. The common vocabulary with its explicit classification
hierarchy provides a foundation for the development of a shared
reference ontology towards semantic interoperability.
The shared reference ontology is defined in OWL [12],
which is different from the mathematical notion based methods
for classifications and infomorphisms, such as those used
by Tomiyamas group [20]. In the OWL approach, the
intended meanings of domain terminologies and relations are
specified through various OWL language constructs which
have implemented OWL semantics and logical axioms in
an easy-to-use way. By expanding the is-a and part-of
relationships in the vocabulary classification to include
other domain concepts and ontological constructs, such as
the owl:cardinality constraint and the owl:intersectionOf,
owl:disjointWith relationships, the reference ontology is
defined. Fig. 3 shows a segment of the reference ontology for
the concept ObjectBehaviors, which was defined early in
Section 2.3.
From the OWL description in Fig. 3, it is known that the concept ObjectBehaviors has four sub-concepts (defined by subClassOf in the figure): CADbehaviourSet, RelationSet, ConstraintSet, and RefLinkSet. It has at least one object relationship
(restricted by owl:minCardinality in Fig. 3) with another concept BuildingObject: behaviorEmbeddedIn. It also has two
attributes (denoted by owl:DatatypeProperty): behaviorName
and behaviorDescription. Both attributes have the same data
type (specified by the domain-range pair in Fig. 3): a string
of the XML Schema. The behaviorEmbeddedIn relationship
and the two attributes of behaviorName and behaviorDescription are associated with the ObjectBehaviors concept
through the domain and range restrictions in Fig. 3. Described
by these formal, explicit and rich semantics, the domain concept of ObjectBehaviors, its attributes and relationships with
other concepts can be queried, reasoned or mapped to support
the shared understanding in building designs.

1104

Q.Z. Yang, Y. Zhang / Computer-Aided Design 38 (2006) 10991112

Fig. 3. OWL definition of a concept and its relationships.

The main functionality of the shared reference ontology is

to provide the ability for delivering and sharing the semantics
of the supplementary design information from a building
design object server to multiple CAD systems, more generally,
to multiple design application systems at client sites, and
vice versa. This is done by annotating semantics of the
supplementary design information from each design application
to the shared reference ontology through application profiles.
An application profile works as a semantic interface between
an application systems local data schema and the shared
reference ontology. It annotates meanings of information
elements in local conceptual schemas according to the semantic
references defined in domain ontologies. For each engineering
application (e.g. CAD, structural analysis, or code checking)
concerned, an application profile is defined using the terms
and definitions from the common vocabulary library. For
example, the profile for a CAD application may specify a set of
definitions for CAD properties, behaviors, and reference links.
It is defined in the XML format. For each building design object
to be submitted to the server for sharing with others, a CAD
profile instance file describing the semantics of its embedded
supplementary information will be generated, associated with
the CAD model, and delivered to the server. The server
analyzes and annotates the information elements delivered by
using the shared reference ontology in Fig. 3. Through the
annotation process, the information elements described in the
CAD profile are given commonly understood meanings for
use in other design applications in a collaborative development
environment.

3. Prototype system design

3.1. Distributed system architecture
A Web-enabled prototype system has been developed to
implement the semantic interoperability methods presented in
Section 2 into a set of software tools to support semantic
interoperations of multi-disciplinary design applications. The
prototype uses a multi-tier architecture consisting of a design
object server and a set of client-side interfacing software tools.
Fig. 4 is the functional architecture showing the major server
functional modules and the client interfacing tools.
As shown in Fig. 4, the prototype system consists of four
tiers to provide online design object services.
Data source tier: This is used to store, retrieve and manage the
design objects, IFC files, and XML instance files in a server
database and file repositories.
Domain logic tier: This tier uses Java beans to provide domain
services for management of CAD objects and vocabulary,
property, behavior, and relationship objects. It also supports
online access for objects uploading/downloading, searching and
updating, collaboration team setting and activity coordination,
CAD models visualization and conflict negotiation, etc.
Web tier: The Model-View-Controller (MVC) pattern is used at
this tier. The Controller Servlets direct online service requests
from clients to relevant Model beans for processing. The server
responses are passed to View for transforming JSP pages to be
shown on client browsers. The Web tier also facilitates the XML
message interactions between the server and its clients.

Q.Z. Yang, Y. Zhang / Computer-Aided Design 38 (2006) 10991112

1105

Fig. 4. Functional architecture of the prototype system.

Client tier: This consists of interfacing tools and add-on toolkits

for CAD and non-CAD applications. Thin Web clients are used
at this tier with a small amount of client-side code to assemble
service requests and receive responses. The Java3D package
is deployed for Web browsers to render geometries of design
objects.
The software design of selected server and client
components are elaborated as follows.

to edit a vocabulary definition in the server database, a

database connection object, a VocabularyObjectBroker and a
VocabularyObjectAttributeBroker need to be instantiated for
interacting with the database and conducting the find() and
update() operations to an existing vocabulary entry. Fig. 6 is
a UML class diagram of the data access component.

3.2. Server components design

The client-side components of the prototype include four

tools: a building design Object Creation Wizard and a CAD
Integration Toolkit, both being used with CAD systems as addons; a Local Storage Box which can be used with or without a
CAD system; and a Structural Interfacing Tool which is used to
transform and edit architectural IFC files for structural analysis
with the SAP2000 system.

The design of the Web component in the Web tier and the
data access component in the domain logic tier of Fig. 4 are
discussed below.
Web component: The Web component uses the Model-ViewController (MVC) pattern to fulfill its responsibility for routing
an incoming HTTP request from a client browser to the
Controller for generating an appropriate Command object
which knows how to handle the request. This Command
object can then further delegate the request to a facade object
by instantiating a Model object. The object will execute
appropriate business logic functions of the design object server.
Once the request processing is completed, the Controller will
invoke a Flow Management object to look up the next display
page and present it to the client through a View object. The
following sequence diagram of UML [22] in Fig. 5 depicts how
the MVC pattern works.
Data access component: This component is responsible for
database connection and brokers management, such as to
help a requesting object to get a database connection; to
release the database connection; to retrieve the appropriate
broker; and to manage the number of brokers to be
instantiated. Any domain object can only manipulate the
server database objects through brokers. Each domain object
must have at least one broker to process its requests
for accessing the server database. For example, in order

3.3. Client components design

Object creation wizard: The wizard is designed for use with the
ADT system to provide the services of: defining the semantics
of entity properties for ADT models, instantiating the property
definitions with design parameters extracted automatically from
ADT or supplemented by users, validating the property values
against the implemented attribute constraints in the wizard,
linking property objects with CAD models or ADT styles,
and semantically mapping property definitions between ADTs
and IFCs. Three modules are developed with the wizard to
implement these services. The functional requirements of each
module are captured and analyzed by use case diagrams of
UML. Fig. 7 shows one of the use cases for the CAD Pset
definition module.
CAD integration toolkit: It is another CAD add-on to provide
more value-added services to the CAD users who are using
semantics of the supplementary information, especially CAD
behaviors of the downloaded building design objects in
their native CAD systems. As the supplementary information
semantics with the design objects may have been edited
at the server side, the toolkit will identify and retrieve,

1106

Q.Z. Yang, Y. Zhang / Computer-Aided Design 38 (2006) 10991112

Fig. 5. How MVC works.

Fig. 6. Data access classes.

based on the common vocabulary and reference ontology, the

updated information semantics of representation maps, object
relationships, CAD behaviors, etc. for use in a CAD system.
Its services include: automatic placement of the downloaded
design objects/symbols onto designated layers/levels as
stipulated in code of practices for CAD; interpreting the edited
information semantics and applying them to the corresponding
CAD objects/symbols in a design space; providing interfaces
for the user to access external information directly from within
a CAD design environment through the reference links of the

design objects; and automatically executing the built-in CAD

behaviors in a design space.
Local storage box: It stores and manages, at the clients desktop,
the downloaded building objects and XML instance files from
the server. It can be used to search, visualize and manipulate
these objects and XML data without use of a CAD system. If
used with a CAD, it supports draggingdropping of building
objects from the storage space to CAD modeling space using
an explorer-like file tree structure. Fig. 8 shows one of its
usage scenarios to update the building objects/symbols from

Q.Z. Yang, Y. Zhang / Computer-Aided Design 38 (2006) 10991112

1107

and scalability. Standard Web server technologies are used

to integrate all server components and to provide common
services. End users can either use software add-on tools or
thin-clients, such as a Web-based GUI (Graphic User Interface)
developed with Java or Java3D, to access functions provided by
the server modules.
4.1. Server portal implementation
The server portal is implemented as two logical sections, a
public area and a private area. In the public area where no login
is required, a surfer will be able to register and log in to the
prototype system. In the private area after logging-in, users are
able to invoke the following services:
Fig. 7. UML use case diagram for Pset definition.

the server to the Local Storage Box, then to drag and drop
a selected object/symbol from the local storage to a CAD
working environment.
Structural interfacing tool: This thin client tool uses a Java3D
enabled Web browser with Java applet running on it. The
applet reads in structural design models from the server;
extracts the model topological information and geometric
design parameters; and displays 3D structural elements on a
browser with the support from the Java3D package. Besides 3D
visualization, the interfacing tool allows users to add or edit the
structural property sets to selected structural elements (shown
in Fig. 9). It also supports the design negotiation of architects
and structural engineers through XML messaging between the
two.
4. Software implementation
The prototype server is implemented in Java and supports the
J2EE (Java 2 Enterprise Edition) [23] platform for portability

Project team setting and activity coordination through

member profile management, role and task assignment,
access rights control, task checklist configuration, etc;
Building design object uploading, and searching/updating
supplementary design information based on users roles and
access rights assigned;
Vocabulary object definition, search, update and validation;
Object profile management, such as browsing the building
objects in the server repositories, online visualizing CAD
models, co-editing the supplementary design information,
retrieving vocabulary definitions, etc.;
Personal profile management to select and manage the user
preferred building design objects, vocabulary and property
objects;
Downloading facility, for downloading a group of preferred
objects from the personal profile to the Local Storage Box at
the client side;
Live updating, for populating the Local Storage Box with
the latest version of the server-side objects according to userdefined updating policies;

Fig. 8. Updating and draggingdropping scenarios of the local storage box.

1108

Q.Z. Yang, Y. Zhang / Computer-Aided Design 38 (2006) 10991112

meanings of the embedded reference links and behaviors of

a basin object in Fig. 11 and provides GUIs to enable a
users retrieving the external product information about the
basin and invoking the embedded CAD behaviors in the ADT
environment. Fig. 11 illustrates these two scenarios.

Fig. 9. Class diagram for structural Pset processing.

Building design object viewing and draggingdropping in

multiple CAD formats;
Message broadcasting and conflict logs to facilitate design
conflict detection and negotiation in collaborative design
process; and
User account management.
Fig. 10 below shows one of the portals private area pages for
object profile management.
4.2. Client toolkits implementation
As mentioned in Section 3.3, there are four client side
tools developed in the prototype. The implementation of the
CAD Integration Toolkit and the Structural Interfacing Tool are
described as follows.
CAD integration toolkit: Based on the design in Section 3.3,
the toolkit is implemented as an add-on to work with a CAD
system such as ADT or ArchiCAD. When a design object is
downloaded from the server or from the Local Storage Box
to a CAD platform, the toolkit will process its embedded
supplementary information semantics and apply them to the
native CAD environment. For example, the toolkit interprets

Structural interfacing tool: The thin-client tool is implemented

in Java running on a Web browser with Java3D capability.
Structural engineers can use it for viewing and editing
downloaded structural elements in 3D. It also provides GUIs for
attaching additional structural information, as structural Psets,
to the elements. Fig. 12 shows one of the tools functions to add
a structural Pset describing joint coordinates and tolerance, and
defining a structural analysis theory type to one of structural
elements.
By invoking the Feed Back facility in Fig. 12, a structural
engineer can send a commenting message to other project team
members about the model changes he made. Whatever disputes
arise from any design changes, they can always discuss and
negotiate, until the Agree message is sent from Fig. 12.
5. Evaluation and use scenarios
5.1. Evaluation of the approach and prototype
The proposed semantic interoperability approach and the
prototype system are evaluated and tested by case studies.
Among others, two cases are discussed in the next sections
for:
Modeling of architectural design objects captured with
building design semantics from the property and behavior
supplements by using the design Object Creation Wizard;
and
Ontology-enabled sharing of design semantics across
disciplinary applications in structural analysis, M/E design,
and building code compliance checking.
The evaluation from these two cases is focused on the following
aspects in:

Fig. 10. Object profile management.

Q.Z. Yang, Y. Zhang / Computer-Aided Design 38 (2006) 10991112

1109

Fig. 11. Use of embedded CAD behaviors and reference links.

Fig. 12. Adding semantic properties to a structural element.

Test of functionality of the Wizard such as provision of

common vocabulary to architects within the ADT modeling
environment, validation of user inputs against constraint
algorithms, interaction with the hosting CAD system to
manipulate CAD data for instantiation of the property and
behavior objects, and IFC and XML file generation; and
Validation of the reference ontology on its handling
capability of queries and navigations of domain concepts
and relationships, and its reasoning capability over the
ontological definitions and axioms to admit or reject
interpretations of terminologies.
The evaluation results show that the prototype system can
provide sufficient functionality to address user requirements
on supplementary information modeling, building semantics
capturing with design objects, and support of semantics
sharing among disciplines. However, the current version of the
reference ontology presents limited capabilities for reasoning,
mapping, and matching terminologies and relations used in
case studies. The details of the two use scenarios are discussed
below.

5.2. Design objects creation and semantics capturing

This scenario demonstrates the creation of architectural
design objects embedded with the semantic and interoperable
(IFC-compliant) supplementary information. The scenario
involves the use of the building design Object Creation Wizard
(shown in Fig. 13) developed for this study. The modeling of a
school door is taken as an example in this scenario.
The 3D CAD geometry of the door is modeled by the
ADT system and packed with multi-view blocks to fully
describe the graphical representations of the CAD object. The
Wizard is invoked from within the ADT environment through a
customized ADT menu as shown in Fig. 13.
The supplementary design information for semantic properties and object behaviors of the door is defined by using the
Wizard. This includes a Pset with three properties for Description, FireRating and IsExterior; one CAD behavior for Explode;
and two reference links for Manufacturer and ProductDetail as
shown in Fig. 13. The Wizard automatically extracts the relevant design characteristics, if they are available, from the door

1110

Q.Z. Yang, Y. Zhang / Computer-Aided Design 38 (2006) 10991112

Fig. 13. Design object creation embedded with supplementary information.

Fig. 14. Capturing supplementary information in IFC and XML files.

CAD model to instantiate these property and behavior definitions. If not, it provides GUIs to allow new data entries from
users (lower left GUI in Fig. 13). All input data will be evaluated by constraint algorithms of the Wizard and only valid
inputs are accepted. As indicated in Fig. 13, the Wizard only
provides commonly agreed terms from the vocabulary library
for naming the doors supplementary information of multi-view
representation maps, Psets, behaviors, and reference links. It
embeds these information elements into the door CAD model
through customized ADT facilities. By mapping and annotating
the embedded information semantics, the Wizard generates an
IFC file and an XML profile instance file for the door. Both files
(shown in Fig. 14) together with the door CAD model extended
with the supplementary information will be submitted to the
design object server for sharing with other design applications.

5.3. Semantics sharing with structural, M/E and code checking

applications
In this scenario, building design objects downloaded from
the server are reused for structural analysis with the SAP2000
package. The design semantics in the downloaded objects
are also queried, inferred, and shared in CAD and non-CAD
applications of M/E design and code conformance checking.
Structural engineer A, M/E engineer B, and plan checker C are
involved in this use scenario.
Structural engineer A, as a registered user of the server
portal, searches and views structural components through the
Object Profile Manager in Fig. 10. The selected structural
objects together with their server-side-populated XML instance
files are downloaded to a local network at the client side.

Q.Z. Yang, Y. Zhang / Computer-Aided Design 38 (2006) 10991112

1111

Fig. 15. Ontological definition of CadBehavior.

Fig. 16. Provision for setback distance of wall.

The Structural Interfacing Tool in Fig. 12 is used to edit the

supplementary information of the design objects to address
structural design specific requirements, such as adding a Pset
for load and frame section information and modifying a
reference link pointing to a loading calculation manual in the
local network. The modification is updated in the XML file as
well. So other fellow engineers can invoke the new Pset and
the edited link, as well as other built-in design semantics (as
shown in Fig. 12) in the XML file when they work with the
SAP2000 software. The SAP2000 structural analysis models
use the geometric information from the IFC models, as well as
the extended semantic properties of material, load, and section
data extracted from the downloaded structural design objects.
M/E engineer B logs to the local network to view and
select building objects related to his M/E design tasks. He may
then drag and drop the selected architectural and structural
objects to his Mechanical Desktop (MDT) workspace. The
CAD Integration Toolkit in Fig. 11 is then invoked to convert
these objects in ADT format to MDT multi-view blocks, if
an Explode CAD behavior has been encapsulated in these
building objects. The term Explode is retrieved from an XML

instance file accompanied with the building objects selected

by M/E engineer B. The semantics of the term are interpreted
through querying the ontological relationships defined in the
shared reference ontology (as shown in Fig. 15).
For example, given the definition in the reference ontology
in Fig. 15, it can be inferred that Explode is a CAD behavior
because the domain of its ObjectProperty hasBehaviorType is
CadBehavior according to the reference ontology in Fig. 15.
Its behaviorValue and behaviorDescription (defined elsewhere
in the ontology) information can be further identified and
retrieved through other properties of the Explode instance.
The information will then be executed by the CAD Integration
Toolkit to help the M/E engineer B in model format converting
and in model semantics deployment.
Plan checker C uses a prototype [21] for building code
compliance checking in a testing run. Design object models
are generated from IFC-compliant data files and rule object
models from code regulation references. Fig. 16 lists a sample
code which specifies certain design rules to constrain design
parameters and their relationships for walls in household
shelters (HS).

1112

Q.Z. Yang, Y. Zhang / Computer-Aided Design 38 (2006) 10991112

As the setback distance is not an explicit design parameter in

CAD models of wall, geometric reasoning has to be conducted
to derive its value for comparison with the code, such as through
the following function calls:
getFloorSpaceWallAttributes();
getWallCartesianPoint(); and
calculateSetbackDistance();
which may complicate the checking process and affect its
efficiency. Alternatively, if a wall object is encapsulated with
object behaviors for: (1) object relationship between the HS
clear height and the minimum setback distance; and (2)
behavior set for the constraint values as given in Fig. 16,
the setback distance of the wall is then directly available for
compliance checking.
6. Conclusion
An object CAD based, IFC compliant, and ontology
enabled semantic interoperability approach has been developed
with its software implementation for capturing and reusing
interoperable, semantics-rich information with building design
objects. The approach and the prototype can be used to support
the semantic interoperability of BIMs and project model
data. The building design objects modeled with this approach
and encapsulated with the semantically interoperable design
information could provide multi-disciplinary design teams
and heterogeneous design applications with understandable,
transferable and sharable building information. The use
scenarios have demonstrated the capability and usability of
the prototype in support of building design activities of
architects, structural analysts, M/E engineers and other design
professionals over distributed and heterogeneous environments.
Further efforts will be made, based on the evaluation results,
for extension of the prototype system to provide Semantic Web
services to building design applications and for more studies on
ontology modeling, reasoning, and composition.
Acknowledgements
The authors wish to thank Mr. Rajesh Babu, Mr. Xingjian
Xu, Mr. Jason Cheng, and Dr Lu Cui for their contributions to
software development in this research.
References
[1] International Alliance for Interoperability (IAI). Industry Foundation
Classes IFC 2x. On-line documentation,
http://www.iai-international.org/Model/IFC(ifcXML)Specs.html; 2003.
[2] aecXML, http://iai-na.org/aecxml/mission.php; 2005 [last accessed
10.05].
[3] Zarli A, Richaud O. Requirements and technology integration for IT-based
business-oriented frameworks in building and construction. ITcon 1999;
4:5375.
[4] Aziz Z, Anumba C, Ruikar D, Carrillo P, Bouchlaghem D. Semantic web
based services for intelligent mobile construction collaboration. ITcon
2004;9:36779.

[5] Cheng J, Law K, Kumar B. Integrating project management applications

as Web Services. In: The 2nd int. conf. on innovation in AEC. 2003
http://eil.stanford.edu/psl/publications/jimchenguk3.pdf.
[6] Adachi Y. Overview of IFC model server framework. In: Turk Z,
Scherer R, editors. Proceedings of ECPPM 2002, eWork and eBusiness
in AEC.
[7] Bengtsson K. Using IFCs and EDMmodelServer for BIM implementations. In: Conf. on building information modeling. 2005.
[8] Lai YC. Contribution of semantic web to collaborative design. In:
Proceedings of the 9th CAADRIA04. 2004. p. 91107.
[9] Schreyer M, Hartmann T, Fischer M. Supporting project meetings with
concurrent interoperability in a construction information workspace.
ITcon 2005;10:15367.
[10] Chen D, Vernadat FB. Enterprise interoperability: a standardized view.
In: Kosanke K, et al., editors. IFIP series, vol. 108. Kluwer Academic
Publishers; 2003. p. 27382.
[11] Guarino N. Formal ontology and information systems. In: Guarino N,
editor. Formal ontology and information systems. IOS Press; 1998.
[12] W3C. OWL Web ontology language overview,
http://www.w3.org/TR/2003/PR-owl-features-20031215/; 2005 [last
accessed 10.05].
[13] Brickley D, Guha RV. Resource Description Framework
(RDF) Schema Specification 1.0. http://www.w3.org/TR/2000/
CR-rdf-schema-20000327/.
[14] Stephens J, Dimtsas N, Lima C, Tn A, Steinmann R, Woestenenk
K et al. eCommerce & eBusiness in the building and construction industry.
eConstruct project report. http://www.econstruct.org/6-Public/bcXML
CD/PublicDeliverables/pfr v3b.pdf; 2006 [last accessed 02.06].
[15] Lima C, Fies B, Zarli A, Bourdeau M, Wetherill M, Rezgui Y. Towards
an IFC-enabled ontology for the building and construction industry: The
e-COGNOS approach. In: eSM@RT 2002. 2002.
[16] Turk Z, Dolenc M, Nabrzyski J, Katranuschkov P, Balaton E, Balder R et
al. Towards engineering on the grid. In: Proceedings of ECPPM04. 2004.
p. 17986.
[17] Yang Q. IFC-compliant design information modeling and sharing. ITcon
2003;8:114.
[18] International Alliance for Interoperability (IAI). IFC 2x extension modeling guide.http://www.iai-international.org/Model/documentation/Ifc2x
EMG/EMG-Base.htm# Toc515689786; 2001.
[19] ISO TC184/SC4. ISO 10303 Part 11: Description methods: The
EXPRESS language reference manual. 1994.
[20] Nagasaka I, Kikuchi M, Tsutsui H, Taura T, Ueda K. A model of
design based on generation process of function-attribute classifications.
http://kurt.scitec.kobe-u.ac.jp/kikuchi/papers/iwes01fac.pdf; 2006 [last
accessed 02.06].
[21] Yang QZ, Xu XJ. Design knowledge modeling and software implementation for building code compliance checking. Building and Environment
2004;39:68998.
[22] Rational Software Corporation. Rational Rose 2000e. Cupertino (CA,
USA): Rational Software Corporation; 2000.
[23] Keogh J, Keogh J. J2EE: The complete reference. McGraw Hill;
2002.
Dr. Q.Z. Yang is a Research Scientist with the Singapore Institute of
Manufacturing Technology, Singapore. Dr. Yangs research interests include:
semantic interoperability of information models and systems, building lifecycle
information management, design semantics description and sharing, and
ontology-based engineering applications integration.
Ms. Y. Zhang received her Batchelors degree in Computing and Information
Systems from University of London. Her current research interests are
ontology modeling and reasoning, heterogeneous information sharing, and Web
semantics for e-business and engineering.