Resource Rendering
VocBench allows for rendering of RDF resources (i.e. showing them in different, usually more human-friendly, ways wrt their URI) accordng to different policities.
By first, rendering is a functionality based on an extension point, so that very specific policies can always be covered by developing and plugging a dedicated rendering engine.
However, VocBench (more specifically, its backing server Semantic Turkey) comes bundled with an already configurable rendering engine, which is satisfying most of the common (and less common) needs.
The rendering engine can be configured at project creation (in the advanced settings) or later on, by the administrator, by closing the project and selecting its context option "Edit Project Settings".
Whichever the origin, the section for configuring the rendering engine will look like this:
From this menu it is then possible to select which rendering engine to use and, in case, customize its behavior through the "configure" option. Please notice that the initial selection will be automatically set basing on the lexicalization model chosen for the project and it will mostly affect the rendering based on labels (if labels are chosen to be adopted for rendering, otherwhise it is irrelevant).
Once the configure button is clicked, the next window will appear as in the following picture:
The fields above contribute to the configuration in this way:
- Languages: it is possible to describe the set of languages, universally for the project, that will be used for rendering the resources by using their labels. If the userLangs variable is used (variables are always indicated with the ${variablename} syntax), then the languages are determined by the preferences for rendering set by each user, independently.
- Template: as the name suggests, this field describes the string that will be used as a template for representing resources. The template must be a mix of ground characters and variables (to determine what characterizes each resource). A special variable, labels, determines the rendering based on the labels of the resources (constrained by the languages described in the languages field). If the field is left empty, it defaults to: ${labels}, thus rendering the resource with the set of its labels without further customization. It is possible to use a group notation in order to bind the representation of parts of the template to the existence of some property values (see example later in this section).
- Variables: this field allows for the definition of user-defined variables. The field is indeed a map, with keys representing variables and values representing their binding to properties. The binding to properties can be defined in terms of single properties or property paths, by listing the properties to be traversed for each variable. Please notice that, usually, configuration panels allow for the possiblity to choose RDF resources (in this case, properties) directly from the project. However, since this configuration field can only be accessed with the project being closed, the user has to manually write or paste the URI of the properties into the property path fields.
- Ignore validation: this field determines whether the values that would be extracted by the previous settings would be considered even when pending validation.
In the following example:
we see how the property skos:notation is bound to the variable notation. Furthermore, the group feature of the template is being shown; the template is meant to represent resources with their skos:notation value, followed by a colon (":"), a space and the list of labels, according to the user preferences for visualization, so that the concept tree would look like this:
However, what if the skos:notation property is not valued for a certain concept? Instead of the ugly representation with an empty string followed by the colon, it is possible to bind the colon to the existence of the skos:notation value, with the group expression (...)?. This way, if the skos:notation is missing, only the labels will be represented, with no colon separator.