Los Actores

SPIN and VISO/facts

We already introduced simple SPIN constraints in Sect. 7.11.1 as a means to define a schema for RVL. In the absence of a standard to define contraints and hints for guidance, we also use SPIN

CHAPTER 8. THE OGVIC APPROACH

to formulate the necessary (additional) constraints for guidance. In the following, we apply the classification of constraints and guidance levels to the OGVIC approach and give examples of constraints we implemented with SPIN and interpreted with our prototypes. SPIN constraints are attached to classes of the RVL language using the property spin:constraint. The constraint itself is a SPARQL query in SPIN notation (stored as triples). In most examples, to maintain readability, we give the query as plain text, though.

Structural Depth

With respect to the structural depth of the constraints, we require »SINGLE PROPERTY« (e. g., to constrain a datatype property to xsd:int) and »INTRA-OBJECT« constraints. An example for an »INTRA-OBJECT« constraint is given in Listing 8.1, where two properties of the same object are used in one constraint – rvl:lowerBound and rvl:upperBound – to express that rvl:lowerBound must always have a value smaller than rvl:upperBound.

1 rvl:Interval spin:constraint

[ a sp:Ask ;

rdfs:comment "Upper bound may not be less than lower bound." ; sp:where (

6

# ... SPARQL-query represented as RDF statements with SPIN, # here shown as plain SPARQL ...

?this rvl:lowerBoundIncl ?lb .

11 ?this rvl:upperBoundIncl ?ub . FILTER (?ub < ?lb) .

) ] .

Listing 8.1: Intra-object constraint realised in SPIN. The constraint detects an error, if the upper bound of an rvl:Interval is less than the lower bound (corresponds to Fig. 8.6 in Sect. 8.3).

So far we could not identify cases where »INTER-OBJECT« references are required. Inference and Constraint Evaluation

Constraints defined with SPIN can be checked with the open-source SPIN API (cf. Sect. 2.2.7 for background on SPIN-related software) and are internally evaluated using a SPARQL engine. Still, sometimes the preceding run of an RDFS reasoner is required. This may be necessary to extend constraints to subclasses and consider subproperty hierarchies. For example, using standard reasoning avoids the necessity to put a constraint for each subclass of rvl:PropertyMapping, since constraints defined for the class are automatically applied to subclasses. The benefits of combining (OWL and RDFS) reasoning with constraint checking – as it possible with SPIN – have been recently elaborated by Bosch et al. [BANE15].

Usage of External Knowledge

Referencing an »EXTERNAL TYPE SYSTEM« is the common case for the set of constraints that we defined for the OGVIC approach. For example, types of graphic relations defined in VISO/graphic are referenced in RVL constraints (cf. Listing 8.1). However, we can split the overall set of constraints into two subsets by the criterion »EXTERNAL FACTS«. We stored the two subsets separately as RVL-Constraints and RVL-VISO-Constraints.

The module RVL-Constraints provides all constraints that serve to describe valid RVL mappings, but does not need to evaluate facts from external knowledge bases. These constraints can been seen as part of a formal specification of the RVL language that we refer to as RVL schema in Sect. 7.11. Examples of such constraints are the constraint on rvl:ValueMapping given in Sect. 7.11 (last listing) and Listing 8.1.

8.1. ONTOLOGY-DRIVEN, GUIDED EDITING OF VISUAL MAPPINGS

The module RVL-VISO-Constraints provides all constraints that reference external facts from a knowledge base. These constraints go beyond ensuring valid RVL mappings but can be used for generating warnings and recommendations concerning the quality of the graphic. For example, we defined constraints on the expressiveness and effectiveness of visual mappings with respect to the scale of measurement of the data. An example of an expressiveness constraint is given in Listing 8.2. An example of an effectiveness constraint is given in Listing 8.3. The knowledge base utilised by RVL-VISO-Constraints has to conform to the VISO/facts module, i. e., it has to offer knowledge about graphics formulated with the VISO/facts vocabulary. As introduced in Sect. 5.7, we offer the module VISO/facts/empiric as a basic instance of such a knowledge base. 1 ASK WHERE { ?this rvl:sourceProperty ?sp . ?this rvl:targetGraphicRelation ?tgr . { ?sp rdfs:subPropertyOf viso-data:has_nominal_value . 6 ?tgr viso-facts:not_expresses viso-data:Nominal_Data . } UNION { ?sp rdfs:subPropertyOf viso-data:has_ordinal_value . ?tgr viso-facts:not_expresses viso-data:Ordinal_Data . } UNION { 11 ?sp rdfs:subPropertyOf viso-data:has_quantitative_value . ?tgr viso-facts:not_expresses viso-data:Quantitative_Data . } }

