# Presentation: 103223

## INFORMATION MODELING

**Introduction**
**History**
**Languages**

- Seminar 30: Data Modeling for Building Operation, 2001 ASHRAE Annual Meeting. Copyright © 2001 Marinsoft, Inc. and AEC3 Ltd. All rights reserved.

## Commercial Free!

***All references to relevant research activities are informational only and are not an endorsement or promotion for commercial advantage****** ***

## What is a Model ?

_**a representation**_
**models represent items, that appear in real or virtual worlds**
_**an abstraction**_
**models only capture relevant properties of the items**
_**a subjective interpretation**_
**the selection and the projection of relevant properties is done with subjective judgment**
**therefore:****there is no single model, capturing a considerably complex domain that serves all purposes**
**this is particularly true for building and construction**

## What is an Information Model

_**definition:**_
***An information model is a ******formal description of types****** ******of ideas, facts and processes which together form a model of a ******portion of interest****** ******of the real world and which provides an ******explicit set of interpretation rules****** ***
_**key phrases:**_
**formal description of types**
**the extraction of the structure or concept, the "idea of the thing", that is common for all occurrences of the *****type;***** the extraction should be *****formal***** to provide for an unambiguous understanding of the types**
**portion of interest**
**the well-known "universe of discourse", *****portion***** since only a certain section of the real world domain is considered, *****interest***** since the model depends on the particular view driven by the intention of the modelers**
**explicit set of interpretation rules**
**defines an unambiguous and precise meaning or semantics can be inferred from the *****formal description of types***** **

## Purpose of Information Models

**used to define interface models for ****data exchange**** ****and ****data access**
**used to define data models for ****applications**** dealing with semantics**
**used to define the ****correspondence**** between application and interface**

## Fundamentals of Information Models

**need to represent the ****information**** together with the ****interpretation rules****, i.e. the syntax (or symbols) together with the semantics (or meanings)**
**need to abstract the ****type****, i.e. the common behavior of a set of comparable real world items, from its particular appearance, the ****instance**
**need to ****classify**** the information in categories of information at different ****levels of abstraction**

## What kind of information is captured ?

**What kind of information is captured ?**

**static properties**
**description of classes**
**description of attributes**
**description of relationships**
**dynamic properties**
**description of operations**
**description of events and transactions**
**integrity**
**local constraints**
**global constraints**

## What are objects in an information model ?

**any item of interest, e.g.:**
**things****(physical objects)**
**ideas****(non-physical concepts)**
**processes****(activities, schedules, ...)**
**etc.**

## Which object information is captured

**generic information sets describing ****products ****in ****building and construction**
**systems and system parts**
**versions or states during life cycle**
**requirement and solution attributes**
**component structure (whole - part)**
**context, relations to other products**
**shape information**
**placement**

## What are attributes in an information model

**A characteristic, quality or property of an object**
**Explicit attributes**** - the attribute value is populated by the application**
**Mandatory explicit attributes**** - the attribute value has to exist**
**Optional explicit attributes**** - the attribute value may exist or be not determined (the attribute definition has to be always recognized!)**
**Inverse attributes**** - the existence of an instance may depend on the existence of another instance which uses this entity for definition.**
**Inverse attributes are not explicitly exchange, they are re-associated on the receiving end **
**Derived attributes****Re-declared attributes**

## Levels of Information Model

**conceptual level **
**totally independent from implementation concerns**
**design level **
**take implementation constraints into account**
**implementation level **
**build application according to the model**

## History of Building Product Models

**first predevelopment phase**
**database views, modular systems, CAD**
**second predevelopment phase**
** ****expert systems**
**first generation of building product models**
**second generation of building product models**
**third generation of building product models**

## Pre-runner: ANSI/SPARC layer model

**definition of the ****Conceptual Model**** ****Layers in the ****ANSI/SPARC architecture (1985)**
**external layer**** ****to capture external views (application views) onto the model**
**conceptual layer**** ****to provide a uniform definition of the data for external views being independent of chosen physical layer**
**physical layer**** ****to implement the data, defined in the conceptual layer in an appropriate form, i.e. data base schema**

## First Period: Academic Models

**first generation of building product models**
**academic approaches at universities and research institutes**
**focused on the definition of high-level constructs**
**influenced by the previous expert system development, e.g., frames**
**examples of this period**
**work done in North America**
**Engineering Data Model (EDM) - Eastman, et. al.**
**Building System Model - Turner, et. al.**
**work done in Europe**
**General AEC Reference Model (GARM) - Gielingh, et. al.**
**RATAS Model, Björk, et. al. **

## Academic example: GARM

**General AEC Reference Model**
**circa 1988**
**part of early information modeling activities in STEP **
**high level definition of requirements and solutions**
**known as “hamburger” diagram**

*the functional unit / technical solution*
*top-level definition*

## Academic example: Building System Model

**Building System Model**
**circa 1990**
**part of early information modeling activities in STEP - AEC Group**
**high level definition of building systems and system elements**

*example of the system definition in NIAM*

## Second Period: Joint R&D projects

