INTRODUCTION TO Semantic Exchange Modules (SEMs)

Semantic Exchange Modules (SEMs) are the kernel ofa newly proposed approach for defining IFC Model Views thatis 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. Composabilityapplies 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 exchange[1]. The result is meant to be a structured module that can be validated, and that is composable within larger structures.

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 animportant 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.

Figure 2: Example left-to-right ordered definition of specifying SEMS for a Building Element

A SEMSpecification document page consists of a functional capability defined for users, defining theuses 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 re-using 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 –

Rafael Sacks -

Ivan Panushev -

Manu Venugopal -

Shiva Aram -

[1] These notes address only translation of new models, not yet dealing with incremental updates to an existing model.