• No results found

5 KNOWLEDGE-INTENSIVE DESIGN SUPPORT

5.2 Model-based design support

5.2.1 Introduction to modelling on the knowledge level

Term ‘knowledge level’ was coined by Alan Newell (1982) in order to distinguish a higher level of information processing in addition to the lower, ‘symbol level’. Both levels refer to different processes a knowledgeable agent is performing whilst solving a problem or doing a (intelligent) task. Symbol level is concerned mainly with a description of syntactic operations of an agent, which involve processing and manipulation of certain available ‘symbols’. For instance, the number theory in the mathematics uses ‘numbers’ as the basic symbols and a few simple rules to solve the problems. On the other hand, knowledge level is concerned with knowledge that is used and created by an intelligently behaving agent. One point for the investigation on the knowledge level is what knowledge concepts are present or lacking when solving a task. Another, perhaps even more interesting question, is how available knowledge couples the actions of an agent to the task being solved. How does it relate the individual actions to each other, and to the environment in which they take place?

A careful reader may have already noted that the statements above do not make any commitment regarding the form the knowledge-level models may have, nor the internal representation they may be implemented in. As was already stated in section 3.2.1, the main advantage of this ‘higher tier’ in problem solving is that it abstracts knowledge as a competence, which is independent of the physical representation of symbols and concepts it manipulates (Newell and Simon 1976). This attitude towards knowledge acted as an important impetus for artificial intelligence research in general and knowledge-based systems in particular. Moreover, as it is the case with modelling in a general systems theory (see also section 3.2.3), one can build models that are closer or more distant approximation of the real world (Klir 1985). It is fully understandable that many different implementations of general knowledge-level models can be found throughout the history of AI (Stefik 1995). Some of the proposals that have a direct connection with design are briefly discussed later, in section 5.2.2. In this section, we concentrate on the features that make this knowledge-level account interesting for design as an intelligent problem solving activity.

Let us discuss several properties of the knowledge-level models that we see as beneficial for design.

First, we return to the statement from Newell’s definition at the beginning of this section. Namely, that it is an agent’s knowledge of a specific domain that determines its actions during a problem-solving episode in a particular environment. Different actions of an agent that seem otherwise random and unrelated, have a sound common ground in the knowledge the agent has about the domain and uses in it. Thus, a knowledge-level model may be perceived as a kind of indexing or referential framework, to

which the agent’s actions are related. However, such an index is usually very complex, far richer than the indexes that are known, for instance from libraries. Typically, a knowledge-level model is not a linear structure. It is a richly interconnected network of the records that in addition to determining the agent’s actions, defines also the ‘meaning’ of those actions. In other words, it is the agent’s knowledge that gives to any individual action its proper place in problem solving. Thus, the knowledge endows the agent’s actions with some semantics and context, in addition to a strict syntax.

Another aspect of knowledge-level models that distinguishes them from symbol-level implementations is that they can be shared and easily transferred among multiple implementations.

This aspect is typically illustrated using an analogy with computers6. Hardware (incl. a processor, storage units, memory units) is unique for every computer – it is a symbolic representation framework.

However, software (operating system, applications and data) is more flexible, and to the certain extent, can be shared between different computers. When we replace term ‘computer’ with a more generic term ‘agent’, it is possible to perceive knowledge-level models as that layer in the information processing, on which the collaboration between the agents, and knowledge sharing may be observed. In order to share knowledge, the agents must subscribe to a common expressive mechanism, so that they can use the same knowledge in a similar manner. They must share the semantics for interpreting the concepts from a transferred knowledge-level model. An example from our everyday life of a sharable knowledge-level model of an external world, commonly applied in practice by almost everyone is a human language developed as a means to communicate, i.e. to share, publish and acquire knowledge.

Having discussed the most important features and advantages that are brought into the game by the knowledge-level systems informally, we may now turn to definitions that are more formal. One particular approach to modelling on the knowledge level is using an entity known as a common ontology. Ontology as a term (and a scientific theory) has been known in philosophy for several centuries. It denotes a theory that is concerned with the nature and relations of being. This philosophical term was brought to the computer science and consequently ‘AI in design’ community by researchers from Stanford University during their research into knowledge interchange. Gruber (1993) understands ontology in the world of computational systems as ‘an explicit specification of conceptual representation’. He justifies such a view with pointing to the fact that ‘in knowledge-based systems what exists is only what can be represented’. Chandrasekaran, Josephson et al. (1999) add to Gruber’s view that ontology is typically ‘a representation vocabulary specialised to some domain or problem matter’. An agent can then use such a vocabulary to express and represent its knowledge related to the actions performed in connection with a particular problem or task.

