MultiNet is an expressive formalism which permits a very detailed meaning representation. However, a textual representation of the semantic network as a list of all nodes and edges together with all accompanying attribute layers becomes unreadable even for small networks. This is witnessed e.g. by the Scheme representation of the sentence "In Bayern herrscht heute schönes Wetter." (Translation: "The weather in Bavaria is fine today") shown in Figure 1.
(net ( (sort "bayern.0" fe) (etype "bayern.0" 0) (sort "name.1.1" na) (gener "name.1.1" +) (etype "name.1.1" 0) (sort "gebietsinstitution.1.1" (dis io d)) (gener "gebietsinstitution.1.1" -) (refer "gebietsinstitution.1.1" det) (varia "gebietsinstitution.1.1" con) (etype "gebietsinstitution.1.1" 0) (sort "c32" na) (gener "c32" -) (etype "c32" 0) (val "c32" "bayern.0" categ situa) (sub "c32" "name.1.1" categ situa) (sort "c31" (dis io d)) (gener "c31" -) (refer "c31" det) (varia "c31" con) (etype "c31" 0) (sub "c31" "gebietsinstitution.1.1" categ situa) (attr "c31" "c32" categ categ) (sort "herrschen.1.2" dn) (gener "herrschen.1.2" +) (etype "herrschen.1.2" 0) (sort "c40" l) (etype "c40" 0) (*in "c40" "c31" categ situa) (sort "heute.1.1" t) (etype "heute.1.1" 0) (sort "present.0" t) (etype "present.0" 0) (sort "c3" dn) (gener "c3" -) (etype "c3" 0) (subs "c3" "herrschen.1.2" categ situa) (loc "c3" "c40" situa situa) (temp "c3" "heute.1.1" restr situa) (exp "c3" "c37" categ situa) (temp "c3" "present.0" restr situa) (sort "wetter.1.1" as) (gener "wetter.1.1" +) (etype "wetter.1.1" 0) (sort "schön.1.1" nq) (etype "schön.1.1" 0) (sort "c37" as) (gener "c37" +) (card "c37" 1) (etype "c37" 0) (sub "c37" "wetter.1.1" categ situa) (prop "c37" "schön.1.1" proto situa)))
Experience from teaching MultiNet and from developing semantic networks shows that users feel most comfortable with the graphical notation of semantic networks, as opposed to working with lists of nodes and edges. Therefore, MWR rests on a graphical user interface for providing access to MultiNet knowledge bases. Editing of the knowledge base contents follows the WYSIWYG (What you see is what you get) principle, i.e. nodes and edges are directly inserted and manipulated with the mouse pointer. See Figure 2 for a GUI snapshot of the MWR system. The node "schön.1.1" (beautiful) is shown in blue color to indicate selection.
The way in which MWR displays a MultiNet knowledge base can be flexibly changed by selecting additional attributes from the MultiNet repertoire. The following example adds the sorts of the nodes to the network shown in the previous example.
All of MultiNet's elements are equipped with context sensitive popup menus. By using these menus, additional information related to the selected elements can be displayed and altered if appropriate. The final example of this section shows the popup menu for the node "gebietsinstitution.1.1". After selecting the "Layers" menu item, a dialog window appears for viewing and editing the layer information of the selected node.
In addition to the basic editing functions explained above, MWR offers further support for building and maintaining MultiNet knowledge bases, as shown in the next figure.
If the user drags a node over another node of the network, a dialog window appears asking whether both nodes should be combined into a single node. The user can either agree or demand that the nodes remain separated. In case the user confirms the identification, the "lower" node will inherit all edges of the node placed upon it and the upper node will be removed after assimilation of its edges. This method of manually identifying nodes is useful to establish the coherence of a knowledge base assembled from individual pieces of knowledge (e.g. meaning representations of individual sentences which must be assimilated into the representation of a coherent text).
The MultiNet formalism offers advanced features for characterising the meaning of nodes and edges, viz layer features, ontological sorts and knowledge types (ktypes). These descriptive means serve an important structuring purpose because they make it possible to detect errors in the manual editing of networks and react as appropriate. For example, certain relations (edges) are incompatible with certain concepts (nodes) by definition. A typical example is the violation of sortal requirements of a relation with respect to its arguments. Such criteria can be turned into automated consistency checks which are evaluated every time the user makes manual additions or changes to the knowledge base. As shown in Figure 6, MWR recognizes the inconsistency if a user tries to add a location node ("links" - german for "left") using a temporal relation (TEMP). The edge which failed the consistency check will be painted orange to signal the signature violation.
Popup menus provide access to help texts and specific information from the MultiNet documentation for all MultiNet concepts. To find out about the reason for the inconsistency in the previous example, the user can look up the description of the TEMP relation in the online documentation by opening the context menu for the TEMP edge. The German help text for TEMP shown in Figure 7 explains the meaning of the TEMP relation as well as its signature and other formal characteristics.
The editing functions discussed so far only affect single nodes or edges. However, there are also MWR tools operating on MultiNet knowledge bases. MWR distinguishes between built-in tools and external tools.
The built-in tools are implemented as Scheme programs which are integrated into the MWR system via its plug-in interface. One example of a built-in tool is the assimilation tool which automatically merges two semantic networks into a large one, thereby resolving contextual dependencies by identifying nodes which refer to the same entity. To make use of this tool, the two networks must first be loaded into two separate MWR windows (see Figure 8).
The two networks can then be combined using the assimilation tool. In order to simplify subsequent corrections, the nodes originating from the first and second net are painted differently in the resulting network.
External tools include WOCADI, the word-class controlled functional analysis for NL inputs, and the computer lexicon HaGenLex which both have been developed in the MultiNet framework. Results from these tools can be included into MWR knowledge bases, as shown in Figure 10.
For example, MWR offers an input field (marked orange in the
into which natural language sentences or phrases
can be entered and forwarded to WOCADI by clicking the
"NatLink" button which links the MWR tool to the natural language analysis
The semantic network generated by WOCADI will be
entered into the knowledge base, which makes it available
for further processing within MWR.
When manually entering new net nodes into the knowledge base, MWR looks up HaGenLex for a suitable entry, and enriches the node description with the relevant layer attributes specified in the lexicon. Furthermore MWR will indicate if there are several readings in the lexicon for the word associated with an entered node. In this case, the user is offered a list of options from which the intended reading can then be selected (see yellow area in the screenshot).
MWR serves as a development environment for other MultiNet-based applications. New applications can be constructed from existing components offered by the MWR toolkit. The system capabilities can easily be extended by adding new features to the programming library using the plug-in mechanism.
A natural language interface (NLI) to bibliographical databases which was built using the MWR libraries and then integrated as an MWR plugin, demonstrates the utility of MWR as an application development system. To implement the natural language access to a target database, the natural language query is first passed to the WOCADI parser, which translates the query into its MultiNet representation (see Figure 11 for the MultiNet analysis of the query "Show me books by Nilsson on artificial intelligence.")
At this point the transformation component comes into action. Using a rule-based approach, parts of the query network are translated into conditions on corresponding attributes in the target database. The transformation makes intensive use of the knowledge base and inference services from the MWR system.
The following part of the rule system is involved in inferring possible fillers for the "Author" attribute of the bibliographical data base:
;; ## Derive the author (define autor-aux '( ;; 2020 Ausweitung Verlag-Fokus auf seine Buecher ((FOKUS F2) :- (PROP F1 "fragefokus") (SUB F1 "verlag.1.1") (SCAR F2 F1) (SUBS F2 "haben.1.1")) ;; 2011 ff. ((AUTOR-NAME O N) :- (ATTR O NS)(SUB NS "nachname.1.1")(VAL NS N)) ;; 2013 ((AUTOR-VON A B) :- (SCAR SV B) (SUBS SV "stammen.1.1") (ORIGL SV L) (SUB L "autor.1.1") (NAME L A)) ... more rules )) (define autor-rules '( ;; 2011,2012,2015 ((SQL-AUTOR N) :- (FOKUS F) (ATTCH A F) (AUTOR-NAME A N)) ;; 2016 ((SQL-AUTOR N) :- (FOKUS F) (OBJ F X) (ATTCH A X) (AUTOR-NAME A N)) ;; 2013 ((SQL-AUTOR N) :- (FOKUS F) (PRED F "buch.1.1") (AUTOR-VON N F)) ;; 2024 ((SQL-AUTOR N) :- (FOKUS F) (SUBS F "herausgeben.1.1") (AGT F A) (AUTOR-NAME A N)) ... more rules))
The formal database query constructed by this translation process will then be passed to the target database for execution. Figure 13 displays the generated SQL query along with the result from the data base.
The MWR tool is currently subject to further development
and extension in order to fit a number of additional needs.
These activities are focused on an improvement of graphical net editing, the implementation of a graphical axiom editor, and the support for cooperative editing which will enhance the value of MWR in teaching.
The main innovation, however, will be the support for additional representional means beyond the MultiNet core formalism, viz meaning molecules which permit a flexible shift in the meaning of a concept according to its use, and new means for expressing the encapsulation of knowledge which will improve the modelling of modal embeddings and quantification.