INTRODUCTION TO Semantic Exchange Modules (SEMs)
Semantic Exchange Modules (SEMs) are the kernel of a newly proposed approach for defining IFC Model
Views that is more flexible and easy to implement and maintain than other model view methods. SEMs
build upon and expand the notion of Concepts that are used in the IFC Solutions Factory and NBIMS Vol.
1. The following text provides an early provisional definition of SEMs to support their testbed
implementation. These notes are directed toward implementers.
The fundamental aspect of SEMs is that they are
composable modules that a knowledgeable user can select
at run-time to define new or modify existing Model Views
with given target functionality. Instead of software vendors
hard coding every necessary Model View in advance,
model views can be composed by users; a new Model View
can be realized by configuring a set of SEMs for a given
purpose.
In order to define or adapt a module between two or more
applications, there must be consistency of their semantic
definition within the IFC neutral representation. In addition,
to realize composability, a SEM needs to support all the ways it can be composed. That is, an SEM (when
complete) must be able to bind in ALL the possible compositions in which it could be used.
Composability applies to both IFC bindings and native structure bindings, so that this unit of
implementation is complete within a building modeling application. A SEM has the general structure
defined in Figure 1. That is, it is an object with two important structures: (1) the IFC entity structure
representing it in neutral format and (2) the corresponding structure in the native format. These
structures are supported by methods defining a new structure for import (a new instance of the native
structure) or for export (a new instance structure in IFC). Additional methods are needed to support the
integration of the new structures into the larger context of the model exchange1. The result is meant to
be a structured module that can be validated, and that is composable within larger structures.
Figure 1 The basic structure of a single
SEM
SEMS are medium sized modules, generally larger than existing proposed Concepts, but appropriate for
distinguishing all the semantic variations realizable between different applications. They are ordered
compositions, where the context provided by some SEM definitions provides the context for later SEMs.
For example, the IFC Spatial Configuration Hierarchy of Project, Site, Building, Storey is the fundamental
space containment reference in IFC and is defined early, so that later Building Elements may be placed
within the hierarchy. This ordering is an important consideration of SEMS, and it should be composed
so that the number of passes over the data model in order to define a Model View are minimized
(ideally a single pass). An example ordered structure of SEM implementation is shown in Figure 2. This
structure suggests one possible user interface structure for defining or editing of SEMs.
1
These notes address only translation of new models, not yet dealing with incremental updates to an existing
model.
Figure 2: Example left-to-right ordered definition of specifying SEMS for a Building Element
A SEM Specification document page consists of a functional capability defined for users, defining the
uses that the SEM addresses. It includes a technical specification defining the IFC binding and an explicit
definition of the kinds of real world objects that it can represent. This latter definition is generic, not
specific to any given software, and for this reason it cannot represent a precise binding to the internal
software schema. Each software company will need to add its own binding specification for each SEM.
The SEM spec document also suggests a sequence of methods that might be used to integrate each SEM
within the object or project structure, on both the IFC side (for export) and on the native model side (for
import). Rules that delimit more general structures for this particular SEM use are also defined.
THE STRUCTURE OF SEMS
We found it effective to define some SEMs within families. Geometry is a set of SEMS, for addressing a
similar model aspect. Similarly, Building Elements and Building Element Types are two families of SEMS
that have largely the same structure, allowing the family to be easily implemented together or by reusing their structure. SEM families, if followed, simplify implementation.
The structure of SEMs specified in this work are organized by the following criteria:
1. they are aggregated units of IFC entities and structures that internally do not restrict
combinatorial use;
2. Each SEM must address all potential uses, as allowed by its IFC release. This means that its
definition must be insertable in the proscribed order sequence, able to integrate with both its
predecessor and successor SEMs;
3. if IFC structures are always used together, they should belong to the same SEM.
This structure, if followed, allows two or more users to modify a model view by revising the same
(predefined) SEM composition, realizing the same result. Thus model views based on SEMS provide a
level of flexibility not realizable using Concepts or other methods.
We invite comments, notification of inconsistencies and suggestions for improvement of this document
Chuck Eastman – chuck.eastman@coa.gatech.edu
Rafael Sacks - cvsacks@tx.technion.ac.il
Ivan Panushev - ivan.panushev@gatech.edu
Manu Venugopal - manu.menon@gatech.edu
Shiva Aram - shiva_aram@gatech.edu