RDFS/OWL Visualization Language (RVL)

jan.polowinski at tu-dresden.de
Imported Ontologies:
Download / Source view:
Ontology source code
Download Fork me on GitHub

Table of Content

  1. Introduction
  2. Classes
  3. Object Properties
  4. Data Properties
  5. Namespace Declarations


RVL is a declarative language that allows to specify a mapping from RDF(S)/OWL concepts to visual means that are defined in the Visualisation Ontology (VISO). The syntax is based on RDFS, while the semantics are given by means of SPIN rules.

RVL was developed in the SemVis project by Jan Polowinski. More on RVL can be found in the Wiki.

Overview of Mapping Classes in RVL

Overview of Datatypes used in RVL

MissingSourceValueHandlingType: Hide, Ignore, Missing (default), Neutral, Average

MissingValueMappingHandlingType: Calculate (default), Hide, Neutral, Ignore, No mapping, Average

NeutralValueHandlingType: Average, Style

OutOfBoundHandlingType: Cut (default), Clamp

ScaleTransformationType: Linear (default), Logarithmic


FSL selectorc


A string representing a FSL path expression

FSL is the selector language used in Fresnel: http://www.w3.org/2005/04/fresnel-info/fsl/

has super-classes

Graphic attribute intervalc


An interval of graphic values, either defined by literals or ordered resources of type Visual_Attribute.

has super-classes

Identity mappingc


Passes source values through to the target graphic relation without changing the datatype or value. The type of the values in the domain is equal to the type of the values in the co-domain.


rdfs:label is passed to labeling; RGB-values are passed trough to color.

Also referred to as "Passthrough Mapping" in some tools.

Except passing strings to labels, also a few other values in the source data may be passed through, e.g. RGB-values, sizes in px, positions in px (all other need scaling). These values do not need to be mapped, but can directly be used as they are. However, it should be possible to perform string-operations in order to do small changes if the datatypes don't match exactly. Setting "image/uri" as value in fresnel is similar, however it also instructs how to present. It could be argued that in rare cases relations in the data (when the source data is already about graphic relations) may need to be passed through to GOTORs as well which is not possible at the moment.

RVL may be extended to support identity mappings also on the level of value mappings, in order to allow for splitting the source values and handling each part with differernt settings (e.g. partly use a calculated mapping, or add additional text for some parts). This has been neglected for now for reasons of overall complexity in favor of this simple PM class. To achieve the above mentioned behavior, complex filters on the PM may be used for now.

has super-classes



An interval of values of a simple datatype or ordered objects. The interval can be unbounded (infinite) to one direction by not specifying upper or lower bound. An interval may also require a label, when a legend shall be created (use rdfs:label for this).

has super-classes
  • owl:Thing
has sub-classes
Graphic attribute intervalc, Source value intervalc



The abstract super-class of all mappings. Both PropertyMapping and ValueMapping are sub-classes of Mapping and inherit the property includeInLegend. This way, it can consistantly be defined, whether they should appear in a legend.

add a flag active/inactive

has super-classes
  • owl:Thing
has sub-classes
Property Mappingc, Resource mappingc, Value mappingc

Out of bound handling typec


An option of how to handle the values that are out of bounds of a defined interval.

has super-classes

Property Mappingc


A Property mapping (PM) defines the mapping from one source property (i.e., a relation) to one target graphic relation. Depending on the type of graphic relation different sub-types of PM have to be used. For graphic-object-to-object relations PropertyToGraphicObjToObjRelationMapping and for graphic attributes PropertyToGraphicAttributeMapping. The latter allows for various settings on the mapping of different values.

When are PM applied?

Property mappings apply, whenever a property instance (i.e. a statement using the property) exists, no matter what is the object or subject. When constraints need to be made on the application of the mapping, filters have to be used on subject and/or object.

The following figure illustrates a PM that is independent of the source values. Only the existence of some value for "geo:coordinates" leads to the creation of a world-shaped label:

To which Graphic Object is a PM applied?

Settings defined by a mapping will by default be applied to the Graphic object (GO) representing the subject of the mapped statement. This means changes to graphic attributes are applied to the subject's GO and the subject's GO is chosen as the starting point for graphic object-to-object relations defined in the mapping. When new graphic objects are implicitly created by a mapping (e.g. as a label) they, too, will be assigned to the subject's GO. When this default behavior is not desired, two options are at hand:

  1. Map the inverse property instead (e.g., "updatedBy" instead of "updates")
  2. Use a filter-expression to invert the direction of the statement (e.g., "!updates" instead of updates) . This will select objects instead of the subjects.
  3. (only usable within sub-mappings:) Use the rvl:onRole parameter to define the graphic object to which the mapping is to be applied.

How to map multiple values for the same property?

