Synergy as an Hybrid Object-Oriented Conceptual Graph Language

Adil KABBAJ

INSEA, Rabat, Morocco, B.P. 6217

Fax : (212) 7 77 94 57

 

Abstract. This paper presents the use of Synergy as an Hybrid Object-Oriented Conceptual Graph Language (HOO-CGL). Synergy is an implemented visual multi-paradigm language based on executable conceptual graphs with an activation interpretation, instead of a logical one. This paper describes the formulation in Synergy of basic concepts of the hybrid object-oriented paradigm: encapsulation, definition of a class with methods and daemons, method and daemon definitions, class hierarchy, instance and instantiation mechanism, inheritance (both property and method inheritance), method call, method execution and daemon invocation due to accessing data. An example is used to illustrate the presentation of such an Hybrid Object-Oriented Conceptual Graph Language.

 

Note: This paper has been published in ICCS’99 Proceedings by Springer-Verlag:

1      Introduction and previous works

Due to the relevance of the object-oriented paradigm (more abstraction, encapsulation and modularity), its relationship to conceptual graphs has been investigated by several authors [2, 20, 13, 18, 3, 1].

As noted early by [2], melding conceptual graphs (CG) with object-oriented principles (OOP) to produce object-oriented CG “presents the possibility of greater semantic capture than can be obtained with either technique alone”.

A CG-language that aims to incorporate OOP should support (at least) the concepts of class, instance, method, inheritance, instantiation and sending messages. This paper presents a running implementation of such an OO-CG language. Moreover, the language is enhanced by the incorporation of daemons to enable reactive OO-CG programming.

To motivate the need for such a language and to put this research in context, this section gives an overview of related works.

 

In the mapping of OO concepts to CG, it is straight-forward to map a declarative part of a class definition to a type definition, an instance description to a concept with a specific referent and description, and OO inheritance to type hierarchy. Several approaches have been proposed however for method description and call : map a method to an actor graph [2], map a method to a schema with bound actors [20], map a method to a process defined with a CG (or a set of CGs) [18], map a method to a defined goal in Prolog+CG language [3] and map a method to a dyadic relation defined as a single state-transition description [1].

According to the standard view of CG [16], CG is a purely declarative notation and to perform actions, one should use actors and functional dataflow graphs [16]. In their formulation of methods, Hines and al. [2] and Wuwongse and Ghosh [20] follow this standard view. Thus, they commit method descriptions to the limited expressive power of functional dataflow graphs as outlined by Sowa [16, 17, 19] (see also [6] for a more detailed discussion).

 

Sowa [18] and Ellis [1] use CG to represent both declarative and procedural knowledge. They propose CG as a logical foundation and as a specification language for object-oriented systems. Sowa proposal is based on two aspects of CG : a) using contexts to realize encapsulation and, b) using Peirce’s rules of inference to define method execution as theorem proving. Two additional rules have been proposed by Sowa to enable the insertion of a message in the context of the object.

Ellis [1] notes that if the method is defined outside the type definition and it is defined as a dyadic relation with a simple state transition semantic and a modus-ponens interpretation, then method execution (by theorem proving) will be more efficient and the two additional rules proposed by Sowa will be of no use.

Both Sowa and Ellis focused on method execution only and this process is presented through a simple example only. The generality of their models has not been considered and the models should be developed further to assess their claims (e.g., to consider in detail all the concepts of OOP, and to develop an executable language and a running implementation). These remarks apply also to the approaches of [2] and [20].

Also, defining methods outside the class definition, as actors [2], as  schemas [20] or as relations [1], violates the encapsulation principle which constitutes the basis of OOP. Like Sowa and as explained in this paper, we use contexts to realize encapsulation and to define methods inside class definition.

 

Lukose presents in [13, 14] “actor graphs” as the result of the merger of CG and OO principles : “Actor Graph = CG + Actor”; CG is used to define the declarative part of an action while “Actor” represents the procedural part. OO principles are used to define a domain-dependent notation for the definition of actors : on top of the Prolog language and the modules of the Deakin ToolSet, Lukose developed a Prolog-based data structure in order to define actors as action classes and to build and use actor hierarchy. Methods of an actor are defined as rules of Prolog and CG is used by actors as data structure, beside other Prolog data structures. Thus, CG is neither used to define actor classes nor to define the methods of an actor class.

 

