Summary of Already Implemented RVL features
In order to learn about what features of RVL have been implemented in the current prototype, look at the mapping examples in the rvl-example module and the test cases in the rvl-process project or browse the examples in our demonstrator.
The following presents a (possibly not complete) overview on the implemented features:
PropertyMapping to Graphic Object-to-Object Relations
- Mapping an rdf:Property to a graphic (Object-to-Object) relation such as "vg:Linking_Directed_Relation"
- Limitations: Property must only be used between resources (like owl:ObjectProperty)
:SomeExampleMapping a rvl:PropertyMapping ; rvl:sourceProperty foaf:knows ; rvl:targetObjToObjRelation vg:Linking_Directed_Relation ; .
- vg: Linking_Directed_Relation
- vg: Linking_Undirected_Relation
- vg: Labeling_Relation
- see for a complete list of other not yet implemented relations
PropertyMapping to Graphic Attributes
- Mapping any rdf:Property to a graphic attribute such as "vg:color_named".
- Limitations: does not yet work without value mapping
Supported graphic attributes
- Integers from 0-100. Example: "50"^^xsd:int
- Values should become all defined by CSS. For now only vg:Red, vg:Green, ... are supported. Search the currently used version of VISO/graphic for RVL for others
- E.g. common-shapes:Square, common-shapes:Rhomb, common-shapes:Cross, common-shapes:Star18 ...
- All named shapes mapped in ShapeX.java to SVG objects from org.purl.rvl.tooling.d3vis/svg/symbols.svg.
- It is planned to dereferenciate arbitrary SVG files and use them as shapes
- Limitation: The area of the SVG-shapes cannot be calculated at the moment. This leads to inacurate sizing (square pixels)
- Pixels as integer 0-100. Example: "75"^^xsd:int
:SomeExampleMapping a rvl:PropertyMapping ; rvl:sourceProperty factbook:internetusers ; rvl:targetAttribute vg:color_named ; .
- Manual value mappings are n-to-1-mappings from 1 or more source values to exactly 1 target value:
[ a rvl:valueMapping; rvl:sourceValue dbpedia:Tom_Baker; # rvl:sourceValue "Tom Baker"@en; # optionally more values ... rvl:targetValue vg:Green; ].
- Various automatic value mappings are available.
- IdentityMappings can pass through source data values to the graphic, which is needed to pass through text values (but rarely in other cases):
- currently all values are passed to vg:text_value
- generated text objects will also be labeled, which is probably not desired
- Supported source values: all rdf:Literals (all interpreted as strings)
- Special source values (beyond current spec):
- WILL ONLY WORK IN SUBMAPPINGS BY NOW
- rvl:label - look for other common label properties and use the resource's local name otherwise
- rvl:IDandTypes - HACK to display the ID and a list of the resource's types, mainly introduced for debugging purposes
:LabelTextIdentityMapping a rvl:IdentityMapping ; rvl:sourceProperty rdfs:label ; rvl:targetAttribute vg:text_value ; .
Filtering the data of interest is considered to be a preceeding step and out of the scope of RVL. The following means of filtering are only intended to restrict the application of mappings. Currently statements to be visualized by PropertyMapings can be filtered by their subject as follows using rvl:subjectFilter with a string typed with a ...
rvl:subjectFilter "owl:Thing"^^rvl:classSelector; - This will filter subjects to instances of owl:Thing.
This will filter subjects to sub-classes of "PO_0025059"
Only very simple FSL like statements as short as the one above allowed so far.
Prefixes not yet supported in the expression and as a separator "::" must be used
For more complex filtering demands a SPARQL query can used as a filter.
rvl:subjectFilter " ?s rdfs:subClassOf ?restriction . ?restriction owl:onProperty amino-acid:hasPolarity . ?restriction owl:allValuesFrom amino-acid:Polar . "^^rvl:sparqlSelector;
- This will filter subjects to those classes being restricted to "Polar" for all values of "hasPolarity".
- Sure, this is a hack ;) and will be changed to work with a statement set.
- General limitations:
- Not applicable to sub-mappings
Handling of Class-Level Relations
Using rvl:inheritedBy (rvl:passBy not yet implemented) mappings can be extended to cover class-level relations such as rvl:domainRange, owl:someValuesFrom or owl:allValuesFrom. To allow for a consistent handling of these implicit relations (just like normal properties), currently, an URI is derived from the orginal property following this schema:
- original URI --> <original URI>____(<name of the class restriction>)
other values are "class-restriction", "some-values-from", "all-values-from".
As a workaround - as long as we don't provide labels for the generated "properties" - we "decode" the URI to yield a more readable string by replacing "____" by " " (i.e., "4 underscores" by "space").
- A text label is automatically added to all graphic object that represent rdfs:Resources unless they already have some text label
- (Graphic) nodes representing identical resources are co-highlighted on hovering the mouse over one of the nodes
- Neighboured nodes (and connectors) are highlighted in the force-directed representation
- Neighboured nodes (and connectors) and the whole path to the root are highlighted in the collapsible-tree representation