NBS

PUBLICATIONS

analyses p

Ij -IfSauction to SASE: Standards

Analysis, Synthesis, and

Expression

Steven J. Fenves^

Richard N. Wright^

Fred I. Stahl^

Kent A. Reed^

^ Department of Civil Engineering

Carnegie Mellon University

Pittsburgh, PA 15213

^U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Center for Building Technology

Gaithersburg, MD 20899

^current affiliation: IBM Corporation

Southfield, Ml 48086-5050

May 1987

U.S. DEPARTMENT OF COMMERCE

'QC

100

.056

# 87-3513

1987

lAU OF STANDARDS
'ir
NBSIR 87-3513

‘Research Informatioa Center

Rational liureau of Standards

Oaithershurg, Maryland 20899

I

- »S

INTRODUCTION TO SASE: STANDARDS ; 3

ANALYSIS, SYNTHESIS, AND

^ EXPRESSION

Steven J. Fenves^

Richard N. Wright^

Fred I. Stahl^

Kent A. Reed^

^ Department of Civil Engineering

Carnegie Mellon University

Pittsburgh, PA 15213

^U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Center for Building Technology

Gaithersburg, MO 20899

^current affiliation; IBM Corporation

Southfield, Ml 48086-5050

May 1987

U.S. DEPARTMENT OF COMMERCE, Malcolm Baidrige, Secretary

NATIONAL BUREAU OF STANDARDS, Ernest Ambler, Director

ABSTRACT

The Standards Analysis, Synthesis, and Expression (SASE) methodology

provides an objective and rigorous representation of the content and

organization of a standard. Both the methodology and a computer program

that implements it are described in this document in terms of two

underlying conceptual models. The conceptual model for the information

content of a standard is essentially independent of any particular

organization and expression of the information. The fundamental unit of

information in the model is a provision stipulating that a product or process have some quality. The highest level provisions in a standard are requirements that directly indicate compliance with some portion of the

standard and are either satisfied or violated. Techniques are provided in

SASE to ensure that individual provisions are unique, complete, and

correct, and that the relations between provisions .are connected, acyclic,

and consistent. Entities in SASE that represent the information content of

a standard are data items, decision tables, decision trees, functions, and

information networks. The conceptual model for the organization of a standard is based on a logical classification system in which each

requirement is classed in terms of its subject (product or process) and

predicate (required quality) . Techniques are provided in SASE for building

and manipulating hierarchical trees of classifiers and testing the

resulting organization for completeness and clarity. Entities in SASE that

deal with the organization of a standard are classifiers, hierarchy,

scopelist, index, organization, and outline. The SASE methodology is

demonstrated in an analysis of a complete standard for concrete quality. An

annotated bibliography of the most significant relevant research reports is

presented.

keywords: Arrangement, building, classification, code, consistency,

knowledge representation, organization, provisions, standards

iii
FOREWORD

This report is intended to serve two purposes

• To provide an introduction to the methodology of Standards

Analysis, Synthesis, and Expression (SASE) by summarizing in one place the concepts and methods developed over nearly two decades;

and

« To serve as a tutorial guide to the SASE program which implements

that methodology.

A chronological annotated bibliography of the publications leading up to

this report is presented in Appendix B. The documentation of the SASE

program is contained in the companion SASE User Manual'^.

The writers appreciate the contributions of several colleagues. Judy

Calabrese and Charles Yancey assisted with the study described in Appendix

A. James Harris made a considerable contribution to the design of the SASE

software and the planning of this study, and was lead author of the

principal resource document. Steven Bushby provided numerous insightful

comments in his critical review of the manuscript. Systems Architects, Inc.

of Falls Church, Virginia, prepared the initial version of the SASE

program.

* NBSIR 87-3514. See reference 4 of this report.
TABLE OF CONTENTS

Page

ABSTRACT iii

FOREWORD iv

LIST OF FIGURES vi

LIST OF TABLES vii

1. INTRODUCTION 1

1.1 Standards 1 1.2 Role of SASE in the Standards Development Process 2 1.3 Organization of this Document 5

2. OVERVIEW OF SASE 7

2.1 The SASE Methodology 7 2.2 The SASE Program 22

3. MODELLING THE INFORMATION OF A STANDARD 31

3.1 Data Items 31

3.2 Provisions 33

3.3 Decision Tables 35

3.4 Decision Trees 57

3 . 5 Functions 64

3.6 Networks 67

4. ORGANIZING THE INFORMATION OF A STANDARD 79

4.1 Classifiers 79

4.2 Hierarchy 89

4.3 Scopelist 96

4.4 Index 97

4.5 Organization 101

4.6 Outline 108

REFERENCES 119

APPENDIX A: Analysis of a Standard for Concrete Quality 121

APPENDIX B: Annotated Bibliography 175

V
LIST OF FIGURES

Figure Page

2.1 Text of fire escape example 8 2.2 Decision tree for the logic in table 2.5 16

2.3 Portion of information network for the fire escape example.... 17

2.4 A hierarchy of classifiers for the fire escape example ....... 21

2.5 An organization for the fire escape example 23

2.6 An outline for the fire escape example 24

2.7 New text for the fire escape example 25

2.8 Organization of the SASE Database . . .' 29

3.1 Sample provision 40

3.2 Sample provision 44

3.3 Sample provisions 50

3.4 Sample provision 53

3.5 Decision tree generation from a hypothetical decision table .. 58

3.6 Decision tree in SASE format generated from table 3.7 ........ 61

3.7 Decision tree in SASE format generated from table 3.9 ........ 61

3.8 Comparison of decision trees 63

3.9 Simplified provisions 68

3.10 Information network for simplified provisions 69

3.11 Information network ordered by levels from output data item... 72

3.12 Information network ordered by levels from input data items... 73

4.1 Sample combination of facets of subject classifiers 81

4.2 Basic categories for requirements 85

4.3 Physical Entity field from a classification

for seismic provisions 90

4.4 Physical Entity field from an alternative

classification for seismic provisions 93

4.5 Example of a simple index 98

4.6 Example of advanced indexes 99

4.7 Partition of a tree into logical regions 112

A.l Text of a standard for concrete quality 127

A. 2 SASE- generated listing of derived data items 131

A. 3 SASE-generated listing of input data items 137

A. 4 SASE-generated global ingredience network 140

A. 5 Segment of SASE-generated global ingredience

network enlarged 144

A. 6 SASE-generated classifier list 145

A. 7 SASE-generated scopelist 152

A. 8 SASE-generated index 157

A. 9 SASE-generated outline 167

VI
LIST OF TABLES

Table Page

2.1 Datum list for fire escape example 10

2.2 Requirement for permission to use fire escapes 12

2.3 Requirement for design load of fire escapes 12

2.4 Requirement for landing clearance 13

2.5 Requirement for material type 13

2.6 Requirement for stair dimensions 14

2.7 Requirement for fire rating of doors and windows 14

2.8 Requirement for landing dimensions 14

2.9 Classifier list for the fire escape example 18

2.10 Argument list for the fire escape example 19

2.11 Scopelist for the fire escape example 20

2.12 SASE command/entity combinations 30

3.1 Regions of a decision table 36

3.2 Sample provision 37

3.3 Extended entry decision table 37

3.4 Limited entry decision table 38

3.5 Initial condition entries 42

3.6 Completed condition entries 43

3.7 Revised condition entries (compare table 3.6) 44

3.8 Decision table with compound actions 45

3.9 Implicit entries (compare table 3.6) 46

3.10 Implicit entries (compare table 3.4) 46

3 . 11 Equivalent rules 47

3.12 Counting simple rules 48

3.13 First approach to checking maximum height 51

3.14 Second approach to checking maximum height 52

3.15 Compound conditions 53

3.16 Standard form of rule entry 56

3.17 Condensed form of rule entry 56

3.18 Rules for selecting a condition for testing 59

3.19 Levels and floats in example network 74

A.l Requirement for strength tests at specified age 169

A. 2 Requirement establishing the value of f^,^ corresponding

to specified value of f'^, 169

A. 3 Determination of required average test strength 169

A. 4 Determination of standard deviation of strength test data 170

A. 5 Determination of strength corresponding to watercement ratio of laboratory trial batch 170

A. 6 Requirement for maximum permissible w/c ratio by table 4.5 .... 171

A. 7 Requirement for permissible reduction

of average test strength 171

A. 8 Requirement for the frequency of strength test samples

taken for each class of concrete 172

A. 9 Requirement for strength levels based on lab-cured cylinders .. 172

A. 10 Acceptability of in-situ strength based on core tests 173

A. 11 Requirement for the protection and curing of concrete 174

vii
•i(’ '' ^ '^*.

1 ”^'^ .*'1 ^

,.

. ' “Iv 'Tfe .'?'.

i;’’. > , lTgiHtg«^;gr

j r/. - * ^ * .

. . -sj.iri

. )

*’

*'•'- - /

^' »• ’'-ft

'

''

rt 1 ..I

• '•*

I

-• ' --:

y

•'•

.i f'

-._.•*• ijlf rJ*V

'•