All the above works have been concerned by the class-OO paradigm. In fact, the OO paradigm is subdivided in general in class-OO paradigm and frame-OO paradigm, leading to two OO language families. The first paradigm is message-driven and computation is based on method execution while the second is data-driven and computation is based on daemon invocation due to accessing data [15]. It has been recognized early that the two OO paradigms are complementary [12] and, to get more flexibility and to deal with complex and real-world applications, they should be integrated in an hybrid OO paradigm. And in fact, several hybrid OO languages have been proposed [15].

 

This paper presents the Synergy language as an hybrid or reactive object-oriented CG language. Synergy is a visual multi-paradigm language based on CG activation [5, 6, 7, 8, 9, 10]. Synergy is multi-paradigm since it integrates functional, procedural, process, reactive, object-oriented and concurrent object-oriented paradigms. The integration is done using CG as the basis knowledge structure, without actors or other external notation. In Synergy, CG is used as a knowledge representation formalism with activation-based interpretation instead of a logical one.

 

The Synergy language constitutes the main part of the SYNERGY environment [10]. SYNERGY is a CG tool implemented with Microsoft Visual C++ (a portable Visual J++ implementation will be available in summer 1999) and it is composed of a CG graphic editor, the Synergy language, an engine for dynamic formation of knowledge bases [4, 6, 11] and an information retrieval process. The SYNERGY tool is described in [6, 10], the SYNERGY site (www.insea.ac.ma/InseaCGTools/Synergy.html) is under construction and a SYNERGY group is being formed to enhance, extend and use SYNERGY in many ways.

 

This paper is organized as follows : sections 2 recalls some basic elements of Synergy. Section 3 presents the anatomy of hybrid object-oriented CG programming in Synergy: definition of a class with methods and daemons, method and daemon definitions, class hierarchy, instance and instantiation mechanism, method call (message), inheritance mechanism (both property and method inheritance) and method/daemon execution. An example is used in section 3 to illustrate the different concepts of such an hybrid object-oriented CG language. Using the same example, section 4 presents some detail of methods and daemons execution. Finally, section 5 gives a conclusion with an outline of some current and future works.

2      An overview of the Synergy language

This section recalls some basic elements of the Synergy language that are mandatory to understand the following sections. We refer the reader to [10] for a more detailed presentation of Synergy.

 

An application (e.g., a program) in Synergy is represented as a CG with two concepts: [LongTermMemory] and [WorkingMemory]. The top window in Fig. 1 represents the application “OOSample”. The contain of the concept [LongTermMemory] describes the knowledge base (KB) of the application in terms of concept type hierarchy augmented by type definitions, individual descriptions, type schemas and type synonyms. The whole KB is represented by a CG.

 

 


Fig. 1. An OO example - a class hierarchy. To have a concise drawing of CG, the graphic editor of SYNERGY does not encircle relations with circles and it shows only the type and the referent of a concept; the description and the state fields are shown only upon a demand from the user. However and as illustrated in this Fig. and in Fig. 2, the CG editor draws a small triangle at the left-bottom of a rectangle to indicate that the concept has a description. The triangle is blue if the description is simple and red if it is a CG. The state field has a visual representation too : the concept at state “trigger” has a green rectangle, the rectangle is “red” if the state is “in-activation”, etc. For more information on the CG graphic editor of SYNERGY see [6, 10].

 

The second window in Fig. 1, named “LongTermMemory”, shows the contain of the concept [LongTermMemory], which is the KB of the application “OOSample”; a simple class hierarchy.

In this paper, we consider KB composed of concept type hierarchy with type definitions only (without type schemas and type synonyms). Moreover, the types represent classes.

Relevant to this paper, please note that Synergy incorporates the encapsulation/modularity principle by allowing a concept type to be defined in the context of another concept type definition. As shown in the next section, this is useful for the encapsulation of methods (and daemons) in the class definition.

The concept [WorkingMemory] of an application describes the working space where the user specifies his requests, represented by CGs.

 

A CG in Synergy is a set of concepts related eventually by dyadic relations. A relation between two concepts can be either an element of the Synergy-Relation-Set (SRS) or it can be an identifier provided by the user. The  SRS is composed of the primitive relations “in”, “out”, “next” and “grd” (guard) which are data/control relations and the primitive relations “sp” (specializationOf/generalizationOf), “inst” (instanceOf), “sta” (situationFor) and “synm” (synonymOf) which are “knowledge base relations”; they are used to organize the KB of a Synergy application.

 

