Esotericism & Natural Sciences

TOWARDS PARASEMIOTICS OF LOOSE DOMAINS

 V.S.Lozovskiy*, KDS-2001

 

*Institute of Market Economy and Ecology, Ukrainian Academy of Sciences
29, Francuzskiy Boulevard, Odessa, 65044, Ukraine

 

The most important things, once too often, are weightless. It looks like here the most import­ant was a smile. The main point is frequently a smile.

Antoine De Saint-Exupéry, A Letter to a Hos­tage
ABSTRACT

Loose domains are application domains, for which it is hard to work out rigorous, stable, time invariant, complete and consistent descriptions. Majority of applications are from this class. It is shown, that in the search of efficient knowledge representation means for such domains, one can start from IDEF0 formalism, which supports several important requirements to know­ledge representation and handling systems on the stage from knowledge acquisition – model creation, during the whole modeling, expert or decision support system’s life cycle.

INTRODUCTION

One needs not dwell on the arguments in favor of using knowledge bases (KB) in expert, con­trol or management systems. While specialists still argue about the definition of the notion “knowledge”, creators and supporters of modern software systems already have evolved large “KB” and made them accessible through Internet. One can find in these bases manuals, text­bo­oks, theoretical articles, explanations of some tough situations, various roundabouts and know-how on handling system’s bugs and exceptions. These text bases are structured, index­ed and/or ordered according to certain classification principles and have some method (usual­ly the context search) for finding the set of relevant articles when query, keywords, or key phra­ses are given. Thus, to a first approximation, the problem of handling knowledge in com­puter is somehow solved. Really, all knowledge, which application experts produce, is stored in computer readable format, and it becomes available to a worldwide user’s community. This method of creating KB has extremely important positive features:

·         All textual knowledge, which experts are ready to supply, can be handled by such sys­tems;

·         Knowledge is transferred from its creators to consumers without any intermediaries of any kind – knowledge engineers (ignorant, as a rule, in the application domain fla­vors), or some formal language, filtering any notions, facts or nuances, which cannot be handled by the chosen formalism;

·         Information, acquired by user is in 100% NL – with all known merits of man-compu­ter interaction in NL.

One of extremely important merits of NL KB is their capability for “graceful degradation” – their quality deteriorates gradually, if subjected to faulty modification operations. The draw­backs are also evident. And they are direct consequences of using informal NL as knowledge representation (KR) language:

  • Knowledge in this form can be utilized only by humans; formal representational or programming systems cannot be directly controlled by such base;
  • Knowledge in NL KB bears that same level of ambiguity, incompleteness and incon­sistency, which is characteristic for purely human communication – and this feature is present also when human user acquires knowledge from such base;
  • Handling knowledge in NL bases is quite nontrivial: unpunctual its deletion, modifica­tion or addition can deteriorate its quality; usually, these manipulations are performed just on per document basis;
  • Documents in traditional NL KB are very personal and, to the great degree, disjoint – they are prepared usually by different people, which frequently supply self-contained texts; as a rule, they are poorly correlated with the remaining part of the KB.

In what follows, we shall try to discuss the approaches for building KB for loose application domains, taking textual KB as a reference point.

LOOSE APPLICATION DOMAINS

By loose, or “soft” [1], application domain (AD) we shall understand AD, which possesses the following features.

  1. It is not a formal system (with its definite axiomatic basis, strict rules of inference and formal verification procedures).
  2. It is incompletely observable system – according to Ross Ashby – the system, for which we do not know the state of all its determinative parameters, or cannot analyze them due resource or access limitations. Its direct consequence is that the system beha­ves itself unpredictably. And if it is intolerable – the model representation should be changed. As a rule, it is not one moment action, but it ought to be repeated during the process of enhancing the model.
  3. The system can be partially controlled, i.e. the governing body does not possess all the levers needed for the full control; in this situation one cannot avoid experimentation: let us try this… or let us try that…
  4. Organizational systems include humans in their structure, or participate in some hu­man activity It is hard to acquire, analyze and predict the state, goals and behavior of human participants. Besides, they change in time in usually not completely clear way.
  5. The viewpoint of specialists and authorities on the system (its goals, activity, methods and strategies) change with time, which should be reflected in the structure and beha­vi­or of its model or accompanying DSS.