(

•

. ..

• »r,\

i«» .-., j. 1:. . ; .1 , st^Xis.JSigBSi

i'^r |

'

'.' •' '‘Spi»r

r

^XS.

s'

.

'. . , . i: f', .4 . .at f«>; 'u^»U

..J >'l.'

' .' (('.',' V" >S'.hV^K,'
1. INTRODUCTION

The Standards Analysis, Synthesis, and Expression (SASE) methodology provides an objective and rigorous representation of the meaning of a standard. It is intended to assist organizations engaged in the formulation,

promulgation, and maintenance of standards. In order to put SASE in context, this chapter presents first a discussion of standards followed by a discussion of the role of SASE. Finally, the organization of this document

is discussed.

1 . 1 Standards

In this discussion, the term standard includes all types of normative

documents used to define the required qualities of buildings, building

products, materials, or building processes. The term includes legal building regulations , consensus standards such as those of the American National

Standards Institute and of the International Organization for Standardization, and proprietary specifications. Standards are used for communication

between buyer and seller and for protection of public health, safety, and

welfare

Standards from many technology areas should be equally amenable to the SASE

methodology. However, the methodology and the information models on which

it is based have been tested extensively only in areas of building technology1.1.1 The Standards Development Process

Standards are generally developed following the principle of due process in

notification, balloting, resolution of dissent, and careful record keeping.

A standard is usually drafted by a committee of experts who:

• define the scope, including the products or processes to be covered

and their required performance attributes;

• determine whether to express the standard as a performance standard

(attributes in terms of user needs [19]), procedural standard

(attributes in terms of specified, rigorous technical evaluation

procedures [5]), or prescriptive standard (attributes given as dimensions or properties completely defining the acceptable con- figuration or procedures)

• formulate the standard, that is, develop appropriate provisions for

ascertaining that the required performance attributes of the products or processes are satisfied; and

• submit the draft standard to the organization responsible for

promulgation and maintenance.

The process of promulgation and maintenance is typically of long duration.

Modifications and interpretations may occur without participation of or consultation with the experts who initially drafted the standard.

1
1.1.2 Shortcomings of the Process

A number of problems arise in the present process of developing standards.

First, the process itself is expensive because much time and effort is

required from leading experts in the subject area and from those whose

interests are affected. Most of this time and effort is expended in mutually understanding technical issues and resolving them.

Second, the slowness of the process means that standards may become obsolete or even technically incorrect and continue to be used for some time

while new or modified standards are being developed. This problem is exac- erbated by rapidly changing societal demands for building qualities, such

as energy conservation, and rapidly changing technologies in building

products and processes, both of which lead to many new subjects for standardization and the frequent revision of existing standards.

Third, once a standard is developed, each user of the standard must invest

time and effort in interpreting it, that is:

• locating all relevant provisions; and

• understanding and correctly applying the applicable provisions.

Ultimately, society bears the additional risks and expenses that arise from

the potential building malfunctions and waste associated with the use of

obsolete, incorrect, or incorrectly applied standards.

The increased use of computer-aided design potentially magnifies these

problems. A single error in interpretation of a standard by the developer

of a computer program may lead to many errors in application as the program

is used. Furthermore, the time and expense associated with updating programs to incorporate revisions in standards cause programs to lag behind

and to act as impediments to the application of improved technologies that can increase the economy, safety, or usefulness of buildings.

An objective, analytical method for generating and reviewing either the

content or the form of a proposed new standard or modifications of an existing one would help mitigate the problems described above by providing

experts and users both with explicit representations of the content and

organization of the standard. Because standards are so important to industry and because the cost of producing them is high, there is a need for

such a method, beyond due process, informal peer review, and occasional

test comparisons with previous standards, for making objective evaluations

of the logic and internal consistency of standards. The SASE methodology

fills this need.

1 . 2 Role of SASE in the Standards Development Process

The methodology embodied in SASE deals exclusively with the logic, format,

and organization of standards, that is, their syntax. Because of this

emphasis on syntax, SASE is applicable to the entire range of standards

2
discussed in section 1.1. By contrast, the meaning or semantics of each

standard is highly specific to its subject area, and requires the background and knowledge of experts in the area for proper analysis and synthesis .

The objective of SASE is to provide a formal methodology to represent the

logic and organization of standards so as to ensure the following qualities

in a standard:

1. Individual provisions need to be:

• Unique - the provision must yield one and only result in any

possible application;

• Complete - the provision must apply explicitly to all possible

situations; and

• Correct - the result of applying the provision is to be consistent with the objective of the standard.

2. Relations among provisions should be:

• Connected - explicit cross references must show the data re- quired for the application of each provision and the use stipulated for the data produced by each provision.

• Acyclic - the data produced by evaluation of a provision should

not be required prior to its evaluation (no loops in logic) ; and

• Consistent - uniform logical and technical bases must be provided for comparable provisions.

3. The organization of the standard should be:

• Complete - explicit scope must be provided so that a user knows

the subjects and qualities covered by the standard; and

• Clear - the arrangement and display of provisions should be

such that the user readily finds all provisions pertinent to

his query.

1.2.1 The Application of SASE

The methodology of SASE is applicable to three distinct processes in standards development.

1. Analysis - the process of extracting the information content of an existing standard. This is the necessary first step in modifying

or updating an existing standard.

3
2 . S 3mthesis - the process of generating the information content of a new or modified standard. This process is most directly concerned

with ensuring that the standard possesses the qualities presented

previously

.

3. Expression - the process of expressing the previously synthesized

information content in textual form.

The first two processes are collectively referred to as the formulation of

a standard since they lead to the format and complete representation of the

information content.

1.2.2 Mode of usage of SASE

SASE may be used in the development of a standard by designating one or more members of the standards drafting committee as analysts, whose primary

responsibility is to work with SASE on issues of format and organization,

interacting closely with the other committee members who are experts in the

area covered by the standard. Alternatively, organizations involved in

standards activities may provide analytical services to their committees as

a staff support function. In either event, analysis should be closely

coordinated with the standards formulation process.

For a project that involves the formulation of a new standard, systematic

analysis using SASE should begin at the same time as the overall project of

standards drafting and be closely coordinated with it. This avoids the

possibility of the analyst appearing as an intruder, and allows the analyst

to keep up with the experts

.

For a project that involves a revision of an existing standard, it is

desirable to begin analysis of the standard before the committee begins

considering revisions. Once again, this allows the analyst to keep up with

the committee. It also allows a thorough study of the possible flaws in

the existing provisions, which could serve as part of the rationale for

change

.

Once the analysis has been undertaken, it should be kept up to date as the

project continues. There are several advantages accruing from concommitant

analysis

;

• it provides a firm, rational basis for recommendations to be made

to the experts

;

• the details of the analysis may be important to some of the experts

in their deliberations; and

• the final SASE documentation can be completed and released with the

written standard or very soon after its completion.

Effective interaction between the analysts and the experts is of the utmost

importance. Close and frequent contacts facilitate the work and greatly

improve the likelihood of significant benefit. Analysis, synthesis, and

4
expression of any standard are too important to the success of the standard-writing project to be delegated to a format committee remote from the

main thrust of the work. The analysts should interact directly with the

committee concerned with the substance of the standard, for that is where

the key issues will arise and the decisions will be made. It can become

easy to fall into adversative positions when the experts and the analysts

are too far removed from one another because of the organizational structure. Close contact increases the spirit of cooperation and lessens the

chance of the analyst antagonizing the experts. Successful interaction

also requires quick response.

Typically, recommendations generated by the analysts come in the form of a question raised or of an improvement suggested. Both forms are valid but,

with every recommendation, it must be clear what the form is and what the

appropriate action for the experts is. In addition, all recommendations

must be carefully explained, with due consideration of present problems and

the impacts of change. Finally, the participants in such projects must

frequently conduct critiques of their work, their own effectiveness in the

work, and the standard that they are working on.

In summary, the following items are critical components for the successful

use of SASE in a standards development project:

• begin analysis at the earliest possible time;

• obtain early agreement within the committee on the interaction between experts and analysts;

• conduct a full, detailed analysis early and keep the analysis up to

date

• cultivate close and effective interactions between experts and ana- lysts ;

• make all recommendations clear; and

• conduct on-going critiques.

1 . 3 Organization of this Document

This document is directed primarily to analysts participating in standard

development activities. The document is intended to provide the background

on the SASE methodology and tutorial guidance on the SASE program. It is

expected that the document will be used in conjunction with the SASE User

Manual [4]

,

both to provide the motivation for and an understanding of the

features in SASE and to serve as an illustrative guide for the use of these

features.

Portions of this document, especially Chapter 2 but also the introductory

material and examples of Chapter 3 and Chapter 4, should be of interest not

just to analysts but to all experts participating in standard developing

5
committees. This material will provide an understanding of the types of

assistance that can be provided to the experts by analysts using SASE.

A brief overview of the conceptual model incorporated in the SASE methodology and of the representation of the principal components of a standard in

the SASE program is presented in Chapter 2.

Detailed descriptions of the process of modelling and organizing the information of a standard according to the conceptual model are provided in

Chapter 3 and Chapter 4. Each of the major sections of these chapters is

subdivided into three parts

• a detailed definition of the concept presented in the section,

including background information;

• a discussion of proper usage of the concept, containing suggestions

to serve as tutorial aids ; and

• the representation of the concept in the SASE program.

The results of a study of a standard for concrete quality are presented in

Appendix A as a practical demonstration of the SASE methodology. Virtually

all of the SASE techniques described in this report were applied in the

s tudy

6
2. OVERVIEW OF SASE

This chapter presents a brief overview of the conceptual model incorporated

in the SASE methodology and of the representation of the principal components of a standard in the SASE program.

2 . 1 The SASE Methodology

This overview of the SASE methodology is illustrated by a completed analysis of a section of a model building code [1] dealing with fire escapes.

The text of the fire escape example is shown in figure 2.1. The underlined

portions of the text correspond to data items identified in the analysis;

the numbers in the right margin of the figure are datum reference numbers

assigned by the analyst.

2.1.1 Provis ions

The basic unit of a standard is a provision or normative statement stipulating that a product or process shall have or be assigned some quality. A

number of forms of provisions fit this definition;

• a performance requirement, e.g., "the system shall maintain an adequate supply of hot water,"

• a performance criterion, e.g., "hot water temperature shall be con- trolled between 40°C and 50®C,"

• a prescriptive criterion, e.g., "the hot water tank shall have a capacity of 150 liters,"

• a determination or function, e.g., "the flow q = av."

Each provision has the function of assigning a value to a data item or datum. It is useful to distinguish between two kinds of provisions based on their usage in the standard:

• Requirements are provisions that directly determine compliance with

some portion of a standard. Such provisions normally can be characterized as satisfied or violated, represented by the Boolean data

values true or false, respectively.

• Determinations are all provisions that are not requirements. Such

provisions are normally characterized by either numerical or nominal values, including Boolean, but are not amenable to characterization as satisfied or violated.

Seven requirements were identified in the analysis of the fire escape

example. They are described in terms of their corresponding data items in

the following section.

7
Section 623.0 Fire Escapes

623.1 Where Permitted: Except in use grouts L-2 and L-3 (one- 2 and two-family and multi-family dwellings), fire escapes shall

not in general be accepted as an element of a required means of

egress. Fire escapes shall be permitted only by special order 1,3

of the building official , in existing buildings or structures 4

of other use groups, not exceeding five (5) stories or sixty- 6

five (65) feet in height . when constructed in accordance with 7 the approved rules and when more adequate exitwav facilities 9

cannot be provided.

623.2 Location: When located on the front of the building and 10

projecting beyond the building line , the lowest landing shall 11,12

be not less than ten (10) or more than fourteen (14) feet above

grade, equipped with a counterbalanced stairway to the street 13

and with fixed ladder to the roof . In alleyways and thorough- 14,15

fares less than thirty (30) feet wide , the clearance under the 29

lowest landing shall not be less than fourteen (14) feet.

623.3 Construction: The fire escape shall be designed to sup- 8 port a live load of one hundred (100) pounds per square feet 16

and shall be constructed of steel or other approved noncombus- 17 , 30

tible materials .

623.31 Dimensions: Stairs shall be at least twenty- two (22) 31

inches wide with risers not more and treads not less than eight 21-23

(8) inches and landings at foot of stairs not less than forty 35

(40) inches wide by thirty-six (36) inches long . located not 24-26

more than eight (8) inches below the access window or door.

623.32 Opening Protectives: Doors and windows along the fire 34

escape shall be protected with three-quarter (3/4) hour opening 27

protectives in other than residence buildings of use groups L-2

and L-3.

623.33 Outside Fire Limits: On buildings not over three (3)

stories nor more than forty (40) feet in height located outside

the fire limits, accomodating not more than twenty (20) per- 32 sons fire escapes may be constructed of wood or other approved 33

material of similar combustible characteristics .

623.34 Within Fire Limits : Within Fire District No. 2, fire 20,28

escapes may be constructed of wood not less than two (2) inches 18

thick on buildings of type 3 or type 4 construction not more 19

than three (3) stories in height.

Figure 2.1 Text of fire escape example with data items

underlined and datum reference numbers in right margin.

8
2.1.2 Data Items

A data item or datum is a precise identification of an information element

occurring in a standard. The status (satisfied or violated) of each re- quirement is represented by a datum. Each result or variable generated by

a determination is a datum. In addition, every other variable referred to

in a standard but not explicitly assigned a value by some provision is a datum. For example, the density of a material may be referred to, but not

defined, in a standard. Such data are called input data; their values are not determined by the standard itself. All data assigned values by provisions of the standard are called derived data. The list of data items is

similar to, but typically much longer than, the conventional list of definitions and s 3rmbols found in present standards.

The set of data items plus the expressions of the rules for evaluating and

relating the data items contain all the information necessary to evaluate

compliance with a standard.

The data items for the fire escape example are listed by reference number

in table 2.1. The reference numbers were assigned as the analyst identified

each datum and are not necessarily in the order of appearance in the text.

Each datum is described by a short title. It is instructive to compare the

titles in table 2.1 with the underlined portions of text in figure 2.1.

Frequently, a verbatim extraction of text does not suffice to capture the

meaning of an information element and the title must be synthesized.

Each datum in table 2.1 is also described by the source of its value (e.g.,

input or derived) ; and, if derived, the reference numbers of the ingredient

data items on which its value depends (see section 2.1.4). Note that datum

5 in the table is neither a derived datum nor an ingredient of any datum.

It was entered by the analyst expecting to encounter a height limit within

this section and was retained because it may be an ingredient to a datum in

another section of the standard.

2.1.3 Decision Tables

A decision table is used to represent the rules for assigning a value to a derived datum. A decision table is an orderly presentation of the reasoning leading to a decision. It is easily analyzed to assure that the rea- soning leads to a unique result in each case and that no possibility exists

for encountering an unanticipated situation.

The seven decision tables given in tables 2.2 through 2.8 correspond to the seven requirements identified in the fire escape example.

Each decision table is divided into four quadrants (in this representation,

by the double lines) . The upper left quadrant is the condition stub defining all logical conditions that have a bearing on the actions. The lower

left quadrant is the action stub defining all possible actions. The upper

right quadrant is the condition entry and the lower right quadrant is the

action entry . The rules defining the logic of the decision table are the

columns spanning the entry quadrants. The horizontal rows of conditions

9
Table 2.1 Datum list for fire escape example

Reference

Number Title Source

Ingredient

Data Items

1 Requirement for permission

to use fire escapes

Derived 2, 3, 4, 6, 7,

9

2 Use group Input

3 Special order of building

official

Input

4 Existing building Input

5 Height limit Input

6 Number of stories Input

7 Height of building Input

8 Requirement for design load

of fire escapes

Derived 16

9 Availability of more

adequate exitway

Input

10 Front of building Input

11 Projecting beyond building

line

Input

12 Height of lowest landing

above grade

Input

13 Counterbalanced stair to

street

Input

14 Fixed ladder to roof Input

15 Alley or thoroughfare less

than 30 feet wide

Input

16 Design live load Input

17 Steel or other noncombustible

material

Input

18 Wood not less than 2 inches

thick

Input

10
Table 2.1 Datum list for fire escape example (concluded)

Reference

Number Title Source

Ingredient

Data Items

19 Type of construction Input

20 Fire district Input

21 Stair width Input

22 Riser height Input

23 Tread width Input

24 Landing width Input

25 Landing length Input

26 Landing distance below access Input

27 Hour opening protective Input

28 Within fire limits Input

29 Requirement for landing

clearance

Derived 10,11,12,13,14,15,

26

30 Requirement for material

type

Derived 6,7,17,18,19,20,28,

32,33

31 Requirement for stair

dimensions

Derived 21,22,23

32 Number of occupants Input

33 Wood or similarly

combustible material Input

34 Requirement for fire rating

of doors and windows

Derived 2,27

35 Requirement for landing

dimensions

Derived 24,25

11
Table 2.2 Requirement for permission to use fire escapes (datum number 1)

1 2 E

Use group L2 or L3 (2) T F

Special order of building official (3) AND

existing building (4) AND

height not greater than 5 stories (6) AND

height not greater than 65 feet (7) AND

more adequate exitway impossible (9)

T

Requirement = satisfied X X

Requirement = violated X

Table 2.3 Requirement for design load of fire escapes (datum number 8)

1

1

2

1 2

Design live load > 100 psf (16) T F

Requirement = satisfied X

Requirement = violated X

12
Table 2.4 Requirement for landing clearance (datxim number 29)

1 2 3 4 5 6 E

1 Front of building (10) T T F F T F

2 Projecting beyond building line (11) T F T

3 Counterbalanced stair

to street (13) AND

fixed ladder to roof (14) AND

10 ft < height of lowest

landing (12) < 14 ft

T • F

4 Alley or thoroughfare < 30 ft wide (15) F • T F T

5 Height of lowest landing (12) > 14 ft • • T • F

6 Landing dist. below access (26) < 8 in T T T T

1 Requirement = satisfied X X X X

2 Requirement = violated X X X

Table 2.5 Requirement for material type (datum number 30)

1 2 3 4 5 E

1 Steel or other noncombustible

material (17)

T - - - -

2 Within fire limits (24) F F T T

3 Height < 3 stories (6) AND

height < 40 feet (7) AND

number of occupants < 20 (32)

T F

4 Wood or similarly combustible

material (33)

- T T T T

5 Within fire district 2 (20) AND

type 3 or type 4 construction (19) AND

wood < 2 inches thick (18) AND

height < 3 stories (6)

T F

1 Requirement = satisfied X X X

2 Requirement = violated X X X

13
Table 2.6 Requirement for stair dimensions (datum number 31)

1 E

1 Stair width (21) > 22 in T

2 Riser height (22) < 8 in T

3 Tread width (23) > 8 in T

1 Requirement = satisfied X

2 Requirement = violated X

Table 2.7 Requirement for fire rating of doors and windows

(datum number 34) 12 3

1 Use group L2 or L3 (2) T F F

2 Fire rating of doors and windows > 3/4 hr (27) T F

1 Requirement = satisfied X X

2 Requirement = violated X

Table 2.8 Requirement for landing dimensions (datum number 35)

1 E

1 Landing width >40 in (24) T

2 Landing width > 36 in (25) T

1 Requirement = satisfied X

2 Requirement = violated X

14
and actions and the vertical columns of rules are numbered in each decision

table for reference purposes.

A simple nomenclature is used in the decision tables. A "T" or "Y" in a condition entry indicates that the condition must be true for the particular rule to apply. An "F" or "N" in a condition entry indicates that the

condition must be false. An "I" or in a condition entry indicates the

condition is immaterial; it can be either true or false. A in a condition entry indicates the condition is implicitly false because of another

condition, and a indicates the condition is implicitly true. An "X" in an action entry indicates which action is to be taken for a given rule.

Tables 2.2, 2.4, 2.5, 2.6, and 2.8 have a last rule labeled "E" (for Else)

that is matched by any combination of conditions not matched by any preceding rules. The action corresponding to an else rule is either the issuance

of an error message (if the combination of conditions is impossible) or the

assignment of "violated" to the datum corresponding to the table (if the

combination of conditions is unacceptable)

The numerals in parentheses in the condition stubs of the decision tables

are the reference numbers of the data items that must be known in order to

evaluate the particular condition. Each datum referenced in a condition

stub is an ingredient of the datum defined by the action. The latter datum

is termed a dependent of each of its ingredients.

Table 2.2 illustrates most of this decision table nomenclature. In this

table, rule 1 applies if condition 1 is true since condition 2 is then

immaterial; action 1 is taken. Only ingredient datum 2 had to be known in

order to determine that rule 1 applies and to evaluate the dependent datum.

If condition 1 is false and condition 2 is true, rule 2 applies, and action

1 also is taken. For all other combinations (here, only one), the else

rule applies, and action 2 is taken. Ingredient data items 3, 4, 6, 7, and 9 had to be known in addition to datum 2 to determine which of rule 2 and the

else rule applies and to evaluate the dependent datum.

A decision tree can be generated from the logic represented in a decision

table to explore the significance of the else rule. The decision tree

corresponding to table 2.5 is shown in figure 2.2. Each of the else rules

in the decision tree represents a combination of conditions not covered by

a rule in the decision table. Each such combination can be checked to

determine whether it is feasible and should have an explicit rule and

action. The else rules found in figure 2.2 turn out to be infeasible- - they

describe a material that is neither combustible nor noncombustible.

2.1.4 Information Network

The ingredient data items are those whose values must be known in order to

evaluate the dependent. For example, datum 1, Requirement for the Use of

Fire Escapes, has ingredient data items 2, 3, 4, 6, 7, and 9, as shown by

tables 2.1 and 2.2. The set of ingredient data items is called the ingre

dience of the dependent. Similarly, the set of data items dependent on an

15
Figure 2.2 Decision tree for the logic in table 2.5.

Logical tests of conditions are shown as diamonds with

"T" and "F" labelling the branches corresponding to

true and false values of the condition tested.

ingredient datum is called its dependence . For example, datum 2, Use

Group, has dependents 1 and 34, as shown by tables 2.1, 2.2, and 2.7.

An information network is used to represent the precedence relations among

the data items in the standard. Each datum corresponds to a node in the

network and branches are drawn from each ingredient to its dependent

datum(s). The information network graphically represents the flow of

information through the data items and the decision points in the set of

provisions. Figure 2.3 shows a portion of the information network for the

fire escape example. This particular example leads to a shallow, straightforward network. Many standards lead to complex networks many levels deep.

It should be apparent that, irrespective of its complexity, the entire

information network can be assembled once each datum and its direct ingredients are known.

2.1.5 Classification System

A classification system based on a model structure for provisions [9] is

used to generate outlines, organizations, and indices that represent the

arrangement and scope of the standard. All requirements as well as any

determinations that are likely to be referred to directly by users must be

classified.

The model structure of a requirement includes two parts, a subject and a predicate. The subject may be a physical entity (for instance, a part of a

16
Derived data items

Figure 2.3 Portion of information network for the fire escape example

building), a process (for example, design or manufacture), or a participant

in the process (for example, a designer, builder, or regulatory agency).

The predicate is a particular quality or action required of a subject (for

instance, strength or stiffness of a building part or submission of quality

assurance documents from a manufacturer) . The classification system for a standard, then, is based on the names, called classifiers . of all of the

subjects and predicates covered by its privision.

The classifiers for the fire escape example are listed in table 2.9. They

were selected by naming the subject and predicate of each of the requirements shown in table 2.1.

The list of classifiers pertaining to a particular provision is called the

argument list of that provision, as is the collection of lists for all the

provisions. The argument list for the fire escape example is given in table

2.10. The list of provisions coming under a particular classifier is called

the scopelist of that classifier, as is the collection of lists for all the

classifiers. The scopelist for the fire escape example is shown in table

2.11. The scopelist can be generated by transposing the argument lists for

all the provisions. The use of these lists is discussed in Chapter 4.

Once selected, the classifiers are systematically organized into a hierarchy to represent the successively finer subdivisions of the subjects and

the required qualities (predicates) falling within the scope of a standard.

Figure 2.4 provides one possible hierarchy of classifiers for the fire

escape example with one field for subjects under the principal heading

"building" and another field for predicates under the principal heading

"acceptability." The hierarchy of a major standard may involve many fields.

17
Table 2.9 Classifier list for the fire escape example

(a) Subjects

Reference

Number Title

1 Fire escape

2 Landing

3 Material

4 Doors and windows

11 Components

12 Stairs

13 Mechanical parts

14 Apertures

17 Building

(b) Predicates

Reference

Number Title

5 Permitted usage

6 Design strength

7 Clearance

8 Combustibility

9 Dimensions

10 Fire rating

15 Live loads

16 Dead loads

18 Acceptability

18
Table 2.10 Argument list for the fire escape example

Provision Classifier

1 Requirement for permission to use fire escapes 1 Fire escape

5 Permitted usage

8 Requirement for design load of fire escapes 1 Fire escape

15 Live loads

29 Requirement for landing clearance 2 Landing

7 Clearance

30 Requirement for material type 3 Material

8 Combustibility

31 Requirement for stair dimensions 9 Dimensions

12 Stairs

34 Requirement for fire rating of doors and windows 4 Doors and windows

10 Fire rating

35 Requirement for landing dimensions 2 Landing

9 Dimensions

19
Table 2.11 Scopelist for the fire escape example

Classifier Provision

1 Fire escape 1 Requirement for permission to use fire escapes

8 Requirement for design load of fire escapes

2 Landing 29 Requirement for landing clearance

35 Requirement for landing dimensions

3 Material 30 Requirement for material type

4 Doors and windows 34 Requirement for fire rating of doors and windows

5 Permitted usage 1 Requirement for permission to use fire escapes

6 Design strength

7 Clearance 29 Requirement for landing clearance

8 Combustibility 30 Requirement for material type

9 Dimensions 31 Requirement for stair dimensions

35 Requirement for landing dimensions

10 Fire rating 34 Requirement for fire rating of doors and windows

11 Components

12 Stairs 31 Requirement for stair dimensions

13 Mechanical parts

14 Apertures

15 Live loads 8 Requirement for design load of fire escape

16 Dead loads

17 Building

18 Acceptability

20
Subject field

Building

Fire escape

Material

Components

Landing

Stairs

Mechanical parts

Apertures

Doors and windows

Predicate field

Acceptability

Permitted usage

Design strength

Live loads

Dead loads

Combustibility

Dimensions

Clearance

Fire rating

Figure 2.4 A hierarchy of classifiers for the fire escape example

21
The subject and predicate fields in the classifier hierarchy are combined

to generate three related representations of possible arrangements of a standard. An organization is a tabular arrangement of headings, each

heading corresponding to a specific classifier. A possible organization for

the fire escape example is shown in figure 2.5.

An outline contains, in addition to the headings, the pertinent provisions

classified under the selected heading. An outline for the fire escape

example is shown in figure 2.6. As an illustration of the use of an outline

(along with the decision tables for the provisions) in the expression of a standard, new text has been generated for the fire escape example from the

outline in figure 2.6. The new text is given in figure 2.7.

Finally, an index provides an alphabetized listing of classifiers, with a listing of the scopelist of each classifier, that is, of the provisions

associated with each classifier. An index for the fire escape example would

be a trivial reordering of table 2.11 and isn't shown.

2 . 2 The SASE Program

2.2.1 SASE Program Summary

The SASE program is an integrated collection of computer aids for the analysis, synthesis, and expression of standards. The salient features of the

SASE program are:

• integration of all functions into a single system;

• maintenance of all information in a database, thus providing facilities to store, analyze, modify, and combine information about ver- sions of a standard as it progresses through its "life cycle" of

initial formulation, revisions, modification, adoption, and maintenance ;

• convenient user interaction for entry, analysis, modification, and

display geared to users with varying levels of proficiency;

• facilities for processing and combining large standards subdivided

into several units, which may be analyzed or synthesized by different groups of experts or analysts; and

• facilities for interfacing with additional capabilities, including

text generation and computer-aided design, to be developed in the

future

The SASE program provides the following major functions to the analyst:

« data management for storage and maintenance of the information con- tained in a standard;

• analysis to check decision table representations of provisions of a standard for uniqueness and completeness;

22
I. Fire escape

A. Permitted usage

1. Material

2 . Components

B. Dimensions

1. Material

2 . Components

a . Landing

i. Clearance

b. Stairs

i. Clearance

c. Mechanical parts

i. Clearance

C. Design strength

1. Live loads

a. Material

b . Components

2. Dead loads

a. Material

b . Components

D. Combustibility

1. Material

2 . Components

II. Apertures

A. Fire rating

1. Doors and windows

Figure 2.5 An organization for the fire escape example

generated from the hierarchy in figure 2.4.

23
I. Fire escape

A. Permitted usage

- Requirement for permission to use fire escapes

1. Material

2 . Components

B. Dimensions

1. Material

2 . Components

a . Landing

- Requirement for landing dimensions

i. Clearance

- Requirement for landing clearance

b. Stairs

- Requirement for stair dimensions

i. Clearance

c . Mechanical parts

i. Clearance

C. Design strength

1. Live loads

- Requirement for design load of fire escape

a. Material

b , Components

2. Dead loads

a. Material

b. Components

D. Combustibility

1. Material

- Requirement for material type

2 . Components

II. Apertures

A. Fire rating

1 . Doors and windows

- Requirement for fire rating of doors and windows

Figure 2.6 An outline for the fire escape example

corresponding to the organization in figure 2.5.

24
SECTION 623.0: FIRE ESCAPE

623.1 Permitted Usage

Fire escapes are unconditionally permitted in use groups L2 and L3 (oneand two-family and multi-family dwellings). In all other use groups,

fire escapes are permitted only on existing buildings with height of not more than 5 stories and not more than 65 feet, and only if more adequate

exit ways do not exist, by special order of the building official.

623.2 Dimensions

623.21 Landings. No landing shall be less than 40 inches wide and 36

inches long. No landing shall be more than 8 inches below the bottom of

an access window or door. Lowest landings which project beyond the front

building line shall have counterbalanced stairways to the street, fixed

ladders to the roof, and shall be between 10 and 14 feet, inclusive,

above the street. Lowest landings in alleyways or thoroughfares less

30 feet wide shall not be less than 14 feet above the alley or thoroughfare

.

623.22 Stairs. Stairs shall be not less than 22 inches wide, with

risers not greater than 8 inches and treads not less than 8 inches.

623.3 Design Strength

The fire escape shall be designed to support a minimum live load of 100

psf

.

623.4 Combustibility

Steel or other noncombustible materials are unconditionally acceptable

for the fabrication of fire escapes. Wood or other combustible materials

are acceptable for the fabrication of fire escapes outside the fire

limits if the building height is not greater than 3 stories and not

greater than 40 feet, and if the occupant load is not greater than 20

persons. Wood at least 2 inches thick is acceptable for the fabrication

of fire escapes within the fire limits if the building is within Fire

District 2, is of type 3 or type 4 construction, and has a height not

greater than 3 stories.

623.5 Fire Rating of Building Aperture

For use groups other than L2 or L3 , the fire rating of doors and windows

providing access to fire escapes must be at least 3/4 hour.

Figure 2.7 New text for the fire escape example

generated from the outline in figure 2.6.

25
• information network model which enables the evaluation of relations

among provisions of a standard and provides checks to ensure that

these relations are connected and acyclic;

• organization model which permits the exploration of alternative

ways of organizing a standard without losing information contained

in the document or changing the standard's meaning; and

• index generator which extracts information from a given organization of a standard.

2.2.2 SASE Database Organization

The components of standards represented in SASE are called entities. The

entities are organized into three groups, according to type, and each group

has an associated set of commands specifying the actions to be performed on

the designated entities.

Each entity is defined by the value of a set of attributes, one of which

serves as the reference (or key) for uniquely identifying a specific entity.

The three groups are briefly discussed below. In the discussion, reserved

words in the SASE program, such as entity names, attribute labels, and

commands are shown in capital letters.

Organizational Entities. This group of entities refers to the global organizing elements in the SASE database, and includes:

• STANDARD - the specific standard currently under consideration;

• VERSION - a particular stage of a standard (e.g., original, trial,

modification, adopted, etc.) and

« CHAPTER - a major subdivision of the current version.

Organizational entities are identified by name and contain attributes such

as title and description.

The SASE commands applicable to organizational entities are:

• CREATE a new entity;

• USE a previously defined entity;

• ADD, MODIFY, AND DELETE attributes;

• LIST entities currently in database; and

® DESTROY an entity.

26
Basic Entitles. This group of entities contains the detailed information

about a standard, and includes;

• DATUM - representing individual data items;

• TABLE - representing individual decision tables;

• FUNCTION - representing functions; and

• CLASSIFIER - representing individual classifiers.

DATUM and CLASSIFIER entities are identified by a reference number. TABLE

and FUNCTION entities are identified by the reference number of their cor- responding DATUM. The specific attributes of each entity are discussed in

the following chapters.

The SASE commands applicable to this class of entities are:

• ENTER an initial definition;

• ADD, MODIFY, OR DELETE attributes;

• DISPLAY an entity or set of entities;

• DELETE an entity.

Derived Entities. This group contains entities generated from the basic

entities, and includes:

• TREE generated from a decision table;

• NETWORK generated from the data items

;

• HIERARCHY generated from the classifiers;

• SCOPELIST generated from the hierarchy and data items;

• INDEX generated from the scopelist;

• ORGANIZATION generated from the classifiers;

• OUTLINE generated from the classifiers and data items.

ORGANIZATION entities are identified by a reference number. TREE entities

are identified by the reference number of the decision tables from which

they are generated. The other entities in this group do not have a reference, as (in the present version of SASE) only one entity of each type can exist at any one time in a VERSION of a standard.

The SASE commands applicable to this group are:

• GENERATE to derive the entity;

27
DISPLAY the entity;

• DELETE the entity.

In addition, an ORGANIZATION may be initially ENTERed by the user instead

of being GENERATEd at the same time as its associated OUTLINE. Because the

construction of satisfactory ORGANIZATIONS and OUTLINES is a complex process, interactive dialog modes are made available to the user including the

ability to interrupt and then CONTINUE their entry.

The hierarchical relationships among the entities in the SASE database is

shown in figure 2.8.

The combinations of command/entity pairs available in the SASE program are shown in table 2.12.

28
STANDARD

29

Figure

2.8

Organization

of

the

SASE

Database
Table 2.12 Available SASE command/entity combinations

Commands

(create) ( change

)

(examine) (remove)

R

E

G S C

E E 0 D D

C N M Q N I E D

R E E 0 u T S S E

E N R D E I L P T L

A T A A I N N U I L R E

T E T D F C U S S A 0 T

Entities E R E D Y E E E T Y Y E

(organizational)

STANDARD X X xi X X X X^

VERSION X X X X X X X

CHAPTER X X X X X X X

(basic)

DATUM X X X X X X

TABLE X X X X X X

FUNCTION X X X X X

CLASSIFIER X X X X X X

(derived)

TREE X X X

NETWORK X X X

HIERARCHY X X X

SCOPELIST X X X

INDEX X X X

ORGANIZATION X X X X X

OUTLINE X X X X

1 Only non-key attributes can be modified or deleted.

30
3. MODELLING THE INFORMATION OF A STANDARD

This chapter presents the SASE techniques for modelling the information of

a standard. The model is essentially independent of the organization and

expression of the information. Major sections are: Data Items, Provisions, Decision Tables, Decision Trees, Functions, and Networks. The

reader is encouraged to examine the Appendix A, which presents an example

to illustrate the application of these techniques to a standard.

3 . 1 Data Items

3.1.1 Definition

A data item or datum is an information element occurring in a standard.

Conventionally, a standard contains a list of definitions of key information elements and a table of nomenclature for information elements identified by symbols. All these information elements are identified as data

items in SASE. For a complete representation, SASE typically requires many

additional data items not normally included in definitions or the table of

symbols

.

The identification of data items representing the information content of a standard is somewhat analogous to the parsing of sentences. The identification of significant information elements to be designated as data items

has to be guided by the analyst's experience and "feel" for the intent and

scope of the standard being analyzed. It is best to approach this task

incrementally, initially identifying only obvious key data items, and then

supplementing these as the analysis proceeds in depth.

3.1.2 Proper Usage

The selection of data items must be guided by the analyst's experience and

judgment. The following suggestions may be of assistance.

Granularity

.

New users of SASE have a tendency to identify more data items

than necessary for describing the intent and content of a standard. It is

important to use the right "granularity" and identify only the meaningful

data items. Additional items can always be entered later, say, when a detailed decision table analysis identifies additional ingredients.

Existence- type items. It is easy to overlook Boolean data items specifying

a true or false quantity, such as the existence of a particular object or

state. Thus, to represent the sentence: "If stiffeners are provided and

they are spaced ...", a Boolean data item, "stiffeners provided" is needed

in addition to the numeric data item "stiffener spacing".

Options and alternatives

.

Standards frequently, contain words such as "optionally" , "preferably" or "alternately", indicating user choices. It is

important to identify each of these as individual Boolean data items, with

appropriate titles such as "option desired" or "alternate exercised"

.

31
Regulatory options. Similar to the above, standards contain statements

such as "building official may require", "values satisfactory to the building official," etc. All such options must again be identified as specific

data items, with appropriate titles such as "required by building official"

or "acceptable to building official."

Use of Boolean vectors. Compactness and clarity of representation can be

achieved by the use of Boolean vectors instead of separate individual

Boolean data items. Thus, a single data item -'building type" with possible

values of "new" and "existing" is preferable to two separate Boolean data

items. Boolean vectors can be extended to more than two entries, such as a "building category" item with possible values of "A", "B", "C" , or "D"

.

Data items such as "load type" and "element type" fall into this category.

It will be seen in section 3.3 that many of the conditions in decision

tables are directly in the form of "Boolean vector datum = one of its

possible values". It is good practice to use the COMMENT field to record

the possible values of a Boolean vector datum.

3.1.3 Representation

Each data item is represented in SASE by a datum entity. The attributes

describing a datum are discussed below.

REFERENCE NUMBER. The reference number is a numeric key for identifying

the datum. The reference number must be unique within a version. A con- venient identification scheme is to use a five -digit reference number, the

first two digits referring to the chapter and the last three digits sequentially assigned within the chapter in increments of 10, thereby providing

space for reference numbers for data items to be inserted later.

NAME

.

Any short, mnemonically meaningful alphabetic designation. While

this attribute can be useful now as a memory aid to the analyst, its primary use will be in executable computer programs that represent the standard.

TITLE

.

Any descriptive title of the datum entered, as a text string. Its

most common use is in the preparation of the index.

SECTION

.

The alphanumeric designation of the section in the existing standard. This and the PAGE attribute are used for cross-referencing to the

text of an existing standard.

PAGE The page number in the existing standard.

VALUE

.

This attribute defines the kind of value used for expressing the

data item, and can be one of the following:

• NUMERIC, meaning that the data item is expressed as a number;

• BOOLEAN, meaning that the data item is a fact (a true or false

quantity) ; or

32
• BV for Boolean vector, meaning that the data item can take on a value from a fixed list or vector of distinct names or numbers.

SOURCE

.

Designates whether the datum is INPUT or DERIVED from other data

items. This and the following three attributes relate to the position of

the datum in the information network, which will be discussed further in

section 3.2 through 3.6.

TYPE

.

If the datum is DERIVED, this attribute- designates whether the derivation is by means of a decision TABLE (see section 3.3) or a FUNCTION (see

section 3.5).

UTILIZATION

.

If the datum is DERIVED, this attribute designates whether

the datum is a REQUIREMENT or a DETERMINATION (see section 3.2).

INGREDIENTS

.

If the datum is DERIVED, the list of ingredient data items is

given, identified by their dattim reference numbers.

STATUS

.

Designates whether the dattim is CLASSIFIED or UNCLASSIFIED. This

and the ARGUMENT attribute relate to the position of the datum in the

classification hierarchy, which is discussed in Chapter 4.

ARGUMENTS

.

If the datum is CLASSIFIED, the list of its classifiers is

given, identified by their classifier reference numbers. The argument list

may be preceded by the words INDEX or OUTLINE, designating that the datum

be included in the index or outline only.

EQUIVALENTS

.

In the analysis of existing standards, the situation frequently arises where the text uses a variety of names for what is actually

a single thing. Such equivalents initially can be cross-referenced by

their datum reference numbers as they are detected and the duplication

subsequently eliminated.

COMMENT

.

Any descriptive information or comment may be entered as a text

string

.

3 . 2 Provisions

3.2.1 Definition

Provisions are the basic units of a standard. Each provision is a normative statement, stipulating that some object or process within the scope of

the standard is to have a certain quality or property.

Provisions are distinguished by their use:

• Requirements are provisions that directly determine compliance with

the standard; they are Boolean valued, with the values of true or false interpreted as satisfied or violated, respectively; while

33
• Determinations are all other provisions; these may include numerical, nominal, and Boolean valued items which can not be characterized as satisfied or violated.

Requirements contain two basic components: a subject and a predicate. The

subject is a physical entity, a process or a participant in the process,

and the predicate defines the particular quality required of the subject.

Requirements play a key role in the SASE methodology. On the one hand,

they are the highest nodes of the information network (see section 3.6):

the information network traces the data items, which when evaluated, determine whether the stipulations of the standard are satisfied or not. On the

other hand, requirements are the lowest nodes of the classification system

(see Chapter 4) : the hierarchy of classifiers defining the scope and

organization of the standard is built up from the "elementary" classifiers

defining the subjects and predicates of the requirements.

Harris and Wright [9] define six types of requirements;

• Basic requirements have a singular subject and a singular predicate. They do not directly depend on other requirements.

« Multiple requirements have plural subject and/or predicates. They

do not directly depend on other requirements

• Cumulative requirements depend unconditionally only on other re- quirement data items. The logic of the provision does not contain

any original requirements

• Application requirements depend conditionally on at least one of

the ingredient requirements. The provision does not contain an original requirement, nor is it equivalent to a new basic requirement .

® Synthetic requirements are like application requirements except

that they are equivalent to a new basic requirement.

• Mixed requirements depend directly on other requirements (either

conditionally or unconditionally) and the provision does contain an original statement of a requirement.

3.2.2 Proper Usage

In synthesis. In synthesizing a new or revised standard, it is important

not to constrain the organizational system from developing alternative ar- rangements based on the classifier hierarchy. Therefore, it is recommended

that [ 9 ]

• Mixed requirements not be used;

• Cumulative requirements not be used;

34
• Multiple Requirements be used only in those instances in which the

constituent basic requirements would be most likely to remain

together in all practicable arrangements, and then only with caution; and

• Application requirements that simply group ingredient requirements

not be used.

In analysis. In analyzing or representing an existing standard, it will be

frequently found that individual requirements are lumped together, i.e.,

that a section or even a single existing provision may contain several

unrelated individual requirements. The analyst may be tempted to create

one or more cumulative requirements to express all the requirements of the

section or original provision. This practice is to be avoided because

cumulative requirements constrain the exploration of alternative arrangements; also, cumulative requirements will be difficult to classify by the

procedures described in Chapter 4.

3.2.3 Representation

In SASE, provisions are represented by the data items that carry the value

of the provision. Data items representing provisions are distinguished by

the following attribute values

• SOURCE is DERIVED, since, by definition, the value of the provision

must be derived from the values of other ingredient data items

;

• TYPE is either TABLE or FUNCTION, depending on how the logic of

derivation is expressed;

• UTILIZATION is either REQUIREMENT or DETERMINATION; and

• the list of INGREDIENTS is non-empty.

Furthermore, all requirements, as well as many key determinations, will

have non-empty lists of ARGUMENTS since they are to be located using the

classification system.

3 . 3 Decision Tables

3.3.1 Definition

Decision tables are used to represent and examine the logical structure of

individual requirements in a standard. They may also be used for all other

data items whose value is derived by procedures or rules described in the

standard. The following discussion begins with a general description of

decision tables before arriving at the specific form of decision tables

used in SASE.

General

.

A decision table defines a set of rules specifying certain ac- tions to be executed based on a specific set of conditions. Decision

tables are a convenient means to express the logic for a set of decisions.

35
Decision tables were developed in the late 1950' s to describe logical

problems for computer programming when flow charting proved to be too

complex and cumbersome. Decision tables have met with success because they

require an overall analysis of situations involving parallel thought pro- cesses. Written text and, to some extent flow charts, both describe se- quential thought patterns. References [14, 11] contain general information

on decision tables.

A decision table is composed of conditions, actions, and rules. A condition is a logical statement that may have only one of two values; true or false. An action in a general sense is any operation, e.g., it may be the

assignment of a value to a variable by means of a formula, or a statement

that prescribes a set of conditions in order that a specified set of ac- tions can be performed. A decision table is a structure for defining a set

of related rules. The conventional structure of a decision table is shown

in table 3.1.

The condition stub lists each condition in the table, one to a row. The

action stub does the same for the actions. The condition entry lists the

combinations of values of the conditions, one set to a column. Each column

in the condition entry defines a rule. The action entry indicates which

actions are to be executed for each rule. The rule is a logical AND function, that is, the rule is not satisfied unless each of the condition

entries it contains is matched.

Extended Entry Tables. The most general form of decision table is known as an extended entry table. The statements contained in the stubs of these

tables are generally incomplete, in that the stub and an entry value together make a complete statement. This form of decision table is very

flexible and is readily interpreted by readers. Many tables in existing

standards are essentially of this type, although the physical arrangement

is generally not as shown in table 3.1. For example, consider a sample

provision taken from [15] and shown in table 3.2.

36
Table 3.2 Sample provision

Specific minimum yield

point of lowest strength

steel being joined

Electrode

classification

ASTM

Permissible stress in

shear on throat of

fillet or plug welds

< 36 ksi A233E60 13.6 ksi

> 36 ksi but A233E60 13.6 ksi

< 50 ksi A233E70 15.8 ksi

> 50 ksi

A316E70 15.8 ksi

A326E80 17.7 ksi

In this example, the first two columns correspond to conditions, the third

column corresponds to an action, and the rows correspond to rules. This

same information is rewritten as an extended entry decision table in table

3.3.

In many standards, ingenious table formats have been devised to represent

the logic associated with a particular decision when a narrative description is not practical. However, the tables become hard to interpret when

more than two or three conditions are involved. Extended entry decision

tables are by no means new or unique, but the formal structure that allows

the combination of many conditions was not developed fully until the 1950'

s

[ 1^].

Limited Entry Tables. Primarily because they are so flexible, extended

entry decision tables do not lend themselves to a routine analysis of their

logic, and are difficult for computer programs to interpret automatically.

A more widely used form of decision table, the limited entry form, avoids

these problems. The condition stub of limited entry tables contains only

complete logical statements which can have values of true or false. The

Table 3.3 Extended entry decision table

Minimum yield point

of lowest strength

steel is

<36

ksi

>36 but

<50 ksi

>36 but

<50 ksi

>50

ksi

>50

ksi

ASTM electrode is A233E60 A233E60 A233E70 A316E70 A316E80

Permissible shear 13.6 13.6 15.8 15.8 17.7

stress = ksi ksi ksi ksi ksi

37
condition entry contains only the values of the conditions (true or false)

and the action entry contains an "X" if an action is to be executed or a blank if not. An elementary extension of the concept allows the use of an immaterial entry in the condition entry, which means that the particular

rule does not depend on the value of the condition for the row with the

immaterial entry. Conventional symbols used in limited entry tables are:

"T" or "Y" for true, "F" or "N" for false, and an "I", dot, or blank for

immaterial in the condition entry; a blank or a dash for "don't execute"

and an "X" for "execute" in the action entry.

Extended entry tables may be converted to limited entry tables in a straightforward manner. Table 3.4 contains the conversion of the extended

entry table shown in table 3.3. The new table has the same number of rules

as the original table, but considerably more conditions and actions. Each

extended entry condition must be divided so that all of its possible re- sponses can be covered by limited entry conditions. Thus, the first condition of table 3.3 is divided into two limited entry conditions that are capable of defining the three bounded ranges. The second condition of table

3.3 is divided into four limited entry conditions, one for each of the

unique entries in the original condition.

Preparation of Conditions. Actions, and Rules. One of the keys to the

successful use of decision tables in the analysis and synthesis of standards is the proper formulation of condition and action stubs. There are

two fundamental principles for the use of decision tables to represent,

provisions of standards.

The first principle is that each decision table establishes the value for

only one data item. This restriction allows each decision table to be

Table 3.4 Limited entry decision table

F„ < 36 ksi

j

T F F F F

Fy < 50 ksi T T T F F

A233E60 T T F F F

A233E70 F F T F F

A316E70 F F F T F

A316E80 F F F F T

F.^ = 13.6 ksi X X

= 15.8 ksi X X

F^ = 17.7 ksi X

38
uniquely associated with one datum, which becomes a node in the information

network, and it allows the ready determination of the ingredients of that

node. The only allowable actions are those which establish a value for the

data item associated with the decision table. All of the other data items

used in the conditions and actions are the ingredients. Uhile this principle restricts somewhat the great flexibility of decision tables, it does

lead to a desirable consequence: the decision tables thus formed tend to be

small and therefore easy to formulate, understand, and analyze.

The second principle is that, constants and operators aside, each condition

stub and action stub contains only data items defined as nodes in the

information network. This is necessary so that the information network can

serve its function of providing access to all the necessary data items.

This principle sounds elementary; however, some skill is required in formulating a standard such that the set of data items is consistent. Among the errors that occur are omission of data items, use of multiple names for the same item, and use of the same name for different items.

As an example of the formulation of conditions and actions for a decision

table, consider another sample provision taken from [15] and presented in

figure 3.1.

The provision deals entirely with the evaluation of one datum, the allowable stress, F(,. There are four ingredients, variables that may affect the

value of F(,

• the yield stress, Fy|

• the width, w;

• the thickness, t; and

• the type of member (angle strut or other section)

.

The step by step procedure for formulation of a decision table is flexible.

One approach is to write down first the easily identifiable actions:

1. Fc = 0.60 Fy

2 . = given by formula 1

3. Fc = 8,000/(w/t)2

4. Fc .= 19.8 - 0.29 (w/t)

5 . = given by formula 2

Note that the fifth action was found in a footnote of the cited reference.

From a first reading of the provision, it is clear that the width- thickness

ratio, w/t, is very important and that several conditions will involve it.

39
3.2 Compression of Unstiffened Elements

Compression, F^,, in kips per square inch, on flat unstiffened

elements

(a) For w/t < 63.3/7Fy: F^, = 0.60Fy

(b) For 63.3/7Fy < w/t <

^

Fc = Fy [0.767 - (2.64/103)(w/t)7Fy] Formula (1)

(c) For 144/7Fy <w/t <25:*

= 8,000/(w/t)2

(d) For 25 < w/t < 60:**

For angle struts:

Fc = 8, 000/ (w/t)

For all other sections:

F^ - 19.8 - 0.28 (w/t)

In the above formulas, w/t = flat-width ratio as defined in section 2.2

*When the yield point of steel is less than 33 ksi, then for w/t

ratios between 63.3/7Fy and 25:

**Unstiffened compression elements having ratios of w/t exceeding

approximately 30 may show noticeable distortion of the free

edges under allowable compressive stress without detriment to the

ability of the number to support load.

For ratios of w/t exceeding approximately 60 distortion of the

flanges is likely to be so pronounced as to render the section

structurally undesirable unless load and stress are limited to

such a degree as to render such use uneconomical.

Fc = 0.60Fy

[w/t - 63.3/7Fy](0.60Fy - 12.8)

Formula (2)

25(1 - 2.53/7Fy)

Figure 3.1 Sample provision

40
It is convenient to write related conditions in adjacent positions, as follows

1. w/t < 63.3/7Fy

2. w/t < 144/7Fy

3. w/t < 25

4. w/t < 60

5. Member type = angle strut

The next step in the preparation of the table is to begin writing the

rules, one rule at a time. The process is iterative, so the initial order

of conditions and rules is not of paramount importance. The first three

rules are easily identified: for rule one, condition one is true and the

action is one; for rule two, condition one is false, condition two is true,

and the action is two; for rule three, condition two is false, condition

three is true, and the action is three. Choosing to ignore temporarily the

first footnote, rules four and five can be formulated: for both rules,

condition three is false and condition four is true; condition five is true

for rule four and false for rule five while rule four uses action three and

rule five uses action four.

In taking account of the first footnote, a new rule is formed which involves a new condition:

6 . Fy < 3 3 ks

i

For the sixth rule condition one is false, condition three is true, condition six is true, and the action is five. The decision table at this stage

is shown in table 3.5.

At this point, one iteration in the formulation of the rules is complete.

It should be emphasized that the blanks in the condition entry do not

necessarily represent immaterial entries, because no consideration has been

given to them yet. The conditions and actions can be seen to be in agreement with the stated principles of formulation. Completing the example

will not add to the study of conditions and actions, but it is instructive

in that it points out the manner in which decision tables demand full

consideration of the situation being defined.

For rule one, condition two is obviously true if condition one is. Conditions three and four are not so obvious. A simple calculation indicates

that condition three can be false when condition one is true only if

Fy < 6.4 ksi, which is not only unlikely, but . impossible if the material

used meets the ASTM specifications referenced in [15]. For the sake of

illustration, this information will be ignored, as if this one provision

were analyzed in isolation. Therefore, conditions three and four will be

immaterial for rule one. Conditions five and six also turn out to be

immaterial for the rule.

41
Table 3.5 Initial condition entries

1 2 3 4 5 6

1 w/t < 63.3/7Fy T F F

2 w/t < 144/7Fy T F

3 w/t < 25 T F F T

4 w/t < 60 T T

5 Member strut = angle strut T F

6 Fy < 33 T

1 F^, = 0.6 Fy X

2 Fj, = formula 1 X

3 Fc = 8000/(w/t)2 X X

4 F(, = 19.8 - 0.28 (w/t) X

5 F(, = formula 2 X

For rule two, a similar analysis indicates that condition three could be

false if Fy < 33 ksi. Since this is the situation defined in the footnote

and covered in rule six, the entry for conditions three and four is true

while that for condition six is false. Condition five is once again immaterial .

Rule three is completed using reasoning very similar to that for rule two.

For rules four and five, the same limited analysis that was invoked on rule

one is used again; consequently, the entries for conditions one, two, and

six are immaterial for both rules.

For rule six, condition two may be either true or false so an immaterial

entry is made. Condition four is true if condition three is, and condition

five is immaterial. The completed table is shown in table 3.6.

Analysis of this table will show that rule one is not independent of either

rule four or rule five. It can be determined from visual examination that

the same set of condition values will satisfy rules one and four (for

example: T, T, F, T, T, T), and that another set can be found for rules

one and five. [A much easier way to determine this is to attempt to generate a decision tree (see section 3.4)]. As will be discussed further in

the following, all rules in a decision table must be independent, therefore, some modification of the table is necessary. In this case, the

information concerning the possible range of values for Fy must be taken

42
Table 3.6 Completed condition entries

1 2 3 4 5 6

1 w/t < 63.3/7Fy T F F F

2 w/t < 144/yFy T T F • •

3 w/t < 25 T T F F T

4 w/t < 60 • T T T T T

5 Member strut = angle strut • T F

6 Fy < 33 • F F T

1 Fc = 0.6 Fy X

2 F^ = formula 1 X

3 Fc = 8000/(w/t)2 X X

4 Fc = 19.8 - 0.28 (w/t) X

5 Fj, = formula 2 X

into account. As pointed out, this would make condition three true for

rule one. It would also make condition one false for rules four and five.

For rule one, since condition three is true, condition four will be true

also. The revised table is shown in table 3.7.

This completes the illustration of the development of the sample decision

table. Decision trees derived from the various iterations in the development are shown in section 3.4.

Contents of Condition and Action Stubs. Typically, each condition stub

consists of a single condition (true- false comparison) and each action

consists of a single assignment expression or function. Both of these

simple cases can be extended.

Several logical statements may be combined into one condition with the use

of the logical functions AND and OR. Consider the hypothetical condition

"A>B AND C>D AND E>F." The condition will be true if all portions of the

condition are true ,' but it will be false if any one portion is false. If

the AND operators in the example were replaced by the OR operator, the

condition would then be true if any one portion were true, and it would be

false only if all portions were false. Many provisions in standards are conveniently expressed using combined conditions. An example of their use

is included at the end of this section.

43
Table 3.7 Revised condition entries (compare table 3.6)

1 2 3 4 5 6

1 w/t < 63.3/7Fy T F F F F F

2 w/t < 144/7Fy T T F • •

3 w/t < 25 T T T F F T

4 w/t < 60 T T T T T T

5 Member strut = angle strut • T F •

6 Fy < 33 F F • T

1 Ft = 0.6 Fy X

2 Ft =• formula 1 X

3 Ft = 8000/(w/t)2 X X

4 Ft = 19.8 - 0.28 (w/t) X

5 Ft = formula 2 X

Some decisions are appropriate to perform in the action stubs. As an

example, consider a provision for allowable tension stress taken from [16]

and shown in figure 3.2. The decision table for the determination of the

allowable tension stress is shown in table 3.8. The instruction to find

the minimum or maximum of a group of variables is conveniently located as part of the action. Note, however, that logical operations included in the

actions are not included in the decision tree or in any of the checks for

On the net section, except at pin holes:

Ft = 0.60Fy

but not more than 0.5 times the minimum tensile strength of the steel.

On the net section at pin holes in eyebars , pin-connected plates or built-up members:

Ft - 0.45Fy

For tension on threaded parts see Table 1.5. 2.1.

Figure 3.2 Sample provision

44
Table 3.8 Decision table with compound actions

Location = pinhole T F

Ft = 0.45 Fy X

Ft = min (0.60 Fy, 0.50 F^) X

independent rules; therefore errors in their formulation are more difficult

to detect.

The style of defining data items and of writing conditions and actions is an important consideration. A tendency exists immediately to write decision tables for requirements with only two actions, one for the yes value

(satisfied) and one for the no value (violated) . This may lead to decision

tables that are large and difficult to analyze. When the analyst finds

that a decision table is large (consisting of more than about ten rules),

consideration should be given to redefining some of the ingredients, or to

partitioning of the decision table. An example illustrating this point

follows

.

Related Conditions and Implicit Entries. Conditions that involve the same data item are related. In many cases, the value for one condition will

predetermine the value of a related condition. Table 3.5 presents such a case because the four conditions concerning w/t are related In rule one,

the first condition is true; therefore, the second is also true because w/t

cannot be both less than 63.3/7Fy and greater than 144/7Fy. (The expansion

of the entries permitted in a limited entry table allows such situation to

be treated to advantage [14]). The two new condition entries needed to

represent related conditions are implicitly true , , and implicitly

false, They are used when the value of a condition for a rule is predetermined by the values of other conditions for that same rule. Thus,

table 3.6 is transformed into table 3.9.

Besides conditions that compare a data item to bounded ranges, there are other types of conditions that are related. A common situation in standards is the comparison of a data item to the elements of a Boolean vector.

The conditions concerning the type of electrodes is a mutually exclusive

set, that is, only one of them may be used. Therefore, if any one of those

four conditions is true, then the other three must be false. Table 3.4 is

rewritten in table 3.10 taking account of the mutually exclusive set and of

the relation between the conditions with Fy also.

Some sets of mutually exclusive conditions have another property: they are collectively exhaustive (the variable always takes one value from the set)

.

When both properties hold, it is possible to write a rule in two equivalent

ways with implicit entries. Consider the hypothetical variable x which

must take a value from the mutually exclusive and collectively exhaustive

set [A, B, C, D] . The three rules shown in table 3.11 are equivalent.

45
1

2

3

4

5

6

1

2

3

4

5

Table 3.9 Implicit entries (compare table 3.6)

1 2 3 4 5 6

w/t < 63.3//Fy T F - - - F

w/t < 144/VFy + T F •

w/t < 25 + + T F F T

w/t < 60 + + + T T +

Member strut = angle strut • • T F

Fy < 33 F F • T

Fc = o o^ X

Fc = formula 1 X

Fc = 8000/(w/t)2 X X

Fc = 19.8 - 0.28 (w/t) X

Fc = formula 2 X

Table 3.10 Implicit entries (compare table 3.4)

Fy < 36 ksi T F F - -

Fy < 50 ksi + T T F F

A233E60 T T - - -

A233E70 - - T - -

A316E70 - - - T -

A316E80 - - - - T

F^ = 13.6 ksi X X

F.^ = 15.8 ksi X X

F.^ = 17.7 ksi X

46
Table 3.11 Equivalent rules

12 3

X = A F - F

X = B T T +

X = C F - F.

X = D F - F

Note that the set of electrode designators in table 3.10 is not collectively exhaustive because there are many more types of electrodes. It is

possible that they could be made collectively exhaustive if another decision table were used to test the acceptability of the electrodes; the

specification is not complete concerning this question [15].

Uniqueness

.

A very important principle in the theory of decision tables is

that one rule and only one rule must be matched for any given set of variables that are used to define the conditions [14]. That is, the logical

process of a decision table must always find a unique rule in any possible

situation. Another way to state this is to say that all the rules in a table must be independent. It is incorrect for any two rules in the same table to have identical condition entries. When two rules are not unique,

they are called dependent. Note that two rules may be dependent even

though their condition entries are not identical if they contain immaterial

or implicit entries. This was demonstrated in the discussion of table 3.6.

If two rules are dependent and their action entries are the same, they are called redundant, whereas they are called contradictory if their action

entries are different. It is not incorrect for two different rules to have

the same action entries. In some cases, two such rules may be combined

into one. If two rules have identical entries for all conditions but one and have the same action entry then the two rules can be made into one by

placing an immaterial entry at the condition that had the different values

.

Note that the different values in the two original rules should be a true

and a false; if not, one or both of the rules probably contains an error.

Completeness

.

One benefit that can be derived from expressing logic in a limited entry decision table format is that it is possible to determine if

the logic is complete. A decision table is complete if its decision tree

contains no else rules. This is the same as saying that a decision table

is complete when its condition entries contain all of the possible combinations of values for its conditions. Note that this test of completeness

does not consider any logic contained in the conditions.

The recommended way to check the completeness of a decision table is to

generate a decision tree, but it is not the only way. A classical way of

checking the completeness of decision tables is to count the equivalent

47
simple rules [14]. A simple rule is one that contains only true and false

entries. A decision table with n conditions will have 2^^ unique simple

rules. Most decision tables will contain entries other than true and

false. The counting procedure is easily extended to those with immaterial

entries. Defining a compound rule as one that contains an immaterial

entry, a compound rule with r immaterial entries represents 2^ equivalent

simple rules. A decision table with n conditions is complete if the sum of

simple rules --both explicit and equivalent- - is equal to 2^ and the rules

are unique

.

Consider table 3.12 (the condition entry from table 3.7). The last two rows are tabulations of the ntomber of immaterial entries and of equivalent

simple rules for each of the rules in the table. The total number of simple

rules is 20, much less than 2^ = 64, so the decision tree should contain

else rules, which it does, as shown in figure 3.6 in section 3.4, Each of

the else rules in the figure can be considered a compound rule with immaterial entries for those conditions not included on their path. Thus, the

first else rule does not test conditions five and six so it represents four

equivalent simple rules. Likewise, the second else rule represents eight

equivalent simple rules and the last one contains 32, The total number of

simple rules shown in the tree is the sum 20 + 4 + 8 + 32 = 64, which is

the proper total for a decision table with 6 conditions.

An instance where counting simple rules in a table with immaterial entries

can lead to an error is when two or more of the compound rules contain the same simple rule. This error will not occur when using the decision tree

approach because such compound rules are dependent and will always be

identified as such. If the rule counting method is used to check completeness of tables with immaterial entries, care must be exercised to detect

dependent rules

.

Table 3.12 Counting simple rules

1 2 3 4 5 6

Condition 1 T F F F F F

Condition 2 T T F • • •

Condition 3 T T T F F T

Condition 4 T T T T T T

Condition 5 T F

Condition 6 F F • • T

r 2 1 1 2 2 2

2^^ 4 2 2 4 4 4

48
Implicit entries in a table make the counting of equivalent simple rules

unreliable. The reason is that it is not predictable (with any ease) how

many simple rules a rule with implicit entries may represent.

As previously stated, the recommended procedure for checking the completeness of a decision table is to use the decision tree to locate else rules.

All of the else rules, that is, any rule not included in the original

table, will be detected using the decision tree. The condition entries for an else rule can be found by tracing along the path from the else rule to

the start of the tree, taking the condition entry from the sense of the

branch. Any condition not encountered on the path will have an immaterial

entry. Note that implicit entries can not be detected from the decision

tree. Once all the else rules have been found, each should be examined to

determine why it was not anticipated in the original table.

Generally speaking, decision tables for standards should be complete,

because an else rule indicates an error situation. Some tables may be

formulated using an else rule to lead to a specific action. For example,

rules 5 through 10 in table 3.13 in the next section could be replaced with

one else rule leading to action two. However, it is recommended that this

approach not be used by the analyst until all of the rules have been examined. Once this is accomplished, the else rule may be a convenient shorthand.

One exception to this completeness -checking procedure can occur when tables

have implicit entries. It is possible to generate an else rule in the

decision tree which is opposite to the implicit entry in some stated rule.

These else rules do not make the table incomplete.

Style of Table. Previously, it was pointed out that the manner of defining

data items and writing actions has a bearing on the complexity of the

decision tables produced. One example from a model building code [1] will

be used to illustrate this. The provision of interest is included in

section 1411.0 of the code and is shown in figure 3.3. This section includes provisions for sign materials, bottom clearance, maximum height, and

support materials. For the purpose of this analysis, bottom clearance has

been included in the provision for maximum height.

A decision table was written for checking the provision for the maximum

height, with two possible actions (1) height acceptable and (2) height not

acceptable. The decision table appears in table 3.13 and involved a significant amount of preparation. Note, among other things, that conditions 3 and 4 are mutually exclusive but not collectively exhaustive, and that

bottom clearance has been made condition 1 in this table rather than a separate provision.

Table 3.13 is logically complete but complex. Introduction of a new data

item called "Maximum allowable height" leads to a substantial simplification using two decision tables instead of one, as shown in table 3.14.

The revised set of tables involves fewer decisions and is less subject to

misinterpretation.

49
Section 1411,0 Roof Signs

1411.1 Materials: All roof signs shall be constructed entirely of

metal or other approved noncombustible materials except as provided in

section 1409.5. Provision shall be made for electric ground of all

metallic parts; and where combustible materials are permitted in

letters or ther ornamental features, all wiring and tubing shall be

kept free and insulated therefrom.

1411.2 Bottom Clearance: There shall be a clear space of not less

than six (6) feet between the lowest part of the sign and the roof

level except for necesssary structural supports.

1411.3 Closed Signs: A closed roof sign shall not be erected to a height greater than fifty (50) feet above fireproof and noncombustible

buildings (types 1 and 2) nor more than thirty-five (35) feet above

the roof of non- fireproof (type 3) buildings.

1411.4 Open Signs: An open roof sign shall not exceed a height of

one hundred (100) feet above roof of buildings of fireproof and

noncombustible construction, (type 1 and 2); and not more than sixty

(60) feet above the roof of buildings of non- fireproof (type 3)

construction.

1411.5 Combustible Supports: Within Fire Districts Nos. 1 and 2, no roof sign which exceeds forty (40) feet in height shall be supported on

or braced to wooden beams or other combustible construction of a building or structure unless otherwise approved by the building official.

Figure 3.3 Sample provisions

50
1

2

3

4

5

6

7

8

1

2

k'

Table 3.13 First approach to checking maximum height 123456789 10

Clearance < 6' T T T T T T T T T F

Sign const. = closed T T F F T T F F

Bldg. type = 1 or 2 T - T - T - T - F

Bldg. type = 3

- T - T - T - T F •

Height > 35' • F • • - T + +

Height > 50' F -

• • T • + + •

Height > 60' - - F • + T

Height > 100' - - F - T

Height acceptable X X X X

Height not acceptable X X X X X X

51
Table 3.14 Second approach to checking maximum height

1 2 3 4 5 6

1 Clearance < 6' F T T T T T

2 Sign const. = closed • • T T F F

3 Bldg, type = 1 or 2 • F " T - T

4 Bldg, type = 3 F T - T -

1 Max. height = 0' X X

2 Max. height = 35' X

3 Max. height = 50' X

4 Max. height = 60' X

5 Max. height = 100' X

Height < max. height T F

Height acceptable X

Height not acceptable X

52
623.31 Dimensions: Stairs shall be at least twenty- two (22) inches

wide with risers not more and treads not less than eight (8) inches

and landings at foot of stairs not less than forty (40) inches wide by

thirty- six (36) inches long, located not more than eight (8) inches

below the access window or door.

Figure 3.4 Sample provision

Combined Conditions. It was stated previously that conditions may be

composed of compound logical statements, and that use of such conditions is

frequently advantageous in that the number of rules is reduced. Another

provision taken from a model building code [1] and shown in figure 3.4

illustrates this. It should be clear from the language of this provision

that only one compound logical statement is required in the condition stub.

The resulting decision table is shown in table 3.15.

3.3.2 Proper Usage

Many of the suggestions for proper use have been introduced in narrative

form in section 3.3.1 and will be summarized here.

Table size. It is best to restrict tables to manageable size, of the order

of 10 rules at most. Tables much larger than that tend to be difficult to

formulate and analyze

.

Completeness of stubs. The first step in analyzing a provision should be

the complete listing of all possible conditions and actions, as illustrated

in section 3.3.1. This discipline is most helpful in subsequent analysis;

it is also an early indication that the table may be too large, and that

the provision could fruitfully be subdivided into several smaller tables.

Table 3 . 15 Compound conditions

1 2

Stair width > 22" AND T F

Riser < 8" AND

Tread > 8" AND

Landing width > 40" AND

Landing length > 36" AND

Landing below access 0<x<8"

Dimensions acceptable X

Dimensions not acceptable X

53
Top-down development. As an alternative to the above recommendation, one may begin to analyze requirements in a top-down fashion by recognizing that

a requirement may have only two actions: requirement satisfied or requirement violated. Attention can then focus on the conditions. Again, if too

many conditions are involved, the requirement provision may be subdivided

into one table for the requirement itself, and one or more sub tables for

the key ingredients.

Incremental development. Once the conditions and actions are identified, a good strategy to follow is first to identify only those condition entries

that represent directly the statements in the original provision, leaving

all other entries as immaterial. Then, interaction among rules and tests

for uniqueness can be examined by generating a tree , and immaterial entries

modified to implicit entries as needed on succeeding iterations.

Compound conditions

.

As illustrated in section 3.3.1, individual conditions occurring together may be combined into compound conditions using

logical connectives of AND and OR.

Compound actions

.

The evaluation of both requirements and determinations

frequently involves selecting the minimum or the maximum of several expressions. As illustrated by table 3.8, such "subsidiary" tests can be handled

in the action stub by conditionals. However, as discussed in connection

with that table, such conditionals are "buried" in the stub, and are not

available for testing. Also, such "buried" provisions are not available for

classification purposes: in the example shown, one cannot attach separate

classifiers to the two expressions to indicate that one guards against

failure by yielding while the other pertains to rupture.

Boolean vectors. Examples such as table 3.10 illustrate the point made in

section 3.1.3 that many conditions involve testing a Boolean vector variable against one of its possible values.

Identification of ineredients

.

SASE at present does not analyze the con- tents of the condition and action stubs. Thus, it is the analyst's responsibility to ensure that all elements of the condition and action stubs

other than constants and operators are defined data items, representing the

ingredients of the datum generated by the decision table. Consistent with

the top-down development sketched above, the analyst may develop the table

first and then use it to ADD the INGREDIENTS of the DATUM represented by

the table.

3.3.3 Representation

Each decision table is represented in SASE by a TABLE entity.

A table is referenced by the REFERENCE number of its corresponding data

item (see section 3.1.3). To establish the cross-reference between the

datum and the table, when the ENTER TABLE command is given, the attributes

of the datum are automatically set as follows:

• SOURCE is set to DERIVED; and

54
• TYPE is set to TABLE

The attributes of a table entity are its CONDITIONS, ACTIONS and RULES, and

COMMENT

.

Since in SASE, actions can only produce alternative values for the data

item represented by the table, it follows that each rule can have only one action entry. Thus, SASE uses a condensed form for the input of action

entries. Table 3.16 repeats shows the action entry portion of table 3.5,

each action corresponding to a different assignment of F^,. The action entry

form used in SASE is shown in table 3.17.

SASE permits two modes for entering tables: by row (conditions followed by

actions) or by columns (rules)

.

In the row- entry mode, conditions are entered in the following order:

• a sequential condition number starting with 1;

• an optional condition stub entered as a text string;

• the separation symbol ;

• the condition entries, separated by blanks, each entry one of the

symbols

T or Y for yes or true (the symbols are equivalent)

F or N for no or false (the symbols are equivalent)

+ for implicit yes

for implicit no

. or I for immaterial (the symbols are equivalent)

The keyword CONDITIONS is given at the beginning of the first condition row

and either CONDITIONS or the repetition symbol is given at the

beginning of each succeeding row. A dollar sign "$" at the end of a line

signifies continuation.

SASE accepts the number of entries in the first condition row as the number

of rules in the table, and expects all succeeding rows to have the same number of entries.

To complete the row-entry mode, actions are entered in the following order:

• a sequential action number starting with 1;

• an optional action stub entered as a text string;

• the separation symbol ;

t • a list of the rule (column) number(s) which result in this action,

as shown in table 3.17, separated by commas.

55
Table 3.16 Standard form of rule entry

Rules

1 2 3 4 5 6

Action 1 X

2 X

3 X X

4 X

5 X

Table 3.17 Condensed form of action entry

Rules

1 2 3 4 5 6

Actions 1 2 3 3 4 5

56
The key word ACTIONS is given at the beginning of the first action row, and

either ACTIONS or the repetition symbol for each succeeding row. A

dollar sign "$" at the end of a line signifies continuation.

The keyword END completes the entry of the decision table.

In the column- entry mode, rules are entered in the following order:

• a ^sequential rule number starting with, 1;

• the condition entries, as above;

• the separation symbol ;

• an action number for the action corresponding to this rule.

The keyword RULES is given at the beginning of the first rule, and either

RULES or the repetition symbol for each succeeding column. A dollar

sign "$" at the end of a line signifies continuation.

Again, the keyword END completes the entry of the decision table.

Note that condition and action stubs cannot be ENTERed in the RULES form of

input; they must be ADDed subsequently.

SASE accepts the niomber of condition entries in the first rule as the

number of conditions, and expects all succeeding columns to have the same

ntimber of condition entries. Similarly, SASE accepts the highest action

number in any one rule column to be the number of actions.

Once a table has been ENTERed, stubs and condition and action entries may

be ADDed, MODIFYed and DELETEd. Furthermore, additional conditions, ac- tions, and rules may be ADDed sequentially to the existing ones. Finally,

an ELSE rule may be ADDed to the existing rule.

The conditions, actions, and rules may also be arbitrarily RESEQUENCEd.

In its present version, SASE treats condition and action stubs as text,

i.e., it performs no analysis of any kind. Subsequent versions of SASE may

include additional processing capabilities, i.e., identification of ingredient data items from the stubs or direct generation of executable computer

programs [17].

3 .

4

Decision trees

3.4.1 Definition

The logic contained in a decision table can be expressed as a decision

tree, which is a network with one condition at each node. The branches

from each node represent the possible condition entries and the termination

of each path, or limb, is a rule. Figure 3.5 gives an example of a decision tree generated from a hypothetical decision table.

57
Cl

C2

C3

R1 R2 R3 R4

C2

C3

T T T F

T T F

• T F

• •

(a) Decision tree showing the subtables produced for each condition tested.

(b) Decision tree alone.

Figure 3.5 Decision tree generation

from a hypothetical decision table.

58
The process of generating a decision tree from a decision table can be

summarized by the following steps [20]:

1. Begin with the original table (the condition entry is all that is

necessary)

.

2. Select a condition to test. Table 3.18 provides rules for

condition selection that result in an efficient decision tree.

3. i-Produce two subtables. Each will contain the remaining conditions

not yet tested. One will contain those rules for which the tested

condition is true, the other those rules for which it is false. A

rule with an immaterial entry will be in both new subtables.

4. If the new subtable contains at least one condition and more than

one rule, go to step 2 and repeat the cycle; else, go to step 5.

5. There are four possibilities at this stage:

• The subtable contains exactly one rule and no conditions except

those with immaterial entries. The rule has been isolated, so the path is ended.

• The subtable contains one rule and at least one condition with

a true or false entry. Return to step 2 and continue.

Table 3.18 Rules for selecting a condition for testing

1 One condition has fewest immaterial entries T - -

2 One of the conditions tied for fewest immaterial

entries has fewest implicit entries

T - -

3 Quick rule desired • T -

4 Delayed rule desired • - T

1 Select condition with fewest immaterial entries X

2 Select condition with fewest implicit entries X

3 Select condition tied for fewest immaterial andfewest implicit entries that has greatest

difference between number of true and false entries

X

4

Select condition tied for fewest immaterial and

fewest implicit entries that has least difference

between number of true and false entries

X

59
• The subtable contains no rules. The rule isolated was not included in the original table. The union of all such rules is

called the else rule.

• The subtable contains no remaining conditions, but does contain

two or more rules. The rules are not independent; that is,

they can be satisfied by the same set of condition entries.

The remaining rules are either redundant or contradictory.

The expression of logic in a decision tree strongly resembles a conven- tional flow chart.

Note that more than one network can be generated from any decision table,

depending on the order of selection of the conditions for testing, but that

a unique set of condition entries will always isolate the same rule.

Decision trees can be generated from extended entry tables also; however,

the number of branches leaving each node depends on the number of unique

entries for the condition. One of the advantages of a limited entry table

is that the decision tree will always have two branches coming out of each

condition node.

The decision tree derived from table 3.7 is shown in figure 3.6. There are three else rules identified; that is, rules that are not in the table.

Examination of the entries for condition four in table 3.7 shows that the

false entry is never used; this is pointed out in the decision tree by the

existence of only an else rule on the false branch from condition four.

The second footnote in the original provision pertains to that situation,

but no specific disposition is made (a limitation on w/t of 60 does exist

elsewhere in the specification.)

When implicit entries are encountered in the decomposition of a table into

a decision tree, the same steps described above are followed. The implicit

entries are treated somewhat differently than explicit or immaterial en- tries. First, it is efficient to avoid testing conditions with implicit

entries, similar to the efficiency gained in the avoidance of immaterial

entries. However, the avoiding of immaterial entries takes precedence over implicit entries. When new subtables are formed by separating the true

rules and false rules for the condition being tested, the implicit entries

are used like explicit entries to determine the subtable for a rule. For

example, a rule with a for the condition being tested is entered in the

subtable of true rules, but not in the subtable of false rules. When a subtable contains only one rule, the implicit entries are treated as immaterial entries. That is, they need not be tested to verify the rule.

The decision tree generated from table 3.9 is shown in figure 3.7. Compare

it to the decision tree shown in figure 3.6: it is much more compact since

fewer conditions need be tested. In addition, two of the else rules that

appear in figure 3.6 but represent impossible situations have disappeared

in figure 3.7.

60
C4 + + + Cl + + + C2 + + + C3 -^ + + R1

- - - - ELSE

- - - - ELSE

- -C3 + + + C6 + + + R6

- - - - C2 + + + R2

- - - - R3

. . . . C5 + + + R4

- - - - ELSE

- R5

Figure 3.6 Decision tree in SASE format generated

from Table 3.7 ( "+” denotes branch corresponding to

true value of condition tested, to false value).

Figure 3.7 Decision tree in SASE format generated from table 3.9.

61
Implicit entries make a tremendous difference in the number of else rules

encountered in the decision tree. Compare the two decision trees derived

from tables 3.4 and 3.10, shown in figures 3.8a and 3.8b. The former has

15 else rules while the later has three. The else rules in figure 3.8b

represent possible combinations of material strengths and electrode types

that are not included in the decision table because nothing was said about

them in the table in the original specification. The question arises from

this analysis as to whether the electrodes listed with the various material

strengths are the only ones permitted for use. This question can be

resolved only by consultation with the experts who wrote the specification.

3.4.2 Proper Use

Generate early and often. While decision tables are convenient and compact

representation of the logic of provisions, decision trees are the best tool

for checking tables for uniqueness, completeness and, to a lesser degree,

clarity. Therefore, a decision tree should be generated and analyzed as soon as a skeleton decision table is formed, and the tree re-generated and

examined whenever the table is significantly modified.

Corrections

.

If the analysis reveals two or more redundant rules, the

table should be carefully examined. Two redundant rules should differ by a true and false entry for one condition; if that is the case, the two can be

combined into a single rule with an immaterial entry; if not, then one or both rules must be in error. If two contradictory rules are found, the

action entry may be in error, or the logic may be at fault, probably be- cause one or more immaterial entries are improperly used.

Use of ELSE. Most decision tables representing provisions of standards are highly incomplete, in that the number of actual rules is considerably less

than the number of possible combinations of conditions. The ELSE qualifier

should be used to generate the rules not defined in the table. Each ELSE

rule should be carefully analyzed to determine whether it represents:

• a combination that is impossible because of related conditions;

• an omission from the original standard that must be rectified; or

• a combination that falls outside the scope of the standard.

3.4.3 Representation

In SASE, decision trees are generated by the GENERATE TREE command. A

decision tree is referenced by the reference number of the decision table

or, more precisely, of the datum derived by the decision tree.

The GENERATE TREE command has a number of optional qualifiers that control

the processing.

ORDER specifies the sequence in which condition rows are selected for

testing: INPUT specifies that conditions are to be tested in the original

62
cl + + + C2 + + + C3 + + + C4 + + + ELSE

- - - - - C5 + + + ELSE

- - - - - C6 H- + + ELSE

- - - . - else

- - ELSE - - - - R1

- - - -C3+++C2+++C4+++ ELSE

- - - - - C5 + + + ELSE

- - - C6 + + + ELSE

. „ - - ELSE - - - - R2

(a.) - - - - C2 + + + C4 + + + C5 + + + ELSE

- - . _ . _ (36 + + + ELSE

- - - - - R3

- - - - - ELSE

- - - - C4 + + + ELSE

- - - - C5 + + + C6 + + + ELSE

C2 + + + Cl + + + C3 + + + R1 - - - - R4

- - - - ELSE - - - - C6+++ R5

- . - . C3 + + + R2 - - - - ELSE

- - - - C4 + + + R3

- - - - C5 + + + R4

- - ELSE

- - - - C6 + + + R5

(b) ... - else

Figure 3.8 Comparision of decision trees in SASE format

generated from (a) table 3.4 and (b) table 3.10.

63
input sequence, while QUICK or DELAY specify the test sequences discussed

below.

The specific algorithm operates as follows:

• first priority: find the condition row with the minimum number of

immaterial entries or "I").

• second priority: find the condition row with the maximum number of

explicit entries ("T", "Y" , "N" , or "F").

• third priority:

for the QUICK rule algorithm, find the condition with maximum

difference between the number of true ("T" or "Y") and false

("F" or "N") entries.

for the DELAY rule algorithm, find the condition with minimum

difference between the number of true ("T" or "Y") and false

("F” or "N") entries.

The ELSE qualifier causes all ELSE rules to be generated and added to the

defined rules

.

The SORT qualifier rearranges the tree and the corresponding table so that

shorter branches of the tree are displayed before the longer branches.

The algorithm produces an error message if:

• any redundant rules are detected (i.e., rules are not unique and

their action entries are the same) ; or

• any contradictory rules are detected (i.e., rules are not unique

but their action entries are different)

.

When either of these errors occur, no tree is generated. The user must

MODIFY the original decision table and re-execute the GENERATE TREE com- mand,

3 . 5 Functions

3.5.1 Definition

Not all provisions depend upon conditions for their evaluation. A provision which does not require the evaluation of any conditions (i.e., leads

to a "degenerate" decision table with only one rule and one action) is

called a function.

Functions have been classified in [8] as

» definite functions;

64
• indefinite functions; and

• implied functions.

A definite function provides a specific, unambiguous means for deriving the

value of a dependent data item. The most common means are formulae or tables

.

An indefinite function specifies a set of ingredients for the evaluation of

a derived data item, but does not specify precisely how the ingredients are

to be used in the evaluation. An illustration is taken from section 4.2.2

of [18]

.

"4.2.2 Period Determination

The fundamental period of the building, T, (used) in formula 4-2

may be determined based on the properties of the seismic resisting system in the direction being analyzed and the use of established methods of mechanics assuming the base of the building to

be fixed ..."

In this instance the datum "Calculated fundamental period" is said to be an indefinite function of the following ingredients:

• Period calculated using established methods

• Properties of seismic resisting system in direction being analyzed

• Building assumed to be fixed at base

An implied function is used to denote instances in which the provision of a standard seems to indicate a precedence relation between data items, but

the analyst must make some assumption as to what that relation is. Sometimes the assumption is so strongly implied that the ingredience relation

can be treated just as was the indefinite function described previously.

However, the implication may be weak or nonexistent. Such instances are called assumed functions. Two examples illustrate the typical characteristics of such provisions.

The first is a sentence from section 7.2.1 of [18];

"The strength of foundation components shall not be less than

that required for forces acting without seismic forces."

It is assumed that the "forces acting without seismic forces" include all

other forces that are included in [18]. Thus the data item, "Required

strength without seismic load" is said to be an assumed function of the

ingredients

• Dead load effect

• Live load effect

65
• Snow load effect

The second example is from section 1.2 of [18]:

"These provisions establish requirements for strengthening of

existing buildings where alterations reducing the seismic force

resistance are made ..."

Among the data items identified in the provision is: "Seismic force resistance before proposed activity." It is assumed that this resistance should

be determined according to the provisions of the remaining chapters, however, no data items can be identified as specific ingredients.

3.5.2 Proper Use

Identification of ingredients. SASE at present does not perform any analysis of the body of functions. Therefore, it is entirely the analyst's

responsibility to identify the ingredients of the datum generated by the

function.

Clarification of function type. The analyst should ask the drafting com- mittee to clarify the type of function used, and attempt to have the com- mittee eliminate as many of the indefinite and implied functions as possible. In many instances, it is not appropriate to have a definite function

appear in the standard itself (e.g., the ingredient "period calculated with

the use of established methods of mechanics" in the first example in sec- tion 3.5.1); in such cases, the commentary to the standard may be an appropriate medium to describe or reference the applicable function.

Expansion to decision table. Many determinations that appear to be functions on first reading may turn out to be decision tables when footnotes,

exceptions, etc. are also included. In such cases, the FUNCTION must be

DELETEd and a new TABLE ENTERed.

3.5.3 Representation

Each function is represented in SASE by a function entity or record.

A function is referenced by the REFERENCE number of its corresponding data

item (see section 3.1.3). As with decision tables, when the ENTER FUNCTION

REFERENCE in command is given, the attributes of the datum are set as follows

:

• SOURCE is set to DERIVED

• TYPE is set to FUNCTION

The only attribute of a FUNCTION entity is its BODY, entered as a text

string.

66
3 . 6 Networks

3.6.1 Definition

General

.

A network can be defined as a set of points connected by lines.

The points are called nodes and the lines are called branches. A branch

may only be connected to two nodes, one at each end, and branches may only

be connected at nodes, although they may cross over one another at points

without impairing the generality of the definition [3].

The information network used to represent the precedence relations of the

information contained in a standard is formed by assigning one data item to

each node. These nodes may be: numerical quantities such as material

strength; qualitative values such as the type of occupancy of a building;

or Boolean values such as the status of a requirement (satisfied or unsatisfied) . In order to provide a more concise representation of the relations among data items, each detailed decision table or function is abstracted into a subnetwork, or subtree, consisting of:

1. a node representing the derived item generated by the table or function;

2. nodes representing all the data items occurring in the table or function, i.e., the ingredients; and

3. directed branches from each ingredient to the node representing

the derived data item.

The nodes in set (2) are called the (direct) ingredients of node (1)

;

con- versely, node (1) is called a (direct) dependent of all nodes in set (2).

Each decision table establishes the value for one data item, so each decision table is uniquely associated with a node in the network. Some nodes

represent items that have their value established by a function; in such

cases the function is associated with the node as if it were a decision

table

.

There will be data items that have no procedure for evaluation contained

within the standard. The nodes for these items are called input nodes

because their value must be supplied by sources of information outside the

standard.

Construction of the Network. The global network can be assembled by interconnecting the subtrees representing the individual provisions. Provisions

leading to an illustrative network are shown in figure 3.9, which is a simplification of the provisions for the design of simply reinforced beams

taken from [2].

The network is shown in figure 3.10.

In this network, we can trace out the global dependence of a node, that is,

all data items affected by the datum. By following the branches in the

67
p =

Pb =

M =

Decision table for tension

reinforcement requirement

1 E

p < 0.75 Pb Y .

p > 200/fy Y

M < Y

TROK = satisfied X

TROK => violated X

Decision table for factor

1 2

V 4000 Y N

k]_ - 0.85 X

ki =• 0.85 - 0.00005(fc - 4000) X

Supporting functions

= 0.90

f'c 87000

0.85 ki

fy 87000 + fy

bd2 f'^ q(l - 0.59q)

Figure 3.9 Simplified provisions for the

design of simply reinforced concrete beams.

68
Figure 3.10 Information network for simplified provisions

for the design of simply reinforced concrete beams.

69
reverse direction, we can trace out the global ingredience of a node, that

is, all data items needed to evaluate the datum. We can also classify the

nodes into:

• input data items, that is, nodes without ingredients;

• derived data items, that is, nodes with one or more ingredients;

and

• output data items , that is , nodes with no dependents

The input nodes will have no ingredients. All of the nodes that have

ingredients are called derived nodes . The information network does not

show how they are derived; it shows only the data items that may be neces- sary in order to derive the value. Some of the nodes (at least one) will

have no dependents; they are called terminal or output nodes of the network, The output nodes represent the requirements included within the

standard. The concept of using the requirement as the output node is

rather arbitrary, since one final node could be defined as "standard satisfied". However, this would be an ambiguous, cumulative requirement. It is

advantageous to truncate the network at some convenient definition of

requirements in order to provide freedom in the use of the organizational

network, as is discussed in chapter 4.

Characteristics of the Network. One of the characteristics of the information network that can be used to advantage in the formulation and expression of standards is its concise representation of all the information

contained in the standard. The simple process of defining a consistent set

of items of information can lead to the identification of extraneous items.

When an existing standard is being analyzed or restructured, a preliminary

list of the items of information would be one of the first steps in the

analysis. Ingredients do not become apparent until the examination of the

detailed logic involving each data item is begun. The study of the detailed logic is described in section 3.3 on decision table analysis.

Once the network is constructed from the list of nodes and their ingredients, it is possible to discern global ingredience and dependence properties of the hierarchy of information. The global ingredience of a particular node is the portion of the overall network located on branches pointing

towards the node: it is a subnetwork that begins at the node in question,

then goes to each of its ingredients , which are followed in turn by each of

their ingredients in a recursive manner until all of the branches end at

input nodes. The direction of traversing this network is counter to the

direction of the branches. The global dependence is constructed in a similar manner, except dependents are used: the final nodes are the output

nodes, and the direction of traversing is in the direction of the branches

as defined originally. In summary, the global ingredience shows all of the

nodes that may have a direct or indirect effect on the node in question.

The global dependence shows all of the nodes that may be affected by the

node in question.

70
Computations on the Information Network. A number of useful computations

can be performed on a network. The network can be viewed as a criticalpath-method (CPM) diagram with all branches having a length of one unit.

Labelling the terminal (output) node 0, the labels of all nodes are determined as

:

L°]^ = max (L°j -i- 1)

where j ranges over the set of direct dependents of node k. The cor- responding labels are shown on figure 3.11, and represent the highest or latest level from output of each node.

Alternatively, the input nodes are labelled 0, and the labels of all nodes

determined as:

= max (L^j +1)

where j ranges over the set of direct ingredients of node k. The cor- responding labels are shown on figure 3.12 and represent the highest level

from input of each node.

Finally, to complete the CPM analogy, the float of every node is calculated

as

:

^k “ ^aax (^^k ^°k^

where

Ljjjax maximum label in network

= longest path from input to output

The various quantities for the sample network are tabulated in table 3.19

below.

The input level, output level, and float are three properties of the nodes

in a network that are of considerable use in the expression of a standard,

as discussed below.

Connectedness

.

Information networks frequently will have more than one node at the output level. It is entirely possible that the information

network for a standard will consist of more than one completely separate

network, although this possibility seems improbable. Such cases do not

alter the generality of what has been described. The definition of what

constitutes an output mode is somewhat arbitrary, as discussed previously.

Acyclic Networks. Information networks will generally have many closed

loops or cycles, although none of them may be traversed completely without

going counter to the direction of at least one branch. Such a network is

called acyclic. If it were possible to traverse a complete loop in the

direction of the branches, it would mean that a node might require assign71
Figure 3.11 Information network ordered

by levels from output data item.

72
S5i

Figure 3.12 Information network ordered

by levels from input data items.

73
Table 3.19 Levels and floats in example network

Node Level from Output Level from Input Float

TROK 0 4 0

M 1 0 3 Mu 1 3 0

Pb 1 2 1

q 2 2 0

0 2 0 2 ^1 2 1 1

p 3 1 0

fy 3 0 1

^ C

3 0 1

b 4 0 0

d 4 0 0

^s 4 0 0

ment of its value before it could be evaluated. While iterative calculation

is used' in many analyses, it is not appropriate in standards. When such a situation is encountered, it will be necessary to define two nodes as the

initial and final values of a datum to break the loop.

Use in Formulation. Most of the uses of the information network in aiding

the formulation of a standard are qualitative. One exception is the check

that the network be acyclic, which can be detected explicitly in the con- struction of the network. Other explicit checks are that the network must

have at least one output node and one input node. Disconnected portions of

the network should be examined critically. When the disconnected portion

consists of one node, an error in formulation is revealed. The node either

has some ingredients that were left out, is an overlooked ingredient of some other node, or is not used at all.

The information network also allows the explicit determination of the

global ingredience and global dependence of a node as described above.

When a change in the definition (decision table) of a node is contemplated,

the dependent network allows the effects of that change to be traced

through the specification. Likewise the ingredience network allows any

subset of the specification to be checked for consistency.

One qualitative check is that provisions dealing with parallel situations

should be located at approximately the same level from output. The comparison of output levels is based on the concept that provisions described by

a nearly identical set of arguments (i.e., classifiers) should have nearly

identical global dependence networks.

Another qualitative check is on the similarity of ingredients for various

nodes. Particularly when reformulation of an existing standard is being

pursued, it may be possible to combine several similar provisions taken

74
from different portions of the standard into one new provision, thus clarifying the intent of the provision.

Use in Expression. The information network is of use in composing the

textual expression of a standard by providing a guide to the ordering of

data items required for the definition of a set of related provisions and

in the recognition of cross references. The overall organization of the

text (ordering of sets of provisions) is somewhat independent of the information network and is discussed in the chapter, on outlining.

Two schemes may be defined for the ordering of the data items used in the

written expression of a set of provisions represented by an information

network: conditional and direct [12, 13].

In the conditional or top-down strategy, we list the top node first, followed by its direct ingredients, that is, those at level 1 from output.

Each of these, in turn, is listed with its direct ingredients, etc. The

skeletal structure of the text for the sample network shown in figure 3.10

may read as follows:

Tension reinforcement shall satisfy the following . . .

is evaluated as follows . . .

q is evaluated as follows . . .

p is evaluated as follows . . .

p|j is evaluated as follows . . .

k]_ is evaluated as follows ...

(the input data items are not shown).

Comparison of the skeletal structure with figure 3.10 will show that the

structure represents a particular path through the graph information network. The order in which the paths are traversed is immaterial, and will

depend on the analyst's preference. What is important is that:

• every complete outline represents a spanning tree (that is, it

contains every node) of the network, rooted at the terminal node;

and

• branches of the network not included in the outline may be represented as cross-references to other nodes.

In the direct or bottom-up strategy, we list the input nodes first, followed by their direct dependents, that is, those at level 1 from input.

Each of these, in turn, is listed with its direct dependents, etc. The

skeletal structure may read as follows:

Given b, d, and Ag ' compute p as follows . . .

75
Given p, fy and fj,' compute q . . .

Compute k]_ . . .

Compute . . .

Compute p-j^ . . .

Evaluate whether tension reinforcement requirement is satisfied.

Again, the writer has the option of ordering the nodes in one level, but

the two properties discussed for the conditional strategy still hold: the

outline is a spanning tree, and all cross-references point to nodes previous defined.

Direct ordering will lead to a boring style of writing when the global

ingredience of a provision is several levels deep, because the reader is

forced to read the definition of all the possible ingredients before the

provision is located. Conditional ordering allows the user familiar with

the standard to cease reading the text of a set of provisions when he has

read the first statement, if he is already aware of the definition of items

close to input, or if he is only scanning the major requirements.

The global ingredience network alone is not sufficient for organization of

the textual expression needed to define a set of provisions. One difficulty is that it does not indicate which of the several nodes at a given

precedence level should be used first. The problem cannot be completely

separated from the logic expressed in the decision tables. The float and

output level may be of some aid. They are simple numerical indicators of

the depth of precedence, or numbers of intermediate steps between the input

and output node and the node in question. Ingredients that have the

largest float or level will generally have the smallest global ingredience

networks and thus will be easier to define. In some cases, it will be most

convenient to order the ingredients that are defined in the simplest manner

first; however, no consistent rule concerning this has been developed.

Another benefit that the information network offers for formulation and

expression of standards is the explicit recognition of cross-references.

Frequently, input parameters and derived data are used in the evaluation of

more than one provision. Proper cross-referencing depends on the recognition of these reuses of the same data items. This becomes more important

in larger standards because cross-referenced nodes will sometimes have a large global ingredience of their own. Cross-referencing is necessary to

prevent presentation of duplicative material and possible confusion.

3.6.2 Proper Use

Proceed from small to bie. It is best to generate and analyze smaller

networks corresponding to individual chapters before combining the data

items into larger networks for several chapters.

76
Corrections for loons. If the analysis reveals the presence of loops,

these must be eliminated. Loops may result from:

• "circular" definitions, where a data item is in its own global

ingredience network. Such data items must be redefined and the

ingredients modified accordingly;

• iterative calculations, involving a trial and error procedure.

Such procedures are not appropriate for a standard; if absolutely

^needed, two data items must be defined, e.g., one for the assumed

and one for the computed value of the datum in question, where the

assumed value is treated as an input data item;

• overly strict interpretation of some cumulative requirements (see

section 3.3) or indefinite functions (see section 3.5). Once identified, these items must be reinterpreteted.

Detached subnetworks

.

Detached subnetworks should be examined with care.

It will frequently happen that subnetworks corresponding to individual

chapters will have several detached subnetworks, to be "connected" later

through cross-references between chapters. This is a valid occurrence of

detached subnetworks. By contrast, an undesirable situation is one where

the detached subnetwork is within the scope of the chapter, but there is no "logical" way to interconnect it with the remainder of the chapter through

compound requirements

.

Choice of SORT. The SORT qualifier determines the ordering of nodes in a subsequent DISPLAY of the network (see the next section) . No firm rules can

be given on the choice of the SORT qualifier. Generally SMALL SMALL should

be tried first: it will put shorter paths ahead of longer ones.

3.6.3 Representation

In SASE, a network is generated by the GENERATE NETWORK command. In the

present implementation of SASE, there can be only one network for each

VERSION of a standard. Therefore, the network is not given an explicit

reference number. The user must specify the CHAPTERS of the version to be

included in the network.

In SASE the network can be DISPLAYed as a spanning tree, that is, a tree

containing all of the nodes in the network. Each branch of the tree corresponds to a path through the network. The SORT qualifier controls the order

in which nodes appear in the tree. If the SORT qualifier is used, either

FLOAT or LEVEL may be specified as the primary key; the other will be taken

as the secondary key. The first SMALL or LARGE qualifier indicates sorting

on the primary key in descending or ascending order, respectively. The

second SMALL or LARGE qualifier indicates the sorting order for the secondary key.

SASE produces an error message if a loop is detected, and prints out the

list of nodes (data item reference numbers) constituting the loop. The user must modify the INGREDIENTS of one or more data items to break the

77
loop before the network can be generated. SASE does not generate any error

messages if disconnected subnetworks are encountered.

The DISPLAY NETWORK command provides two basic options for displaying the

network:

• If INGREDIENCE or DEPENDENCE is specified, a spanning tree is displayed, indented by levels; either the ENTIRE network or a subnetwork rooted at a specified node may be requested.

• If DATALIST is specified, a tabular display of data items is produced, including the LEVEL and FLOAT attributes of each data item.

78
4. ORGANIZING THE INFORMATION OF A STANDARD

The organization of a standard deals with both the scope (the range of

subject matter) and the arrangement (the grouping and ordering) of the

provisions it contains. An effective organizational system assists the

writers of a standard in defining its scope and assists the user of a standard in quickly and reliably finding the relevant provisions. This

chapter presents the SASE techniques for dealing with the organization of a standard. Major sections are: Classifiers, Hierarchy, Scopelist, Index,

Organization, and Outline.

4 . 1 Classifiers

4.1.1 Definition

Classifiers are words that concisely define the scope of a provision. All

provisions that are requirements should be classified for the purpose of

generating organizations and outlines; frequently, key provisions that are determinations also are classified, at least for indexing purposes.

As discussed in section 3.2, a requirement contains at least two basic

components. The subject of the requirement may be a physical entity, process or participant, collectively these are referred to as THING in the

following. The predicate of the requirement defines the REQUIRED QUALITY

of the subject. Classifiers serve to identify, relate, and organize the

subjects and the predicates.

Faceted Classification System. The SASE methodology for classification of

provisions of standards is based on the faceted classification system

developed for library science. The essence of a faceted classification can

be reduced to three features;

1. The classification consists of several more or less independent

areas, called fields and facets. A field can be thought of as a subject area (such as architecture) and a facet can be thought of

as a way to classify within a particular field (a classification

of architectural objects might have facets for material, historical period, form, etc.).

2. Each facet is structured hierarchically and may have several

levels

.

3. Rules are provided for combining terms from different facets for

the classification of an entire standard.

Within a facet, the classifiers should be logically structured, that is,

the classifiers should be:

1. mutually exclusive at every level of the hierarchy to guarantee

that each provision is uniquely described by one set of classifiers only,

79
2. collectively exhaustive at every level to ensure complete coverage , and

3. strict subdivisions of the parent classifier in the hierarchy.

Development of a Classification System. There are five important principles that govern the development of a faceted classification system for the

provisions of a standard:

1. There must be at least two independent fields: one for THING and

one for REQUIRED QUALITY of the provisions (see section 3.2).

Relevant classification of requirements requires this as a minimum. There also may be independent fields for determinations.

The fact that the fields are independent facilitates the construction of a classification and allows great freedom in constructing

alternative arrangements

2. Each facet must be a strictly logical tree. That is, each suc- ceeding level must be a direct subdivision of the parent and the

logical principles of mutual exclusion and collective exhaustion

must be satisfied at each level. This logical rigor is not typical of faceted classification systems, but it is required of the

classification system of a standard in order to satisfy two of the

objectives of organization: uniqueness and completeness (see

section 4.6).

3. A field may have any number of facets, and each facet, except the

root facet, must be a logical subdivision of some other classifier

in the field. In order to provide an outline that is unique,

complete, and graded (see section 4.6), it must be possible to

combine the facets in at least one way to produce a single logical

tree for the entire field. Thus the potential connections between

facets must be stated explicitly. A corollary of this principle

along with the first principle suggests that the same facet not be

used in more than one field.

4. The maximum number of siblings (classifiers having the same parent

classifier) at any level should not exceed a reasonable estimate

of the span of immediate memory of the user, of the order of five

to ten.

5. The facets should promote an even division of the scope of the

standard.

The third principle merits additional discussion. One use of the classification system is to build an outline, which should follow the logical

principles as much as possible. Thus, it is desirable to avoid the possibility of a tree containing siblings that are not mutually exclusive and it

is necessary to avoid any closed meshes. Non-exclusive siblings is the more substantive concern because closed meshes rarely arise in practice.

The first concern is satisfied by allowing only one facet to be appended to

any one classifier.

80
Consider the example taken from [18] shown in figure 4.1.

Two of the three facets in figure 4.1a apply to the classifier "Building

Part," which is a terminal classifier of another facet (not shown). The

third facet applies only to the combination of the classifiers "Seismic

resisting" and "Component." As is frequently the situation, it is necessary to be able to subdivide a single classifier (Building Part) into more

than one facet. To accomplish this logically the subdivisions are applied

successively rather than concurrently. Thus, the second facet is applied

to thei^terminal classifiers of the first facet, as shown in the left column

of figure 4.1b. The right column of figure 4.1b shows a variation that

maintains logical rigor but it does so by dividing the facet "Function of

Building Part" into subfacets. This subdivision of facets is quite useful

in constructing outlines, and will be discussed further.

Function of building part Scale of building part

Structural System

Seismic resisting Component

Non-seismic resisting

Foundation

Material

Nonstructural Type of seismic resisting component

Frame

Shear panel

a) Three logical facets, shown in indented outline format

(Function of building part) (Function of building part)

Structural Struc tural

Seismic resisting System

System Seismic resisting

Component Non-seismic resisting

Frame Foundation

Shear panel Component

Material Seismic resisting

Non-seismic resisting Frame

System Shear panel

Component Non-seismic resisting

Material Foundation

Foundation Material

Nonstructural Nonstructural

b) Two possible ways of combining the three facets into a tree

Figure 4.1 Sample combinations of facets of subject classifiers

81
The example shows several other interesting features. Note that the name

of the facet disappears when it is appended to another classifier. In this

sense, the name of a facet is transparent. Also note that facets need not

be appended at all possible locations -- "Scale of building part" is not appended to "Foundation" in the left column of figure 4.1b, and the second

level subfacet of "Function of building part" is not appended to "Material"

in the right column of figure 4.1b. In addition, a single facet may require

the context of presence (or absence) of several other classifiers to be

relevant- - "Type of seismic resisting component" is attached to only those

branches in figure 4.1b containing the classifiers "seismic resisting" and

"components." Techniques for combining facets are discussed in more detail

in the description of outlining methods in section 4.6.

The division of the facet "Function of building part" shown in figure 4.1b

illustrates that the fundamental unit of the classification is a single set

of sibling classifiers connected to their parent classifier. This unit is

the smallest unit that preserves the logical principles; hereafter it is

termed a nuclear tree . For purposes of combining classifiers into an outline, a facet may be divided into its constituent nuclear trees. Thus

the logical structure of a classification system may be summarized as follows

1. A nuclear tree is the smallest logical unit.

2. A facet consists of one or more nuclear trees and is the largest

logical unit. It may be subdivided into smaller logical units at

any time.

3. A field consists of one or more facets and does not necessarily

maintain logical rigor. Each field is considered to be an independent classification.

It is important that any deviation from the above logical principles be

soundly based, and that the classification still give an unambiguous indication of the applicability of a particular requirement to a particular

classifier. The logical principles can be relaxed when classifying for the

purpose of indexing, but it is more convenient to treat this subject in the

principles for classing provisions.

In addition to following the principles just presented, care must be taken

to provide relevant and progressive ordering of the classification.

Classing Provisions. There are five principles pertinent to the association of classifiers and provisions, that is, to the assignment of arguments

to data items. These principles are:

1. Each requirement must be classed according to THING and to

REQUIRED QUALITY.

2. No provision may be classed by more than one classifier from any

one facet.

82
3. Each classifier associated with a provision must be the most detailed that includes the scope of the provision.

4. All terminal classifiers must be associated with at least one provision.

5. It is permissible to establish a priority among the classifiers

associated with a provision.

The first principle assures relevance based on the model of the underlying

structure of requirements. No comparable model or principle exists for

determinations

.

The second and third principles are simply corollaries of the logical

principles. It frequently is useful to violate both of them when classing

for the purposes of indexing. Consider a provision that applies to both

the "Seismic resisting" and "Foundation" parts of the "Structure", but not

to the "Non-seismic resisting" parts (refer to the first facet in figure

4.1a). Outlining has the function of finding a single best location in a linear list for a provision. Thus, according to the logical principles,

the provision must be classed as "Structure". Indexing has the function of

directing a user to a provision from any relevant starting point, thus the

provision is most appropriately classed "Seismic resisting" and "Foundation." It is fairly simple to account for different ways of classing the same provision and to call on the appropriate classification for a given

purpose

.

The fourth principle prevents useless detail in the classification system.

The fifth principle is useful in outlining. In the light of the basic

structure of classification, it appears that such a priority will be of the

most use when applied to classifiers from different facets in the same

field. Thus a provision classed as "Structure", "System", and "Seismic

resisting" from the facets in figure 4.1a (with the first facet subdivided

as previously described) might be more appropriately placed in one or the

other outlines of figure 4.1b based on the priority given to "System" and

"Seismic resisting."

Basic Categories. The establishment of a set of basic categories gives a firm starting point for the development of a classification for a particular standard. In this section, categories appropriate for use in design

standards for buildings are proposed, with some discussion of their importance, application, and interrelationships. It is expected that the same

or similar categories would be appropriate for standards that pertain to

other subjects or that are broader in scope than building design. The

objective in presenting these categories is to provide an aid for the

development of a relevant and meaningful classification. They should be

reviewed for any specific application. The indiscriminate application of

these or any other basic categories is unwise.

83
The structure defined in section 3.2.1 for a requirement provides the basis

for deriving basic categories. There must be at least two major independent fields, one for the THING (subject) and one for the REQUIRED QUALITY

(predicate). Both of these are too general for the present purpose; their

major constituents, which may be fields or facets, are the real interest.

Figure 4.2 summarizes the basic categories proposed for classifying re- quirements. The lower portion of the figure consists of categories that are useful in particular situations; thus they are. termed facets.

The figure is not a logical classification itself, and there may well be

other usable facets not included. A brief discussion of each category with

selected examples follows.

Categories of THINGS. Three principal categories of THINGS are shown in

figure 4.2. They are: Physical Entities, Human Entities, and Processes.

(By definition. Human Entities are distinct from all other Physical Entities.) Some potential for ambiguity exists between Human Entity and Pro- cess for some provisions and between Physical Entity and Process for other

provisions. These ambiguities are usually resolvable by considering the

most relevant REQUIRED QUALITY.

A most important factor in the classification of THINGS is the whole -to

part relationship, shown as a "multi-purpose" facet in figure 4.2. A

common characteristic of Physical Entity classification is the large number

of levels that are typically related in the fashion of "system-subsystemcomponent-constituent . " Similarly, Processes can be divided into stages.

Great detail in the whole- to-part naming of Physical Entities is common in

prescriptive standards; it is somewhat antithetical to the concept of a performance standard. Where innovation is desired, too much whole- to-part

naming can restrict freedom. Where easy judgment of compliance is desired,

a classification strongly tied to the most common implementations is desirable. As the facets of figure 4.2 are reviewed, the whole- to-part relationship should be kept in mind.

There is considerable richness in the way the Physical Entities are named

and classified. Following are examples to help define the facets in figure

4.2.

« Function: the division of stairs into required exits and supplemental exits; the division of a structural system into seismic re- sisting and non-seismic resisting subsystems.

• Material: the division of structural components into wood, steel,

reinforced concrete, masonry, etc.

• Dimensions: the division of buildings into one-story and multistory.

• Exposure (Circumstances) : the division of components into those in

contact with corrosive fluids, those in contact with soil, etc.

84
Figure 4.2 Basic categories for requirements.

85
• Configuration: the division of stairs into straight, spiral, etc.

• Behavior: the division of materials into brittle and ductile.

• Procedure: the division of concrete components into those cast- inplace and those precast.

• Resource: the division of energy sources into coal, oil, nuclear,

solar, etc.

• Time: the division of buildings into existing and proposed.

• Place: the division of components by location on the top story,

below grade, etc.

Examples of the facets for Human Entity are:

• Activity: the division into users of buildings and agents of the

building process; the division of users into occupants, maintenance

crews, neighbors, etc.

• Discipline: the division of designers into architects, structural

engineers, mechanical engineers, etc.

« Time: the division of licensed designers by the date of registration.

• Place: the division of licensed professional designers by state of

registration.

Similar examples for facets of Process are:

• Agent: the division into natural processes, such as corrosion, and

human operations, such as welding.

® Physical Entity: the division of pile driving by types of piles,

for example: open steel section, closed steel section, timber, and

precast concrete piles.

• Human Entity: the division of quality assurance activities into

those carried out by the designer, the regulator, the contractor,

etc

.

• Time: the division of structural design into conceptual design,

analysis, proportioning, detailing, etc.

• Place: the division of welding into shop welding and field welding, or downhand and overhead welding, etc.

Some useful facets may be a combination of some of the above. For example,

in standards for the structural design of buildings a class of "stress

states" (axial stress, flexural stress, shear stress, etc.) is very useful

86
for grouping components. The class can be thought of as Function, Circumstance, or Behavior, or some combination of them.

Categories of REQUIRED QUALITIES. The classification of REQUIRED QUALITIES

does not show the richness of the classification of THINGS, but this is not

an indication of simplicity. The first problem with the categories shown

for REQUIRED QUALITY in figure 4.2 is that the principal category. Performance Attribute, is not explicitly stated in some standards, particularly

in prescriptive ones. Another factor that 'contributes to the relative

difficulty of developing a classification of REQUIRED QUALITIES is that the

whole- to-part relation is rarely applicable, making the logical structure

entirely dependent on the characteristics of the REQUIRED QUALITIES.

In spite of the problems, the classification of REQUIRED QUALITIES is

worthwhile for two reasons. It is necessary to allow full and relevant

classification of requirements, without which the access function of the

organizational system would be severely hampered. It also allows a com- pletely independent arrangement of a standard that concentrates on the

objective rather than the subject, which is quite desirable for some individuals and some uses. Thus the categories of figure 4.2 are presented

with the knowledge that difficulties may be encountered in the classification of REQUIRED QUALITIES.

A useful subdivision of the performance hierarchy is through the use of

Limit States as classifiers of performance criteria. In the context of

structural engineering, a Limit State has been defined as an event that may

cause the loss of a performance attribute either by its occurrence or by

its amplitude. Examples of limit states and their related performance

attributes are "collapse of a building" (safety) , "vibration of a floor"

(comfort) , and "cracking of a water tank" (function)

.

Measure is shown in figure 4.2 as a reminder that not all requirements can

be classified through the performance hierarchy, and that even for those

that can there exists a more basic facet for the REQUIRED QUALITY. In this

sense. Measure is all-encompassing from the most fundamental qualities,

such as existence, through the more remote or accidental qualities like

"Circumstances .

4.1.2 Proper Usage

Many of the suggestions for proper usage have been introduced in narrative

form in section 4.1.1, and will be summarized here essentially in the order

in which a classification system is developed.

Basic Categories. The first and most critical step in developing a classification system is to define the basic categories or fields describing the

scope of a standard. Figure 4.2 may be used as a guide, but modifications

or extensions of that model may be in order for a specific standard.

Things and Required Qualities. In the analysis of an existing standard, it

is usually easier first to construct the classification system for the

THINGS covered, and then concentrate on their REQUIRED QUALITIES. By

87
contrast, in synthesizing a new standard, it is advisable first to identify

the REQUIRED QUALITIES sought, and only then enumerate the THINGS which are

to possess those qualities.

Fields and Facets. The distinction between fields covering large heterogeneous areas of subject matter and facets covering specific, homogeneous

sub -areas is often problematical. An evolutionary approach is to start

with many facets in a field and then examine them to see whether they could

be logically combined into fewer, larger facets.

Logical Structure of Facets. Care must be exercised that the classifiers

within a facet satisfy the three rules of logical structure given in sec- tion 4.1.1.

Classing Provisions. The true test of the classification system lies in

the actual classing of provisions, i.e., the assignment of ARGUMENTS to

DATUMs . The ease with which the five principles given in section 4,1.1 can be followed quickly will determine the usefulness and appropriateness of

the classification system.

Interaction with data items. Of the five principles given in section

4.1.1, the most troublesome in practice is the second, namely, that no provision may be classed by more than one classifier from any facet.

Potential violation of this principle may mean that the classification is

too detailed, e.g., the classification distinguishes between "walls" and

"diaphragms" whereas the provisions deal with walls and diaphragms. However, violation may also occur because the provisions themselves are too

inclusive, i.e., they are multiple or cumulative requirements, as defined

in section 3.2.1. In such cases, proper classification requires that the

data items be redefined (see section 3.2.2).

4.1.3 Representation

Each classifier is represented in the SASE program by a classifier entity.

The attributes describing a classifier are discussed below.

REFERENCE NUMBER The reference number is a numeric key for identifying the

classifier. The reference number must be unique within a version. A

convenient identification scheme is to use a five-digit reference number,

the first two digits referring to the facet and the last three digits

sequentially assigned within the facet in increments of ten, thereby providing space for new classifiers to be inserted later.

NAME Any short, mnemonically meaningful alphabetic designation may be

given to the classifier.

TITLE Any descriptive title, entered as a text string, may be given to the

classifier; its most common use is in the preparation of organizations,

outlines, and indexes.

88
TYPE This attribute defines the way the classifier is to be used in organizations and outlines. Its possible values are:

• ACTUAL, meaning that the classifier will be displayed, or

• TRANSPARENT, meaning that the classifier will not be displayed in

the outline.

PARENT A classifier may have a single parent or multiple foster parents.

If a parent is entered, identified by its classifier reference number, the

classifier belongs to the same facet as its parent, and is a direct subdivision of the parent classifier.

FOSTER The reference numbers of foster parents are entered only for classifiers that are roots of facets. These classifiers will be introduced in

the organization as if the referenced foster parent (s) were true parent (s)

.

The introduction of a classifier having more than one FOSTER parent may be

made conditional on a specified CONTEXT with respect to classifiers PRESENT

or ABSENT in the hierarchy above the classifier.

COMMENT Any descriptive information or comment, entered as a text string,

may be attached to the classifier.

4 . 2 Hierarchy

4.2.1 Definition

A hierarchy is a tree of classifiers. The tree of a facet is formed by

assigning one classifier to each node and forming a branch from each node

to its parent. The tree of a field is formed as follows:

• the tree of the root facet of the field is formed;

• the trees of the remaining facets of the field are attached by

branchs to the foster parents of the root nodes of the facets;

• if a facet has more than one foster parent, copies of the tree of

the facet are attached by branchs to each of its foster parents

satisfying the specified context.

The assembly of the hierarchy tree is readily done by SASE. The resulting

tree can be examined for the desired properties of the classification

scheme. As an illustration of the use of hierarchies to examine a classification scheme, figure 4.3 presents the Physical Entity field for a classification [9] for seismic provisions for buildings. The field has 21 facets.

A recent reorganization [10] of the same classification produced the Physical Entity field shown in figure 4.4. The field now has eight facets, themselves arranged roughly in a system- component hierarchical order.

89
*Building

Whole Building

Part of Building

^Seismic Performance

Category A

Category B

Category C

Category D

^Seismic Hazard Exposure

Group III

Groups I and II (Not Used)

^Existence of Building

Proposed (New)

Existing

^Material Nature of Bldg Part

Material Generic

Material Specific

*Scale of Building Part

System

Component

Material

^Function of Building Part

Structural

Seismic Resisting

Non-Seismic Resisting

Foundation

Non- Structural

Architectural

Mechanical/Electrical

^Structural Components

Connection

Member (Not Used)

(continued)

Figure 4.3 Physical Entity field from a classification [11]

for seismic provisions for buildings showing 21 facets

(* denotes the root of a facet)

.

90
^Materials of Construction

Wood

Steel

Reinforced Concrete

Masonry

*Type of Seismic Resisting Component

Frame

Moment Frame (Unbraced)

Ordinary Moment Frame

Special Moment Frame

Braced Frame

Shear Panel

Shear Wall

Diaphragm

*Frame Components

Beam

Column

Joint

*Part of Shear Panel

Boundary Member

Web (not used)

*Part of Foundation

Soil

Foundation Structure

Pile

Non-Pile (not used)

•*Non- Structural Components

Equipment

Anchorage

*Wood Design Method

Conventional

Engineered

(continued)

Figure 4.3 Physical Entity field from a classification

for seismic provisions for buildings (continued)

.

91
*Part of Wood Shear Panel

Framing (Wood)

Sheathing

Plywood

Diagonal Board

Other Sheathing Material

^Reinforced Concrete constituents

Concrete

Reinforcement (Concrete)

Lateral Reinforcement

Longitudinal Reinforcement

^Concrete Pile Construction

Cast- in-Place

Cased

Uncased

Precast

Prestressed

Non-prestressed (Not Used)

•’'^Masonry Constituents

Masonry Unit, Mortor, Grout

Reinforcement (Masonry)

*Masonry Construction

Unreinforced

Stacked Bond

Hollow Unit Masonry

*Type of Member Stress

Axial Stress

Flexural Stress

Shear Stress

Torsion Stress

figure 4.3 Physical Entity field from a classification

for seismic provisions for buildings (concluded)

.

92
^Building Type

Proposed (New)

Existing

^Building Function

Seismic Performance Category

Category A

Category B

Categories C and D

Category C

Category D

Seismic Hazard Group

Group 1 Group 2 Group 3 ^System Type

Structural

Non- S true tural

Architectural

Mechanical/Electrical

Foundation

^System Function

Seismic Resisting

Frame

Moment Frame (Unbraced)

Braced Frame

Wall

Shear Wall

Bearing Wall

Screen Wall

Diaphragm

Horizontal Truss

Non-Seismic Resisting

^Material

Soil

Wood

Plywood

Steel

Concrete

Unreinforced Concrete

Reinforced Concrete

Precast Concrete

Cast- in-Place Concrete

(continued)

Figure 4.4 Physical Entity field from an alternative

classification [12] for seismic provisions for buildings

showing eight facets (* denotes the root of a facet)

.

93
^Material (continued)

Masonry

Masonry Units, Mortar, Grout

Unreinforced Masonry

Reinforced Masonry

Stacked Bond Masonry

Hollow Unit Masonry

Undifferentiated Material

^Element Type

Beam

Column

Beam-Column

Boundary Member

Pile

Uncased Pile

Cased Pile

Equipment

Collector Member

Tie Member

Undifferentiated Element Type

*Part of Element or System

Reinforcement

Lateral Reinforcement

Longitudinal Reinforcement

Reinforcement Splice

Reinforcement Anchorage

Joint

Member Anchorage

Opening

Sheathing and Diagonal Board

Undifferentiated Part

^Element Function (stress)

Axial Stress

Flexural Stress

Shear Stress

Torsional Stress

Undifferentiated Element Function

Figure 4.4 Physical Entity field from an alternative

classification for seismic provisions (concluded)

.

94
I

4.2.2 Proper Usage

Proceed from small to big. It is best to generate and examine smaller

hierarchies corresponding to individual facets before combining classifiers

into larger fields.

Generate early and often. Hierarchies should be generated and examined as soon as a few classifiers have been identified, and regenerated whenever a significant number of classifiers is added or their relations modified.

Correct for loops. If the analysis reveals the presence of loops, these

must be eliminated by redefining parent or foster parent relations among

classifiers. Unlike loops in networks (see section 3.6), loops among classifiers arise infrequently, and are more likely caused by data entry errors

than by logical flaws in the definition of classifier hierarchies.

4.2.3 Representation

In SASE, a hierarchy is generated by the GENERATE HIERARCHY command. Since

all classifiers are identified with a VERSION of a standard, the hierarchy

does not have an explicit reference number. If the FACET qualifier is used,

separate facet hierarchies will be generated using the PARENT attributes

only, starting from the root nodes of each facet (root nodes of facets have

no PARENT) . If the ALL qualifier is used, the facets will be combined into

FIELDS, by connecting root nodes of facets through their FOSTER parent (s)

.

The hierarchy will start from the root node(s) of field(s) (root nodes of

fields have neither PARENT nor FOSTER parent) . The inclusion in a particular field of a facet root node having more than one FOSTER parent is conditional on the CONTEXT specified for each FOSTER parent (see section 4.1.3).

SASE produces error messages if:

• a loop is detected (i.e., the hierarchy is not a strict tree), in

which case a list of the nodes (classifier reference numbers) that

form the loop is printed;

• a GENERATE HIERARCHY ALL is requested, but one or more facet root

nodes are not linked up through FOSTER parents.

In either case, the user must MODIFY the PARENT or FOSTER parent of one or more classifiers before the hierarchy can be generated.

The DISPLAY HIERARCHY command provides a number of options for displaying a hierarchy:

• the display can show ALL nodes or only ROOTs or FIELDS or FACETs

,

• the display can include the hierarchy of the entire VERSION or only

a selected FIELD or FACET, and

• the display can be in STRUCTURE (indented) or LIST (tabular) form.

95
4 . 3 Scopelis

t

4.3.1 Definition

The scopelist is the basic cross-reference between classifiers and data

items. The scopelist is generated by appending to each classifier the list

of all data items having that classifier as one of its arguments. Thus,

each datum will appear under each of the classifiers in its argument list.

A scopelist for the fire escape example was shown in table 2.10. An example

in SASE format is given in Appendix A.

4.3.2 Proper Usage

Proceed from small to big. It is best to generate and examine smaller

scopelists before generating larger ones. As soon as the hierarchy of a facet appears satisfactory, it is advisable to generate a scopelist for

that facet. Examination of the data items under each classifier will help

in "calibrating" the classification scheme, namely, in deciding whether the

classifiers appropriately identify and group related provisions. It may be

advisable to perform this analysis on data items from individual chapters

before performing it on the entire version. Conversely, particularly in

synthesis, if the scopelist of some classifier(s) contains isolated data

items from several chapters, regrouping those data items into more closely

related chapters and redefining the classification scheme may both be

appropriate

BalanceThe scopelist should be carefully reviewed for classifiers with

an excessively large number of data items (the COUNT option is useful as a preliminary screening tool) . Such large "clusters" warrant a review of

both the classification scheme (to see whether one or more classifiers

should be further subdivided) and the data items (to see whether requirements of the multiple or cumulative type should be subdivided)

4.3.3 Representation

In SASE, a scopelist is generated by the GENERATE SCOPELIST command. There can be only one SCOPELIST for each VERSION of a standard. Therefore, the

scopelist does not have an explicit reference number. The user must specify the CHAPTERS to be included in the scopelist. A hierarchy must have

been previously generated.

The DISPLAY SCOPELIST command provides a number of options for displaying a scopelist

• all the options on choice and formats of classifiers discussed in

section 4.2.3;

• the choice of all data items or only REQUIREMENTS or DETERMINATIONS

(COUNT gives just the number of data items rather than a listing)

® the choice of all classifiers or only those used for OUTLINing or INDEXing.

96
4 . 4 Index

4.4.1 Definition

An index is a list of classifiers with a list of references to provisions

associated with each classifier that provides access to the provisions.

The simplest form is an alphabetical arrangement of the classifiers in a single level, with a cluster of references to the provisions associated

with each classifier given below (hereafter called a "simple index").

Figure 4.5 is an example of such an index; it is a portion of the index

produced for [18]. Each reference in a cluster consists of three parts:

the datum number, the descriptive title of the datum, and the section or chapter number of the original text containing the provision. The datum

number alone might suffice for access in some instances, but the descriptive title is particularly helpful in a simple index. It would be possible

to include the page number. Note that the most common index for a book is

a single level list of headings with a cluster of page numbers for each

heading

.

A characteristic defect of simple indexes is that many headings reference

clusters containing too many provisions for efficient use. An index with

multiple levels of headings, such as in figure 4.6a, aids the user by

subdividing the clusters of references to provisions into more intelligible

groups

.

Indexing principles can be formulated for indexes with multiple levels of

headings and for indexes with several classifiers for each heading (see

figure 4.6 for examples of both). The former type is quite useful for

large indexes. The latter type introduces more power and possibly more

relevance, but also causes additional problems of length. It does not seem worth the added cost when the provision reference in the index contains the

datum description, because the description and a heading containing most or all of the arguments of the provision are frequently very similar.

It is useful to include both requirements and determinations in the index.

Even though all terminal, or highest level, data items correspond to re- quirements, use of the standard frequently requires access to non- terminal

provisions for many purposes. This is particularly true for determinations

that evaluate important characteristic quantities. The outline system

primarily, but not wholly, provides access to the requirements, and the

information network system primarily provides access to determinations

through the ordering of the global ingredience of requirements. The index

is essentially a backup access system and must provide access for both

types of provisions.

As described in section 4.1.1, the logical principles for classing a provision may be violated for the purpose of Indexing. Generally speaking, the

arguments of a provision for outlining will be fewer in number than those

for indexing. A common example would be a requirement with compound THINGS

or REQUIRED QUALITIES. Such a provision must be related to a general classifier for unique placement in an outline, but for reliable access through

97
ALPHABETICAL INDEX REFERENCE LOCATION

ACCESS/EGRESS; BLOCKED

1472 GROUP III ACCESS REQUIREMENT

ALTERATION

1380 ALTERATION AND REPAIR REQUIREMENT

ANALYSIS

3105 STRUCTURAL ANALYSIS REQUIREMENT

3381 CATEGORY C AND D INTERACTION REQUIREMENT

4001 EQUIVALENT LATERAL FORCE ANALYSIS REQUIREMENT

5001 MODAL ANALYSIS REQUIREMENT

5210 MODELING REQUIREMENT

5310 MODES REQUIREMENT

5410 PERIOD AND MODE SHAPE ANALYSIS REQUIREMENT

6001 SOIL STRUCTURE INTERACTION ANALYSIS REQUIREMENT

ANALYTICAL EVALUATION

13226 ANALYTICAL EVALUATION PROCEDURES REQUIREMENT

13228 ANALYSIS METHOD REQUIREMENT

13230 DETAILS OF ANALYTICAL EVALUATION REPORT REQ

13246 RESULTS OF ANALYTICAL EVALUATION

13248 GOVERNING EARTHQUAKE CAPACITY RATIO

13262 ALLOWABLE EARTHQUAKE CAPACITY RATIO

ANCHORAGE

8165 ARCH/MECH/ELEC ATTACHMENT REQUIREMENT

8240 EXTERIOR WALL PANEL ATTACHMENT REQUIREMENT

8315 AMPLIFICATION FACTOR FOR ATTACHMENT OF M/E COMP

8321 TYPE OF RESILIENT MOUNTING SYSTEM

8345 MECH/ELEC ATTACHMENT DESIGN REQUIREMENT

8369 M/E ATTACHMENT CERTIFICATION (TESTING) REQUIRED

ARCHITECTURAL

8100 ARCH/MECH/ELEC PROVISIONS APPLICABLE

8105 ARCH/MECH/ELEC PERFORMANCE LEVEL

8106 PERFORMANCE LEVEL FROM TABLES -B

8190 PERFORMANCE CHARACTERISTIC FACTOR

8200 ARCHITECTURAL DESIGN REQUIREMENT

8215 SEISMIC FORCE FOR ARCHITECTURAL COMPONENTS

8220 SEISMIC COEFFICIENT FOR ARCHITECTURAL COMP

8240 EXTERIOR WALL PANEL ATTACHMENT REQUIREMENT

Figure 4.5 Example of a simple index

1.4.2(E)

1.3.2

3.1

3.3.4(B)

CHAPTER 4

CHAPTER 5 5.2

5.3

5.4

CHAPTER 6

13.2.2

13.2.2

13.2.2

13.2.2

13.2.2

13.2.2

8 . 1.2

8.2.3

8.3.2(A)

8.2.3, 2.1

8.3.3

8.3.4

8.1

8.1, 8.1.3

TBL 8-B

8.1.3, TBL 8 -A

8. 2. 1-5

8.2.3

8.2.3

8.2.3

98
CATEGORY A

3620 CATEGORY A DESIGN AND DETAILING REQUIREMENT

9300 CATEGORY A WOOD REQUIREMENT

11300 CATEGORY A CONCRETE REQUIREMENT

11310 CATEGORY A CONCRETE FRAMING REQUIREMENT

11340 CATEGORY A CONCRETE ANCHOR BOLT REQUIREMENT

CATEGORY B

BEAM

11602 ORDINARY CONCRETE FLEXURAL MEMBER REQUIREMENT

11604 ORDINARY CONCRETE FLEXURAL MEMBER REINFORCEMENT REQUIREMENT

11618 ORDINARY CONCRETE FLEXURAL MEMBER MOMENT RESISTANCE REQ

11628 ORDINARY CONCRETE FLEXURAL MEMBER REINFORCEMENT ANCHORAGE REQ

11640 ORDINARY CONCRETE FLEXURAL MEMBER WEB REINFORCEMENT REQ

CASED

7476 CATEGORY B CASED CONCRETE PILE REQUIREMENT

COLUMN

11662 ORDINARY CONCRETE BEAM COLUMN LATERAL REINFORCEMENT REQ

COMPONENT

CASED

7476 CATEGORY B CASED CONCRETE PILE REQUIREMENT

CONCRETE

7452 CATEGORY B UNCASED CONCRETE PILE REQUIREMENT

7476 CATEGORY B CASED CONCRETE PILE REQUIREMENT

7490 CATEGORY B CONCRETE FILLED STEEL PIPE PILE REQUIREMENT

7492 CATEGORY B PRECAST CONCRETE PILE REQUIREMENT

7494 CATEGORY B PRESTRESSED CONCRETE PILE REQUIREMENT

DETAILED DESIGN

3630 CATEGORY B DESIGN AND DETAILING REQUIREMENT

3640 CATEGORY B OPENINGS REQUIREMENT

a) Multiple level headings

CATEGORY B CONCRETE ORDINARY MOMENT FRAME

11600 CATEGORY B CONCRETE ORDINARY MOMENT FRAME REQUIREMENT

11602 ORDINARY CONCRETE FLEXURAL MEMBER REQUIREMENT

11604 ORDINARY CONCRETE FLEXURAL MEMBER REINFORCEMENT REQUIREMENT

11618 ORDINARY CONCRETE FLEXURAL MEMBER MOMENT RESISTANCE REQ

11628 ORDINARY CONCRETE FLEXURAL MEMB. REINFORCEMENT ANCHORAGE REQ

11640 ORDINARY CONCRETE FLEXURAL MEMBER WEB REINFORCEMENT REQ

CATEGORY B CONCRETE PILE REINFORCEMENT

7452 CATEGORY B UNCASED CONCRETE PILE REQUIREMENT

7476 CATEGORY B CASED CONCRETE PILE REQUIREMENT

7490 CATEGORY B CONCRETE FILLED STEEL PIPE PILE REQUIREMENT

7492 CATEGORY B PRECAST CONCRETE PILE REQUIREMENT

7494 CATEGORY B PRESTRESSED CONCRETE PILE REQUIREMENT

b) Multiple classifier headings

Figure 4.6 Examples of advanced indexes

99
an index it would be better if the provision were related to specific

classifiers for each of the compounded THINGS or REQUIRED QUALITIES. Another common example is the addition of more general classifiers for indexing when the arguments are of a very narrow scope.

In some instances, classifiers are associated with provisions purely for

the purpose of arrangement in outlining. For example, requirements for the

performance of a structure might be classed according to the stages of the

design process in which the requirement normally would be satisfied. Such

classification is relevant in outlining, but possibly can be misleading in

indexing, if the same classifiers are used (1) to indicate the THING or REQUIRED QUALITY of some requirements and (2) for arranging some other

requirements pertaining to other THINGS or REQUIRED QUALITIES. The user of

the index has no sure way of distinguishing between these two purposes, and

he might assume that the heading (classifier) is related to the THING for

each associated provision. For the purpose of indexing, a provision should

be deleted from the scope list of a classifier when that classifier is

associated with the provision only for purposes of arrangement in outlining.

Logical classing is not necessary for indexing because the structure of an index depends primarily on the relation of a classifier and a provision.

The relations between classifiers are much less important. The index does

not have a unique location for each provision reference; it generally will

have several, even if the classing is strictly logical. The index benefits

from relaxation of logical rigor when it can make the product more natural,

and when the relaxation can do no harm.

An alphabetical ordering of the headings in an index is meaningful and well

accep.ted. The other choice for indexing is to order the headings by their

positions in the trees of classifiers. The Alphabetical order appears

preferable because it is common to so many indexes and because doing so relieves one from making decisions about the ordering of fields and facets

for use as an index. Adopting the alphabetical order adds importance to

the ordering of words in multi-word headings. Thus classifiers containing

more than one word ideally should have the most relevant word placed first.

The production of an alphabetical index of the simple type on a computer is

quite elementary, once the classification, the provision references, and

the arguments for each provision have been stored. Two preliminary steps

are the transposition of the argument lists to determine the provisions

associated with each classifier (i.e., generation of the scopelist) and the

alphabetical sorting of the classifier names. The only decision-making

necessary during the generation of the index is to suppress those classifiers associated with no provisions (common for very general classifiers)

,

to delete those classifiers associated with too many provisions to be

useful, and to delete provisions from the scope list of a classifier when

the association is for purposes of arrangement only.

100
4.4.2 Proper Usage

Generate sparingly. Unlike the scopelist, the index may take considerable

computer time to generate , and may provide too much information to analyze

and evaluate thoroughly. Therefore, it is recommended that analyses and

modifications be based on the scopelist generated, and the index be used

only in the final phase of formulating a standard.

4.4.3 Representation

In SASE, an index is generated by the GENERATE INDEX command. There can be

only one index for each VERSION of a standard. Therefore, the index does

not have an explicit reference number. A SCOPELIST must have been previously generated.

The index may be specified as SIMPLE, with a single level of classifier

headings, or SUBDIVIDED according to classifier levels, so as to break up

large clusters of provisions. Certain classifiers may be DROPped from the

index; by specific classifier numbers, by specific ROOTs of field or facets, or those whose scopelist exceeds a certain number or percentage of

the total.

The DISPLAY INDEX command provides a number of options for displaying an

index, which may include:

• all classifiers or only those of specific FIELDS or FACETs

;

• all data items in the scopelists or only REQUIREMENTS or DETERMINATIONS :

• a COUNT of the data items in each scopelist rather than their listing.

4 . 5 Organization

The concepts of organization and outline are closely related. The reader

should be comfortable with the material in both this section and in section

4.6 before creating extensive organizations and outlines for a standard.

4.5.1 Definition

An organization, or more precisely, its dual representation, an organizational tree, is a tree of classifiers formed by appending nuclear trees

from various facets and fields. An organization is the list representation

of its organizational tree, with the structure and classifiers in the tree

converted into hierarchical headings in the organization. An organizational

tree differs from a hierarchy (see section 4.2), in that the organizational

tree is "built" one nuclear tree at a time (that is, one parent classifier

and its immediate descendent classifiers), whereas for the hierarchy, once

the root of a facet is included, the entire tree of that facet is included.

An organization differs from an outline (see section 4.6) in that the

101
organization contains only the classifiers as headings, whereas the outline

contains also the provisions entered at the appropriate headings.

In synthesis, the goal of the organization process is to assist standards

writers in defining the scope of a new standard by identifying those combinations of classifiers that correspond to potential provisions. In expression, the goal is to assist users of an existing standard in quickly and

reliably locating the relevant provisions by providing a logical arrangement for them. An effective organization, one •. that meets these goals, pos- sesses five qualities:

1. Relevant: Each heading is significantly related to its provisions; it concisely expresses their scope.

2. Meaningful: The reader perceives the heading as being relevant to

the provision.

3. Unique: The headings are distinct from one another to allow

readers to access provisions unambiguously.

4. Complete: The total set of headings covers the entire scope of

the standard and nothing more.

5. Graded: The headings show a regular gradation in scope through

the levels.

Additional qualities are desirable for an efficient organization:

6. Progressive: The headings at any level are ordered in a pattern

significant to the reader.

7. Intelligible: The depth (the number of levels in an organization)

and breadth (the number of headings at one level) does not exceed

the span of immediate memory of the reader.

8. Minimal: The number of headings is the minimum necessary for

meaningful access.

9. Even: The organization divides the provisions so that depth and

breadth do not vary greatly from one part to another.

Criteria for judging the effectiveness and efficiency of an organization

can be developed for each of these qualities. Criteria for the first and

second qualities - -Relevant and Meaningful- -can be evaluated completely only

when an outline is developed from the organization; discussion of these

qualities carries into section 4.6. Criteria for the other qualities can be

evaluated on the basis of the ordering and grouping of the classifiers

only. The ability to generate and evaluate alternative organizations

before introducing the provisions is a valuable tool for both the synthesis

and the expression of standards. An example of an organization was presented in the fire escape example in Chapter 2.

102
Use in Synthesis. The process of synthesizing a new standard includes the

identification of provisions potentially to be included in the standard.

This identification is accomplished in several stages. Iteration of the

stages is normal.

In the first stage, a "top-down" classification is constructed. This must

include at least one field for THING and one for REQUIRED QUALITY. Top-down

classification is essentially a way of making decisions about scope, and

then retaining those decisions as the criteria for completeness and relevance in the organization of a standard. It is practicable because the

classification of the subjects and objectives of a standard automatically

gives a classification for the THINGs and REQUIRED QUALITIES for the re- quirements of the standard. Classification has already been discussed in

detail in section 4.1.

In the second stage, an organizational tree is constructed from the classification. The purpose of constructing the organizational tree is to produce

the combinations of THING and REQUIRED QUALITY classifiers that correspond

to provisions. The ordering of provisions is not of particular concern at

this stage.

The construction of the organizational tree is presented as a formal algorithm below. This classifier-driven algorithm has not been implemented in

SASE but is presented here as an aid to the reader constructing an organization manually using the available SASE tools.

The first step is to explode the trees of the classification into nuclear

trees (recall that a nuclear tree is defined in section 4.1 as a classifier

and its direct children). Thus, the process of appending trees into an organizational tree deals with one set of logical siblings at a time. The

relations among and within facets are not forgotten in this step; each

nuclear tree belongs to a certain facet and field, and the context conditions for a facet apply to each of the nuclear trees taken from it.

The second step is to select the root of one of the major THING or REQUIRED

QUALITY fields as the root of the organizational tree. The process of

appending begins with consideration of its first child, which is the first

terminal node to be examined in step three.

The third step is the heart of the algorithm. Considering the classifiers

on the branch from the root to any particular terminal node as the "stack",

the stack and the remaining nuclear trees are examined to determine whether

it is necessary, appropriate, or possible to append an additional nuclear

tree. Because the model of a basic requirement has a THING as subject and a REQUIRED QUALITY as predicate, it is necessary to append another tree if

the stack does not contain the root nuclear trees for the field of THING

and the field of REQUIRED QUALITY. It is often appropriate that the stack

contains more than one classifier for either or both of these two categories. The possibility of appending a nuclear tree is governed by the

following rules

;

103
1. Relevant: a nuclear tree whose parent is the root of a field may

be appended at any location; a nuclear tree whose parent is the

root of a facet but not a field may be appended when a class that

the facet expands is present on the branch; and a nuclear tree

whose parent is neither may be appended when a predecessor is on

the branch.

2. Unique: only one nuclear tree may be appended to any single node

of an organizational tree.

3. Graded: a nuclear tree may not be appended where a descendant of

the tree is already on the branch.

4. Complete: all the siblings shall be retained when appending the

nuclear tree.

5. Progressive: the order of the siblings in the organizational tree

shall be the same as in the original classification.

6. Minimal: larger nuclear trees should be appended after smaller

nuclear trees

If the conditions are met, the nuclear tree is appended by "burying" the

parent at the current terminal node and then processing to its first child.

The third step is then repeated. If more than one nuclear tree are possible candidates, the most appropriate should be selected from due consideration of the consequences of the subsequent execution of step three. If no possibility of appending another tree exists, proceed to step four.

The fourth step is to select the next appropriate action once a branch is

terminated. If the terminal classifier has a sibling remaining, proceed to

it and execute step three for the new branch. If no sibling remains,

examine the parent in the organizational tree (note that, in general, this

would not be the parent of the nuclear tree) . If that classifier is not a root of a field, the fourth step is repeated. If that classifier is a root

and if no other fields remain that can be used to start a new tree (or a new "trunk"), then the algorithm is completed. If such fields remain, the

root can be appended and the algorithm continued from step two.

If the resulting tree contains each field in the classification such that

each terminal classifier from the root nuclear tree of each THING field is

combined with each terminal classifier from the root nuclear tree of each

REQUIRED QUALITY field, then the tree covers the scope of the classification. Note that different THING fields need not be combined and that

descriptive REQUIRED QUALITY facets do not control any check for completeness. The order in which classifiers occur on a branch is not a factor in

this algorithm (except for hierarchical considerations) although it is a consideration in some techniques for arrangements.

Several of the rules for appending nuclear trees used in this algorithm

deserve further discussion. The first rule, Relevant, reflects the follow104
ing considerations. Fields are independent classifications; there is no situation where appending the root nuclear tree of a field would be irrelevant, provided the logical rules are not violated. Facets that are not the

root of a field are not independent; they are a subdivision of some other

class or classes in their field. Thus it would be irrelevant to append the

root of a facet unless such a class is already in the organizational tree.

For example, "Cast- in-place" and "Precast" are the siblings in a nuclear

tree that serves to modify the class "Concrete". Appending that nuclear

tree to "Steel" would be irrelevant.

For the nuclear tree that is not the root of a facet (the third type men- tioned) , the simplest rule for relevant appending would be that the parent

of the nuclear tree must be present on the branch (not necessarily at the

terminus). This has great intuitive appeal, but in practice it seems to be

too rigid. Relevance depends a great deal on the specific context of the

situation, but a few generalizations are in order. First, relevance is

much less likely if an extended sibling is present on the branch. (An

extended sibling is a classifier from the same facet that is neither a predecessor nor a descendant [See section 4.6].) Second, relevance is

possible even through the parent is not present, as long as some predecessor is present. Strict application of a rule requiring the parent to be

present ignores this second obseirvation, introducing unwanted depth in

organizational trees and reducing desirable flexibility.

A system for recording relations among facets is incorporated in SASE. It

is designed to meet the need to determine the eligibility of a facet. In

this system, each facet (except the root of a field) is attached to one or more "foster parents," which are simply other classifiers in the field.

The foster parents need not be terminal classifiers on a facet. In addition, each link between a facet and a foster parent may be made conditional

be specifying and recording a "context" (see section 4.1). Contexts take

the form of conditions that given classifiers must be present or absent (in

the organizational tree) for the relation between the foster parent and the

facet to be relevant. For example, the facet "Concrete Pile Construction"

may be appended when its foster parent "Pile" is on the branch of the

organizational tree only if the classifier "Concrete" is also on the

branch. (Use of such a system for checking the relevance between a classifier and argument for the purpose of provision entry requires a more thorough specification of the permissible links for successful use.)

The second rule. Unique, prevents the creation of "step siblings" in the

organization. In the following example derived from [18], "Pile" and

"Strength" have been made step siblings:

Foundation

Soil

Foundation Structure

Strength

Interrelationship

Pile

Existence

Details

105
Because of this forced relationship, the question arises whether piles will

be included in strength (and interrelationship) requirements for the foundation structure. Violation of this rule has been quite common in past

models for organization.

Finally, it should be apparent that this classifier-driven algorithm can generate an extremely large organizational tree because of the assumed

independence of the various fields and because of the requirement for

completeness. The "top down" development of a classification advocated at

the beginning of this section helps minimize the size of the resulting

organizational tree.

Use in Expression. The capability to generate alternative organizations for

a set of existing provisions is a key aspect of the SASE methodology. The

needs for a method with enough rigor to preserve and promote the relevance

and logic incorporated in the classification system and yet with enough

flexibility to provide several arrangements might seem contradictory. Nonethe-less, such a capability is central to SASE.

Compared to generating an organizational tree in synthesis, generating an organizational tree in expression does not demand the presence of at least

one field for THING and one for REQUIRED QUALITY, nor does it require

strict enforcement of the completeness rule for appending nuclear trees,

because the resulting organization will serve only to order the existing

provisions when they are outlined, not to identify all potential provisions. For the same reason, the organizational tree need not be a complete

representation of the classification. It is conceivable that a single facet

could lead to a useful ordering of a set of provisions. However, the organization must provide a location for each existing provision.

With these points in mind, the classifier-driven technique described in the

preceding section "use in synthesis" can be used to generate alternative,

or trial, organizations for an existing standard, and these organizations

examined for the qualities discussed at the beginning of this section. It

should be noted, however, that when the outline is subsequently generated,

the majority of the branches in the organizational tree likely will be

found not to have any provisions associated with them. This point is discussed further in section 4.6.

4.5.2 Proper Usage

Proceed from small to big. It is best to enter, examine, and modify

smaller organizations corresponding to various grouping of facets before

entering an organization for an entire version.

Use as "template" for outlining. Since fewer decisions are required for

generating an organization than for generating an outline, it is advisable

to experiment with several organizations before proceeding to building a complete outline.

106
4.5.3 Representation

In SASE, an organization is generated by the ENTER ORGANIZATION command.

(It can also be generated concurrently with an outline. See section 4.6.)

Since there may be alternative organizations within a VERSION of a standard, the organization is given a reference number.

The organization is built in a dialogue form. For each line of input, the user specifies a classifier to serve as the heading, and the hierarchical

position of that heading on the organization tree. For the latter, two

options are provided:

• if the LEVEL qualifier is used in the command, the user directly

specifies the hierarchical level to be assigned to the classifier

entered.

• if the PARENT qualifier is used in the command, the user enters the

heading number previously assigned to the parent of the classifier

entered; SASE automatically assigns a hierarchical level to the

classifier equal to the parent's level plus one.

Entry by the PARENT option is recommended, as this is the only way to ensure that the hierarchical relation of the nuclear trees is properly

reflected in the organization.

Since entry of a sizeable classification is time-consuming, the user can

END the dialogue to any time and resume entry using the CONTINUE ORGANIZATION command.

The MODIFY ORGANIZATION permits various rearrangements, including:

• INSERTing specific headings by LEVEL or PARENT, as above;

• DELETing a specific heading or a set of headings;

• DUPLICATing or MOVing a specific heading or set of headings to a specified position.

• MODIFYing a specific classifier, its level or its parent in the

organization.

The DISPLAY ORGANIZATION command provides a number of options for displaying an organization:

• the display can be in indented or tabular form;

• the tabular form can include any attributes of the classifiers

serving as headings

.

107
4 . 6 Outline

4.6.1 Definition

An outline is a list representation of the scope of a standard. It consists

of a hierarchical arrangement of the classifiers as headings of sections

(i.e., an organization) with the provisions of the standard entered under

the appropriate headings

.

The goal for the process of outlining a standard is to find the best linear

order of the provisions in the list- -the order that maximizes the desired

qualities of organization described in section 4.5. Outlining differs from

indexing in the necessity for logical rigor. Because an outline is intended to provide a single point of access for every provision, logical

unambiguity is more important than it is for indexing, in which classing a provision by two siblings is acceptable. (Note that the outlining process

does not guarantee that a provision will appear only once in the outline;

this problem is taken up in the discussion of provision entry.)

The approach advocated here involves two activities:

1, Generating alternative outlines with strategies that promote the

desirable qualities.

2. Measuring the qualities of different outlines to compare their

overall goodness for the specific intended use.

This approach has the advantage of being able to provide different outlines

of the same provisions for different users. Only the generation of the

outlines is discussed in this report. Much of the basis for preference of one outline over another is individual and subjective; hence, little guid- ance can be given on measuring the quality of an outline. A discussion of

several useful measures is presented in [9].

The generation of an outline from a classification for a set of provisions

logically proceeds in two steps: first, an organizational tree is generated

by appending nuclear trees of classifiers together, then provisions are en- tered on the branches of the tree according to their arguments. In SASE,

these steps can be taken separately by first generating an organization

from the classification, as described in section 4.5, and then generating

an outline from it, or the steps can be taken together in an interactive

input mode to generate an outline (including its organization) directly

from the classification.

The techniques of creating an outline are discussed in more detail in the

following two subsections. First, the methods for generating organizational trees are reviewed; then, criteria for entry of a provision on a branch of an organizational tree are discussed.

Generation of organizational trees

,

The rules for appending nuclear trees

to an organizational tree described in section 4.5 can be modified when the

goal is the generation of an outline for existing provisions. Now two

108
different criteria are available for making the decision to cease the

extension of a branch and move on to the next branch: the absence of any

qualified nuclear trees or the absence of an eligible provision. The first

criterion was used in the classifier-driven technique presented in section

4.5. Classifier-driven techniques allow one to maintain the completeness of

the classification system in the organizational tree, and thus to check the

completeness of the provisions. However, nearly all techniques for generating outlines for an existing set of provisions make use of the second

criterion; they may be termed "provision driven." Classifier-driven

techniques are not often used for expression of existing standards because

the resulting organizational trees are extremely large and the majority of

their branches do not have provisions associated with them.

The reason that classifier-driven techniques develop so many empty branches

is that the assumption of independence between the fields is not warranted.

Consider the analysis of the seismic provisions [18], and the classification system for it given in figure 4.3. If the 21 facets in the "Physical

Entity" field were independent (obviously they are not, nor are they as- sumed so) an organizational tree fully incorporating all of them would have

over three billion branches (the product of the terminal branches of the 21

facets) . The most conservative estimate for the number of branches in an organizational tree for that classification would proceed as follows: assume that the "Physical Entity" field is one tree with no interaction (a

false assvimption) , thus having 62 branches (the sum of the terminal classifiers of its facets) , and assume that the 21 branches of the "Process"

field (not shown) combines additively, not multiplicatively , with it to

give all THINGS possible for subjects of Requirements (also a false assumption). Ignoring other possible fields, estimate the total number of

branches as the product of the 12 branches of the REQUIRED QUALITY field

(also not shown) and the 79 branches of the combined subject fields. The

total thus obtained is 948, whereas the total number of requirements found

in that study is 242. It does not appear that the number would approach

948. The assiomption regarding the "Physical Entity" field having only 62

branches is quite extreme. Thus, a more realistic assumption would result

in a number of branches far in excess of 948.

The drastic pruning of the branches of the actual organizational tree

compared to the complete tree occurs because there are many situations in

which it is correct to append only a portion of a nuclear tree, leaving

some of the siblings off the organizational network. Provision-driven

techniques allow this

.

A problem that arises in generating an organizational tree for outlining

purposes is that some provisions are of a more general nature than others,

and therefore strict application of the Graded criterion for provision

entry frequently will prevent the entry of the more general provisions in an organizational tree. It is possible to overcome this problem by expanding the classification system. Such was the reason for including the facet

"Material Nature" with the sons "Material Generic" and "Material Specific"

in the classification for the seismic provisions (figure 4.3). This small

109
facet was appended in conjunction with the material types thus:

Material Generic

Material Specific

Wood

Steel

Concrete

Masonry

This allowed otherwise identical branches to be constructed so that both

general and specific provisions could be outlined without forcing "Wood,"

"Steel," and so forth, to become siblings of other classifiers to which

they were logically unrelated.

Entry of provisions in an organizational tree. Entry depends upon the com- parison of the set of classifiers that compose a branch of an organizational tree with the set of outlining arguments for a provision. The

comparison reveals whether the provision is appropriately identified by the

classifiers on the branch. The decision to enter a provision is based on four criteria which follow from the qualities necessary for an effective

organization of a standard (see section 4.5) as follows:

1. Relevant: each classifier on the branch must be related to one of

the provision's outlining arguments.

2. Complete: each outlining argument of the provision must be included among the set of classifiers on the branch.

3. Unique: no classifier on the branch may be a "cousin" (This con- cept is defined subsequently) of any outlining argument.

4. Graded; no classifier on -the branch may be a descendant of any

outlining argument.

The decision does not depend on the desirable qualities Even, Minimal, and

Progressive because they are not relevant in the context of a single branch

of an organizational tree. The quality Meaningful is achieved automatically

the arguments for each provision have been selected properly. It is possible to consider a limit on the number of nodes on a branch as a criterion

for the quality Intelligible.

Each of the four criteria depends on the logic of the classification system. Since a faceted classification system need not be strictly logical,

checking of the criteria becomes complex. As mentioned in section 4.2, it

is possible to combine all the facets in a field into a single large facet,

but frequently it is also possible to combine the facets in a relevant

fashion into a large tree that is not completely logical. The problem is

to define clearly how the qualities can be attained with a less than perfectly logical classification system.

Given a faceted system, the criterion for the quality ' Relevant is easily

described in three steps. Each classifier on the branch must pass the

110
criterion for the provision in question to qualify for entry on the branch.

The three steps are:

1. A classifier that is an argument of the provision is relevant.

2. A classifier from the same facet as an argument is relevant if it

is a logical predecessor of the argument. (A logical predecessor

is the parent, the parent of the parent, etc.)

3. A classifier from the same field, but not the same facet, as an argument is relevant if it is a logical predecessor of the argument in a large tree of combined facets.

The second test can be extended to say that a classifier from the same facet as an argument is not relevant unless it is a predecessor of the

argument (assuming it failed the first test) . Making this extension means

that the criteria for the qualities Unique and Graded mentioned previously

are automatically included, as far as facets are concerned. As shown in

figure 4.7, there are four possibilities for a classifier and an argument

from the same facet: the classifier is a predecessor, descendent, or cousin of the argioment or is the same as the argument. As shown in figure

4,7, a cousin includes the siblings, the siblings of the predecessors, and

any descendants of such siblings. The third test for the quality Relevant

cannot be similarly extended, (that is, it cannot be used to disqualify a provision simply because one classifier fails the test) , because the possibility of illogical siblings leaves the possibility that the classifier may

be relevant for another argument for the same provision.

The principal problem in using these tests for the quality Relevant is that

a complete specification of the permissible interconnections of the facets

is required as a part of the classification system. Otherwise a potentially relevant classifier that is not traceable to any argument will

disqualify a provision from appearance on the appropriate branch. A system

for recording and using relations between facets is included in SASE.

An added problem is that the tracing of the permissible interconnections

among facets involves significantly more checking than any other tests

employed for entry of a provision on a branch.

There is a less stringent criterion for the quality Relevant that frequently is good enough to produce useful outlines. The criterion combines

well with the relatively simple criteria for the qualities Unique and

Graded, which tend to prevent irrelevance in addition to delivering their

named objectives. The criterion is quite simple: the last classifier on

the branch must be an argument of the provision. It is accomplished efficiently by selecting those provisions in the scope list of the last classifier and discarding all others. Since it is the last classifier on the

branch, it also has the desirable feature of limiting the provisions to be

checked by the other criteria in an intuitively optimal fashion. For

convenience, this less stringent criterion is called "local relevance."

Useful outlines may be obtained employing the local relevance criterion

without any of the other criteria. Methods of synthesizing organizational

111
Figure 4.7 Partition of a tree into logical regions.

112
trees, described in section 4.5, tend to promote the validity of the local

relevance criterion.

The criterion for the quality Complete assures that a provision is not

prematurely entered into an outline. It has nothing to do with assuring

that all provisions are outlined, another aspect of completeness. The

criterion is independent of the question of relevance, and it is applied

conveniently immediately following the local relevance criterion. For each

provision passing the local relevance criterion, a check is made to see that each of its arguments is among the classifiers on the branch.

A separate check for the quality Unique at the facet level often is useful

when the full relevance criterion is not employed. The criterion disqualifies any provision with an argument that is a cousin of one of the classifiers on the branch.

A separate check for the quality Graded at the facet level often is also

useful when the full relevance criterion is not employed. The test is

convenient to apply in conjunction with the Unique criterion just described, because of the nature of the task of partitioning a tree as shown in

figure 4,7, Redundant, therefore ambiguous, locations for provisions may

be a common defect in outlines developed without use of the graded criterion, Because logic is not preserved above the facet level it is not

possible to apply criteria for Unique or Graded above that level,

A common defect in an outline that satisfies all the criteria except full

relevance is the entry of a single provision on more than one branch of the

organizational tree. The ambiguity usually arises from the use of a facet

that is not exhaustive, (A facet is exhaustive if its combined scope list

includes all provisions,) For example, consider a provision from the

analysis of the seismic provisions for buildings with the arguments: "Part

of Building," "Material Specific," and "Masonry," It would meet all criteria except full relevance for both of the following branches of classifiers :

(i) (ii)

Part of Building

Structural

Material Specific

Masonry

Part of Building

Nonstructural

Material Specific

Masonry

The problem is that Structural and Nonstructural are not exhaustive; the

provision could apply to either. Using the full relevance criterion, the

provision would not qualify for either branch.

Even the full relevance criterion is not guaranteed to prevent all redundant entry of provisions, unless the fields are strictly logical. Consider

the same provision just described and the following branches of classifiers :

113
(i) (ii)

Part of Building Part of Building

Material Specific Material Specific

Component Masonry

Masonry

"Component" belongs to a facet that can be used to distinguish among various "Parts of Buildings", and "Masonry" belongs to a facet that may be

used to distinguish among various "Components." The former fact means "Component" is not out of place in the branch, and the latter fact means

that "Component" can be a predecessor of "Masonry," thus satisfying the

full relevance criterion. Since "Component" is not an argiiment, the com- pleteness criterion is satisfied for either branch. Thus the provision

qualifies for both branches- -an ambiguous situation.

Three possible solutions for this problem exist. The first possible solution is to enforce the logical rules for the entire classification. For

reasons already explained, however, fully logical classifications are not

always desirable or possible.

The second possible solution is to strengthen the full relevance criterion

by requiring that each of the classifiers on the branch be an argximent or the direct predecessor (within the same facet) of an argument. This would

avoid tracing the relations between facets. It has the disadvantage of

requiring added identification and storage of arguments. For example,

consider the following five arguments for a requirement giving the minimum

amount and spacing of reinforcement in a cased concrete pile:

Pile, Reinforced Concrete, Cased,

Reinforcement, Quantities and Dimensions

With the exception of "Quantities and Dimensions," which is a child of

"Required Quality," these arguments appear in the physical entity field

shown in figure 4.3. Now, consider the application of the strengthened

relevance criterion against the following list of classifiers which clearly

represents an appropriate branch for the provision (compare figure 4.3):

Building - does not qualify

Required Quality - direct predecessor of "Quantities

and Dimensions"

Part of Building - does not qualify

Structural - does not qualify

Foundation - does not qualify

Foundation Structure - direct predecessor of "Pile"

Pile - is an argument

Quantities and Dimensions - is an argument

Reinforcement - is an argument

Reinforced Concrete - is an argument

Cast- in-place - direct predecessor of "Cased"

Cased - is an argument

114
The requirement fails to qualify for this branch based on the strengthened

criterion. The addition of "Foundation" as an argument for the requirement

would qualify "Foundation" trivially and "Structural" because it is a direct predecessor. The addition of "Part of a Building" as an argument

would qualify "Part of Building" and "Building" in like fashion. The re- quirement would then pass the strengthened criterion. For this provision,

it is not a large problem to add two arguments, but it could be for others.

Furthermore, it seems redundant because the argument "Pile" clearly implies

that all of those higher order classifiers are . relevant

.

The third possible solution is to develop a more complete and explicit set

of rules for tracing the relations among facets. One such test not included in the present system is to require that the argument indirectly related

to the classifier must follow that classifier (not necessarily immediately)

on the branch. Another is that the branch of classifiers contain at least

one classifier from each facet involved in the linkage.

Given that the relevance criterion is divided into two criteria, local and

full, and that the full relevance criterion will not always be used, an efficient strategy for computer processing emerges:

1. Apply the local relevance criterion.

2. For each provision passing the local relevance criterion, test

each argument for the Complete, Unique, and Graded criteria, in

that order.

3. For each provision passing those criteria, test each of the set of

classifiers for the full relevance criterion, di£>qualifying the

provision if any classifier fails. The full relevance criterion

is actually applied in three steps, repeated here for convenience:

the classifier is relevant if it is an argument or it if it is a logical predecessor of an argument, either within or outside the same facet.

Such an approach is included in SASE. The application of all three criteria is optional: testing may stop after any criterion, if desired.

A recommended strategy is to begin outlining using all criteria relaxing

the application of the later criteria if logical problems seem to preclude

the development of outlines that can include all the provisions. The

alternate strategy of beginning to outline without the more rigorous criteria, and resorting to them only if necessary to reduce the redundant

occurrences of provisions has the advantage of less costly computer processing, but it has the disadvantage of letting irrelevant, and sometimes

illogical, outlines be developed.

In summary, two independent criteria- -Relevant and Complete -- lead to five

criteria that work in a faceted classification system: local relevance.

Complete, Unique, Graded, and full relevance. It is possible to develop

good outlines without using all the criteria, but ambiguities and inconsistencies are less likely when using all the criteria. Because it still is

115
possible to develop outlines with more than one position for a provision

when using all the criteria, more study of the fifth criterion and of the

logic of faceted systems is in order.

The development of an algorithm capable of automatically and completely

generating an organizational tree and outline in a provision-driven mode

and with a faceted classification system appears to be a formidable task.

SASE contains a semi-automatic, interactive computer algorithm. With

respect to the criteria for appending nuclear trees presented earlier in

this section, the algorithm operates as follows:

1. Relevant: no explicit check is made

2. Unique: appending more than one nuclear tree to a single node is

possible, but only on explicit command of the user.

3. Graded: no explicit check is made.

4. Complete: no explicit check is made in most situations -- this is

not a classifier driven algorithm.

5. Progressive: the normal order of the classification is automatic,

although it is possible for the user to override it.

6. Minimal: the order of appending is completely up to the user.

The lack of explicit checks for Relevant and Graded is not intended to

imply that they are thought unnecessary. Rather, their incorporation is

advocated. They are not in the present SASE computer algorithm only because

the algorithm was developed to test various criteria for provision entry

rather than nuclear tree appending. A test for Relevant may be more problematic, as discussed. Various criteria should be tested for workability,

because incorporation of such a test would be an important step in the

development of a completely automatic algorithm.

The interactive algorithm is provision driven. Once the user has entered a branch, the algorithm determines which provisions have the potential to be

outlined on the branch should additional classifiers be appended to it.

The algorithm will also specify those classifiers upon request. The user

then continues by either appending another nuclear tree, or moving on to

the next branch.

4.6.2 Proper Usage

First develop a satisfactory organization (see section 3.5). Even with an organization as a "template" the user must proceed thoughtfully to obtain

the desired qualities for an outline. A logically unambiguous location must

be provided in the outline for each provision.

116
4.6.3 Representation

In SASE, an outline is generated by the GENERATE OUTLINE command. Since

there can be only one outline within a VERSION of a standard, the outline

does not have an explicit reference number.

There are two basic options for generating an outline:

• FROM a previously entered ORGANIZATION-; or

• STEPWISE, in a dialogue form similar to ENTER ORGANIZATION.

The user can further specify:

• whether ALL classifiers are to appear in the outline or only those

with relevant provisions;

• whether all data items are to be included or only REQUIREMENT or DETERMINATION;

• DROPping specified CLASSIFIERS, FIELDS, or FACETS from the outline;

and

• criteria for ENTRY (see above)

.

In the STEPWISE option, each heading (classifier) and its associated provisions (data items) are generated in two cycles of the dialogue:

• the user first enters a classifier to serve as the heading and its

hierarchical level in the outline (the heading may be a specific

CLASSIFIER or indirectly a descendant of a specified PARENT)

;

• the user specifies the provisions meeting the ENTRY criterion to be

entered under the heading; alternately, the user can first ask SASE

to LIST the qualified candidate provisions and then specify the ones to be entered.

Since generated of a sizeable outline is time-consuming, the user can END

the dialogue at any time and resume generation using the CONTINUE OUTLINE

command

.

The DISPLAY OUTLINE command provides a number of options for displaying an outline

:

• the display can be indented or tabular form;

• ALL or only specified classifier attributes can be included;

• ALL data items or only REQUIREMENTS or DETERMINATIONS can be included under each classifier; and

• ALL or only specified data item attributes can be included.

117
(This page intentionally left blank)

118
REFERENCES

1. BOCA Basic Building Code 1970 (Chicago: Building Officials and Code

Administrators International, 1969).

2 . Building Code Requirements for Reinforced Concrete (ACI 318-77)

(Detroit: American Concrete Institute, 1977).

3. Fenves, S. J., Computer Methods in Civil Engineering (Englewood

Cliffs, NJ : Prentice-Hall, 1967),

4. Fenves, S.J., Slava, M.T. , and Barnett, J.P., "SASE - Standards

Analysis, Synthesis, and Expression Program: User Manual," NBSIR 87-

3514 (Gaithersburg: National Bureau of Standards, 1987).

5. Fenves, S. J. and Wright, R. N. , "The Representation and Use of

Design Specifications," in W. J. Hall (editor). Structural and

Geotechnical Mechanics (Englewood Cliffs, NJ : Prentice-Hall, 1977)

pp. 277-304.

6. Harris, J. R. , Melin, J. W. , and Albarran, C., "Technology for the

Formulation and Expression of Specifications, Volume 2; Program

Users Manual," Civil Engineering Studies . SRS 424 (Urbana: University

of Illinois, 1975).