A concept is described by four fields : [Type :Referent  =Description   #State]. The referent, if specified, can be an identifier of an instance, a variable (that can be bound to a referent) or a co-referent. A description, if specified, can be a simple data (for example, a real, a boolean or a string) or a composed data (a CG). The state field is defined on the following set : {steady, trigger, check-preconditions, wait-preconditions, wait-value, in-activation, wait-affectation, wait-end-affectation}. The state field represents the dynamic part of the concept. It is considered in detail in [6, 10].

3           The anatomy of Hybrid Object-Oriented Programming (HOOP) in Synergy

This section describes how Synergy supports the basic notions of HOOP : section 3.1 introduces class definitions, method and daemon definitions as well as class hierarchy, section 3.2 describes the instantiation mechanism and section 3.3 defines method call, inheritance and method/daemon execution.

3.1         Class hierarchy and class, method and daemon definitions

Definition 1. The root of any class hierarchy in Synergy is the “primitive” concept [Class]. Using the CG graphic editor of the environment SYNERGY, the user can define a new class and relate it to its direct super-class by the relation “sp” (specializationOf).

 

Fig. 1 shows a simple example of a class hierarchy, with a zoom-in on two classes ([Clothe] and [LuxuryItem]) including their “Methods” and “Daemons” contexts. This example will be used through the sub-sections of section 3. The definition of the class [Item] is given in Fig. 2.

 

 

Definition 2. A class is a concept type defined by its super-class, its declarative part and its procedural part.

-    The super-class of the class is represented by the concept [SUPER_CLASS : super], with “SUPER_CLASS” that represents the direct super-type of the class type and “super” a key-word referent.

-    The declarative part is composed of the attributes of the class. The attributes are represented by a set of concepts that could be connected to the super-class to form a connected CG.

-    Daemons can be attached to attributes of the class. The set of daemons used in the class should be defined in the context [Daemons] contained in the class definition.

-    The procedural part is composed of a set of methods defined in the context [Methods] which is contained in the class definition.

-    Attributes, methods and daemons are optional.

-    A default value for an attribute can be specified as a description for the corresponding concept.

 

In our example (Fig. 1 and 2), the class [Clothe] has [Item] as a direct super-class, it has three attributes (“Color”, “Size”, “PeriodOfUse”), two methods (“InitializeClothe” and “IsGoodChoice”) defined in the context [Methods] and one daemon (“PER_USE”) defined in the context [Daemons]. The daemon  (“PER_USE”) is used in the class definition to compute the value of the attribute “PeriodOfUse”. Thus, if the value of this attribute is needed, the daemon [PER_USE] will be triggered.

The class [LuxuryItem] has also [Item] as a direct super-class, it has no attribute and has two methods (“ATIPrice” and “InitializeLuxItem”). The method “ATIPrice” is a redefinition of a method defined in the super-class [Item].

 

The class [Item] has [Class] as a direct super-class (Fig. 2), it has six attributes (“Reference”, “Designation”, “DateOfProduction”, “NetPrice”, “HTPrice”, “Quantity”), five methods (“Retract”, “Add”, “InitializeItemPart”, “ATIPrice”, “TransPrice”) and two daemons (“HTCPrice”, “StockUnderFlow”). Each time the attribute “Quantity” gets a new value, the daemon [StockUnderFlow] will be triggered, since it has [Int: Quantity] as an input argument. Concerning the daemon [HTCPrice], it will be triggered if the value of the attribute [Real: HTPrice] is needed, since it has this attribute as an output.

 

Definition 3. The definition of a method or a daemon is represented by a CG (CG of Synergy, with the underlying computation model [6, 10]).

-    A method and a daemon can be an operation (a procedure or a function) or a process. The user should specify, in the method/daemon definition, the concept [Operation : super] for the first case, or the concept [Process : super] for the second.

-    A method and a daemon can have input argument(s)/parameter(s) and/or output argument(s)/parameter(s). A parameter is a reference to the corresponding argument.

-    The definition of a method and of a daemon contains in general defining concepts (for local referents) and/or reference concepts; references to attributes of the class where the method/daemon is defined, or to attributes of a super-class (direct or indirect), or even to defining concepts which should be contained, at time execution, in an outer context.

-    The definition of a method and of a daemon can contain a concept that represents a call to : a) an operation defined locally in a context specified in the [LongTermMemory], b) an operation defined globally in the [LongTermMemory], or c) a primitive operation. In addition, the definition of a method can contain a concept that represents a call to a method of the same class or of a super-class (direct or indirect).

 