This problem frequently occurs, for example, when mapping rdf:type, since multiple inheritance is allowed in RDFS. When multiple values for a source property exist and only one value is possible, the more specific value shall be processed. For PropertyToGraphicAttributeMappings, in case of two equally specific values, a warning shall be issued and the first value that is loaded shall be used. For PropertyToGraphicObjToObjRelationMappings, a warning shall be issued and the graphic object representing the subject shall be duplicated.


Although most frequently OWL object properties will be mapped to graphic object-to-object relations while OWL datatype properties will be mapped to graphic attributes, other constellations are possible. Also, some relations will only be modelled as rdf:Property.

When a target graphic relation is used in multiple mappings, a warning should be issued, since ambiguities become possible.


As described, each property mapping is an "existence mapping", so no extra class is needed for this. A PM without filters does exactly the job, when exactly one target vaue is defined (this is inline with semantics of other settings). However, we could improve performance by explicitly stating, that the context (e.g. the value of the object) will not influence the mapping process. Any existence of the property will lead to the mapping described by the property mapping and no value mappings have to be considered (consider that value mappings are only special filters on the object side!!). We first considered to have a new class - Constant mapping - for this kind of property mapping.


rvl:newGraphicObject could be used as a targetValue, when a new additional GO needs to be created. Whether this GO can also be a complex CGO having an internal structure (NV/PPR) and/or can have visual attributes already set from the beginning, or whether it should be the instance of a VR needs to be examined.


Besides the objectFilter and the subjectFilter, which are implemented, also an additional predicateFilter could be allowed (resp. we could allow a complex (SPARQL) selector as the range for sourceProperty). When we should introduce a predicateFilter, it has to be clarified whether it may be used in addition to the selection of a sourceProperty (only refining it) or instead of this setting. Since the defininition of property-paths and other complex relations may be achieved on the data side by introducing temporary properties and/or inference (e.g. for handling subproperties), no further filters are allowed for the moment.


Instead of separately describing the sourceProperty and various filters, also a complex statement-filter (e.g. a SPARQL selector) could be used to simply select all triples to be mapped. This, however, does not meet our goal of a stepwise and explicit definition of mappings. For example, this would cause problems when it comes to generating legends, since the sourceProperty is not explicitly defined. Having separate filters for subject, object and (possibly, for refinement) predicate, reduces the complexity of the single filter definitions and can more easily be handled.

FILTERS vs. sourceValue... properties:

While both objectFilter and properties such as sourceValue constrain the set of statements by the resources used as object in these statements, objectFilter is meant to filter via a complex (e.g. SPARQL) selector, while sourceValue defines single valid values. The properties sourceValueSet and sourceValueOrderedSet allow for easily selecting specific resources allowed as objects. SourceValueOrderedSet as well as the properties sourceValueUpper/LowerBound allow for defining ranges and existing sets of values in a more consise way.

sourceValue... properties and object/subject:

All properties starting with sourceValue always refer to the object of the source statement that is to be mapped, not the subjects - just as valuemappings do. The object may be a literal or a complex resource on its own.


In future versions of RVL, also multiple values could be mapped and property could be introduced that allows for defining how to handle multiple values. Options could include: Use colored stripes, when mapping to multiple colors, mix colors (blue+yellow=green) or somehow calculate in-between values. (TODO: This is more a problem of P2GAMs)

has super-classes
has sub-classes
Identity mappingc, No-Property-Value-Mappingc, Property-to-Graphic-Attribute Mappingc, Property-to-Graphic-Object-to-Object-Relation Mappingc

Property-to-Graphic-Attribute Mappingc


A Property-to-Graphic-Attribute Mapping (P2GAM) draws a general connection between a (domain) property and the graphic attribute. The interesting part remains the mapping of the values, which is left to Value mappings (VM). The default implicit VM, which is assumed, when no other VMs are explicitly defined, maps all source values to all target values. For details, refer to the description of VM.

has super-classes

Property-to-Graphic-Object-to-Object-Relation Mappingc


A Property-to-Graphic-Object-to-Object-Relation (P2GOTOR) mapping maps (domain) properties to relative graphic object-to-object relations.

Without this extra class some attributes of mappings would have to be set in dependency on the type of the target graphic relation.

In contrast to PropertyToGraphicAttribute mappings, which make the language construct of Value Mappings a necessity, for P2GOTOR mappings it would have been sufficient to have source filters on the property mapping level.

has super-classes

Remove transitive hullc


Simplifies the RDF graph by removing all edges that represent relations that are implicitly given, because the relation is transitive.


has super-classes

Resource mappingc


A convenience mapping to substitute property mappings that map a resources ID (represented by the property "rdf:ID") to a target graphic attribute plus an attached value mapping from a specific source value to a fixed graphic attribute value, which is a frequently occuring mapping case. It can be used in combination with inheritedBy and passedTo in order to easily transfer the same value to all instances or subclasses of some specific resource.

