Documents

Conceptual Programming

Description
Conceptual Programming
Categories
Published
of 18
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  Conceptual Programming: Foundations of Problem-Solving  Roger T. Hartley and Michael J. Coombs Computing Research Laboratory and Department of ComputerScience BOX3CU NewMexico State University Las Cruces, NM 88003  ABSTRACT  Conceptual Programming is a term meant to convey a similar idea tothat of Logic Programming, but at a higher levelofrepresentation. Pro-gramming with concepts, as presented here, has all the advantages thatmanyknowledge representation schemes have indealing with declarativeknowledge i.e. explicitness, naturalness, expressibility,and transparency.It also givesprocedural knowledge these same features, using the samerepresentational technology,thus providing uniformity of expression forboth forms of knowledge. Wepresent an augmented conceptual graph the-ory,the building blocks of a conceptual programming system, and adescription of the interpreter for the system.Conceptual programming isintended for work in knowledge engineering. 1. Introduction: Programming systems for knowledge engineering. Knowledge Engineering is about the engineering of better computer systems to handletasks involving cognitive expertise, human decision making, heuristic reasoning and com-plex, empirically learned associations.The three main phases of a KE exercise allinvolveknowledge. Theyare: elicitation, representation and acquisition.The three arenecessarily intertwined, but also have a degree of independence in that theyinv olvedif-ferent active participants. Elicitationof knowledge involves a human expert (or his writ-ings); representation involves the knowledge engineer; acquisition involves the machineand its constraints.It is these constraints which are the focus of this paper.The central task, representation, is often a compromise between the needs of the knowl-edge engineer to cope with imprecision (or at least with the more informal, high-leveldescriptions necessary in representing expertise), and the desire for formally correctinference procedures.With this goal in mind, representation at the levelofconcepts, withgood epistemological underpinnings (Brachman, 1979) givesthe most flexibility.Along with the levelofrepresentation, the handling of procedural and declarative knowl-edge is also important for KE.Expertise is the application of appropriate problem-solv-ing techniques to a situation-specific body of facts. Strategies for problem-solving needexpression in the same terms as these facts in order to avoid loss of generality (Chan-drasekaran, 1984).If possible, procedural knowledge should enter into the same mecha-nisms of abstraction and generalization that are common in declarative knowledge (as inmanyknowledge representation systems such as KL-ONE).Commonly there is no  -2-choice of strategy provided or strategies are expressed in a different language from therest of the knowledge base.This paper describes a uniform way of including proceduralknowledge and factual information in both the assertional and terminological componentsof the representation system.The paradigm behind these methods is called  conceptual programming .Until a fewyears ago the best available tools for building expert systems were the‘‘empty’’systems, typified by EMYCIN (van Melle, 1980).Aspate of EMYCIN look-alikes are nowcommercially available (e.g. Teknowledge’sM1and TI’sPersonal Consul-tant). Expertsystem technology has become equated with the rule-based paradigm (syn-tactic pattern-matching, forward or back chaining), eventhough such systems have beencriticized for their methodological and technological shortcomings (Clancey, 1983; Hart-ley, 1984; Chandrasekaran, 1983).The reported inadequacies of these systems led to thedevelopment of   hybrid  systems which include IntelliCorp’sKEE and Inference’sART.Among the ‘‘goodies’’theyinclude are frames, rules, procedures, demons (or ‘‘active val-ues’’), viewpoints and truth maintenance, all in the same package.However, the mereprovision of facilities does not makeiteasier to build expert systems since there is pre-cious little help in choosing appropriately among them.At the other end of the scale is Prolog, whose foundations are rooted in formal logic, thusgiving an extremely elegant system, but which turns out to be inefficient in execution (inits pure form) and limited in scope.In between these twoextremes there are fewexpertsystem tools which are expressive enough for ease of use and applicability and yet haveformal underpinnings.Anotable exception is Omega,best described as a descriptionlogic (Attardi et al., 1984) which caters for frame-likeexpression of declarative knowl-edge yet has a formally complete set of inference rules.We might wish for a language system in which arbitrary expressions of knowledge can behandled, and yet the arbitrariness is restricted to capturing real relationships in the world,not in the methods and procedures used to manipulate them.We might hope that therewould be no Lisp code to write and no choice to be made between seemingly equivalentpieces of technology.Itispartially this lack of orthogonality in the hybrid systems whichmakes them so hard to work with.Moreover, a system which explicitly separatesdomain-specific information from all other types  and  in which everything that is notdomain-specific is minimized and formalized is preferable.Conceptual Programming(hereafter ‘CP’) is just such a system since it expresses the content of knowledge, bothdeclarative and procedural, using concepts, and its interpreter follows a formally correctmethodology based on hypothesis generation and testing. 2. Extendedconceptual graphs and procedural knowledge Conceptual graphs, as described in Conceptual Structures, express declarative knowledge.An  assertional mechanism built using such graphs would allowacollection of graphs torepresent a state of knowledge of an agent.If rules governing the assertion and de-asser-tion of graphs can be expressed within the  terminological component, then proceduralknowledge can also be incorporated.Sowa has actors behaving likefunctions embeddedwithin a graph to provide concept referents (i.e.for instantiation).Our extension allowsactors to be much more like‘‘active concepts’’which accept states as preconditions andev ents as triggers.Having been triggered, theyassert states and enable further acts as by-products of their activity.These actors may be used to express  causality ,inv olving states  -3-and events, and  inferences ,inv olving propositions.Since each actor of this sort is com-pletely specified by its inputs and outputs, there is no need to label the actor box in thegraph. Ineffect, the actor merely acts as a confluence node for its inputs and outputs, notas a function as in Sowa’s srcinal formulation.In the example in figure 2a the declarative component of the graph expresses an assertionwhich in English can be written: ‘‘A person x is the agent of an act of giving a physicalobject, which is in x’spossession, to a person y’’. Theaddition of an actor can expressthe change of possession from x to y.The actor is linked to its inputs and outputs via spe-cial conceptual relations which collectively express a factorization of the combination of states and events typically found in a theory of action (cf. Rieger’ssimilar treatment incommon-sense algorithms: Rieger,1976). Inour case, a state is defined canonically as aspecialization of the graph [T] → (REL) → [T] and an event as an arbitrary number of  joins (on ACT) of specializations of the graph [ACT] → (CASE-REL) → [CASE-TYPE]where CASE-REL encompasses anyofthe standard set of case relations (AGT,PTNT,INST,SRCE etc.) and CASE-TYPE is restricted to conform to the corresponding case.Forexample, the AGT relation is, canonically,[ACT]  → (AGT)  → [ANIMATE] andSRCE is [ACT] → (SRCE) → [LOCATION]. Inthe example, twoinputs are needed: thestate of possession of a physical object by person x (via the relation ‘TEC’) and the eventinvolving x giving it to y,via the relation ‘AS’, and the de-assertion of the input state.‘TEC’ denotes this transitory state.The graphs involving actors are actually abbreviatedfrom graphs containing embedded graphs of type STATEand EVENT.Howev er, theembedded levelhas been removed, unambiguously,since the nature of actor inputs andoutputs are restricted.The complete graph is giveninfigure 2b.Itcan be seen that figure2a is cleaner,aslong as Sowa’s srcinal notation is extended to allowrelations embeddedin states to be connected to actor relations.The actor relations are necessary to typeinputs and outputs according to their temporal relationships.The epistemology of actors, together with their inputs and outputs is meant to be as sim-ple as possible while still maintaining adequate expressiveness. Statesare to be thoughtof as intermediate between events; roughly speaking, states enable events and eventscause states.Anyactor linked to a relation (via one of the actor relations shown in figure2c) has a state as input or output; an actor linked to a concept has an event as input or out-put. Inputstates can either be triggering, or enabling, and transitory or persistent, in allcombinations. Triggering states are ones which causes events directly and the existenceof the state is enough to start the event. For example, a switch being ‘on’ causes currentto flow. Onthe other hand, enabling states have nodirect causal link.To continue theelectricity example, the presence of a voltage source enables the current to flow, but doesnot trigger it under normal circumstances.States can also be classified as transitory,meaning that the state disappears when some event stops it, or persistent, when an eventhas no effect. Thusthe presence of a voltage source is persistent with respect to the cur-rent flow, but transitory with respect to the failure of the source (say a battery runningdown). Itis also possible that the absence of a state can trigger or enable an event. Inthis way it is possible to handle negated conditions.Forexample, a solenoid may bemagnetized thus inhibiting a switch from closing.Asoon as the solenoid becomesunmagnetized, the switch closure event can begin.Events are either continuous, when their effects continue after the event ceases, or one-off when the effects terminate with the event. Theflowing of a current in a wire causes a  -4-magnetic field to surround it, but as soon as the current stops, so does the field.This isone-offbehavior.Onthe other hand the act of closing a switch causes the current to flow,butitremains flowing after the act has terminated.This is continuous behavior.Aswithstates causing or inhibiting events, events can cause the presence or absence of a state tooccur.Itisalso possible to represent a ‘‘lagged response’’which occurs on some formsof causality.Infact the current/magnetic field example is one of these, where the fieldtakes a finite time to build, and cannot be thought of as coextensive intime with the cur-rent flowing. Inparticular,after the current is switched offthe field takes a small amountof time to collapse again.Figure 2c shows all the possible combinations of state and event causality,together withtheir canonical time charts.These simple diagrams showthe temporal extent of statesand events and their interrelationships.Time proceeds to the right, along the horizontalstraight lines.Asmall vertical bar indicates a definite start or stop instant, whereas anarrowhead indicates an indefinite instant.The vertical relationship between the instants(i,e, before, after or equal) characterizes the different relationships between the intervals.The full meaning and use of the actor relations in figure 2c are described in (Hartley,1987), along with their translation into Allen’stemporal relations (as in Allen, 1983).The example to be presented in section 7 shows howactors can express the proceduralcomponents of concept definitions, and can be ‘compiled’ into declarative forms suitablefor answering queries about the sequencing of states and events.Figure 2a.An example of an actor. 3. ConceptualProgramming: a programmer’spoint of view. Writing a conceptual program is very similar to manyother forms of top-down program-ming. Inparticular the similarity with Lisp and Prolog is striking.In both of these lan-guages one writes a large number of hierarchically related definitions, expressing, inLisp’scase, procedurality and in Prolog’scase, a mixture of logical relationships and pro-cedurality.The program is then executed by handing control to one of the defined objectsin some pre-determined way.Functions or predicates are only related through control(one calls another) and through the binding of values in parameters.However, in

1

Jul 23, 2017
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks