NBSIR 88-3754

A Global Model for Building-Project

Information: Analysis of Conceptual

Structures

William F. Danner

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

National Engineering Laboratory

Center for Building Technology

Gaithersburg, MD 20899

April 1988

75 Years Stimulating America s Progress 1913-1988

U.S. DEPARTMENT OF COMMERCE

NATIONAL BUREAU OF STANDARDS

NBSIR 88-3754

A GLOBAL MODEL FOR BUILDING-PROJECT

INFORMATION: ANALYSIS OF CONCEPTUAL

STRUCTURES

William F. Danner

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

National Engineering Laboratory

Center for Building Technology

Gaithersburg, MD 20899

April 1988

U.S. DEPARTMENT OF COMMERCE, C. William Verity, Secretary

NATIONAL BUREAU OF STANDARDS, Ernest Ambler, Director
.

*
Abstract

The development of a consensus model for building-project information requires a

precise description of the meaning of the information to be maintained. This report

presents an analysis of the conceptual structures that are available to specify that meaning using a proposed "global model" as an example. The model is currently under

development by the Architecture, Engineering, and Construction (AEC) Committee

of the Initial Graphics Exchange Specification (IGES) / Product Data Exchange

Specification (PDES) Organization.

The key conclusion of this analysis is that a core semantic vocabulary is needed. This

core vocabulary derives from how meaning is expressed without regard for specific

domains of information. Preliminary elements of such a core vocabulary are defined.

Further, a means by which that core is extended to add necessary domain-specific

semantics is presented. The analysis has identified those aspects of developing a global

model for building-project information that should proceed in the context of a broad

interdisciplinary effort to represent information and those that require extensive technical input from the building industry.

Keywords: building data; building information; conceptual modeling; data modeling;

information modeling; semantic modeling
Acknowledgments

The author wishes to thank Dr. Kent Reed, Head of the Computer Integrated Construction (CIC) Group for his continued support and direction of this work.

Special appreciation is extended to all those who contributed through many hours of

discussion. They include but are not limited to: Mr. Mark Palmer of the CIC Group

for his knowledge and direction regarding AEC standardization efforts; Ms. Linda

Parks, formerly of the CIC Group, for her valuable insights and suggestions concerning semantics and natural language processing; and Ms. Joan Milloy of Control Data

Corporation for her practical suggestions for representing complex ideas.

Appreciation is also extended to Ms. Joan Tyler and Ms. Mary Mitchell of the Factory

Automation Systems Division of the Center for Mechanical Engineering at NBS for

their technical review of this report.

©

IV
Table of Contents

1. Introduction 1

1.1 Background 1

1.2 Terminology 1

1.3 Purpose and Organization .2

2. Analysis of Conceptual Structures 3

2.1 Overview 3

2.1.1 Concepts 3

2.1.2 Ideas 4

2.1.3 Relationships 4

2.1.3

Relations and Roles 4

2.2 Relationship Types 5

3. Specifying Ideas 9

3.1 Alternative Representations 9

3.1.1 Symmetric Representation .9

3.1.2 Relational Representation 10

3.1.3 Graphic Representation 10

3.2 Defining and Using Relationship Types 11

3.2.1 Active Relationships 11

3.2.2 Dative Relationships 12

3.2.3 Locative Relationships 16

3.2.4 Partitive Relationships 17

v
3.3

Complex Ideas 18

3.3.1 Representing Complex Ideas 19

3.3.2 The Utility of Complex Ideas 20

4. From Initial Concepts to Constructs 21

4.1 Developing Concepts ....... .21

4.2 Identifying Constructs .......... ............. 22

4.2.1 Composites 22

4.2.2 Sets 23

4.2.3 Classifications 24

4.3 Prototypes 27

5. Summary and Conclusions: 33

5.1 The Conceptual Schema Development Process 33

5.2 Natural Expression of Ideas 34

References 35

VI
List of Tables

Table 1. Example Ideas using Four Relationship Types . 5

Table 2. Relations of the AEC Descriptive Model 6

Table 3. Ideas Using Active Relationships of the AEC Model 13

Table 3. (continued) . .14

Table 4. Ideas Using Dative Relationships of the AEC Model 15

Table 5. Locative Relationships of the AEC Model. .... 17

Table 6. Ideas in a Building_System Classification 27

Table 7. Ideas in an Engineering_System Prototype 28

Table 8. Inherited Ideas of an HVAC_System Concept 29

Table 9. Non-Inherited Ideas of an HVAC_System Concept 30

Table 9. (continued) 31

Table lOf Natural Expression of Ideas by Relationship Type 35

List of Figures

Figure 1. A Building_System Classification 25

Figure 2. An Alternative Building_System Classification 26

VII
. , * ,
1. Introduction

1.1 Background

There has been considerable interest in recent years in the possibility of developing a global conceptual model for building-project information. This interest has intensified

with the advent of semantic modeling techniques in both the fields of database management and artificial intelligence [1,2]. Application of such techniques presents the possibility of encoding building-project information in an accessible and meaningful form

for all participants in the building process over the entire life-cycle of a building.

The Initial Graphics Exchange Specification (IGES) / Product Data Exchange

Specification (PDES) Organization is developing a "global model" 1 for building-project

information within its Architecture, Engineering, and Construction (AEC) Committee

[3]. Other conceptual models are also being developed in conjunction with the

IGES/PDES AEC Committee, however, reference to the AEC Model in this report

refers to the "global model." This AEC Model is a first step toward the long term goal

of a global building-project information model. It is being developed to represent a

finite time in a building’s life-cycle as a means of limiting the scope of the problems en- countered in establishing industry-wide specifications for such a large domain of information.

1.2 Terminology

The central focus of this report is the specification of meaning (i.e., semantics) in the

development of an information system at the logical level. It represents a synthesis of

approaches to this topic from a number of disciplines including database management,

artificial intelligence, and linguistics as well as from the building industry. Terminology both within and between these disciplines is extremely varied. For example, what

has been described as a conceptual model by the IGES/PDES AEC Committee is often

referred to in the database literature as a conceptual schema. The term "data model"

in this context identifies a formal approach to specifying a conceptual schema. This

report adopts the use of the word "model" as used by the AEC Committee and uses it interchangably with the term schema. The distinction between model (i.e., schema)

and data model is maintained.

1 This model has recently been renamed the "Building Systems Model" (March 1988).
Throughout this report, terminology has been adopted that is eclectic among the disciplines listed above. Therefore, definitions are given as terms are encountered. The

terms have been chosen to facilitate the discussion of the topics being presented rather

than to endorse any given formal approach to conceptual modeling.

1.3 Purpose and Organization