While the sourceProperty is implicitly clear (the ID), it is necessary to state the target graphic attribute when only a value of a simple data type is given as a target value. For example take the value "10.5" - is it a height or a width? For the target value viso-graphic:red it is clear that it is a named color value, therefore, the target graphic attribute viso-graphic:color_named can be omitted.

Systems interpreting resource mappings may decide whether to internally transform resource mappings to a property mapping and one (or more) value mappings, or directly process them.

NOTE: Regarding the neccasity of explicity specifying a target graphic attribute: Alternatively, as target values only instances of visual attribute, i.e., named attribute values may be allowed. Or, if also literals should be usable, such as "10.5"^^viso-graphic:heightValue, these datatypes will have to be introduced first! Standard unit ontologies may have to be considered for reuse in this context!

TEMP NOTE: Class mappings (the predecessor of this) are internally processed to PropertyMappings at the moment (in the prototype - rvl2rvl)

TODO: Also a cascading mechanism is needed to determine the winning mapping, when multiple mappings are applicable to a resource.

has super-classes



Abstract super-class of all simplifications. A simplification is a transformation on the source RDF graph with the intention to gain a simpler model by removing redundant information. It is not part of the visual mapping, but a pre-step for this.

has super-classes
  • owl:Thing
has sub-classes
Remove transitive hullc, Unify with inverse and pick onec

Source value intervalc


The setting of bounds for the source values is optional. The properties lowerBound and upperBound define the span of source values to be mapped. Other values, outside this span, are either cut or set to the bounding values, depending on the value for the property sourceValuesOutOfBounds.

If no bounds are defined, the span of source values should be calculated from all available source values.

The span of source values can also be set larger than the span implicitly created by the existing values. This can be used to enlarge the domain of the mapping, e.g. for enforcing a domain to important timespans such as 01.01.1900 - 31.12.2000.

has super-classes

SPARQL selectorc


A string representing a SPARQL query

has super-classes

Sub-mapping relationc


Creates an n-ary relation between a base mapping and a sub-mapping, which is applied on the graphic object playing the role defined by rvl:subMapping-onRole. This allows for reusing existing mappings as sub-mappings. Additionally to the role, also the resource on which the sub-mapping should operate may be defined. By default this is the object of the source-data-triple mapped by the "super-mapping", but it may be changed to the predicate or subject by using rvl:subMapping-onTriplePart.

Using sub-mappings has the following effects/benefits as opposed to defining a new standalone mapping (simultaneous composition):

  • Sub-mappings refine the graphic elements the super-mapping has worked on (each role can be referenced)
  • Sub-mappings always work on the resources already selected by the super-mapping - complex filter settings do not need to be defined once again.
  • Sub-mappings may create new graphic objects


Example of a sub-mapping, determining the color of the connector that has been created by a mapping to Linking.

SUBGRAPHICS: Submappings may also be attached to (constant/static) subgraphics. Here it has to be clarified how the source data can be referenced easily.

TODO: REUSE: How well works reusing mappings with submappings?

TODO PROTOTYPE: Not used in most examples at the moment. Instead hasSubMapping is simply used directly between mappings. However, this simplification, does not allow to reuse mappings in different situations, since onRole is fix and cannot be changed for each use of the mapping in different contexts. The same problem as with onRole applies to selecting the triple part to work on rdf:subject/predicate/object.

has super-classes
  • owl:Thing

Unify with inverse and pick onec


Unifies a property and its inverse for the purpose of graphic representation. This is achieved by replacing one of them with the preferred property.


has super-classes

Value mappingc


Value mappings (VM) define which source values should be mapped to which target values and optionally provide further information on how to do this mapping of values exactly. That way they are a supplement to Property-to-Graphic-Attribute Mappings (P2GAM), which only draw the general connection between the source relation and the target graphic relation. If no VM is defined for a P2GAM, a single default VM with default settings is used, which basically maps all the available source values to all the available target values.

  • A special case of a VM is a value mapping which requires no calculation and maps exactly one source value to exactly one target value.
  • VMs can be seen as a shorthand for simple object filters on the object (value) side of a statement.
  • Each value mapping may have its own settings like discreteStepCount.


Selecting Intervals (Ranges)

VMs may be constrained by creating an Interval of values defining a minimum and/or maximum value using sourceValueInterval. The same can be done for graphic attributes using targetValueInterval.

Selecting Ordered Sets, Lists and Unordered Sets

(Existing) ordered sets of ordered source values can be selected using sourceValueOrderedSet.
(Existing) unordered sets can be selected using sourceValueSet or simply by using sourceValue multiple times. All selected values will build an ad-hoc set.
For the target graphic attribute values the analogeous properties targetValueOrderedSet, targetValueSet, targetValueList and targetValueCycle can be used. Refer to the description of these properties on details on how they differ from each other.

Exclude single source or target values from the mapping

