Consideraciones finales al capítulo

display error and warning messages. These messages are not only listed in a global view, but also displayed locally on the involved property widgets of the respective constrained class (Fig. 8.2 and Listing 8.3). Furthermore, TopBraid Composer evaluates constraints to suggest possible values in the value-select-dialogues of the editor. However, errors are not completely avoided (»PREVENT VIOLATIONS«), nor are properties suggested »RECOMMEND PROPERTIES«.

Listing 8.3 also gives an example of a quickfix defined using spin:fix. Fig. 8.3 shows how this quickfix is presented in TopBraid Composer.

Figure 8.3: Effectiveness constraint – Quickfix: This figure shows how the constraint from Listing 8.3 is interpreted in the TopBraid-Composer-based prototype (see Sect. 8.3). A quickfix is offered to delete the statement that violates the effectiveness constraint.

8.2

Support of Explicit and Composable Visual Mappings

A second important feature of the OGVIC approach, are the aspects »explicit« and »composable« visual mappings, corresponding to research question Q-1. Composition is not an optional feature but required for realising most of the sketches from our case studies. Speaking of composition, we first have to clarify what is subject to composition. This includes the

• composition of graphic objects, • composition of graphic relations,

• composition of mappings, and eventually, the

• composition of data as a pre-step (not in focus here).

When introducing the AVM in Chapter 6, we already dealt with the composition of graphic objects (Sect. 6.5) and graphic relations (Sect. 6.6). We introduced how graphic objects as well as graphic relations and the emerging structures can be composed based on the syntactic graphic roles that graphic objects can play. Visual mappings may be composed as well. The prerequisite for reusing and composing mappings is that we make the visual mapping from data relations to graphic relations explicit. We provided the RVL language for this purpose, which defines the possible mappings. With the graphic module of the VISO ontology, we introduced a formal description for the graphic relations to be used within these mappings. Also the composition of visual mappings was already briefly mentioned in the context of the RVL language (Sect. 7.10): We showed how composability is realised by the submapping mechanism of RVL, in combination

CHAPTER 8. THE OGVIC APPROACH

with the concept of the role-based AVM. In the following section, we discuss in more detail, which composition cases may occur, beyond the basic distinction we already described in the chapter on RVL – Simultaneous Composition and Context Composition.

8.2.1

Mapping Composition Cases

The following figures illustrate the identified cases of visual mapping compositions. We omit the concrete source data relations and focus on the composed graphic relations instead.

Simultaneous composition. All mappings are applied to the graphic objects independently of other mappings, i. e., removing one mapping does not influence the other mappings. Si- multaneous composition steps are confluent, that means they can be performed in any order. Each mapping works on the same set of graphic objects. Fig. 8.4 shows an example of the simultaneous composition of multiple mappings. We use the term »simultaneous« referring to the »simultaneous combination of visual syntactic structures« described by Engelhardt [vE02]. Crossing of graphic attributes. A special case of a simultaneous composition is the crossing of graphic attributes. The same graphic attribute may be used multiple times if its value space can be split into multiple orthogonal dimensions. This works – and is frequently done – for position in physical space, but also for attributes like colour, which equally spans up a multidimensional colour value space2_.

Y X Y X Simult aneous Composi �on Cr oss ing X-Posi�on, Y-Posi�on (con�nuous values) X-Posi�on, Y-Posi�on (discrete values) Line-Up

(ordered variant) Separa�on by a Separator(ordered variant)

Hue, Lightness (HSL color space)

Crossing of other graphic relations. Since graphic-object-to-object-relations consume graphic attributes like spatial position, crossing can also be applied to relations such as separation by a separator or line-up, as long as each mapping is constrained to use only one of the dimensions available. The last subfigure above shows an example of this: Two different

2 _{For spatial dimensions, this works only if the graphic attribute comprises only one dimension, since already}

the crossing of two by two dimensions would result in four spatial dimensions, which is more than the three spatial dimensions that can be perceived by the human eye.

Figure 8.4: Example for a set of visual mappings that are simultaneously applied to the whole set of »raw« graphic objects. The order in which they are applied to the graphic objects does not affect the final result, since simultaneous composition is confluent. Because line-up is the only graphic relation that internally uses position, no conflicts occur. Depending on the data, this may be different if we compose with containment (cf. Sect. 5.7.3).