This report addresses issues of knowledge representation and semantic modeling in the

context of the preliminary AEC Model for building-project information. Of particular

importance is the initiation of a discussion on the process by which such a model is developed and the conceptual structures that are chosen to represent information

during that process.

After the introductory remarks of this section, Section 2 presents an overview of the

basic conceptual structures used in the current AEC Model. The specification of ideas

is described as both the identification of largely domain specific concepts and the selection of more generic relationships that serve to establish the logical connections between concepts. The relationships of the AEC Model are then discussed in terms of

categories based on the grammatical constructions used in their specification.

Several alternative representations for specifying ideas are presented in Section 3. They include symmetric, relational, and graphic representations. Conversion from one

form to the other is discussed. Relationship types reflecting the categories identified

in Section 2 are then defined. The use of relationship types is suggested as a means by

which a systematic approach to the specification of ideas can be established.

Section 4 returns to the topic of identifying concepts. Their development through

specification of ideas is outlined. The discussion then proceeds to the identification

and development of constructs formed by a group of hierarchically related ideas. The

section ends with a discussion of concepts that serve as prototypes for other concepts.

Examples from the current AEC Model are used extensively.

Section 5 presents a summary which reviews the conceptual model development

process. Conclusions include recommending the use of a systematic approach to the

specification of the conceptual structures. In particular, the use of relationship types in

defining relationships and the explicit identification of constructs and prototypes that are central to the overall organization of building information are advocated. The final

sections present an overview of the schema development process and the utility of a core conceptual vocabulary that serves as the foundation for domain specific information models such as those being developed for the building industry.

2
2. Analysis of Conceptual Structures

2.1 Overview

The AEC Model has served as a basis for prototype information system implementations which have been used as testbeds for investigating topics of knowledge representation and schema development. Specifically, a frame-based information system

has been implemented using a knowledge-base development environment on a Lisp

machine and a predicate logic based relational information system has been implemented in Prolog with an emphasis on user interface characteristics. The latter system

was used to explore desirable characteristics of a schema development environment

that would be of assistance in the specification of conceptual structures. A discussion

of the preliminary AEC Model follows based on observations made during the implementation of these testbed systems.

2.1.1 Concepts

"Concepts" in the context of this report represent a class of uniquely identifiable things,

events, or notions. Examples include the central concept of a building project in the case of the AEC Model and the building and site that are parts of a building project.

Within the field of conceptual modeling, concepts are variously described as concepts

[4,5], object classes [1], or entity types [6,7]. Each of these terms is meant to indicate

that a concept does not represent a particular building for example, but rather represents a class of which there can be many instances, in this case many buildings.

1

The preliminary AEC Model contains over 500 concepts, many of which are domain

specific. That is, most of the concepts have been specified in the early stages of the

AEC Model development for the explicit purpose of communicating information about

buildings. No attempt has been made in this report to evaluate the suitability of the

concepts chosen or their ultimate usability in a global information model. This task

falls clearly within the scope of the members of the AEC Committee and others within

the AEC community who will select concepts based on the needs of the participant

groups they represent. Rather, issues of knowledge representation that apply to these

concepts as they have been defined and which would have essentially equal validity for

other concepts are discussed in the sections which follow.

1 The IGES/PDES Organization has adopted the terminology of "entity" to represent a concept and "occurrence" to represent an instance of a concept.

3
2.1.2

Ideas

"Ideas" are composed of several concepts and a relationship that establishes a logical

connection between those concepts. "Building has-part building-element" is an ex- ample of an idea.

2.1.3

Relationships

"Relationships" represent the logical connections between concepts in a conceptual

model. In stating the idea that "building has-part building-element," one is stating that

there exists a whole-to-part relationship between the concept "building" and the concept "building-element". Frequently in defining ideas, conceptual models make use of

alternative ways of stating the idea when taking the perspective of one or the other concept. Therefore, "building has-part building-element" and "building-element part-of

building" can be seen to be aspects of the same idea. These representations can be considered to be an obverse and inverse representation of the idea. What is emphasized

in such representations is the role played by each of the concepts. The idea can be considered from the perspective of the building (the whole) or the building-element (the

part) each of which leads to a slightly different statement of the relationship ("has-part"

and "part-of

1 respectively).

2.1.3

Relations and Roles

A relationship can be specified most clearly in terms of a relation and its associated

roles. A "relation" identifies the nature of the logical connection. A "role" is a link that

can be used between a relation with which it is associated and a concept in forming an

idea. A role identifies the function of the concept in the idea. (See also [8].)

The "has-part/part-of

1 relationship pair combines the "part" relation with other words

that indicate the roles played by each concept in an idea. In the obverse representation

of our example, the verb "has" in combination with part identifies the role of the whole

as being primary ("building has-part building-element"). In the inverse representation,

the preposition "of identifies the role of the part as primary ("building-element partof building"). Relationship pairs like "has-part/part-of then are one means of conveying the semantics of both a relation and associated roles of the concepts in an idea.

Often, however, the representation of the relationship from the perspective of one concept is quite obvious, but from the perspective of the other concept seems forced or

unclear. It is straight forward to say "lighting-fixture in ceiling" but much less so to say

"ceiling around lighting-fixture." Lack of clarity often results in ideas being defined in4
completely. There are alternative ways of representing relationships explicitly in terms

of relations and associated roles. These will be discussed in subsequent sections.

The AEC Model contains over twenty distinctly different relations. These relations

tend to be more generic (i.e., less domain specific) than the concepts of the model. The

relation "part” is an example of a relation that is clearly not limited to the building industry. In fact, the possibility that there exists a finite set of generic relations will be

considered in later sections. Developing a particular model such as the AEC Model

could therefore involve a process of selection from among generic relations, defining

new domain specific relations only when necessary.

2.2 Relationship Types

The preliminary AEC Model uses an idea representation that employs the use of

relationship pairs such as "has-part/part-of' in defining ideas. Four general types of

relationships have been identified. The relationship types derive from certain grammatical constructions that can be used in the specification of ideas [8]. They include

active, dative, locative, and partitive relationships. Obverse and inverse representations of example ideas using these relationship types are listed in Table 1.

Table 1. Example Ideas using Four Relationship Types.

Relationship Type Obverse Representation Inverse Representation

Active x controls y y controlhd-by x Dative x conducts-z-to y y receives-z-from x

Locative xony y under x

Partitive x has-party ypart-oix

An active relationship uses a verb in the active and passive voice in its obverse and in- verse representations respectively. The idea "hvac-system controls air-quality" is an ex- ample of an obverse representation. An active relationship is most easily identified by

