STTL

A SPARQL-based Transformation Language for RDF

Olivier Corby

and Catherine Faron-Zucker

Inria Sophia Antipolis M

editerran

ee, Valbonne, France

Univ. Nice Sophia Antipolis, I3S, Nice, France

Keywords:

RDF Transformation Language, SPARQL, STTL.

Abstract:

The general research question addressed in this paper is How to transform RDF into other languages. This

is of prime interest to present data selected and extracted from the Web of data in a format suitable for the

user (e.g., HTML or CSV). Moreover, RDF can be viewed as a meta-model to represent on the Web of

data other languages and models. The above research question then becomes How to generate the concrete

syntax of expressions of a given language from their RDF representation. To answer these questions, we

present SPARQL Template Transformation Language (STTL), a generic RDF transformation rule language,

independent from the output language. We conceived it as a lightweight syntactic extension to SPARQL

and we show how to compile it into standard SPARQL. We present a generic transformation rule engine

implementing STTL and several RDF transformers we deﬁned for various output languages, showing STTL’s

expressive power.

1 INTRODUCTION

The read-write Web is now providing us with a world-

wide blackboard where a hybrid society of users and

software agents exchange digital inscriptions. The

RDF standard (Cyganiak et al., 2014) provides us

with a general purpose graph-oriented data model rec-

ommended by the W3C to represent and interchange

data on the Web. While the potential of a world-wide

Semantic Web of linked data and linked data schemas

is now widely recognized, the transformation and pre-

sentation of RDF data is still an open issue. Among

the initiatives to answer this question there are exten-

sive works for providing RDF with several and var-

ied syntaxes: XML, N-Triples, Turtle, RDFa, TriG,

N-Quads, JSON-LD, CSV-LD, etc. But this is still a

partial view of the above problem.

Just like the structured Web has been provided

with the XSLT transformation language to present

XML data to the user into HTML pages or to trans-

form XML data from one XML schema into another

one or from an XML schema into any non XML

speciﬁc text format, for XML data interchange be-

tween agents and therefore interoperability, the Web

of data now requires a transformation language to

present RDF data to users and transform RDF data

from one RDF schema into another or transform data

from its RDF “syntax” into another one. Indeed, a

special case of RDF data holds a very special poten-

tial: RDF data encoding other formal languages. In

computer science, formal languages have been used

for instance to deﬁne programming languages, query

languages, data models and formats, knowledge for-

malisms, inference rules, etc. Among them, in the

early 2000’s, XML has gained the status of a meta-

language or syntax enabling to deﬁne so-called XML

languages. In the same way, we are now assisting to

the advent of RDF that will likely be more and more

used as a syntax to represent other languages. For in-

stance in the domain of the Semantic Web alone, this

is the case of three W3C standards: OWL 2 (Patel-

Schneider and Motik, 2012) is provided with sev-

eral syntaxes, among which the Functional syntax,

the Manchester syntax used in several ontology edi-

tors and RDF/XML and RDF/Turtle; the Rule Inter-

change Format (RIF) (Hawke and Polleres, 2012) is

provided with several syntaxes among which a ver-

bose XML syntax, two compact syntaxes for RIF-

BLD and RIF-PRD and an RDF syntax; SPARQL In-

ference Notation (SPIN) is a W3C member submis-

sion (Knublauch, 2011) to represent SPARQL rules

in RDF, to facilitate storage and maintenance. Many

other languages can (and will) be “serialized” into

RDF. For instance (Follenfant et al., 2012) is an at-

466

Corby O. and Faron-Zucker C..

STTL - A SPARQL-based Transformation Language for RDF.

DOI: 10.5220/0005450604660476

In Proceedings of the 11th International Conference on Web Information Systems and Technologies (WEBIST-2015), pages 466-476

ISBN: 978-989-758-106-9

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

tempt to represent SQL expressions in RDF.

As a result of this emerging trend to use RDF

as a “syntax” or a meta-language for other Web lan-

guages, just like XML ten years earlier, the trans-

formation of RDF data into various output formats,

various concrete syntaxes, becomes a major issue.

Regarding the RDF/XML syntax of RDF, one could

think that XSLT is a good candidate to declaratively

express RDF transformations. However, writing of

XSLT templates for RDF would be based on its XML

syntax and not the graph structure and semantics of

RDF model — the transformation rules would depend

on the concrete XML syntax of RDF instead of its

semantics—, which would make the writing of the

transformation quite difﬁcult. Moreover, the many

potential serializations of any given RDF statement

would make the writing XSLT templates for RDF

even more complex.

In this paper we address the latter problem of

transforming RDF data, i.e., generating the concrete

syntax of expressions of a given language from their

RDF representation. More generally, the research

question addressed in this paper is How to transform

RDF data into other languages? We answer two sub-

questions: (1) How to write declarative transforma-

tion rules from RDF to other languages? (2) How to

make the approach generic, i.e the rule language in-

dependent from the output language?

We show how SPARQL (Harris and Seaborne,

2012) can be used as a generic transformation rule

language for RDF, independent from the output lan-

guages. We deﬁne an RDF transformer as a set of

transformation rules processed by a generic transfor-

mation rule engine. We present SPARQL Template

Transformation Language (STTL), a lightweight syn-

tactic extension to SPARQL enabling the writing of

transformation rules.

