Rendering Engine

The Purpose

Inside the resource view (as well as in other parts of the UI in future releases of ST) it is necessary to compute a more human friendly representation of a resource than its URI or bnode identifier. That may be the case for bnodes that are heads of RDF Collections or represent anonymous classes. Another case is when the dataset uses opaque identifiers (e.g. alphanumeric local names), which are not comfortable for human users.

The Model

When the resource view is opened for a given subject resource, the rendering is based on the engine associated with the dataset defining that resource. In case the resource is available in one of the local projects currently open, than the rendering engine associated to that project is used. Otherwise, in case of a remote resource, it is considered an implementation based on RDFS labels.

Rendering Engine Configuration

During project creation

A specific Rendering Engine is associated to a project during its creation. In the panel "Optional settings", it is possible to choose a Rendering Engine, in place of the default one. Also, it is possible to configure the selected rendering engine, by choosing an alternative configuration than the default one. In some case, it may be necessary to manually configure the chosen configuration type, if it has at least one mandatory parameter with no default value.

The default rendering engine is determined based on the model type of the project being created. As explained below, there are currently three implementations of this extension point that covers respectively rdf:labels, skos:prefLabels and skosxl:prefLabels, respectively.

Low-level project metadata

It is not currently possible to change the Rendering engine after a project has been created. However, it is possible to change the Rendering Engine by altering the metadata of a closed project.

In the project file (project.info), there are two properties:

plugins.mandatory.rendering.factoryID: the ID of the factory to use
plugins.mandatory.rendering.configType: the type of configuration used

Then, in the project directory, the file rendering.config contains the serialization of the configuration object to use for instantiating the extension point.

Rendering Engine Implementations

The predefined RenderingEngine implementations construct a representation the form label1 (lang1), label2 (lang2) ..., based on labels expressed in different lexicalization models.

These RenderingEngine share the same configuration options: accordingly, we will discuss them once.

The configuration parameter languages contains a comma-separated list of language tags, ${languages} to mean the current display languages, or the star * to mean any language. Actually, a value different from ${languages} would make the customization of the display language via project level user settings ineffective.

The optional configuration parameter template allows for customizing the representation produces by the rendering engine, usually by adding further property values. A template consists of:

literal content: text that will be included as is
variable substitution expression: ${variable name}
optional sub-template: (...)? which can contain arbitrary literal content and variable substitution expressions

The backslash character \ can be used within a template to force the interpretation of special characters, such as parenthesis, question marks and dollars signs, as literal content instead.

The predefined variable show contains the default representation obtained by concatenating the labels. The configuration parameter variables can be used to define further variables: each variable is associated with a property path (i.e. a sequence of properties), which is used to initialize the variable with an RDF term extracted from the description of the resource being rendered.

If the property path associated with a variable can extract multiple values, which are candidate for the initialization of the variable, then one of them is picked randomly. Consequently, the property path should be defined in such a way that at most one value should be found within a well-formed dataset.

When validation is enabled for a given project, it is possible however that a property path can extract multiple values, because the traversed triples exists in different validations stages. In this case, the rendering engine tries to behave predictably, by considering, orderly, information that is committed, staged for addition, and staged for deletion. Let us consider a property path of length one, if a user replaces its value (i.e. deletes the existing one and adds a new value), then this order guarantees that the value staged for addition is considered (which, in a certain sense, is the most up-to-date). Unfortunately, this behavior has a computational cost, which can be avoided by setting the property ignoreValidation to true.

Let us consider a pretty common use case, in which someone wants to include in the rendering of a SKOS concept its skos:notation.

A template should be like this (: )?${show}. Before discussing the definition of the variable notation, which is initialized with the skos:notation, it is important to observe that it is used inside an optional sub-template: some SKOS concepts may not have skos:notation and, above all, the same template is applied to render any resource, including ones that should not have a SKOS notation.

In this example, the variable definition is written like this:


{"notation" : {"propertyPath" : ["<http://www.w3.org/2004/02/skos/core#notation>"]}}

The properties of the outer object (e.g. notation) are the variables, while the values of these properties contain their definition. The nested object defining a variable, the property propertyPath is a JSON array corresponding to the property path.

RDFS Rendering Engine

The RDFS Rendering Engine (whose factory ID is it.uniroma2.art.semanticturkey.plugin.impls.rendering.RDFSRenderingEngineFactory) constructs a representation of a resource of the form label1 (lang1), label2 (lang2) ... based on its rdfs:labels in the configured languages.

This rendering engine has only one type of configuration (RDFSRenderingEngineConfiguration).

SKOS Rendering Engine

The SKOS Rendering Engine (whose factory ID is it.uniroma2.art.semanticturkey.plugin.impls.rendering.SKOSRenderingEngineFactory) constructs a representation of a resource of the form label1 (lang1), label2 (lang2) ... based on its skos:prefLabels in the configured languages.

This rendering engine has only one type of configuration (SKOSRenderingEngineConfiguration).

SKOSXL Rendering Engine

The SKOSXL Rendering Engine (whose factory ID is it.uniroma2.art.semanticturkey.plugin.impls.rendering.SKOSXLRenderingEngineFactory) constructs a representation of a resource of the form label1 (lang1), label2 (lang2) ... based on its skosxl:prefLabels in the configured languages.

This rendering engine has only one type of configuration (SKOSXLRenderingEngineConfiguration).

OntoLex-Lemon Rendering Engine

The OntoLex-Lemon Rendering Engine (whose factory ID is it.uniroma2.art.semanticturkey.plugin.impls.rendering.OntoLexLemonRenderingEngineFactory) constructs a representation of a resource of the form label1 (lang1), label2 (lang2) ... based on OntoLex-Lemon lexicalizations in the configured languages. Additionally, it includes rdfs:labels as fallback.

This rendering engine has only one type of configuration (OntoLexLemonRenderingEngineConfiguration).