the inverse representation which uses the preposition "by" as in "air-quality controlledby hvac-system." A listing of the active relations contained in the AEC Model is presented in Table 2. Active relations in this table are named by verbs only without

reference to the use of the preposition "by" used to distinguish roles.

5
Table 2. Relations of the AEC Descriptive Model.

Active Dative Locative Partitive

accesses (5)*

connects (8)

contains (5)

controls (1)

defines (3)

divides (5)

generates (2)

protects (1) serves (6)

supports (2)

triggers (1)

applies

-finish (1)

conducts

-waste (7)

-water (9)

exhausts

-air (3)

leads

-[person] (1)

in (2)

on (2)

function (20)

part (20)

StS6t

(485)

subtype

* Numbers in parentheses indicate

frequency of occurrance.

A dative relationship is more complex than an active relationship. Dative relationships include a verb with the prepositions "to" and "from" in their obverse and inverse

representations. An example of a dative relationship from the AEC Model is "gutter

conducts-water-to down-spout." The AEC Model does not contain an inverse for this

relationship though something like "down-spout receives-water-from gutter" might be

chosen. Three concepts are identifiable (e.g., gutter, water, and down-spout) in an idea

containing such a dative relationship. The idea typically involves the transfer of a thing

from one object or place to another. Ideas involving transferrence (often discussed in

the context of "directed networks") deserve special attention. The AEC Model chose

to use a single binary representation for an idea involving a dative relationship in which

the thing being transferred is included as part of the relationship. Alternatives to this

approach will be discussed in subsequent sections. (See 3.2.2 and 3.3.)

Table 2 lists the dative relations of the AEC Model. There are five relationship pairs

which identify dative relations. They include "applies-finish-to," "conducts-waste-to,"

"conducts-water-to," "exhausts-air-to," and "leads-[person]-to" (and their inverses).

The prepositions "to" and "from" are not included in Table 2 since these prepositions

serve to identify roles rather than the relation itself. Further, the verb and the object

which constitutes the third concept in a dative relationship are separated. An advantage of listing dative relations in this way is that it identifies each of the elements

explicitly. Within the AEC Model the relationship involving the application of a finish

6
does not involve three concepts as does the generalized dative relationship. Rather it is expressed as "finish applied-to enclosure-component." A dative relationship using

the generalized form would suggest an implied third concept, perhaps "[subcontractor]

applies-finish-to enclosure-component." Similarly, there is an implied concept in the

relationship "emergency-egress-route leads-[person]-to exit."

A locative relationship is identified by a preposition as in "lighting-fixture in ceiling."

1 The inverse representation of locative relationships are not always clear. Though technically speaking one might use "ceiling around lighting-fixture," this inverse relationship seems quite unnatural which may account for the fact that the AEC Model does

not include an inverse for this relationship. Alternative means of specifying the roles

played by concepts in a relationship can be employed to allay this difficulty. This is of

particular interest since relations involved in locative relationships appear to be generic

rather than domain specific lending them to standardization.

A partitive relationship is identified by the use of a noun in combination with the verb

"has" in the obverse and by the preposition "of' in the inverse. "Building has-part building-element" and "building-element part-of building" are examples of a partitive

relationship.

2

Moreover, the relationship pair "has-part/part-of' identifies a whole-topart relationship that is a member of a subcategory of partitive relationships involving

generalization [9]. Part-generalization can have implicit characteristics in knowledgebased information systems. For example, instances of a concept representing a whole

can have instances of parts assigned automatically. This is a special kind of inheritance

that can be very useful. Therefore, the appropriate use of part-generalization should

be considered in the development of a conceptual schema.

Generalization can also be indicated by two other relationship pairs, "has-subset/subset-of' and "has-subtype/subtype-of."

3 The former pair identifies a set-generalization.

Set-generalization does not involve inheritance of ideas. This derives from the fact that

there are not inherent similarities among members of a set other than that they are each members of the same set. An example from the AEC Model is the concept of

topography ("topography has-subset elevation," "topography has-subset orientation,"

and "topography has-subset slope"). In these ideas the concept "topography" is identified as comprising subsets of information on elevation, orientation, and slope. These

subsets taken together constitute what is meant by topography. They do not inherit

ideas from the concept topography which they serve to define.

1 Locative relationships have an implied verb "is" as in "lighting fixture is-in ceiling."

2 The inverse representation of a partitive relationship has an implied "is" as in "building-element is-part-of building."

3 In many knowledge-based systems, the "has-subtype/subtype-of' relationship pair is dis- cussed as the "is-a" relationship, where "subtype" is implied but not stated explicitly.