When some specific value shall not be handled by the VM, rather than defining a new set of all desired values, we can reuse an existing set or interval and exclude the value in question using excludeSourceValue (resp. excludeTargetValue).

Complex Source Value Selectors

More complex source value selectors can be defined using sourceFilter which allows for SPARQL and FSL expressions.

Valid Combinations of Source/Target Selectors in a Single VM

In a single value mapping, most source selectors are to be used alternatively - only those selecting an (unordered) set of values can be used in combination and also multiple times. The union of all values selected by sourceValueSet and sourceValue will be used as source values. Further potential exceptions to this have not been specified by now for reasons of simplicity. (This applies equally to target selectors).

Additional Mapping Parameters

Value mappings can store additional information on the desired mapping process. For example the property discretize and discreteStepCount define if and how a discretization of values should be done. Via scaleTransformation, the scaling can be changed from linear scale transformation (default) to a logarithmic one, for example.

Giving Hints on the Scale of Measurement

By default, VMs are performed based on the scale of measurement that can be derived from the source and target properties as well as from the available values. An ordinal or quantitative scale of measurement may be explicitly stated for the source values by using one of the properties orderSourceValuesBy resp. quantifySourceValuesBy. Analogeos properties exist to order/quantify the target values.

Calculation of Value Mappings - Schematic Overview of Possible Mapping Cases

The figure below gives an overview on the possible combinations between the Scale of measurement (SoM) of source and target values as well as on additional settings that can influence the mapping process. Note that although we allow for selecting continuous source ranges in VM, the RDF resources will always have concrete discrete values!

Calculation of Value Mappings - Semantics as Pseudocode

Constant values

VM will map any source value to a fixed target value, when no source values are defined (this implicitly means all values are selected) and only 1 target graphic attribute is defined. This can be used to show that there exists a value for this property at all, e.g. by using a specific color or adding some specific label when the property ist set.

Overlapping of Value Mappings

When a source value is mapped by multiple VMs, the priority of the VMs is used to determine the mapping to be applied and a warning is issued. When two value mappings have the same priority, the one that is first mentioned is used and a warning should be issued. Already mapped values are then ignored when evaluating further VMs. The following priorities exist (1 = highest priority):

  1. single value via ..value
  2. ..orderedSet/..List
  3. set formed by multiple values via ..value
  4. ..Set
  5. ..interval

Since discrete values on the target site are distinguished and mapped to source values, only mappings to visual attributes - not to other visual relations - will typically have value mappings. In the case of graphic-object-to-object-relations, there are usually no various target values which need to be mapped explicitly. Since most are binary, there are only two - either the graphic relation exists or not.

CLARIFIED: Should value mappings also be able to work on the subject/predicate part of a statement? By setting "object" as default and using an optional parameter, this could be achieved. However, creating a different mapping for each subject value is hardly useful and different predicates can be distinguished via multiple property mappings or by mapping the URI to an additional visual means within a composite mapping.

INFO: VMs for GO2ORs? - more arguments against:

For graphic object-to-object relations, we decided not to allow value mappings for the following reasons:

1 ) The behavior can be achieved by filtering on PM level as well

2) VM are convenience constructs for filtering statements by object only, but in the case of GO2ORs filtering the subject side is usually equally important. Object side as default makes no sense here.

3) There is no variety of "values" that needs to be distinguished (also stated in the comment above). Limiting a PM by attached VMs (which say relate or relate not, e.g. linked_to and not_linked_to) would contradict the PM's general statement. (-> filters are more logical)

4) The name "VM" would make no sense

TODO: Continuous Color Ranges:

Ranges of colors are complicated to describe, since color is a multidimensional construct and may be based on various color models (RGB, HSL, ..). Also it has to be possible to map to "paths" visiting multiple colors (e.g. from red via white to green). This has to be handled in future by extra mappings and could internally use discrete 1-to-1 value mappings (or an extra class "PathStep") to model the steps in such a path. The problem of color paths could be generalized to paths through other spaces than the color space as well. SVG also modells such paths and could be reused/immitated here.

TODO: Should this be abstract as in the diagram?

INFO: Using multiple Selectors at the same time:

At the moment using multiple selectors is only allowed for those selectors selecting unordered sets. Other considerations on this are noted in the figure below:

INFO: Invalid / Discouraged / ... combinations of source/target selectors on a syntactic level:

Considerations on which selectors can reasonably be used in combination between source and target side are given below. These considerations have to be aligned with later changes. This is not up-to-date.

has super-classes

Object Properties

exclude source valueop


has super-properties
  • owl:topObjectProperty

Excludes a discrete source value from the mapping.


Use the range of source values from HighImportance to LowImportance, but exclude MediumImportance.

Excluding a value from the mapping does not mean that a resource with this value won't show up at all in the graphic. That is the task of filtering the data to visualize. It simply means that this value does not get a visual value assigned by this mapping. Hence, the default value for the visual attribute will be chosen instead. In this case it is important to chose a default value, that is not mixed up with a value that carries meaning! So the default value has to be chosen carefully.