Fig. 2. Definitions of the class [Item] and of some of its methods and daemons

To illustrate the above definition, let us explain the definition of the method “Retract” and of the daemon “StockUnderFlow” (Fig. 2). The method [Retract] is defined as an operation with one input parameter [Int : in|_q ] and no output parameter. “in|” and “out|” prefixes the referent of an input and an output parameter respectively. The definition of the type-method “Retract” contains a defining concept [Int : in|_q ] for the referent-parameter “_q” and a reference concept [Int : Quantity. ] to the attribute [Int : Quantity] of the class [Item]. In Synergy, the concept [Int : Quantity] represents the defining node for the referent “Quantity” while the concept [Int : Quantity. ] represents a bound or a referent node.

The daemon [StockUnderFlow] is defined as an operation with one input parameter [Int :in|_Qty] and one output parameter [Bool: out|_Res].

3.2      Instantiation mechanism

The Synergy working space, represented by the context [WorkingMemory], can be used by the user to specify entities (like instances of classes) and requests. For instance, [WorkingMemory  = [Clothe: Clothe1] ] contains the declaration of the class instance “Clothe1”. At the specification time, the instance has no description, but during method execution the first access to the instance will trigger its instantiation.

 

Definition 4. The creation of an instance of a class consists in locating the class definition and then creating a description for the instance by a partial copy of the class definition. The copy is partial since the concepts [Methods] and [Daemons] (and of course, the content of the two concepts) are not copied.

 

Fig. 3 shows the result of  “Clothe1” instantiation using the definition of the class [Clothe] (in Fig. 1). Note that the concepts [Methods] and [Daemons] are not copied but the attachment of the daemon [PER_USE] to the attribute [Int: PeriodOfUse] is copied.

 

 


 

 

 

 

 

 

 

Fig. 3. The result of the instantiation of [Clothe: Clothe1]

 

In Synergy, the creation of an instance of a class is just a special case of referent instantiation ; if the referent is not an instance of a class, the instantiation consists in a complete copy of the referent type definition. The referent can be either an individual identifier, a variable identifier or an implicit variable (when the referent is not explicitly specified). As illustrated in the next section, instantiation of both referent and instance of a class is a basic operation in the Synergy interpreter.

3.3      Message, inheritance and method/daemon execution

While a method is defined in the context of a class definition, a message (or method call) should be interpreted in the context of an instance description.

 

Definition 5. Sending a message to an instance “Inst” for the execution of the method “Mtd” is represented by a concept with the composed type “Inst.Mtd” : [Inst.Mtd]. The method is interpreted in the context of the instance description.

 

A composed type in Synergy [10] has the form “Ident1.Type2” where “Ident1” is either a type identifier or an instance identifier. In the first case, the type “Ident1.Type2” is a reference to the type “Type2” which is defined in the context of “Ident1” definition. In the second case, the type “Type2” is defined in the class of the instance “Ident1”.

 

Fig. 4 shows a request, formulated in the [WorkingMemory], that is composed of two messages : the first message [Clothe1.InitializeClothe] is sent to the instance “Clothe1” to execute the method “InitializeClothe”, followed by a second message sent to the same instance to execute the method “ATIPrice”.

 

Calling a method, from the body of another method or due to a message involves inheritance mechanism to locate the method. Beside this “method inheritance”, method execution involves in general “property inheritance” to locate the defining concept for a property or attribute of the instance.

 

 


                         

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Fig. 4. Sending messages [Clothe1.InitializeClothe] and [Clothe1.ATIPrice]. Unlike the SYNERGY graphic editor, we show explicitly in this Fig. and in others the description and the state of a concept. “#?” stands for  “state trigger” and “#!@” for “state in-activation”.

Definition 6.  Inheritance concerns the methods and the attributes of a class :