7
Type-generalization uses the third relationship pair used in generalizations ("has-subtype/subtype-of'). "Engineering-system has-subtype mechanical-system" and the in- verse "mechanical-system subtype-of engineering-system" is an example. The use of

these relationship pairs identifies a type-generalization which can be extended from

one concept to another forming a type-generalization hierarchy. An important aspect

of such use of type-generalization is the fact that many knowledge-based information

systems use type-generalization for inheritance. That is, the concept mechanical-system would inherit ideas from the concept engineering-system.

The distinction between generalizations involving parts, subsets, and subtypes can be

of major importance in developing conceptual schemas. This selection is often complicated, however, by the fact that the distinctions made here between part-, set-, and

type-generalization are not universally observed by various modeling techniques. In

the case of the AEC Model, the use of a particular modeling technique has resulted in

some confusion among these choices.

1

In addition to generalization, a second subcategory of partitive relationships involves

what can be grouped together as characterization. This category includes all partitive

relations that do not involve generalization. An example would be the relationship pair

"has-function/function-of." As with the concepts themselves, relations used to characterize concepts can be either generic or domain specific in contrast to those involving

generalization which include the three generic relations: part, subset, and subtype.

Table 2 lists the frequency of occurrence of the relations in the AEC Model. At the

current phase of development most relationships involve generalization (i.e., the relations part, subset, and subtype). This reflects the development of the top level of or- ganization for the conceptual schema and the descriptive function of the AEC Model

It has also been observed that locative and partitive relations involving generalization

tend to be generic (i.e., less domain specific). In contrast, the active and dative relations appear to be more specific to the building industry. Partitive relations involving

characterization can be either generic or domain specific. Whether these tendencies

will continue to be true as the AEC Model is developed and whether conceptual

schemas in other domains display these same tendencies requires further attention. It represents an area of schema development and specification where various domains

can contribute to one another’s precision as well as holding potential for long term compatibility among domain specific systems through the development of conventions.

1 The data model used by the IGES/PDES AEC committee in developing its "global model" is referred

to as information analysis [10]. The notation used by information analysis provides a unique and

simple representation for type-generalization. It does not, however, provide similar capabilities for

part- and set- generalization.

8
3. Specifying Ideas

3.1 Alternative Representations

The field of conceptual modeling has in recent years had many alternative methods

suggested for representing semantics in conceptual schemas [1]. Often these representations are part of a comprehensive approach to conceptual modeling called a data

model (though it might be more useful to think of these data models as conceptual

tools). The alternative representations have as their goal the expression of the underlying meaning of a conceptual schema. Three general ways of representing ideas are

useful in discussing the AEC Model. They include symmetric, relational, and graphic

representations.

3.1.1 Symmetric Representation

The most intuitive of the three representations is referred to here as a symmetric representation. The ideas of the AEC Model and the description of example ideas in Section 2 use a symmetric representation. Symmetric representations account for the fact

that the concepts are often of central importance in understanding a conceptual

schema. With this in mind, one defines relationship pairs that suggest the roles played

by each of the concepts in an idea such that the idea can be viewed from the perspective of any given concept. In many information systems, the relationship pairs are defined as individual but associated "relations." They are associated in the sense that

they are the inverse of one another. Therefore, when the idea "building has-part building-element" is established in such a conceptual schema, the inverse "building-element

part-of building" should also be established.

Two types of difficulties are often present in developing a conceptual schema using a symmetric representation. The first is the uncertainty in assigning inverse roles. If we

wish to establish "lighting-fixture in ceiling," is the inverse "ceiling around lighting-fixture?" The second difficulty involves semantic errors that stem from mixing relations.

The classic example not taken from the building industry is the use of "x grandfatherof y" and "y grandson-of x." In addition to not taking into account granddaughters, the

establishment of these relationships as being inverses of one another misses the fact

that there are two relations employed with the following relationship pairs: "hasgrandfather/grandfather-of' and "has-grandson/grandson-of." Developing a conceptual schema using a symmetric representation of relationships always has the potential

for difficulties of the above kinds.

9
3.1.2 Relational Representation

An alternative to the symmetric representation of ideas is the use of a relational (or

predicate logic) representation. The meaning contained within the relationship pairs

of the symmetric representation is established through the use of compositional semantics (i.e., the position in an abstracted idea). The first element of the idea is the relation that describes the logical connection between concepts. The position of each subsequent concept within the idea indicates its role. In the above example, the relation

"part" would be used to define an abstract idea involving appropriate roles such as "part

(Whole, Part)."

1 Then for a given instance of the abstract idea, the role played by each

concept is established by its position as in "part (building, building-element)."

A relational representation alleviates uncertainty that derives from the need to define

relationship pairs required by a symmetric representation. However, since there is no

standardization with regard to which position within an abstract idea will identify a given role, assignment is left to the developer and can vary from one system to the next.

Even within a given system it is uncertain intuitively which role is associated with which

position. Som§ degree of consensus on this topic would be most beneficial.

3.1.3 Graphic Representation

Another representation useful in specifying ideas employs a graphical notation such as that developed to represent the meaning contained in natural language called the conceptual graph [4]. A conceptual graph uses brackets to enclose concepts and parentheses to enclose relations between concepts. Directed arrows connote implicit roles

of the concepts in the idea. The conceptual graph for a whole-to-part relationship between "building" and "building-element" is expressed as:

[ building ] — (part) -> [ building-element ]

Using a relation in a conceptual graph suggests that it has previously been declared to

be a relation associated with explicit roles. A formal derivation of a relation using conceptual graphs is beyond the scope of this report [4]. However, the above idea involving the part relation can be stated simply but explicitly using the following notation:

1 The language Prolog [11] uses this syntax which can be used to specify ideas in an information sys- tem. Alternatively, a relational representation can be expressed as a simple list of elements as in

"[part, Whole, Part]."

10
( part )

- {Whole} -

[ building ] {Part} -

[ building-element ]

This can be generalized to the following abstract representation of an idea:

( Relation )

- {Role} - [ Concept ] {Role} - [ Concept ]

3.2 Defining and Using Relationship Types

In reviewing the AEC Model, it was observed that many of the ideas were similar in

terms of the relationships used. Four relationship types were sufficient for grouping

all relationships. The relationship types used for this purpose were Active, Dative,

Locative, and Partitive. These names were chosen to reflect natural language constructions that can be used in expressing relationship pairs in a symmetric representation of

ideas. The notation introduced in the previous section can be used to define the four

relationship types with explicit roles which hold for all relationships that are of that

type.

3.2.1 Active Relationships

Active relationships are defined using an active relation (ActRel) and roles identifying

an actor (Actor) and an acted upon object (ActObj) as follows (the relationship appears in bold face in this and subsequent definitions of relationship types):

( ActRel )

- {Actor} - [ Concept ] {ActObj} -

[ Concept ]

Specifying an idea that uses an active relationship therefore requires identifying the

ActRel and the Concepts in accordance with this type definition.

( controls )

- {Actor} -

[ hvac-system ] {ActObj} -

[ air-quality ]

11
Active relationships therefore are seen as comprising an active relation and two concepts that fulfill the roles of Actor and ActObj. Since the specification of such a relationship serves to declare the existence of a given active relation, it can thereafter

be represented in an implicit representation as:

[ hvac-system ] (controls) -> [ air-quality ]

This is the format that was first introduced for an implicit graphic representation of an

idea, but has been derived in a way that removes ambiguity as to the roles played by

each concept in the idea. Establishing the roles which are a part of the graph makes

the meaning explicit. Table 3 lists the ideas which involve active relationships in the

AEC Model in terms of an ActRel, an Actor, and an ActObj.

Once defined in this fashion, specifying a relational representation for ideas using active relationships can be stated in terms of the following abstraction and example:

ActRel (Actor, ActObj)

controls (hvac-system, air-quality)

If there is consensus on the order in which the roles are listed for the abstracted idea, a source of confusion is avoided in specifying all further ideas that use this relationship

type.

3.2.2 Dative Relationships

Dative relationships have been defined using a dative relation (DatRel) and roles identifying a dative object (DatObj), a source (Source), and a target object (Target) as follows:

( DatRel )

- {DatObj} -

[ Concept ] {Source} -

[ Concept ] {Target} -

[ Concept]

Specifying an idea that uses a dative relationship therefore requires identifying the DatRel and the Concepts playing the roles of DatObj, Source, and Target.

(conducts) - {DatObj} -[water]

{Source} -[gutter]

{Target} -

[ down-spout ]

12
Table 3. Ideas Using Active Relationships of the AEC Model.

ActRel Actor ActObj

accesses artificial-light-system

engineering-system

natural-light-sytem

electrical-system

utility-system

opening

connects air-distribution-network

electric-circuit-network

footing-drain

stack

water-distribution-network

water-distribution-network

water-distribution-network

water-distribution-network

hvac-distribution-device

electrical-component

cleanout

vent

water-fixture

hvac-distribution-device

standpipe-component

sprinkler-component

contains circulation-system

emergency-egress-route

enclosure-component

occupied-room

space

emergency-egress-route

room

opening

furniture

equipment

controls hvac-system air-quality

defines enclosure-system

external-envelope

internal-subdivision

room

exterior

interior

divides electric-zone

hvac-zone

lighting-zone

sprinkler-zone

standpipe-zone

electrical-system

hvac-system

lighting-system

sprinkler-system

standpipe-system

(continued)

13
! Table 3. (continued)

ActRel Actor ActObj

generates luminaire

luminaire

heat

noise

protects over-current-device electric-circuit-network

serves street-main

meter

service-equipment

feeder

branch-circuit

junction-box

meter

service-equipment

feeder

branch-circuit

junction-box

electric-equipment-network

supports structural-system

raceway

building-system-component

electric-circuit-network

triggers control instrument

An idea involving a dative relationship therefore is seen as comprising a dative relation and three concepts that fulfill the roles of DatObj, Source, and Target. Table 4

lists the ideas that involve dative relationships in the AEC Model in terms of these components.

An implicit representation of a dative relationship is problematic in that it is not a binary relationship. Dative relationships can be viewed as a binary relationship in which

the DatRel and DatObj are combined to form a unique relation. The AEC Model ex- presses dative relationships in this fashion. The implicit representation of an idea involving a dative relationship resulting from the combination of the DatRel and the DatObj is as follows:

[ gutter ] (conducts-water) [ down-spout ]
Table 4. Ideas Using Dative Relationships of the AEC Model.

DatRel Source Target

-DatObj

applies

-finish [subcontractor] enclosure-component

conducts

-waste branch-soil-pipe stack

building-drain bulding-trap

building-sewer main-sewer

building-trap building-sewer

fixture-trap branch-soil-pipe

fresh-air-fixture fixture-trap

stack building-drain

-water down-spout discharge-component

footing-drain sand-interceptor

gutter down-spout

gutter roof-drain

large-paved-area discharge-component

roof gutter

roof-drain discharge-component

sand-interceptor discharge-component

steep-slope discharge-component

exhausts

-air branch-vent vent

fresh-water-fixture branch-vent

vent vent-stack-terminal

leads

[-person] emergency-egress-route exit

15
A relational representation for such an idea involving a binary dative relationship can

be stated in terms of the following abstraction and example:

DatRel-DatObj (Source, Target)

conducts-water (gutter, down-spout)

The alternative to the above combination of the DatRel and the DatObj is a representation which accommodates a tertiary relationship.

DatRel (DatObj, Source, Target)

conducts (water, gutter, down-spout)

The latter representation of an idea involving a tertiary dative relationship is preferred

to the form which combines the dative relation and object. (See Section 3.3 for a further discussion of this topic.)

3.2.3 Locative Relationships

Locative relationships have been defined using a locative relation (LocRel) and roles

which identify a located object (LocObj) and a location (Location) as follows:

( LocRel )

- {LocObj} -

[ Concept ] {Location}- [ Concept ]

Specifying an idea that uses a locative relationship requires identifying appropriate

components in accordance with the type definition.

(in) - {LocObj} -

[ lighting-fixture ] {Location}- [ ceiling ]

Ideas which involve locative relationships are seen as comprising a locative relation and

two concepts that fulfill the roles of LocObj and Location. Table 5 lists the ideas involving locative relationships of the AEC Model in terms of a LocRel, a LocObj, and

a Location.

16
Table 5. Locative Relationships of the AEC Model.

LocRel LocObj Location

in lighting-fixture ceiling

outside-siamese-connector exterior-wall

sprinkler-head ceiling

on building site

roof-manifold roof

An implicit representation of the above example idea using a locative relationship is:

[ lighting-fixture ] -» (in) -* [ ceiling ] Arelational representation for ideas using a locative relationship can be stated in terms

of the following abstraction and example:

LocRel (LocObj, Location)

in (lighting-fixture, ceiling)

Though most locative relationships are binary there exists the possibility of tertiary or higher order locative relationships. The relation "between" requires the ability to deal

with higher order relationships. A locative relationship involving the relation between

would necessarily have at least two (and possibly more) concepts with the Location

role. Since the roles of each of these concepts is the same, additional locations can be

accommodated by repeating that role.

3.2.4 Partitive Relationships

Partitive relationships have been defined using a partitive relation (ParRel) and roles

indicating a primary object (PrimObj) and an auxiliary object (AuxObj) as follows:

( ParRel )-

{PrimObj} -

[ Concept ] {AuxObj }

-

[ Concept ]

17
The roles PrimObj and AuxObj have been chosen so they can be applied to both subcategories of partitive relationships (i.e., both generalization and characterization).

Specifying an idea using a partitive relationship requires identifying each of the components:

(subtype) - {PrimObj} -

[ engineering-system ] {AuxObj} -

[ mechanical-system ] An idea involving a partitive relationship therefore has a partitive relation and two concepts that fulfill the roles of PrimObj and AuxObj. An implicit representation of the

above idea is:

[ engineering-system ] (subtype) -* [ mechanical-system ] A relational representation for an idea using a partitive relationship can be stated in

terms of the following abstraction and example:

ParRel (PrimObj, AuxObj)

subtype (engineering-system, mechanical-system)

Most ideas in the AEC Model involve partitive relationships. A table of the ideas that

employ partitive relationships in terms of ParRel, PrimObj, and AuxObj is not included

in this report. Most of the partitive relations of the AEC Model (see Table 2) involve

generalization but do not consider the distinctions suggested previously. In those cases where inheritance is judged to be relevant, the distinction between part- and typegeneralization should be considered. In those that do not involve inheritance, setgeneralization is appropriate. This topic will be discussed in terms of specific examples

used to organize information within the conceptual schema in Section 4.2.

3.3 Complex Ideas

Ideas involving dative relationships contain a dative relation and three concepts (an

arity of three when considered from the perspective of a relational representation).

Such ideas while easily represented in a relational form are not represented accurately by a single symmetric binary idea. Therefore, an alternative representation is desirable. A complex idea requires a representation which employs more than one binary idea to convey the required semantics.

18
3.3.1 Representing Complex Ideas

An idea involving a dative relationship contains a dative relation (DatRel) and three

concepts having the roles of a dative object (DatObj), a source (Source), and a target

(Target) as in the following example (not from the AEC Model):

(ships) - {DatObj} -

[ material ] {Source} -

[ supplier ] {Target} -

[ contractor ] Such a tertiary idea can be represented in a binary format using one binary idea involving an active relationship and two binary ideas involving partitive relationships. An additional concept is used that identifies an implied process of transfer (e.g., "supplierto-contractor-material-transfer").

(ships) - {Actor} -[ supplier-to-contractor-material-transfer ] {ActObj} -[material]

(origin) - {PrimObj}-[ supplier-to-contractor-material-transfer ] {AuxObj} -[ supplier ] (destination) - {PrimObj}-[ supplier-to-contractor-material-transfer ] {AuxObj} -[ contractor ] The corresponding implicit representations are as follows:

[ supplier-to-contractor-material-transfer ] (ships) -»>

[ material ]

[ supplier-to-contractor-material-transfer ] (origin) -> [ supplier ]

[ supplier-to-contractor-material-transfer ] (destination) [ contractor ] The relational representations for these ideas are:

ships (supplier-to-contractor-material-transfer, material)

origin (supplier-to-contractor-material-transfer, supplier)

destination (supplier-to-contractor-material-transfer, contractor)

The relationship pairs of a symmetric representation are "ships/shipped-by," "hasorigin/origin-of," and "has-destination/destination-of

1 respectively.

19
3.3.2 The Utility of Complex Ideas

An underlying concept of transfer appears central to the representation of complex

ideas involving dative relationships as currently defined. Semantic information is appropriately maintained within a binary format by establishing a complex idea centered

around this additional concept.

While using an idea involving an active relationship in representing a complex idea falls

within the scope of previous discussions, combining such an idea with paired ideas involving partitive relationships to express direction adds another aspect to the representation of ideas. Such pairing of ideas has been identified in the field of natural language processing by Schank [8]. In addition to the expression of direction (from source

to target) is that of state change (from initial to final states). Both direction and state

change fit well within the context of the transfer process as being central to complex

ideas involving dative relationships.

Certainly the idea of directed transfer is useful to the building industry especially in the

context of "directed networks." Many building systems can be viewed as a collection of

connected and ordered components that transfer a given thing for the purpose of satisfying explicit functional requirements. The potential of the complex idea mechanism

representing not only directed transfer but also state change will continue to be an active topic of research.

20
4. From Initial Concepts to Constructs

4.1 Developing Concepts

Initial concepts are chosen by individuals who understand the needs of the given

domain for which a conceptual schema is being developed. Therefore, it is the participants involved in the design, construction, and maintenance of a building throughout

its entire life cycle that ultimately determine the concepts that must be represented in a global model. The preliminary AEC Model used as a basis of discussion in this report

is a first step toward identifying a comprehensive set of concepts for the building industry.

Once a concept such as building is identified, it can be represented using the conceptual graph form [building]. This form represents the initial concept. The next step is to begin to develop the concept by specifying ideas in which the concept is logically

connected to other concepts, such as:

[ building ] -* (part) -* [ building-element ] An idea can also be expressed in the following form:

(part)

[building]

[building-element]

This representation can be further abbreviated by assuming that the first concept points

toward the relation and the second points away from it as follows:

(part)

[building]

[building-element]

The form can then be used in a shorthand version which includes similar ideas involving the same relation and initial concept by adding the concepts to which the initial concept is related from those other ideas.

(part)

[ building ]

[ building-element ]

[ building-system ]

21
What is understood to constitute the concept of a building at later stages of concept

development includes all those ideas in which the concept is directly involved (i.e., an

aggregation of ideas [9]). The developed concept of a building in the AEC Model can

be represented as:

(part)

[building-project]

[building],

(part)

[building]

[building-element]

[building-system],

(on)

[building]

[site],

(function)

[building]

[building-function]

.

4.2 Identifying Constructs

Constructs are hierarchical conceptual structures formed by a synthesis of ideas that

involve generalization. In the case of part-generalization, for example, a given concept

is understood to be made of a number of parts which in turn are made of parts and so on forming a hieararchy of parts. The originating concept, in this case, represents a composite construct. The use of part-, set-, or type-generalization with the originating

concept identifies a construct as being a composite, set, or classification respecitively.

4.2.1 Composites

Composites are constructs that serve to identify a whole as being made of a number of

parts. Composites therefore use part-generalization at the originating level of the construct. An example composite for a building might view it as a simple list of parts (an

approach not taken by the AEC Model).

(part)

[building ] [ceiling]

[floor]

22
In the above example any or all of the parts could themselves be made of parts and the

composite construct of a building would include the ideas representing that further

breakdown.

An alternative composite views a building as including only the concepts building-system and building-element at the originating level. Building-system and building-element are in turn made up of various kinds of systems and elements. This is the approach used in the AEC Model.

(part)

[building]

[building-element]

[building-system],

(subtype)

[building-element]

[ceiling]

[floor]

[roof]

[room]

[wall],

(subtype)

[building-system]

[engineering-system]

[non-engineering-system],

Since in this construct a wall is a subtype of a building element, and a building element

is a part of a building, it follows that a wall is also a part of a building. Similarly parts or subtypes of a wall can also be seen to be included in a composite view of a building.

This example illustrates the use of a concept classification (involving type-generalization) being incorporated within a composite construct.

4.2.2 Sets

Sets are constructs that use set-generalization at the originating level. Sets identify collections of concepts that do not necessarily have anything in common other than that

they are members of the same set.

23
4.2.3 Classifications

Classifications are constructs that provide the ability to view information in a hierarchical arrangement of categories, each subsequent level adding more detailed information. Classifications use type-generalization at the originating and all subsequent

levels of the construct. They are often included as a portion of composite constructs

(see Section 4.2.1). Classifications are particularly useful in organizing building information where taxonomies of building elements and systems are central issues in

developing a global model.

An important aspect of the AEC Model is its systems approach to organizing information about a building. Figure 1 presents a hierarchy that represents the classification

of concepts under the heading of building-system. The representation is of the structure only and does not explicitly identify the relationships between concepts involving

type-generalization. However, since the structure is identified as a classification, the

subtype relation is implied throughout.

An alternative classification is presented in Figure 2. This classification takes the view

that building systems can be subdivided into enclosure, interior, mechanical, and structural systems. All other building systems fall under these four classes. This alternative

structure reflects an organization suggested in "The Building Systems Integration

Handbook" published by the American Institute of Architects [12]. Deciding between

such details within a generalization hierarchy is a major aspect of developing a conceptual schema.

Table 6. presents the ideas of the building-system classification shown in Figure 2.

24
building-system

engineering-system

communication-system

conveyance-system

electrical-system

lighting-system

mechanical-system

acoustical-system

fire-protection-system

hvac-system

plumbing-system

structural-system

non-engineering-system

circulation-system

enclosure-system

internal-subdivision-system

external-envelope-system

aperture-system

interior-system

spatial-system

Figure 1. A Building-System Classification.

25
building-system

enclosure-system

internal-subdivision-system

external-envelope-system

aperture-system

interior-system

circulation-system

spatial-system

mechanical-system

acoustical-system

communication-system

conveyance-system

electrical-system

fire-protection-system

hvac-system

lighting-system

plumbing-system

structural-system

Figure 2. An Alternative Building-System Classification.

26
Table 6. Ideas in a Building-System Classification.

ParRel PrimObj AuxObj

subtype building-system enclosure-system

interior-system

mechanical-system

structural-system

subtype mechanical-system acoustical-system

communication-system

conveyance-system

electrical-system

fire-protection-system

hvac-system

lighting-system

plumbing-system

subtype enclosure-system internal-subdivision

external-envelope

opening

subtype interior-system circulation-system

spatial-system

4.3 Prototypes

When a concept is developed and that concept is also contained within a typegeneralization hierarchy, the developed concept (i.e., its ideas) can be inherited within

the context of that hierarchy. This kind of construct is referred to here as a prototype

concept. It is something of a cross between a developed concept and a construct. It includes both the aggregation of ideas in which the initial concept is involved and possibly other selected ideas that extend beyond that aggregation.

27
Table 7. Ideas in a Prototype Engineering-System.

Relation Concept 1 Concept 2

accesses engineering-system utility-system

divides zone engineering-system

part engineering-system system-component

part engineering-system directed-network

part directed-network device-part

represents device-part-geometry device-part

supports structural-system system-component

triggers control instrument

subtype system-component control

device-part

instrument

insulation

Within its building-system classification, the AEC Model has developed a prototype

engineering-system (Figure 7). This prototype serves as a template for developing the

concepts of mechanical and structural systems since it specifies ideas that are believed

to hold for all types of engineering systems.

In considering what constitutes an hvac-system, the prototype engineering-system can

be inherited if the hvac-system is related to a mechanical-system which in turn is re- lated to an engineering-system by type-generalization. Therefore, the development of

the hvac-system concept begins with inherited ideas which can be derived from the

prototype engineering-system followed by ideas that uniquely specify the hvac-system

concept.

28
Table 8. Inherited Ideas of an HVAC-System Concept.

Relation Concept 1 Concept 2

accesses hvac-system utility-system

divides zone hvac-system

part hvac-system system-component

part hvac-system directed-network

part directed-network device -pan

represents device-part-geometry device-part

supports structural-system system-component

triggers control instrument

subtype system-component control

device

instrument

insulation

In fact, it is this addition of lower level specific ideas to higher level general ideas that

justifies the use of type-generalization. If unique information is not added by lower

level classes, the division into subtypes is probably not appropriate.

Table 8 presents the inherited ideas that serve to develop the concept of an hvac-system. Table 9 expands upon the concept by adding ideas that are unique to an hvac-system. Such inheritance, from a prototype to concepts that represent subtypes of the

prototype, is a capability that needs to be considered when developing generalization

hierarchies.

29
Table 9. Non-Inherited Ideas of an HVAC-System Concept.

1 Relation Concept 1 Concept 2

connects air-distribution-network air-distribution-device

conntects water-distribution-network water-distribution-device

subtype control temperature-control

air-flow-control

subtype device-part air-terminal

conditioner-device

air-distribution-device

water-distribution-device

water-terminal

subtype air-terminal air-distribution-ceiling

diffuser

door

grille

light-fixture

louver

register

roof-ventilator screen

skylight

vent

window

subtype conditioner-device cooling-conditioner

heat-conditioner

humindity-conditioner

(continued)

30
Table 9. (continued)

Relation Concept 1 Concept 2

subtype water-terminal convector

radiant-panel

radiator

unit-heater

31

5. Summary and Conclusions:

5.1 The Conceptual Schema Development Process

The development of a conceptual schema such as the AEC Model has at least four es- sential aspects. They include:

Topic Process

Concepts

Relationships

Ideas

Constructs

identification and development

selection of Relation &Roles

assignment of Roles to Concepts

identification and development

The process of schema development begins with the identification of concepts appropriate to a given domain. In the case of the building industry, this is itself a formidable task and is therefore expected to be a continuing effort.

In contrast to the large number of concepts that'can be expected in a global conceptual

model, the number of relations used in describing relationships between concepts is much smaller. Further, many relations that are appropriate for the building industry are also useful in other domains. Therefore, identifying relations should be a matter

of selection from among previously identified relations. This aspect of schema development lends itself to cooperative efforts across disciplines.

A problem that is encountered, however, is that there is little or no standardization in

the manner in which relationships are specified. Many data models (in the sense of

tools used to develop schemas) have their own way of defining relationships. Whether

the relation and roles remain separate or are combined in a single representation is the

most obvious difference. However, the details of the words used to express the relationships and the precise syntax of their specification continues to be problematic. This

report has described an initial step toward resolving this important issue.

The lack of consensus is also serious in the case of specifying ideas. Many alternative

representations exist. This report has described three general kinds of representation

as an overview of the sorts of differences that exist. However, it is important to note

that they should be truly alternative representations. The underlying semantics must

remain the same though expressed in different ways. In those cases where a particular

representation cannot accommodate necessary semantics, extensions to the representation are justified.

33
What has not been a part of the specification of ideas in the past is the use of relationship types to assist the schema developer. Ideas when specified in a form close to

natural language (e.g., a symmetric representation) should use certain grammatical

constructions. The definition of active, dative, locative, and partitive relationship types

makes this point explicit. Roles have then been established that reflect the underlying

semantics attached to concepts involved in these types of relationships. This approach

allows for explicit statements of meaning that can serve as a check for alternative representations. In this context, a representation for complex ideas has been developed

for the special case of ideas involving dative relationships to address the underlying

semantics of directed transfer.

Another aspect of developing a conceptual model emphasized in this report is the importance of identifying and developing constructs within the conceptual schema. Composites, sets, and classifications serve to establish hierarchically related groups of ideas

within a conceptual schema. Identifying constructs involves important choices that

must be made between part-, set-, and type-generalization. When using typegeneralization, the specification of prototypes can serve as templates in developing

lower level concepts within a classification.

These aspects of the development of conceptual models need further review and re- search. TTiey can, however, be applied to ongoing schema development as an aid to the

developer in considering the many choices that are to be made during that process.

5.2 Natural Expression of Ideas

The development of a conceptual schema using representations that are similar to

natural language expressions benefits both the developer and most other individuals

that are to make use of the schema. Internal computer representations vary greatly

from one implementation to another. Clear conceptual representations offer a means

by which systems can be developed that are capable of communication both within and

between disciplines.

This report has presented a view of how ideas and other conceptual structures can be

specified unambiguously. Adoption of such an approach (see Table 10 as an example)

presents the possibility for more direct comparison and integration’ of conceptual

schemas than is currently the case. Particularly in the realm of relationships, the potential for developing a consensus semantic vocabulary fromwhich schema developers and

integrators can choose seems of considerable relevance to standardization organizations.

34
Table 10. Natural Expression of Ideas by Relationship Type.

Active

Idea: ActObj-ActRel1 air-quality_control

Obv Actor ActRelfs]

