- Email: [email protected]
Conceptual modelling of building regulation knowledge
Artificial Intelligence in Engineering 11 (1997) 273-284 0 1997 ElsetierScienceLimited. All rightsreserved ELSEVIER
PII:
Printedin Great Britain c954-1810/97/$17.00
SO954-1810(96)00043-X
Conceptual modeling of building regulation knowledge Johan de Gelder Arthur Andersen & Co., Business Consulting Knowledge Based Systems, Stadhondersplantsoen 29, Den Heag, The Netherlands
(Received for publication
8 November 1996)
In recent years knowledge has become more and more a critical production factor for many organisations. Adequate performance of many activities depends on the availability of knowledge. However, volume and complexity of knowledge increase more and more. Consequently the accessibility of knowledge decreases. Knowledge of fire-safety regulations is critical for architects to design fire-safe buildings and for local authorities to verify fire-safety of building designs. However, effective application of this knowledge in the Netherlands is a problem because of the volume, complexity and inaccessibility of the Dutch Fire-Safety Regulations. People in practice don’t understand and consequently misinterpret the regulations. A solution to this lack of knowledge is the development of a knowledge based system. In the development of knowledge based systems the conceptual modelling phase is an important one. In this phase knowledge of the application-domain is modelled using a conceptual modelling language.*This paper describes criteria for selecting a suitable conceptual modelling language taking into account the nature of knowledge in a particular application-domain. Further it explains what the nature of building regulation knowledge is and which conceptual modelling language is most suitable to represent this knowledge. Finally the paper describes and shows some contents of a knowledge based system that advises architects to design fire-safe buildings conforming to the regulations and helps local authorities to verify building designs with respect to fire-safety regulations. 0 1997 Elsevier Science Limited. Key words: knowledge, nature of knowledge, building regulations, based systems.
1 INTRODUCTION
knowledge
system containing
knowledge of effective and correct application of fire-safety regulations. In the Netherlands there are only a limited number of experts, who have sufficient knowledge of how to apply the fire-safety regulations effectively and correctly. If we are able to include knowledge of these experts into a knowledge based system, we can offer people in practice, who have to apply the regulations in practical building designs and design verifications, a personal expert on their desk.
Effective application of fire-safety regulations in the Netherlands by architects and local authorities is difficult because of the volume, complexity and inaccessibility of the Dutch fire-safety regulations. This often leads to misinterpretation and incorrect application of the regulations in building design. This is a serious problem, because the aim to develop and bring into effect fire-safety regulations is to guarantee design and realisation of fire-safe buildings. With voluminous, complex and inaccessible regulations this aim is hardly achieved. This problem can be categorised as a knowledge problem. The knowledge of people in practice, architects and local authorities, is insufficient to apply the firesafety regulations effectively. A solution to this knowledge problem is the development of a knowledge based
In order to develop a knowledge based system containing knowledge of experts in application of fire safety regulations, we have to model the fire-safety regulations. It is of great importance that the knowledge in the system is represented correctly, completely and consistently. Therefore, a lot of attention should be paid to the conceptual modelling phase in the development of a knowledge based system for fire-safety verification of office buildings. 273
274
J. de Gelder
This paper describes important aspects and decisions in the development of a knowledge based system for fire-safety verification of office buildings. Section 2 first describes in more detail practical problems in application of building regulations in general. Section 3 describes criteria for selecting suitable conceptual modelling languages taking into account the nature of knowledge in a particular application domain. Further section 3 describes the nature of building regulation knowledge and the consequences this nature has for the selection of a conceptual modelling language to model this knowledge. Finally section 4 describes and shows some contents of a knowledge based system that advises architects to design fire-safe buildings conforming to the fire-safety regulations and helps local authorities to verify building designs with respect to fire-safety regulations.
2 APPLICATION
OF BUILDING REGULATIONS
Effective and correct application of regulations is a complex and knowledge intensive task. In the application of Building Regulations the following knowledge problems can be recognised:
(1) Building
Regulations are voluminous and spread over many direrent documents. Because of volume
and spread it is hard to build up sufficient knowledge in order to apply the Building Regulations effectively. People in practice don’t have sufficient knowledge to determine which provisions are relevant in a specific situation and where they can find these provisions. Often relevant provisions originate from different documents and different places in one document. One is never sure to have found all relevant provisions.
(2) Provisions juridical
are hard to understand because of presentation. The provisions in the
Building Regulations are presented by text. Describing provisions by text and at the same time minimising the risk to create shortcomings in the rules, requires juridical formulations on a high level of abstraction. People in practice, however, are not interested in complex juridical formulations but in presentation of provisions directed towards their specific goals and activities. (31 Structure of Building Regulations and presentation
of provisions are often not connected with goals and activities of people in practice. In the building
process many different parties are operating in many different building phases. Each party has its own goals and activities and needs presentation of provisions directed towards these goals and activities. In fact each party needs a different cross-section of the Building Regulations and provisions presented in a goal-oriented way. Since the Building Regulations are only presented in
one way, all parties in the building process have problems to find the relevant provisions, interpret them correctly and translate them for practical use. (4) Descriptions of building objects (buildings, building
parts, building products and building materials) are often not directed towards application of the Building Regulations. A party in the building
process describes a building object from its own perspectives, including only properties relevant for its own goal. This description may be incomplete for another party. The description of a building that architects present to local authorities for verification is often incomplete. On the one hand it contains irrelevant information. On the other hand relevant information is missing. Mainly this is caused by lack of knowledge of the building regulation and lack of knowledge of what information is relevant to adequately perform a verification of conformance to the Building Regulations. Figure 1 graphically displays a part of the complexity in applying building regulations. It displays some goals and activities in which building regulations have to be applied to building objects. Each activity needs different parts of the building regulations. Activities, needing the same parts of the building regulations, may use the provisions differently depending on the different goals. The solution to these knowledge problems seems to be the development of many different goal-oriented descriptions of the Building Regulations for the benefit of specific parties and suitable to be used for specific activities. Depending on the activity only those provisions which are relevant to adequately perform the activity have to be included in a description. Depending on the goal the relevant provisions have to be presented in a goal-oriented way. These descriptions can be presented on paper. More effective is to include the goal-oriented descriptions in a knowledge based system. People can just run the system and, depending on the activity, goal and building object, only the relevant Building Regulation knowledge is presented and the system guides the activity towards the goal. Section 4 describes the development and some interesting parts of such a knowledge based system. The knowledge based system includes knowledge of the building regulations concerning fire-safety of office buildings. The fire-safety regulations are selected because this domain is experienced in practice to be the most complex part of the building regulations. First, section 3 describes the relationship between on the one hand the selection of a conceptual modelling language to model the knowledge for a knowledge-based system and on the other hand the nature of the knowledge. This relationship is first described for knowledge in general
275
Conceptual modelling of building regulation knowledge
Building object
X
definition of building requirements by client
Building Regu’ations conformanceverificationof by local authorities
Fire Safetyprovisions
Goals and activities Fig. 1. Heterogeneity in the application of Building Regulations. and after particular.
that
for
building
regulation
knowledge
in
3 SELECTION OF A CONCEPTUAL MODELLING LANGUAGE TO MODEL BUILDING REGULATION KNOWLEDGE During
the last decade
knowledge-based
systems
There exist many languages that can be used to model knowledge. Each language has its own characteristics. Not every language is suitable for representation of every kind of knowledge. Therefore we need information about the background of languages. What kind of knowledge can be modelled using a specific language? Before we are able to answer this question, we need to define what knowledge is.
have
become increasingly important for the daily practice of many organisations. Today they have even attained a permanent and secure role in trade and industry.’ Yet, the development of knowledge-based systems that are applicable in the daily practice of organisations, remains problematic. Many prototypes of knowledgebased systems simply never go into usage. It is of vital importance for the success of a knowledge based system that the knowledge of the application-domain is represented correctly, completely and consistently. A precondition for the specification, design and implementation of operational knowledge-based systems is therefore the availability of an adequate language to model knowledge.
3.1 Knowledge In AI research the question ‘What is knowledge?’ is often asked and answered. Many of these answers are rather academic, which are not useful as a practical support for understanding knowledge problems and for the selection of adequate languages to model knowledge. An academic definition of knowledge, that is practically useful to perform this selection, originates from Lucardie.* Lucardie defines knowledge as the competence to match an object to an object-type. In this definition objects are physical things, like a mammal or a fire-safe building, or abstract things, like malaria or a car defect diagnosis. Object-types are descriptions of
Fig. 2. Knowledge as the competence to match an object to an object-type.
276
J. de Gelder
physical or abstract things. The object-type ‘mammal’, for instance, defines the properties of a mammal. The object-type ‘fire-safe building’ defines the properties of a fire-safe building. A match of an object to an object-type is comparing a real-world object with the definition of an object-type. A match of a specific animal to the object-type ‘mammal’ is comparing the properties of the animal with the definition of the object-type ‘mammal’. If the animal (the object) has properties satisfying the definition of a mammal (the object-type), then the object matches the object-type and consequently the animal is a mammal. Figure 2 displays this matching process graphically. Experience teaches that many knowledge problems can be represented in this abstract schema of matching an object to an object-type. Representation of knowledge problems in this schema helps to understand the problem better and supports the selection of adequate languages for the benefit of knowledge based system development. In knowledge based system development the definition of an object-type has to be modelled and knowledge about the objects has to be retrieved and stored in a database in order to be able to match the objects to the definition of the object-type. In this process only that knowledge about the object has to be stored in the database that is sufficient to perform the match to the definition of the object-type. In the case of matching of animals to the definition of mammals, only that knowledge of animals should be retrieved and stored that is important to classify an animal as a mammal. Here, for instance, the number of legs of the animal is not important and need not be stored. Since the relevance of knowledge about the objects depends on the definition of the object-type, the definition of the object-type has to be constructed first. The questions here are: ‘What does this definition look like?’ and ‘What languages are suitable to model and represent this definition?‘. The answers to these questions depend on the nature of knowledge. 3.2 Nature of knowledge With respect to the nature of knowledge four views can be recognised in practice. In this paper we refer to these views using the following names: 1. 2. 3. 4.
Classical view. Probabilistic view. Prototypical view. Functional view.
Fig. 3.
These four views will be discussed in the next subsections. Additionally examples of well-known ceptual modelling and knowledge representation guages able to represent knowledge according to view will be given.
four conlaneach
3.2.1 Classical view of knowledge The classical view states that an object-type can easily be defined. It’s easy to define the conditions of an object-type and properties of objects can easily be compared with these conditions. An example of a classical defined object-type is the definition of an elephant as an animal with the following conditions: trunk, grey colour, four legs and big body. Having this definition it’s easy to match an object to this definition by comparing the object’s properties with the conditions of the object-type. Objects having a trunk, grey colour, four legs and a big body, for instance, match to the definition of the object-type ‘elephant’. Consequently these objects are elephants. Figure 3 schematically shows the matching according to the classical view. Object-types that can be defined according to the classical view are easily represented in the language ‘records’. A record represents a fixed sequence of condition values. The meaning (object-type) of these attributes is stored in a so called data dictionary. A number of records (objects) matching the object-type is called a table. A record can only be stored in a table if it has values for each condition. It will be clear that in practice definitions of objecttypes are not as easy as supposed by the classical view. If an elephant has an accident and loses his trunk, this elephant doesn’t match the definition of the classical object-type ‘elephant’. Consequently this animal is not an elephant anymore according to the definition. But in fact it’s still an elephant, so the definition is not correct. Eventually this problem can be solved by leaving the first condition, trunk, out of the definition, but this is not really a solution, because the elephant can also by accident lose one leg or change colour because of a disease. If these problems are solved by leaving the colour and legs condition out as well, only the big body condition is left. Then another problem is created: a rhino and a hippo match the definition of the objecttype ‘elephant’ and the knowledge based system will recognise these animals as elephants. Although human beings don’t have many problems in recognising an animal as an elephant, it appears that it’s not very easy to give a clear definition. A simple objecttype, like an elephant, has a lot of fuzzy conditions, which are hard to define. In order to give computer
Matching in the classical view.
Conceptual modelling of building regulation knowledge
programs the ability to catch this fuzziness, alternative views on the nature of knowledge have been developed. In the next three subsections these views will be discussed: the probabilistic view, the prototypical view and the functional view. 3.2.2 Probabilistic view of knowledge Like the classical view, the probabilistic view states that an object-type can easily be defined. The difference is that the probabilistic view states that it’s not always possible to be 100% sure of all conditions of the objecttype. Sometimes the occurrence of one condition can compensate the absence of another condition. To be able to match objects probabilities are assigned to each condition of the object-type and an objective function is defined. Sure conditions are assigned a high probability. Unsure conditions a low probability. Matching takes place by comparing properties of an object with the definition of the object-type and filling in the probabilities of the satisfied conditions in the objective function. If in the end the set of satisfied conditions is sufficient to fulfil the objective function, the object matches the definition of the object-type. If, in the elephant example, the condition ‘trunk’ is assigned the probability 0.3, the condition ‘grey colour’ the probability 0.2, the condition ‘four legs’ the probability O-1 and the condition ‘big body’ the probability 0.4 and the objective function is a simple addition of probabilities with a minimum score of 0.5, then, for instance, elephants missing a trunk and animals missing a grey or yellow colour and one or more of their legs still match the definition of the object-type. Figure 4 schematically shows the matching according to the probabilistic view. The objective function is a simple addition of probabilities. This simple example shows that condition Y should always be satisfied and conditions X and 2 can compensate each other. This means that if condition X is not satisfied, condition Z must be satisfied. If condition Z is not satisfied, condition X must be satisfied. Examples of languages that support the definition of object-types according to the probabilistic view are:
277
multi-criteria and regression techniques. Also many neural networks represent knowledge in a probabilistic way. Using a neural network, the object-type is not explicitly defined, but derived from a large set of objects matching the definition of the object-type. In contrast with the classical view, the probabilistic view offers abilities to match objects to the definition of the object-type, also if not all conditions are satisfied. The starting point of the probabilistic view is the assumption that conditions can compensate each other. This is however not always a valid assumption. In many definitions of object-types conditions exist which must be satisfied anytime or must be satisfied depending on other conditions. If this is true, defining object-types according to the probabilistic view will not deliver reliable matching results. 3.2.3 Prototypical view of knowledge In contrast with the classical and the probabilistic view, the prototypical states that it’s not possible to define a set of conditions all objects must satisfy in order to match the object-types. The question is not: does the object match the object-type? The question is: how well does the object match the object-type? An object matching many conditions of the object-type better matches the object-type than an object matching only a few conditions of the object-type. An object matching all conditions of the object-type is called a prototype or a stereotype object. The conditions of the object-types are called (proto- or stereo-) typical conditions. If in the definition of the object-type ‘elephant’ trunk, four legs and grey colour are defined as (proto- or stereo-) typical conditions, an object with a trunk, four legs and a grey colour is called a (proto- or stereo-) typical elephant. An elephant with, for instance, a brown colour caused by a disease or without trunk because of an accident is not a (proto- or stereo-) typical elephant anymore, but still an elephant. The question then arises: What conditions must an object at least satisfy in order to still be classified as an elephant. Prototypical languages like semantic networks, frames, object-oriented modelling languages like 0MT3 and data modelling languages like
2OX+4OY+30%=60
Fig. 4. Matching in the probabilistic
view.
278
J. de Gelder
Fig. 5. Matching in the prototypical view. NIAM, solve this problem by offering facilities to define deviating prototypes. An elephant with a brown colour caused by a disease is then a (proto- or stereo-) typical sick elephant and an elephant without trunk because of an accident is a (proto- or stereo-) typical trunkless elephant. Figure 5 shows schematically the matching according to the prototypical view in case facilities for defining deviating prototypes are available. In this example three prototypes of the same object-type are defined. Objects satisfying all conditions (X, Y and 2) match the first prototype. Objects not satisfying condition Z, but satisfying conditions X and Y, match the second (deviating) prototype. Objects not satisfying condition X, but satisfying conditions Y and Z, match the third (deviating) prototype. Although the prototypical view offers more abilities to represent knowledge of reality than the classical and probabilistic view, there are still a number of conceptual problems.4 Earlier the prototype ‘elephant’ was defined with the conditions trunk, four legs and grey colour. In order to match sick and trunkless elephants as well, two deviating prototypes were defined. The prototype ‘sick elephant’ with the conditions trunk, four legs and brown colour and the prototype ‘trunkless elephant’ with the conditions four legs and grey colour. Suppose an elephant loses his trunk, but also two of his legs. This elephant matches none of the prototypes. In the prototypical view this can be solved by defining another deviating prototype ‘trunkless two-legged elephant’ with the necessary conditions two legs and a grey colour. This generates the problem again that also animals other than elephants exist with two legs and a grey colour. A heron, for instance, is a bird with two legs and a grey colour. This bird matches the object-type ‘trunkless twolegged elephants’ and hence is classified as a typical trunkless two-legged elephant. This example shows that the prototypical view has limitations in case many different deviating prototypes have to be defined. Another conceptual problem in the prototypical view is the definition of the object-type or prototype itself.
This is not always obvious. How should a prototype be defined? In fact the prototypical view states that the prototype should be defined in the way an object (matching the prototype) presents itself in the real world most of the time. But how does an object present itself in the real world? How, for example, does a building presents itself? A building, for instance, can be defined in many different ways. In the real world many different buildings exist. A prototypical approach would be to investigate which types of buildings exist and to define a general prototype ‘building’ and deviating prototypes for each type of building. The issue is which types of buildings must be distinguished and which conditions must be defined for each type. Possible building types could be: office buildings, lodging buildings and dwellings. But why choose such a distinction. Why not choose a distinction of buildings into public buildings and private buildings or buildings with and without sleeping accommodation. This example demonstrates that the different ways objects present themselves in reality cannot be the starting point for defining object-types. How do objects present themselves in the real world? Does the real world show office buildings, lodging buildings and dwellings? Does the real world show public buildings and private buildings? Does the real world show buildings with and without sleeping accommodation? What’s the best detini’tion for buildings? These are questions that are hard to answer in the prototypical view. The functional view has answers to these questions. 3.2.4 Functional view of knowledge Like the prototypical view the functional view recognises that in the real world objects present themselves in many different ways. In contrast with the prototypical view, the functional view explains this by stating that people observe and define objects taking in mind a certain goal or viewpoint. According to the functional view there is no best definition of an object-type. A definition is goaldependent. If, in defining a building, the goal is to
Conceptual modelling of building regulation knowledge
determine whether a building has sleeping accommodation or not, the object-type ‘building with sleeping accommodation’ has to be defined by defining the conditions an object must satisfy in order to be a ‘building with sleeping accommodation’. A building not satisfying the defined conditions automatically is a building without sleeping accommodation. On the other hand if the goal is to determine whether a building is a private building or a public building, the objecttype ‘private building’ has to be defined by defining the conditions a building must satisfy in order to be a ‘private building’. In the functional view the goal also determines what conditions are relevant for the definition of the objecttype. A wall in a building must, for instance, satisfy a large number of conditions. A wall must satisfy sound proofing conditions, fire-safety conditions, constructive conditions, etc. Verifying fire-safety of a wall requires completeb different conditions from verifying sound proofing of a wall. The consequence is that the definition of the object-type ‘wall’ defined for the benefit of firesafety is completely different from the object-type ‘wall’ defined for the benefit of sound proofing. If walls have to be verified by a knowledge based system on both firesafety and sound-proofing, then two object-types have to be defined. It’s possible that a specific wall matches the object-type ‘wall’ defined for the benefit of firesafety, but doesn’t match the object-type ‘wall’ defined for the benefit of sound proofing. Another important aspect of the functional view is the recognition that objects with different properties can all match the same object-type. When people, for instance, intend to buy a new car, they formulate a number of conditions (the object-type) the new car (the object) must satisfy. It appears in practice that many different cars satisfy these conditions. This is because conditions are defined not independently but dependent on other conditions. An example: someone may define that the car’s price shouldn’t exceed 20000 dollars, but, if a car
Fig. 6.
219
doesn’t have a sun roof, the price shouldn’t exceed 19000 dollars. This example shows that the condition ‘price’ is not an independent condition, but a condition dependent on the condition ‘sun roof’. Another condition may be: the car should have a car radio and two doors, but, if for the same price a car can be found with four doors, the car radio is not necessary. This example shows that the condition ‘car radio’ is not always relevant. Its relevance depends on the value of the conditions ‘number of doors’ and ‘price’. Further this example shows that a car with two doors and a car radio is equivalent to a car with four doors and without a car radio. In the functional view this mechanism is called ‘functional equivalence’. This means, taking into account the buyer’s goals, the two alternatives are equivalent. Possibly these two alternatives are not equivalent for another buyer with other goals. So, the relation of an object-type definition to a specific goal is of vital importance. This car-buying example shows that the definition of an object-type can be very heterogeneous. Conditions are not independent, but their values depend on the values of other conditions. Conditions are, dependent on other conditions, sometimes relevant and sometimes irrelevant. Because of this, objects with completely different properties may all match the same object-type and hence are functional equivalent. Figure 6 schematically shows the matching according to the functional view. In this example two objecttypes are defined for two different goals. Three objects are displayed. The first object only matches the definition of the first object-type. The third object only matches the definition of the second object-type. The second object matches the definition of both object-types. The conditions of both object-types are conditionally defined. An object matches the definition of the first object-type if it satisfies conditions X and 2. Condition Y is in this case irrelevant. However, if condition X is not satisfied, condition Y must be
Matching in the functional view.
280
J. de Gelder
satisfied and condition 2 is not relevant. An object matches the second object-type if it satisfies the conditions X and Y. Condition Z is not relevant. However, if condition Y is not satisfied, condition Z must be satisfied. Examples of languages that support the definition of object-types according to the functional view are: logic and languages based on logic, like decision tables and production rules. Decision tables have the advantage of having the ability to explicitly express functional equivalence (see section 3.3). In this sense decision tables are the most powerful language based on the functional view of knowledge. In practice matching often takes place as viewed by the functional view of knowledge. In many cases conditions are not independently defined, but dependent on other conditions. Often conditions are only relevant or have variable values depending on the values of other conditions. These dependencies may differ depending on a specific goal. If matching takes place like this or, in other words, knowledge has this nature, a language able to represent dependencies between conditions should be selected. Languages based on a classical, probabilistic or prototypical view of knowledge are not able to represent this kind of knowledge adequately.
3.3 Nature of building regulation knowledge Like any other regulations, building regulations contain a lot of interdependencies between conditions. Figure 7 shows a part of Article 235 of the Dutch Building Code. Article 235 describes provisions concerning escape ways from a smoke compartment. Article 235 stipulates that in principle each smoke compartment should have at least two independent escape ways. This can be realised in two different ways. From an entrance of a smoke compartment people can escape in two different and independent directions (part 1) or a smoke compartment has two entrances, each leading to at least one
independent escape way (part 2b). Independent means: escape ways are not coming together somewhere inside the building. In principle there must be two independent escape ways from a smoke compartment, but in specific situations it is allowed that a smoke compartment has only one escape way. Parts 2a, 2c, 3, 5 and 6 of Article 235 describe provisions for these situations. So, if it’s not possible to escape from a smoke compartment via two independent escape ways, one has to verify this smoke compartment for conformance to parts 2a, 2c, 3, 5 and/or 6. Article 235 of the Dutch Building Code contains a number of conditions whose relevance or value depends on other conditions. Further this article enables escape ways to be designed in different (functionally equivalent) ways. The dependencies between conditions and the existence of functionally equivalent solutions a& hard to recognise reading Article 235 iti its textual representation. A solution to this problem is representing Article 235 in a decision table. Figure 8 shows this decision table. Condition C4, for example, is relevant depending on other conditions. Condition C4 is only relevant if the smoke compartment is not situated on the ground floor, people have to escape via a fire proof staircase and the user surface of all smoke compartments, which have to pass this staircase to escape to the site, doesn’t exceed 1OOOm’.In all other cases condition C4 is not relevant. The value of condition C3 depends on the value of other conditions. If the smoke compartment is situated on the ground floor, the user surface of all smoke compartments, which have to pass the single escape way, is not allowed to exceed 250m2. The same requirement is valid if the smoke compartment is not situated on the ground floor and the escape way is not a safety staircase nor a fire proof staircase. But if the smoke compartment is not situated on the ground floor and the escape way is a fire proof staircase, then the user
Escape in case of fire Article
235
1. An entrance of a smoke compartment as meant in article 234, part four to seven, must be situated next to the site or next to a room which contains two independent escape ways. 2. Contrary to part I, the entrance may be situated next to a room which contains one single escape way, if: a. the entire user surface of the smoke compartments dependent on the single escape way does not exceed 250 m2 ; b. the smoke compartment has two entrances each leading to at least one independent escape way, or c. the escape way is a fire proof staircase. 3. The entire user surface of the smoke compartments dependent on the single escape way, as meant in part 2c, excluded an escape way via a safety staircase, may not exceed 1000 m2. 5. The distance between an entrance of a smoke compartment as meant in part I and an entrance of the office building, may not exceed 30 m, if part 2c is applied. 6. Pan 5 is not applicable if the escape way is a safety staircase. Fig. 7. A part of Article 235 of the Dutch Building Code.
281
Conceptual modelling of building regulation knowledge Oneescapewayfroma
smokecomputmmt
Cl
L.ccath smoke
other floor
Ground tloer
cempttiment SClfcty staifcasc
c2
Type of staircase
c3
user smfacc of all smoke compartments dependentonthc singleescapeway
=<250 m2
c4
Distancebetween
-
stailulse entmnce
>2M m2
Fire proof staircase
othutypcof S-
=clOOOm2
=<30 m
>30m
>looo m2
=Q50 m2
>2SOm2
-
and office
Fig. 8. Article 235 of the Dutch Building Code in a decision table representation. surface of all smoke compartments, which have to pass this staircase, is not allowed to exceed 1OOOm’. This demonstrates that the allowed user surface is not a fixed value. The value depends on the value of the conditions Cl and C2. For example, a user surface of 500m2 is sometimes allowed and sometimes not allowed, depending on the values of conditions Cl and C2. The decision table clearly shows four functional equivalent solutions (Rl, R3, R4 and R7). None of the four conditions (C 1-C4) has a fixed value independent of other conditions. The conditions C2-C4 are only relevant dependent on the value of other conditions. The allowed value of condition C3 depends on the values of conditions Cl and C2. Most articles in the Dutch Building Code, and also articles in many other legislations, are like Article 235. A lot of interdependencies between conditions exist, leading to many different functional equivalent ways to satisfy the requirements. The conclusion must be that knowledge in this application-domain must be modelled and represented according to the functional view of knowledge. The example demonstrates that ‘decision tables’ is an excellent language to represent this kind of knowledge because of the ability of this language to show the interdependencies between conditions and to show functional equivalent solutions. Also other researchers came to this conclusion.5-9 Although the difference with these researchers is their use of decision
tables to represent only quantitative knowledge instead of qualitative knowledge on a conceptual level, as presented in this paper.
4 KNOWLEDGE BASED SYSTEM FOR FIRE SAFETY VERIFICATION OF OFFICE BUILDINGS Section 3.3 showed that building regulation knowledge must be modelled and represented according to the functional view of knowledge. Values of conditions may vary depending on values of other conditions. Conditions are sometimes relevant and sometimes irrelevant depending on values of other conditions. And many different functional equivalent solutions may exist. Further section 3.3 showed that ‘decision tables’ is an excellent language to represent this kind of knowledge. Decision tables are able to represent conditional between conditions and decision tables clearly represent functional equivalence. Therefore we decided to use decision tables to represent the knowledge for the knowledge based system for fire safety verification of office buildings. We developed a knowledge based system shell based on decision tables, called AKTS.” AKTS is written in Prolog and offers a user-friendly graphical editor for editing decision tables and is running on an Apple Macintosh. Knowledge represented in decision tables
vetifieation of a
Fig. 9. The matching problems the knowledged based system is based upon.
282
J. de Gelder
can immediately be consulted by AKTS. Additional to decision tables Prolog can be used to represent knowledge or to implement user-interface aspects. Consultation of knowledge using AKTS is possible on an Apple Macintosh and Windows. We started the development of the knowledge based system for fire verification by identifying object-type and object and defining the matching problem. Since the knowledge based system had to support both architects (design) and local authorities (verification) we defined two matchings problems, one from a design perspective and one from a verification perspective. Figure 9 displays the earlier introduced schematic representation of a matching problem, filled in for both design and verification of a fire-safe office building. The definition of the object-type ‘design of a fire-safe office building’ contains knowledge about the properties a particular design must have in order to be a correct design of a fire-safe office building. At the same time the definition of the object-type ‘verification of a fire-safe office building’ contains knowledge about the properties a particular design verification must have in order to be a correct fire-safety verification of an office building design. Figure 10 shows the decision table representing the object-type ‘design of a fire-safe office building’. A particular office building design is a design of a fire-safe office building if the six design aspects (Cl -C6) all satisfy the fire-safety regulations. Splitting up the design into a number of sub-designs generates in fact a number of sub-object-types. The design of fire-safe escape
ways, for instance, is expressed by the sub-object-type ‘design of fire-safe escape ways’. As an example a part of the conceptual model of this sub-object-type will be described in more detail. The design of fire-safe escape ways is performed after the design of smoke compartments. This is because the fire-safety regulations define escape ways from the exit of a smoke compartment. In section 3.3 we explained that in principle each smoke compartment must have two independent escape ways. Smoke compartments having only one escape way are allowed if a number of other requirements is satisfied. The decision tables in Fig. 11 display the definition of the sub-object-type ‘design of fire-safe escape ways’. The second decision table of Fig. 11 contains the same knowledge as the decision table in Fig. 8, but structured differently. The decision table in Fig. 8 represents the knowledge from a verification perspective. The decision table in Fig. 11 represents the knowledge from a design perspective. A designer needs as output of the system a list of requirements to satisfy in order to design a firesafe office building. A verifier needs as output of the system an indication whether the design satisfies the requirements. Both have different goals in applying the building code. And different goals lead to different object-types, whose definitions differ, although they contain the same knowledge. The knowledge for all other design aspects has been modelled similarly to the knowledge concerning fire-safe escape ways. The knowledge based system contains in
Design of a fire-safe office building Doesn’t satisfy fire-safety requirements
Satisfies fire-safety requirements
Doesn’t satisfy fire-safety requirements
Satisfies fire-safety requirements
Doesn’t satisfy tire-safety requirements
Satisfies fire-safety requirements
c4
Design of fire-safe staircases
c5
Design of fire-safe room layouts
f cd
Al
=t
Design of fire-safe entrances aad exits Design of a fire-safe office building
Doesn’t satisfy fire+ety
Satisfies fire-safety req inments
Satisfies fire-safety requirements
Satisfies
tire-safety requirements
c
Doesdt satisfy fire-safety requirements
Doeso’t
Doesn’t satisfy satisfy fire-safety fire-safety reauirements requirements R3
I I
R4
Fig. 10. The object-type ‘design of a fire-safe office building’ represented by a decision table.
283
Conceptual modelling of building regulation knowledge Design of fire-safe escape ways >I
I
Number of escape ways from smoke compartment
I
No
I
Dccslttsatisfy
Satisfies
fin-safety requirements
~
Yes
fUC-Safety
requirements
satisfies fire-safety requirements
Doesn’tsatisfy fire-safety requirements
Satisfies fire-safety reauinments
Doesn’tsatisfy fire-safety reuuirements
----Satisfies
I I
fife-safety
wayi
reauirtments I I
Rl
t I
Doesn’tsatisfy fm-safety rrauirements
R2
I
I
I I
Satisfies tire-safety reauirements
R3
I
R4
I I
1
1
R5
I I
Design of fire-safe escape way< in case of one escape way from a smoke compartment
=c250 m2
I
1
Other floor
Groundfloor
1
>250 m2, =
>lCQOm2
smoke compartments dependenton the single =<30 m staircase entrance and office building exit The user surface of all smoke dEggri%e single escape way is not greaterthan 250 m2 (article 235, part 2a)
The escape way
satisfies the requirementsof article 235, part 2a of Toz$lding
The escape way only satisfies the nq&zments of the Building code (article 235, part 2c, 3 and 5), if the escape way is a fire oroof
Satisfies
I
>30In
The escape way only satisfies the requirementsof the Building code (article 235, part 5 and 6). if the escape way is a safety staircase Satisfies tire-safety requirrments
fire-safety requirements
The escape way
only satisfies the requirementsof the Building code (article 235, PM 31, if the escape
way is a safety staircase Satisfies tire-safety requirements
smoke &mpa&ent R5 Fig. 11. The object-type ‘design of fire-safe escape ways’ represented by two related decision tables.
total 163 related decision tables. The system contains two independent modules, a design module and a verification module. The design module asks the designer a number of questions about his or her design and gives as output the requirements the designer must satisfy in order to make the building fire-safe. The verification module asks the user a number of questions about a completed design and gives as output: design satisfies or design doesn’t satisfy the fire safety requirements. If the design doesn’t satisfy the fire safety requirements, the verification module explains why the design doesn’t satisfy. The system is running on Windows and has been sold to several design firms and local authorities in the Netherlands. The system contains a lot of (graphical) explanations in order to help the user answering the questions and understanding the output correctly. Although there are also other systems tackling legislation advice, the uniqueness of the system described in this paper is the explicit representation of the fire safety
regulation knowledge in a way interpretable by a computer. The systems helps a user not only in finding the relevant regulations, but also in interpreting and correctly applying them. Most legislation advice systems support in finding relevant regulations quickly using hyperlinking techniques, but don’t support interpretation of the regulations. These systems can only be used by experts in the field. The system described in this paper can be used by less qualified people and helps these people to perform on a higher level.
5 CONCLUSION This paper described the problem of conceptual modelling and of selection of languages in the development of knowledge based systems. As an illustration of this problem a part of the development of a knowledge based system for fire-safety verification of office buildings has been described. Prior to starting the knowledge
284
J. de Gelder
based system development process the knowledge problem has been clearly formulated and a suitable modelling language has been selected. The paper described criteria for selecting suitable conceptual modelling languages taking into account the nature of knowledge in an application domain. It showed that the conceptual modelling language ‘decision tables’ is the most suitable language taking into account the nature of building regulation knowledge. The description of the knowledge based system for fire-safety verification of office buildings proves the usefulness of this language to model knowledge in this application domain.
REFERENCES 1. Hayes-Roth, F. & Jacobstein, N., The state of knowledgebased systems. Communications of the ACM, 1994, 37(3), 27-39. 2. Lucardie, G. L., Functional Object-Types as a Foundation
of Complex Knowledge-Based Systems. Computer Science, Technical University Eindhoven, 1994. 3. Rumbaugh, J., Object-Oriented Modelling and Design. Prentice-Hall, EngIewood Cliffs, NJ, 199 1. 4. Brachman, R. J., I lied about the trees, or, defaults and definitions in knowledge representation. AI Magazine, 1985, 6(3), 80-93. 5. Fenves, S. J., Tabular decision logic for structural design. Journal of the Structural Division, 1966, 92(6), 473-90. 6. Garrett, J. H. & Hakim, M. M., Object-oriented model of engineering design standards. Journal of Computing in Civil Engineering, 1992, 6(3), 323-47. 7. Garrett, J. H. & Fenves, S. J., A knowledge-based standards processor for structural component design. Engineering with Computers, 1987, 2(2), 219-38. 8. Garrett, J. H. & Fenves, S. J., Knowledge-based standard independent member design. Journal of Structural Engineering, 1989,115(6), 1396-411. 9. Cronembold, J. R. & Law, K. H., Automatic processing of design standards. Journal of Computing in Civil Engineering, 1988, 2(3), 255-73. 10. Lucardie, L., de Gelder, J. & Huijsing, A., The advanced knowledge transfer system. In CAAD Futures ‘95, Singapore, 1995.
PII:
Printedin Great Britain c954-1810/97/$17.00
SO954-1810(96)00043-X
Conceptual modeling of building regulation knowledge Johan de Gelder Arthur Andersen & Co., Business Consulting Knowledge Based Systems, Stadhondersplantsoen 29, Den Heag, The Netherlands
(Received for publication
8 November 1996)
In recent years knowledge has become more and more a critical production factor for many organisations. Adequate performance of many activities depends on the availability of knowledge. However, volume and complexity of knowledge increase more and more. Consequently the accessibility of knowledge decreases. Knowledge of fire-safety regulations is critical for architects to design fire-safe buildings and for local authorities to verify fire-safety of building designs. However, effective application of this knowledge in the Netherlands is a problem because of the volume, complexity and inaccessibility of the Dutch Fire-Safety Regulations. People in practice don’t understand and consequently misinterpret the regulations. A solution to this lack of knowledge is the development of a knowledge based system. In the development of knowledge based systems the conceptual modelling phase is an important one. In this phase knowledge of the application-domain is modelled using a conceptual modelling language.*This paper describes criteria for selecting a suitable conceptual modelling language taking into account the nature of knowledge in a particular application-domain. Further it explains what the nature of building regulation knowledge is and which conceptual modelling language is most suitable to represent this knowledge. Finally the paper describes and shows some contents of a knowledge based system that advises architects to design fire-safe buildings conforming to the regulations and helps local authorities to verify building designs with respect to fire-safety regulations. 0 1997 Elsevier Science Limited. Key words: knowledge, nature of knowledge, building regulations, based systems.
1 INTRODUCTION
knowledge
system containing
knowledge of effective and correct application of fire-safety regulations. In the Netherlands there are only a limited number of experts, who have sufficient knowledge of how to apply the fire-safety regulations effectively and correctly. If we are able to include knowledge of these experts into a knowledge based system, we can offer people in practice, who have to apply the regulations in practical building designs and design verifications, a personal expert on their desk.
Effective application of fire-safety regulations in the Netherlands by architects and local authorities is difficult because of the volume, complexity and inaccessibility of the Dutch fire-safety regulations. This often leads to misinterpretation and incorrect application of the regulations in building design. This is a serious problem, because the aim to develop and bring into effect fire-safety regulations is to guarantee design and realisation of fire-safe buildings. With voluminous, complex and inaccessible regulations this aim is hardly achieved. This problem can be categorised as a knowledge problem. The knowledge of people in practice, architects and local authorities, is insufficient to apply the firesafety regulations effectively. A solution to this knowledge problem is the development of a knowledge based
In order to develop a knowledge based system containing knowledge of experts in application of fire safety regulations, we have to model the fire-safety regulations. It is of great importance that the knowledge in the system is represented correctly, completely and consistently. Therefore, a lot of attention should be paid to the conceptual modelling phase in the development of a knowledge based system for fire-safety verification of office buildings. 273
274
J. de Gelder
This paper describes important aspects and decisions in the development of a knowledge based system for fire-safety verification of office buildings. Section 2 first describes in more detail practical problems in application of building regulations in general. Section 3 describes criteria for selecting suitable conceptual modelling languages taking into account the nature of knowledge in a particular application domain. Further section 3 describes the nature of building regulation knowledge and the consequences this nature has for the selection of a conceptual modelling language to model this knowledge. Finally section 4 describes and shows some contents of a knowledge based system that advises architects to design fire-safe buildings conforming to the fire-safety regulations and helps local authorities to verify building designs with respect to fire-safety regulations.
2 APPLICATION
OF BUILDING REGULATIONS
Effective and correct application of regulations is a complex and knowledge intensive task. In the application of Building Regulations the following knowledge problems can be recognised:
(1) Building
Regulations are voluminous and spread over many direrent documents. Because of volume
and spread it is hard to build up sufficient knowledge in order to apply the Building Regulations effectively. People in practice don’t have sufficient knowledge to determine which provisions are relevant in a specific situation and where they can find these provisions. Often relevant provisions originate from different documents and different places in one document. One is never sure to have found all relevant provisions.
(2) Provisions juridical
are hard to understand because of presentation. The provisions in the
Building Regulations are presented by text. Describing provisions by text and at the same time minimising the risk to create shortcomings in the rules, requires juridical formulations on a high level of abstraction. People in practice, however, are not interested in complex juridical formulations but in presentation of provisions directed towards their specific goals and activities. (31 Structure of Building Regulations and presentation
of provisions are often not connected with goals and activities of people in practice. In the building
process many different parties are operating in many different building phases. Each party has its own goals and activities and needs presentation of provisions directed towards these goals and activities. In fact each party needs a different cross-section of the Building Regulations and provisions presented in a goal-oriented way. Since the Building Regulations are only presented in
one way, all parties in the building process have problems to find the relevant provisions, interpret them correctly and translate them for practical use. (4) Descriptions of building objects (buildings, building
parts, building products and building materials) are often not directed towards application of the Building Regulations. A party in the building
process describes a building object from its own perspectives, including only properties relevant for its own goal. This description may be incomplete for another party. The description of a building that architects present to local authorities for verification is often incomplete. On the one hand it contains irrelevant information. On the other hand relevant information is missing. Mainly this is caused by lack of knowledge of the building regulation and lack of knowledge of what information is relevant to adequately perform a verification of conformance to the Building Regulations. Figure 1 graphically displays a part of the complexity in applying building regulations. It displays some goals and activities in which building regulations have to be applied to building objects. Each activity needs different parts of the building regulations. Activities, needing the same parts of the building regulations, may use the provisions differently depending on the different goals. The solution to these knowledge problems seems to be the development of many different goal-oriented descriptions of the Building Regulations for the benefit of specific parties and suitable to be used for specific activities. Depending on the activity only those provisions which are relevant to adequately perform the activity have to be included in a description. Depending on the goal the relevant provisions have to be presented in a goal-oriented way. These descriptions can be presented on paper. More effective is to include the goal-oriented descriptions in a knowledge based system. People can just run the system and, depending on the activity, goal and building object, only the relevant Building Regulation knowledge is presented and the system guides the activity towards the goal. Section 4 describes the development and some interesting parts of such a knowledge based system. The knowledge based system includes knowledge of the building regulations concerning fire-safety of office buildings. The fire-safety regulations are selected because this domain is experienced in practice to be the most complex part of the building regulations. First, section 3 describes the relationship between on the one hand the selection of a conceptual modelling language to model the knowledge for a knowledge-based system and on the other hand the nature of the knowledge. This relationship is first described for knowledge in general
275
Conceptual modelling of building regulation knowledge
Building object
X
definition of building requirements by client
Building Regu’ations conformanceverificationof by local authorities
Fire Safetyprovisions
Goals and activities Fig. 1. Heterogeneity in the application of Building Regulations. and after particular.
that
for
building
regulation
knowledge
in
3 SELECTION OF A CONCEPTUAL MODELLING LANGUAGE TO MODEL BUILDING REGULATION KNOWLEDGE During
the last decade
knowledge-based
systems
There exist many languages that can be used to model knowledge. Each language has its own characteristics. Not every language is suitable for representation of every kind of knowledge. Therefore we need information about the background of languages. What kind of knowledge can be modelled using a specific language? Before we are able to answer this question, we need to define what knowledge is.
have
become increasingly important for the daily practice of many organisations. Today they have even attained a permanent and secure role in trade and industry.’ Yet, the development of knowledge-based systems that are applicable in the daily practice of organisations, remains problematic. Many prototypes of knowledgebased systems simply never go into usage. It is of vital importance for the success of a knowledge based system that the knowledge of the application-domain is represented correctly, completely and consistently. A precondition for the specification, design and implementation of operational knowledge-based systems is therefore the availability of an adequate language to model knowledge.
3.1 Knowledge In AI research the question ‘What is knowledge?’ is often asked and answered. Many of these answers are rather academic, which are not useful as a practical support for understanding knowledge problems and for the selection of adequate languages to model knowledge. An academic definition of knowledge, that is practically useful to perform this selection, originates from Lucardie.* Lucardie defines knowledge as the competence to match an object to an object-type. In this definition objects are physical things, like a mammal or a fire-safe building, or abstract things, like malaria or a car defect diagnosis. Object-types are descriptions of
Fig. 2. Knowledge as the competence to match an object to an object-type.
276
J. de Gelder
physical or abstract things. The object-type ‘mammal’, for instance, defines the properties of a mammal. The object-type ‘fire-safe building’ defines the properties of a fire-safe building. A match of an object to an object-type is comparing a real-world object with the definition of an object-type. A match of a specific animal to the object-type ‘mammal’ is comparing the properties of the animal with the definition of the object-type ‘mammal’. If the animal (the object) has properties satisfying the definition of a mammal (the object-type), then the object matches the object-type and consequently the animal is a mammal. Figure 2 displays this matching process graphically. Experience teaches that many knowledge problems can be represented in this abstract schema of matching an object to an object-type. Representation of knowledge problems in this schema helps to understand the problem better and supports the selection of adequate languages for the benefit of knowledge based system development. In knowledge based system development the definition of an object-type has to be modelled and knowledge about the objects has to be retrieved and stored in a database in order to be able to match the objects to the definition of the object-type. In this process only that knowledge about the object has to be stored in the database that is sufficient to perform the match to the definition of the object-type. In the case of matching of animals to the definition of mammals, only that knowledge of animals should be retrieved and stored that is important to classify an animal as a mammal. Here, for instance, the number of legs of the animal is not important and need not be stored. Since the relevance of knowledge about the objects depends on the definition of the object-type, the definition of the object-type has to be constructed first. The questions here are: ‘What does this definition look like?’ and ‘What languages are suitable to model and represent this definition?‘. The answers to these questions depend on the nature of knowledge. 3.2 Nature of knowledge With respect to the nature of knowledge four views can be recognised in practice. In this paper we refer to these views using the following names: 1. 2. 3. 4.
Classical view. Probabilistic view. Prototypical view. Functional view.
Fig. 3.
These four views will be discussed in the next subsections. Additionally examples of well-known ceptual modelling and knowledge representation guages able to represent knowledge according to view will be given.
four conlaneach
3.2.1 Classical view of knowledge The classical view states that an object-type can easily be defined. It’s easy to define the conditions of an object-type and properties of objects can easily be compared with these conditions. An example of a classical defined object-type is the definition of an elephant as an animal with the following conditions: trunk, grey colour, four legs and big body. Having this definition it’s easy to match an object to this definition by comparing the object’s properties with the conditions of the object-type. Objects having a trunk, grey colour, four legs and a big body, for instance, match to the definition of the object-type ‘elephant’. Consequently these objects are elephants. Figure 3 schematically shows the matching according to the classical view. Object-types that can be defined according to the classical view are easily represented in the language ‘records’. A record represents a fixed sequence of condition values. The meaning (object-type) of these attributes is stored in a so called data dictionary. A number of records (objects) matching the object-type is called a table. A record can only be stored in a table if it has values for each condition. It will be clear that in practice definitions of objecttypes are not as easy as supposed by the classical view. If an elephant has an accident and loses his trunk, this elephant doesn’t match the definition of the classical object-type ‘elephant’. Consequently this animal is not an elephant anymore according to the definition. But in fact it’s still an elephant, so the definition is not correct. Eventually this problem can be solved by leaving the first condition, trunk, out of the definition, but this is not really a solution, because the elephant can also by accident lose one leg or change colour because of a disease. If these problems are solved by leaving the colour and legs condition out as well, only the big body condition is left. Then another problem is created: a rhino and a hippo match the definition of the objecttype ‘elephant’ and the knowledge based system will recognise these animals as elephants. Although human beings don’t have many problems in recognising an animal as an elephant, it appears that it’s not very easy to give a clear definition. A simple objecttype, like an elephant, has a lot of fuzzy conditions, which are hard to define. In order to give computer
Matching in the classical view.
Conceptual modelling of building regulation knowledge
programs the ability to catch this fuzziness, alternative views on the nature of knowledge have been developed. In the next three subsections these views will be discussed: the probabilistic view, the prototypical view and the functional view. 3.2.2 Probabilistic view of knowledge Like the classical view, the probabilistic view states that an object-type can easily be defined. The difference is that the probabilistic view states that it’s not always possible to be 100% sure of all conditions of the objecttype. Sometimes the occurrence of one condition can compensate the absence of another condition. To be able to match objects probabilities are assigned to each condition of the object-type and an objective function is defined. Sure conditions are assigned a high probability. Unsure conditions a low probability. Matching takes place by comparing properties of an object with the definition of the object-type and filling in the probabilities of the satisfied conditions in the objective function. If in the end the set of satisfied conditions is sufficient to fulfil the objective function, the object matches the definition of the object-type. If, in the elephant example, the condition ‘trunk’ is assigned the probability 0.3, the condition ‘grey colour’ the probability 0.2, the condition ‘four legs’ the probability O-1 and the condition ‘big body’ the probability 0.4 and the objective function is a simple addition of probabilities with a minimum score of 0.5, then, for instance, elephants missing a trunk and animals missing a grey or yellow colour and one or more of their legs still match the definition of the object-type. Figure 4 schematically shows the matching according to the probabilistic view. The objective function is a simple addition of probabilities. This simple example shows that condition Y should always be satisfied and conditions X and 2 can compensate each other. This means that if condition X is not satisfied, condition Z must be satisfied. If condition Z is not satisfied, condition X must be satisfied. Examples of languages that support the definition of object-types according to the probabilistic view are:
277
multi-criteria and regression techniques. Also many neural networks represent knowledge in a probabilistic way. Using a neural network, the object-type is not explicitly defined, but derived from a large set of objects matching the definition of the object-type. In contrast with the classical view, the probabilistic view offers abilities to match objects to the definition of the object-type, also if not all conditions are satisfied. The starting point of the probabilistic view is the assumption that conditions can compensate each other. This is however not always a valid assumption. In many definitions of object-types conditions exist which must be satisfied anytime or must be satisfied depending on other conditions. If this is true, defining object-types according to the probabilistic view will not deliver reliable matching results. 3.2.3 Prototypical view of knowledge In contrast with the classical and the probabilistic view, the prototypical states that it’s not possible to define a set of conditions all objects must satisfy in order to match the object-types. The question is not: does the object match the object-type? The question is: how well does the object match the object-type? An object matching many conditions of the object-type better matches the object-type than an object matching only a few conditions of the object-type. An object matching all conditions of the object-type is called a prototype or a stereotype object. The conditions of the object-types are called (proto- or stereo-) typical conditions. If in the definition of the object-type ‘elephant’ trunk, four legs and grey colour are defined as (proto- or stereo-) typical conditions, an object with a trunk, four legs and a grey colour is called a (proto- or stereo-) typical elephant. An elephant with, for instance, a brown colour caused by a disease or without trunk because of an accident is not a (proto- or stereo-) typical elephant anymore, but still an elephant. The question then arises: What conditions must an object at least satisfy in order to still be classified as an elephant. Prototypical languages like semantic networks, frames, object-oriented modelling languages like 0MT3 and data modelling languages like
2OX+4OY+30%=60
Fig. 4. Matching in the probabilistic
view.
278
J. de Gelder
Fig. 5. Matching in the prototypical view. NIAM, solve this problem by offering facilities to define deviating prototypes. An elephant with a brown colour caused by a disease is then a (proto- or stereo-) typical sick elephant and an elephant without trunk because of an accident is a (proto- or stereo-) typical trunkless elephant. Figure 5 shows schematically the matching according to the prototypical view in case facilities for defining deviating prototypes are available. In this example three prototypes of the same object-type are defined. Objects satisfying all conditions (X, Y and 2) match the first prototype. Objects not satisfying condition Z, but satisfying conditions X and Y, match the second (deviating) prototype. Objects not satisfying condition X, but satisfying conditions Y and Z, match the third (deviating) prototype. Although the prototypical view offers more abilities to represent knowledge of reality than the classical and probabilistic view, there are still a number of conceptual problems.4 Earlier the prototype ‘elephant’ was defined with the conditions trunk, four legs and grey colour. In order to match sick and trunkless elephants as well, two deviating prototypes were defined. The prototype ‘sick elephant’ with the conditions trunk, four legs and brown colour and the prototype ‘trunkless elephant’ with the conditions four legs and grey colour. Suppose an elephant loses his trunk, but also two of his legs. This elephant matches none of the prototypes. In the prototypical view this can be solved by defining another deviating prototype ‘trunkless two-legged elephant’ with the necessary conditions two legs and a grey colour. This generates the problem again that also animals other than elephants exist with two legs and a grey colour. A heron, for instance, is a bird with two legs and a grey colour. This bird matches the object-type ‘trunkless twolegged elephants’ and hence is classified as a typical trunkless two-legged elephant. This example shows that the prototypical view has limitations in case many different deviating prototypes have to be defined. Another conceptual problem in the prototypical view is the definition of the object-type or prototype itself.
This is not always obvious. How should a prototype be defined? In fact the prototypical view states that the prototype should be defined in the way an object (matching the prototype) presents itself in the real world most of the time. But how does an object present itself in the real world? How, for example, does a building presents itself? A building, for instance, can be defined in many different ways. In the real world many different buildings exist. A prototypical approach would be to investigate which types of buildings exist and to define a general prototype ‘building’ and deviating prototypes for each type of building. The issue is which types of buildings must be distinguished and which conditions must be defined for each type. Possible building types could be: office buildings, lodging buildings and dwellings. But why choose such a distinction. Why not choose a distinction of buildings into public buildings and private buildings or buildings with and without sleeping accommodation. This example demonstrates that the different ways objects present themselves in reality cannot be the starting point for defining object-types. How do objects present themselves in the real world? Does the real world show office buildings, lodging buildings and dwellings? Does the real world show public buildings and private buildings? Does the real world show buildings with and without sleeping accommodation? What’s the best detini’tion for buildings? These are questions that are hard to answer in the prototypical view. The functional view has answers to these questions. 3.2.4 Functional view of knowledge Like the prototypical view the functional view recognises that in the real world objects present themselves in many different ways. In contrast with the prototypical view, the functional view explains this by stating that people observe and define objects taking in mind a certain goal or viewpoint. According to the functional view there is no best definition of an object-type. A definition is goaldependent. If, in defining a building, the goal is to
Conceptual modelling of building regulation knowledge
determine whether a building has sleeping accommodation or not, the object-type ‘building with sleeping accommodation’ has to be defined by defining the conditions an object must satisfy in order to be a ‘building with sleeping accommodation’. A building not satisfying the defined conditions automatically is a building without sleeping accommodation. On the other hand if the goal is to determine whether a building is a private building or a public building, the objecttype ‘private building’ has to be defined by defining the conditions a building must satisfy in order to be a ‘private building’. In the functional view the goal also determines what conditions are relevant for the definition of the objecttype. A wall in a building must, for instance, satisfy a large number of conditions. A wall must satisfy sound proofing conditions, fire-safety conditions, constructive conditions, etc. Verifying fire-safety of a wall requires completeb different conditions from verifying sound proofing of a wall. The consequence is that the definition of the object-type ‘wall’ defined for the benefit of firesafety is completely different from the object-type ‘wall’ defined for the benefit of sound proofing. If walls have to be verified by a knowledge based system on both firesafety and sound-proofing, then two object-types have to be defined. It’s possible that a specific wall matches the object-type ‘wall’ defined for the benefit of firesafety, but doesn’t match the object-type ‘wall’ defined for the benefit of sound proofing. Another important aspect of the functional view is the recognition that objects with different properties can all match the same object-type. When people, for instance, intend to buy a new car, they formulate a number of conditions (the object-type) the new car (the object) must satisfy. It appears in practice that many different cars satisfy these conditions. This is because conditions are defined not independently but dependent on other conditions. An example: someone may define that the car’s price shouldn’t exceed 20000 dollars, but, if a car
Fig. 6.
219
doesn’t have a sun roof, the price shouldn’t exceed 19000 dollars. This example shows that the condition ‘price’ is not an independent condition, but a condition dependent on the condition ‘sun roof’. Another condition may be: the car should have a car radio and two doors, but, if for the same price a car can be found with four doors, the car radio is not necessary. This example shows that the condition ‘car radio’ is not always relevant. Its relevance depends on the value of the conditions ‘number of doors’ and ‘price’. Further this example shows that a car with two doors and a car radio is equivalent to a car with four doors and without a car radio. In the functional view this mechanism is called ‘functional equivalence’. This means, taking into account the buyer’s goals, the two alternatives are equivalent. Possibly these two alternatives are not equivalent for another buyer with other goals. So, the relation of an object-type definition to a specific goal is of vital importance. This car-buying example shows that the definition of an object-type can be very heterogeneous. Conditions are not independent, but their values depend on the values of other conditions. Conditions are, dependent on other conditions, sometimes relevant and sometimes irrelevant. Because of this, objects with completely different properties may all match the same object-type and hence are functional equivalent. Figure 6 schematically shows the matching according to the functional view. In this example two objecttypes are defined for two different goals. Three objects are displayed. The first object only matches the definition of the first object-type. The third object only matches the definition of the second object-type. The second object matches the definition of both object-types. The conditions of both object-types are conditionally defined. An object matches the definition of the first object-type if it satisfies conditions X and 2. Condition Y is in this case irrelevant. However, if condition X is not satisfied, condition Y must be
Matching in the functional view.
280
J. de Gelder
satisfied and condition 2 is not relevant. An object matches the second object-type if it satisfies the conditions X and Y. Condition Z is not relevant. However, if condition Y is not satisfied, condition Z must be satisfied. Examples of languages that support the definition of object-types according to the functional view are: logic and languages based on logic, like decision tables and production rules. Decision tables have the advantage of having the ability to explicitly express functional equivalence (see section 3.3). In this sense decision tables are the most powerful language based on the functional view of knowledge. In practice matching often takes place as viewed by the functional view of knowledge. In many cases conditions are not independently defined, but dependent on other conditions. Often conditions are only relevant or have variable values depending on the values of other conditions. These dependencies may differ depending on a specific goal. If matching takes place like this or, in other words, knowledge has this nature, a language able to represent dependencies between conditions should be selected. Languages based on a classical, probabilistic or prototypical view of knowledge are not able to represent this kind of knowledge adequately.
3.3 Nature of building regulation knowledge Like any other regulations, building regulations contain a lot of interdependencies between conditions. Figure 7 shows a part of Article 235 of the Dutch Building Code. Article 235 describes provisions concerning escape ways from a smoke compartment. Article 235 stipulates that in principle each smoke compartment should have at least two independent escape ways. This can be realised in two different ways. From an entrance of a smoke compartment people can escape in two different and independent directions (part 1) or a smoke compartment has two entrances, each leading to at least one
independent escape way (part 2b). Independent means: escape ways are not coming together somewhere inside the building. In principle there must be two independent escape ways from a smoke compartment, but in specific situations it is allowed that a smoke compartment has only one escape way. Parts 2a, 2c, 3, 5 and 6 of Article 235 describe provisions for these situations. So, if it’s not possible to escape from a smoke compartment via two independent escape ways, one has to verify this smoke compartment for conformance to parts 2a, 2c, 3, 5 and/or 6. Article 235 of the Dutch Building Code contains a number of conditions whose relevance or value depends on other conditions. Further this article enables escape ways to be designed in different (functionally equivalent) ways. The dependencies between conditions and the existence of functionally equivalent solutions a& hard to recognise reading Article 235 iti its textual representation. A solution to this problem is representing Article 235 in a decision table. Figure 8 shows this decision table. Condition C4, for example, is relevant depending on other conditions. Condition C4 is only relevant if the smoke compartment is not situated on the ground floor, people have to escape via a fire proof staircase and the user surface of all smoke compartments, which have to pass this staircase to escape to the site, doesn’t exceed 1OOOm’.In all other cases condition C4 is not relevant. The value of condition C3 depends on the value of other conditions. If the smoke compartment is situated on the ground floor, the user surface of all smoke compartments, which have to pass the single escape way, is not allowed to exceed 250m2. The same requirement is valid if the smoke compartment is not situated on the ground floor and the escape way is not a safety staircase nor a fire proof staircase. But if the smoke compartment is not situated on the ground floor and the escape way is a fire proof staircase, then the user
Escape in case of fire Article
235
1. An entrance of a smoke compartment as meant in article 234, part four to seven, must be situated next to the site or next to a room which contains two independent escape ways. 2. Contrary to part I, the entrance may be situated next to a room which contains one single escape way, if: a. the entire user surface of the smoke compartments dependent on the single escape way does not exceed 250 m2 ; b. the smoke compartment has two entrances each leading to at least one independent escape way, or c. the escape way is a fire proof staircase. 3. The entire user surface of the smoke compartments dependent on the single escape way, as meant in part 2c, excluded an escape way via a safety staircase, may not exceed 1000 m2. 5. The distance between an entrance of a smoke compartment as meant in part I and an entrance of the office building, may not exceed 30 m, if part 2c is applied. 6. Pan 5 is not applicable if the escape way is a safety staircase. Fig. 7. A part of Article 235 of the Dutch Building Code.
281
Conceptual modelling of building regulation knowledge Oneescapewayfroma
smokecomputmmt
Cl
L.ccath smoke
other floor
Ground tloer
cempttiment SClfcty staifcasc
c2
Type of staircase
c3
user smfacc of all smoke compartments dependentonthc singleescapeway
=<250 m2
c4
Distancebetween
-
stailulse entmnce
>2M m2
Fire proof staircase
othutypcof S-
=clOOOm2
=<30 m
>30m
>looo m2
=Q50 m2
>2SOm2
-
and office
Fig. 8. Article 235 of the Dutch Building Code in a decision table representation. surface of all smoke compartments, which have to pass this staircase, is not allowed to exceed 1OOOm’. This demonstrates that the allowed user surface is not a fixed value. The value depends on the value of the conditions Cl and C2. For example, a user surface of 500m2 is sometimes allowed and sometimes not allowed, depending on the values of conditions Cl and C2. The decision table clearly shows four functional equivalent solutions (Rl, R3, R4 and R7). None of the four conditions (C 1-C4) has a fixed value independent of other conditions. The conditions C2-C4 are only relevant dependent on the value of other conditions. The allowed value of condition C3 depends on the values of conditions Cl and C2. Most articles in the Dutch Building Code, and also articles in many other legislations, are like Article 235. A lot of interdependencies between conditions exist, leading to many different functional equivalent ways to satisfy the requirements. The conclusion must be that knowledge in this application-domain must be modelled and represented according to the functional view of knowledge. The example demonstrates that ‘decision tables’ is an excellent language to represent this kind of knowledge because of the ability of this language to show the interdependencies between conditions and to show functional equivalent solutions. Also other researchers came to this conclusion.5-9 Although the difference with these researchers is their use of decision
tables to represent only quantitative knowledge instead of qualitative knowledge on a conceptual level, as presented in this paper.
4 KNOWLEDGE BASED SYSTEM FOR FIRE SAFETY VERIFICATION OF OFFICE BUILDINGS Section 3.3 showed that building regulation knowledge must be modelled and represented according to the functional view of knowledge. Values of conditions may vary depending on values of other conditions. Conditions are sometimes relevant and sometimes irrelevant depending on values of other conditions. And many different functional equivalent solutions may exist. Further section 3.3 showed that ‘decision tables’ is an excellent language to represent this kind of knowledge. Decision tables are able to represent conditional between conditions and decision tables clearly represent functional equivalence. Therefore we decided to use decision tables to represent the knowledge for the knowledge based system for fire safety verification of office buildings. We developed a knowledge based system shell based on decision tables, called AKTS.” AKTS is written in Prolog and offers a user-friendly graphical editor for editing decision tables and is running on an Apple Macintosh. Knowledge represented in decision tables
vetifieation of a
Fig. 9. The matching problems the knowledged based system is based upon.
282
J. de Gelder
can immediately be consulted by AKTS. Additional to decision tables Prolog can be used to represent knowledge or to implement user-interface aspects. Consultation of knowledge using AKTS is possible on an Apple Macintosh and Windows. We started the development of the knowledge based system for fire verification by identifying object-type and object and defining the matching problem. Since the knowledge based system had to support both architects (design) and local authorities (verification) we defined two matchings problems, one from a design perspective and one from a verification perspective. Figure 9 displays the earlier introduced schematic representation of a matching problem, filled in for both design and verification of a fire-safe office building. The definition of the object-type ‘design of a fire-safe office building’ contains knowledge about the properties a particular design must have in order to be a correct design of a fire-safe office building. At the same time the definition of the object-type ‘verification of a fire-safe office building’ contains knowledge about the properties a particular design verification must have in order to be a correct fire-safety verification of an office building design. Figure 10 shows the decision table representing the object-type ‘design of a fire-safe office building’. A particular office building design is a design of a fire-safe office building if the six design aspects (Cl -C6) all satisfy the fire-safety regulations. Splitting up the design into a number of sub-designs generates in fact a number of sub-object-types. The design of fire-safe escape
ways, for instance, is expressed by the sub-object-type ‘design of fire-safe escape ways’. As an example a part of the conceptual model of this sub-object-type will be described in more detail. The design of fire-safe escape ways is performed after the design of smoke compartments. This is because the fire-safety regulations define escape ways from the exit of a smoke compartment. In section 3.3 we explained that in principle each smoke compartment must have two independent escape ways. Smoke compartments having only one escape way are allowed if a number of other requirements is satisfied. The decision tables in Fig. 11 display the definition of the sub-object-type ‘design of fire-safe escape ways’. The second decision table of Fig. 11 contains the same knowledge as the decision table in Fig. 8, but structured differently. The decision table in Fig. 8 represents the knowledge from a verification perspective. The decision table in Fig. 11 represents the knowledge from a design perspective. A designer needs as output of the system a list of requirements to satisfy in order to design a firesafe office building. A verifier needs as output of the system an indication whether the design satisfies the requirements. Both have different goals in applying the building code. And different goals lead to different object-types, whose definitions differ, although they contain the same knowledge. The knowledge for all other design aspects has been modelled similarly to the knowledge concerning fire-safe escape ways. The knowledge based system contains in
Design of a fire-safe office building Doesn’t satisfy fire-safety requirements
Satisfies fire-safety requirements
Doesn’t satisfy fire-safety requirements
Satisfies fire-safety requirements
Doesn’t satisfy tire-safety requirements
Satisfies fire-safety requirements
c4
Design of fire-safe staircases
c5
Design of fire-safe room layouts
f cd
Al
=t
Design of fire-safe entrances aad exits Design of a fire-safe office building
Doesn’t satisfy fire+ety
Satisfies fire-safety req inments
Satisfies fire-safety requirements
Satisfies
tire-safety requirements
c
Doesdt satisfy fire-safety requirements
Doeso’t
Doesn’t satisfy satisfy fire-safety fire-safety reauirements requirements R3
I I
R4
Fig. 10. The object-type ‘design of a fire-safe office building’ represented by a decision table.
283
Conceptual modelling of building regulation knowledge Design of fire-safe escape ways >I
I
Number of escape ways from smoke compartment
I
No
I
Dccslttsatisfy
Satisfies
fin-safety requirements
~
Yes
fUC-Safety
requirements
satisfies fire-safety requirements
Doesn’tsatisfy fire-safety requirements
Satisfies fire-safety reauinments
Doesn’tsatisfy fire-safety reuuirements
----Satisfies
I I
fife-safety
wayi
reauirtments I I
Rl
t I
Doesn’tsatisfy fm-safety rrauirements
R2
I
I
I I
Satisfies tire-safety reauirements
R3
I
R4
I I
1
1
R5
I I
Design of fire-safe escape way< in case of one escape way from a smoke compartment
=c250 m2
I
1
Other floor
Groundfloor
1
>250 m2, =
>lCQOm2
smoke compartments dependenton the single =<30 m staircase entrance and office building exit The user surface of all smoke dEggri%e single escape way is not greaterthan 250 m2 (article 235, part 2a)
The escape way
satisfies the requirementsof article 235, part 2a of Toz$lding
The escape way only satisfies the nq&zments of the Building code (article 235, part 2c, 3 and 5), if the escape way is a fire oroof
Satisfies
I
>30In
The escape way only satisfies the requirementsof the Building code (article 235, part 5 and 6). if the escape way is a safety staircase Satisfies tire-safety requirrments
fire-safety requirements
The escape way
only satisfies the requirementsof the Building code (article 235, PM 31, if the escape
way is a safety staircase Satisfies tire-safety requirements
smoke &mpa&ent R5 Fig. 11. The object-type ‘design of fire-safe escape ways’ represented by two related decision tables.
total 163 related decision tables. The system contains two independent modules, a design module and a verification module. The design module asks the designer a number of questions about his or her design and gives as output the requirements the designer must satisfy in order to make the building fire-safe. The verification module asks the user a number of questions about a completed design and gives as output: design satisfies or design doesn’t satisfy the fire safety requirements. If the design doesn’t satisfy the fire safety requirements, the verification module explains why the design doesn’t satisfy. The system is running on Windows and has been sold to several design firms and local authorities in the Netherlands. The system contains a lot of (graphical) explanations in order to help the user answering the questions and understanding the output correctly. Although there are also other systems tackling legislation advice, the uniqueness of the system described in this paper is the explicit representation of the fire safety
regulation knowledge in a way interpretable by a computer. The systems helps a user not only in finding the relevant regulations, but also in interpreting and correctly applying them. Most legislation advice systems support in finding relevant regulations quickly using hyperlinking techniques, but don’t support interpretation of the regulations. These systems can only be used by experts in the field. The system described in this paper can be used by less qualified people and helps these people to perform on a higher level.
5 CONCLUSION This paper described the problem of conceptual modelling and of selection of languages in the development of knowledge based systems. As an illustration of this problem a part of the development of a knowledge based system for fire-safety verification of office buildings has been described. Prior to starting the knowledge
284
J. de Gelder
based system development process the knowledge problem has been clearly formulated and a suitable modelling language has been selected. The paper described criteria for selecting suitable conceptual modelling languages taking into account the nature of knowledge in an application domain. It showed that the conceptual modelling language ‘decision tables’ is the most suitable language taking into account the nature of building regulation knowledge. The description of the knowledge based system for fire-safety verification of office buildings proves the usefulness of this language to model knowledge in this application domain.
REFERENCES 1. Hayes-Roth, F. & Jacobstein, N., The state of knowledgebased systems. Communications of the ACM, 1994, 37(3), 27-39. 2. Lucardie, G. L., Functional Object-Types as a Foundation
of Complex Knowledge-Based Systems. Computer Science, Technical University Eindhoven, 1994. 3. Rumbaugh, J., Object-Oriented Modelling and Design. Prentice-Hall, EngIewood Cliffs, NJ, 199 1. 4. Brachman, R. J., I lied about the trees, or, defaults and definitions in knowledge representation. AI Magazine, 1985, 6(3), 80-93. 5. Fenves, S. J., Tabular decision logic for structural design. Journal of the Structural Division, 1966, 92(6), 473-90. 6. Garrett, J. H. & Hakim, M. M., Object-oriented model of engineering design standards. Journal of Computing in Civil Engineering, 1992, 6(3), 323-47. 7. Garrett, J. H. & Fenves, S. J., A knowledge-based standards processor for structural component design. Engineering with Computers, 1987, 2(2), 219-38. 8. Garrett, J. H. & Fenves, S. J., Knowledge-based standard independent member design. Journal of Structural Engineering, 1989,115(6), 1396-411. 9. Cronembold, J. R. & Law, K. H., Automatic processing of design standards. Journal of Computing in Civil Engineering, 1988, 2(3), 255-73. 10. Lucardie, L., de Gelder, J. & Huijsing, A., The advanced knowledge transfer system. In CAAD Futures ‘95, Singapore, 1995.