TODO: What is the best term for the user of the mapping vocabulary to understand that the values are not filtered completely? Ignore? Hide? Exclude? Hide and ignore suggerate filtering.

TODO: Should this also be usable on PropertyMappings directly as a shorthand?

TMPOFF: domain also IdentityMapping

exclude target valueop


has super-properties
  • owl:topObjectProperty

Excludes a discrete target value from the mapping.


Map to {orange, red, blue, black} but exclude black, when mapping to an existing color set. Also values from ranges of discrete ordered values may be excluded: Use the range from shapeNamed:A to shapeNamed:C, but exclude shapeNamed:B.

falls back toop


has super-properties
  • owl:topObjectProperty

The mapping that should be used as a "fall back", when some constraint, e.g. of the user-model or system-model is not met.


Example for value mappings: if "gold" cannot be displayed -> fall back to "yellow". If "dotted" lines cannot be drawn, use "dashed" lines instead.

Examples for property mappings: If color ("hue") cannot be displayed -> fall back to "brightness" -> if this cannot be displayed either, fall back to "texture density".

We decided to allow the definitions of fall-backs on the level of mappings instead of the level of visual means, to allow for context-dependent decisions. Still, fall-backs between visual means could be defined additionally in future versions of this vocabulary.

has sub-mappingop


has super-properties
  • owl:topObjectProperty

Points to a SubMappingRelation instance, not directly to another Property mapping in order to create an n-ary relationship. Please refer to "SubMappingRelation" for details.

Often not used correctly; Does often not point to a SubMappingRelation, but directly to other mappings. Cf. SubMappingRelation

Domain can proabably be P2GO2OR mapping.

map missing values toop


has super-properties
  • owl:topObjectProperty

The visual value to map missing source values to. Related to neutralValue, but not the same. It might happen that a dataset has some entities that do not have a value for a property that others have attached (e.g. when selecting entities with SPARQL the OPTIONAL operator). This setting allows to define which graphic value is chosen in this case. This could be either the neutral value, or a very different value than the others, to stress that the value has to be interpreted differently from the others.


For a set of persons, it can be stated which value for "position" should be chosen, when their geographical position is unknown.

TMPOFF: range better rdfs:Literal or viso-graphic:Visual_Attribute

The range should be literals with string, int, float, boolean + discrete visual attributes

neutral valueop


has super-properties
  • owl:topObjectProperty

The visual value to use, if no semantics should be expressed by the visual means.

If unset the viso-graphic:default_neutral_value of a visual means is used. The neutralValue owerwrites the default_neutral_value, to allow for different neutral values for different presentations.

If this is also unset, the average value is calculated from all available target values and a warning is issued.

Calculating an average is only possible for ordered values, therefore, for non-ordered values, it is required that neutralValue or default_neutral_value are defined.


1 use case: Missing source values.

2 use case: No ValueMapping exists (or can be calculated) for a given source value (e.g., when "source value out of bound" or "value mappings only" is chosen)

on roleop


has super-properties
  • owl:topObjectProperty

States the role of graphic objects where this mapping will be applied. (If not set, the default which is "mark" will be used.) While submappings refer to a smaller and smaller subset of graphic objects, on the source side, the mappings all refer to the properties of the entity where the basic mapping was applied. Please refer to "SubMappingRelation" for details.

TODO: Make this optional, when only one new graphic object is introduced where submappings could be applied?! -> Rather not. What about cases where there is no new GO at all??

order source values byop


has super-properties
  • owl:topObjectProperty

Defines a property, that is to be used (for the context of a concrete mapping) for ordering the source values that have been selected for mapping. This may either be a (transitive and acyclic) object property (we refer to as the "order-relation-property"), or a datatype property that adds a numeral value to the selected individuals.


  • Top example: Assume the property "ex:size" shall be mapped. For defining an order between the (named) size values, the (order-relation-property) "ex:gt", an ObjectProperty, is selected. Another example would be to order various phases ("Beginning" "Endphase" "Middlephase") by a relation "ex:followsDirectly".

  • Bottom example: The property "ex:receivedAward" shall be mapped. The order of the possible values ("Bronce", "Gold" and "Silver") is determined by the ex:ranked value. This is explicitly stated by setting "orderSourceValuesBy" to "ex:ranked".

INFO: Instead of defining an order relation for the context of the mapping, this could also be achieved globally by making the property in question a subproperty of either viso-data:greater_than or viso-data:less_than. Similarily, by making a datatype property in question a subproperty of has_ordinal_value this can be achieved for datatype properties that offer ordinal information about individuals.

CLARIFIED: Is it necessary to have two properties, orderSource- and orderTargetValuesBy? -> Yes, if stated for a mapping.

