In the remainder of this section, we list additional criteria only applying to RDF display languages.
Display, Sorting and Formatting of Resources Table 4.24 gives an overview of how the examined RDF presentation languages handle the questions of (1) What resources to display? (2) In which order? (Sorting) and (3) How should resources be formatted?
Looking at the first three columns, which represent these presentation steps, we note that none of the languages separates all these steps. Some languages such as Fresnel/REMM and LeTL separate some steps though. In Fresnel, selecting what to display and in which order is performed by the »Lenses« and separated from formatting being the »Formats« task. Also in LeTL, the choice of what to display is done in a previous step (SPARQL query) before going on with formatting. GSS does not provide means to select subgraphs for display, but the whole graph is styled unless parts of the graph are excluded using gss:display = none.
Conditional Branching and Looping Conditional branching and looping constructs can be found in all languages, except for the declarative ones. VPOET offers very limited conditional branching, though, and no looping.
Resource Selection Methods and Languages The basic means of selecting resources (properties, classes or instances) is to address them by URI. Besides this, however, most of the languages also support the description of selectors by means of a dedicated selection language. While SPARQL is frequently supported (Fresnel, LeTL, UISPIN), some languages use own expression languages, which are often path-based and inspired by XPATH (FSL used in Fresnel, TALES used in Tal4Rdf and OWL-PL expressions). Path-based languages are often considered a more concise or intuitive [Cha09] alternative to SPARQL, but may also coexist.
Attaching Display Information to Resources In the last column of Table 4.24, we compare how presentation information is »attached« to the resources. This is an interesting detail, since a similar mechanism is required for visualisation information as well.
While Fresnel and GSS select the resources in question by means of selectors that are attached to the Styles respectively Lenses and Formats, in UISPIN, the opposite approach was chosen. Here, a view can be attached to a resource, which may be a class or instance. For classes, it is possible to attach views in two different ways in order to distinguish styling the instances of a class from styling the class itself29. This is achieved by using the instanceView instead of the view
property. In the template approaches no explicit coupling between classes and styles is possible, but data is referenced ad hoc within display descriptions. An exception to this is LeTL, which allows for restricting templates to special classes. A further observation is that only Fresnel allows for styling properties, i. e., making explicit statements on how relations should be styled. This is interesting, since we aim at the definition of visualisation information per relation. Details of Resource Display and Formatting
Table 4.25 offers more details for those readers interested in a detailed comparison of RDF presentation languages. The criteria are again separated into display and formatting of resources: Since RDF is a graph, cycles may occur and need to be handled somehow in order to obtain a document structure. Fresnel turns the graph into an ordered tree for this purpose. Since sublens relationships can cause infinite loops, this can be addressed by specifying a maximum recursion depth. In GSS, there is no need to handle cycles, since the graphs spatial structure is
CHAPTER 4. ANALYSIS OF THE STATE OF THE ART
left as is and not turned into a document (tree) structure at all. Tal4Rdf restricts each node to show up only once in the presentation and thereby avoids infinite recursion problems. For the other languages, we could not find means of handling cycles explicitly. UISPIN and LeTL seem to delegate this problem to SPARQL (a DISTINCT SPARQL result set cannot contain the same statement multiple times).
The nature of RDF data, which could be gathered from various sources on the web, suggests additional language features that we sum up as robustness improvements and property bundling. Robustness aims at handling missing or redundant data. Fresnel allows for defining content to be displayed if no value is available for a property as well as a list of alternative properties. If the first property is not set for a given resource, the second best is taken and so on. Less improves robustness on the system level by dereferencing URIs and downloading supplementary linked data. However, robustness is not explicitly supported by the LeTL language.
Bundling properties goes beyond alternating properties, since the created »bundle« may have its own formatting information. Fresnel supports this with its mergeProperties construct. While not making this feature explicit, also Tal4Rdf and OWL-PL offer some support for bundling properties. In OWL-PL, the »or« operator may be used in statements for the same purpose. Tal4Rdf relies on reasoning for merging properties, however, the availability of a reasoner cannot be assumed in all situations, especially in lightweight linked-data scenarios. In the template languages and UISPIN, robustness and bundling may be partly achieved by using if-then-else-statements. While this allows for great flexibility, it may suffer from the fact that display code becomes verbose.
Specific language constructs for modifying labels and values explicitly can only be found in Fresnel. Here it is possible to add presentation-specific labels and thereby override default30
labels or compensate for missing labels. Further, if there are multiple values for a property, often iterating these values only for the purpose of concatenating them by »,« is necessary.
30rdfs:label is evaluated by default.
Cycles handled Robustness impro v emen ts Prop er ty bundling (explicit) Mo d ify lab els (explicit) A dd con ten t to v alues (explicit) Define v alue rendering typ e (exp licit) CSS-supp ort T arget lan guage
GSS - - - (x) - (interpreted) interactive UI, DOT, SVG Fresnel x x x x x x x -
REMM - - - x - -
VPOET - - - x HTML, also JS, CSS Tal4Rdf x - (x) - - - x XML, other textual formats LeTL x - - - x XML, other textual formats OWL-PL ? - (x) - - - x XHTML
UISPIN x - - (x) (x) - x SVG, XHTML (extendible to other XML formats) UISPIN Charts as UISPIN - - - - Google Widgets code (XHTML)
Display Formatting
4.3. RDF PRESENTATION LANGUAGES
Again, only Fresnel allows for stating this concisely by language constructs (fresnel:contentBefore, fresnel:contentLast). UISPIN offers similar support by allowing for the definition of specific UI-templates to iterate over values or present useful labels. Some of these are already available in the TUI31 extension.
Another feature only supported by the declarative languages is the definition of rendering type for the values of a given property. Fresnel, but also GSS, allow for defining, whether a URL of an image should be printed as text or the image located at the URL should be displayed. Fresnel can also define that a navigable link should be created. REMM even extends these capabilities and allows for defining hints on suitable widgets to edit the property’s values. Most languages delegate style settings to CSS or use similar terms and accept values defined in CSS. The latter is the case for GSS, for example.
Additionally, in the same table, the target language is given, unless the approach is platform-independent. While GSS, Fresnel and REMM are not bound to any concrete platform, the template approaches directly produce code in the target platform’s language. The code generation can be aware of the languages schema, e. g., with XML as target language (UISPIN) or XHTML (OWL-PL), but otherwise as arbitrary text (Tal4Rdf, LeTL, VPOET) loosing the ability to statically validate the templates.
4.3.4
Conclusion – What Is Still Missing?
All the languages we compared in this section are languages for presenting data, i. e., turning raw (graph) data into a human readable document format. However, none of them allows for the explicit definition of visual mappings in a simple manner. We can further summarise that many of these languages are not (fully) declarative and depend on a specific platform or a specific visual structure. Composability, where available, does not include visualisation aspects. Besides this, the lack of a formally described, restrictive schema often prevents the derivation of editors.
However, several lessons can be learned from the RDF presentation languages that have been collected and analysed here, especially from Fresnel. Some of the RDF-specific aspects, such as »resource selection«, »attachment of presentation information to resources« and »robustness in an open web« are important for an RDF-based visualisation language as well and should be considered in such a language. In Chapter 7, we discuss, whether building an extension to one of the presentation languages mentioned here is sufficient to overcome their shortcomings or whether a completely new language is required. Further, we also need to clarify, how presentation and visualisation languages can be used in conjunction.
CHAPTER 4. ANALYSIS OF THE STATE OF THE ART