CHAPTER 8. THE OGVIC APPROACH

semantic relations are both mapped to the same graphic relation separation by a separator . This works, because one is mapped to horizontal separators and the other to vertical separators.

Context composition. In a context composition, the second mapping applies only to a subset of the graphic objects defined by the first mapping, the context. In the next subsection, we discuss multiple options to define a context. Two mappings taking part in a context composition cannot be changed independently of one another, because one mapping needs to work on graphic objects that depend on the other mapping. Sometimes, the objects to which a context composition is applied, may even have been newly created by the other mapping. In the example below, the second mapping is used in the context of the first mapping, which is determined by a graphic role connector . This graphic role is assigned during the first mapping, so the scope of the second mapping is limited by the first one. Still, the second mapping is self-contained and could be reused in other contexts.

Mapping A (linking) Mapping B (color) Composi�on of A and B

Simultaneous c. Context c. (role: connector)

8.2.2

Selecting a Context

Describing a context composition requires the selection of a graphic context as well as a data context:

Selecting a graphic context. In order to create a graphic context, we need to reference parts of a graphic. In RVL, the rvl:submapping_onRole property of submappings allows for selecting only those graphic objects that currently play a specific graphic role.

While not yet being part of the RVL specification, another option is to select the graphic objects indirectly via the resources they represent. Filters, which may even select a single entity by ID, could be applied to further restrict the set of graphic objects. Further contexts based on the structure of the data or the structure of the graphic are conceivable. Context could, for instance, be given through structural references by

• a certain level of a hierarchy (DAG required), • each level of a hierarchy (DAG required),

• leaf nodes of a hierarchy per branch (DAG required),

• second degree neighbours (this would be dependent on the »position« of a user, e. g., in a node-link diagram),

• nodes with fan-out > 20.

Finally, further contexts, such as referencing specific graphic objects by their graphic values, are possible. For example, we could apply some mapping to each graphic object that was coloured »red« by a previous mapping. A similar case is to pick graphic objects by their ID. Both cases should be rare.

8.2. SUPPORT OF EXPLICIT AND COMPOSABLE VISUAL MAPPINGS

Selecting a data context. To determine the data to be processed by the composed mapping, we also need a data context. In RVL, we can refer to the statement processed by the »supermap- ping«. With the rvl:submapping_onTriplePart property, we then define whether subject, predicate or object of this statement should form the new data context for the submapping (cf. Sect. 7.10).

8.2.3

Using the Same Graphic Relation Multiple Times

Valuable graphic relations such as linking , but also separation by a separator or proportional repetition can be mapped more than once, if their instances can be clearly distinguished. This can be easily achieved if the respective graphic relation involves creating additional graphic objects (such as a separator , a connector , a label or proportionally repeated objects). In this case, a second mapping (e. g., to colour) can be applied on the newly created objects (by means of a context composition) to resolve the ambiguity. In the figure below we give three examples of using the same graphic relation for two different semantic relations: for linking, we colour the connectors; for proportional repetition, we colour the repeated objects; for separation by a separator, we colour the separators (here we use grey and green). A similar example from our case study sketches is RO-6 (Fig. 3.4a), where both ro:refines and ro:isInConflictWith are mapped to linking. Here, the two completely unrelated semantic relations are distinguished by the shape of the connectors. A special case of this principle is the use of colour/shape to distinguish subproperties in example CIT-1 (Fig. 3.4c) and CIT-5 (Fig. 3.3c).

Linking Separa�on by a Separator

(ordered variant) Propor�onal Repe��on

With respect to the scalability and complexity of the composition approach, we have to keep in mind that while calculations on the composability of various graphic relations may quickly become complex and expensive, a single graphic will, for the sake of human perception, only make use of a limited number of relations. If it is necessary to encode more relations, multiple views will probably be used, which should also break down the necessary calculations into reasonable fractions.

CHAPTER 8. THE OGVIC APPROACH

Having discussed the defining features of the OGVIC approach, in the following, we present three prototypes that have been developed to implement aspects of our approach and discuss their differences and shortages. For each prototype (P1–P3), we give an architectural overview. These figures refer back to the schematic overview of an architecture for the OGVIC approach that we presented in the introduction (Fig. 8.1).