2 ActObj hvac-system controls air-quality

Inv ActObj [is-]ActRel[ed-by]3 Actor air-quality is-controlled-by hvac-system

Dative (Complex Idea)

Idea: Source_[to]_Target_DatObj_[transfer4

] gutter_to_downspout_water_transfer

Obv. S ource- [to] -Target-DatObj- [transfer] gutter-to-downspout-water-transfer

" DatRel[s] DatObj " conducts water

" [has-origin] Source " has-origin gutter

" [has-destination] Target " has-destination downspout

Inv. Source- [to] -Target-D atObj - [transfer] gutter-to-downspout-water-transfer

DatObj [is-]DatRel[edrby] " water is-conducted-by

Source [is-origin-of]

" gutter is-origin-of "

Target [is-destination-of] " downspout is-destination-of "

Locative

Idea: LocObj_[location] building_location

Obv LocObj [is-]ObvLocRel Loc building is-on site

Inv Loc [is-]InvLocRel LocObj site is-under building

Partitive

Idea: PrimObj_ParRel building_part

Obv. PrimObj [has-]ParRel AuxObj building has-part building-element

Inv AuxObj [is-]ParRel[-of] PrimObj building-element is-part-of building

1 Beginning capital letters indicate variables.

2 Letters, words, and characters in brackets are used literally.