The “looseness” of systems can vary: one system can be more looser, than another. Formaliz­ed systems, to the large degree, after their creation become autonomous from their creators. Loose systems are tightly tied with their authors – application experts and knowledge engine­ers – by a short navel-string. In later case, it is important to choose representation/communi­ca­tion language for building corresponding models and communication between experts as natural and demonstrative to humans, as it could be possible.

It should be self-evident, that for utterly loose systems the best KR language is NL. That is why humanities use NL, and no one is expecting this situation to change considerably in the foreseeable future. Though, the bright efforts in this direction are known, for example: [2].

SEMIOTICS AND PARASEMIOTICS

We are interested in creating computer expert, decision support systems (DSS). They cannot efficiently interact with pure textual KB. So, some steps aimed at the knowledge unification, explication, formalization and simplification should be done, before knowledge from such ba­ses could be made accessible by computer systems. If KR system, which we are aimed at, is of semantic net type, the satisfactory answer lies in adhering to the methods of applied semio­tics [3-5]. Sound methods were developed to define and handle such representational entities, as relations, objects, properties and attributes. But this level is achieved at concluding stage of model creation.

It was noticed that success of man-computer interaction profoundly depends upon thorough un­derstanding and efficient implementation of ergonomic principles and recommendations [6]. More than that, it came out that sometimes it is hard to discern effects of KR technique and ergonomics (well known phenomenon of Weizenbaum’s “Eliza”) – when deeper semantic representational levels and “intellectual” behavior can be mimicked by the set of pertinent er­gonomic solutions. In order to develop an integrated approach to this problem it was proposed to consider semiotics and ergonomics jointly using the term “parasemiotics” [7].

KNOWLEDGE ACQUISITION AND PARASEMIOTICS OF ACTIVITY

Parasemiotics gives a sound groundwork for computer models of AD. Creation of such mo­dels is preceded by system analysis of AD and knowledge acquisition stage, which comprises the art of dealing with experts and other sources of domain knowledge [1]. This job is done by knowledge engineers (KE) and is badly in need of some sound representational formalism, which could play the role similar to that of semiotics in KR sphere. Otherwise, KE are com­pel­led to work with NL texts, schemes, pictures, tables, graphs and other spotty representati­onal means – until they will be able to develop computer model aimed at.

One cannot say, that this impetus for formalization of KE activity passed unheeded by scien­ti­fic community. More than that, the abundance of instruments and formalisms proposed brings the feeling, that no one specific method is satisfactory enough to completely rely upon. One of the most impressive formalism proposed until now is UML [8], though it is, probably, too universal, ponderous and far from easy in mastering by application specialists. We shall try to work out the main preferences, guidelines, which should be adhered to in developing useful construction aids for application specialists and KE at the stage of system analysis – knowled­ge acquisition.

SEMIOTICS AND GRAPHICAL LANGUAGES

The term “semiotics” is unalienable from the concept of sign. In [3-5] “signs” were conside­red as formal symbols handled by computer. Now we cannot neglect the ergonomic aspect of the problem, efficiency of good layout in communication between specialists and as concep­tu­al aid in handling complicated problems. Thus, we arrive at the idea of importance of grap­h­ical representations of sign. Everyone can remember situations when s/he in order to explain some idea to a collocutor, took a pencil and a sheet of paper... Sometimes, the picture thus pro­duced was even completely unintelligible, but during explanations, transfer of ideas... even the movements of the pencil were extremely important for the success of communication. Thus, we arrive at importance of using graphs in KR systems. These graphs should be picto­ri­al for human specialist, and at the same time, be enough formal and natural for computer pro­cessing. If we do not deal at this stage with aesthetical, subconscious and artistic issues, it is natural to admit that the graphical language being sought should consist of, probably marked and decorated boxes, arrows and texts of various types, shapes and colors.

PARADIGMS AND VIEWS