-    Method inheritance : the definition of a method “Mtd” specified in a message [Inst.Mtd] is looked for in the definition of the class of the instance “Inst” and then upward in the class hierarchy until the method definition is located or the class [Class] is reached. In the same way, the definition of a method “Mtd” specified in the body of another method “Mtd1” is searched first in the definition of the class where the method “Mtd1” is defined and then upward in the class hierarchy, if necessary.

-    Property inheritance : in the body of a method call [Inst.Mtd] a co-referent is resolved by looking for its defining concept in the description of the instance “Inst”. If the defining concept is not found there, the search continues recursively in the “super” contexts embedded in the instance description until the defining concept is found or the context [Class: super] is reached in which case the co-referent is not a reference to a property (direct or inherited) of the instance, and the search of the defining concept will continue in the context that contains the instance description.

 

Definition 7. Method and daemon executions conform to concept execution or interpretation which constitutes the basis part of the Synergy interpreter.

 

Briefly, interpretation of a CG consists in the parallel interpretation of its concepts and a concept C is interpreted according to its lifecycle : a concept C at state “trigger ; ?” is requested to “determine and then interpret (i.e. evaluate or execute) the description”. Once the description is determined (by instantiation for example, if the concept type is defined) and if the concept C has preconditions, it will enter a waiting phase until its preconditions are satisfied. At the end of this waiting phase, the concept’ description is evaluated and then, the concept will enter another waiting phase until its post-conditions are satisfied. After that, the concept C returns to the state ``steady ; o``.

We refer the reader to [5, 6, 10] for a more detailed description of concept interpretation, CG interpretation and the Synergy interpreter in general.

4      An example of methods and daemons execution

As an example of methods and daemons execution, let us follow in some detail the execution of the message [Clothe1.InitializeClothe] (Fig. 4). Its input arguments are in “trigger” state. The “in” relation will propagate this state to [Clothe1.InitializeClothe]. Being at state “trigger” and since the concept referent does not have a description and its type is a composed type, the first action is to locate the definition of this latter : the interpreter will attempt to find the definition of “InitializeClothe” in the definition of the class “Clothe” (since Clothe1 is an instance of Clothe). Once located, the definition is then instantiated.

 

Note that the type of the message [Clothe1.InitializeClothe] becomes “Clothe@Clothe1.InitializeClothe”. Indeed, once determined, the class of the instance prefixes the instance identifier to avoid the search of the class (several times) during message execution. The prefix will be eliminated at the end of the message execution, e.g., to become again “Clothe1.InitializeClothe”.

 

Let us consider now the interpretation of [Clothe@Clothe1.InitializeClothe] (Fig. 5). The states of the arguments are transmitted to the corresponding parameters which become in “trigger” state. Then, by forward propagation from the first five parameters, the concept [InitializeItemPart] that is contained in the description of [Clothe@Clothe1.InitializeClothe] becomes in turn at state “trigger”. The same effect happens in parallel to the two primitive operations (:=); triggered by the six and the seven parameter respectively.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Fig. 5. Instantiation of [Clothe1.InitializeClothe]

