As RDF data becomes increasingly available on the Web, there is a need to render this data in different formats, aimed at end-users or applications. We propose Tal4Rdf, a template based language, implemented as an open-source project and an online demo. Tal4Rdf uses intuitive path-based expressions for querying RDF data, allows to easily generate any XML or textual output format, using available and proven technologies. We believe it has the potential to become a “scripting language for presentation”.
More and more RDF data has become available in the recent years, thanks to different
efforts to export RDF from legacy databases [
Tal4Rdf (T4R), a lightweight template language for RDF, aims at providing the underlying technology to help fulfill those requirements. It allows to render RDF data in any XML or textual format, has an open-source implementation and an interactive demo both available at http://champin.net/t4r/. It is based on TAL (Template Attribute Language), an existing template language that we have already reused ? This work is supported by Science Foundation Ireland under grant 07/CE/I1147 and the French
National Research Agency (ANR) under project Cine´Lab (ANR-06-ANR-AM-025).
1 http://linkeddata.org/
successfully in the Advene framework [
In the next section we will present the TAL language. Section 3 will present the rationale and basic features of T4R, focusing on the notion of path to retrieve RDF data. In the next section, we will discuss features of T4R that are more related to the rendering process. Section 5 compares T4R to related works, and the last section concludes and gives some further research directions. 2
TAL
The Template Attribute Language or TAL [
This is achieved by encoding the processing instructions in XML attributes with a specific namespace (usually associated to the prefix tal:). Standard editors for the target format can then be used to modify the presentation of the template without altering (or being altered by) the processing instructions. Furthermore, only minor changes are required in such editors to provide ad-hoc management of the TAL attributes, this functionality being orthogonal to the other features of the format. This approach has been applied in the Advene project and could also be applied to T4R.
We present in Table 1 a subset of the processing instructions of TAL, in order to give an overview of its capabilities. All TAL attributes use a common syntax for accessing the underlying data: TALES (TAL Expression Syntax). TALES expressions are, in most cases, slash-separated paths. The exact meaning of those paths depends on the underlying data structure, but their similarity to file or URL paths makes them pretty intuitive. Hence the idea of using TAL to query and render RDF data, as will be demonstrated in the following sections.
TAL also has the advantage of being implemented in several popular scripting
languages [
The rationale of using TAL for RDF rendering was that TALES paths could easily be
mapped to paths in the underlying RDF graph, hence providing an intuitive way of
querying RDF data. For example, using the FOAF vocabulary [
knows/currentProject/homepage 2 http://zope.org/ 3 http://www.owlfish.com/software/simpleTAL/ <tag tal:content="x/y/z">... <tag tal:attributes="at x/y/z">... <tag tal:condition="x/y/z">... <tag tal:repeat="i x/y/z">... <tag tal:define="v x/y/z">...
Replace the content of the tag by the evaluation of x/y/z.
Add or replace attribute at in the tag, with the evaluation of x/y/z as its value.
Remove the tag and its content if x/y/z evaluates to False.
Assuming that x/y/z evaluates to a collection, variable i will iterate over it, and the tag will be repeated for each value of i.
Creates a variable v with the evaluation of
x/y/z as its value.
meaning that, starting from the resource representing myself, T4R would need to
traverse in sequence three arcs labelled with knows, currentProject and homepage
respectively. The rest of this section describes the actual path syntax used in T4R,
starting from this example, and explains the rationale for its design. For a full BNF grammar
of the path syntax, see [
The motivating example above is a bit over-simplistic. In RDF, arcs (and resources)
are not labelled by plain terms, but by URIs, in order to avoid name clashes. We need a
way of concisely representing URIs as path elements. This problem is well known and a
common solution is to use CURIEs [
In T4R, namespaces prefix and URIs are associated by defining special variables
(using tal:define) of the form t4rns:prefix, in a way very similar to XML.
Note that it is recommended by [
In the following, we will assume that the appropriate namespaces have been declared, with their usual prefix (t4rns:rdf for the RDF namespace, t4rns:foaf for the FOAF vocabulary, etc.). 3.2 Using CURIEs, our intuitive example above, to retrieve the homepages of the current projects of the people I know, becomes: hardly more complicated that our initial proposal. The evaluation of this path on an example dataset is illustrated in Figure 1.
The first interesting thing to notice is that each node may have several values for the same property, hence such a path expression evaluates to a collection of RDF nodes, which can be iterated with the tal:repeat construct. It is also possible to keep only a single node by appending the T4R operator any to this path (see 3.4). However, it is not required when the result of the path is rendered as an element content of attribute. Hence if the path above was used as is to fill the href attribute of a link, it would render as one of the result URIs (the other would then be ignored), keeping the link working4.
Another thing worth pointing out is that, since RDF data has a graph structure, the path may discover the same node several times (cf. Figure 1). However, in T4R, each node matching the path will appear only once, no matter how many times it was reached through the path. 3.3
Sometimes, we are interested in the inverse of a given properties. This is possible by appending :- to a CURIE. Hence, the path: 4 This tolerant behaviour, convenient for rapid prototyping of templates with open RDF data, can nevertheless be changed to a stricter one, which is preferable for debugging complex templates. will retrieve the people working on the same projects as myself (and yield only #paul in the example of Figure 1).
Another frequent problem when querying RDF data in the open is that some
properties from different vocabularies have a similar meaning (it even happens sometimes
in the same vocabulary). Since all variants are likely to be used in the data, queries
have to take all of them into account. A similar problem occurs when two properties
are defined to be inverse of each other, and can therefore be used indifferently (only by
changing the orientation of the arc). Managing this variability in common query
languages, like SPARQL [
One may argue that this problem can (or even should) be solved by inference rather than the presentation layer; indeed, an inference engine will recognize that foaf: depicts and foaf:img are, respectively, the inverse and a particular case of foaf: depiction. Should T4R be backed by such an inference engine (which is a possible use of T4R), the simple path foaf:depiction would be equivalent to the more complex path above. However, in practice, inference capabilities are not always available nor easy to add (if for example the data is accessed through a SPARQL endpoint without inference). Aiming to be usable as a lightweight solution, T4R must provide means to cope as well as possible with the absence of inference. The T4R keyword or is such a mean. 3.4
We have already encountered a T4R operator: any. Although all are not listed here
because of space limitations (the interested reader is referred to [
Section 4.3. 3.5
In all the examples given above, the path was evaluated relatively to an implicit resource (the resource being described by the template). Each CURIE in the path, including the first one, is interpreted as a property.
A path can also be evaluated relatively to the resource(s) stored in a variable (usually resulting from the previous evaluation of another path). In this case, the first item of the path is not a CURIE, but a variable name, for example
v/foaf:currentProject Since variable names in T4R can not contain a colon, there is no possible ambiguity with a CURIE5.
A third kind of paths are absolute paths. Those paths start with a slash, just like file or URL absolute paths. The first CURIE of such a path is not interpreted as a property, but as a resource. For example:
/foaf:Person/rdf:type:will retrieve all the instances of foaf:Person.
A simple example of the TAL language and the use of CURIE paths is given in Figure 2. Further example from the online demo are illustrated in Figure 3. <ul tal:define="global t4rns:foaf string:http://xmlns.com/foaf/0.1/"> <li tal:repeat="pe foaf:knows"> <span tal:content="pe/id">someone I know</span> works on: <ul> <li tal:repeat="pr pe/foaf:currentProject"> <a tal:attributes="href pr/foaf:homepage"
tal:content="pr/id">a project</a></li> </ul> <span tal:define="past pe/foaf:pastProject" tal:condition="past"> and also worked on <span tal:content="past/count">n</span> project(s) in the past.
</span> </li> </ul> as the first item of a path, while variables may only appear in first position.
As any typical rendering engine, a T4R processor combines a presentation specification (the template) with a data source (the RDF graph) into an output document. In this section, we will discuss noteworthy features of those three parts. 4.1
The RDF data source is provided to the T4R rendering engine as the URI of the resource to be rendered with the template. This URI is actually used for two distinct purposes: – identify the resource used to resolve relative paths, and – locate the RDF data.
Since it is not always the case that the URI of a resource gives access to the RDF data about that resource, it is possible to provide T4R with an alternative URL for retrieving RDF data. This URL can point to an RDF document, but other kinds of data sources are possible.
Follow your nose. The “Follow your nose” strategy consists in obtaining information about a resource by retrieving data from its URI, and from other resources known to be related to the former (e.g. with the rdfs:seeAlso property). That strategy has been included in our T4R application: using the special URL fyn: for the data source, the engine will retrieve data on demand from all intermediate resources involved in a path, and their related resources. Since this can lead to retrieve a lot of data, the number of queries that can be performed for one rendering can be bounded (this is the case for the online demo).
SPARQL endpoint. With the trend of Linked Data gaining momentum, an increasing number of data sources are available as SPARQL endpoints. Although our implementation does not yet provide support for SPARQL endpoint, we plan to add this feature in a near future. Furthermore, the design of the implementation has been guided with this aim: a path is not evaluated on the fly, but parsed until the end, then evaluated. That way, a long path can be converted into a small number (ideally one) of SPARQL queries rather than querying the SPARQL endpoint at each step of the path.
Inference-enabled data sources. As pointed out in section 3, T4R makes no assumption about the inference capabilities of the underlying data sources, and purposefully aims at making no such assumption. It is not impossible, however, to deploy T4R in a context where RDF stores or SPARQL endpoints are known to have such inference capabilities, shifting the burden of complex queries from the templates to the inference engine. Although we have not implemented it yet, we have a back-end architecture making such an evolution straightforward. 4.2
We have stated in section 2 that TAL was designed to produce HTML and XML documents, while we claimed in introduction that T4R is able to produce any textual document. This deserves more explanation.
Although TAL is mainly based on XML attributes, it also recognizes a special XML element: tal:block. This element is a placeholder for TAL attributes, but only its content, not the tag, is rendered in the output document. Its use is not encouraged, since it breaks the validity of the template with respect to the output format, but nevertheless necessary in some situations to produce a valid output document.
The current approach of T4R for producing non-XML text-based output documents is to: – exclusively use tal:block elements in the body of the template, – enclose it in an artificial XML element before processing, to make it a well-formed
XML document, – remove that artificial XML element after processing.
This solution is not very elegant: processing instructions in the template are quite verbose, requiring both the tal:block element and one of the TAL attributes. However, it was straightforward to implement and to use, and enlarges, almost for free, the scope of T4R.
Proposing alternative syntaxes for integrating TAL processing instructions in specific non-XML languages is a possibility. However, the burden for the user of learning another syntax may counteract the advantage of that syntax being more integrated to the target language. 4.3
Modularity is a key to scalability, hence a desirable feature for any open and web-based technology. T4R offers two levels of modularity: one at the path level, and one at the template level.
Path level modularity is a mere consequence of a standard feature of TAL that we have not presented yet: indirection. We saw that TAL allows the definition of variables. A special use of variables is to evaluate their content as elements of a path. Assume the following variable declaration:
IMG (note the TAL prefix string: indicating that the following text should not be evaluated, but considered as a literal string). This variable can now be dereferenced in any path using a leading question mark, avoiding the need to copy this long path multiple times. For example, the path:
foaf:knows/?IMG will retrieve all the images representing the people I know.
Template level modularity, on the other hand, is more specific to T4R. It is implemented with the renderWith binary operator, which must be followed by a CURIE path. For example, the following path: will use the resource template card.html, located at the URI associated with prefix lib, to render one of the people I know. Since templates can be located anywhere on the Web6, the number of retrieved templates can be bounded (like retrieved graphs with the “Follow your nose” strategy) to prevent overloading of the rendering engine.
Note also that any CURIE path (or variable indirection) can be used after the renderWith operator, allowing for complex selection of the template based on the resource itself. For example, the following TAL sample: tal:define = "p foaf:knows/any;
t p/rdf:type/ex:template_for:-/any/asPath" tal:content = "p/renderWith/?t" will store a person I know in variable p, then retrieve the URI of any template suitable for one of the declared type of that person and store it in t7, then use indirection to render p with that template. 5
The idea of using paths to query RDF is not new: see for example ARQ8, nSparql [
The reference in terms of RDF presentation is now Fresnel [
Compared to T4R, the strengths of Fresnel are also its weaknesses. Its model is quite complex and not practical for rapid prototyping of templates. Furthermore, the mapping from the abstract box model to concrete syntaxes being not specified in Fresnel, it is not a “ready to use” solution for application developers. In fact, we believe that T4R could be used to implement this missing step between Fresnel and concrete formats. Even more, provided some ad-hoc mechanisms to implement Fresnel selectors, we believe that (at least some part of) Fresnel could be implemented on top of T4R, following the method outlined in the end of section 4.3, since Fresnel lenses and formats are expressed in RDF. This would give an interesting hybrid rendering engine, allowing presentation knowledge to be gradually and seamlessly migrated from quickly hacked templates to cleanly designed lens and format groups. 6
In this paper, we have presented Tal4Rdf (T4R), a language for rendering RDF data in various XML and non-XML formats. Based on the proven TAL language, this uses an intuitive path-based language for retrieving RDF data and integrates well with output formats, both points providing it with a gentle learning curve and a suitability for rapid development. An open-source implementation and online demo are available at http: //champin.net/t4r/.
A number of planned or possible evolution have been presented in sections 4 and 5: alternative syntaxes for non-XML formats, integration with SPARQL endpoints and inference-enabled RDF back-ends, support for external queries and Fresnel selectors, and a possible T4R-based implementation of Fresnel.
Another interesting lead would be a better integration with RDFa [
The author would like to thank the reviewers for their constructive remarks, including references to some related works. 9 http://haystack.csail.mit.edu/ 10 http://www.w3.org/2001/11/IsaViz/