We present a new interface based on natural language to support users in specifying their queries with respect to RDF datasets. The approach relies on a number of prede ned patterns that uniquely determine a type of SPARQL query. The approach is incremental and assisted in that it guides a user step by step in specifying a query by incrementally parsing the input and providing suggestions for completion at every stage. The methodology to specify the patterns is informed by empirical distributions of SPARQL query types as found in standard query logs. So far, we have implemented the approach using two patterns only as proof-of-concept. The coverage of the pattern library will be extended in the future. We will also provide an evaluation of the approach on the well-known QALD dataset.
SPARQL is the query language for the Web of data, but it su ers from a high adoption barrier by end users. Mastering the SPARQL syntax is a problem for users lacking IT skills. But even knowing the SPARQL syntax, a more severe problem remains: the need to know the underlying vocabulary of the queried dataset. Thus, querying RDF data remains a barrier not only for lay people but also for technically skilled users. There are di erent approaches to alleviate this barrier and to support users in the task of querying RDF data.
One approach consists in guiding users in writing SPARQL queries by some
interface, e.g. SindiceTech's Qakis [
Another type of approach uses visual metaphors to support writing queries,
abstracting from the SPARQL syntax, e.g. Rhizomer [
The systems in the third category are typically not incremental in the sense
that they require a user to enter a full query before it is processed. Thus, the
user has no guidance on how to write the query. Exceptions are systems such
as Attempto-OWL [
We present a novel approach to guided natural language querying that is
incremental in the sense that it interprets the question while the user is typing
it and can thus provide guidance by proposing possible completions of the query
to the user. The approach relies on a number of patterns that have been de ned
to cover the most frequent types of SPARQL queries. So far, only two patterns
have been implemented to provide a proof-of-concept, but the long-term goal
is to continue adding natural language patterns iteratively to cover the most
frequent types of SPARQL queries sent by users to SPARQL endpoints. In fact,
it has been shown that the the SPARQL queries made to SPARQL endpoints
follow a power-law distribution [
Figure 1 shows the number of queries for each type (left y-axis) and the percentage of the total number of queries (right y-axis). One can see that the rst query type (the most used) was used by 1.2 million queries, corresponding to 42% of the total number of queries. The top-20 queries cover 95% of all queries. This gure was built using 3 months of DBpedia logs (USEWOD 2014 dataset). A speci c question of a user might be:
\Give me movies by Tarantino" The corresponding natural language pattern would be the following:
Give me Noun Preposition Instance The corresponding SPARQL query type would be the following:
SELECT ?s WHERE f?s prop instance g And the actual SPARQL query would look as follows:
SELECT ?s WHERE f?s dbpedia:director dbpedia:Tarantinog Our long-term goal is to have an approach that covers 90% of all queries. By guiding the user, one ensures that only such queries are typed in that can actually 1,400,000 tep1,200,000 y y r e tqu1,000,000 a h t ro 800,000 f s e i r eu 600,000 q f o r eb 400,000 m u N 200,000 0 2 4 6
8 10 12 14 Query type (ordered by frequency) 16 18 20 be processed by the system, thus reducing errors and increasing robustness of the system. With this method we can cover quickly the most frequent query types, but covering the long tail would require implementing hundreds of query types. Our system is intended to allow an incremental way of adding new query types.
An important challenge is to have a system with high lexical coverage that
covers as many alternative ways of referring to one given property, class or
individual as possible. We rely on ontology lexica as modeled by the lemon model [
A further challenge is to have a real-time response so that query completion
is immediate from the users' point of view. This can be achieved by appropriate
inverted indexes that return for a class which properties are associated to this
class, which instances stand in the subject or object of a particular property, etc.
We rely on an index [
?s dbpedia:starred dbpedia:John_Travoltag or Which Noun Verb Preposition Instance? e.g. Which river passes through London?, mapping to the SPARQL query SELECT ?s WHERE f?s a dbpedia:River .
?s dbpedia:crosses dbpedia:Londong
Overall, NL patterns thus represent slotted and typed patterns into which elements can be inserted to be completed. Once all elements have been inserted into an NL pattern, the SPARQL query is determined.
Figure 2 shows two NL patterns. Each NL pattern represents a sequence of so called Parseable Elements. Each element parses or recognizes one part of the input. A question is parsed by applying all NL patterns available and determining which ones match or recognize the input. This is determined iteratively by checking for each parseable element whether it recognizes or matches the corresponding part of the question. In general, multiple patterns will match a question at any time. We distinguish the following types of parseable elements: B
D NLP NLP 1 2
Fig. 2. Use case for two NL query patterns NLP1 and NLP2 { TextElements: These elements are responsible for recognizing constant ller elements (e.g. `what', `who', etc.) { PropertyNounElements: These elements are responsible for recognizing a noun that denotes a property (e.g. `capital' ) { ClassNounElements: These elements are responsible for recognizing a noun that denotes a class (e.g. `river' ) { VerbElements: These elements are responsible for parsing a verb that denotes a property (e.g. `passes' ) { InstanceElements: These elements are responsible for parsing an instance (e.g. `London', `John Travolta' ), etc.
For each pattern, the system checks whether it accepts the input query. It iterates through the sequence of parseable elements that constitute an NL pattern and veri es for each parseable element whether it recognizes the corresponding part of the sentence. A simple lookahead method is used to compute possible completions of the question by showing the user the inputs that the following parseable element will accept. Choices made by the user are propagated to future elements of the sequence as needed and modeled by corresponding dependencies between the parseable elements in the sequence. In the example depicted in Figure 2), the user has typed in what, which matches both patterns. Then, the system proposes completions for both patterns. The user can delete any number of previous selections to return to a previous point and the system continues the process from that point. 3
Architecture of the system The architecture of the system is depicted in Figure 3. The main components of the architecture are the following ones:
DBpedia endpoint
Web Server
interQA
Fig. 3. Key components in the interQA system for the DBpedia use case. 1. SPARQL endpoint: As any user interface, a quick response is a fundamental issue. In order to avoid an excessive number of requests to the endpoint, we create an index with the results of a speci c set of extractive queries. Therefore, we need a privileged access to the endpoint. In our experiments we have used the Spanish DBpedia. Other endpoints could run the indexer in low-demand periods (by night) or with small pagination (the smaller the pagination size, the longer time to create the index). 2. SPARQL endpoint index: This index is available online as a REST service. For the case of the Spanish DBpedia see (http://loupe.linkeddata. es/loupe). 3. Question Interpretation component: the component4 that incrementally interprets the user's input by matching it to the patterns and returns possible completions. It is described in the next section. 4. Frontend: A web server running a web application to interact with the user. 5. Lexicon: a lexicon that contains information about how the vocabulary elements of the dataset are lexicalized in natural language. The system currently uses the lexicon for DBpedia in three languages (Spanish, English, German). 4
Question Interpretation component We have presented a preliminary system that interprets natural language questions with respect to SPARQL and has three key features: i) it is pattern-based in the sense that it exploits a number of patterns that cover the most frequent types of SPARQL queries, ii) it is data-driven in the sense that it is grounded in an analysis of frequent query types and in that it uses indices to anticipate possible completions of a query in real time, and iii) it is guided in the sense that it computes potential completions and displays these to the user. In this 4 See http://github.com/ag-sc/InterQA g > itrn i)ng *
r> S t
Sg 1 n i < tr t isS n L< e t
s em )g i(L llEe itrn aed b (S h a e a rsa rsa ko P p lo 1 * an id g >
n g le vo itr in o S tr o S b < t s i L g n i r t S ) > 1 ) < t g t n in ) is e tr ) g (L litrEengm (tscaeSh i(trSndgd i(trrsaeSn kaaehod S m a p lo » e t a e r c 1 « g > in g r )n 1 t i
r> S t g S n i < tr t isS n L< e ts lem )ng i(Ld 1 tscEaenn i(trrsaeS kaaeho 1 I p lo » e t a e r c «g > itrn i)ng
r> S t g S n i < tr isS L < t s ) i g (L 1 un in d o tr ae N (S h s e a s s k la ra o
C p lo 1 n > g lae ing itrn oo tr S b S < t s i L ) * ( y r e ) u g Q n L n i r tr () Q 1 ttae (seS txe PRA P s N S A r t t
a e e Q p g g » e t a e r c « d g > > > > id id ivo itrn ing try ing ing vo vo
S tr En tr tr
S l S S t< ica t< t< is x is is L e L L
L < t s i L » e t a e r c « » e t a e r c « 1 1 ) y r t n E l a c i xe ) )t )t L g n n , in e e 1 ng ) tr m m trryeunoopN lii(ttrrrsaaeeSSPnbddg i()trrsaeSng ii(ttrsLkaaeShnoodg<> ,lii(tttrrxcLyEaeeSSnng iI()tttrsscaeeSnnng i()ttrrseeePop lII(tttsssccEaaeeeennnn iiil(tttrrsEeeeSPnnoopg trc«eae» P a p l g g g s s » e t a e r c « n > g a g in 1 le in tr oo tr S b S 1 t< s i L ) ( y r e 2 ) u rn g Q ttae itrSn )(t LRQ ryP (se xe PA e s N S u ra te te Q p g g d i o v ) n 1 r e t t r a e P g A a Q n ( a rn M te n t r a te P t y a r P e y u 1 re Q u d
d Q a » e t a e r c «
d t i se vo T r e g ) a ( n g a n
i M h n t r e e tt m a o P tS ry se e t u
Q > n > g ing lae ing itrn trS< oob trS S te»
< a its its re L L c
« ) g n i r t S , g n i r t S ( m r o F s u l P l a c i n o n a ) ( 1 r1n rsFoC )g ryeuQ ttryaeeP Itscaenn i(trsseSn )(txeN LSPRAQ u te ra te te 1 Q g p g g way, one ensures that only such queries are entered into the system that are also valid and can be processed and interpreted by the system, thus reducing errors and increasing robustness. Future work includes increasing the coverage of the system with more patterns, improving the indexes and covering languages other than English. An evaluation of the approach remains to be done.