7. Harris, J. R. , Melin, J. W. , Tavis, R. L. , and Wright, R. N.

,

"Technology for the Formulation and Expression of Specifications,

Volume 1: Final Report," Civil Engineering Studies . SRS 423 (Urbana:

University of Illinois, 1975).

8. Harris, J. R. , Fenves, S. J., and Wright, R. N. , Analysis of

Tentative Seismic Design Provisions for Buildings . NBS TN 1100

(Washington: National Bureau of Standards, 1979).

9. ' Harris, J. R. and Wright, R. N. , Organization of Building Standards:

Systematic Techniques for Scope and Arrangement . BSS 136 (Washington:

National Bureau of Standards, September 1981).

10. Howard, H. C. and Fenves, S. J., "Representation and Comparison of

Design Specifications," Technical Report R-83-141, Department of

Civil Engineering (Pittsburgh: Carnegie-Mellon University, 1983).

11. McDaniel, H., ed. , Applications of Decision Tables (Princeton:

Brandon/Systems Press, 1970).

12. Nyman, D. J., Fenves, S. J., and Wright, R. N., "Restructuring Study

of the American Institute of Steel Construction Specification,"

Civil Engineering Studies 393 (Urbana: University of Illinois, 1973).

13. Nyman, D. J. and Fenves, S. J., "An Organizational Model for Design