In section 2 we present existing transformation

languages for RDF. In section 3 we present STTL, a

syntactic extension to SPARQL enabling the writing

of RDF transformation rules. In section 4 we present

the generic transformation rule engine we developed

to implement STTL. In section 5 we show the expres-

sive power of STTL through several RDF transform-

ers we deﬁned for various output languages.

2 RELATED WORK

XSLT (Kay, 2007) is a pioneer rule-based transforma-

tion language for XML. An XSLT stylesheet is a set

of transformation rules, called templates, which en-

ables to transform any XML document conform to a

given model, i.e., to which the templates apply. An

XPath expression identiﬁes the XML subtrees (their

roots) for which a template applies, and the content

of the template describes the transformation and its

output. XSLT could be used to process and display

RDF/XML data in any output format. For instance

the following XSLT template could be used to trans-

form RDF triples into an HTML table row.

<xsl:template

match=’rdf:Description[@rdf:about]’>

<xsl:for-each select=’./*’>

<xsl:value-of select=’../@rdf:about’/>

</td>

</td>

<xsl:with-param name=’v’ select=’.’/>

</xsl:call-template>

</td> </tr>

</xsl:for-each>

</xsl:template>

However RDF/XML syntax is too versatile and less

and less used and, most of all, writing XSLT tem-

plates for it would be very complex considering the

many potential serializations of an RDF statement:

the transformation rules would depend on the con-

crete XML syntax of RDF instead of its semantics.

GRDDL (Connolly, 2007) is a mechanism for ex-

tracting RDF data from XML documents. A GRDDL

proﬁle is associated to an XSLT stylesheet and can

be speciﬁed in any XML document conform to the

targeted model or dialect to order GRDDL agents

to extract RDF data from it. GRDDL could then

be used to extract RDF data from RDF data in RD-

F/XML syntax. However this W3C recommandation

has never really been adopted and, like XSLT, this

solution would rely on the many concrete XML syn-

taxes of RDF instead of its semantics.

OWL-PL (Brophy and Heﬂin, 2009) is an ex-

tension of XSLT for transforming RDF/OWL into

XHTML. It provides an adaptation of XSLT pro-

cessing of XML trees to RDF graphs. In particular,

it matches properties of resources instead of XML

nodes through XPath. OWL-PL is both tied to its RD-

F/XML input format, like XSLT. Xenon (Quan, 2005)

is another ontology for specifying in RDF how RDF

resources should be presented to the user. It reuses

many of the key ideas of XSLT, among which tem-

plates, and deﬁnes a so-called RDF Stylesheet lan-

guage. Xenon’s two foundational concepts are lenses

and views. Lenses specify which properties of an

RDF resource are displayed and how these properties

are ordered; views specify how they are displayed.

STTL-ASPARQL-basedTransformationLanguageforRDF

467

PersonLens a fresnel:Lens ;

fresnel:classLensDomain foaf:Person ;

fresnel:showProperties

( foaf:name foaf:mbox foaf:depiction ).

:nameFormat a fresnel:Format ;

fresnel:label "Name" ;

fresnel:propertyFormatDomain foaf:name .

Figure 1: A Fresnel RDF graph describing a presentation

format for RDF data on persons.

Both OWL-PL and Xenon are tied to a speciﬁc dis-

play paradigm and an XHTML-like output format.

Fresnel (Bizer et al., 2005) is an RDF vocabu-

lary for specifying in RDF which data contained in

an RDF graph should be displayed and how. Fres-

nel’s two foundational concepts are lenses and for-

mats. Fresnel’s formats generalize Xenon’s views.

Figure 1 presents a Fresnel RDF graph describing a

presentation format for RDF data on persons: a lense

speciﬁes that for each person, her name, mbox and

picture should be displayed and a format speciﬁes

how to display her name.

SPARQL is provided with a CONSTRUCT query

form which enables to extract and transform RDF

data into any other schema. A CONSTRUCT query re-

turns an RDF graph speciﬁed by a graph template in

the CONSTRUCT clause of the query and built by sub-

stituting the variables in the graph template with the

solutions to the WHERE clause.

(Alkhateeb and Laborie, 2008) addresses the

problem of generating XML from RDF data with an

extended SPARQL query. A SPARQL query is given

a template of XML document where variables are fed

with the query results. The SPARQL CONSTRUCT

clause is overloaded to refer to an XML template with

reference to SPARQL query variables that are bound

by a standard WHERE clause.

XSPARQL (Bischof et al., 2012) is a combination

of SPARQL and XQuery (Robie et al., 2014) enabling

to query both XML and RDF data and to transform

data from one format into the other. XPARQL in-

tegrates within XQuery the SPARQL WHERE clause

to facilitate the selection of RDF data to transform it

into XML and, conversely, the SPARQL CONSTRUCT

clause to facilitate the construction of RDF graphs

from some extracted XML data. For instance the XS-

PARQL statements in FIgure 2 enable to select RDF

data on persons and transform it into an XML tree de-

scribing relations between persons.

Finally, there are quite a wide range of RDF

parsers and validators

, some of which enable to

transform RDF data from one serialization format to

http://www.w3.org/2001/sw/wiki/Category:Tool

declare foaf="http://xmlns.com/foaf/0.1/";

<relations> {

for $Person $Name from <relations.rdf>

where {$Person foaf:name $Name}

order by $Name

return

<person name = "{$Name}"> {

for $FName

where {$Person foaf:knows $Friend .

$Friend foaf:name $FName}

return <knows>{$FName}</knows> }

</person> }

</relations>

Figure 2: XSPARQL statements to select RDF data on per-

sons and transform it into an XML tree describing relations

between persons.

another. Among them, let us cite RDF Distiller

and

RDF Translator

. A review of these RDF-to-RDF

converters can be found in (Stolz et al., 2013). An-

other famous example of speciﬁc-purpose RDF trans-

former is the RDF/XML parser in OWL API

(Hor-

ridge and Bechhofer, 2011) which enable to transform

OWL 2 statements in RDF/XML into the Functional

syntax of the language.

To sum up, the state-of-the-art solutions presented

in this section to transform RDF data are all tied to

either an RDF/XML input syntax or to a speciﬁc out-

put format, or both — except Fresnel. But Fresnel

focuses on the presentation of RDF data and does not

handle the general problem of the transformation of

RDF data. In the following, we present a generic ap-

proach for writing RDF transformers for any output

language.

3 SPARQL TEMPLATE

TRANSFORMATION

LANGUAGE

SPARQL Template Transformation Language

(STTL) is a generic transformation rule language for

RDF based on SPARQL. It relies on two extensions

of SPARQL: an additional TEMPLATE query form to

express transformation rules and extension functions

to recursively call the processing of a template into

another one. Section 3.1 summerizes the key features

of SPARQL and sections 3.2 and 3.3 present the

extensions of SPARQL in STTL. Section 3.4 presents

STTL syntax; section 3.5 presents the compilation

http://rdf.greggkellogg.net/distiller

http://rdf-translator.appspot.com/

http://owlapi.sourceforge.net/

WEBIST2015-11thInternationalConferenceonWebInformationSystemsandTechnologies

468

of STTL into standard SPARQL; and section 3.6

presents STTL semantics. Finally, section 3.7

compares STTL to XSLT.

3.1 SPARQL

SPARQL is the query language for RDF recom-

mended by W3C. It has a SQL-like syntax (SELECT

FROM WHERE) and is a graph pattern matching lan-

guage. A SPARQL query is a set of triple patterns

that are RDF triples (in Turtle syntax) which may hold

variables. A query may also have operators such as

ﬁlter, conjunction, union, optional, minus, etc. An

example of SPARQL query searching resources with

name “Olivier” which are linked to other resources

with a knows property is shown below:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

SELECT * WHERE {

?x foaf:name "Olivier" ;

foaf:knows ?y .

FILTER (?x != ?y) }

SPARQL is also provided with a CONSTRUCT

WHERE query form the result of which is a graph.

The CONSTRUCT clause speciﬁes a graph pattern with

variables which are replaced by the values found in

the solutions of the WHERE clause in order to create

a graph. For instance, the following SPARQL query

enables to construct the RDF graph of foaf:knows

inverse relations between the resources of the original

RDF graph.

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

CONSTRUCT {

?y foaf:knows ?x }

WHERE {

?x foaf:knows ?y }

3.2 SPARQL Template Query Form

STTL relies on two extensions of SPARQL: an ad-

ditional TEMPLATE query form and extension func-

tions such as st:apply-templates to process a set

of templates.

A TEMPLATE query is made of a standard WHERE

clause and a TEMPLATE clause. The WHERE clause

is the condition part of a rule, specifying the nodes in

the RDF graph to be selected for the transformation.

The TEMPLATE clause is the presentation part of the

rule, specifying the output of the transformation for

the RDF statements matching the condition.

For instance, let us consider the OWL 2 axiom

stating that the class of men and the class of women

are disjoint. Here is its expression in Functional syn-

tax: DisjointClasses(a:Man a:Woman); and here

it is in Turtle: a:Man owl:disjointWith a:Woman.

The following template enables to transform the

above RDF statement into the corresponding state-

ment in Functional syntax.

TEMPLATE {

"DisjointClasses(" ?in " " ?c ")" }

WHERE { ?in owl:disjointWith ?c }

The WHERE clause matches the RDF statement and

enables to select the subject and object of property

owl:disjointWith and to bind them to variables

?in and ?c. The TEMPLATE clause speciﬁes the result

that must be generated using the solution sequence of

the WHERE clause. Variables in the TEMPLATE clause

are replaced by their value displayed in the Turtle syn-

tax.

The value of a variable may be a blank node that

represents another OWL statement, e.g., a Restriction.

In this case, we would like to display not the blank

node itself but the target OWL statement. This can be

done using another template.

3.3 SPARQL Template Extension

Functions

Let us now consider the OWL 2 axiom stating that the

class of parents is equivalent to the class of individu-

als having a person as child. Here are its expressions

in Functional syntax and in Turtle:

EquivalentClasses(

a:Parent

ObjectSomeValuesFrom(a:hasChild a:Person))

a:Parent a owl:Class ;

owl:equivalentClass

[ a owl:Restriction ;

owl:onProperty a:hasChild ;

owl:someValuesFrom a:Person ]

The following template enables to transform the

above RDF statement into the corresponding Func-

tional statement.

TEMPLATE {

"EquivalentClasses("

st:apply-templates(?in) " "

st:apply-templates(?c) ")" }

WHERE { ?in owl:equivalentClass ?c . }

The value matching variable ?in is a:Parent which

is expected in the transformation output (the Func-

tional syntax of the OWL 2 statement), while the

value matching variable ?c is a blank node whose

property values are used to build the expected output.

This is deﬁned in another template to be applied

on this focus node. The st:apply-templates ex-

tension function

enables this recursive call of tem-

Named in reference to XSLT xsl:apply-templates

STTL-ASPARQL-basedTransformationLanguageforRDF

469

plates, where st is the preﬁx of STTL namespace:

<http://ns.inria.fr/sparql-template/>. In

other words, hierarchical processing is done using

the st:apply-templates function in the TEMPLATE

clause. It returns the result of the application of other

templates to the focus nodes. The result is concate-

nated in the TEMPLATE clause. Hence, nested tem-

plates processing is performed by dynamic calls to

st:apply-templates.

According to the deﬁnition of

PrimaryExpression in SPARQL grammar, both

SPARQL functions and extension functions can be

used in TEMPLATE clauses. The following SPARQL

extension functions have been deﬁned to process a

transformation:

• st:apply-templates(term) calls the trans-

former on a focus node term and executes one

template;

• st:call-template(name, term) calls a tem-

plate by its name on a focus node term;

• st:apply-templates-with(uri, term) calls

the transformer speciﬁed by uri on a focus node

term and executes one template;

• st:call-template-with(uri, name, term)

calls a template by its name, on a focus node with

a speciﬁed transformer;

• st:apply-templates-all(term) calls the

transformer on a focus node term and executes

all templates; it returns the concatenation of the

results.

Some additional utilitary extension functions have

been deﬁned, among which:

• st:turtle(term) returns the Turtle form of an

RDF term;

• st:define(), st:process() and

st:default() enable to parameterize the

transformation behaviour when used in the

predeﬁned templates presented in section 4.4.

3.4 Syntax

Figure 3 presents STTL’s grammar. It is based

on SPARQL 1.1’s grammar

. In the deﬁni-

tion of Template, Prologue, DatasetClause,

WhereClause, SolutionModifier and

ValuesClause are those deﬁned in SPARQL

grammar. In the deﬁnition of TemplateClause,

iri is a template name. In the deﬁnition of Term,

PrimaryExpression is that deﬁned in SPARQL

http://www.w3.org/TR/sparql11-

query/#sparqlGrammar

Template ::= Prologue TemplateClause

DatasetClause* WhereClause

SolutionModifier ValuesClause

TemplateClause ::=

’TEMPLATE’ (iri VarList ?) ?

’{’ Term* Separator? ’}’

VarList ::= ’(’ Var+ ’)’

Term ::= PrimaryExpression | Group

Group ::= ’GROUP’ ’DISTINCT’? ’{’

PrimaryExpression* Separator? ’}’

Separator ::= ’;’ ’separator’ ’=’ String

Figure 3: STTL grammar.

grammar and Group is syntactic sugar for SPARQL

GROUP CONCAT aggregate, enabling an easier

writing of aggregation with several arguments.

Separator enables to deﬁne the separator of ag-

gregates; by default, it is the space character for

Group (see Section 3.5) and the newline character for

TemplateClause (see Section 3.6).

3.5 Compilation into Standard

SPARQL

A template can be compiled into a standard SPARQL

query of the SELECT form. The compilation keeps the

WHERE clause, the solution modiﬁers and the VAL-

UES clause of the template unchanged and the TEM-

PLATE clause is compiled into a SELECT clause. Here

is the compilation scheme of a TEMPLATE clause into

a SELECT clause:

(1) cp(TemplateClause(

Term(t1), ... Term(tn), sep)) =

SELECT (CONCAT(cp(t1), ... cp(tn))

AS ?out)

(2) cp(Group(Term(t1), ... Term(tn), sep)) =

GROUP_CONCAT(CONCAT(cp(t1), ... cp(tn)),

sep)

(3) cp(Var(v)) = st:process(v)

(4) cp(PrimaryExpression(if(e1, e2, e3))) =

if(e1, cp(e2), cp(e3))

(5) cp(PrimaryExpression(e)) = e

Basically, a recursive function cp compiles a TEM-

PLATE clause by concatenating the compilation of its

terms by a call to function CONCAT (1). A GROUP is

syntactic sugar for GROUP CONCAT aggregate (2); a

variable v in a TEMPLATE clause is compiled into the

WEBIST2015-11thInternationalConferenceonWebInformationSystemsandTechnologies

470

st:process(v) function call (3); if function call ar-

guments are compiled except the condition which is

left unchanged (4); other primary expressions are left

unchanged (5).

For instance, by applying the above scheme, the

following STTL expression:

TEMPLATE {

"ObjectAllValuesFrom(" ?p " " ?c ")" }

WHERE {

?in a owl:Restriction ;

owl:onProperty ?p ;

owl:allValuesFrom ?c }

is compiled into the following SPARQL query:

SELECT

(CONCAT("ObjectAllValuesFrom(",

st:process(?p), " ",

st:process(?c), ")") AS ?out)

WHERE {

?in a owl:Restriction ;

owl:onProperty ?p ;

owl:allValuesFrom ?c }

3.6 Evaluation Semantics

Since STTL can be compiled into standard SPARQL

1.1, the evaluation semantics of a template is that

of SPARQL

. Let Ω the solution sequence resulting

from the evaluation of the SPARQL query resulting

itself from the compilation of a template. If the solu-

tion sequence is empty, the template fails. Otherwise,

we deﬁne the result of the evaluation of a template as

the result of the Aggregation operator of SPARQL

Algebra

with the following arguments:

Aggregation((?out), GROUP CONCAT,

scalarvals, {1 -> Ω})

where scalarvals corresponds to the sep argument

in the TEMPLATE clause. Matching the graph pattern

in the WHERE clause of a template may return several

solutions: Ω is a solution sequence. However, the

result of the evaluation of a template is unique: the

solutions in Ω are aggregated with a GROUP CONCAT

aggregate. The result of the template is the result of

the GROUP CONCAT.

3.7 Comparison of STTL and XSLT

STTL and XSLT are quite similar in their functional-

ities and expressiveness. The key difference between

http://www.w3.org/TR/sparql11-

query/#sparqlAlgebraEval

http://www.w3.org/TR/sparql11-

query/#aggregateAlgebra

both languages is that XSLT operates on a XML (or-

dered) tree whereas STTL operates on an RDF (un-

ordered) graph. Then, a XSLT template can match

several patterns in the body whereas in a STTL tem-

plate, there is one multiset of solutions resulting from

the evaluation of one WHERE clause.

STTL inherits all SPARQL 1.1 statements, includ-

ing Property Path and service which enables to per-

form Linked Data transformation on remote graphs.

4 IMPLEMENTATION

We implemented a SPARQL Template Transforma-

tion engine within the Corese Semantic Web Factory

(Corby et al., 2012; Corby and Faron-Zucker, 2010).

Basically, it is called by the st:apply-templates

extension function, or any other transformation func-

tions introduced in section 3.3. Given an RDF graph

with a focus node to be transformed and a list of tem-

plates, the transformation engine successively tries to

apply them to the focus node until one of them suc-

ceeds. A template succeeds if the matching of the

WHERE clause succeeds, i.e., returns a result.

4.1 Algorithm

Here is the core algorithm of the

st:apply-templates function in pseudocode:

(1) Node st:apply-templates(Node node) {

(2) for (Query q : getTemplates()) {

(3) Mappings map = eval(q, IN, node);

(4) Node res = map.getResult(OUT);

(5) if (res != null) return res; }

(6) return st:default(node); }

Templates are selected (2) and tried (3) one by one

until one of them returns a result (4-5). In other

words, a template is searched whose WHERE clause

matches the RDF graph with the binding of the fo-

cus node to variable IN. If no template succeeds,

the st:default function is applied to the node (6).

Recursive calls to st:apply-templates implements

the graph recursive traversal with successive focus

nodes: eval (3) runs templates that recursively call

the st:apply-templates function.

In addition to the above pseudocode, the trans-

former checks loops in case the RDF graph is a cyclic

graph. It keeps track of the templates applied to nodes

in order to avoid applying the same template on the

same node twice. If no fresh template exists for a fo-

cus node, the transformer returns the value returned

by a call to the st:default function.

http://wimmics.inria.fr/corese

STTL-ASPARQL-basedTransformationLanguageforRDF

471

A call to any other transformation functions intro-

duced in section 3.3 triggers a similar algorithm.

4.2 Dynamic Variable Binding

When matching the WHERE clause of a template with

the RDF graph, the SPARQL query evaluator is called

with a binding of variable IN (?in in the WHERE

clause) with the focus node to be transformed. When

processing templates, the SPARQL interpreter must

then be able to perfom dynamic binding to trans-

mit the focus node. This dynamic value binding

can be implemented in SPARQL with an extension

function st:getFocusNode() that retrieves the fo-

cus node from the environment and a SPARQL BIND

clause to bind it to the ?in variable in the WHERE

clause: BIND(st:getFocusNode() AS ?in). The

same scheme can be used for named templates with

arguments.

4.3 Template Selection

By default, the transformation engine considers tem-

plates in order: given a focus node, in response

to a call to the st:apply-templates function, it

considers the ﬁrst template that matches this node.

Hence, the result of the transformation of the fo-

cus node is the result of this template. Named tem-

plates can be chosen to be processed by a call to the

st:call-template function.

In some cases, it is worth writing several tem-

plates for a type of focus node, in particular when

the node holds different graph patterns that should be

transformed according to different presentation rules.

Executing several templates on the focus node is done

by calling the st:apply-templates-all function in

the TEMPLATE clause. The result of the transforma-

tion is the concatenation of the results of the success-

ful templates.

A transformer can be used to transform a

whole RDF graph — without any distinguished

root node in the graph. For this purpose, the

st:apply-templates- with function can be called

without focus node and the transformer must then de-

termine it. By default, the ﬁrst template that succeeds

is the starting point of the transformer; or a st:start

named template can be deﬁned to be executed ﬁrst

(see Section 4.4).

4.4 Transformer Setting

Our implementation of STTL enables to simply set a

special default template selection behavior for a set of

templates deﬁning a transformer, by deﬁning two spe-

cial named templates: st:start and st:default.

The st:start template, if any, is selected at the be-

ginning of the transformation process when no focus

node is available. In that case, it is the ﬁrst template

executed by the template engine. The st:default

template, if any, is executed when all templates fail to

match the focus node.

The processing of a variable in the TEMPLATE

clause by default consists in outputting its value in

the Turtle format. A speciﬁc template, st:profile,

can be used to overload this default transformation

behaviour. For example, the following deﬁnition

of st:profile speciﬁes that processing any vari-

able, denoted by st:process(?x), consists in the

application of the st:apply-templates function to

it and that, in case no template applies, its default

processing, denoted by st:default(?x), should be

the output of its string value, denoted by str(?x),

instead of the by default Turtle syntax, output by

st:turtle(?x).

TEMPLATE st:profile {

st:define( st:process(?x) =

st:apply-templates(?x) )

st:define( st:default(?x) = str(?x) ) }

WHERE { }

5 VALIDATION WITH SPECIFIC

RDF TRANSFORMERS

In our approach of RDF transformation based on

SPARQL templates, the template processor is com-

pletely generic: it applies to any RDF data or any lan-

guage or model provided with an RDF syntax. What

is speciﬁc to each output language or format is the set

of transformation rules deﬁned for it. In other words,

each transformer speciﬁc to an output format is a spe-

ciﬁc set of templates processed by the generic tem-

plate processor implementing STTL.

In this section we present speciﬁc transformers

available online

which validate both STTL and our

implementation of a generic STTL processor. The

applications of STTL are many and varied. A ﬁrst

family of applications deals with the presentation of

RDF data into speciﬁc syntaxes, e.g., Turtle, (see Sec-

tion 5.1), or presentation formats, e.g., HTML (see

Section 5.2), or any other format answering speciﬁc

needs. As a result, STTL answers all the applica-

tion scenarii addressed in the related work. A sec-

ond family of applications deals with the transforma-

tion of statements of a given language represented

http://ns.inria.fr/sparql-template

WEBIST2015-11thInternationalConferenceonWebInformationSystemsandTechnologies

472

in RDF syntax, e.g., OWL (see Section 5.3), or any

other special purpose language with an RDF syntax.

A third family of applications deals with the transla-

tion of RDF into other languages, e.g., RDF-to-CSV

(see Section 5.2), or any translation X-to-Y of lan-

guages with RDF syntaxes.

5.1 RDF-to-RDF/Turtle Transformer

The following single STTL template enables to output

RDF data in Turtle syntax.

TEMPLATE {

?x "\n"

GROUP { ?p " " ?y ; separator = ";\n" }

"." }

WHERE { ?x ?p ?y }

GROUP BY ?x

In a similar way, it is easy to write a transformer for

each of RDF syntaxes.

5.2 RDF to HTML

We implemented a generic transformation to trans-

late SPARQL query results into HTML. CONSTRUCT

query returns an RDF graph whereas SELECT query

result is translated in RDF using W3C DAWG result-

set RDF vocabulary

which is a RDF version of

SPARQL Query Results XML format.

The template below generates table cells for vari-

able bindings:

prefix rs:

<http://www.w3.org/2001/sw/

DataAccess/tests/result-set#>

TEMPLATE {

"<td>"

COALESCE(

st:call-template(st:display, ?val),

" ")

"</td>" ; separator = " "

}

WHERE {

?x rs:solution ?in

?x rs:resultVariable ?var

OPTIONAL {

?in rs:binding [

rs:variable ?var ; rs:value ?val ]

}

ORDER BY ?var

http://www.w3.org/2001/sw/DataAccess/tests/result-

set

Such RDF to HTML transformation enabled us to

design a light weight Semantic Web Hypertext Nav-

igator

on top of a local dataset as well as a remote

dataset such as DBpedia. The transformer is embed-

ded in a Web server, that is a SPARQL endpoint aug-

mented with a transformation engine. The transfor-

mation engine is accessible at a speciﬁc URI on the

server. Given a resource URI, the transformation re-

trieves a description of the resource in the dataset and

generates a HTML page accordingly. In the HTML

page, references to related resource URI are displayed

as hypertext links to the Web server.

5.3 OWL 2 Pretty-printer

We wrote a transformation generating OWL 2 expres-

sions in functional syntax from OWL 2 expressions in

RDF syntax as a set of 48 STTL templates.

We validated it on the OWL 2 Primer complete

sample ontology

containing 350 RDF triples. To

validate the result of the transformation, we loaded

the output produced in OWL Functional syntax into

Prot

e and did a complete cycle of transformation

(save to RDF/XML, load and transform again) and

we checked that the results were equivalent. Let us

note that the results are equivalent and not identi-

cal because some statements are not printed in the

same order, due to the fact that Prot

e does not save

RDF/XML statements exactly in the same order and

hence blank nodes are not allocated in the same order.

We tested this OWL/RDF transformer on several

real world ontologies, among which a subset of the

Galen ontology. The RDF graph representing it con-

tains 33080 triples, the size of the result is 0.58 MB

and the (average) transformation time is 1.75 seconds.

We also have tested our pretty-printer on the HAO on-

tology. The RDF graph representing it contains 38842

triples, the size of the result is 1.63 MB, the (average)

pretty-print time is 3.1 seconds.

In addition to the transformation of an RDF

dataset representing OWL statements, this trans-

former can also be used when querying an OWL on-

tology stored in its RDF syntax, to present the re-

sults to the user in OWL 2 Functional syntax. This is

done by calling in the SELECT clause of the query one

of the extension functions launching the transformer.

As an example, the following query retrieves speciﬁc

classes of the ontology and displays them in Func-

tional syntax:

SELECT

(st:apply-templates-with(st:owl, ?x)

http://corese.inria.fr

http://www.w3.org/TR/owl2-primer

STTL-ASPARQL-basedTransformationLanguageforRDF

473

as ?t)

WHERE {

?x a owl:Class ;

rdfs:subClassOf* f:Human }

5.4 Example of an Entire STTL

Transformation

In this section we detail the execution of the OWL

transformation

on the following OWL/RDF state-

ment:

a:Parent owl:equivalentClass [

a owl:Restriction ;

owl:onProperty a:hasChild ;

owl:someValuesFrom a:Person

]

The transformation engine ﬁrst searches a template

that matches the owl:equivalentClass statement.

Here is the retrieved template:

TEMPLATE {

if (bound(?t), "DatatypeDefinition",

"EquivalentClasses")

"("

if (?iu,

st:call-template(st:interunion, ?in),

?in)

" " ?y

")"

}

WHERE {

?in owl:equivalentClass ?y

BIND (EXISTS {

?in owl:intersectionOf|owl:unionOf ?z}

as ?iu)

OPTIONAL { ?y a ?t

FILTER(?t = rdfs:Datatype) }

}

The TEMPLATE clause is compiled to:

SELECT

(concat(

if (bound(?t), "DatatypeDefinition",

"EquivalentClasses"),

"(",

if (?iu,

st:call-template(st:interunion, ?in),

st:process(?in)),

" ", st:process(?y),

")")

as ?out)

http://ns.inria.fr/sparql-template/owl

The WHERE clause of this template succeeds with the

following bindings, where :b is the blank node of

type owl:Restriction:

?in = a:Parent ;

?y = _:b ;

?iu = false .

The TEMPLATE clause then evaluates its arguments:

• The ?t variable is not bound, hence the ﬁrst ex-

pression evaluates to "EquivalentClasses".

• The ?iu variable value is false, hence the second

expression evaluates to st:process(?in).

The following SELECT clause is eventually evaluated:

SELECT (CONCAT("EquivalentClasses", "(",

st:process(?in), " ", st:process(?y),

")") AS ?out).

st:process(?in) with ?in bound to IRI a:Parent

then returns a:Parent. st:process(?y) with ?y

bound to blank node :b of type owl:Restriction,

subject of properties owl:onProperty and

owl:someValuesFrom, then searches a template

that matches such statements. Here is the retrieved

template:

TEMPLATE {

if (bound(?t1) || bound(?t2),

"DataSomeValuesFrom",

"ObjectSomeValuesFrom")

"(" ?p " " ?z ")"

}

WHERE {

?in owl:someValuesFrom ?z ;

owl:onProperty ?p

OPTIONAL { ?z a ?t1

FILTER(?t1 = rdfs:Datatype) }

OPTIONAL { ?p a ?t2

FILTER(?t2 = owl:DatatypeProperty) }

}

The TEMPLATE clause is compiled to:

SELECT

(concat(

if (bound(?t1) || bound(?t2),

"DataSomeValuesFrom",

"ObjectSomeValuesFrom"),

"(", st:process(?p), " ", st:process(?z), ")"

as ?out)

The WHERE clause of this template succeeds with the

following bindings:

?in = _:b ;

?z = a:Person ;

?p = a:hasChild

The TEMPLATE clause of the above template then

evaluates its arguments: variables ?t1 and ?t2 are

WEBIST2015-11thInternationalConferenceonWebInformationSystemsandTechnologies

474

not bound, hence the ﬁrst expression evaluates to

"ObjectSomeValuesFrom".

The following SELECT clause is eventually evaluated:

SELECT (CONCAT("ObjectSomeValuesFrom",

"(", st:process(?p), " ", st:process(?z),

")") AS ?out).

As ?p and ?z both are bound to URIs, the evalua-

tion of st:process(?p) and st:process(?z) even-

tually returns the Turtle format of these URI. The re-

sult of the above SELECT clause and therefore of the

template is then the string:

"ObjectSomeValuesFrom(a:hasChild a:Person)"

As there is only one result, the ﬁnal

group concat(?out) aggregate does not change it.

This result is returned to the ﬁrst template as the value

of st:process(?y) in its SELECT clause . The result

of this SELECT clause and therefore of the ﬁrst tem-

plate is then the following string:

"EquivalentClasses(a:Parent

ObjectSomeValuesFrom(a:hasChild a:Person))"

This is precisely the expression in OWL Func-

tional syntax of the example of OWL statement cho-

sen as input to illustrate the STTL transformation.

6 CONCLUSION AND FUTURE

WORK

In this paper we considered two related problems: (1)

the transformation of RDF to present RDF data to

users, e.g., into a HTML domain or application de-

pendant format, and (2) the transformation of RDF

when it is used as a meta-model to represent on the

Web other languages and their abstract graph struc-

ture. We addressed the general problem of trans-

forming RDF into other languages. We answered

this question by specifying STTL, a generic and do-

main independent extension to SPARQL to support

the declarative representation of any special-purpose

RDF transformation as a set of transformation rules.

Being based on SPARQL, STTL inherits its expres-

sivity and its extension mechanisms. This speciﬁca-

tion and the algorithms we described have been im-

plemented and tested in a generic transformation rule

engine part of the Corese Semantic Web Factory plat-

form (Corby et al., 2012; Corby and Faron-Zucker,

2010). This means all these results are part of this

open-source platform. We demonstrated the feasi-

bility and genericity of our approach by providing

several transformations including: RDF-to-RDF syn-

taxes, RDF-to-HTML, RDF OWL 2-to-OWL 2 Func-

tional syntax.

As future work, regarding the performances of our

generic transformation rule engine, we intend to im-

prove them by implementing heuristics to optimize

the selection of templates. We should compare in the

short term the performance of our generic transforma-

tion rule engine with that of existing tools for speciﬁc

RDF transformations. For instance, we may compare

the performance of our engine with that of the parser

of the well known OWL API

for transforming large

OWL 2 ontologies from RDF/XML syntax into Func-

tional syntax.

Regarding the exploitation of our generic trans-

formation rule engine to implement RDF transform-

ers into speciﬁc languages, we intend to augment the

number of STTL transformations available by writing

rule sets for other formats and domains. In the cases

where the TEMPLATE clauses of the transformation

rules produce RDF triples (as text), we deﬁne RDF-

to-RDF transformations with SPARQL Template. In

particular, we envisage implementing a special case

of RDF-to-RDF transformation to anonymize RDF

datasets.

REFERENCES

Alkhateeb, F. and Laborie, S. (2008). Towards Extending

and Using SPARQL for Modular Document Genera-

tion. In Proc. of the 8th ACM Symposium on Docu-

ment Engineering, pages 164–172, Sao Paulo, Br

esil.

ACM Press.

Bischof, S., Decker, S., Krennwallner, T., Lopes, N., and

Polleres, A. (2012). Mapping between RDF and XML

with XSPARQL. J. Data Semantics, 1(3):147–185.

Bizer, C., Lee, R., and Pietriga, E. (2005). Fresnel -

A Browser-Independent Presentation Vocabulary for

RDF. In Second International Workshop on Interac-

tion Design and the Semantic Web @ ISWC’05, Gal-

way, Ireland.

Brophy, M. and Heﬂin, J. (2009). OWL-PL: A Presenta-

tion Language for Displaying Semantic Data on the

Web. Technical report, Department of Computer Sci-

ence and Engineering, Lehigh University.

Connolly, D. (2007). Gleaning Resource Descriptions from

Dialects of Languages (GRDDL). Recommendation,

W3C. http://www.w3.org/TR/grddl/.

Corby, O. and Faron-Zucker, C. (2010). The KGRAM Ab-

stract Machine for Knowledge Graph Querying. In

IEEE/WIC/ACM International Conference on Web In-

telligence, Toronto, Canada.

Corby, O., Gaignard, A., Faron-Zucker, C., and Montagnat,

J. (2012). KGRAM Versatile Data Graphs Querying

and Inference Engine. In Proc. IEEE/WIC/ACM In-

ternational Conference on Web Intelligence, Macau.

http://owlapi.sourceforge.net/

STTL-ASPARQL-basedTransformationLanguageforRDF

475

Cyganiak, R., Wood, D., and Lanthaler, M. (2014). RDF

1.1 Concepts and Abstract Syntax. Recommendation,

W3C. http://www.w3.org/TR/rdf11-concepts/.

Follenfant, C., Corby, O., Gandon, F., and Trastour, D.

(2012). RDF Modelling and SPARQL Processing of

SQL Abstract Syntax Trees. In Programming the Se-

mantic Web, ISWC Workshop, Boston, USA.

Harris, S. and Seaborne, A. (2012). SPARQL

1.1 Query Language. Recommendation, W3C.

http://www.w3.org/TR/sparql11-query/.

Hawke, S. and Polleres, A. (2012). RIF In RDF. Working

Group Note, W3C. http://www.w3.org/TR/rif-in-rdf/.

Horridge, M. and Bechhofer, S. (2011). The OWL API: A

java API for OWL ontologies. Semantic Web, 2(1):11–

21.

Kay, M. (2007). XSL Transformations (XSLT) Version

2.0. Recommendation, W3C. http://www.w3.org/

TR/xslt20/.

Knublauch, H. (2011). SPIN - SPARQL Syntax. Member

Submission, W3C. http://www.w3.org/Submission/

2011/SUBM-spin-sparql-20110222/.

Patel-Schneider, P. F. and Motik, B. (2012). OWL 2

Web Ontology Language Mapping to RDF Graphs

(Second Edition). Recommendation, W3C. http://

www.w3.org/TR/owl-mapping-to-rdf/.

Quan, D. (2005). Xenon: An RDF Stylesheet Ontology. In

Proc. WWW.

Robie, J., Chamberlin, D., Dyck, M., and Snelson, J.

(2014). XQuery 3.0: An XML Query Language.

Recommendation, W3C. http://www.w3.org/TR/

xquery-30/.

Stolz, A., Rodriguez-Castro, B., and Hepp, M. (2013). RDF

Translator: A RESTful Multi-Format Data Converter

for the Semantic Web. Technical report, E-Business

and Web Science Research Group.

WEBIST2015-11thInternationalConferenceonWebInformationSystemsandTechnologies

476