TODO: Semantics: Does this form an implicit selection (all values related via the property) or should the system return an error, when a resource misses this property and, therefore, cannot be ordered?

How to handle the case, when the property only offers a weak order, i.e. a DAG topology is created by it, not a list? Should such properties be allowed here?

order target values byop


has super-properties
  • owl:topObjectProperty

Using order properties in order to create an order between target values is discouraged, since this could generate a non-strict order. Lists are preferred to object properties here. Also selecting datatype properties can lead to a non-strict order. In both cases a warning should be issued, when multiple values are ranked equally.

preferred propertyop


has super-properties

The property to be chosen, when two properties are "merged" for visualisation purposes, for example, when a property and its inverse are represented by a single visual means in the graphic.

property to simplifyop


has super-properties

A property that shall be simplified for graphic representation. Multiple properties may be selected.

quantify source values byop


has super-properties
  • owl:topObjectProperty

Defines a property, that is to be used (for the context of a concrete mapping) for assigning a quantitative value to the source objects that have been selected for mapping.


  • "sizeInMM" is selected as the quantification property. Values such as Big (sizeInMM="10"), Medium (sizeInMM="5") and Small (sizeInMM="1") are quantified using the quantitative values assigned by sizeInMM.

quantify target values byop


has super-properties
  • owl:topObjectProperty

Defines a property, that is to be used (for the context of a concrete mapping) for assigning a quantitative value to the target objects that have been selected for mapping.


"sizeInMM" is selected as the quantification property. Values such as Big (sizeInMM="10"), Medium (sizeInMM="5") and Small (sizeInMM="1") are quantified using the quantitative values assigned by sizeInMM.

similar propertyop


has super-properties

property that is somehow similar to another

source intervalop


has super-properties
  • owl:topObjectProperty

source propertyop


has super-properties
  • owl:topObjectProperty

The property from the data to be mapped.

A sourceProperty always works as a basic filter, limiting the mapped statements to those where the predicate is the given sourceProperty. Note that addditional constraints on the statements to be mapped can be defined via constraining the subjects and objects (e.g. via subjectFilter).

As range also expressions in SPARQL (attach via SPIN?? or as strings??) could be allowed in order to describe selektors (filters) which select triples (similar to the selektors used with FRESNEL propertyFormatDomain) instead of sets of resources. Doing so, it would be possible to define a complex context in which a mapping has to be applied.

FSL-selectors: If we also allow expressions in a path-language: Can the necessary triples be selected this way? S,P,O need to be known after each matched selektion! FSL always selects a set of nodes or properties, so this will be difficult/impossible?!

source valueop


has super-properties
  • owl:topObjectProperty

The value(s) from the source data to be mapped. "sourceValue" is used in value mappings (but also in Identity mappings) to allow for the selection of multiple discrete source values alternatively to the selection of a (predefined) set or list.

TODO: The range should actually be instances of the classes defined as range of the defined sourceProperty or rdf:literals. This cannot be expressed in owl, but SPIN can be used for this.

INFO: This cannot replace sourceValueSet and sourceValueOrderedSet completely, since we may need to select an existing set/list.

TMPOFF: domain also PropertyToGraphicAttributeMapping

source value ordered setop


has super-properties

Defines a list that will be interpreted as an ordered set, i.e. no duplicates are allowed. Tools should issue a warning, if the list contains duplicates.

We don't need sourceValueList, since if we allowed duplicates in a list, the mapping would not be deterministic anymore.



has super-properties
  • owl:topObjectProperty

Points to another mapping, that is used as a sub-mapping. Existing mappings may be reused here. Please refer to "SubMappingRelation" for details.

target attributeop


has super-properties

The graphic attribute to be mapped onto.

target graphic relation (abstract)op


has super-properties
  • owl:topObjectProperty
has sub-properties
target attributeop, target object-to-object relationop

Abstract property. The graphic relation to be used in a mapping. Sub-properties need to be used in mappings - either targetGraphicAttribute or targetObjToObjRelation.

TODO: Is the range correct? Should it be OP or only Property? Can it be functional otherwise?

TODO: Do we need the two sub-properties?

target object-to-object relationop


has super-properties

The target graphic object-to-object relation to map onto.

target valueop


has super-properties
  • owl:topObjectProperty

A concrete discrete visual value to map onto.

"targetValue" is not only used in value mappings, but also in various property mappings to allow for the selection of multiple discrete target visual values (alternatively to the selection of an existing or adhoc created set or list).

The domain is mapping, since it is also needed for property mappings, not only value mappings.

This cannot replace targetValues completely, since we may need to select an existing set/list.

TMPOFF: rage viso-graphic:Visual_Attribute or rdfs:Literal, domain should also be resource mapping

target value cycleop


has super-properties

The values are to be interpreted as a cycle of ordered values.

Use with care - c.f. targetValueList.

target value intervalop