Specifications," Technical Report R73-4 (Pittsburgh: Carnegie-Mellon

University, 1973).

119
14. Pollack, S. L. , Hicks, H. T., and Harrison, W. J., Decision Tables:

Theory and Practice (New York: Wiley- Interscience , 1971).

15 . Specification for the Design of Cold Formed Steel Structural Members

(Washington: American Iron and Steel Institute, 1980).

16 . Specifications for the Design. Fabrication, and Erection of

Structural Steel for Buildings (Chicago :• American Institute of Steel

Construction, 1980).

17. Stirk, J. A., "Two Software Aids for Design Specifications Use,"

Master's thesis (Pittsburgh: Carnegie -Mellon University, 1981)

Unpublished M.S, thesis.

18 . Tentative Provisions for the Development of Seismic Regulations for

Buildings . ATC-3-06 (Palo Alto: Applied Technology Council, 1978).

19. Wright, J. R. , "Performance Criteria in Buildings," Scientific

American 224(3) (New York: Scientific American, March 1971) pp . 16-

25.

20. Wright, R. N. , Harris, J. R. , Melin, J, W. , and Albarran, C.

,

"Technology for the Formulation and Expression of Standards, Volume

3: Technical Reference Manual," Civil Engineering Studies . SRS 425

(Urbana: University of Illinois, 1975).