An ontology is thus an account and representation of an explicit portion of what is often referred to as a ‘domain theory’ or ‘background knowledge’. An ontology may certainly be developed for many different purposes. For instance, for a consistent naming of symbols that are manipulated in a particular domain or for a definition of important relations among certain objects. Although ontology defines the conceptual objects and symbols of a particular domain, this definition is clearly on the knowledge level. An agent does not define the implementations and the individual bits and pieces of the objects,

6 This is definitely, not the most fortunate metaphor (as many computer users would agree), but it shall suffice in making a point we want to argue.

but rather it assigns certain meanings to such objects. As it is defined, the only commitment made by ontology is regarding the interpretation of the objects and relations in a domain. Ideally, no commitment at all is made in respect to the agent’s underlying internal representations. On the contrary, it is often the case that the commitments, which an agent makes using a particular ontology, may have several different internal (or symbol-level) representations. An ontology is thus inherently a knowledge interchange framework that has a competence of referring to different knowledge sources and representations through the same channel or ‘interface’.

If multiple agents (including mixture of human and artificial) subscribe to the same ontological commitments in respect to a particular domain, these commitments serve as a common or shared ontology. Such an ontology, when shared among different agents, provides a vocabulary (similarly as a human language does) for the exchange of information. At the same time, ontology defines a vocabulary not only for expressing the simple terms from a domain, but also allows assertions about the world that are more complex. For instance, a chunk of data acquired in an empirical study of the world performed by an agent may be rather poor in respect to yielding an ‘immediate’ knowledge.

Measured temperature of ‘39.5°C’ may have different implications in different domains. In forecasting the weather, it may imply a hot day; in medicine, it confirms a serious fever of a patient. Thus, the full potential of a particular chunk of data is revealed only when it is related to other data and knowledge of a particular domain. In other words, it must be interpreted in the domain ontology; only then, further complex assertions may be made. Generally, the ‘profit’ from the information acquisition is greater for the interpreted (or ontologically grounded) ‘knowledge’ than it was for the ‘standalone data’.

For a single subject matter several ontologies may be developed. Van Heijst, Schreiber et al. (1997) organise ontologies into hierarchical structures, and talk about ‘upper-level’ and ‘lower-level’ models.

As they argue, some knowledge has often more generic nature than the other does. In some cases, knowledge may be used in many different problems; whereas in other cases it is very narrowly bound to a particular problem or task. An example often quoted throughout the knowledge modelling literature considers a ‘diagnostics’. Accordingly, the main principles of diagnostics are invariant whether one works as a general practitioner in medicine, a computer support specialist, or a shop-floor technician. Terms as ‘cause’, ‘effect’ or ‘location’ are sufficiently generic to be expressed by an upper-level ontology of generic diagnostics tasks. These terms however, may be fine-tuned for the individual domains. For instance, doctors usually talk about ‘symptoms’ as a specific type of ‘effects’; they distinguish several specific ‘locations’, such as ‘skeletal apparatus’ or ‘digestive system’. The same terms specified for the domain of machine diagnostics may include e.g. ‘power distribution apparatus’,

‘mechanical apparatus’ or ‘input/output system’ as specific ‘locations’. Such specific terms may be grouped into a ‘lower-level’ ontologies to emphasise their association with particular specific domains.

The relation between a more abstract ontology and the specific ontologies is typically hierarchical.

A significant part of the research community distinguishes between domain- and task-oriented ontologies that can be easier to re-use and share than highly specific, problem-oriented ontologies (Motta 1997; Chandrasekaran, Josephson et al. 1998; Motta and Zdrahal 1998). At this point, we can comment on one often-cited characteristic of ontologies that was not presented in the definitions above – the ontology re-usability. In the above definitions, it was only mentioned that agents could share an

ontology as a common knowledge-level model, similarly as a human language is shared among the different people. It must be noted that such a sharing can be understood differently according to two basic paradigms. First, a common ontology may be shared ‘spatially’; i.e. there are multiple, ‘physical’

agents that use the same ontology to mediate and communicate their mutual knowledge exchange.

Alternatively, an ontology may be shared ‘temporally’; i.e. the agent can use knowledge expressed using a certain ontological commitment made at a different time, usually in the past. In the most generic case, sharing may occur along both paradigms – one agent may use knowledge acquired and published by a different agent in the past if both of them commit to the same, shared ontology. Some researchers – e.g. Motta (1997), refer to the sharing on a spatial paradigm as (proper) ‘knowledge sharing’, in order to distinguish it from the temporal paradigm that is often called ‘knowledge re-use’.

Nonetheless, both terms essentially argue the same – an ontology can be shared by the multiple domains, agents, and problems, or it may be re-used in the different domains, tasks, or problems. From this reason, the condition of the re-usability of knowledge-level model was not particularly emphasised in the definitions above and in section 3.2.1.