3 Normal rules of English grammar apply.

4 Complex ideas involving dative relationships represent directed transfer.

35
mtj

'
References

[1] Brodie, M., Myopoulos, J., and Schmidt, J.; On Conceptual Modelling,

Springer-Verlag, NY 1984.

[2] Date, C.J.; An Introduction to Database Systems: Volume II, Addison-Wesley

Publishing Company, Reading, Mass., 1986.

[3] Turner, J.; The AEC Building Project Model, ISO TC184/SC4/WG1, Document N 131, The International Organization for Standardization, 1987.

[4] Sowa, J.F.; Conceptual Structures: Information Processing in Mind and

Machine, Addison-Wesley Publishing Company, Reading, Mass., 1984.

[ 5 ] Su, S.Y.W.; Modeling integrated manufacturing data with SAM*, Computer,

34-49, Jan. 1986.

[6] Chen, P.P.; The entity-relationship model - Toward a unified view of data, in

Tutorial: Centralized and Distributed Data Base Systems, W.W. Chen and P.P.

Chen (eds), IEEE Computer Society #EHO 154-5, IEEE, NY, 166-193, 1979.

[ 7] Danner, W.F.; The Use of Artificial Intelligence Programming Techniques for

Communication between Incompatible Building-Information Systems, NBSIR