120
APPENDIX A. ANALYSIS OF A STANDARD FOR CONCRETE QUALITY

A . 1 Introduction

To provide a practical demonstration of the SASE methodology for the ra- tional analysis and expression of standards, the results of a study of a standard for concrete quality are presented in this appendix. The subject

standard comprises all of Chapter 4, "Concrete Quality", of the American

Concrete Institute's Building Code Requirements for Reinforced Concrete

CACI 318-77) [1] . Virtually all of the SASE techniques for analyzing and

expressing a standard were applied in the study.

A. 2 Technical approach

The study was conducted in the order of the steps for the rational analysis and expression of an existing standard described in Chapters 3 and 4 of

this report. In stimmary, these steps are to;

1. identify the derived (requirements and determinations) and input

data items in the text of the standard;

2. develop decision tables to model the logic of the requirements and

determinations

;

3. develop a global ingredience network systematically linking the

requirements and determinations contained in the standard;

4. classify the requirements and determinations to determine the

scope of the standard and for outlining and indexing the contents;

and

5. organize logically the contents of the standard.

As described in Chapter 1 of this report, reviewing the subject matter with

experts during the course of analysis and expression was found in the study

to be essential. Such interaction was especially valuable wherever multiple interpretations of the text seemed possible, and where SASE analysts

noted the text of the standard to be ambiguous or incomplete. Particularly

important times for interaction between subject matter experts and SASE

analysts were: (1) after requirements and determinations had been (tentatively) identified and a draft ingredience network had been developed, and

(2) while draft organizational outlines were being developed.

A. 3 Results

The results are presented in this section in the same order as the steps

taken in the study. The figures and tables discussed in this section are grouped at the end of the appendix for easy reference.

121
A. 3.1 Data items

The text of the standard for concrete quality, indicating the location of

individual data items (annotated with datum reference number; see section

A. 3.

3

below), is shown in figure A.l. The derived data items are listed in

SASE- format in figure A. 2 and the input data items are listed in SASEformat in figure A. 3. The notation used includes (see Chapter 3 of this

report)

:

REFE: datum reference number (numbers below 1000 denote derived data

items; those above denote input data items).

NAME: a datum identifier.

SECT: section of the standard containing the datum (delimiting periods omitted)

.

PAGE: page of Chapter 4 of the standard containing the datum.

VALU: boolean for requirements; boolean, boolean vector, or numeric

for determinations.

SOUR: source of the datum, i.e., either input or derived.

TYPE: type of datum, i.e., either decision table or function.

STAT: either classified (linked with at least one classifier) or unclassified.

UTIL: utilization of the datum, i.e.', either requirement or determination.

TITL: text string providing a descriptive title of the datum.

INGREDIENTS: reference numbers of data items ingredient to the datum, or data items upon which the datum is dependent.

ARGUMENTS: reference numbers of classifiers linked to the datum.

EQUIVALENTS: cross references with other data items, by datum refer- ence numbers (not used in the present example)

.

COMMENT: text string containing explanatory information.

The distribution of the data items in the standard (see figure A.l) shows

that the text is not uniformly complex. The subdivision of the text into

numbered paragraphs implies that each paragraph is a discrete unit of

information. In some instances, there is, in fact, a one-to-one correspondence between a datum and a mombered paragraph. On the other hand, in some instances, several data items correspond to a single numbered paragraph,

and, in some instances, a datum corresponds to an entire major heading

encompassing several numbered paragraphs.

122
A. 3.

2

Decision Tables

Any datum of type REQUIREMENT may be expressed as a decision table, and

with the use of this aid may be analyzed for completeness and clarity. The

general form for a decision table representation of a datum is discussed in

section 3.3 of this report. The decision table for a requirement datum

specifies a set of conditions (each of which may be true, false, or irrelevant during the evaluation of the datum), combinations of which (i.e.,

rules) yield either of two actions: that the requirement is satisfied or violated. In practice, requirements with only a single condition frequently are found in the text of a standard. One example found in the text

of figure A.l is: "Requirement for the specification of concrete strength

on design drawings," datum reference number 10. The single condition here

is whether or not concrete strength has in fact been specified on the

drawings. If it has, then the requirement is satisfied. If not, then the

requirement is violated. The analysis of such a requirement's completeness

and clarity would not be enhanced by the development of a decision table.

For this reason, decision tables were developed in this study only for data

items with two or more conditions.

Data items of type DETERMINATION also may be expressed as decision tables.

Unlike tables for REQUIREMENT data items, however, rules in DETERMINATION

tables may yield actions that return numerical or nominal values. An exam- ple is the "determination of standard deviation," datum reference number

70. In this example, rules 1 and 2 yield the nominal scalar value: "standard deviation computed by statistics." The standard deviation is not defined for any other rule.

Once entered in SASE, the decision tables were analyzed by generating

decision trees. This analysis checked the decision tables for logical

consistency. In addition, this analysis determined explicitly the else

rules associated with each decision table. A list of all possible combinations of conditions leading to the else rule in a decision table is very

helpful to the SASE analyst in determining whether the corresponding provision is complete in its scope. The decision tables for the standard for

concrete quality are presented in SASE-format in tables A.l to A. 11, along

with their associated tables of else rules as generated by SASE.

A. 3.

3

Global ingredience

Once the individual data items were entered into SASE along with their

ingredient data items, the global ingredience network was generated to

thread all the data items together. Figure A. 4 displays the global ingredience network for the standard for concrete quality arranged in order of

the requirements

.

An exploded segment of the global ingredience network is displayed in

figure A. 5 to provide a guide to the interpretation of a SASE-generated

network. Datum 181 is the only output requirement in this segment and lies

at level 0 in the network. Datum 182 is a direct ingredient of this output

requirement and lies at level 1. Datum 60 is also a direct ingredient of

123
the output requirement but, perhaps counter-intuitively, it lies at level

2. A property of the algorithm that displays networks in SASE is that first

the innermost level at which each datum lies anywhere in the network is

determined and then each datum is displayed at this innermost level everywhere it appears in the network. Thus, datum 60, which is a direct ingredient of the output requirement lies at level 2 in the network because that

is the innermost level it occupies as a consequence of being a direct

ingredient of dattim 182 also. This level- spanning property of the display

algorithm results in a network that is easier -for a SASE analyst to assess

in terms of flows of information.

Figure A. 5 also illustrates the SASE notation for network entries. The

reference number in the second (and any following) occurance of datum 60 is

preceded by a minus (-) sign to indicate that this datum has occured before

in the display of the network. The asterisk (*) following the reference

number in its second (and any following) occurance indicates that datum 60

has ingredient data items and that these have been listed previously in the

display of the network.

A. 3. 4. Classification and scope

The ability to access relevant information in a standard depends on the

clarity and completeness of the classification scheme used to organize the

standard. The basic elements of the classification scheme are the classifiers , which denote the entities and attributes pertinent to the data items

in the standard. Section 4.1 of this report treats classification in

detail. Classifiers appropriate for accessing information in the standard

for concrete quality are listed in figure A. 6. The notation used includes

(see Chapter 4 of this report)

:

REFE: classifier reference number.

NAME: a character string used to identify the classifier.

TYPE: ACT(ive) denotes that the classifier will be displayed in an Outline; no entry indicates that the classifier will not be

displayed.

PARE: specifies the reference number of the single classifier which

is the parent of the current classifier in the facet (see

Chapter 4 of this report)

.

TITL: text string providing the full classifier name.

FOSTER: specifies the reference numbers of multiple parents in