Listing 8.2: Example of how an expressiveness constraint can be realised in SPIN (showing only the encapsulated SPARQL query as plain text).

1 CONSTRUCT { _:b0 a spin:ConstraintViolation . _:b0 spin:violationRoot ?this . _:b0 spin:violationPath rvl:targetAttribute . _:b0 rdfs:label ?cvLabel . 6 _:b0 spin:violationLevel spin:Warning . _:b0 spin:fix _:b1 . _:b1 a :DeleteTriple . _:b1 rdf:subject ?this . _:b1 rdf:predicate rvl:targetAttribute . 11 _:b1 rdf:object ?tga . } WHERE {

?this rvl:targetAttribute ?tga . {

16 SELECT COUNT(?tga) AS ?altCount SAMPLE(?sp) AS ?sp1 SAMPLE(?som) AS ?som1

WHERE {

?this rvl:sourceProperty ?sp . ?this rvl:targetAttribute ?tga . {

21 ?sp rdfs:subPropertyOf viso-data:has_nominal_value .

?tga viso-facts:has_effectiveness_ranking_for_nominal_data ?rankValue .

?anyOtherGr viso-facts:has_effectiveness_ranking_for_nominal_data ?otherRankValue . BIND ("nominal" AS ?som)

} UNION {

26 ?sp rdfs:subPropertyOf viso-data:has_ordinal_value .

?tga viso-facts:has_effectiveness_ranking_for_ordinal_data ?rankValue .

?anyOtherGr viso-facts:has_effectiveness_ranking_for_ordinal_data ?otherRankValue . BIND ("ordinal" AS ?som)

} UNION {

31 ?sp rdfs:subPropertyOf viso-data:has_quantitative_value .

?tga viso-facts:has_effectiveness_ranking_for_quantitative_data ?rankValue . ?anyOtherGr viso-facts:has_effect.._ranking_for_quantitative_data ?otherRankValue . BIND ("quantitative" AS ?som)

}

36 FILTER (?tga != ?anyOtherGr)

CHAPTER 8. THE OGVIC APPROACH

NOT EXISTS {

?anyOtherMapping rvl:targetGraphicRelation ?anyOtherGr . FILTER (?this != ?anyOtherMapping)

41 }

}

GROUP BY ?tga }

FILTER (?altCount > 0)

46 BIND (fn:concat("There are ", ?altCount, " more effective visual means for visualizing the selected ", ?som1," source property ’", afn:localname(?sp1), "’ that are not yet used in other mappings.") AS ?cvLabel)

}

Listing 8.3: Example of how an effectiveness constraint can be realised in SPIN (showing only the encapsulated SPARQL query as plain text). The constraint definition includes a quickfix for deleting ineffective mappings using spin:fix (Line 7–11). Furthermore, the severity level – spin:violationLevel–

is set to spin:Warning (Line 6). rvl-cs:DeleteTriple is a spin:UpdateTemplate for deleting arbitrary

statements, which we instantiate here for deleting ineffective rvl:targetGraphicRelation-statements. Possible improvements include extending the quickfix to suggest the most effective visual means as well as considering the fact that visual means may be used more than once if we use submappings. See Fig. 8.2 and 8.3 for an example of how this constraint is interpreted in prototype P1.

Figure 8.2: Effectiveness constraint – Warning: This figure shows how the constraint from Listing 8.3 is interpreted in the TopBraid-Composer-based prototype (see Sect. 8.3). A warning is issued for this property mapping, since viso-graphic:color_hsl_lightness was used for visualising the quantitative values of ex:population, which is not the optimal choice according to the effectiveness ranking that we formalised in the VISO module VISO/facts/empiric.

Supported Levels of Severity

Severity levels can be added to a SPIN constraint or SPIN rule by adding an extra triple using spin:violationLevel. For example, we assign the level spin:Warning if the effectiveness of a mapping is non-optimal and spin:Error if the expressiveness is not given.

Supported Levels of Guidance and Quickfixes

With respect to the levels of guidance used in the OGVIC approach, the levels »DISCOURAGE VALUES«, »RECOMMEND VALUES«, »DISCOURAGE PROPERTIES« and »DERIVE QUICKFIXES« have been employed. Our first (Sect. 8.3) and second protototype (Sect. 8.4) can