HYPERFORMS FOR RAPID ACCESS TO DISPARATELY STRUCTURED INFORMATION AND META-INFORMATION Dr. Wayne L. Myers & Dr. Michael Foster The Pennsylvania State Univ. Univ. Park, PA 16802 ABSTRACT Catastrophes create needs to draw upon several kinds of disparately structured information quickly. Such needs typically encompass both computerized databases and document-based sources. Relevant computerized databases may reside on different hardware platforms, under different software systems, controlled by different database administrators. Specialized formats and access protocols may elevate the problem to an order that approaches need for a panel of experts. Flexible hyperforms can provide the functionality of compound expert systems managing meta-information (information about information) that are both inexpensive and easily updated as databases change. When structured as generalized objects, complex hyperform systems can be linked retrospectively and recursively into higher order network objects. If desired, demons can be imbedded in such systems to reach directly into other systems and extract content. Multisystems of this nature can handle complexity of high order within the confines of PC-compatible computer technology. INTRODUCTION Rapid assessment of impacts from catastrophic events will require correspondingly rapid access to a collage of information and knowledge, some of which is routinely utilized by certain persons and other that pertains mainly to eventualities such as catastrophic occurrences. For any particular instance of catastrophe, it is likely that some of the key personnel who possess important knowledge will be at least temporarily unavailable. Absence of such individuals will delay mobilization in response to the catastrophic event. Likewise, pulling together information that applies specifically to catastrophes will give rise to crucial delays if advance provision is not made to facilitate mobilization when such an event occurs. 'Fire drill' analogues constitute one possible mode of preparedness for catastrophes, but these cause recurring distractions from busy routines that become an expensive sort of overhead. 'In case of emergency' fire extinguisher analogues constitute an alternative mode of informational preparedness which is much less disruptive of routines. Our purpose here is to consider informational equivalents of emergency fire extinguishers. These same concepts can also be adapted to deal with a variety of contingencies that are much less extraordinary. We use the term 'hyperforms' to characterize information/knowledge systems of this nature, and introduce a generic 'shell' system called GNOSIS for exploring these domains. META-INFORMATION SYSTEMS The information resources of an organization provide the foundation of its routine operations and become central to strategic response in emergency situations. The logistics of normal operations usually favor distribution of knowledge about information resources among different personnel and perhaps also among several offices that may not even be colocated. Each type of information is typically the special province of one or a few staff members, with such units interacting through established lines of communication in order to achieve integration of information elements for particular functional purposes. In emergency situations, however, the usual lines of communication tend to be disrupted and/or too slow for mobilizing rapid response. Need thus arises for an incident command center to have an overview of all information resources that might have relevance to mounting a plan of action in response to contingencies. Such information about information constitutes meta- information. There is growing recognition of need to formalize management of meta-information, if only to reduce the difficulties associated with staff absences and personnel transitions. Meta-information has received particular attention in the context of spatial data and geographic information systems (GIS). An index constitutes meta-information at the most fundamental level, and meta-information systems must therefore perform indexing in some manner. In the modern electronic era, however, indexing can be extended to a very high order. The first order of extension leads to electronic storage and retrieval of abstracts. As a second order extension, hypertext arises from linking the index to more substantial 'chunks' of content along with active 'see also' links. Incorporating images and sounds as 'chunks' leads to hypermedia. Further extension is suggested by noting that retrieval and presentation of media chunks takes place by activating appropriate software facilities. An object-oriented view leads to 'chunking' of such processing software as 'demons,' at which level we generalize the 'hypermedia' terminology to 'hyperforms.' A program invoked by another program thus becomes a type of hyperform. Hyperform handling transcends the conventional concept of subroutines since the hyperforms may be capable of functioning as stand-alone programs. The generalization thus progresses to the level of meta- programming. There is no reason to truncate the generalization at the meta-programming level. Separately configured hyperform systems can, in turn, be linked together as hyper-systems. There is likewise no reason to limit such linkage to systems that reside on the same computer. There are currently no technological barriers to the formation of distributed hyper-systems, with Internet servers and clients being illustative. There is also no reason to insist on 'rigid' links between systems. Links can form and dissolve according to circumstances, as they do on the Internet. With 'soft' linkages, the 'systemness' becomes more apparent than real because only one among many potential sets of linkages gets 'instantiated' during a particular session. Most contemporary examples of soft linkage systems are 'directed' by a human 'pilot' who controls or at least constrains navigation through the network of (virtual) linkages. The ultimate in such generalized systems appears to come when humans 'delegate' control to 'intelligent' software 'agents' that have authority for higher-order delegation to other software agents. Such distributive sense of direction and purpose among mutually interacting software entities begins to mirror the organization and dynamics of human societies (Gelernter, 1991). Implementing such 'societies of software' is mostly a matter of attitude adjustment on the part of software engineers, but the functional potential of software societies will take a quantum leap when truly parallel computers become commonplace. While it is intriguing to contemplate the future complexion of 'socialization' among software, relatively modest implementations of such ideas can do much to facilitate management of meta-information. Each unit having some responsibility for information resources can set up a 'server' which is 'cognizant' of information in that particular domain. Several such servers can then be linked into servo-networks, and the servo-networks can be further linked into meta-networks. We focus here on a 'shell' called GNOSIS (Generalized Networks Of Symbolically Integrated Systems) which enables the creation of hyperform networks on PC-DOS computers. Conference 'hyperceedings' provide an illustration of application. GENESIS OF GNOSIS Initial perception of need for GNOSIS arose from a two-year odyssey for the first author as technology advisor with USAID on social forestry and natural resource sustainability in India. Direct implants of western technology have a perverse tendency to exacerbate rather than alleviate environmental and economic problems under indigenous social contexts. There needs to be an envelope of attached knowledge to sustain and acclimate a technology implant. Such an amalgam of technology and knowledge might be considered as 'tecknowledgy.' There is further need for capability to reconfigure tecknowledgy remotely so that cost and logistical difficulties for consultative teams and cooperative science are minimized. This latter need is considered in GNOSIS by making applications amenable to piecewise transmission over InterNet. Direct impetus for initiating development came in the context of USDI National Park Service desires to operationalize distributive geographic information systems (GIS) for recurrent applications without a substantial overburden of training. This involves GIS scripts in the sense of Schank & Abelson (1977), whereby a park resource manager and a GIS specialist cooperate to characterize a repetitive scenario for application of spatial information in similar fashion to the way one might characterize a scenario for visiting a restaurant. A computer then orchestrates the scenario on subsequent occasions. The GIS specialist incorporates specialized knowledge associated with the scenario directly in the script, so that the user gains autonomous capability through the script without having to 'learn' details of either procedure or technical jargon. The point of departure for development was an analogy between computer orchestration of a script and an orchestra capable of playing the work of an unspecified composer for an audience. A PDC Prolog (Prolog Development Center, 1992) model of an orchestra was constructed, complete with conductor, instruments, performers, ensembles, auditorium, usher, patrons, etc. This model was dubbed ORCHSTR8. The orchestral context was then abstracted to general scenarios in a system called PHASES (Process Hierarchies And Structured Event Scenarios). Motivation to further generalize PHASES as early GNOSIS came through need to integrate hydrologic models with other environmental process models in a GIS context. The acronymony for this sort of work is CHEMistry (Composite Hierarchical Environmental Modeling). For development at stage 4 of GNOSIS, the original context of tropical forestry was revisited through a summer fellowship in Forest Research Institute Malaysia. GNOSIS AND THE NATURE OF GNOMES One makes provision for application of GNOSIS by formulating a GNOME (Generalized Network Operations Managing Entity) that operates under GNOSIS. Formulation of GNOMEs takes place by interaction between GNOMEs and developer(s). This apparent circularity is typical of organizational recursion in GNOSIS. The circularity is not pathological since it is also possible to develop GNOMEs without assistance from GNOMEs. Direct development of GNOMEs is somewhat akin to pushing a vehicle in order to start the engine -- laborious and better avoided when possible. A GNOME consists of the GNOSIS compiled PDC Prolog engine interacting with ASCII files which contain formal terms for predicate logic. In the gnomenclature of GNOSIS, the ASCII files are FOLDs (File Of Logical Determinants). Functionally, FOLDs are consulted into a PDC Prolog dynamic database for which the terms constitute database predicates. The chromoGNOMEs of GNOSIS are thus instances of database predicates, and the 'genes' are the arguments. 'Logical determinant' is the GNOSIS terminology for an instance of a database predicate. Since GNOMEs are the executors of GNOSIS, it is tempting to think of them as programs. However, the ASCII FOLDs are readily changed and reconsulted 'on the fly,' thus giving GNOSIS much of the advantage associated with interpreted Prolog while retaining much of the advantage in compiled Prolog. GNOMEs as paradigms are extremely powerful organizers as well as being executors. Therefore, the seeming 'programness' of GNOMEs is at best superficial. Subsequent discussion of GNOMEs as generalizable objects should help to clarify this in some degree. If all the logical determinants for a GNOME were required to reside in a single ASCII file or simultaneously in dynamic memory, then the size of a GNOME would be rather severely restricted. To avoid such restriction, subsets of logical determinants for a GNOME can reside in different FOLDs. The FOLD acronym has an associated visualization in terms of a map. A map is folded for more tractable handling. One can use a map without unfolding it when the local area of interest does not extend beyond a fold line, and so also with a GNOME. Only one FOLD will reside in dynamic memory at a time, with that FOLD referencing other FOLDs as appropriate for extension of activity beyond the purview of the current FOLD. FOLDs can thus be seen as something of a GNOSIS analog to overlays in conventional programming, except that one FOLD pointing to another takes the place of main program sequencing. One of the more common pitfalls for inexperienced GNOME developers is that of placing all logical determinants in a single FOLD. Every GNOME has a centerFOLD. The centerFOLD carries the name of the GNOME as its root filename, and has a .NOM extension on the filename. Additional FOLDs are optional, but highly recommended in the interest of modularization. Additional FOLDs can have any root filename, but all carry a .FLD extension on the filename. There is a set of GNOMEs that provide for interactive development of other GNOMEs. This suite of developmental GNOMEs comprises the 'GNOMEdrome' of GNOSIS. For GNOMEs developed in the GNOMEdrome, there is an ASCII file of selected chromoGNOME information which has the name of the GNOME as the root of its filename with a .GEN extension. A Testrac GNOME can be attached to the GNOMEdrome which allows developing GNOMEs to be tested without leaving the GNOMEdrome. The GNOMEs comprising the GNOMEdrome become an integral part of GNOSIS, much as bees tending a hive are integral to the hive as a functional entity. In keeping with doctrines for declarative systems, the order of logical determinants within a FOLD is immaterial. The core construct among logical determinants is the ITEM, which serves primarily to 'Initiate/ Transfer Event Management.' Each ITEM has three basic components (arguments): a name, a type, and a caption. There are several types of ITEMs, with three being central to the networking activity of GNOSIS. The first of these is a NEXUS (NEXt Unit Selector), which constitutes a (potential) node of a network. A NEXUS has associated with it a list of ITEMs and a 'guidance.' Links in a GNOSIS network are unidirectional, and the elements in the list of ITEMs constitute (outgoing) links from the node. Such a node is 'unaware' of any incoming links that may exist. Thus, the role of a NEXUS is to transfer control via one of its (outgoing) links. The guidance for a NEXUS is a separate construct contained in a 'gnoway' logical determinant and identified by an integer index. One very straightforward use of a NEXUS is as a menu of selectable ITEMs that call other menus. A NEXUS can be specified to operate under user control by giving it a guidance indexed as a positive integer, in which case the human user selects an ITEM from the menu. Alternatively, the NEXUS can automatically execute one of its own selectable items when given a zero index for guidance, thus initiating any one of many sorts of transactions. A NEXUS can thus act as a user-controlled menu, but a simple alteration in the GNOMEdrome converts it to a self-executing frame-like object with slots. In the self-executing mode, one can create quasi-rule based or quasi-object oriented systems. A NEXUS can also be placed under control of a designated software demon by giving it a negatively indexed guidance. This latter mode requires direct editing of a FOLD for installation. The second major type of ITEM is a STEP (Software Triggered Event Pattern). A STEP is a linear sequence of events that can transpire without need for link selection until the sequence terminates. A STEP can be conditionally interrupted in the manner of a C-language 'break,' but will proceed to completion unless thus interrupted. A STEP in itself does nothing except to declare an event sequence. The actual event sequence consists of an associated series of PARTs (Procedure And Related Tasks). The sequence may be unitary, consisting of only a single PART. Each PART may or may not have SPECS (Select Process Execution Control Settings), with the SPECS being a list of process parameters. In the more straightforward configurations, STEPs become selectable ITEMs in a NEXUS. There are several possible states of STEP termination. One possible state of termination is to restore the pre-STEP state of the network. Another possible state of termination is to 'endat' a particular node (NEXUS). A third possibility is to 'endwith' another STEP (which could in turn be composited with other composite STEPs). The chained STEPs can be in the same NEXUS or a different NEXUS. The third major type of ITEM for present attention is the one that arguably places GNOSIS in a software class by itself. This is the GNOMIC (GNOMe Inter-Connect). This allows a GNOME to cede control to another GNOME at a given NEXUS (node) with full access to the current state of the GNOSIS object oriented global memory. At least in concept, this can proceed without inherent limit. GNOMEs containing other GNOMEs are hyperGNOMEs. The GNOME thus becomes a 'tecknowledgy' organizing construct in its own right. Existing GNOMEs can become part of a new GNOME, which subsequently becomes part of another new GNOME, and so on in an upward recursion of organizational generalization. To make this possible, GNOSIS lacks any intrinsic sense of beginning or end, and establishes no fundamental precedence among GNOMEs. GNOSIS thus constitutes an environment for GNOMEs that only gets 'switched off' when it has no reason for continuation by virtue of having no cognizant GNOME to support. The major structure of a GNOME is shown diagrammatically in Figure 1. The diagrammed GNOME is a hyperGNOME containing siamese GNOMEs that share a FOLD. Table 1 summarizes important GNOMEnclature. ----------------------------------------------------------------------- | hyperGNOME containing GNOMEa & GNOMEb as GNOMICs | | -------------------------------------- | | | centerFOLD of hyperGNOME | ---------------------- | | | ---------------------------------- | | Supplemental FOLD #1 | | | | | ITEM = NEXUS, STEP, GNOMIC | | | for hyperGNOME | | | | | ------------------------------ | | | | | | | | | NEXUS | | | | | | | | | | -------------------------- | | | ---------------------- | | | | | | NEXUS | | | | | | | | | |..........................| | | | ---------------------- | | | | | | GNOMEa (as GNOMIC) | | | | | Supplemental FOLD #2 | | | | | | |..........................| | | | | for hyperGNOME | | | | | | | GNOMEb (as GNOMIC) | | | | | | | | | | | |..........................| | | | | | | | | | | | STEP | | | | ---------------------- | | | | | | ---------------------- | | | | | | | | | | | PART | | | | | -------------------- | | | | | | | -------------------| | | | | | Associated demons | | | | | | | | | SPECS | | | | | | | | | | | | | | -------------------| | | | | -------------------- | | | | | | ---------------------- | | | | | | | | | -------------------------- | | | | | | | ------------------------------ | | | | | ---------------------------------- | | | -------------------------------------- | | ---------------------------------------------------------------- | | | GNOMEa | | | | ---------------------- --------------------------- | | | | | centerFOLD of GNOMEa | + | Supplemental FOLD shared | | | | | | | + | by GNOMEa & GNOMEb | | | | | | | + | | | | | | ---------------------- --------------------------- | | | ------------------------------ + + + + + + + + + + + + + + - | | | --------------------------- | | | | | centerFOLD of GNOMEb | | | | | | | | | | | --------------------------- | | | | | | | | GNOMEb | | | --------------------------------- | | | ----------------------------------------------------------------------- Figure 1. HyperGNOME encompassing GNOMEa and GNOMEb as siamese GNOMEs that share a supplemental FOLD. Table 1. GNOMEnclature. FOLD File Of Logical Determinants GNOMAD GNOMe And Delivery GNOME Generalized Network Operations Managing Entity GNOMEdrome Development environment for GNOMEs. GNOMIC GNOMe Inter-Connect GNOSIS Generalized Networks of Symbolically Integrated Systems hyperGNOME GNOME containing other GNOMEs via GNOMIC. ITEM Initate/Transfer Event Management NEXSTEP Automated NEXUS NEXUS NEXt Unit Selector PART Procedure And Related Tasks SPECS Select Process Execution Control Settings STEP Software Triggered Event Pattern GNOMEDROME AND GNOMADS GNOSIS is activated by keying in a tilde ~ that is prefaced by the path to the GNOSIS directory, and then pressing ENTER. Of course, no prefacing path is necessary when GNOSIS is situated in the home directory or the GNOSIS directory is in the environment path. GNOSIS maintains a separate sense of GNOSIS directory, GNOME directory, and home directory. GNOSIS first looks in the home directory for 'resident' GNOMEs. If one or more GNOMEs are resident, the user is offered a selection among such GNOMEs. If there are no resident GNOMEs, GNOSIS permits specification of another directory to search for 'nonresident' GNOMEs. If the user declines this option by just pressing ENTER, then GNOSIS initiates transport to the 'GENOME level' and positions the user in GNOMEdrome central which is the development environment for GNOMEs. The GNOMEdrome is managed by a GNOME called GENOME. Another GNOME called TESTRACK can be called upon to provide a test track as an adjunct to the GNOMEdrome. When a developing GNOME has been 'registered' with the TESTRACK, that GNOME can be tested while it is undergoing development without leaving the GNOMEdrome. At stage 4 of GNOSIS there are two 'genesis facilities' that can be reached from GNOMEdrome central. These facilities are compiled PDC Prolog executable demons. The GENGNOME facility provides for development and alteration of 'generic' GNOMEs, which are GNOMEs that operate in directed or CONSORT (CONveyor SORTing) modes as discussed later. The ISOGNOME facility provides for development of 'inferential' GNOMEs that use the GNOSIS forward-chaining meta-reasoning strategy of considerations that became available in stage 4. There is a NEWGNOME file that describes the procedure for creating a simple GNOME that is the GNOSIS equivalent of a C-language 'Hello World' starter program. This file can be examined editorially from the GNOMEdrome central or from either of the genesis facilities. The GNOMEdrome also contains a demonic facility for cloning a GNOME under a different name. There is also a port for docking a demonic facility that converts old PHASES applications into GNOMEs. The latter port is locked in stage 4, however, since most PHASES applications have already been converted to GNOMEs. Stage 4 of GNOSIS with the full GNOMEdrome occupies the capacity of the 3.5-inch high-density distribution diskette rather completely, but does not require compression. There is also a READ.ME file which suggests transferring GNOSIS to a hard disk where there is room for development of new GNOMEs, and also mentions the NEWGNOME file. It should be noted at this juncture that one normally does not develop a GNOME in the GNOSIS software directory. Development of a new GNOME should be started in an empty directory. When a GNOME has been developed, it may be desired to transfer it to a diskette as self-contained software. With any substantial GNOME, however, there will not be sufficient capacity on a diskette to contain all of the GNOSIS distribution files. The matter of which files are critical is not easy to explain, so the obvious solution was to make explanation unnecessary in the following manner. After a GNOME has been developed and assuming that its intended users are not expected to alter its structure, there is no need for the facility demons of the GNOMEdrome. The facility demons and their associated text files take up roughly half the capacity of the GNOSIS distribution diskette. There is an option in GNOMEdrome central to transfer critical GNOSIS files to the GNOME directory, which should also be the home directory during GNOME development. The result of such transfer is a 'GNOMAD' (GNOMe And Delivery) that can be copied to a diskette unless the GNOME is quite extensive. GNOMEdrome central is still accessible with a GNOMAD, but all of the facilities are closed. The only drawback to running directly from diskette is that loading of GNOSIS takes longer, by about an order of magnitude. Because of this loading delay, it is still desirable to transfer the GNOMAD to a hard disk for routine usage. GNOMES AND DEMONS The philosophy underlying GNOSIS is one of practicality, and continual reworking of existing software capability seems an impractical waste of time unless the associated advances in capability are substantial. The first author is likewise not enthralled with glitz of user interface, although the second author is much more interface oriented. Since the former was responsible for design and implementation, the expedient approach has prevailed. GNOSIS thus favors direct incorporation of existing capability as demons whenever possible, and its native interface has a plain vanilla flavor. As an concession to interface concerns, demonic interfaces are also accommodated. GNOSIS can operate in the foreground, in the background, or alternate between foreground and background. Demons can be managed in either of two modes, and the two modes can both be used in the same GNOME. The 'normal' mode is to fire a demon 'underneath' GNOSIS with GNOSIS remaining fully resident and waiting to resume immediate control when the demon terminates its activity. Interface demons must operate in this mode. The normal mode works well for demons of modest size, but memory constraints are encountered with larger demons. The alternative is an 'occult' mode wherein GNOSIS enters an altered state that substantially vacates RAM memory. This involves a tier of batch files whereby GNOSIS is invoked at one level and automatically reconfigures other levels to make an appropriate call and then be recalled. In this latter mode, the demon possesses the computer resources aside from the inconsequential overhead of a couple small batch files that are waiting. GNOSIS encourages a very cosmopolitan attitude toward demons, with the scenarios often encompassing highly diverse software systems residing in different directories and on different disks. Conflict can arise from many sources in such settings, and demons can often become disoriented about where to find and put files. To help in resolving such problems, demons can be run either 'inboard' or 'outboard' relative to the GNOME. Recall that the home directory may be different from either the GNOSIS directory or the GNOME directory. Firing is considered to be 'outboard' when the home directory is permitted to be different from the GNOME directory. When a demon assumes that the home directory will be its own directory, a GNOME can be placed in the same directory as the demon and 'inboard' firing used to activate the demon. For inboard firing, the home directory is temporarily changed to the GNOME directory. Even this does not resolve all difficulties, and there may be occasional demons that prove intractable. Unfortunately, such intractability can be inherent when the only resolution lies at the level of unavailable source code for compiled demons. Rather substantial implications arise from the capability of GNOMEs to pass batons to other GNOMEs and orchestrate an essentially unending procession of demons. One such implication is that neither GNOSIS nor the GNOME need contain many capabilities already available in other software. Expert systems in other shells, neural nets, database managers, statistical software, optimizers, GIS, and so on can all be incorporated in scenarios or sub-scenarios of GNOMEs directly as demons. GNOMES provide an inexpensive way of custom configuring suites of software to suit the needs of particular users. While the interface isn't fancy, it provides functionality. When systems are being designed that have functional overlap with existing software, GNOSIS provides an expedient approach to functional prototyping. Small programs can be written in a procedural language like C to fill the respective gaps in capability, and then networked with the existing software as demons to create a working (if perhaps somewhat cludgy) prototype. Actual experience with such an ad hoc prototype can often save several cycles of revision relative to conventional design. The thesis of M. Fink (1993) provides an example of such prototyping with GNOSIS, in which dBase demons produce landscape ecological assessments in response to user queries. Sometimes the prototype even proves to be sufficiently workable to dispense with a more formal version. HYPERFORMS AS FICHENETS The term 'FicheNet' is appropriate for characterizing the GNOSIS approach to hyperforms. Instead of the form selectors appearing as highlighted words in other text, they appear as ITEMs in a NEXUS comprising a menu. Any given ITEM may either access a form directly or access another such menu. This is essentially a dynamic index approach to hyperforms. A 'textlet' is one type of 'fiche' that can be accessed. A textlet can be either an entire ASCII text file or an indexed segment thereof. Textlets are presented to the user through the PDC Prolog string display capability that behaves much like a file editor. The user can scroll or page through the text and do searches for particular character strings, but is prohibited from making any changes in the text. Capability is also provided for copying blocks of text to a file or a printer. Any given textlet file is limited to 64K bytes. GNOMEdrome central contains a similar file editor that can be used to compose and alter textlets. This editor can also be incorporated directly in a GNOME if it is desired to give the user capability for manipulating text. A 'piclet' is a second type of fiche that consists of a .PCX image file. The capability for piclet display resides in a demon constructed by the second author that is treated as being integral to GNOSIS. It is a relatively straightforward matter to support other types of media as fiches through the demonic capabilities of GNOSIS. For example, one might incorporate 'soundlets' in this manner. Authoring of hyperforms in the GNOMEdrome can be taught rather quickly, with the facilities for configuring textlets being particularly convenient. The system has been thus used by students in an international forestry course for authoring hyperpapers. FicheNets do not require the full capability of GNOSIS at stage 4. Stage 3 of GNOSIS is sufficient for this purpose, and has the advantage of being small enough that the development facility can usually be accommodated on the same diskette as the GNOME. FicheNets are essentially semantic networks that the user navigates by picking ITEMs from menus. This is the directed mode of operation for GNOSIS, wherein it reacts to the selections of the user. Very little training is needed to configure simple but workable expert systems based on this type of structural logic that is analogous to conventional keys. QUESTIONABLE GNOMES AND CONSORTIA GNOSIS is 'comparadigm' oriented, with different modes of interaction between GNOMEs and user being not only accommodated but also facilitated. This proves particularly useful for illustrating the limitations and advantages of different approaches to students in AI courses. Expert systems operating in directed mode through the menu-like NEXUS have a vanilla flavor and passive character that is more suggestive of conventional identification keys than of computer intelligence. They nevertheless provide a lower window for guidance on how to make a selection, and also make provision for optional detail regarding each of the ITEMs available for selection. An advanced feature of this seemingly simple interface allows a user to interrupt a session and resume at the same point later, even after shutting off the computer entirely. The logic in a FicheNet is structural, and the user feels very much 'in the driver's seat' as (s)he navigates the semantics of the network. Nonetheless, instantiation of the one path that the user sees in the virtual network is very much declarative at the level of the engine. Despite their simplistic appearance, FicheNets can provide a convenient medium for initial knowledge representation in the course of knowledge acquistion. The structural logic is easily extended and/or altered by adding/dropping symbolic links and nodes. Furthermore, the FicheNet provides an immediate working prototype that develops progressively. The consultation paradigm is so closely associated with impressions of computer intelligence that capability for questioning is de rigueur in AI shells. The primary GNOSIS interrogator is a garnished version of the vanilla NEXUS interface, allowing for selection among a fixed suite of acceptable answers to a question. The text of the question is presented in a lower window, with the alternative answers selected in menu style from an upper window. Supplementary text can be provided for each alternative to be perused at the discretion of the user. Images can also be associated with the respective alternatives for discretionary viewing. The latter capability allows for consultation to proceed in a gestalt fashion. Since the logical determinants for questions are relatively straightforward, developers are required to formulate these directly with the file editor. This provides a context for introducing developers to the structure of FOLDs. The more adventurous developers are then in a position to attempt direct editing for other aspects of GNOMEs. With a capability for direct editing, one may wish to explore customized interfaces for GNOMEs using interface demons. Instructions are provided in the GNOMEdrome regarding procedures for installing interface demons. Application scenarios may call for open-ended inputs as opposed to selection from a fixed set of alternatives. Provision is made for this through a 'refer' PART for STEP ITEMs. Such open-ended input can come either directly from the user or from an ASCII file. The directed mode of operation is inappropriate when users answer questions posed by a GNOME. GNOSIS provides two modes of logical operation for the consultation paradigm. The simplest for new developers (and students) to learn is the CONSORT (CONveyor SORTing) mode, in which the GNOME becomes a CONSORTium. This mode has the intuitive analog of a system of conveyors with sorting operatives positioned along each conveyor. The role of a sorting operative is pick a certain type of instance out of the conveyor and transfer it to another conveyor for more specific sorting by other operatives. The conveyor is a NEXUS functioning in automatic mode, and the sorting operatives are STEPs in the NEXUS. A NEXUS operating automatically is called a NEXSTEP, and the GNOMEdrome provides for converting a user directed NEXUS into a NEXSTEP by changing its guidance index integer to zero. GNOSIS works downward through a NEXSTEP by virtually pressing the ENTER key for an ITEM, and then pressing the down arrow key to reach the next ITEM before pressing ENTER again. Transfer from one NEXUS (conveyor) to another is effected by a '?endat' PART in a STEP ITEM. This type of PART tests a conditional on a global memory object to determine whether transfer should occur. If the relevant global memory object does not yet exist, GNOSIS attempts to create it by interrogating the user. If the transfer condition is not satisfied, flow continues downward in the NEXUS where conditions in other STEPs will come into play. If an applicable transfer condition is not found before NEXSTEP ITEMs are exhausted, GNOSIS declares the NEXUS a 'dead end' of faulty logic and halts operation. Any procedural ITEMs not involving conditionals become side effects of the flow. Debugging of a CONSORTium is easily done by giving a NEXUS positive guidance, and then alternately pushing the ENTER and down arrow keys as GNOSIS will do for a NEXSTEP. Like a FicheNet, a CONSORTium has the formal structure of a semantic network. Unlike a FicheNet, however, the network is navigated by autopilot rather than manually. Navigational decisions by the autopilot revolve around GNOSIS dynamic memory objects. In addition to having names and values, memory objects are associated with FOLDs. It is the FOLD association that allows GNOSIS to locate appropriate questions to ask the user. Regardless of FOLD association, however, all memory objects are globally accessible. The FOLD associations only serve to impose a schema on memory objects. It thus becomes possible to instruct GNOSIS to forget all memory objects associated with a particular FOLD in preparation for a new consultation. Although GNOSIS does not use conventional rules with explicit consequents and antecedents, it is interesting to make comparisons with the latter. The basis of comparison lies in the fact that a rule is a conditional. The conditional test on a memory object is effectively an antecedent of a rule. However, the consequents of GNOSIS conditionals are indefinite. The 'consequence' of a GNOSIS conditional is a NEXUS, entered by default at the first ITEM or optionally at a particular ITEM. Thus the consequents of GNOSIS reasoning are substantially implicit in the reasoning itself. As a point of information, the CONSORTium terminology is not actually used in the GNOMEdrome. In the GNOMEdrome, a CONSORTium is called a 'regulatory' GNOME. The conveyor sorting analogy was contrived as a pedagogical device for helping students to grasp the reasoning strategy rapidly in a way that provides a model for developmental work. CONSIDERATE GNOMES Although the CONSORTium approach to logic is completely general and easily debugged, it is somewhat rigid. Every decision must be fully specified, to the extent that explicit provision must be made for handling failure. Some of the issues concerning GOTO in conventional programming arise here as well. A CONSORTium is a sort of logical fabric with NEXUS warp and conditional weave. Such a fabric has a tight knit that is not conducive to adaptivity in GNOMEs. Alterations made in one sector tend to have echos in other sectors of a CONSORTium. There is also a peculiar tendancy to have rule equivalents stated in the converse. These concerns were sufficiently compelling to prompt further development of inferencing strategies in stage 4 of GNOSIS. As usual for GNOSIS, the outcome of the development is somewhat unconventional. Formulating workable rules of adaptivity requires that domains and subdomains be well structured. Expansiveness in a single 'rule pool' makes alterations difficult (whether adaptive or remedial) as well as promoting combinatorial explosion of search trees. Likewise, horizontal development by successively 'throwing another rule in the pool' is a prescription for disorder and eventual instability. Making systems conducive to structure was thus a major concern for stage 4 development. The goal was to promote top-down view in both design and implementation. The result is perhaps best characterized as a facility to formulate meta-rules of logical consideration. From a computational viewpoint, however, it involves logic subroutines. 'Consider' is the implicit operator of the stage 4 engine, and the subject of consideration becomes a NEXUS as a NEXSTEP. The three possible outcomes of consideration are 'conclude' as success, 'preclude' as global failure, and 'exclude' as failure of a particular alternative. Considerations may be either mandatory or contingent, and contingent considerations may be qualified or unqualified. A consideration scenario usually begins with a mandatory consideration formulated as follows: {Consider} PREMISE [NEXUS] where curly brackets indicate an implicit element, square brackets indicate a required argument, and angle brackets indicate an optional argument. This construct invokes the specified NEXUS with entry at a particular ITEM if specified or at the first ITEM by default. The specified NEXUS and ITEM are pushed on a logical call stack. Flow proceeds downward in the called NEXUS until a logical return is reached. Control then returns to the invoking NEXUS at the point of the call. If the return state is CONCLUDE, flow continues downward with the next ITEM. If the return state is PRECLUDE, a downward scan ensues for another mandatory consideration, with all intervening ITEMs being bypassed. When the return state is EXCLUDE, the downward scan will also accept a contingent consideration formulated as follows: OR {consider} [NEXUS] Once invoked, a contingent consideration functions in the same manner as a mandatory consideration. A NEXUS invoked as a consideration may invoke a further consideration and so on. When an unresolved return hits the end of a NEXUS that was invoked as a consideration, that NEXUS returns its consideration in an EXCLUDE state. Conjunctive considerations round out the logic of unqualified considerations, with formulation as: AND {consider} [NEXUS] A conjunctive consideration is invoked whenever it is encountered in the flow. It differs from a mandatory consideration only in being bypassed by an EXCLUDE/PRECLUDE scan. Except for a mandatory consideration, the foregoing constructs admit conditional qualifiers. Conditional qualifiers modify the forms as follows: OR {if} [condition] {then} {consider} [NEXUS] AND {if} [condition} {then} {consider} [NEXUS] Conditions are specified in terms of memory objects. An unsatisfied condition with OR causes the OR to be bypassed in the EXCLUDE/PRECLUDE scan. An unsatisfied condition with AND constitutes an implied EXCLUDE, interrupting the flow and starting a scan for alternatives. It is also possible to truncate the foregoing qualified forms after the condition, so that they become: OR {if} [condition] {then} {continue} AND {if} [condition] {then} {continue} These latter are termed 'local' considerations. Satisfying the condition in a local consideration constitutes an implicit CONCLUDE, whereas an unsatisfied condition constitutes an implicit EXCLUDE. An ultimate NEXUS that finishes a nest of considerations will use locals exclusively. Special care must be exercised not to make an inconsiderate exit from a NEXUS that has been posed as a consideration. Such an exit would confuse the logic by leaving unresolved calls on the stack. Provision is made for short-circuiting considerations on returns. This is done by specifying a NEXUS with optional ITEM in the CONCLUDE, EXCLUDE, or PRECLUDE. Control then returns directly to the specified consideration, and all intervening considerations are popped from the logical call stack. Care must be taken not to specify a non-existent consideration in the short circuit, since this would confuse the logic by leaving unresolved calls on the stack. This inferencing approach for stage 4 of GNOSIS is extremely flexible. The operation essentially involves logical subroutines, in much the same manner that Prolog predicates constitute logical subroutines. Like a predicate or rule, the same logical subroutine can become part of several different lines of reasoning. The activity goes up and down relative to NEXUS units instead of threading across them. This allows logic to be modularized in a way that accommodates local modifications without incurring echos elsewhere in the flowpath, thus setting the stage for subsequent exploration of adaptive GNOMEs. It also makes possible rather complete development of logic units at higher levels while postponing development of lower levels. EXPLANATORY GNOMES GNOSIS embodies several provisions for explaining the results of consultations. A 'review' PART is available for STEP ITEMs that will review questions and responses for a consultation. It is wise to segregate questions in particular FOLDs so that GNOSIS can be instructed to 'forget' memory objects associated with these FOLDs in preparation for a new consultation. There is also a substantial set of 'textual' PARTs. These PARTs serve multiple purposes. One purpose is to compose detailed explanations as a consultation unfolds. Such compositions can be stored either in global memory variables or in ASCII text files. With a view toward conservation of memory resources, such explanations are best relegated to text files unless they are quite brief. System responses to users during dialogs can be composed dynamically in like manner, and often without need for retention in global memory. Still another use for textual capabilities is composition of input files for demons. HYPERGNOMES AND HETERARCHIES In the terminology of GNOSIS, GNOMEs that invoke other GNOMEs recursively are called hyperGNOMEs. HyperGNOMEs are formed by incorporating GNOMIC (GNOMe Inter-Connect) ITEMs in the GNOME that does the invoking of another GNOME. Susceptibility to GNOMIC invocation is inherent to GNOMEs, and is one of the more significant features of the GNOME as a construct. A GNOMIC 'enters' a GNOME at a particular ITEM of a particular NEXUS in a particular FOLD. Since these must be specified, invoking a GNOME via a GNOMIC is not the blind process of invoking a demon. Some knowledge of structure in the target GNOME is required. It is also not presently possible to invoke a GNOME GNOMICally in its startup mode. That is, any file of 'greeting' information and/or preparatory STEP is bypassed. Aside from this, the invoked GNOME does not work any differently than it would if started independently. Any alterations in global memory objects by the invoked GNOME remain available to the calling GNOME unless specifically erased by the GNOME in the course of its activity. Any crosstalk between GNOMEs thus occurs through global memory and/or files used by both GNOMEs. GNOMEs do not scan other directories in attempting a GNOMIC unless specifically instructed to do so, even if other such directories lie in the path. Other directories to be scanned for GNOMICs can be specified in a gnome.PTH file, where 'gnome' is the name of the GNOME containing the GNOMIC ITEM and thus doing the calling. This takes care of the situation where two developers may create different GNOMEs having the same name in different directories, which happens quite frequently in classroom settings. A GNOMIC creates an interGNOMIC 'stack object' in global memory that enables a GNOME to find its way back to its own FOLDs after invoking a GNOME in another directory. As with most other aspects of a GNOME, it is possible to install GNOMICs dynamically during a run. This is the manner in which GNOMEs are registered with the TESTRACK GNOME during development. In the TESTRACK case, a GNOME is always entered GNOMICally at the first ITEM of its opening NEXUS. Thus, a GNOME does not present any file of introductory information when it is run on the test track. GNOMIC invocation can take place reciprocally between GNOMEs like dogs chasing each other's tails. Besides invoking other GNOMEs GNOMICally, GNOMEs can share FOLDs with other GNOMEs in a manner akin to siamese twins as illustrated in Figure 1, but this can extend beyond twins to any level of tuples. The combination of these capabilities with demonic activity makes possible extreme complexity of virtual systems under GNOSIS. It is interesting to consider GNOSIS in the context of Hofstadter's (1979) discussions of recursion, strange loops, and heterarchies. With networking demons, it even becomes possible for GNOMEs to teleport themselves across networks to other computers where they could proceed to initiate activity. This potential carries substantial security implications, and is one reason why explicit PARTs for self-adaptation have not been provided in the current stage of GNOSIS although it is relatively easy to do. We would prefer that GNOSIS foster nice GNOMEs or at least benign GNOMEs, rather than nasty GNOMEs. The open-ended systems concept of GNOSIS serves to extend the conventional view of object-oriented systems. GNOMEs are essentially symbolic objects at the system level. Object inheritance and polymorphism conventionally involve specification and modification. HyperGNOMEs feature object generalization that encompasses potentially self-organizing systems with emergent properties at some unspecified higher level. PERSPECTIVE GNOSIS has proven itself to be very versatile and highly intuitive for users. Management of meta-information is but one of its demonstrated applications. It has served for packaging and delivery of maps and images generated by other software systems. It has been used as a platform for computer-based tutorials and courseware for instruction. It has provided front-ends for modeling and spatial analysis software. It serves as teaching shell for development of expert systems in an artificial intelligence course at Penn State University as well as operational expert system host. It has even been used as an authoring system for 'hyper-papers' in a writing- intensive course. It is particularly well-suited for developing working prototypes of knowledge-based systems and decision-support systems that provide clients a basic level of early functionality while they decide whether more sophisticated and efficient versions are warranted. GNOSIS executables are treated as being in the public domain, so the applications that it supports can be freely distributed and redistributed as long as they do not involve third-party propriety demons. GNOSIS stage 3 and stage 4 each occupy one high-density 3.5-inch diskette. The 'manual' for GNOSIS is itself a hyperGNOME on a separate diskette. The Prolog source code for the GNOSIS engines is not needed, and is not available for distribution. Copies of the GNOSIS software can be obtained by sending 3 high-density 3.5-inch diskettes to: Dr. Wayne L. Myers Rm. 124, Land & Water Research Bldg. Penn State Univ. University Park, PA 16802 USA LITERATURE CITED Fink, M. 1993. An artificial intelligence software system as a preliminary research tool in landscape ecology and biodiversity. M.S. thesis in Ecology. The Pennsylvania State University, University Park, PA. Gelernter, D. 1991. Mirror worlds. Oxford Univ. Press. Hofstadter, D. 1979. Godel, Escher, Bach: an eternal golden braid. Basic Books, Inc. Schank, R. and R. Abelson. 1977. Scripts, plans, goals, and understanding. Lawrence Erlbaum Associates.