Much research has been done to combine the fields of Databases and Natural Language Processing. While many works focus on the problem of deriving a structured query for a given natural language question, the problem of query verbalization - translating a structured query into natural language - is less explored. In this work we describe our approach to verbalizing SPARQL queries in order to create natural language expressions that are readable and understandable by the human day-to-day user. These expressions are helpful when having search engines generate SPARQL queries for user-provided natural language questions or keywords and enable the user to check whether the right question has been understood. While our approach enables verbalization of only a subset of SPARQL 1.1, this subset applies to 85% of the 209 queries in our training set. These observations are based on a corpus of SPARQL queries consisting of datasets from the QALD-1 challenge and the ILD2012 challenge.
Much research has been done to combine the fields of Databases and Natural
Language Processing to provide natural language interfaces to database
systems [
In this paper we describe the current state of our SPARTIQULATION system1 which allows verbalization of a subset of SPARQL 1.1 SELECT queries.
The remainder of this paper is structured as follows. Section 2 gives an overview of our query verbalization approach in terms of our system’s architecture and the tasks that it performs. Section 3 relates it to existing work, and in Section 4 conclusions are drawn and an outlook is provided. 2 2.1
Our approach is inspired by the pipeline architecture for natural language
generation (NLG) systems and the set of seven tasks performed by such systems
as introduced by Reiter and Dale [
In this section we present our approach along the seven tasks involved in NLG
according to Reiter and Dale [
The pipeline architecture is depicted in Figure 1. Within the Document Planner the content determination process creates messages and the document structuring process combines them into a document plan (DP) which is the output of this component and the input to the Microplanner component. Within the 1 The name is derived from joining SPARQL and articulation.
Document structuring
Microplanner the processes lexicalization, referring expression generation and aggregation take place, which results in a text specification (TS) that is made up of phrase specifications. The Surface Realizer then uses this text specification to create the output text.
Content determination is the task to decide which information to communicate in the text. In the current implementation we decided not to leave this decision to the system. What is communicated is the meaning of the input query without communicating which vocabularies are used to express the query. Therefore, in this task no action is performed.
Document structuring is the task to construct messages from the input query and to decide for their order and structure. These messages are used for representing information in the domain, such as the class to which the selected entities belong to or the number to which the result set is limited. We present the set of message types after introducing the notion of the main entity and the graph transformation. Our observations are based on a corpus of SPARQL queries consisting of datasets from the QALD-1 challenge2 and the ILD2012 challenge.3 The full dataset contains 2634 SPARQL SELECT queries and associated manually created questions. In order to leave parts of this dataset for future evaluation we only regarded 80% of each dataset as training data. Since in our approach we cannot yet handle all features of the SPARQL 1.1 standard, we had to exclude some queries. Within this training set of 209 queries we excluded the queries with the features UNION (22), GROUPBY (7), and those where the triple patterns 2 http://www.sc.cit-ec.uni-bielefeld.de/qald-1 3 http://greententacle.techfak.uni-bielefeld.de/~cunger/qald/ 4 For nine questions no query is given since they are out of scope regarding the datasets provided for the challenge. 28 queries are ASK queries. within the WHERE clause do not form a connected graph (3). This means that this subset covers 85% of the queries within the training set.
We perform a transformation of the query graph, since it reduces the
number of necessary message types which are shown in Table 1. Thus it simplifies
the verbalization. This transformation is based on the observation that in most
queries one variable can be identified that is rendered as the subject of a
sentence. For example when querying for mountains (bound to variable ?mountain)
and their elevations (bound to variable ?elevation), then ?mountain is
verbalized as the subject of the verbalization mountains and their elevations. We
refer to this variable as the main entity of a query. However, for some queries
no such element exists. Consider for example the query SELECT * WHERE { ?a
dbpedia:marriedTo ?b .}. Here a tuple is selected and in a possible
verbalization Tuples of married entities5 no single variable appears represented as a
subject. In order to identify the main entity we define Algorithm 1 that applies
the ordered list of rules shown in Figure 2. These rules propose the exclusion of
members from a candidate set. We derived them by looking at queries within
the training set having multiple candidates. The candidate set C is initialized
with variables that appear in the select clause and the algorithm eliminates
candidates step by step. Q denotes the set of triples within the WHERE clause of
a query, Rt is the property rdf:type and Rl is a labeling property from the set
of 36 labeling properties identified by [
Rule 1 E := {x ∈ C | ”x appears in OP T ION AL only”} Rule 2 E := {z ∈ C | ¬∃(z, Rt, u) ∈ Q}
if ∃c1 ∈ C : ¬∃(c1, Rt, x) ∈ Q ∧ ∃c2 ∈ C : ¬∃(c2, Rt, y) ∈ Q Rule 3 E := {z ∈ C | ¬∃(z, Rl, u) ∈ Q} if ∃c1 ∈ C : ¬∃(c1, Rl, x) ∈ Q ∧ ∃c2 ∈ C : ¬∃(c2, Rl, y) ∈ Q
The rules can be described as follows where the numbers show how often a rule was successful in reducing the candidate set for the 209 queries within our training set. Rule 1 (85, 40.67%) proposes removing candidates that appear within the WHERE clause only within OPTIONAL blocks. Rule 2 (12, 5.74%) proposes removing candidates that represent subjects that are not constrained via rdf:type in the case that there are candidates that are constrained via rdf:type. Rule 3 (48, 22.97%) proposes removing candidates for which no label is constrained or requested in the case that there are candidates for which this is the case. In some cases (64, 30.62%) no rule was applied since the candidate set contained only a single variable. For all queries given these rules the main entity has been identified. While our actual list of exclusion rules contained more rules these were never applied for the given training data and thus omitted here. 5 DBpedia provides no rdfs:domain and rdfs:range information, such as foaf:Person for this property. Therefore here we give a generic verbalization to demonstrate the problem. Algorithm 1 Applying reduction rules to candidate set.
if |C| = 1 then
return C while |C| > 1 do for all Ri ∈ R do if |Ri(C)| > 0 then
C ← Ri(C) if |C| = 1 then
return C return ∅
We transform, as shown in Algorithm 2, queries in a way that the query graph is converted into a graph where the main entity is the root and all edges point away from the root if the query does not come in that shape already. Therefore the algorithm maintains three sets of edges: edges that are already processed (P ), edges that need to be followed (F ), and edges that need to be transformed (T ) which means reversed. An edge is reversed by exchanging subject and object and by marking the property (p) as being reversed (pr).
Algorithm 2 Graph transformation
P ← ∅, F ← {(s, p, o) ∈ Q|s = m}, T ← {(s, p, o) ∈ Q|o = m} while F = ∅ or T = ∅ do for all (si, pi, oi) ∈ F do for all (sj, pj, oj) ∈ Q \ (P ∪ F ∪ T ) do if oi = sj then
F ← F ∪ {(sj, pj, oj)} else if oi = oj then
T ← T ∪ {(sj, pj, oj)}
Move (si, pi, oi) from F to P for all (si, pi, oi) ∈ T do for all (sj, pj, oj) ∈ Q \ (P ∪ F ∪ T ) do if si = sj then
F ← F ∪ {(sj, pj, oj)} else if si = oj then
T ← T ∪ {(sj, pj, oj)} T ← T \ {(si, pi, oi)}
P ← P ∪ {(oi, pir, si)} return P (init)
We identified the set of 14 message types (MT), shown in Table 1 that allow us to represent the 209 queries from our training set. The first 9 MTs represent directed paths in the query graph which means that for each directed path that begins at the main entity, we represent this path with a message. Each path starts at the main entity (M ) and consists of none to many pairs ((RV )∗) of a resource (R) followed by a variable (V ). Moreover, they may contain a labeling property (Rl) or the rdf:type property (Rt). V AR represent all information about a variable, such as its name, whether it is the main entity, whether it is selected, distinct, optional, counted, or whether any filter is specified for this variable. The MTs ORDERBY , LIM IT , OF F SET and HAV IN G represent the respective SPARQL features.
The document plan (DP), which is the output of the Document Planner and input to the Microplanner, structures the content as follows: in the first part, which can later be verbalized as one ore more sentences, the main entity and its constraints are described, followed by a description of the requests (the variables besides the main entity that appear in the select clause) and their constraints. In a second part, if available and not already communicated in the first part, the selection modifiers are verbalized. According to these 3 categories – abbreviated with cons, req, and mod – we classify the MTs as follows. The MTs (1), (2), (4), (6), (7), and (9) from Table 1 belong to the class cons, the MTs (3), (5), and (8) belong to the class req. MTs (1), (2), (4), (6), (7) and (9) may also belong to class req if they contain a variable besides the main entity that appears in the select clause. MTs (10) − (14) belong to the class mod. While this set of message types is sufficient for the given training set, which means that all queries can be represented using these message types, we extended this list with 76 more types in order to be prepared for queries such as SELECT ?s ?p ?o WHERE { ?s ?p ?o. } and SELECT ?p WHERE { ?s ?p ?o. } where instead of generating text, canned text is used, such as All triples in the database and Properties used in the database.
nr name (1) M (RV )∗RR (4) M (RV )∗RlR (7) M (RV )∗RtR (10) V AR (13) OF F SET
As an example the SPARQL query in Listing 1 is represented using the 6 messages shown in Figure 3. Note that due to the graph transformation the property onto:author is reversed which is denoted by rev: yes within the data structure stored in the messages. This query can be verbalized as: Authors of books with English name ”The Pillars of the Earth” and if available their English names. Note that plural (authors, books and names instead of author, book, and name) is used per default. The filter for English labels is stored within the message representing the variable string. 6 Given that all three variables can either be selected or not selected and at least one variable needs to be selected, this results in 7 combinations. ? uri ? string { ? books rdf : type onto : Book . ? books onto : author ? uri . ? books rdfs : label " The Pillars of the Earth " @en .
OPTIONAL { ? uri rdfs : label ? string .
FILTER ( lang (? string ) = ’en ’) } } Listing 1. Who wrote the book The pillars of the Earth? – SPARQL query type: M(RV)*RlL l]]R a l]v1pV abraRV:r:n eeo l:[:[ugl vpo:be:: : [ no: eyrto“endoTksf:shsa:eula tPbhieolllarrs of the Earth” ]tcR yl ]1Va prRV::s ee :[:s[ v::ob :Mo noyntoe(otRkso:sVa:Bu)*toRhootkRr ll]ttsnoR aayyevpapVbnpplarmt:egeeeo :r[c :l:e::py : t]es :VMe::[t nssyrAr(tdieRRrnfsisgVn:g)la*bRelVl type: VAR name: uri main: yes type: VAR name: books select: no
Lexicalization is the task of deciding what specific words to use for expressing
the content. For each entity we dereference its URI and in case that RDF data
is returned, we check if an English label is provided using one of the 36 labeling
properties defined in [
Referring expression generation is the task of deciding how to refer to an entity. Considering the example Entertainers born in Bavaria and where they are born. Here, they is the expression that refers to the Bavarian entertainers. Aggregation is the task to decide how to map structures created within the document planner onto linguistic structures such as sentences and paragraphs. For messages of type cons and req sentence parts are created that are joined into a single sentence. Messages of type mod are verbalized in further sentences. Aggregation is indispensable for concise verbalization. Since we split a query graph into (overlapping) paths where each path is represented by a message, aggregation would exploit these overlappings. Linguistic realization is the task of converting abstract representations of sentences into real text. Text parts are generated for each of the message types (1)− (9) from Table 1. For each such type a rule is invoked that produces a sentence fragment, for example for the MT M RV RlL –which is an instance of the MT M (RV )∗RlL – the rule article(lex(prop1)) + lex(prop1) + L produces for two triples ?uri dbpedia:producer ?producer and ?producer rdfs:label "Hal Roach" the text a producer Hal Roach. The function article choses an appropriate article (a or an) depending on the lexicalization lex(prop1) of the property. This fragment is added to the part of the verbalization where the constraints for the main entity are described and may be joined by the word and with other constraint fragments.
Structure realization is the task to add markup such as HTML code to
the generated text in order to be interpreted by the presentation system, such
as a web browser. While this could be helpful to enhance the readability of a
complex verbalization, which is the case in [
While to the best of our knowledge no work is published on the verbalization
of SPARQL queries, related work comes from three areas: verbalization of RDF
data [
For the task of verbalizing SPARQL queries we focused on a subset of the SPARQL 1.1 standard which covers 88% of the queries in a corpus of 209 SPARQL queries. Evaluation will have to show the representativeness of this corpus compared to real-life queries and the qualities of the verbalizations generated using our SPARTIQULATION system. While in our architecture 6 tasks are needed to generate verbalizations, our main focus has been the task of document structuring which we described in this work. In order to realize the full verbalization pipeline, 5 other tasks need to be explored in future work. Since the current approach is mostly schema-agnostic – only terms from the RDFS vocabulary are regarded during document structuring – we believe that this approach is generic in terms of being applicable to queries for RDF datasources using any vocabularies. However, in the future the tasks of lexicalization can be improved by regarding schemas such as FOAF since persons are treated differently in verbalizations then non-persons, genders can be regarded etc. Having message types designed for specific vocabularies allows to tailor the verbalization to a specific use case and may lead to more concise verbalizations. In the current implementation message types are hard-coded thus limiting the flexibility of the approach. Having the possibility to load a set of message types into the system would add the possibility to integrate automatically learned or application-specific message types.
The work presented in this paper is supported by the European Union’s 7th Framework Programme (FP7/2007-2013) under Grant Agreement 257790.