Natural Language Interfaces (NLIs) to structured data allow users to interact with a system using written or spoken language to perform tasks that require knowledge of a formal language. Due to natural language complexity and ambiguity, such interfaces usually support a Controlled Natural Language (CNL): a subset of a natural language that includes certain vocabulary and grammar rules that have to be followed. Building vocabulary di ers from one system to another, and the way this is performed signi cantly a ects portability: portable CNLs for querying ontologies are those that can be adapted easily to new domains without sacri cing performance. In this paper we describe the approach for dynamically extending the vocabulary supported by such systems, through a dialog with the user.
Natural Language Interfaces (NLIs) for querying structured data allow users to interact with a system using written or spoken language (e.g., English) to perform tasks that usually require knowledge of a formal query language. Due to Natural Language (NL) complexity and ambiguity, such interfaces usually support a Controlled Natural Language (CNL): a subset of a NL that includes certain vocabulary and grammar rules that have to be followed.
Building vocabulary for CNLs which are used for querying ontologies di ers
from one system to another, and the way this is performed signi cantly a ects
portability : portable NLIs to ontologies are those that can be adapted easily to
new domains. Although portable NLIs are considered as potentially much more
useful than domain-speci c systems, constructing them poses a number of
technical and theoretical problems as many of the techniques preclude automatic
adaptation of the systems to new domains [
In this paper, we propose a novel approach for minimizing the customisation of CNLs for querying ontologies without sacri cing performance, when porting them to work with another domain (ontology). We achieve this by modeling a dialog for the user in order to enrich already available vocabulary extracted from the ontology. Along the same lines, the dialog is modeled for any ambiguities which arise from the user's question, and the user is asked to disambiguate the speci c meaning, before the question is translated to the formal language. 2
Several CNL systems for querying ontologies have been developed recently, which
extract the domain vocabulary (lexicon) from the ontology itself by extracting
and processing the lexicalisations such as labels and datatype property values.
Examples of such systems are ORAKEL [
Another way to generate/enrich the lexicon for CNLs for querying ontologies
is by using the CNLs for knowledge representation, such as ACE [
Our approach generates the initial lexicon automatically from the ontology lexicalisations. When the user starts using the system, if a question term is not found in the lexicon, the combination of syntactic parse and ontology reasoning rules is used to generate the dialog. The user is then asked to map the unknown term into the ontology concept and following his selection, the new term is added to the lexicon. In addition, the lexicon carries the semantics which is related to the context in which certain word appeared. 3
Generation of the user-de ned lexicon is broken down into the following steps: 1. Generate lexicon by extracting lexicalisations attached to the Ontology Concepts1. This step includes extracting fragment identi ers, labels, and values of datatype properties. 2. Perform lexicon-based lookup. This would nd the links between question terms and the logical form in the ontology. For example, in What is the population of New York?, New York would be identi ed as Ontology Concept (OC) referring to both geo:newYork2 and geo:newYorkNY, because it is matched with the labels of these URIs which is new york. 3. Analyse grammar and identify the candidate words which could be referring to an Ontology Concept. We call these Potential Ontology Concepts (POCs). For example, for the above question, population would be identi ed as POC, however, as there is no such lexicalisation in the ontology, we do not know to which Ontology Concept this noun refers, and therefore, we ask the user. 4. Generate the dialog (if a POC cannot be mapped to the logical form automatically) and ask the user to map the unknown term (POC) into the speci c concept in the ontology (OC). In addition, if POC refers to more than one OC, generate the dialog and ask the user to disambiguate. For example, in What is the population of New York? the question is ambiguous as it can be translated to two interpretations, where the rst one is the state population of New York state and the other one is city population of New York city. 5. Add the POC to the lexicon as a description of the OC. This description includes the context in which the term appears so that it can be reused in similar contexts. Figure 1 illustrates an example of mapping population to the geo:cityPopulation whenever it appears together with New York as a city 3. If the same word (population) is used together with New York state, then it will need to be mapped to a di erent OC such as geo:statePopulation. 1 Note that we use the term Ontology Concept to refer to all types of ontology resources such as classes, instances, properties and literals. 2 We use geo: instead of the full namespace http://www.mooney.net/geo for brevity. 3 Note that the dialog before this one was asking the user to disambiguate whether
New York is a city or a state
A dynamically enriched lexicon from the user-de ned vocabulary is used
in the system called FREyA4 which serves as an NLI for querying ontologies.
FREyA translates an NL query such as What is the capital of California? into
the formal SPARQL query in order to nd the answer. For more details about
FREyA see [
"http://www.mooney.net/geo#cityPopulation","function":"" The eld function is used to indicate whether mapping certain words into OCs requires applying additional functions on their values (such as applying maximum or minimum function on the values of datatype properties of type number). For example, if in the question What is the largest state in the US?, there is state in the lexicon, which refers to geo:State, but there is no largest. The dialog is modeled and the user can map largest to the maximum value of the geo:stateArea, whenever it is used as a modi er of the lexicalisation of the geo:State: "Key: largest http://www.mooney.net/geo#State", "identifier":
"http://www.mooney.net/geo#stateArea", "function":"max" Translating this JSON format into the knowledge representation such as OWL in a way which can be used by any CNL system is straightforward. For example, the format of the OWL le could be such that ACE OWL Verbaliser generates proper ACE sentences so that the lexicon (content words) of ACE can be enriched. 4 http://gate.ac.uk/freya We experimented with 250 questions from the Mooney GeoQuery dataset5 and the ontology covering the USA geography domain. The system without any customisation (domain lexicon generated automatically from the ontology) could automatically answer 72 questions (28.8%). For the remaining questions, FREyA generated at most 2 dialogs. When running it in the automatic mode (the lexicon is generated without engaging the user, but by selecting the rst suggestion generated by FREyA) the precision and recall were 81.2%. Finally, by engaging the user for up to 15 minutes these values increased to 92.4%.
Acknowledgments We would like to thank A. Bernstein and E. Kaufmann from the University of Zurich, for sharing with us Mooney OWL ontology, and J. Mooney from University of Texas for making this dataset publicly available. 5 http://userweb.cs.utexas.edu/users/ml/nldata/geoquery.html