has super-properties
  • owl:topObjectProperty

target value listop


has super-properties

Can be used to assign a list of ordinal target values. The values are to be interpreted as a list of ordered values. As oposed to targetValueOrderedSet, entities may occur multiple times.

Same targets for different source values are usually not wanted in visualisation. As with targetValueCycle, ambiguous mappings could be the result! However, there may be cases where using a target value multiple times is acceptable and the absolute value is clear from context (e.g. isomeres).

target value setop


has super-properties

Assigns a set of target values, which are not interpreted as ordered. Since it is a set of values, each value may only appear once.

target values (abstract)op


has super-properties
  • owl:topObjectProperty
has sub-properties
target value cycleop, target value listop, target value ordered setop, target value setop

As an example such a set could define a number of colors that match well. Predefined sets are provided as facts in the graphics ontology.

Abstract. Depending on the used subproperty, the Visual_Value_List will be interpreted as actually being only a set, ordered set, list or even a cyclic list. This approach was chosen, since we may want to use existing lists as either only a set, ignoring order, or we may want to state, that we want to use the list in a cyclic way.

1.Possibility: Use Parameter cycleTargetValues boolean (if true, values in a set are used multiple times, if they are not enough to represent the (discrete) source values)

2. Possibility: Use cycle-container class, rdf:bag, rdf:list (it is hard to tell which container class to use best, some a deprecate, most are not well supported)

3. Possibility: Use different property for referencing a list (means list/set/cycle depending on the property). (This is used here)

Is this range fine? It prevents other sets of values than defined with VISO from being used.

value mappingop


has super-properties
  • owl:topObjectProperty

States that some value is mapped explicitly to some discrete visual value. This overrides implicitly assigned mappings if existent.

Data Properties



has super-properties
  • owl:topDataProperty

Defines whether the mapping should be ignored during the evaluation of mappings.

discrete step countdp


has super-properties
  • owl:topDataProperty

Defines the number of discrete steps for discretization of a continuous target value interval. If no target interval is explicitly defined, the maximum possible range (e.g., as limited by the available screen space) shall be used.


NOTE: Tableau lets the user manually create "bins" in order to divide value-ranges into an ordered set of value sets.



has super-properties
  • owl:topDataProperty

Divides a continuous range into discrete values. If the numer of discretization steps is not given by discreteStepCount, the number of steps will be calculated on the available data and selected target values. Cf. ValueMapping for details.

TODO: Is it correct, that this is only used for discretizing continuous TARGET intervals?

TODO: Is VM or PM the best domain for this?

NOTE: The term "discrete" is used in RVL in three contexts which are compared here for clarity:

- "discretize" divides a continuous range into discrete values

- We talk of displaying "discrete" graphic objects in a graphic (which is the normal case, e.g. a dotplot) vs. drawing continuous graphic elements (e.g. a curve). Cf. the flag drawInterpolated which will cause this behavior.

- Finally, "discrete" values can be stored as resources to allow for giving them a name. (e.g. lightness_named=vg:Bright vs. vg:color_hsl_lightness="100"^^xsd:float) These resources will usually encapsulate a literal stating the actual value.

ALTERNATIVE: The discretize flag was introduced to replace various classes for mapping from continuous-to-discrete, continuous-to-continuous ... This was done to allow for easier switching between the mapping "types".

draw interpolateddp


has super-properties
  • owl:topDataProperty

States if marks may be drawn interpolated.


Draw line instead of dots.

This flag will cause the graphic to show source values that do not exist in the raw dataset, but have only been interpolated! Therefore, this setting has to be done with care not to suggest the impression of continuous data, when only discrete source values exist.

TODO: A warning should be issued, when this is set to true for discrete values (problem: there is no continuous/discrete flag at the moment)

include in legenddp


has super-properties
  • owl:topDataProperty

Defines whether the Mapping should appear in legends. Value mappings and property mappings may generate entries in a legend.

invert order of target valuesdp


has super-properties
  • owl:topDataProperty

Inverts the span, or list of target values. This can be useful, when mapping to a predefined color range for example, where the range perfectly fits, except the orientation is wrong. Also lists of target values may need to be flipped, in order to better fit some existing conventions or expectations of the user.

invert source propertydp


has super-properties
  • owl:topDataProperty

Uses the inverse of the source property instead of the source property and additionally maps occurences of the source property inverted.

missing source valuedp


has super-properties
  • owl:topDataProperty

When an entity misses some value for a property that should be mapped - which visual value is chosen then? What should happen to the entity?

hide - hide the entity (draw no mark at all), but consider it in calculations (e.g. the calculation of the overall range of all values in a data set)

ignore - act as if this entity would not exist

neutral - show the entity with a mark and map to the neutralValue in order to minimize the misinterpretation (discouraged)

missing - (default) display a mark for the entity but make clear that the mark does not represent a value for the property, by using the "rvl:mapMissingValuesTo" value that was defined for this purpose.