Let us follow now the interpretation of the concept [InitializeItemPart #?] : the interpreter will look for the type definition of “InitializeItemPart” (since it is triggered, its type is not a primitive operation and it is not a description).

The interpreter finds that “InitializeItemPart” is a method inherited from the class “Item” (since it occurs in the context of the method “InitializeClothe” in [Clothe@Clothe1.InitializeClothe], the interpreter checks first if the type “InitializeItemPart” represents a method defined in the class of the method “InitializeClothe” or in a super-class (direct or indirect) of the class).

The definition of “InitializeItemPart” is now located and the instantiation is done to produce a description for the referent of [InitializeItemPart] (Fig. 6). Its concept type becomes “Item.InitializeItemPart”, its state changes to “in-activation” and its description is now executed (interpreted) : the five primitive operations “:=” that constitute its body are triggered and then executed in parallel (Fig. 6).

 

To illustrate property inheritance and daemon invocation, let us consider now the execution of one of the five affectations contained in [Item.InitializeItemPart] :   

[Int: in4| .] —in® [:=]—out®[Int: Quantity.] 

 

Co-reference resolution using inheritance. The interpreter has to determine first the defining concepts for the two arguments of the affecation : [Int: in4| .] and  [Int: Quantity.].

 

 


Fig. 6. Execution of the message [Clothe1.InitializeClothe]

To locate the defining concept of [Int: Quantity.] the interpreter initiates a search composed of two phases illustrated by Fig. 7 : an upward search in the embedded contexts starting from [Int: Quantity.] (Fig. 7.a) and then a downward search based on property inheritance (Fig. 7.b). Note that Fig. 7 shows only the parts that are in focus; the complete description of each context is not shown.

 

·     The upward search (Fig. 7.a). The interpreter searches first in the current context [Item.InitializeItemPart] for a concept with referent “Quantity”. Since no such a concept is specified in that context, the interpreter searches in the upward context : [Clothe@Clothe1.InitializeClothe]. Here too no such concept is found. Now and since the current context is a message (known from the form of its concept type : “Clothe@Clothe1.InitializeClothe”), the interpreter continues its search in the context of the instance ([Clothe: Clothe1]) instead of following the search in the upward context ([WorkingMemory]) of the previous current context ([Clothe@Clothe1.InitializeClothe]).

·     The downward search (Fig. 7.b). First, if the current context [Clothe: Clothe1] has not a description yet, the interpreter will instantiate it. The result of the instantiation is similar to the CG in Fig. 3. Since no concept with referent “Quantity” is specified in the current context ([Clothe: Clothe1]) and since this latter has a super-concept ([Item: super]) with a defined type (“Item”), the search will continue in [Item: super] which becomes the current context. Property inheritance is in action now ! The search will continue in the context [Item: super] once its description is created by instantiation. The current context [Item: super] contains a concept with referent “Quantity” : [Int: Quantity]. Thus the defining concept of [Int: Quantity.] has been located in [Item : super].

 

Fig. 7.b shows the co-reference link that connects now the two concepts    [Int: Quantity.] and [Int: Quantity].

 

 

 

 

 

 

 

 

 

 


                                                                                                                       

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


(b) : The backward search step

Fig. 7. Co-reference resolution using inheritance

Daemon invocation. Let us resume the execution of the affectation contained in [Item.InitializeItemPart] (Fig. 7):  [Int: in4| .]—in®[:=]—out®[Int: Quantity.]. From the previous step (co-reference resolution), assume that the defining concept of [Int: Quantity.] is located and the defining concept of [Int: in4| .] is [Int  =  100]; the fourth argument of [Clothe@Clothe1.InitializeClothe] (Fig. 4). After the execution of the affectation [:=] (Fig. 7), two events result : a) the value 100 is assigned to the defining concept [Int: Quantity] contained in [Item:super] (Fig. 7, the right part), b) the concept [Int: Quantity.] becomes in state “trigger” (“#?”).

The state “trigger” of [Int: Quantity.  #?] is then propagated, through the co-reference link, to the defining concept [Int: Quantity] and also to its upward contexts ([Item: super] and [Clothe: Clothe1]) (Fig. 7). The interpreter is now committed to interpret/activate those contexts and hence to interpret the concept [Int: Quantity #?] too (because it is contained in the active context [Item: super]). Finally, the state “trigger” is then propagated, through the relation “in”, from [Int: Quantity  #?] to [StockUnderFlow], leading to a forward invocation of the daemon [StockUnderFlow].

 

To summarize : the execution of the message [Clothe@Clothe1.InitializeClothe] (Fig. 6) involves the execution of the method “InitializeClothe” which leads to the parallel execution of the method [Item.InitializeItemPart] and two primitive operations “:=” (Fig. 6). Execution of [Item.InitializeItemPart] involves parallel execution of five primitive operations “:=”, among them : [Int: in4| .] —in® [:=]—out®[Int: Quantity.], which leads to the invocation of the daemon [StockUnderFlow] (Fig. 7).

When all the active concepts of [Item.InitializeItemPart] terminate their execution, the concept [Item.InitializeItemPart] terminates its execution too and because it is defined as an operation (not as a process), its description is erased. Again, when all the active concepts of  [Clothe@Clothe1.InitializeClothe] terminate their execution, the message terminates its execution too.

 

5        Conclusion and future works

This paper presented the Synergy language as an hybrid object-oriented conceptual graph (HOO-CG) language. A detailed description is given for the formulation in Synergy of the basic concepts of the hybrid object-oriented paradigm: encapsulation, definition of a class with methods and daemons, method and daemon definitions, class hierarchy, instance and instantiation mechanism, inheritance (both property and method inheritance), method call, method execution and daemon invocation due to accessing data.

Those concepts have been illustrated by a detailed example.

 

Several projects within the SYNERGY group are in progress, including the development of complex object-oriented applications, the extension of Synergy to enable the construction of interfaces (composed of boxes, buttons, sliders, etc.) and the extension of Synergy to enable a connection with data bases (for efficient manipulation of a great number of instances).

References

1.     Ellis G., Object-Oriented Conceptual Graphs, in Proc. of the Third Intern. Conf. on Conceptual Structures, ICCS'95, Santa Cruz, CA, USA (1995)

2.     Hines T. R., J. C. Oh, and M. A. Hines, Object-Oriented Conceptual Graphs, in Proc. of the Fifth Annual Workshop on Conceptual Structures (1990)

3.     Kabbaj A., C. Frasson, M. Kaltenbach and J-Y Djamen, A conceptual and contextual object-oriented logic programming : PROLOG++ language, in Proc. Second  International Conference on Conceptual Structures, ICCS’94, Tepfenhart and al. (Eds), Springer-Verlag (1994)

4.     Kabbaj A., Self-Organizing Knowledge Bases: The Integration Based Approach, in Proc. Of the Intern. KRUSE Symposium : Knowledge Retrieval, Use, and Storage for Efficiency, Santa Cruz, CA, USA (1995)

5.     Kabbaj A. and C. Frasson, Dynamic CG: Toward a General Model of Computation, Proc. Third  International Conference on Conceptual Structures, ICCS’95, Santa Cruz, CA  (1995)

6.     Kabbaj A., Un système multi-paradigme pour la manipulation des connaissances utilisant la théorie des graphes conceptuels, Ph.D Thesis, DIRO, Université de Montréal, June (1996)

7.     Kabbaj A. and C. Frasson, An overview of SYNERGY : a conceptual graph activation language, accepted but not presented at the Fourth International Conference on Conceptual Structures (ICCS’96)

8.     Kabbaj A., Rouane K. and Frasson C., The use of a semantic network activation language in an ITS project, Third International Conference on Intelligent Tutoring Systems, ITS’96, Springer-Verlag (1996)

9.     Kabbaj A., Contexts, Canons and Co-references as a basis of a multi-paradigm language, submitted to Fifth International Conference on Conceptual Structures (ICCS’97)

10.  Kabbaj A., A conceptual graph activation-based language : Synergy and its environment, submitted to Seventh International Conference on Conceptual Structures (ICCS’99), this volume

11.  Kabbaj A., H. Er-remli and K. Mousaid, An integration-based approach to dynamic formation of a knowledge-base: The method, its implementation and its realizations, submitted to Seventh International Conference on Conceptual Structures (ICCS’99)

12.  Kunz J. C., T. P. Kehler and M. D. Williams, Applications Development Using Hybrid AI Development System, The AI Magazine, 5:4, p. 41-54, (1984)

13.  Lukose D., Executable conceptual structures, Proc. First  International Conference on Conceptual Structures, ICCS’93, Quebec City, Canada (1993)

14.  Lukose D., T. Cross, C. Munday and F. Sobora, Operational KADS Conceptual Model using conceptual graphs and executable conceptual structures, in Proc. of the Third Intern. Conf. on Conceptual Structures, ICCS'95, Santa Cruz, CA, USA (1995)

15.  Masini G., A. Napoli, D. Colnet, D. Léonard and K. Tombre, Les langages à objets, Inter-Editions (1990)

16.  Sowa J. F., Conceptual Structures : Information Processing in Mind and Machine, Addison-Wesley (1984)

17.  Sowa J. F., Relating Diagrams to Logic, Proc. First International Conference on Conceptual Structures, ICCS’93, Quebec City, Canada (1993a)

18.  Sowa J. F., Logical foundations for representing object-oriented systems, J. of Experimental and Theoretical AI, 5 (1993b)

19.  Sowa J. F., Conceptual Graph Standard and Extensions, in Proc. Of the 6th International Conference on Conceptual Structures, ICCS’98, Springer (1998)

20.  Wuwongse V., B. G. Ghosh, Towards Deductive Object-Oriented Databases Based on Conceptual Graphs, in Proc. of the 7th Annual Workshop on Conceptual Structures (1992)