87-3529, National Bureau of Standards, U.S. Department of Commerce, April

1987.

[8] Winograd, T.; Language as a Cognitive Process: Syntax, Addison-Wesley

Publishing Company, Reading, Mass., 1983.

[ 9] Smith, J.M., and Smith, D.C.; Database Abstraction: Aggregation and

Generalization, ACM Trans. Database Systems, 2(2), 105-133, 1977.

[10] Verheijen, G.M.A., and Van Bekkum, J.; NIAM: An Information Analysis

Method, in proceedings of the IFIP/TC8 Working Conference on a Comparative Review of Information Systems Design Methodologies, Noordwijkerhout,

Netherlands, North Holland Publishing Company, 1982.

37
[11] Clocksin, W.F., and Mellish, C.S.; Programming in Prolog, Springer-Verlag,

NY, 1987.

[12] Rush, R.D.; The Building Systems Integration Handbook, The American Institute of Architects, John Wiley & Sons, NY, 1986.

38
NBS-1 1 4 A rev. 2-ac : U.S. DEPT. OF COMM.

BIBLIOGRAPHIC DATA

1. PUBLICATION OR

REPORT NO.

2. Performing Organ. Report No. 3. Publ ication Date

SHEET (See instructions

)

NBSIR 88-3754 APRIL 1988

