4.3 SiAM Meta Model
4.3.3 EMF API Extensions
Based on the Ecore meta-model we implemented an API that, among other function- alities, supports commonly used algorithms on typed feature structures that are very valuable for knowledge processing in multimodal dialogue systems. These algorithms
5http://www.eclipse.org/eclipse/
6
http://www.w3.org/TR/speech-grammar/
4.3 SiAM Meta Model 89
are adopted from algorithms in the eTFS API as described in Pfleger (2007) and imple- mented for EMF models.
Unification
The API contains the static method Unification.unify(EObject a, EObject b) where EObject is the upper class for each Ecore model instance that - as discussed above - can be considered a typed feature structure. This commutative operation takes two typed features structures and returns a new typed feature structure that merges the informa- tion of both TFSs if they are compatible. Otherwise the result is null. Formally, Pfleger (2007) defines the unification as follows:
Definition 7 (Unification)
In an inheritance hierarchy of a typed feature structure the unification of two feature structures is their greatest lower bound (GLB). The GLB is the most specific type that subsumes the types of both TFSs.
A type subsumes another type if it is a superclass of it, e.g., the type Person subsumes the type Man. Figure 4.6 provides an example for a successful unification operation on two compatible typed feature structures.
A unification fails either if the two types of the TFSs do not subsume each other or if the values of a specific slot do not match. Figure 4.7 gives examples for both cases.
unify( Movie
name: Iron Man 3 genre: Action length: 130 , Movie
name: Iron Man 3 director:
"
Person
name: Shane Black # )= Movie
name: Iron Man 3 director:
"
Person
name: Shane Black # genre: Action length: 130
unify( Movie
name: Iron Man 3 genre: Action length: 130 , " Person
name: Shane Black # ) = null unify( Movie
name: Iron Man 3 genre: Action , Movie
name: The First Avenger genre: Action
) = null
Figure 4.7 – Examples of failed unification. In the first example the types are not compatible. In the second one the TFSs have a conflicting value (name).
Strict Unification
The strict unification is a special implementation of the unification operation. The significant difference is the handling of multi-slot content. The standard unification approach does not consider the order of the entries in a multi-slot. Thus, two typed feature structures also unify if the content entities of a mulit-slot match but appear in a different order. In some situations, the order of multi-slot entries plays a relevant semantic role. In this case two typed feature structures should only unify if the order also matches. The static method StrictUnification.unify(EObject a, EObject b) provides an algorithm for this.
Overlay
The overlay operation is a non-commutative operation on typed feature structures that was introduced by Alexandersson and Becker (Alexandersson and Becker, 2001, 2003; Alexandersson et al., 2006; Alexandersson and Becker, 2007). The basis for this operation is the unification on two TFS instances where one is called covering (co) and the other background (bg). In contrast to standard unification, the overlay operation never fails. If possible, the content from the covering is extended with additional content from the background. In the case of a conflict, at least the content of the covering is returned with the risk that some of the background information is possibly lost. The overlay operation is composed of two basic steps:
Assimilation: A direct subsumption relation is necessary between the covering and background object in order to merge them. In the case of a type-clash the background must be refined to the most specific supertype of both objects.
Overlay The overlay of content is similar to the unification operation with the difference that in the case of conflicts, the information from the background is overwritten by the content of the covering so that an overlay is always possible.
4.3 SiAM Meta Model 91
Figure 4.8 depicts an example of an overlay operation. In this example the movie name causes a conflict so that the name of the background entry is overwritten with the name of the covering. The other content is merged as known from standard unification. Besides the effect that overlay never fails, the key-feature is a scoring mechanism for the resulting TFS that shows how well the two TFSs fit together. Two different types of score mechanism exist: one that reflects the structural consistency (Pfleger et al., 2002) and one that estimates the information distance between the two arguments (Alexander- sson et al., 2004). This score, especially, plays a relevant role in discourse resolution with ambiguous content since it reflects the quality of the merge result. The static method Overlay.overlay(EObject co, EObject bg) provides an algorithm for the overlay op- eration.
unif y(co, bg) = unif y(
Movie
name: Iron Man 3 length: 130 , Movie
name: The First Avenger genre: Action ) = Movie
name: Iron Man 3 genre: Action length: 130
Figure 4.8 – Example of an overlay operation
Restricted Unification
The restricted unification is a special case of unification that was introduced by Pfleger (2007) for pattern matching. In contrast to the standard unification it is a non-commutative operation. It is implemented in the static method RestrictedUnification.runify( EObject a, EObject b). The main difference to standard unification is that the first argument defines a pattern that at least must be comprised by the second argument. Thus, our unification example would fail with restricted unification (see Figure 4.9). Although the algorithm for restricted unification played a relevant role in the predecessor dialogue platform ODP, it is supported only for the sake of completeness. Instead, SiAM- dp introduces the more powerful PPattern model (see 4.4) for pattern matching.
unify( Movie
name: Iron Man 3 genre: Action length: 130 , Movie
name: Iron Man 3 director:
"
Person
name: Shane Black # ) = null
Clone
Because the components of the dialogue platform often work independently from each other it is necessary to make deep copies of instances. Thus, it is possible to change the content of a copied instance without affecting the original one. With the method EcoreUtil.copy( EObject eObject), the EMF framework already provides such a functionality, unfortunately with an unwanted effect:
EMF provides two types of references: containment and non-containment. A contain- ment reference refers to an object that belongs to the object which defines the reference, a non-containment reference refers to an object that is content of another element or is a root element. In other words, you can say a non-containment reference is a plain “A knows B” relation, a containment reference is a “A has B” relation.
The EMF copy-method actually creates copies of objects that are the content of con- tainment references and even considers non-containment references and redirects these references to the copied objects (compare Figure 4.10). The figure shows that Entity 0 and the objects in its containment references (solid lines) Entity 1 and Entity 2 are copied. The non-containment reference (dashed line) from Entity 3 to Entity 2 is redi- rected from Entity 6 to the newly created Entity 5. Nevertheless, if a non-containment reference refers to an object not contained in the actual instance, no copy is created and the reference is still directed to the original entity (Entity 1 ).
Since this behaviour is unwanted, we provide the method EmfUtils.clone( EObject eObject) with a full deep-copy functionality that also copies the external content of non-containment references (Entity 10 ).
Figure 4.10 – Comparison of the results from the copy and clone method. The red marked entities are newly created during the copy or clone process.