It is indubitable, that any AD can be viewed differently – depending on the goals of research­ers and their actual tasks. The viewpoints of specialists in public relations are quite different from those of technological staff in that same enterprise. Besides, exist different modeling pa­ra­digms, each stipulating its specific approach to model creation, having different primitives and regulations. For example, one can adopt structural approach (objects, properties, relati­ons; entity-relationships, object-oriented approach), document and data flow, resource trans­formation, workflow diagrams, or processes. Some CASE systems, [9], for example, provide several modeling paradigms in parallel. KE in such systems is given the freedom to choose modeling method most appropriate in each given situation. This approach has an evident draw­back, bringing nontrivial problem of merging all these heterogeneous descriptions into one. It is not yet so bad, when different partial models just interact through properly defined interfaces; it becomes much worse when one needs to compose them into an integrated one.


We believe, that system analysis and modeling should be done in the terms of a single, main paradigm: Fig. 1. Others could be used whenever needed, but in each situation they should be naturally interfaced with the main one, work under its control, obtaining required tasks, data, and conveying there the results obtained.

GOAL-DIRECTED ACTIVITY AS THE MAIN PARADIGM

The idea under this thesis is that the goals governing some activity should control the viewpo­ints, or subsidiary methods, which need not be given the freedom to gather “The Mont Blanc of facts” in the hope that sometimes some of them could be of value for some purpose. The widespread definition of a goal is: it is some desired state in the state space, which is to be re­ached applying some actions. This approach has led to the situation, where states and actions, directed to achieving them, became disjoint, which brought with it the well known difficulties during generating plans for goal directed activity.

We can make the next step, if we let goals to be scripts describing execution of several (gene­rally speaking, interrelated) processes. Each process includes a set of elementary processes – activities, or functions. For example, the goal of road building company could be the set of pro­cesses, including properly road building, road state monitoring, maintenance of road buil­ding machinery, dealing with customers, and so on. The goal of the company is achieved, if these processes are successfully performed. This approach has the following benefits.

  • Allowing goals to be processes, instead of just states, is generalization, which signifi­cantly enhances representative abilities of goal-directed approach.
  • Each activity in this approach can be, if needed, represented at more detailed level – as a script describing “low level” processes. For example, the activity: “Dealing with su­p­pliers” at more detailed level could include registration of their data, obtaining prices, handling contracts, marketing research, and so on. So the problem of complexity can be solved – we can focus our attention at the level of generality most appropriate for the current situation.
  • This formalism has very simple graphic representation, which makes it very conveni­ent for people – application specialists, knowledge engineers – at knowledge acquisi­tion stage, and for handling it during the whole life cycle period.

The closest to these ideas stand IDEF formalism, namely, IDEF0 and IDEF3 [10, 11].

IDEF APPROACH

IDEF0 activity modeling (Integration DEFinition language 0), is a technique for analyzing the whole system as a set of interrelated activities or functions [10]. IDEF0 may be used to model a wide variety of automated and non-automated systems. For new systems, IDEF0 may be used first to define the requirements and specify the functions, and then to design an imple­men­tation that meets the requirements and performs the functions. For existing systems, IDEF0 can be used to analyze the functions the system performs and to record the mecha­nisms (means) by which these are done.

The result of applying IDEF0 to a system is a model that consists of a hierarchical series of diagrams, text, and glossary cross-referenced to each other. The two primary modeling com­ponents are functions (represented on a diagram by boxes) and the data and objects that inter-relate those functions (represented by arrows). The modeling language supports the technique for developing structured graphical representations of a system or application domain frag­ment. The main building block of this formalism is activity (Fig.2).


It is a box designating some action, function, activity or process. Arrows around it show the main objects involved in performing this activity. First two of them are activity’s input (left arrow) and output (right arrow). Controls always enter the top of an IDEF0 activity box. They are often in the form of rules, regulations, policies, procedures, or standards influencing the ac­tivity without actually being transformed or consumed. Controls can also be used to desc­r­ibe items that trigger an activity to start or finish. Mechanisms are those resources that per­form the activity. Mechanisms could be the important people, machinery, and/or equipment that provide and channel the energy needed to perform the activity. A mechanism arrow may be omitted from an activity if it is determined that it is not needed to fulfill the purpose of the model. As an example, was taken an activity of repairing transport vehicles (Fig. 3). Its input is out of order vehicle brought to be repaired, and output – repaired vehicle. The vehicle repa­iring activity is performed according to repairing technology and directives, and is done by re­pair shop.