different fields (see Chapter 4 of this report)

.

COMMENT: additional explanatory notes.

The scope of the standard is established once pertinent classifiers have

been assigned as arguments to all the data items. The scope is this set of

pertinent classifiers. The SASE-generated scopelist for the standard for

124
concrete quality is given in figure A. 7. The scopelist is displayed in the

numerical order of the classifiers. Another convenient way to illustrate

the scope of the chapter is by means of an index, which is displayed in the

alphabetical order of the classifiers. The SASE-generated index for the

standard for concrete quality is given in figure A. 8. In both the scopelist and index, the data items associated with any single classifier are listed in datum reference number sequence.

A. 3. 5 Organization

This study of the standard for concrete quality sought not only to analyze

the text of the standard in terms of its technical content but also to

illustrate the utility of SASE in manipulating the organization of the text

without modifying the technical contents. As described in Chapter 4 of

this report, SASE enables the user to organize trees of classifiers that

will produce the desired information structure (which may vary depending on

the user's view and requirements of this information). Once the user has

established a structured organization of classifiers, SASE can generate a full outline. The outline expresses the organization, and also displays

the data items associated with the various classifiers. A SASE-generated

outline for the standard for concrete quality is shown in figure A. 9.

Comparison of this outline with the text in figure A.l will show that their

arrangements differ. The outline shown here is based on a revised organization for the standard suggested by the analysis of its technical con- tents .

A. 4 Enhanced understanding of a standard through SASE-based analysis

During this study the analysts consulted subject matter experts to ascer- tain that the technical content of the standard was interpreted properly,

and to check the correctness and usefulness of the SASE-based analysis.

Chief among the experts consulted was the chairman of the ACI committee

responsible for Chapter 4 "Concrete Quality" of the ACI 318 standard.

Several questions and recommendations for clarifying aspects of this chapter, following from the SASE-based analysis, were revealed in the consultations. In particular:

1. Section 4.1.1 says that the overall scope of Chapter 4 is to

minimize the frequency of strength tests falling below f'c. However, this objective is not a requirement of any provision of the

chapter. A more accurate statement of the chapter's scope may be:

to realize the intentions of the designer, i.e., to achieve the

specified f'c in the structure.

2. Chapter 4 does not provide for the proportions of the entire mix,

and only stipulates requirements for water-cement ratio.

3. A clause within section 4.4.3 concerning the required average test

strength of concrete from a facility without an adequate record is

simply a restatement of a clause appearing within section 4.3.1.

The clause seems irrelevant to the remainder of section 4.4.3, and

125
in this instance, the redundancy may be a source of confusion for

the user of the standard.

4. Having defined required average test strength of concrete, Chapter

4 never requires its use.

5. Section 4.5.1 specifies that where suitable data from field tests

or laboratory trial batches are not available, permission to base

concrete proportions on water-cement -ratio limits may be granted.

However, the provision does not specify who may grant such permission. Two possible choices are the project engineer and the

building official.

6. The clarity of Chapter 4 would be enhanced through the use of a symbolic representation for required average compressive strength,

namely f'cr, which is used only in the accompanying commentary.

7. Chapter 4 should provide an explicit method for computing f'cr

used as a basis for selecting concrete proportions. Equations 4-1

and 4-2 in the accompanying commentary provide such a method.

8. Chapter 4 lacks a definition of sufficiency of data required to

justify reducing target compressive strength.

The reader is invited to study Chapter 4 "Concrete Quality" of the 1983

edition [2] of the ACI 318 standard and compare it with the results of this

study to see how some of the above questions and recommendations have been

addressed.

REFERENCES

[1] Building Code Requirements for Reinforced Concrete (ACI 318-77") . (Detroit: American Concrete Institute, 1977).

[2] Building Code Requirements for Reinforced Concrete (ACI 318-83) . (Detroit: American Concrete Institute, 1983).

126
PART 3 -CONSTRUCTION REQUIREMENTS

CHAPTER 4 - CONCRETE QUALITY

4.0 • Notation s specified compressive strength of concrete, psi s average splitting tensile strength of

lightweight aggregate concrete, psi

4.1 - General

4.1.1 > Concrete shall be proportioned and

produced to provide an average compressive

strength sufficiently high to minimize frequency

of strength tests below the value of the specified

compressive strength of concrete, See Sections 4.3.1 and 4.8.2.3.

01

10

20

30

40

4.1.2 - Requirements for f; shall be based on tests of cylinders made and tested as prescribed in Section 4.8.

4.1.3 - Unless otherwise specified, f; shall be

based on 28-day tests. For high-early-strength concrete, the test age for f; shall be as indicated

In the design drawings or specifications.

4.1.4 - Design drawings submitted for approval or used for any project shall show the specified

compressive strength of concrete f; for which

each part of the structure is designed.

4.1.5 -Where design criteria in Sections 9.S.2.3, 11.2 and 12.2.3(c) provide for use of a splitting tensile strength value of concrete, laboratory tests shall be made in accordance with

“Specifications for Lightweight Aggregates for Structural Concrete" (ASTM C 330) to establish value of fc corresponding to specified value of

4.1.6 - Splitting tensile strength tests Shan not be

used as a basis for field acceptance of concrete.

4.2 - Selection of concrete proportions

4.2.1 - Proportions of materials for concrete shall be established to provide;

(a) Adequate workability and proper consistency to permit concrete to be worked

readily into the forms and around reinforcement under conditions of placement to be employed,

without excessive segregation or bleeding

(b) Resistance to freezing and thawing and

other aggressive actions, as required by Section 4.6

(c) Conformance with strength test requirements of Section 4.8

4.2.2 - Where different materials are to be used for different portions of the work, each combination

shall be evaluated separately.

4.2.3 - Concrete proportions, including water- cement ratio, shall be established on the basis of

field experience (Section 4.3) or laboratory trial batches (Section 4.4) with materials to be employed, except as permitted in Section 4.5 or required by Section 4.6.

4.3 - Proportioning on the basis of field experience

4.3.1 - Where a concrete production facility has a

record, based on at least 30 consecutive strength

tests that represent similar materials and conditions to those expected, required average compressive strength used as the basis for selecting concrete proportions shall exceed

required at designated test age by at least 400 psi if standard deviation Is les? than 300 psi 550 psi if standard deviation is 3(X) to 4(X) psi 700 psi if standard deviation is 400 to 500 psi

900 psi If standard deviation is 5(X) to 6(X} psi

If standard deviation exceeds 600 psi, concrete

proportions shall be selected to produce an

average strength at least 1200 psi greater than

required ___

4.3.2 - Strength test data for determining standard

deviation shall be considered to comply with Section 4.3.1 if data represents either a group of at least 30 consecutive tests or a statistical average

for two groups totaling 30 or more tests.

4.3.3 - Strength tests used to establish standard

deviation shall represent concrete produced to meet a specified strength or strengths within 1000

psi of that specified for the proposed work.

4.3.4 - Changes In materials and proportions within the population of background tests used to establish standard deviation shall not have been more closely restricted than for the proposed

work.

60

70

Figure A.l Text of a standard for concrete quality [1] with datum

reference numbers annotated in the margins.

127
TABLE 4.5 — MAXIMUM PERMISSIBLE WATER-CEMENT RATIOS FOR CONCRETE WHEN STRENGTH

DATA FROM TRIAL BATCHES OR FIELD EXPERIENCE ARE NOT AVAILABLE

Maiimum oermisslble w«tef cement ratio Nor>.«ir.entrainad Air-entrained concrete CO ncrete

SpecifM

eompressivtt Absolut* U.S gal. p*r Absolute U.S. gal. per

ftren(j-.n. ratio by 04-ib bag ratio by 04-lb bag

arsight ol catnant weigbt of cement

2500 0.67 7.6 0.54 6.1 3000 0.56 6.6 0.46 5.2 3500 0.51 54 0.40 4.5 4000 0.44 5.0 0J5 4.0 4500 0J8 4.3 t T 5000 t t t 1

wrwnqm Witn mo«f r«i«* Mvnwill a</9ng» BtfWAQmB 9>w<»c man mojcctad tn taciion 4^1 aaftaing WBquaad %Pm tmngma a&oia 4500 pai (non a*» awtrawad eoncrata) and 4000 pm» da»9ninmma oonemai pfpoortona aftaii ba aataeiiaM bv twamadi of iBctwat 4Jor4^

4.4 > Proportioning by laboratory trial batches

4.4.1 - When laboratory trial batches are used as

the basis for selecting concrete proportions,

strength tests shall be made in accordance with "Method of Test for Compressive Strength of Cylindrical Concrete Specimens" (ASTM C 39) on

cylinders prepared in accordance with "Method of Making and Curing Test Specimens in the Laboratory” (ASTM C 192).

4.4.2 - When laboratory trial batches are made, air content shall be within ±0.5 percent and slump

182 within ±0.75 in. of maximums permitted by the

specifications.

4.4.3 -A curve shall be established showing

relationship between water-cement ratio (or cement content) and compressive strength. Curve

shall be based on at least three points

representing batches which produce strengths

above and below required average compressive

strength specified in Section 4.3.1. If concrete

construction facility does not have a record based on 30 consecutive strength tests representing

simitar materials and conditions to those ex- pected, required average compressive strength

shall be 1200 psi greater than f;. Each point shall represent the average of at least three cylinders tested at 28 days or the specified earlier age.

4.4.4 - Maximum permissible water<ement ratio

(or minimum cement content) for concrete to be

181 used in the structure shall be that shown by the curve to produce the average strength indicated in Section 4.3.1 or 4.4.3 unless a lower water-cement

ratio or higher strength is required by Section 4.6.

200

4.5 - Proportioning by water-cement ratio

4.5.1 - If suitable data from a record of 30 consecutive tests (Section 4.3) or from laboratory trial

batches (Section 4.4) are not available, permission

may be granted to base concrete proportions on watercement ratio limits in Table 4.5.

4.5.2 - Table 4.5 shall be used only for concrete to be made with cements meeting strength

requirements for Types I, lA, !l, IIA, III, IIIA, or V of “Specification for Portland Cement" (ASTM

C 150), or Types IS, IS-A, IS(MS). IS-A(MS), IP, IP-A, or P of "Specification for Blended Hydraulic

Cements," (ASTM C 595), and shall not be applied

to concrete containing lightweight aggregates or admixtures other than those for entraining air.

4.5.3 - Concrete proportioned by water-cement

ratio limits prescribed in Table 4.5 shall also conform to special exposure requirements of Section 4.6 and to compressive strength test

criteria of Section 4.8.

4.6 - Special exposure requirements

4.6.1 - Concrete that, after curing, will be exposed I to freezing temperatures while wet shall contain

entrained air within limits of Table 4.6.1, and in I addition: i.i.l

4.8.1.1-

For concrete made with normal weight

aggregate, water-cement ratio shall not exceed

0.53 by weight.

4.6.1.2-

For concrete made with lightweight

aggregate, specified compressive strength f; shall be at least 3000 psi.

230

250

240

TABLE 4.6.1 — CONCRETE AIR CONTENT FOR

VARIOUS SIZES OF COARSE AGGREGATE

Nominal maximum

aizeof coarae

aggregate. In. Total air content, percent by volume 3A etoto StoO

3/4 4to8

1 iJSiotJS

1 1/2 3 to 6

2 2.5 toSA

3 1Jto4.5

Figure A.l Text, continued

128
260

261

270

271

282

280

281

290

4.6.2 - Concrete that is intended to be watertight

shall conform to the following:

4.6.2.1 - For concrete made with normal weight

aggregate, water-cement ratio shall not exceed

0.50 by weight for exposure to fresh water and

0.45 by weight for exposure to seawater.

4.6.2.2 - For concrete made with lightweight

aggregate, specified compressive strength f; shall be at least 3750 psi for exposure to fresh water and 4000 psi for exposure to seawater.

4.6.d - Concrete that will be exposed to injurious concentrations of sulfate-containing solutions

shall be made with sulfate-resisting cement, and

In addition:

4.6.3.1 - For concrete made with normal weight

aggregate, water-cement ratio shall not exceed

0.50 by weight.

4.6.3J2 - For concrete made with lightweight

aggregate, specified compressive strength

shall be at least 3750 psi.

4.7 - Average strength reduction

After sufficient test data become available from

the job, methods of "Recommended Practice for Evaluation of Compression Test Results of Concrete (ACI 214-65)" may be used to reduce the amount by which the average strength must ex- ceed fc below that indicated in Section 4.3.1 provided:

(a) Probable frequency of strength tests more

than 500 psi below f. will not exceed 1 in 100,

(b) Probable frequency of an average of three consecutive strength tests below f; will not exceed 1 in 100, and

(c) Special exposure requirements of Section

4.6 are met.

4.8 - Evaluation and acceptance of

concrete

4.8.1 - Frequency of testing

4.8.1.1 - Samples for strength tests of each class

of concrete placed each day shall be taken not

less than once a day, nor less than once for each

ISO cu yd of concrete, nor less than once for each

5000 sq ft of surface area for slabs or walls. 4J.1.2~On a given project, If total volume of concrete 1s such that frequency of testing

required by Section 4.B.1.1 would provide less than five strength tests for a given class of concrete, tests shall be made from at least five ran- domly selected batches or from each batch If fewer than five batches are used.

4.8.1.3-When total quantity of a given class of concrete is less than 50 cu yd, strength tests may

be waived by the Building Official, If in his judgment adequate evidence of satisfactory

strength is provided.

4.B.1.4- Average strength of two cylinders from

the same sample, tested at 28 days or the

specified earlier age, is required for each strength

test.

4.8.2 - Tests of laboratory-cured specimens

4.8.2.1 - Samples for strength tests shall be taken

in accordance with “Method of Sampling Fresh Concrete" (ASTM C 172).

4.8.2.2- Cylinders for strength tests shall be

molded and laboratory-cured in accordance with “Method of Making and Curing Concrete Test Specimens in the Field" (ASTM C 31) and tested In accordance with “Method of Test for Compressive Strength of Cylindrical Concrete Specimens" (ASTM C 39).

330

340

350

4.B.2.3- Strength level of an individual class of concrete shall be considered satisfactory if both

of the following requirements are met:

(a) The average of all sets of three consecutive

strength tests equal or exceed required

(b) No individual strength test (average of two

cylinders) falls below required by more than 500 psi.

4.5.2.4 - If either of the requirements of Section

4.B.2.3 are not met, steps shall be taken Im- mediately to increase the average of subsequent

strength test results. Additionally, requirements

of Section 4.8.4 shall be observed If the requirement of Section 4.8.2.3(b) is not met. _____

4.8.3 — Tests of field-cured specimens

4.8.3.1 -The Building Official may require

strength tests of cylinders cured under field conditions to check adequacy of curing and

protection of concrete In the structure.

4.8.3.2 - Field-cured cylinders shall be cured under field conditions in accordance with Section

7.4 of “Method of Making and Curing Concrete

Test Specimens in the Field" (ASTM C 31).

370

380

420

4.B.3.3 - Field-cured test cylinders shall be

molded at the same time and from the same

aamples as laboratory-cured test cylinders.

4.B.3.4 - Procedures for protecting and curing concrete shall be improved when strength of field- cured cylinders at the test age designated for measuring f; Is less than 85 percent of that of companion laboratory-cured cylinders. When

Figure A.l Text, continued.

129
381

400

laboratory-cured cylinder strengths are ap- preciably higher than ti, field-cured cylinder

strengths need not esceed by more than 500 psi even though the 65 percent criterion is not met.

4.8.4

- Investigation of low-strength test results

4.8.4.1-lf any strength test (Section 4.8.1.4) of laboratory-cured cylinders falls below required ti by more than 5(X) psi [Section 4.8.2.3(b)] or If tests

of field-cured cylinders indicate deficiencies In protection and curing, steps shall be taken to assure that load-carrying capacity of the structure

is not jeopardized.

4.S.4.2 - If the likelihood of low-strength concrete

is confirmed and computations indicate that ioad- carrying capacity may have been significantly

reduced, tests of cores drilled from the area In question may be required in accordance with “Method of Obtaining and Testing Drilled Cores

and Sawed Beams of Concrete" (ASTM C 42). In such case, three cores shall be taken for each

strength test more than 500 psi below required ti.

4.8.4.3-lf concrete in the structure will be dry

under service conditions, cores shall be air dried (temperature 60 to 80 F, relative humidity less than 60 percent) for 7 days before test and shall be

tested dry. If concrete in the structure will be more than superficially wet under service conditions, cores shall be immersed in water for at least 48 hr and be tested wet.

4.8.4.4

- Concrete in an area represented by core

tests shall be considered structurally adequate if the average of three cores is equal to at least 85

percent of ti and if no single core is less than 75

percent of f;. To check testing accuracy, locations represented by erratic core strengths may be

retested.

4.8.4.S - If criteria of Section 4.8.4.4 are not met, and if structural adequacy remains in doubt, the responsible authority may order load tests as

outlined in Chapter 20 for the questionable portion of the structure, or take other action ap- propriate to the circumstances.

Figure A.l Text, concluded.

400

410

130
REFE NAME SECT PAGE VALU SOUR

1 RSTA S413 13 BOOL DERI

TITLE : STRNTH TESTS SHALL BE CONDUCTED

INGREDIENTS : 1000 1010

ARGUMENT: 14 65

EQUIVALENTS : COMMENT

:

TYPE STAT UTIL

TABL CLAS REQU

AT SPECIFIED AGE

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

10 SCSD S414 13 BOOL DERI CLAS REQU

TITLE : REQ FOR SPEC OF CONCRETE STRNTH ON DES DRAWING

INGREDIENTS: 1500

ARGUMENT

:

59 74

EQUIVALENTS

COMMENT

:

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

20 FCT S415 13 BOOL DERI TABL CLAS REQU

TITLE : REQ EST VAL OF F(CT) CORRES TO SPEC VAL OF F'C

INGREDIENTS 1020 1030

ARGUMENT

:

15 74

EQUIVALENTS

COMMENT

:

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

30 STS S416 13 BOOL DERI CLAS REQU

TITLE : REQ NOT ACC CONC ON BASIS OF SPLIT TENSILE STRNTH

INGREDIENTS 1510

ARGUMENT

:

15 74

EQUIVALENTS

COMMENT

:

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

40 WCC S421 13 BOOL DERI CLAS REQU

TITLE : REQ TO PROP FOR ADEQ WORKABILITY & CONSISTENCY

INGREDIENTS 1520

ARGUMENT

:

09 06

EQUIVALENTS

COMMENT

:

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

60 DATS S431 13 NUME DERI TABL CLAS DETE

TITLE : DET OF REQUIRED AVG TEST STRNTH BY FIELD EXP

INGREDIENTS 1040 70

ARGUMENT

:

04 06

EQUIVALENTS : COMMENT

:

Figure A. 2 SASE-generated listing of derived data items for

a standard for concrete quality.

131
REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

70 ARG4 S432 13 NUME DERI TABL CLAS DETE

TITLE : DET OF STD DEV OF STRENGTH TEST DATA

INGREDIENTS: 1050 1290 1300

ARGUMENT: 04 06

EQUIVALENTS : COMMENT

:

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

181 S444 BOOL DERI CLAS REQU

TITLE : REQ THAT LTB W/C RAT YIELDS AVG TEST STR IN 60

INGREDIENTS: 182 60

ARGUMENT: 06 63

EQUIVALENTS : COMMENT: REQUIREMENT THAT LTB WATER-CEMENT RATIO YIELDS AVG T

EST STIPULATED IN DATUM 60

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

182 S444 NUME DERI TABL CLAS DETE

TITLE : DET OF STR CORR TO W/C RATIO OF LTB

INGREDIENTS: 1060 1070 1080 1090 60

ARGUMENT: 06 63

EQUIVALENTS : COMMENT: DETERMINATION OF STRENGTH CORRESPONDING TO WATER- CEM

ENT RATIO OF LAB -TRIAL BATCH

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

200 CEMT S461 14 BOOL DERI TABL CLAS REQU

TITLE : REQ FOR MAX PERMISSIBLE W/C RATIO BY TABLE 4.5

INGREDIENTS : 1100 1110 1120 1130

ARGUMENT: 06 63

EQUIVALENTS : COMMENT

:

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

230 ENAC S461 14 BOOL DERI CLAS REQU

TITLE : CONC EXPOSED TO FREEZ AIR CONT PER TBL 4.6.1

INGREDIENTS: 1530 1540

ARGUMENT: 11 70

EQUIVALENTS : COMMENT: CONCRETE EXPOSED TO FREEZING WHEN WET SHALL HAVE AN

AIR CONTENT IN ACCORD WITH TABLE 4.6.1.

Figure A. 2 SASE-generated listing of derived data items, continued.

132
REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

240 CEFT S461 14 BOOL DERI CLAS REQU

TITLE : CONC EXP TO FREEZ-MADE OF LT WT AGG-F' C>=3000PSI

INGREDIENTS: 1120 1530 1550

ARGUMENT: 11 70

EQUIVALENTS : COMMENT: CONCRETE EXPOSED TO FREEZING WHEN WET & MADE OF LIGH

T WEIGHT AGGREGATE SHALL HAVE F' C <= 3000 PSI

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

250 RCEF S461 14 BOOL DERI CLAS REQU

TITLE : CONC EXP FREEZ-NORM WT AGG-W/C RATIO >0.83

INGREDIENTS: 1530 1120 1560

ARGUMENT: 11 70

EQUIVALENTS : COMMENT: CONCRETE EXPOSED TO FREEZING WHEN WET AND MADE OF NO

RMAL WEIGHT AGGREGATE SHALL HAVE A W/C RATIO NOT EXCE

EDING .83

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

260 FRWA S462 15 BOOL DERI CLAS REQU

TITLE : CONC NORM WT AGG EXPOSED FRESH H20-W/C RATIO<0 .

5

INGREDIENTS : 1120 1570 1580 1560

ARGUMENT: 13 70

EQUIVALENTS : COMMENT: CONCRETE OF NORMAL WEIGHT AGGREGATE EXPOSED TO FRESH

WATER AND INTENDED TO BE WATER TIGHT SHALL HAVE A W/C

RATIO < .5

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

261 SEWA S462 15 BOOL DERI CLAS REQU

TITLE : CONC NORM WT AGG EXPOSED SEA H20-W/C RATIO<=0.45

INGREDIENTS : 1120 1570 1580 1560

ARGUMENT: 13 70

EQUIVALENTS : COMMENT: CONCRETE OF NORMAL WEIGHT AGGREGATE EXPOSED TO SEA W

ATER AND INTENDED TO BE WATERTIGHT SHALL HAVE A W/C R

ATIO <= .45

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

270 WTCF S462 15 BOOL DERI CLAS REQU

TITLE : CONC LT WT AGG EXPOSED FRESH H20-F'C >= 3750PSI

INGREDIENTS: 1120 1550 1570 1580

ARGUMENT: 13 70

EQUIVALENTS : COMMENT: CONCRETE OF LIGHT WEIGHT AGGREGATE EXPOSED TO FRESH

WATER INTENDED TO BE WATERTIGHT SHALL HAVE F'C >= 37

50 PSI

Figure A. 2 SASE-generated listing of derived data items, continued.

133
REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

271 WTCS S462 15 BOOL DERI CLAS REQU

TITLE : CONC LT WT AGG EXPOSED SEA H20-F'C >=4000 PSI

INGREDIENTS : 1120 1550 1570 1580

ARGUMENT: 13 70

EQUIVALENTS : COMMENT: CONCRETE OF LIGHT WEIGHT AGGREGATE EXPOSED TO SEA WA

TER AND INTENDED TO BE WATERTIGHT SHALL HAVE F'C >= 4

000 PSI

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

280 SERI S463 15 BOOL DERI CLAS REQU

TITLE : CONC NORM WT AGG EXPOS TO SULFATE-W/C RATI0<=0 .

5

INGREDIENTS: 1590 1120 1560

ARGUMENT: 39 70

EQUIVALENTS : COMMENT: CONCRETE MADE OF NORMAL WEIGHT AGGREGATE AND EXPOSED

TO SULFATE SHALL HAVE A W/C RATIO <= .5

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

281 SER2 S463 15 BOOL DERI CLAS REQU

TITLE : CONC LT WT AGG EXPOSED TO SULFATE-F'C >=3750 PSI

INGREDIENTS : 1120 1550 1590

ARGUMENT: 39 70

EQUIVALENTS : COMMENT: CONCRETE MADE OF LIGHT WEIGHT AGGREGATE AND EXPOSED

TO SULFATE SHALL HAVE F’C >= 3750 PSI

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

282 SER3 S463 15 BOOL DERI CLAS REQU

TITLE : CONC EXPOSED INJ SULFATE MADE W. SULFATE-RES CEM

INGREDIENTS: 1590 1110

ARGUMENT: 39 70

EQUIVALENTS : COMMENT: CONCRETE EXPOSED TO INJURIOUS CONCENTRATIONS OF SULF

ATE CONTAINING SOLUTIONS SHALL BE MADE WITH SULFATE -R

ISTING CEMENT

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

290 AASR S47 15 BOOL DERI TABL CLAS REQU

TITLE : REQ FOR PERMIS REDUCTN IN REQ'D AVG TEST STRNGTH

INGREDIENTS: 1140 1150 1160 1250 1251

ARGUMENT: 04 06

EQUIVALENTS : COMMENT

Figure A. 2 SASE-generated listing of derived data items, continued.

134
REFE NAME SECT PAGE VALU SOUR TYPE

300 STS S481 15 BOOL DERI TABL

TITLE : SAMPLE STR TESTS FOR EACH CIASS OF CONC

INGREDIENTS : 1170 1180 1190 1200 1210

ARGUMENT: 42 65 41

EQUIVALENTS : COMMENT: ENCOMPASSES SECTIONS 4. 8. 1.1 THROUGH 4

STAT UTIL

CLAS REQU

REQ FREQ

8.1.4

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

330 SLCS S482 15 BOOL DERI ClAS REQU

TITLE : SAMPLES FOR STR TESTS TAKEN IN ACCORD ASTM C172

INGREDIENTS : 1600

ARGUMENT: 43 41 65

EQUIVALENTS : COMMENT

:

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

340 MSTS S482 15 BOOL DERI CLAS REQU

TITLE : CYL MOLDED & LAB CURED IN ACCORD WITH ASTM C31

INGREDIENTS: 1610

ARGUMENT: 07 41 65

EQUIVALENTS : COMMENT: CYLINDERS FOR STRENGTH TESTS OF LABORATORY CURED SPE

CIMENS SHALL BE MOLDED AND LAB CURED IN ACCORD WITH A

STM C31

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

350 CCST S482 15 BOOL DERI CLAS REQU

TITLE : CYL STR TEST LAB CURED SPEC TESTED PER ASTM C39

INGREDIENTS: 1090

ARGUMENT: 55 65

EQUIVALENTS : COMMENT: CYLINDERS FOR STRENGTH TESTS OF LABORATORY CURED SPE

CIMENS SHALL BE TESTED IN ACCORD WITH ASTM C39

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

370 ASL S482 15 BOOL DERI TABL CLAS REQU

TITLE : ACCEPT OF STR LEVELS BASED ON LAB -CURED CYL

INGREDIENTS : 1140 1220 1250 1251 1550

ARGUMENT: 55 65

EQUIVALENTS : COMMENT: PERTAINS ALSO TO SECTION 4. 8. 3.

4

Figure A. 2 SASE-generated listing of derived data items, continued.

135
REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

380 RAl S482 15 BOOL DERI CLAS REQU

TITLE : SOMEONE SHALL TAKE STEPS TO INCREASE STR OF CONC

INGREDIENTS: 370

ARGUMENT: 48 65

EQUIVALENTS : COMMENT

:

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

381 RA2 S484 15 BOOL DERI CLAS REQU

TITLE : SOMEONE SHALL TAKE STEPS -LD CAP NOT JEOPARDIZED

INGREDIENTS: 370 420

ARGUMENT: 48 65

EQUIVALENTS : COMMENT: SOMEONE SHALL TAKE STEPS TO ASSURE THAT LOAD CARRYIN

G CAPACITY IS NOT JEOPARDIZED IF 4.8.2.3(B) ISN'T MET

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

400 SBCT S484 15 BOOL DERI TABL CLAS REQU

TITLE : ACCEPT OF IN SITU STR BASED ON CORE TESTS

INGREDIENTS: 1260 1270 1271 1280 1550

ARGUMENT: 52 53 65

EQUIVALENTS : COMMENT: FROM SECTION 4. 8. 4,

2

THROUGH 4. 8. 4.

4

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

410 LT S484 16 BOOL DERI CLAS REQU

TITLE : DEC BY BLDG OFFL TO ORDER LD TESTS OR OTHER REQ

INGREDIENTS: 400 1620

ARGUMENT: 51 53 65

EQUIVALENTS : COMMENT: IF STRUCTURAL ADEQUACY REMAINS IN DOUBT, DECISION BY

BUILDING OFFICIAL TO ORDER LOAD TESTS OR TAKE OTHER A

PPROPRIATE ACTIONS IS REQUIRED.

REFE NAME SECT PAGE VALU SOUR TYPE STAT UTIL

420 PROC S483 16 DERI TABL CLAS REQU

TITLE : PROC FOR PROT & CURING CONC SHALL BE ADEQUATE

INGREDIENTS: 1230 1240 1250 1310 1550

ARGUMENT: 51 53 65

EQUIVALENTS : COMMENT: PROCEDURES FOR PROTECTING AND CURING CONCRETE IN THE

STRUCTURE SHALL BE ADEQUATE

Figure A. 2 SASE- generated listing of derived data items, concluded.

136
REFE NAME SOUR TITL

1000 ICON INPU TYPE OF CONCRETE

REFE NAME SOUR TITL

1010 AGE INPU TEST AGE

REFE NAME SOUR TITL

1020 FCT INPU VALUE OF F(CT)

REFE NAME SOUR TITL

1030 LABT INPU LAB TEST CONDUCT

REFE NAME SOUR TITL

1040 STDV INPU STD DEVIATION OF STR TEST DATA

REFE NAME SOUR TITL

1050 RDAT INPU REPRESENTIVENESS OF STRENGTH TEST DATA

REFE NAME SOUR TITL

1060 LTBT INPU PREPARATION OF LTB TEST SPECIMENS

REFE NAME SOUR TITL

1070 LTAI INPU LTB AIR CONTENT

REFE NAME SOUR TITL

1080 LTSL INPU LTB SLUMP

REFE NAME SOUR TITL

1090 LTBT INPU LTB TEST PROCEDURE

REFE NAME SOUR TITL

1100 PPWC INPU PERMISSION TO BASE PROPORTIONS ON W/C RATIO

REFE NAME SOUR TITL

1110 TCEM INPU TYPE OF CEMENT

REFE NAME SOUR TITL

1120 TAGG INPU TYPE OF AGGREGATE

REFE NAME SOUR TITL

1130 TADM INPU TYPE OF ADMIXTURE

REFE NAME SOUR TITL

1140 QDAT INPU QUALITY OF TEST DATA PER ACI214-65

Figure A. 3 SASE- generated listing of input data items for

a standard for concrete quality.

137
REFE

1150

NAME

PITS

SOUR

INPU

TITL

PROBABILITY (STRENGTH < F’C - 500)

REFE

1160

NAME

P3TS

SOUR

INPU

TITL

PROBABILITY (AVG OF 3 STRENGTH TESTS < F'C)

REFE

1170

NAME

QUAN

SOUR

INPU

TITL

TOTAL QUANTITY OF CONCRETE PLACED

REFE

1180

NAME

APPR

SOUR

INPU

TITL

BUILDING officials’ APPROVAL OF STRENGTH

REFE

1190

NAME

STSA

SOUR

INPU

TITL

STRENGTH TEST SAMPLING

REFE

1200

NAME

TSNU

SOUR

INPU

TITL

NUMBER OF TESTS PER CLASS OF CONCRETE

REFE

1210

NAME

BCHN

SOUR

INPU

TITL

NUMBER OF BATCHES PER CLASS OF CONCRETE

REFE

1220

NAME

LOTS

SOUR

INPU

TITL

NUMBER OF TESTS < (F’C - 500)

REFE

1230

NAME

RTFC

SOUR

INPU

TITL

REQ FOR STRENGTH TEST OF FIELD CURED CYLINDE

REFE

1240

NAME

MCFC

SOUR

INPU

TITL

METHOD OF MOLDING AND CURING FIELD CURED CYL

REFE

1250

NAME

TSLC

SOUR

INPU

TITL

TEST STRENGTH OF LAB CURED CYLINDERS

REFE

1251

NAME

ACST

SOUR

INPU

TITL

AVG OF 3 CONSECUTIVE STR TESTS OF LAB CURED

REFE

1260

NAME

MOTC

SOUR

INPU

TITL

METHOD OF OBTAINING AND TESTING CORES

REFE

1270

NAME

NUMC

SOUR

INPU

TITL

NUMBER OF CORES PER LOW STRENGTH TEST

REFE

1271

NAME

GTS

SOUR

INPU

TITL

CORE TEST STRENGTH

REFE

1280

NAME

CTSA

SOUR

INPU

TITL

3 CORE TEST STRENGTH AVERAGE

Figure A. 3 SASE- generated listing of input data items, continued.

138
REFE NAME SOUR TITL

1290 PREV INPU PREVIOUSLY SPECIFIED F'C

REFE NAME SOUR TITL

1300 BMP INPU BACKGROUND MATERIALS AND PROPORTIONING

REFE NAME SOUR TITL

1310 TSFC INPU TEST STRENGTH OF FIELD -CURED CYLINDERS

REFE NAME SOUR TITL

1500 SPFC INPU SPECIFICATION OF F'C ON DESIGN DRAWINGS

REFE NAME SOUR TITL

1510 CFCT INPU CRITERIA FOR USE OF F(CT)

REFE NAME SOUR TITL

1520 W&C INPU WORKABILITY AND CONSISTENCY

REFE NAME SOUR TITL

1530 FRX INPU EXPOSURE TO FREEZING

REFE NAME SOUR TITL

1540 AC INPU AIR CONTENT

REFE NAME SOUR TITL

1550 VFC INPU VALUE OF SPECIFIED F'C

REFE NAME SOUR TITL

1560 WCR INPU W/C RATIO

REFE NAME SOUR TITL

1570 TWX INPU TYPE OF WATER EXPOSURE

REFE NAME SOUR TITL

1580 INT INPU INTENTION FOR WATER TIGHTNESS

REFE NAME SOUR TITL

1590 SX INPU SULFATE EXPOSURE

REFE NAME SOUR TITL

1600 INPU METHOD OF SAMPLING FRESH CONCRETE

REFE NAME SOUR TITL

1610 MMCC INPU METH OF MAKING & CURING CONC TEST SPEC IN FI

REFE NAME SOUR TITL

1620 MLTS INPU METH OF LOAD TESTING THE STRUCTURE (CHAP 20)

Figure A. 3 SASE-generated listing of input data items, concluded.

139
COMPLETE GLOBAL INGREDIENCE NETWORK

EXTREME LEVEL FROM OUTPUT

0 12 3 4

1 STRNTH TESTS SHALL BE CONDUCTED AT SPECIFIED AGE

: , _ 1000 TYPE OF CONCRETE

: . . . 1010 TEST AGE

10 REQ FOR SPEC OF CONCRETE STRNTH ON DES DRAWING

;...1500 SPECIFICATION OF F'C ON DESIGN DRAWINGS

20 REQ EST VAL OF F(CT) CORRES TO SPEC VAL OF F'C

:...1020 VALUE OF F(CT)

: . . . 1030 LAB TEST CONDUCT

30 REQ NOT ACC CONC ON BASIS OF SPLIT TENSILE STRTH

: . . .1510 CRITERIA FOR USE OF F(CT)

40 REQ TO PROP FOR ADEQ WORKABILITY & CONSISTENCY

: . . .1520 WORKABILITY AND CONSISTENCY

181 REQ THAT LTB W/C RAT YIELDS AVG TEST STR IN 60

. . . .182 DET OF STR CORR TO W/C RATIO OF LTB

:...1060 PREPARATION OF LTB TEST SPECIMENS

: ... 1070 LTB AIR CONTENT

• : . . . 1080 LTB SLUMP

: ... 1090 LTB TEST PROCEDURE

: 60 DET OF REQUIRED AVG TEST STRNTH BY FIELD EXP

: . . . 1040 STD DEVIATION OF STR TEST DATA

: 70 DET OF STD DEV OF STRENGTH TEST DATA

:...1050 REPRESENTATIVENESS OF STRENGTH TEST DATA

:...1290 PREVIOUSLY SPECIFIED F'C

: . . . 1300 BACKGROUND MATERIALS AND PROPORTIONING

-60* DET OF REQUIRED AVG TEST STRNTH BY FIELD EXP

200 REQ FOR MAX PERMISSIBLE W/C RATIO BY TABLE 4.5

1100 PERMISSION TO BASE PROPORTIONS ON W/C RATIO

1110 TYPE OF CEMENT

1120 TYPE OF AGGREGATE

1130 TYPE OF ADMIXTURE

Figure A. 4 SASE-generated global ingredience network

for a standard for concrete quality. (See section A. 3.

3

for a discussion of the network nomenclature used here.)

140
EXTREME LEVEL FROM OUTPUT

0 12 3 4

230 CONG EXPOSED TO FREEZING AIR CONT PER TBL 4.6.1

:...1530 EXPOSURE TO FREEZING

: . . . 1540 AIR CONTENT

240 CONG EXP TO FREEZ-MADE OF LT WT AGG-F' 0-3000PSI

:..-1120 TYPE OF AGGREGATE

: .

. -1530 EXPOSURE TO FREEZING

: 1550 VALUE OF SPECIFIED F'C

250 CONG EXP FREEZ-NORM WT AGG-W/C RATIO >0.83

: .

. -1530 EXPOSURE TO FREEZING

: . . -1120 TYPE OF AGGREGATE

: . . . 1560 W/C RATIO

260 CONG NORM WT AGG EXPOSED FRESH H20-W/C RATIO<0 .

5

; .

. -1120 TYPE OF AGGREGATE

: . . .1570 TYPE OF WATER EXPOSURE

: . . .1580 INTENTION FOR WATER TIGHTNESS

:..-1560 W/C RATIO

261 CONG NORM WT AGG EXPOSED SEA H20-W/C RATIO<0.45

: .

. -1120 TYPE OF AGGREGATE

; .

. -1570 TYPE OF WATER EXPOSURE

: .

. -1580 INTENTION FOR WATER TIGHTNESS

:..-1560 W/C RATIO

270 CONG LT WT AGG EXPOSED FRESH H20-F'C >- 3750PSI

: . . -1120 TYPE OF AGGREGATE

-1550 VALUS OF SPECIFIED F'C

: . .-1570 TYPE OF WATER EXPOSURE

:..-1580 INTENTION FOR WATER TIGHTNESS

271 CONG LT WT AGG EXPOSED SEA H20-F'C > 4000 PSI

: .

. -1120 TYPE OF AGGREGATE

; -1550 VALUE OF SPECIFIED F'C

: . . -1570 TYPE OF WATER EXPOSURE

:..-1580 INTENTION FOR WATER TIGHTNESS

280 CONG NORM WT AGG EXPOS TO SULFATE-W/C RATI0<=0 .

5

: ... 1590 SULFATE EXPOSURE

:..-1120 TYPE OF AGGREGATE

: . . -1560 W/C RATIO

Figure A. 4 SASE- generated global ingredience network, continued.

141
EXTREME LEVEL FROM OUTPUT

0 12 3 4

281 CONG LT WT AGG EXPOSED TO SULFATE-F'C > 3750 PSI

:..-1120 TYPE OF AGGREGATE

-1550 VALUE OF SPECIFIED F'.C

: .

. -1590 SULFATE EXPOSURE

282 CONG EXPOSED INJ SULFATE MADE W. SULFATE -RES GEM

: .

, -1590 SULFATE EXPOSURE

:..-1110 TYPE OF CEMENT

290 REQ FOR PERMIS REDUCTN IN REQ'D AVG TEST STRNGTH

: 1140 QUALITY OF TEST DATA PER ACI214-65

:...1150 PROBABILITY (STRENGTH < F'C - 500)

:...1160 PROBABILITY (AVG OF 3 STRENGTH TESTS < F'C)

300 SAMPLE STR TESTS FOR EACH CLASS OF CONC REQ FREQ

: . _ 1170 TOTAL QUANTITY OF CONCRETE PLACED

: . . . 1180 BUILDING OFFICIALS APPROVAL OF STRENGTH

: . . . 1190 STRENGTH TEST SAMPLING

: . . .1200 NUMBER OF TESTS PER CLASS OF CONCRETE

:..-1210 NUMBER OF BATCHES PER CLASS OF CONCRETE

330 SAMPLES FOR STR TESTS TAKEN IN ACCORD ASTM C172

: . . . 1600 METHOD OF SAMPLING FRESH CONCRETE

340 CYL MOLDED & lAB CURED SPEC TESTED PER ASTM C31

; . . .1610 METH OF MAKING & CURING CONC TEST SPEC IN FIELD

350 CYL STR TEST LAB CURED SPEC TESTED PER ASTM C31

:..... . -1090 LTB TEST PROCEDURE

380 SOMEONE SHALL TAKE STEPS TO INCREASE STR OF CONC

:....370 ACCEPT OF STR LEVELS BASED ON LAB-CURED CYL

:..-1140 QUALITY OF TEST DATA PER ACI214-65

:...1220 NUMBER OF TESTS < (F'C - 500)

: . . . 1250 TEST STRENGTH OF LAB CURED CYLINDERS

:...1251 AVG OF 3 CONSECUTIVE STR TESTS OF LAB CURED CYL

:..-1550 VALUE OF SPECIFIED F'C

Figure A. 4 SASE- generated global ingredience network, continued.

142
EXTREME LEVEL FROM OUTPUT

0 1 2 3 4

381 SOMEONE SHALL TAKE STEPS -LD CAP NOT JEOPARDIZED

I • • . “370* ACCEPT OF STR LEVELS BASED ON LAB -CURED CYL

420 PROC FOR PROT & CURING CONC SHALL BE ADEQUATE

. . .1230 REQ FOR STRENGTH TEST OF FIELD CURED CYLINDERS

. . .1240 METHOD OF MOLDING AND CURING FIELD CURED CYL

.

. -1250 TEST STRENGTH OF LAB CURED CYLINDERS

. . .1310 TEST STRENGTH OF FIELD -CURED CYLINDERS

. . -1550 VALUE OF SPECIFIED F'C

410 DEC BY BLDG OFFL TO ORDER LD TESTS OR OTHER REQ

400 ACCEPT OF IN SITU STR BASED ON CORE TESTS

. . .1260 METHOD OF OBTAINING AND TESTING CORES

. . .1270 NUMBER OF CORES PER LOW STRENGTH TEST

. . .1271 CORE TEST STRENGTH

. . .1280 3 CORE TEST STRENGTH AVERAGE

. .-1550 VALUE OF SPECIFIED F'C

...1620 METH OF LOAD TESTING THE STRUCTURE (CHAP 20)

Figure A. 4 SASE- generated global ingredience network, concluded.

143
COMPLETE GLOBAL INGREDIENCE NETWORK

EXTREME LEVEL FROM OUTPUT

0 12 3 4

181 REQ THAT LTB W/C RAT YIELDS AVG TEST STR IN 60

: 182 DET OF STR CORR TO W/C RATIO OF LTB

. . .1060 PREPARATION OF LTB TEST SPECIMENS

. . .1070 LTB AIR CONTENT

. . .1080 LTB SLUMP

. . .1090 LTB TEST PROCEDURE

60 DET OF REQUIRED AVG TEST STRNTH BY FIELD EXP

. . . 1040 STD DEVIATION OF STR TEST DATA

70 DET OF STD DEV OF STRENGTH TEST DATA

:...1050 REPRESENTATIVENESS OF STRENGTH TEST DATA

;...1290 PREVIOUSLY SPECIFIED F'C

: . . . 1300 BACKGROUND MATERIALS AND PROPORTIONING

-60* DET OF REQUIRED AVG TEST STRNTH BY FIELD EXP

Figure A. 5 Segment of SASE- generated global ingredience

network enlarged to illustrate discussion of network

nomenclature in section A. 3. 3.

144
REFE

2 NAME

STRT

TYPE

ACT

PARE

74

TITL

STRENGTH

FOSTER:

COMMENT

:

REFE

3

NAME

BEST

TYPE

ACT

PARE

59

TITL

DESIGN STRENGTH

FOSTER:

COMMENT

:

REFE

4

NAME

ATS

TYPE

ACT

PARE

6 TITL

REQ AVERAGE TEST STRENGTH

FOSTER:

COMMENT

:

REFE

5 NAME

HOWS

TYPE

ACT

PARE

59

TITL

SHOWN ON DRAWINGS

FOSTER:

COMMENT

:

REFE

6

NAME

PROP

TYPE

ACT

PARE TITL

PROPORTIONING

FOSTER:

COMMENT

:

REFE

7 NAME TYPE

ACT

PARE

60

TITL

MAKING AND CURING SPECIMENS

FOSTER:

COMMENT

:

REFE

8

NAME TYPE PARE TITL

STRENGTH TEST

FOSTER:

COMMENT

:

REFE

9 NAME

woco

TYPE

ACT

PARE

74

TITL

WORKABILITY & CONSISTENCY

FOSTER:

COMMENT

:

Figure A. 6 SASE-generated classifier list for

a standard for concrete quality.

145
REFE NAME TYPE PARE TITL

11 RESF ACT 70 RESISTANCE TO FREEZING

FOSTER:

COMMENT

REFE NAME TYPE PARE TITL

13 H20 ACT 70 WATERTIGHT CONCRETE

FOSTER:

COMMENT

REFE NAME TYPE PARE TITL

14 AGE OF TEST

FOSTER:

COMMENT

REFE NAME TYPE PARE TITL

15 ACT 2 SPLITTING TENSILE STRENGTH

FOSTER:

COMMENT

REFE NAME TYPE PARE TITL

16 IN ACCORDANCE WITH ASTM C330

FOSTER:

COMMENT

REFE NAME TYPE PARE TITL

17 FIELD EXPERIENCE

FOSTER:

COMMENT

REFE NAME TYPE PARE TITL

18 PROPORTIONS

FOSTER:

COMMENT

REFE NAME TYPE PARE TITL

19 MINIMUM ACCEPTABLE VALUE

FOSTER:

COMMENT

Figure A. 6 SASE-generated classifier list, continued.

146
REFE

21

NAME TYPE

ACT

PARE

4

TITL

STANDARD DEVIATION

FOSTER;

COMMENT

REFE

23

NAME TYPE PARE TITL

IN ACCORDANCE WITH ASTM C39

FOSTER:

COMMENT

REFE

26

NAME TYPE PARE TITL

LAB TRIAL BATCH

FOSTER:

COMMENT

REFE

32

NAME TYPE PARE TITL

ACCEPTABLE CEMENT TYPE

FOSTER;

COMMENT

REFE

33

NAME TYPE PARE TITL

NORMAL WEIGHT AGGREGATE

FOSTER:

COMMENT

REFE

35

FOSTER:

COMMENT

NAME TYPE PARE TITL

ACCEPTABLE ENTRAINED AIR CON

TENT

REFE

36

NAME TYPE PARE TITL

MAXIMUM ALLOWABLE W/C RATIO

FOSTER:

COMMENT

REFE

37

NAME TYPE PARE TITL

MINIMUM DESIGN STRENGTH

FOSTER:

COMMENT

Figure A 6 SASE- generated classifier list, continued.

147
REFE

38

FOSTER:

COMMENT

:

NAME TYPE PARE TITL

LIGHTWEIGHT AGGREGATE

REFE

39

FOSTER:

COMMENT

:

NAME TYPE

ACT

PARE

70

TITL

SULFATE-. RESISTING CONCRETE

REFE

41

FOSTER:

COMMENT

:

NAME TYPE

ACT

PARE

65

TITL

SAMPLES FOR STRENGTH TESTS

REFE

42

FOSTER:

COMMENT

:

NAME TYPE

ACT

PARE

41

TITL

FREQUENCY OF SAMPLING

REFE

43

FOSTER:

COMMENT

:

NAME _ TYPE

ACT

PARE

41

TITL

TAKING OF SAMPLES FOR STRENG

TH TESTS

REFE

44

FOSTER:

COMMENT

:

NAME TYPE

ACT

PARE

72

TITL

LAB CURED TEST CYLINDERS

REFE

45

FOSTER:

COMMENT

:

NAME TYPE PARE TITL

TABLE 4.5

REFE

46

FOSTER:

COMMENT

:

NAME TYPE PARE TITL

IN ACCORDANCE WITH ASTM C31

Figure A. 6 SASE-generated classifier list, continued.

148
REFE

47

FOSTER:

COMMENT

:

NAME TYPE PARE TITL

ADEQUATE STRENGTH

REFE

48

FOSTER:

COMMENT

:

NAME TYPE

ACT

PARE

65

TITL

ACTION Taken in view of subs

TANDARD STRENGTH TES

REFE

50

FOSTER:

COMMENT

:

NAME TYPE PARE TITL

PROTECTION AND CURING

REFE

51

FOSTER:

COMMENT

:

NAME TYPE

ACT

PARE

53

TITL

ADEQUATE PROCEDURES

REFE

52

FOSTER:

COMMENT

:

NAME TYPE

ACT

PARE

53

TITL

STRENGTH OF CONCRETE

REFE

53

FOSTER:

COMMENT

:

NAME TYPE

ACT

PARE

65

TITL

STRENGTH OF EXISTING STRUCTU

RE

REFE

55

FOSTER:

COMMENT

:

NAME TYPE

ACT

PARE

60

TITL

STRENGTH TESTS OF lAB- CURED

CYLINDERS

REFE

56

FOSTER:

COMMENT

:

NAME TYPE

ACT

PARE

72

TITL

FIELD CURED TEST CYLINDERS

Figure A. 6 SASE-generated classifier list, continued.

149
REFE

59

FOSTER:

COMMENT

NAME TYPE

ACT

PARE

2 TITLCOMPRESSION STRENGTH

REFE

60

FOSTER:

COMMENT

NAME TYPE

ACT

PARE

65

TITL

CYLINDERS

REFE

61

FOSTER:

COMMENT

NAME TYPE

ACT

PARE

53

TITL

CORES

REFE

63

FOSTER:

COMMENT

NAME TYPE PARE TITL

W/C RATIO

REFE

65

FOSTER:

COMMENT

NAME TYPE PARE TITL

EVALUATION & ACCEPTANCE OF C

ONCRETE

REFE

67

FOSTER:

COMMENT

NAME TYPE

ACT

PARE

73

TITL

FIELD EXPERIENCE METHOD

REFE

68

FOSTER:

COMMENT

NAME TYPE

ACT

PARE

73

TITL

LTB METHOD

REFE

69

NAME TYPE

ACT

PARE

73

TITL

W/C RATIO METHOD

FOSTER:

COMMENT

Figure A. 6 SASE- generated classifier list, continued.

150
REFE

70

FOSTER:

COMMENT

:

NAME TYPE

ACT

PARE

6 TITLSPECIAL EXPOSURE REQUIREMENT

S

REFE

71

FOSTER:

COMMENT

:

NAME TYPE

ACT

PARE

4

TITL

STRENGTH TEST DATA

REFE

72

FOSTER:

COMMENT

:

NAME TYPE

ACT

PARE

60

TITL

TYPES OF CYLINDERS

REFE

73

FOSTER:

COMMENT

:

NAME TYPE

ACT

PARE

6

TITL

METHODS OF PROPORTIONING

REFE

74

FOSTER:

COMMENT

:

NAME TYPE PARE TITL

GENERAL

Figure A. 6 SASE- generated classifier list, concluded.

151
CLASSIFIER PROVISION

2 STRENGTH

3 DESIGN STRENGTH

4 REQ AVERAGE TEST STRENGTH

60 TITL: DET OF REQUIRED AVG TEST

STRNTH BY FIELD EXP

70 TITL: DET OF STD DEV OF STRENGT

H TEST DATA

290 TITL: REQ FOR PERMIS REDUCTN OF

RED'D AVG TEST STRNGTH

5 SHOWN ON DRAWINGS

6 PROPORTIONING

40 TITL: REQ TO PROP FOR ADEQ WORK

ABILITY & CONSISTENCY

60 TITL: DET OF REQUIRED AVG TEST

STRENGTH BY FIELD EXP

181 TITL: REQ THAT LTB W/C RAT YIEL

DS AVG TEST STR IN 60

182 TITL: DET OF STR CORR TO W/C RA

TIO OF LTB

200 TITL: REQ FOR MAX PERMISSIBLE W

/C RATIO BY TABLE 4.5

290 TITL: REQ FOR PERMIS REDUCTN OF

REQ'D AVG TEST STRNGTH

7 MAKING AND CURING SPECIMENS

340 TITL: CYL MOLDED & LAB CURED IN

ACCORD WITH ASTM C31

8 STRENGTH TEST

9 WORKABILITY & CONSISTENCY

40 TITL: REQ TO PROP FOR ADEQ WORK

ABILITY & CONSISTENCY

11 RESISTANCE TO FREEZING

230 TITL: CONC EXPOSED TO FREEZ AIR

CONT PER TBL 4.6.1

240 TITL: CONC EXP TO FREEZ -MADE OF

LT WT AGG-F'C>3000PSI

250 TITL: CONC EXP FREEZ -NORM WT AG

G-W/C RATIO >0.83

13 WATERTIGHT CONCRETE

260 TITL: CONC NORM WT AGG EXPOSED

FRESH H20-W/C RATIO<0 .

5

261 TITL: CONC NORM WT AGG EXPOSED

SEA H20-W/C RATIO<=0.45

270 TITL: CONC LT WT AGG EXPOSED FR

ESH H20-F'C>3750PSI

271 TITL: CONC LT WT AGG EXPOSED SE

A H20-F'C >=4000 PSI

Figure A. 7 SASE- generated scopelist for a standard for concrete quality.

152
CLASSIFIER PROVISION

14 AGE OF TEST

01 TITL; STRNTH TESTS SHALL BE CON

DUCTED AT SPECIFIED AGE

15 SPLITTING TENSILE STRENGTH

20 TITL: REQ EST VAL OF F(CT) CORR

ES TO SPEC VAL OF F'C

16 IN ACCORDANCE WITH ASTM C330

17 FIELD EXPERIENCE

18 PROPORTIONS

19 MINIMUM ACCEPTABLE VALUE

21 STANDARD DEVIATION

23 IN ACCORDANCE WITH ASTM C39

26 LAB TRIAL BATCH

32 ACCEPTABLE CEMENT TYPE

33 NORMAL WEIGHT AGGREGATE

35 ACCEPTABLE ENTRAINED AIR CONTENT

36 MAXIMUM ALLOWABLE W/C RATIO

37 MINIMUM DESIGN STRENGTH

38 LIGHTWEIGHT AGGREGATE

39 SULFATE RESISTING CONCRETE

280 TITL: CONC NORM WT AGG EXPOS TO

SULFATE-W/C RATI0<=0 .

5

281 TITL: CONC LT WT AGG EXPOSED TO

SULFATE-F'C >=3750 PS

I

282 TITL: CONC EXPOSED INJ SULFATE

MADE W. SULFATE RES CEM

41 SAMPLES FOR STRENGTH TESTS

300 TITL: SAMPLE STR TESTS FOR EACH

CLASS OF CONC REQ FREQ

330 TITL: SAMPLES FOR STR TESTS TAK

EN IN ACCORD ASTM C172

340 TITL: CYL MOLDED & LAB CURED IN

ACCORD WITH ASTM C31

42 FREQUENCY OF SAMPLING

300 TITL: SAMPLE STR TESTS FOR EACH

CLASS OF CONC REQ FREQ

43 TAKING OF SAMPLES FOR STRENGTH TESTS

330 TITL: SAMPLES FOR STR TESTS TAK

EN IN ACCORD ASTM C172

44 LAB CURED TEST CYLINDERS

45 TABLE 4.5

46 IN ACCORDANCE WITH ASTM C31

47 ADEQUATE STRENGTH

Figure A. 7 SASE- generated scopelist, continued.

153
CLASSIFIER PROVISION

48 ACTION TAKEN IN VIEW OF SUBSTANDARD STRENGTH TES

380 TITL; SOMEONE SHALL TAKE STEPS

TO INCREASE STR OF CONC

381 TITL: SOMEONE SHALL TAKE STEPS

. LD CAP NOT JEOPARDIZED

50 PROTECTION AND CURING

51 ADEQUATE PROCEDURES

410 TITL; DEC BY BLDG OFFL TO ORDER

LD TESTS OR OTHER REQ

420 TITL: PROC FOR PROT & CURING CO

NC SHALL BE ADEQUATE

52 STRENGTH OF CONCRETE

400 TITL: ACCEPT OF IN SITU STR BAS

ED ON CORE TESTS

53 STRENGTH OF EXISTING STRUCTURE

400 TITL: ACCEPT OF IN SITU STR BAS

ED ON CORE TESTS

410 TITL; DEC BY BLDG OFFL TO ORDER

LD TESTS OR OTHER REQ

420 TITL: PROC FOR PROT & CURING CO

NC SHALL BE ADEQUATE

55 STRENGTH TESTS OF LAB -CURED CYLINDERS

350 TITL: CYL STR TEST LAB CURED SP

EC TESTED PER ASTM C31

370 TITL: ACCEPT OF STR LEVELS BASE

D ON LAB -CURED CYL

56 FIELD CURED TEST CYLINDERS

59 COMPRESSION STRENGTH

10 TITL; REQ FOR SPEC OF CONCRETE

STRNTH ON DES DRAWING

60 CYLINDERS

61 CORES

63 W/C RATIO

181 TITL; REQ THAT LTB W/C RAT YIEL

DS AVG TEST STR IN 60

182 TITL: DET OF STR CORR TO W/C RA

TIO OF LTB

200 TITL: REQ FOR MAX PERMISSIBLE W

/C RATIO BY TABLE 4.5

65 EVALUATION & ACCEPTANCE OF CONCRETE

01 TITL: STRNTH TESTS SHALL BE CON

DUCTED AT SPECIFIED AGE

300 TITL: SAMPLE STR TESTS FOR EACH

GLASS OF CONC REQ FREQ

Figure A. 7 SASE-generated scopelist, continued.

154
CLASSIFIER PROVISION

(65 EVALUATION & ACCEPTANCE OF CONCRETE)

330 TITL: SAMPLES FOR STR TESTS TAK

EN IN ACCORD ASTM C172

340 TITL: CYL MOLDED & LAB CURED IN

ACCORD WITH ASTM C31

350 TITL: CYL STR TEST LAB CURED SP

EC TESTED PER ASTM C31

370 TITL; ACCEPT OF STR LEVELS BASE

D ON LAB -CURED CYL

380 TITL: SOMEONE SHALL TAKE STEPS

TO INCREASE STR OF CONC

381 TITL: SOMEONE SHALL TAKE STEPS

LD CAP NOT JEOPARDIZED

400 TITL: ACCEPT OF IN SITU STR BAS

ED ON CORE TESTS

410 TITL: DEC BY BLDG OFFL TO ORDER

LD TESTS OR OTHER REQ

420 TITL; PROC FOR PROT & CURING CO

NC SHALL BE ADEQUATE

67 FIELD EXPERIENCE METHOD

68 LTB METHOD

69 W/C RATIO METHOD

70 SPECIAL EXPOSURE REQUIREMENTS

230 TITL: CONC EXPOSED TO FREEZ AIR

CONT PER TBL 4.6.1

240 TITL; CONC EXP TO FREEZ -MADE OF

LT WT AGG-F'C>3000PSI

250 TITL: CONC EXP FREEZ -NORM WT AG

G-W/C RATIO >0.83

260 TITL: CONC NORM WT AGG EXPOSED

FRESH H20-W/C RATIO<0 .

5

261 TITL: CONC NORM WT AGG EXPOSED

SEA H20-W/C RATIO<=0.45

270 TITL: CONC LT WT AGG EXPOSED FR

ESH H20-F'C>3750PSI

271 TITL; CONC LT WT AGG EXPOSED SE

A H20-F'C >=4000 PSI

280 TITL: CONC NORM WT AGG EXPOS TO

SULFATE-W/C RATIO<=0.5

281 TITL: CONC LT WT AGG EXPOSED TO

SULFATE-F'C >=3750 PSI

282 TITL; CONC EXPOSED INJ SULFATE

MADE W. SULFATE RES CEM

Figure A. 7 SASE- generated scopelist, continued.

155
CLASSIFIER PROVISION

71 STRENGTH TEST DATA

72 TYPES OF CYLINDERS

73 METHOD OF PROPORTIONING

74 GENERAL

10 TITL: REQ FOR SPEC OF CONCRETE

STRNTH ON DES DRAWING

20 TITL: REQ EST VAL OF F(CT) CORR

ES TO SPEC VAL OF F'C

30 TITL: REQ NOT ACC CONC ON BASIS

OF SPLIT TENSILE STRNTH

Figure A. 7 SASE-generated scopelist, concluded.
ACCEPTABLE CEMENT TYPE

REFE TITL

282 CONC EXP INJ SULFATE MADE W. SULFATE -RES CEM

ACTION TAKEN IN VIEW OF SUBSTANDARD STRENGTH TES

REFE TITL

380 SOMEONE SHALL TAKE STEPS TO INCREASE STR OF CONC

REFE TITL

381 SOMEONE SHALL TAKE STEPS -LD CAP NOT JEOPARDIZED

ADEQUATE PROCEDURES

REFE TITL

410 DEC BY BLDG OFFL TO ORDER LD TESTS OR OTHER REQ

REFE TITL

420 PROC FOR PROT & CURING CONC SHALL BE ADEQUATE

-k'k-krkrk'kitit-k'k-kic^-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k'k'k-k-k-k-k-k-k-k^-k-k^-k-k-k'k-k-k'k-k-k-k'k-Jc'k-k'k-k-k'k-k'k-k'k'k-k-k'kic'k'k'k ADEQUATE STRENGTH

k-k-k'k'k-k-k-k-k-k-k'k-k-k-k'k-k-k-k-k-kic-kic-k-k-k'k-k'k-k'k'k-k'k-k-k-k-k-k-k-k-k'k'k-k-k-k-k-k-k-k-k-k-k'k'k-k'k-k-k'k'k-k'k'k'k'k-k'k'k AGE OF TEST

REFE TITL

01 STRNTH TESTS SHALL BE CONDUCTED AT SPECIFIED AGE

'k'k-k-k'k-k-k-k-k-k-k'k-k-k-k-k-k'k-k'k-k-k'k'k'k-k'k-k-k-k-k-k-k*-k-k-k-k-k-k-k'k'k-k'k-k-k-k-k-k-k'k-k-k'k-k-k-k'k-k'k-k:k-k-k'k-k-k'k'k-k COMPRESSION STRENGTH

REFE TITL

10 REQ FOR SPEC OF CONCRETE STRNTH ON DESIGN DRAWING

Figure A. 8 SASE-generated index for

a standard for concrete quality.

157
CORES

CYLINDERS

k^'kick-k'k-k'k-kick'k'k-k-k'k-k-k-k'ki^'k'k'k-k'k-k'k-k'k-k'k-k'k'k-k-k'k'k-k'k'k-k-k'k'k'k-k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'kk-k DESIGN STRENGTH

•k'k-k'k-k-k-k-k'k-k-k^-k-k-k-k-k-krk-k-k-k-k-k-k-k-kirk-k-k-k-k'k-k-k-krkit^-k-k-kit'k-k-k'k-k-k-k'k-k-k-k'k'k'k-k^-k-k-k-k-k'k-k-k-k'k-k EVALUATION & ACCEPTANCE OF CONCRETE

REFE TITL

01 STRNTH TESTS SHALL BE CONDUCTED AT SPECIFIED AGE

REFE TITL

300 SAMPLE STR TESTS FOR EACH CLASS OF CONC REQ

REFE TITL

330 SAMPLES FOR STR TESTS TAKEN IN ACCORD ASTM C172

REFE TITL

340 CYL MOLDED & LAB CURED IN ACCORD WITH ASTM C31

REFE TITL

350 CYL STR TEST LAB CURED SPEC TESTED PER ASTM C39

REFE

370

TITL

ACCEPT OF STR LEVELS BASED ON LAB -CURED CYL

REFE

380

TITL

SOMEONE SHALL TAKE STEPS TO INCREASE STR OF CONC

REFE TITL

381 SOMEONE SHALL TAKE STEPS -LD CAP NOT JEOPARDIZED

REFE TITL

400 ACCEPT OF IN SITU STR BASED ON CORE TESTS

Figure A. 8 SASE- generated index, continued.

158
(EVALUATION & ACCEPTANCE OF CONCRETE)

REFE TITL

410 DEC BY BLDG OFFL TO ORDER LD TESTS OR OTHER REQ

REFE TITL

420 PROC FOR PROT & CURING CONG SHALL BE ADEQUATE

FIELD CURED TEST CYLINDERS

k'kkrkkkk'k'kit-k-k'k'k'k-k-k'k'k'k'k'k-kk'k'k'k'k'k'k'k-k-k'k'k'k-kic'k-k-k'k-k'k-k'k-k'k-k'k-k'k-k-k'M'k-k-k-k-k-k'k'k'k'k'k'k'k'k'k'k FIELD EXPERIENCE

•k-k-kic-k’k-k-k-k-k-k-k-k-kk-k-k-k-k-k-k-k'k'k'k'k-k'k-k-k-k-k-k'kk-k'k'k'k'k-k-k'k'k-k-k'kk'k'k'k'k-k'k'k'k-k'k'k'k'k-k'k'k'k-k'k'k-k'k'k FIELD EXPERIENCE METHOD

•k-k-k'k'k-k-k-kk-kk-k'k'k-k'k-k'k-k-k'k'k'k^-k'k-k-k'k'k-k'k-k'k'k'k-k-k-k-k-k-k-k-k'k-k-k-k'kic-k'k-k-k'k-k'k-k'k'k'k'k'k-k'k'k'k'k'k'k'k FREQUENCY OF SAMPLING

REFE TITL

300 SAMPLE STR TESTS FOR EACH CLASS OF CONC REQ FREQ

•k-k'k'kkk-kk'k^-k-k'k'k'k'k-k'k-kk-k'kk'kkk-k'k'k-k'k'kk-k-k'kk-k^kk-kic'k-kk'k-k'k-k^k-k-k-k'k-k-k'k-k'kk-k-k-kk-kk'k'k'k'k'k GENERAL

REFE TITL

10 REQ FOR SPEC OF CONCRETE STRNTH ON DES DRAWING

REFE TITL

20 REQ EST VAL OF F(CT) CORRES TO SPEC VAL OF F'C

REFE TITL

30 REQ NOT ACC CONC ON BASIS OF SPLIT TENSILE STRNTH

'kk'k'k'k'k'k'k-k'k-k'k'k'k'k'k'kkk-k'k-k-k'k-k'k-k-k-k'k-k-k'k'k'k-k'k-k-k-k-k'k-k-k'k-k'k'k'k-k-k-k-k-k'k'k'k'k'k-k-k'k'kk'k'k'k'k'k'k'k IN ACCORDANCE WITH ASTM C31

•kk-k'k'k-k-k-k-k-k-k'k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k'k-k-k'k-k-k-k'k-k-k'k'k-k-k'k-k-k'k-k-k'k-k-k-k'k-k-kk-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k'k IN ACCORDANCE WITH ASTM C330

'k-k'k-k'kk'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k'k-k-k-kk-k-k-k-k-k-k-k-k-k-k'k-k'k-k-k-k'k-k-k-k-k-k-k-k'k-k-k-k-k'k-k-k-k-k-k-kk-k'k-k'k'k

Figure A. 8 SASE-generated index, continued.

159
IN ACCORDANCE WITH ASTM C39

lAB CURED TEST CYLINDERS

'k'k'k-k'k-k-k-k-k-k-k-k-k'k-k-k-k-k'kk'k-kk-k-k-k-k-k'k-kk-k-k-k-k'k-k'k'kk-k-k-k-k'k'k-k-k-k-k-k-k-k-k-k-k-k'k-k'k'k'k-k'k-k-k-k-k'k'k-k LAB TRIAL BATCH

•k-k-k-kk-k'k'kirk^-k-k-k-k-k-k-k-k-k-k-k-k-k-k-kk-k-k-kirk-k-k’k-k-k-kirk-k-kk-k-kick-k-k’kick-kirkrk-k'k-k-k'k-k-k-k-k'k-k'k'k'k'k LIGHTWEIGHT AGGREGATE

•k'k-k'k'k'k'k'k-k'k-k-k-k-k-k-k-k-k-k-k'k-k-k-k'k'k-k-krk-k-k-k-k-k-k-k-k^-k-k'k-k-k-k-k-k'k'k-k-k-k'k-k'k'k'k-k-k-k'k'k'k'k'k'k'k-k'k'k-k'k LTB METHOD

•k'k'k'k-k'k'k'k'k'k'k'k'k-k-k-k-k-k'k-k-k'k'k'k'k-k'k-k-k'k-kirk'k-k-k-k-k'kk’k'k-kk'k-k-k’k'k'kirk-k'k'k'k'k'k'k-k'kk-k'krk'k'k-k-k-k-k MAKING AND CURING SPECIMENS

REFE TITL

340 CYL MOLDED & LAB CURED IN ACCORD WITH ASTM C31

•k-k-k-k-kk-k-k-k-k'k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k'k-krk-k'k-k-k-k'k^-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k'k MAXIMUM ALLOWABLE W/C RATIO

'k'k-k'k-k'k'k-k-k-k-k'k-k'k'kic'k'k'k-k-k-k-k-k'k-k'k'k'k-k-k'k-k'k-k-k'k-k-k-k'k-k-k'k'k-kk'k'k'k-k'k-k'k-k'kk'kk'k-k-k'k-k'k-k'k-k-k'k'k METHOD OF PROPORTIONING

'k-kk’k'k-kick-k'k-k-k-k-k'k-k-k-k-k-k-krk-k'k-k-k’k-k'k-k-k-k-k-k-k'k-k-k-k-k-k-k'k-kirk-k-k'k-k-k-k'k-k'k-k-k-k-k-k-k-k-k-k-k'k'k'kk-k-k MINIMUM ACCEPTABLE VALUE

•k'k-k-k'k-k'kk-kkic^irk-kirkrkirk'k'k'kkic-kick-k-kk-kk^rk-k’k-k-k-kk-k-k'k-k-k-kirk-k’k'k-k-k-k-k-k-k'k'k-k-k-k-k'k-k-k-k'k'k'k MINIMUM DESIGN STRENGTH

•k-k-k-k'k-k-k-k-k-k-k-k-k-k'k-kkk'k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-kk-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-kk-kk^-krk-k-k'k'k'k-k NORMAL WEIGHT CONCRETE

•k^^-k'k-k-k-kifk-k-k-k-k-k-k-k'k-k-k-k-k-k-kk-k-k-k-k-k-k'k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k'k'k-k-k'k-k'k'k'k'k PROPORTIONING

REFE TITL

40 REQ TO DROP FOR ADEQ WORKABILITY & CONSISTENCY

REFE TITL

60 DET OF REQUIRED AVG TEST STRENGH TEST DATA

Figure A. 8 SASE- generated index, continued.

160
(PROPORTIONING)

REFE TITL

181 REQ THAT LTB W/C RAT YIELD AVG TEST STR IN 60

REFE

182

TITL

DET OF STR CORR TO W/C RATIO OF LTB

REFE

200

TITL

REQ FOR MAX PERMISSIBLE W/C RATIO BY TABLE 4.5

REFE

290

TITL

REQ FOR PERMIS REDUCTN OF REQ'D AVG TEST STRNGTH

PROPORTIONS

kic-k'k-k-k-k-k-k-k'k'k'kic'k-k'k'k'k'k'k-k'k'k-k'k-k'k-k'kic-k-k-k'k-k-k-k-k-k-k'k'k-k'kic-k'k-k-k'k-k-k-kic'k-k-k-k'k-k^-k'k'k-k'k-k'k-k'k PROTECTION AND CURING

k'k'kic'k'k-k'k-k'k'k-k'k'k-kick-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k'k-k-k-k'k-k-k'k-k'k'krk'k'k-k'k'k-k'k'k'k'k'k REQ AVERAGE TEST STRENGTH

REFE

60

TITL

DET OF REQUIRED AVG STRNTH BY FIELD EXP

REFE

70

TITL

DET OF STD DEV OF STRENGTH TEST DATA

REFE

290

TITL

REQ FOR PERMIS REDUCTN OF REQ'D AVG TEST STRNGTH

'k^-k’k'k-k'k-k-Jrk-k-k-k'k'k'k'k-k-k-k^-k-k^-k-k-k-k-k-k-k^-k-k-k-k-k-k'k'k-k-k-k-k-k-k-k'k'k-k-k-k-k-k-k-k-k-k'k'k-k-k'k'k'k-k'k'k'k'k'k RESISTANCE TO FREEZING

REFE

230

TITL

CONC EXPOSED TO FREEZ AIR CONT PER TBL 4,.6.1

Figure A. 8 SASE-generated index, continued.

161
(RESISTANCE TO FREEZING)

REFE

240

TITL

CONC EXP TO FREEZ-MADE OF LT WT AGG-F' 03000

REFE

250

TITL

CONC EXP FREEZ-NORM WT AGG-W/C RATIO >0.83

SAMPLES FOR STRENGTH TESTS

REFE

300

TITL

SAMPLE STR TESTS FOR EACH CLASS OF CONC REQ FREQ

REFE

330

TITL

SAMPLES FOR STR TESTS TAKEN IN ACCORD ASTM C172

REFE

340

TITL

CYL MOLDED & LAB CURED IN ACCORD WITH ASTM C31

icicicieici(ic-k'k'k-k-k'k-/c:k-k'k-k-k-k-J(-k-k'k-k-ki(-k'k-k'k-k-k‘k-k-f:i(-ki(i(-k‘k'k-k‘k-i(-k-k-k-ki(':k-kie-k-ki(-k-k-ki:-ki(-k-k-k-k-k-Jc'k-k SHOWN ON DRAWINGS

k'k'k-k'k'k'k-k'k-k-k'k'kkk'k'k-k-kkk-k-k-k-k-k'k-k-k-kk-krk-kit'k-k-kic'k-kkkrk-k-kkic-k-k'k-kkkirk-kk-k'k-k-k-k-k-kk'kkkk'k SPECIAL EXPOSURE REQUIREMENTS

REFE

230

TITL

CONC EXPOSED TO FREEZ AIR CONT PER TBL 4.6.1

REFE

240

TITL

CONC EXP TO FREEZ-MADE OF LT WT AGG-F' 03000

REFE

250

TITL

CONC EXP FREEZ-NORM WT AGG-W/C RATIO >0.83

REFE

260

TITL

CONC NORM WT AGG EXPOSED FRESH H20-W/C RATIO<0 .

5

Figure A. 8 SASE-generated index, continued.
(SPECIAL EXPOSURE REQUIREMENTS)

REFE

261

TITL

CONC NORM WT AGG EXPOSED SEA H20-W/C RATIO<=0.45

REFE

270

TITL

CONC LT WT AGG EXPOSED FRESH H20-F' O3750PSI

REFE

271

TITL

CONC LT WT AGG EXPOSED SEA H20-F'C >=4000 PSI

REFE

280

TITL

CONC NORM WT AGG EXPOSED TO SULFATE-W/C RATIO<=0 .

5

REFE

281

TITL

CONC LT WT AGG EXPOSED TO SULFATE-F'C >=3750 PSI

REFE

282

TITL

CONC EXPOSED INJ SULFATE MADE W. SULFATE RES CEM

SPLITTING TENSILE STRENGTH

REFE

20

TITL

REQ EST VAL OF F(CT) CORRES TO SPEC VAL OF F'C

REFE

30

TITL

REQ NOT ACC CONC ON BASIS OF SPLIT TENSILE STRNTH

'k'k-k'k-k'k'k'k-kk'k-k-k-k-k-k-k-k-k-k'k'k-k-k-k-k'k-k-k-k-k'k'k'k-k-k-k-k-k-k-k'k'k-k-k'k-k'k'k'k-k'k'k'k-k'k'k-k'k'k-k'k-k'k-k'k'k-k'k'k'k STANDARD DEVIATION

'k'kk'k'k'k'k-k-k'k'k-k-k'k'k-k-k-k-k'k-k'k'k-k-k'k-k-k'k'k'k'k'k-k-k-k-k-k-k'kk-k-k-k'k'k'k'k'k-k'k'k'k'k'k-k'k'k'k-k'k'k-k'k-k-kk'k'k'k'k STRENGTH

'kk-k-k-k-k-kk-k-k-k-k-krk-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k'k-k-k-k-k'k-k'k-k-k-k'k'k'k-k-k-k-k-k-k'k-k'k-k'k-k'k-k-k-k-k'k'k'k'k'k'k'k'k

Figure A. 8 SASE-generated index, continued.

163
STRENGTH OF CONCRETE

REFE TITL

400 ACCEPT OF IN SITU STR BASED ON CORE TEST

STRENGTH OF EXISTING STRUCTURE

REFE TITL

400 ACCEPT OF IN SITU STR BASED ON CORE TEST

REFE TITL

410 DEC BY BLDG OFFL TO ORDER LD TESTS OR OTHER REQ

REFE TITL

420 PROC FOR PROT & CURING CONC SHALL BE ADEQUATE

•k'k-k-k^^'k-k-k-k-k-k-k'kifk'k'kick-k'kick'k-k-k-k'k'k-k'k-k-k'k-k-k-k'k-k-k'k'k-k-k-kk-k'k-k-k-k-k^-k-k-k-k'k'k-k-k-k'k'k'k-k'k'k-k'k STRENGTH TEST

•k-k’k’kk'k-k-k-k'k'k'k'k'k-k-k-k'k'k-k'k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k'k'k-k'k-k-k-k-k-krk-k-k-k-k'k-k-k-k'k-k-k'k-k'k^-k'k-k'k'k STRENGTH TEST DATA

'k-k-k-k-k-kk-k-kickirk-k'k-kk-k-k-k-k-k-krk^-k-krkirk-k^rk-k-krk:k-k-k-kic-k'kkk-k'k‘kick-k-k-k^-k'k-k-k'k'k-k-k-k-k'k-k'k-k'k-k-k STRENGTH TESTS OF LAB -CURED CYLINDERS

REFE TITL

350 CYL STR TEST LAB CURED SPEC TESTED PER ASTM C39

REFE TITL

370 ACCEPT OF STR LEVELS BASED ON LAB -CURED CYL

kickirk'k'k'k-kick'k'k'k'k'k'k-k'k-k-k'k-k-k'k'k-k-kic'k'k-kirk-kk'kk'k'k-k'k-k-k’k'k'k-k-k'kickk'k'k'k'k'k'k-k'k-k-k'k-k-k-k'k-k'k'k SULFATE RESISTING CONCRETE

REFE TITL

280 CONC NORM WT AGG EXPOS TO SULFATE-W/C RATI0<0 .

5

Figure A. 8 SASE- generated index, continued.

164
(SULFATE RESISTING CONCRETE)

REFE

281

TITL

CONC LT WT AGG EXPOSED TO SULFATE-F'C >=3750 PSI

REFE

282

TITL

CONC EXPOSED INJ SULFATE MADE W. SULFATE RES CEM

TABLE 4.5

kirk'k-k'k'k'k'k'k'k'k'k'k'kick-k'k'kic'k'k'k'k'k'k'k-k’k'k'k'k'k'k'k'k'k'k-k-k'k'k'k'k-k-k-k-k'k-k-k-k-k'k'k-k-krk-k-k'k-k-k'k'k-k'k'k'k'k TAKING OF SAMPLES FOR STRENGTH TESTS

REFE

330

TITL

SAMPLES FOR STR TESTS TAKEN IN ACCORD ASTM C172

•k-krk-k-k-k-k-krk-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k'k'k'kic-k'kirk'k-k'k^rk-krk-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k'k-k'k-k'k-k-k-k'k-k-k'k TYPES OF CYLINDERS

•k'k-k^-k-k-k-k'k'k-k'kirk'k^-k^'k'k-k-k'kirk-k-k-k-krk-k-k-k-k-k'k-k-k-k-k'k'k-k-k'k-k-k'k'k'k-k-k'k-k-k'k-k-krk'k'k-k'k-k-k'k'k'k'k'k'k WATERTIGHT CONCRETE

REFE

260

TITL

CONC NORM WT AGG EXPOSED FRESH H20-W/C RATIO<0 .

5

REFE

261

TITL

NORM WT AGG EXPOSED SEA H20-W/C RATIO<=0.45

REFE

270

TITL

CONC LT WT AGG EXPOSED FRESH H20-F' O3750PSI

REFE

271

TITL

CONC LT WT AGG EXPOSED SEA H20-F'C >=4000 PSI

k-k-k-k-k-k-kic-k-k-k-k-k-k-k'k-k-k-k-k'k-k-k-k'k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^-k'k-k'k-k'k'k-k-k-k-k'k-k-k'k-k'k'k

Figure A. 8 SASE- generated outline, continued.

165
WORKABILITY & CONSISTENCY

REFE TITL

40 REQ TO PROP FOR ADEQ WORKABILITY & CONSISTENCY

W/C RATIO

REFE TITL

181 REQ THAT LTB W/C RAT YIELDS AVG TEST STR IN 60

REFE TITL

182 DET OF STR CORR TO W/C RATIO OF LTB

REFE TITL

200 REQ FOR MAX PERMISSIBLE W/C RATIO BY TABLE 4.5

'k'k-kk-k'k'k'k-kk-kk-k-k'k-kk-k-kk'k'k-k-k-kk'k-kk-k-k-kk-k-k'k-k-k-k-k-k-k-k-k-k-k'k'k'k'k'k-kk-k-k-kk-k'k'k-k-k'k-k-k-k-k'k'k'k'k W/C RATIO METHOD

'k'k'kk'k'k-k-k-k-k-kick-k'k'k'kirk'k'k-k-k-k-k'k'k-k-k-kkk-k'k-k'k-k-k'k-k-k-k-k-k-k-k-k-k-k'k'k'k'k'k'k-k'k'k'k'k'k'k'k'k'k'k-k'k'k'k'k

Figure A. 8 SASE- generated index, concluded.

166
CLASSIFIER PROVISION

74 GENERAL

59 COMPRESSION STRENGTH

10 TITL: REQ FOR SPEC OF CONCRETE

STRNTH ON DES DRAWING

15 SPLITTING TENSILE STRENGTH

20 TITL: REQ EST VAL OF F(CT) CORR

ES TO SPEC VAL OF F'C

6 PROPORTIONING

9 WORKABILITY & CONSISTENCY

40 TITL: REQ TO PROP FOR ADEQ WORK

ABILITY & CONSISTENCY

4 REQ AVERAGE TEST STRENGTH

60 TITL: DET OF REQUIRED AVG STRNT

H BY FIELD EXP

70 TITL: DET OF STD DEV OF STRENGT

H TEST DATA

290 TITL: REQ FOR PERMIS REDUCTN OF

REQ'D AVG TEST STRNGTH

63 W/C RATIO

181 TITL: REQ THAT LTB W/C RAT YIEL

DS AVG TEST STR IN 60

182 TITL: DET OF STR CORR TO W/C RA

TIO OF LTB

200 TITL: REQ FOR MAX PERMISSIBLE W

/C RATIO BY TABLE 4.5

70 SPECIAL EXPOSURE REQUIREMENTS

11 RESISTANCE TO FREEZING

230 TITL: CONC EXPOSED TO FREEZ AIR

CONT PER TBL 4.6.1

240 TITL: CONC EXP TO FREEZ -MADE OF

LT WT AGG-F' 03000

250 TITL: CONC EXP FREEZ -NORM WT AG

G-W/C RATIO >0.83

13 WATERTIGHT CONCRETE

260 TITL: CONC NORM WT AGG EXPOSED

FRESH H20-W/C RATIO<0 .

5

261 TITL: CONC NORM WT AGG EXPOSED

SEA H20-W/G RATIO<0.45

270 TITL: CONC LT WT AGG EXPOSED FR

ESH H20-F'C>3750PSI

271 TITL: CONC LT WT AGG EXPOSED SE

A H20-F'C > 4000 PSI

Figure A. 9 SASE- generated outline for a standard for concrete quality.

167
CLASSIFIER PROVISION

(6 PROPORTIONING)

(70 SPECIAL EXPOSURE REQUIREMENTS)

39 SULFATE RESISTING CONCRETE

280 TITL: CONC NORM WT AGG EXPOS TO

SULFATE-W/C RATIO<=0 .

5

281 TITL: CONC LT WT AGG EXPOSED TO

SULFATE- F'C > 3750 PS

I

282 TITL: CONC EXPOSED INJ SULFATE

MADE W. SULFATE RES CEM

65 EVALUATION & ACCEPTANCE OF CONCRETE

41 SAMPLES FOR STRENGTH TESTS

42 FREQUENCY OF SAMPLING

300 TITL: SAMPLE STR TESTS FOR EACH

CLASS OF CONC REQ FREQ

43 TAKING OF SAMPLES FOR STRENGTH TESTS

330 TITL: SAMPLES FOR STR TESTS TAK

EN IN ACCORD ASTM C172

7 MAKING AND CURING SPECIMENS

340 TITL: CYL MOLDED & LAB CURED IN

ACCORD WITH ASTM C31

14 AGE OF TEST

01 TITL: STRNTH TESTS SHALL BE CON

DUCTED AT SPECIFIED AGE

55 STRENGTH TESTS OF LAB -CURED CYLINDERS

350 TITL: CYL STR TEST LAB CURED SP

EC TESTED PER ASTM C31

370 TITL: ACCEPT OF STR LEVELS BASE

D ON LAB -CURED CYL

48 ACTION TAKEN IN VIEW OF SUBSTANDARD STRENGTH TES

380 TITL: SOMEONE SHALL TAKE STEPS

TO INCREASE STR OF CONC

381 TITL: SOMEONE SHALL TAKE STEPSLD CAP NOT JEOPARDIZED

53 STRENGTH OF EXISTING STRUCTURE

51 ADEQUATE PROCEDURES

410 TITL: DEC BY BLDG OFFL TO ORDER

LD TESTS OR OTHER REQ

420 TITL: PROC FOR PROT & CURING CO

NC SHALL BE ADEQUATE

52 STRENGTH OF CONCRETE

400 TITL: ACCEPT OF IN SITU STR BAS

ED ON CORE TEST

Figure A. 9 SASE- generated outline, concluded.

168
Table A.l Requirement for strength tests at specified age (datum 1)

DECISION TABLE 1 2 3 E ELSE: RUL 123

1 HI -EARLY CONCRETE * T F F

2 TEST AGE = 28 DAYS * . T F

3 TEST AGE AS SPECIFIED * t + T .

1 REQ FOR TEST AGE = SAT. * X X X

2 REQ = VIOLATED * X

Cl T T F

C 2 T F F

C 3 F F F

Table A. 2 Requirement establishing the value of f^t corresponding

to specified value of f'^ (datum 20)

DECISION TABLE 1 E ELSE: RUL 1 2

1 DESIGN GRIT PERMIT USE OF F( * T C 1 T F

CT) * C 2 T . 2 LAB TESTS IN ACCORD WITH AST * T

M C330 *

*****•*-st jSr '**'st'jt'*’ *•**5!:•**•******•**•**•*-sir 1 REQ EST VAL OF F(CT) = SAT. * X

2 REQ = VIOLATED * X

Table A. 3 Determination of required average test strength (datum 60)

1 REQ AVG TEST STR = F'C+400

2 REQ AVG TEST STR = F'C+550

3 REQ AVG TEST STR = F'C+700

4 REQ AVG TEST STR = F'C+900

5 REQ AVG TEST STR = F'C+1200

**

*

**

X

X

X

X

X X

DECISION TABLE 1 2 3 4 5 6 ELSE: RUL 1

1 STDEV < 300 k T - - - - - C 1 F

2 300<= STDEV <400 k - T - - - - C 2 F

3 400<= STDEV <500 k - - T - - - C 3 F

4 500<= STDEV <600 k - - - T - - C 4 F

5 STDEV > 600 k - - - - T - C 5 F

6 STDEV NOT DEFINED * - - - - - T C 6 F

'•k'k'k'k

169
Table A. 4 Determination of standard deviation of strength test data (datum 70)

DECISION TABLE 1 2 E E: RUL 1 2 3 4 5 6 7

1 DATA REPRESENTS >= 30 CONSEC * T C 1 T T T T F F F

UTIVE TESTS * C 2 T T F F T T F

2 DATA ARE STAT AVG OF 2 GROUP * - T c 3 T F T F T F

S T0T5« 30 TESTS * c 4 F F F

3 BACKGROUND SIR TESTS REP CON * T T

C PRODUCED FOR F'C(BT) SUCH •* THAT (F'C-1000)<=F'C(BT)<=(F k

'C+1000)

4 BACKGROUND MATERIALS & PROPO k T T

RTIONS ARE NOT MORE CLOSELY *

RESTRICTED THAT FOR PROPOSED * WORK *

1 STDEV COMPUTED BY STATISTICS * X X

2 STDEV NOT DEFINED * X

Table A. 5 Determination of strength corresponding to water- cement

ratio of laboratory trial batch (datum 182)

DECISION TABLE E ELSE; RUL 1 2 3

1 CURVE BASED ON >=3 PTS REPG * T

BATCHES W/STR +/- THAT GIVEN * BY DATUM 60 *

2 EACH PT BASED ON >- 3 CYLS M * T

ADE PER ASTM C192 & TESTED P * ER ASTM C39 *

3 BATCH AIR = +/- 0.5% & TACH * T

SLUMP = +/- 0.75 IN OF MAX A * LLOWED *

1 STRENGTH GIVEN BY CURVE X

2 STRENGTH NOT DETERMINED * X

Cl T T F

C 2 T F . C 3 F . .

170
Table A. 6 Requirement for maximum permissible w/c ratio

by table 4.5 (datum 200)

DECISION TABLE E ELSE: RUL 1234

1 SUITABLE DATA NOT AVAILABLE * T

FROM FIELD EXPERIENCE OR LTB * AND PERMISSION GRANTED BY (? *

) TO USE W/C RATIO LIMITS *

2 CEMENT IS TYPE I, lA, II, II * T

A, III, IIIA, OR V PER ASTM * C150, OR TYPE IS, IS-A, IS(M *

S), IS-A(MS), IP, IP-A, OR P *

, PER ASTM C595 *

3 CONCRETE CONTAINS LIGHTWEIGH * F

T AGGREGATE *

4 CONCRETE CONTAINS ADMIXTURE * F

OTHER THAN ENTRAINED AIR *

1 REQ FOR MAX PERMISSIBLE W/C * X

RATIO BY TABLE 4.5 = SAT. *

2 REQ = VIOLATED * X

Cl T T T F

C 2 T T F . C 3 T F . . C 4 . T . .

Table A. 7 Requirement for permissible reduction of average

test strength (datum 290)

DECISION TABLE E ELSE: RUL 123

1 TEST DATA MEETS ACI214-65 * T

2 PROB. [STR<F'C-500] < .01 * T

3 PROB. [(AVG OF 3 STR TESTS)< * T

F'C] < .01 *

1 REQ FOR PERMIS REDUCT OF REQ * X

'D AVG TEST STR (CF ACI214- *

65) = SATISFIED *

2 REQ = VIOLATED * X

Cl T T F

C 2 T F . C 3 F . .

171
Table A. 9 Requirement for the frequency of strength test samples

taken for each class of concrete (datum 300)

DECISION TABLE 1 2 3

' E E: RUL 1234

1 TOTAL QUANTITY OF EACH CLASS * T F , F < 50 CYL & STR TEST WAIVED B * Y BLDG OFFL BASED ON EVIDENC *

E OF SATISFACTORY STRENGTH *

2 CONC SAMPLED >= 1/DAY OF PLA * . T T

CEMENT *

3 CONC SAMPLED >=1/150 CYL * . T T

4 CONC SAMPLED >= 1/5000 SF OF * . T T

SLAB OR FLOOR SURFACE *

5 PROVIDES >= 5 STR TESTS, EAC * . T F

H OF 2 CYLS/SAMPLE *

6 STR TESTS MADE FROM >= 5 RAN * . . T

DOMLY SELECTED BATCHES, OR F * ROM EACH BATCH IF BATCHES <5 *

•k'k'k'k'k'k'k'k'k'k-kicJcic'k'JdcJckic'JrJc'k'k'k'k'k'k'Jck'k'k-k-k'k'Jc'k-k-k-k-k'kick'k-k 1 REQ FOR FREQ OF STR TEST SA * X X X

MPLES = SATISFIED *

2 REQ = VIOLATED * X

Cl F F F F

C 2 T T T F

C 3 T T F . C 4 T F . . C 5 F . . . C 6 F . . .

Table A. 9 Requirement for strength levels based on lab -cured

cylinders (datum 370)

DECISION TABLE 1 E ELSE: RUL 1 2

1 AVG OF ALL SETS OF 3 CONSECU * T C 1 T F

TIVE STR TESTS >= F'C * C 2 F . 2 NO SINGLE TEST <[F'C-500] * T

*'>*****'***'****'*)!:***'****)(:•*"it *******•)(:*•!!!**•***

1 REQ FOR STR LEVELS = SAT. * X

2 REQ = VIOLATED * X

172
Table A. 10 Acceptability of in-situ strength based on core tests (datum 400)

DECISION TABLE 1 E

1 CORES OBTAINED AND TESTED P * T

ER ASTM C42 *

2 THREE CORES PER LOW STR TEST * T

3 AIR DRIED 7 DAYS & TESTED DR * T

Y IF DRY IN SERVICE, OR IMME * RSED 48 HRS AND TESTED WET I * F WET IN SERVICE *

4 [AVG OF 3 CORES ]>=.85F'C AND * T

NO CORE < .75F'C *

1 STRUCTURAL ADEQUACY BY CORE * X

TEST = SATISFIED *

2 STRUCTURAL ADEQUACY BY CORE * X

TEST = NOT SATISFIED *

ELSE; RUL 1234

Cl T T T F

C 2 T T F F

C 3 T F . . C 4 F . . .

Table A. 11 Requirement for the protection and curing of concrete (datum 420)

DECISION TABLE 1 2 3 E • ELSE: RUL 1 2 3

1 BLDG OFFL REQUIRES STR TEST * F T T C 1 T T T

OF FIELD CURED CYLINDERS * C 2 T T F

2 FIELD CURED CYLINDERS CURED * T T C 3 T F

BY SEC 7.4 OF ASTM C31 * C 4 F

3 FIELD CURED CYLINDERS MOLDED * T T C 5 F

AT SAME TIME AMD FROM SAME S * AMPLES AS LAB CURED

4 STR < .85 LAB CURED CYLS

.

* T F

5 STR >=F'C+500 *

'k-k 'k-k-k-k'k-k-k-k-k'k'k-k-k'k'k-k'k'k-k-k'k'k'k'k^'k'k'k'k-k-k-k-k-k'k-k ***k'k'k'k'k 1 REQ FOR PROTECTION AND CURIN 'k X X X

G OF CONC = SATISFIED *

2 REQ = VIOLATED * X

173
(This page intentionally left blank)

174
APPENDIX B. ANNOTATED BIBLIOGRAPHY

The concepts presented in the report are the results of the work of several

groups of researchers over the last 20 years. The most significant

research reports and papers are presented below in chronological order,

with brief explanatory comments. The reader should be warned that this

work represents evolutionary growth in a new area; in particular, the

terminology used has changed over the years.

[1] Fenves, S. J., "Tabular Decision Logic for Structural Design,"

Journal of the Structural Division . Vol. 92, No. ST6 (New York;

American Society of Civil Engineers, 1966), pp. 473-490.

First discussion of the use of decision tables to represent provisions of design specifications.

[2] Fenves, S. J., Gaylord, E. H. , Jr., and Goel, S. K. , "Decision

Table Formulation of the 1969 American Institute of Steel Construction Specification," Civil Engineering Studies . No. SRS 347

(Urbana: University of Illinois, 1969).

First major application of [1] to a design specification. Introduces the concept of "switching tables" to represent the organization or outline, "testing tables" for evaluating requirements, and

"working tables" to evaluate determinations.

[3] Goel, S. K. , and Fenves, S. J., "Computer-Aided Processing of

Design Specifications," Journal of the Structural Division . Vol.

97, No. STl (New York: American Society of Civil Engineers, 1971),

pp. 463-479.

Description of a program for execution of decision tables described

in [2]

.

Introduces concept of "direct execution" and "condition

execution"

.

[4] Wright, R. N. , Boyer, L. T. , and Melin, J. W. , "Constraint Processing in Design," Journal of the Structural Division . Vol. 97, No.

STl (New York: American Society of Civil Engineers, 1971), pp

.

481-494.

Introduces distinction between criterion in a design specification

and its application in a specific instance, termed "constraint".

[5] Seeberg, P. , "Decision Table Formulation of the Specification for

the Design of Cold-Formed Steel Structural Members" (Milwaukee:

University of Wisconsin, 1971)

.

A major application patterned directly after [2].

[6] Fenves, S. J., "Representation of the Computer-Aided Design Process

by a Network of Decision Tables," Computer and Structures . Vol. 3,

No. 5 (New York: Pergamon Press, 1973), pp . 1099-1107.

175
Combination of concepts from [3] and [4], generalizing the process

of conditional execution.

[7] Fenves, S. J., D. J. Nyman, and R. N. Wright, "Reformulation of the

Decision Tables for the 1969 AISC Specification" , Unpublished

progress report (Urbana: University of Illinois, July, 1972).

Reformulated tables from [2], with each decision table producing

one datum.

[8] Nyman, D. J., S. J. Fenves, and R. N. Wright, "Restructuring Study

of the AISC Specification", Civil Eneineering Studies . No. SRS 393

(Urbana; University of Illinois, 1973).

First study devoted exclusively to formulation and organization of

a design specification. Introduces "functional network" and

"organizational network"; three levels of analysis and organization, (subsequently named outline, information network, and

decision tables)

.

[9] Nyman, D. J. and Fenves, S. J., "An Organization Model for Design

Specifications," Journal of the Structural Division . Vol. 101, No.

ST4 (New York: American Society of Civil Engineers, 1975), pp

.

697-716.

Major extension of [8], introducing organization strategies for

outlines and information network, exploring strategies for generating textual expressions.

[10] Noland, J. L. and Feng, C. C., "American Concrete Institute

Building Code in Decision Logic Table Format," Journal of the

Structural Division . Vol. 101, No. ST4 (New York; American Society

of Civil Engineers, 1975), pp . 677-696.

A major application patterned after [2] , but introducing a number

of new concepts, including "active" design tables instead of

"passive" testing tables for evaluating criteria.

[11] Harris, J. R. , J. W. Melin, R. L. Tavis , and R. N. Wright, "Technology for the Formulation and Expression of Specifications, Volume

I: Final Report," Civil Engineering Studies . No. SRS 423 (Urbana:

University of Illinois, 1975).

Harris, J. R. , J. W. Melin, R. L. Tavis, and R. N. Wright, "Technology for the Formulation and Expression of Specifications, Volume

II: Program User's Manual," Civil Engineering Studies . No. SRS 424

(Urbana; University of Illinois, 1975).

Harris, J. R. , J. W. Melin, R. L. Tavis, and R. N. Wright, "Technology for the Formulation and Expression of Specifications, Volume

III; Technical Reference Manual," Civil Engineering Studies . No.

176
SRS 425 (Urbana: University of Illinois, 1975).

Documentation of methodology and program developed up to 1975.

Tutorial material on decision tables, decision trees, and information networks used in chapters 4, 5, and 7.

[12] Wu, S. K. F. and D. W. Murray, "Decision Table Processing of the

Canadian Standards Association Specification S16.1", Structural

Engineering Report No. 52 (Edmonton, Canada: University of

Alberta, 1976)

.

A major application patterned after [2] and [3] , including a modified program for executing decision tables.

[13] Fenves , S. J., K. Rankin, and H. Tejuja, The Structure of Building

Specifications . Building Science Series 90 (Washington: National

Bureau of Standards, 1976).

Extension of previous studies to performance and prescriptive

specifications. First general formulation of requirements.

[14] Fenves, S. J., and R. N. Wright, The Representation and Use of

Design Specifications . Technical Note 940 (Washington: National

Bureau of Standards, 1977).

A synthesis of previous studies, introducing strategies for

analysis and synthesis, distinguishing between formulation,

expression and use.

[15] Nyman, D. J., J. D. Mozer, and S. J. Fenves, "Decision Table

Formulation of the Load and Resistance Factor Design Criteria,"

Report R-77-6, Department of Civil Engineering (Pittsburgh:

Carnegie-Mellon University, 1977).

A major application patterned after [2] and [9].

[16] Cunningham, L. K. , J. W. Melin, and R. L. Tavis, "Detailed Application of a Technology for the Formulation and Expression of Standards," Civil Engineering Studies No. SRS 446, (Urbana: University

of Illinois, 1978).

A tutorial case study on a very detailed level of analysis.

[17] Harris, J. R. , S. J. Fenves, and R. N. Wright, Analysis and Tentative Seismic Design Provisions for Buildings . NBS Technical Note

1100 (Washington: National Bureau of Standards, 1979).

The largest application to date.

[18] Fenves, S. J., "Recent Developments in the Methodology for the

Formulation and Organization of Design Specifications," Int . J. of

Engineering Structures . Vol. 1, No. 5 (London: IPC Science and

177
Technology Press, 1979) pp . 223-229.

A summary of [15].

Rasdorf, W, J. and S. J. Fenves, "Representation and Analysis of

Design Specifications at the Interface Between Outlines, Networks,

and Decision Tables," Report R-127-879, Department of Civil Engineering (Pittsburgh: Carnegie-Mellon University, 1979)

.

Procedures for splitting, expanding and compressing decision tables

and making corresponding changes in information network and

outline.

Harris, J. R. and R. N. Wright, Organization of Building Standards

Building Science Series 136 (Washington: National Bureau of

Standards, 1981).

Major survey of previous work and classification schemes and

criteria and methods for organizing specifications. Tutorial

material on provisions, classifiers, organizations, and outlines

extensively used in chapters 8 through 13.

Fenves, S. J,, "Software for Analysis of Standards," Computing in

Civil Engineering (New York: American Society of Civil Engineers,

1980)

.

Summary of specification for SASE program.

Holtz, N. M. and S. J. Fenves, "Using Design Specifications for

Design," ibid , pp. 92-101.

Extension of methodology to symbolically reformulate specifications

presented in checking mode into constraints on design variables.

Rasdorf, W. and S. J. Fenves, "Design Specification Representation

and Analysis," ibid , pp. 102-111.

A summary of [19].

Harris, J. R. , "Organization of Design Standards," ibid , pp

.

112-123.

A sximmary of [20] .

Harris, J. R. , S. J. Fenves, and R. N. Wright, "New Tools for

Standard Writers," Standardization News . Vol. 8, No. 7 (Philadelphia: American Society for Testing and Materials, 1980), pp . 10-17.

A summary of methods used in [17].

Harris, J. R. , S. J. Fenves, and R. N. Wright, "Logical Analysis of

Tentative Seismic Provisions," J. of the Structural Division . Vol.
107, No. STS (New York; American Society of Civil Engineers,

1981), pp. 1629-1641.

A summary of findings from [17].

[27] Tavis, R. L. and J. W. Melin, "Use of Technical Analysis in Editing," Civil Engineering Studies No. SRS 473 (Urbana: University

of Illinois, 1980).

A follow-up on [16] , concentrating primarily on editing (called

"expression" in this report)

.

[28] Stirk, J. A., "Two Software Aids for Design Specification Use,"

Unpublished M.S. Thesis (Pittsburgh: Carnegie -Mellon University,

1981)

.

A complete revision of the programs described in [2] and [17] for

the conditional and direct execution of networks of decision

tables

.

[29] Fenves, S. J., "A Methodology for the Evaluation of Designs for

Standards Conformance," Proceedings of lABSE Symposium on Informatics in Structural Engineering (Zurich; Int. Assoc, of Bridge and

Str. Eng., 1983), pp. 301-316.

A svunmary of work up to 1983.

[30] Howard, H. C. and S. J. Fenves, "Representation and Comparison of

Design Specifications," Report R-83-141, Department of Civil Engineering (Pittsburgh: Carnegie -Mellon University, 1983).

Extension of previous work to the comparison and representation of

similarities and differences between individual design specifications .

[31] Stahl, F. I., R. N. Wright, S. J. Fenves, and J. R. Harris,

"Expressing Standards for Computer-aided Building Design," Computer

Aided Design . Vol. 15, No. 6 (London: Butterworth and Co., 1983),

pp. 329-334.

A summary of the SASE methodology and program.

[32] Rudnicki, R. , "Decision Table Based Software for Designing with

Standards," Unpublished M.S. Thesis (Pittsburgh: Carnegie -Mellon

University, 1984)

.

A Pascal program that generates decision trees from decision tables

and inserts condition and action stubs to produce a compilable

Pascal procedure for each decision table.

[33] Lopez, L. A., S. L. Elam and R. N. Wright, Mapping Principles for

the Standards Interface for Computer Aided Design . NBSIR 85-3115

(Gaithersburg; National Bureau of Standards, 1985).

179
Defines the data interface requirements between SASE representations of standards and applications programs.

Worthington, L. A. , "An Interactive Program to Assist in the

Compilation and Checking of Specification Provisions in Decision

Table Format," Unpublished M.S. Thesis (Pittsburgh: Carnegie-Mellon

University, 1985).

A Pascal program to complete an intitially sparse decision table

and make various checks on completeness of the table.

Slava, M. T. , "Structure and Organization of Project Specifications, " Unpublished M.S. Thesis (Pittsburgh: Carnegie-Mellon

University, 1985).

Extension of the methodology of [13] to project specifications.

Fenves, S. J., and J. H. Garrett, Jr., "Standards Representation

and Processing," in Proceedings of lABSE Symposium on Steel in

Buildings (Zurich: Int. Assoc, of Bridge and Str. Eng., 1985), pp

,

107-114.

An Updated version of [29].

Fenves, S. J., and J. H. Garrett, Jr., "Knowledge -Based Standards

Processing," Int. Journal of Artificial Intellisence in Engineering . Vol. 1, No. 1 (London: Computational Mechanics Publications,

April 1986), pp . 3-14.

A model of a knowledge -based system which uses the representational

model of a specification to design structural components.

Garrett, J. H. , Jr. and S. J. Fenves, "A Knowledge-Based Standards

Processor for Structural Component Design," Report R-86-157,

Department of Civil Engineering (Pittsburgh: Carnegie-Mellon

University, 1986).

A specification- independent knowledge -based system for the design

of structural components. The designer inputs a hypothesis identifying the controlling behavior. The system translates the hypothesis into appropriate specification provisions, constructs the

resulting constraints, and solves for the basic data by optimization or database lookup. The remaining applicable specification

provisions are checked. If some of the provisions are violated, the

system backtracks with a new hypothesis.

Garrett, J. H. , Jr. and S. J. Fenves, "A Knowledge -Based Standards

Processor for Structural Component Design," to appear in Engineering with Computers (New York: Springer-Verlag , 1986).

A summary of [37].
[40] Fenves , S.J., M. T. Slava and J. P. Barnett, SASS - 'Standards

Analysis. Synthesis, and Expression Program: User Manual . NBSIR 87-

3514 (Gaithersburg: National Bureau of Standards, 1987).

A detailed, conunand-by- command description of the SASE program.

[41] Lopez, L. A. and S. Elam, SICAD User's Manual . NBS GCR-87-531

(Gaithersburg: National Bureau of Standards, 1987).

A detailed description of the SICAD (standards interface for

computer aided design.) programming environment developed as a support tool for research on the interface [33] between standards

and computer aided design systems. The system supports automatic

checking of a design for conformance with applicable provisions of

a standard expressed in an augmented form of the SASE model.

181
(

' ill.;, .

S‘‘5* j!

./' 'i'.'

plfe"l-'/..1i'.

•:}c^ • a^ij^i*'.}ji’)’-" '’^AaT!?;. ttii 1;>' ari^gitfe

T .;• t^e, n^i»iBt^*^ t»;4iK5^-kf|^ 7?»-i#!»^ a^awagS^t^

.. , .. - i-i-;;

•!•»•' i*tt’C«v. ‘ %. .U'vfj!. •* : -ii n P'n'&:n ??<tlht|;'^'

, I'i.;i , Ajyf^uiJ -.-</? «‘s5d "'•SirKv

' 'i.c- i --.' -' . ..- ,„ iV^x?L- ;ffmm

;»ViV''.«f- . $

>..Uv'

f

<<"'

; J r ) X.;? .! rV i'

' m

4vX'

-

1 '/ »i <^-

, i . / I 'i,'VV(.M *

, '.(

Afiiff. ' "

• ’ X- rw-id*)n-. <*f '>v%^is^^t Kiwah. '^ki^t^iWfm-

'i: ,.i",4 \ , .,

, . •-'' ' - '^' ^ '"' '

•iC^>

•> •'••••*ri yt * H' >i>y. •»:..» -nj-htcia

ft. j:f rf .1 4i»i-f ,0 %^a£:«ecu!?ji,i,;

*XT-

»?(* ^Vi '’fc'"'-

' I. ^^T.U:l. . ' -• J'ii

*" '• ?,' ;;.- T , V*

i< --I'.i. -lii t‘# 5; 4; , [.'j 'f'6 ? I

' -.'

,

^

' S' . '...'

’ W i.i X'

''

’

' i. ' '''^'" LH - ttc -\ V Vv.c 'V 1, .*fe*s*ii'' ''9’^‘^ipPfi::'i

'>'* <r>Krp{t:ml

u- ph (t^.viihafi^ l-,,i-f:-Wvj;f.i^ ,

.- \>rj,i^ S-^tU' , tif’

I*.

‘ '^."’'.^^®

.,',/• :v''' V4*l%»*>ilwTij>

.v.rj >,K;.^i'i'i[
o.a. OEPT. or COMM. 1. PUBLICATION OR 2. Performing Organ. Report No. 3. PuOlication ate bibliographic data

REPORT NO.

SHEET (See instructions) NBSIR 87-3513 MAY 1987

Introduction to SASE: Standards Analysis, Synthesis, and Expression

5. AUTHOR(S)

Steven J. Fenves, Richard N. Wright, Fred I. Stahl and Kent A, Reed

*. PERFORMING ORGANIZATION (If joint or other than NBS. see instructions)

national bureau of standards

DEPARTMENT OF COMMERCE

c r WASHINGTON, O.C. 20234

7. Contract^ Grant No.

8. Type of Report & Period Covereo

‘i

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

, 10. supplementary NOTES

r~l Document describes a computer protram; SF-185. FlPS Software Summary, is attached.

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

bibiiegraphy or literature survey, mention it here)

The Standards Analysis, Synthesis, and Expression CSASE) methodology

provides an objective and rigorous representation of the content and

organization of a standard. Both the methodology and a computer

program that implements it are described in this document in terms

of two underlying conceptual models. The conceptual model for the

information content of a standard is essentially independent of any particular organization and expression of the information. The

fundamental unit of information in the model is a provision

stipulating that a product of process have some quality. The

highest level provisions in a standard are requirements that

directly indicate compliance with some portion of the standard and

are either satisfied or violated. Techniques are provided in SASE

to ensure that individual provisions are unique, complete, and

correct, and that the relations between provisions are connected, acyclic and consistent. Entities in SASE that represent the

information content of a standard are data items, decision tables,

continued on separate sheet

12. <EY WORDS (Six Eo twelve entries; alphabetical order; capitalize only proper names; and separate key words Oy semicolon s)

13. availability

14. NO. OF

23 Unlimited

PRINTED pages

f~~i For Official Distribution. Do Not Release to NTIS 190

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

'3^ Order From National Technical Information Service (NTIS). Springfield. VA. 22161 $18.95

USCOmM'OC 60«3.PsO
decision trees, functions, and infortaation networks. The conceptua'.

model for the organization of a standard is based on a logical

classification system in which each requirement is classed in terms

of its subject (product or process) and predicate (required

quality). Techniques are provided in SA53E for building and

manipulating hierarchical trees of classifiers and testing the

resulting organization for completeness and clarity. Entities in

SASE that deal with the organization of a standard are class

hierarchy, scopelist, index, organization, and outline. The SASE

methodology is demonstrated in an analysis of a complete standard

for concrete quality. An Annotated bibliography of the most

significant relevant research reports is presented.