This is a brief showcase (work in progress) of visualization rules, with links to their definitions. See the overview for an introduction.
Two available general purpose rulesets are basic and default. Let's see how they render the following example dataset:
With the basic rules, every triple is shown as a link between its subject and object. The edge label is the local name obtained from the predicate URI, which is available as tooltip. Literal nodes have rectangular shape and the tooltip is either the data type or the language tag. Blank nodes are empty circles and regular URI nodes have the local name as label and the full URI as tooltip. This kind of diagram contains all the information of the dataset, but it is suitable only for very small ones.
The default rules make compact visualizations: only the subjects of some triple become nodes, hence literal values are embedded in the subject node label, that is created as an HTML-like table with the aid of a few N3 built-ins.
To get an idea of which properties and classes are used in a dataset, we can use schema rules. Instead of visualizing the actual nodes in the dataset, we create a node for each class and a node for each property. The edges are drawn between the properties and the classes in their domain and range. This is the outcome for the data above:
The name predicate has literal values, and it is used on instances of class Person but also with subjects that aren't instances of any class, hence classified as generic resources. The livesIn predicate connect instances of Person with untyped resources. The containedIn predicate is used with untyped subjects and objects.
As a first step towards custom rules, we can draw a diagram for our own vocabulary:
The rules used here are still quite generic and may be usable (or at least a good starting point) also to draw other vocabularies, but there are a few assumptions, made for simplicity, that may not hold in other cases (like the existence of a single label and comment for each class and property). There are excellent ontology visualization tools out there, our modest purpose here is to familiarize with custom visualization rules.
The focus is on class definitions (that become nodes) and definitions of properties whose domain is one of the classes. If also the range is one of the classes, the property is shown as an edge between the two classes. If the range is literal, the property is embedded in the label of its domain class.
The barnard59 toolkit allows defining ETL pipelines in RDF. Pipeline definitions can be complex, and custom visualization rules can help understanding them.
Pipelines are represented as rectangular nodes, each with a distinct color. The steps of a pipeline are connected by edges with the same color of the pipeline. This helps to follow the workflow even in the presence of steps shared by multiple pipelines, like mergeInputsStep in the example. The tooltip of each step contains implementation details, like the code module called and its arguments. Some steps have sub-pipelines among their arguments, like mergeInputsStep which takes as input mergeInputsPipeline and, in turn, transformStep which takes as input transformPipeline. In these cases, a strange inverted arrow is used to suggest that the data produced by the sub-pipeline feed the calling step.