Fig. 4 represents decomposition of the “Repair vehicle” activity (Fig. 3), obtained with the help of Bpwin package [9]. Decompositions are used in business process modeling to break an activity into its constituent activities. Each of these activities can in turn be decomposed in­to its own constituent activities. Each time you decompose an activity, you create a new dia­g­ram. We are not aimed here at complete description of IDEF0 formalism and implementati­ons; all details can be found elsewhere. In what follows, we pay attention to the two main is­sues: its representational power and ergonomics.

NL FLAVOR

IDEF0 diagrams can easily be saturated with NL texts. So, at the initial stages of model crea­tion, all that is required, is to appoint the system goal – most general, primary activity, give it clear mnemonic label and any NL comments which are felt pertinent here. It concerns the “co­n­tent” of the box, and all four groups of its attributes. The same is true at all levels of de­composition hierarchy. Thus, we, preserving all positive features of NL descriptions, add stru­cture, goal-directedness. So, we have no grounds to be anxious about loosing any knowledge fragments, which cannot be held by some rigorous formalism.

GENERALITY AND FLEXIBILITY

Any system – technical, or organizational, at least, does something purposefully, i.e. can be represented as a set of interrelated actions. Even, if we do not understand, what is done and with what attributes (it is quite natural at preliminary stages of analysis), we can draw an em­pty box, gradually filling it afterwards with precise comments, and establishing its four gro­ups of adjacent attributes. IDEF0 formalism has certain meta-features. One can easily depict situations, when some activity creates mechanisms for another activity, controls its execution, or works out business rules for this purpose. The effects, outputs of an activity can be self-ap­plicable, which allows to depict loops, or situations of acting under own control, creating me­chanisms for its own execution.

ERGONOMICS

Very laconic graphical descriptive means: boxes, arrows and NL text, - are easily perceived and remembered by human specialists, are very efficient in working out the common para­digm, viewpoint in the minds of different specialists and knowledge engineers, thus decreas­ing the danger of misunderstanding. According to the well-known ergonomic rule, humans can keep under control situations with the number of main factors: 7 ± 2. In this case, hierar­ch­ical nature of IDEF0 scripts gives the means for holding to this rule when organizing de­com­positions of actions – concealing at any given layer technical details, which can be hand­led later, during more detailed consideration. Extraneous details thus are eliminated and im­portant information is highlighted, thereby reducing the apparent complexity of the system under study.

To some extent, given this type of knowledge diagramming, one obtains the means to appro­ach representing wisdom. Wisdom is the ability to apply knowledge gained from experience to new information, or practical situations, and cannot readily be shared in its truest sense. It can be passed along, but only to a certain extent. Wisdom is proprietary to the individual and of course needs sound representational formalisms to be represented and handled within com­puters.

Color can be used to indicate unresolved issues, identify changed items, specify commonality between objects, appurtenance to specific expert, existence of some shared information, be­lon­ging to specific business unit/area.

One can easily add value to the model: specify characteristics such as cost, time, performance, or quality values.

One more positive feature of this approach is self-documenting. Bad, incomplete, or out-of-date documentation is the source of difficulties at system support during its life cycle, when new support specialists are invited. Highly structured, replete with comments models facili­tate automatic generation of documentation being in exact correspondence with the current system state.

FROM DESCRIPTION TO FUNCTIONING MODELS

Some researchers discern descriptions and models of certain activity. We argue, that this is reasonable only in the case of non-constructive descriptions, where only the description of solution, goal state, or script is given, and one should infer the value of unknowns, pass thro­ugh the maze of actions and calculations to obtain specific result. We believe, that there sho­uld be some continuity from the vague, partial, fragmentary descriptions – to the solution. They should not be antagonistic. This approach gives the solid framework for acquiring quite diverse knowledge from AD specialists. This knowledge can be of any kind: some items con­cern important preconditions, (possibly incomplete) sets of business rules, fragmentary know-how, relevant to some intermediary stage of life cycle or system management process. The positive feature is that all these fragments are not lost, or put chaotically in some depositary, but are attached to knowledge structure and either start working right away, or remain on the alert for immediate activation when their time comes.