average - an average value is calculated from all target values available

Should the midrange be chosen here as average? Or another way of calculating an average value?

What is the best default behavior? "missing" is better then "neutral", but requires "rvl:mapMissingValuesTo" to be defined!

missing value mappingdp


has super-properties
  • owl:topDataProperty

If there is at least one value mapping, but not all source values are handled by some value mapping - what should happen to the other source values?

hide - hide the entity (draw no mark at all), but consider it in calculations (e.g. the calculation of the overall range of all values in a data set)

ignore - act as if this entity would not exist

neutral - show the entity with a mark and map to the neutralValue in order to minimize the misinterpretation (discouraged)

average - an average value is calculated from all target values available

calculate - (default) Other source values, without an explicit manual value mapping, get a calculated value mapping assigned (as if no value mappings existed).

no mapping - perform no mapping when there is no value mapping for the source value. This does not mean, the entity will be hidden or ignored. Please note: since some visual means cannot be unset (such as color) the neutral value will be chosen here, which may not always be the desired effect. This setting is useful, for example, in cases where additional graphic objects would be introduced by the mapping (such as labeling).

TODO: clarify "no mapping"

object filterdp


has super-properties
  • owl:topDataProperty

Reduces the set of statements to be mapped to those where the OBJECT matches the filter defined by either a SPARQL or FSL selector.

The sourceFilter of value mappings have a similar function as the objectFilter but is used on the level of value mappings, not on property mappings.

TMPOFF: range also fslSelector

scale transformation typedp


has super-properties
  • owl:topDataProperty

INFO: Here the enumeration is modelled as owl:Datatype. Values can be selected via Add existing .. in topbraid

TODO: Also arbitrary transformations of the scale should be possible.

source filterdp


has super-properties
  • owl:topDataProperty

Reduces the set of source values to those matching the filter defined by either a SPARQL or FSL selector.

Difference to objectFilter: ObjectFilter used with property mappings can filter on the level of property mappings - allowing different graphic realtions to be applied depending on the filter. As opposed to this, sourceFilter only allows for filtering on the level of source values and should be used when the graphic relation is not varied based on the filtering, but only the values are varied. Properties such as sourceValueSet, sourceValue and sourceValueInterval partly work as filters as well and can more easily be used for most cases. For examle, with sourceValueSet existing sets can very easily be referenced. sourceFilter covers all other more complex filtering needs.

a targetFilter could also be introduced. This would allow for selecting ad-hoc subset of graphic attribute values such as "all colors suitable for the color-blind".

TMPOFF: range also fslSelector

source values labeldp


has super-properties
  • owl:topDataProperty

Gives a common label to the selected set of (single) source values.

INFO: Became necessary to label the ad-hoc sets which may occur by using sourceValue multiple times.

source values out of boundsdp


has super-properties
  • owl:topDataProperty

Defines how to handle source values out of the bounds given by interval mappings.

Clamp - map them to the same values as the borders of the interval

Cut (default) - don't treat these values with this value mapping

WARNING: Here it was not possible to modell the enumeration as owl:DataRange generating nice input fields in TopBraid, which is deprecated however. range should be OutOfBoundHandlingType. However, this generates errors in TopBraid when trying to use it after relaoding .

The domain is PM, not a VM or Interval, since the setting was intented to count for all source intervals associated with a property mapping. Now that only one source interval is allowed it could also be a property of a Value mapping or Interval.

Problem: Clarify meaning of cut! Clarify similarity to missing source values and missing value mapping! In the case of cut, other settings will take control, therefore, this should probably be named differently.

subject filterdp


has super-properties
  • owl:topDataProperty

Reduces the set of statements to be mapped to those where the SUBJECT matches the filter defined by either a SPARQL or FSL selector.

Although applying different mappings for the same relation should generally be avoided for reasons of visual inconsistency, there are cases where it perfectly makes sense to use differerent visual means for the the same property: For example, we will probably want represent the age of a person differerently from the age of trees.


At the moment a subjectFilter is the only way to create mappings based on cardinality or universal restrictions. E.g. we can define a mapping (via a SPARQL expression) to be applied when a Person knows at least two other persons, or when a Person knows only books (but notthing else).

- TopBraid will not display a string field in the form-based editor when a range using OR is used.

- Unlike with objectFilter, there is no alternative to subjectFilter for constraining mapped statements by subject

- TODO LATER: Should filters also be applicable on the target (visual) side of (value) mappings? E.g. a set of suitable visual values could be selected by some criteria such as suitedForTheColorBlind=true

TODO: range also flselector

Namespace Declarations

default namespace

Work on this project received financial support from the European Union and the Free State of Saxony.
Logo of the sponsors

This HTML document was obtained by processing the OWL ontology source code through LODE, Live OWL Documentation Environment, developed by Silvio Peroni.