4. TITLE AND SUBTITLE

A Global Model for Building-Project Information: Analysis of Conceptual Services

5. AUTHOR(S)

William F. Danner

6. P ER FORM IN G O RGAN I ZATI ON (If joint or other th an NBS, see instructions) 7

.

Contract/Grant No. NATIONAL BUREAU OF STANDARDS _

DEPARTMENT OF COMMERCE 8 WASHINGTON, D.C. 20234

9.

SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City. State, ZIP)

. Type of Report & Period Covered

10.

SUPPLEMENTARY NOTES

~ Document describes a computer program; SF-185, FIPS Software Summary, is attached.

11.

ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a significant

bi bliography or literature survey, mention it here)

The development of a global model for building-project information requires a precise

description of the meaning of the information to be maintained. This report presents

an analysis of the conceptual structures that are available to specify that meaning

using an "as-designed" global model as an example. This model is currently under

development by the Architecture, Engineering, and Construction (AEC) Committee of the

Initial Graphics Exchanges Specification (IGES) /Product Data Exchange Specification

(PDES) Organization.

The key conclusion of this analysis is that a core semantic vocabulary is needed.

This core vocabulary derives from how meaning is expressed without regard for specific

domains of information. Preliminary elements of such a core vocabulary are defined.

Further, a means by which that core is extended to add necessary domain-specific

semantics is presented. The analysis has identified those aspects of developing a global model for building-project information that should proceed in the context of

a broad interdisciplinary effort to represent information and those that require

extensive technical input from the building industry.

12. KEY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semicolon s) building data; building information; conceptual modeling; data modeling;

information modeling; semantic modeling

13. AVAILABILITY 14. NO. OF

PRINTED PAGES

“X Unlimited For Official Distribution. Do Not Release to NTIS 44

Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C. 20402. 15. Price

"X Order From National Technical Information Service (NTIS), Springfield, VA. 22161

$11.95

USCOMM-DC 6043-P 80
.

*

*