CONCLUSION

I have shown, or, at least, was trying to show, that IDEF0 formalism can efficiently serve as a knowledge acquisition and model building language, starting from the very vague, prelimina­ry stages. Less evident are the following stages, which should bring us to functioning know­ledge and data base systems – modern expert, simulation, and decision support systems. The last question, which should be answered here, is – why do we are speaking in this context abo­ut semiotics, or even, parasemiotics… As we know, semiotics is convenient and conceptu­ally sound bridge between reality and its reflection in human mind and computers. This ref­lec­tion is done with the help of signs. Here, trying to grasp, fix, handle and put into operation the knowledge about complicated, loose domains, we rely also on signs – graphically demon­strative language with clear cut graphical images of signs – boxes, arrows, texts. The diver­g­ence from pure classical notion of semiotics justifies the introduction of specific term: parase­miotics.

REFERENCES
  1. Т.А.Гаврилова, К.Р.Червинская, Извлечение и структурирование знаний для экс­пертных систем, “Радио и связь”, Москва, 1992, 199 с.
  2. Vladimir Propp, Morphology of the Folktale, University of Texas Press: Austin and London (1968)
  3. Vitaly S.Lozovsky, Semiotics of Net Models for Knowledge Representation, 12th Eu­ropean Conference on Artificial Intelligence ECAI'96, W30, Applied Semiotics, Buda­pest, 11-16 August, 1996, ECCAI, pp. 38-42
  4. Lozovskiy Vitaliy (UA): Common Sense Semiotics, Conference Proceedings: Know­ledge-Based Software Engineering (Smolenice, Slovakia), P. Navrat and H. Ueno (Eds.), IOS Press, Amsterdam, Berlin, Oxford, Tokyo, Washington, DC, ISSN: 0922-6389, ISBN: 90 5199 417 6 (IOS Press), 1998, pp.232-240
  5. Vitaliy S.Lozovskiy, Designation and Naming, CAI’98, Sixth National Conference with international participation, Vol. III, Proceedings of Workshop on Applied Semi­o­tics, Russian Association for Artificial Intelligence, Scientific Council for the Problem “AI” of Russian Academy of Sciences, Pushchino, 1998, 06-11 Oct., p.16-24
  6. V.S.Lozovskiy, Ergonomics Of Interaction, Материалы VIII Международной кон­фе­ренции KDS-99 ЗНАНИЯ-ДИАЛОГ-РЕШЕНИЯ, Крым - 13-18.09.99 – Каци­ве­ли, в сб. Искусственный Интеллект - 1999, Специальный выпуск, Националь­ная АН Украины - Институт проблем искусственного интеллекта, Донецк, 1999, ISSN 1561-5359, с. 5-12
  7. Vitaliy Lozovskiy, On the Road to Parasemiotics, ASC/IC'99 - Труды 4-го междуна­родного семинара по прикладной семиотике, семиотическому и интеллек­туаль­ному управлению, Институт программных систем РАН, Российский университет дружбы народов, Российская ассоциация искусственного интеллекта, Москва, октябрь 1999, ISBN5-89574-064-2, с. 158-166
  8. OMG Unified Modeling Language Specification, UML V1.3, Object Management Gro­up, Inc., http://www.omg.org/, June 1999
  9. BPWin Methods Guide, Computer Associates International, Inc., 2001
  10. Draft Federal Information Processing Standards Publication 183, Announcing the Stan­dard for Integration Definition for Function Modeling (IDEF0) December 21, 1993
  11. Richard J. Mayer, Ph.D. Christopher P. Menzel, Ph.D. Michael K. Painter Paula S. deWitte, Ph.D. Thomas Blinn Benjamin Perakath, AL-TR-1995-XXXX Information Integration for Concurrent Engineering (IICE) IDEF3 Process Description Capture Method Report, KB Systems, Inc., Sept., 1995, http://www.kbsi.com/

 

Make a free website with Yola