**second generation of building product models**
**first large development projects**
**focus on more narrow domains, going into the details**
**definition of aspect (or partial) models**
**integration of aspect models, different approaches**
**goals are data exchange and data integration**
**examples**
**COMBINE, JOULE**
**IMPACT, ESPRIT II**
**MARITIME, ESPRIT II**
**ATLAS, ESPRIT III**
**COMBI, ESPRIT III**
**NIDDESC, U.S. Navy**
**STEP**

## Example: COMBINE

**COMBINE Integrated Data Model**
**COMBINE I, 1989-92**
**COMBINE II, 1992-95**
**	****financed by the EC JOULE program to support energy efficient buildings**
**defined the IDM as a set of central data integration schemas**
**provided interfaces for performance evaluation tools**
**final aim: develop computer-based Integrated Building Design System**

*above: application integration in COMBINE*
*below: instep viewer developed in COMBINE*

## Example: COMBI

**COMBI, ESPRIT III project 1993-96**
**focus on the development of integrated expert systems **
**from foundation design and structural analysis**
**includes ****model mapping**** between the different information models and the CAD integration layer**
**CAD integration using layer convention and STEP part 201**

## Third period: Integrated models 

**Focus on collaborative design**
**idea: “middle ware” or “model server”**
**Explored in:**
**VEGA (Virtual Enterprise Groupware Architecture) - ESPRIT IV**
**ToCEE (Towards Concurrent Engineering Environment) - ESPRIT IV**
**STEP Building and Construction**
**Industry Alliance for Interoperability**

## STandard for the Exchange of Product data (STEP) 

**ISO 10303 (STEP) is an International Standard for the computer-interpretable representation and exchange of product data**** **
**ISO 10303 uses a formal data specification language, EXPRESS, to specify the representation of product information**** **

## Industry Alliance for Interoperability (IAI) 

## Modeling Languages 

**classical product modeling languages**
**IDEF, NIAM, EXPRESS, etc.**
**database design language**
**Entity-Relationship methodologies**
**OO analysis and design languages**
**Booch, OMT, UML, etc.**

## Different keywords are used 

**Modeling language keywords != OO language keywords!**
**Entity = class**
**Instance = object**
**Attribute = attribute**
**?? =  operation**
**Relation = association**
**Cardinality = cardinality**
**Inheritance = inheritance**
**Rule = constraint**

## Example for Language Comparison

**consider the following use case:**
**A building stair connects at least two different levels within a building.**** **
**A building stair has at least three steps**** **
**A building stair is subjected to the riser/tread ratio**** **
**The riser/tread ratio is given by 2_x_Riser / Tread = 63 cm +/- 3 cm**** **
**therefore:**
**building, level, and stair are named**
**riser and tread are descriptions of the stair**** **

## From Natural to Formal Language 

**	****Creation of assertions using natural language, removing all connotations, and generating no further reducible sentences:**
**Buildings ***have*** levels**** **
**Buildings ***may have*** **_**two or more**_** levels**** **
**stairs ***can be used in*** buildings**
**stairs ***connect*** **_**at least two**_** levels**
**where:**
**noun - indicates ideas (class or attribute)**** **
*verb*** - indicates relationships**** **
_**cardinality**_** - indicates numerical context**** **

## Entity-Relationship Model 

**first introduced by Chen in 1976**** **
**generalisation of network, relational and set model**** **
**E-R view of world mainly consists of entities, relationships and attributes**** **
**inheritance originally not supported**

## EXPRESS and EXPRESS-G

**primarily used in STEP and IAI communities**
**adopted as international standard under ISO 10303 in 1994**** **
**EXPRESS is the lexical language, EXPRESS-G is its graphical representation**
**specifies standardised implementation methods, STEP physical file and standard data access interface (SDAI)**
**subtype-supertype hierarchies supported**** **
**basic constructs: entity, attribute relation, types and constraints**** **
**special emphasis on data types and constraints on instances of data types**

## EXPRESS and EXPRESS-G Model 

**ENTITY stair**
**ABSTRACT SUPERTYPE OF (ONEOF **
** ****( stairs_with_straight_flights , spiral_stair );**
** ****used_in : building;**
** ****connects: LIST [2:2] OF level;**
** ****steps   : INTEGER;**
** ****tread   : REAL;**
** ****name    : STRING;**
**DERIVE**
** ****riser   : REAL **
**         ****:= connects[1].heigth / steps;**
**UNIQUE**
** ****ur1 : name;**
**WHERE**
** ****wr1 : 2 * riser / tread <= 66 AND**
**   ****2 * riser / tread >= 60;**
** ****-- riser and tread are measured in cm**
**END_ENTITY;**** **

## UML

**primarily used by software developers**
**notation supports OO programming by catering to object, dynamic and functional modelling**
**evolved out of OMT and Booch notations**
**subtype-supertype hierarchies supported**** **
**basic constructs: object class, attribute, operation, association**

## Modeling Considerations

**meta-model**
**extensibility**
**guidelines for modifications**
**backward and forward compatibility**
**mapping**
**documentation**
**dictionary of terminology**
**use cases, processes, actors, etc.**
**issues, implementer agreements**
**conformance**
**syntax, semantics, test cases**
**‘****facilitated approval’**

## A final thought ...

***A theory has only the alternative ******of being right or wrong. ***
***A ******model****** has a third possibility: ******it may be right but irrelevant.***

- Manfred Eigen

## End of basic concepts!