Qallme Semantic Web Data Access

Transcription

1 Qallme Semantic Web Data Access Author: Affiliation: Qall- Me Consortium FBK, University of Wolverhampton,, University of Alicante, DFKI,, Comdata, Ubiest, Waycom Keywords: ontology, question answering, interactive question answering Abstract: This report presents the work carried out in the Data access work package of the Qall- Me project. We report about the Qall- Me ontology, which allows to interface the linguistic components for question interpretation with the data of the application domain. We describe the main procedures for data access, addressing both portability and scalability issues. We also describe the Interactive Question Answering ontology, which has been designed in order to represent in an uniform way simple interactions with the user.

2 1. Introduction The QALL-ME ontology Development of the QALL-ME Ontology Scope Ontology Language Editing Tools Overview of the QALL-ME Ontology The Interactive Question Answering Ontology Question-answer structure Structure of a question Structure of an answer Empty answers Special requirements of IQA Description of Classes...11 Answer...11 Question...11 Core Information...11 Interaction turn...13 Other classes Properties...14 Parts and Direct parts...14 Properties connecting IQA to domain ontology...14 Other properties General axioms Retrieval process Scaling up the amount of data Adaptation to the bibliographical domain The QALL-ME ontology for the bibliographical domain Data acquisition for the bibliographical domain References...25 D4.3

3 1. Introduction This document presents the work carried out in the Qall-Me project on Data Access based on Semantic Web techniques. This work has three main goals: To deliver dynamically updated databases of semantically annotated XML data in the domain of tourism and cultural and other local events. Provide algorithms and an engine for Content Retrieval from these databases. Develop a domain specific ontology to back up the text annotation. To achieve the above goals, in the first cycle of the project, we developed an ontology for the tourism domain in order to provide a common vocabulary for semantic annotation of tourism data and to enable knowledge sharing and reuse among all the partners in this domain. This ontology was then aligned with two upper ontologies WordNet 1 and SUMO (Suggested Upper Merged Ontology) 2 to expand concepts defined in the tourism domain. Data about movies and cinemas, which were obtained from local content providers in the form of databases and HTML web pages, was semantically annotated based on the classes and properties defined in the QALL-ME ontology and then encoded using RDF triples. One of the most popular and efficient RDF storage systems, Jena 3, was selected to store the RDF data into the relational MySQL database using Jena s usual database schema RDB (Wilkinson et al., 2003). In the first stage of the project, the SELECT query form of SPARQL queries was used to retrieve the answers for natural language queries. In the second phase of the project, the main changes were made to the QALL-ME ontology and the solution used for data storage and access. To make the ontology model better the domain knowledge, some new classes and properties were added into the ontology according to the feedback received from all the partners and additional data obtained in the tourism domain, whereas those that were considered useless were removed. In addition to periodically updated data in the sub-domain of movie & cinema, data about accommodation was also collected for answering the questions in this sub-domain. Since response time is a crucial issue for the question answering task, we tried to find a more efficient data storage and access solution for speeding up the execution of SPARQL queries. We performed experiments to compare the loading performance and query performance of Jena s two database schemas: RDB and SDB (with two layouts: Hash vs. Index). The experiment results indicated that the Indexbased SDB schema is more efficient for loading a large amount of RDF data and more efficient for executing complex SPARQL queries which involve more triple patterns. Thus we decided to use SDB-Index, rather than the former RDB, in the second prototype system to store the RDF data in the MySQL database. Another important change in the second phase is that we used the CONSTRUCT query form of SPARQL queries to replace the former SELECT form. The reason is that a CONSTRUCT query returns a single RDF graph, which contains not only the answer strings but also their answer types, the context of the answer in the form of the information from the question, and possibly further information that may support answer presentation, so that appropriate information can be taken from this RDF graph Page 1 of 29

4 to present the answers in a better way. This information was used in the third cycle of the project to develop interactive QA systems. The third cycle of the project had two main foci. The first one was to investigate ways to incorporate interactivity in the QALL-ME prototype. To this end, FBK and University of Wolverhampton developed two complementary ontologies that enable interaction in the system. The second main focus of the work performed this year is related to answering questions from unstructured data. This work was performed by DFKI, University of Alicante and University of Wolverhampton. In addition, University of Wolverhampton continued to explore more efficient ways of retrieving answers from RDF databases and investigated domain portability. The reminder of the document presents the work of each of the academic partners in detail. Given the importance of the ontology in the project, the short description of the QALL-ME ontology is presented next. 2. The QALL- ME ontology The QALL-ME ontology was designed to model the knowledge in the domain of tourism. It covers several important aspects of the tourism industry, including touristic destinations (i.e. cities and towns), sites (i.e. accommodation, gastro, attraction, and infrastructure), events (e.g. movie and show) and transportation. The main purpose of the ontology was to provide a common vocabulary for the selected domain and a computerized specification of the meaning of terms used in the vocabulary. OWL DL was selected as the encoding language because it has more expressive power than OWL Lite and has more efficient reasoning support than OWL Full (Antoniou & van Harmelen, 2004). In the second cycle of the project, the QALL-ME ontology was updated on the basis of the feedbacks received from all the partners involved in building the first prototype system as well as the new data acquired in the domain. Some new classes and properties were added and some existing ones were changed or removed. In the third cycle, the QALL-ME ontology was not changed as it was one of the central components of the QALL-ME project and many other components (e.g. tourism data annotation, question annotation) are heavily reliant on the ontology. Therefore, a fixed ontology was required for the release of the QALL-ME framework. The reminder of this section presents a summary of the ontology. More detailed information can be found in D Development of the QALL- ME Ontology The QALL-ME ontology was developed based on the above related ontologies by borrowing concepts and structures to a certain extent from them. In the aspect of coverage, the QALL-ME ontology is similar to the Harmonise and etourism ontologies: all of them focused on static tourism information (e.g. accommodation and events/activities) rather than dynamic information related to tourism business (e.g. itinerary, customers and travel services) presented in the TAGA and Hi-Touch ontologies. However, the QALL-ME ontology has a wider coverage than the other two ontologies because it includes more tourism sites and tourism events. In the aspect of Page 2 of 29

5 structure, the QALL-ME ontology is more similar to the etourism ontology. Both of them are encoded in OWL rather than RDFS and thus involve more complex classes and relationships and support complex inferences. GETESS is a good example of providing bilingual terms for the concepts defined in the ontology. In the future, the QALL-ME ontology will be mapped with multilingual ontologies, e.g. EuroWordNet, to support multilingual tourism data and user questions. 2.2 Scope The QALL-ME ontology focuses on the tourism domain and aims to provide a conceptualization description for this domain. It covers several important aspects in the tourism industry, including tourism destinations (i.e. cities and towns), tourism sites (i.e. accommodation, gastro, attraction, and infrastructure), tourism events and transportation. However, the aspects related to tourism market such as customers and itineraries are not covered in the ontology. The QALL-ME ontology applies a similar structure to the etourism ontology by using OWL and packaging some common attributes (e.g. contact and location) as separate classes. The final version of the QALL-ME ontology (v4.0) contains 261 classes (concepts), 55 datatype properties which indicate the attributes of the classes, and 55 object properties which indicate the relationships among the classes. The 261 classes were categorized into 17 top-level classes. The class hierarchy has a maximum depth of four. From the point of view of design, the 17 top-level classes fall into the following three categories: (1) Main Classes Main classes refer to the most important concepts in the tourism domain, which can exist independently. The main classes include: Country Destination Site EventContent Event Transportation (2) Element Classes: Element classes refer to the elements of the main classes or the elements of other element classes. The instances of an element class are a part of an instance of a main class or another element class, for example, a RoomFacility instance Satellite TV is a part of a Room instance Quality Hotel Single Room, which is a part of a Hotel instance Quality Hotel Wolverhampton. The element classes include: Facility Room PersonOrganzation Language Currency CreditCard (3) Attribute Classes: the packages of a group of attributes for the main classes or element classes. The attribute classes include: Page 3 of 29

6 Contact Location Period Price Genre The QALL-ME ontology (v4.0) was aligned with two upper ontologies WordNet (version 2.1) and SUMO using a semi-automatic alignment method (see details in D4.1). The final version of the QALL-ME ontology and its alignments to WordNet and SUMO were released freely at the QALL-ME website under the Creative Commons Licence 3.0 (Attribute-Noncommercial-Share Alike 3.0 Unported) Ontology Language An ontology language is a formal language used to encode the ontology. There are a number of such languages for ontologies. One of them is RDF Schema (RDFS) which is recognized as a basic ontology language (Arroy et al., 2004). However, RDFS is too weak to describe resources in sufficient detail. After it, OIL, DAML, and DAML + OIL were designed for more expressive uses (Arroy et al., 2004). Currently OWL (Ontology Web Language) is the most recent development in standardised ontology languages, endorsed by the World Wide Web Consortium (W3C) to promote the Semantic Web vision. OWL provides three increasingly expressive sublanguages OWL-Lite, OWL- DL and OWL-Full for different purposes (McGuinness & Harmelen, 2004). In the QALL-ME project, we used OWL-DL language. It is much more expressive than OWL-Lite and is based on Description Logics (DL) by which all conclusions can be guaranteed to be computed and all computations will finish in a finite time so that the classification hierarchy can be computed and the consistencies can be checked. 2.4 Editing Tools We used Protégé-OWL (Horridge, et al., 2004) as the development tool in the QALL-ME project. Protégé11 is a free, open-source platform that provides a suite of tools to construct domain models and knowledge-based applications with ontologies. The Protégé-OWL editor is an extension of Protégé that supports OWL. After editing the ontology, a reasoner is needed to perform various inferencing services, such as computing the inferred superclasses of a class, determining whether or not a class is consistent, deciding whether or not one class is subsumed by another, etc. OWL-DL provides an API that can be used to interact with an external DIG12 reasoner. We used RacerPro 1.913, which is an OWL reasoner and inference server for Semantic Web, to do automated DL reasoning over the ontology for computing its classification hierarchies and checking for its consistencies. 2.5 Overview of the QALL- ME Ontology The QALL-ME ontology includes 15 first-level classes (concepts). These 15 classes are categorized into three types main classes, element classes and attribute classes. 4 Page 4 of 29

7 Main classes refer to the most important concepts in the tourism domain, including Country, Destination, Site, Transportation, EventContent and Event. The instances of the main classes are concrete countries, destinations, sites, transportation vehicles, event contents (e.g. movie) and occurrences of event contents (e.g. movie show). Element classes refer to the elements of the main classes or the elements of other element classes, including Facility, Room, Person & Organization, Language and Currency. For example, an instance of the class GuestRoom (subclass of the Room class) is an element of an Accommodation instance, and a GuestRoomFacility instance is an element of a GuestRoom instance. Attribute classes refer to the packages of a group of attributes for the main classes or element classes, including Contact, Location, Period and Price. For example, a Contact instance contains all kinds of contact information (e.g. contact person, telephone, fax, , and website) for a Site instance. 3. The Interactive Question Answering Ontology The ability to provide both rich and natural answers with respect to a given question, and clear explanations for failures, is a crucial aspect for a future generation of Question Answering systems able to interact with a user. A relevant aspect for interactivity in a general QA setting is the ability: (i) to consider the context of utterance of a question, such as time and location; (ii) to provide rich answers containing additional information (e.g. justifications) with respect to the exact answer; and (iii) to explain failures when no answer is found. In our view, such abilities are necessarily based on a deep analysis of the content of both the question and the answer. More specifically, we have defined an Interactive Question Answer (IQA) ontology where the question is analyzed in three components (i.e. the expected answer type, a number of constraints over the expected answer type and the context of utterance), and the answer is represented according to both its core information, a number of justifications and, possibly, complementary information [1]. This structure is both domain and language-independent and can be considered a general framework for both Open Domain QA and Natural Language Interfaces to Databases. In addition, we have defined an architecture for QA systems based on the IQA ontology and on dialogue templates using the IQA ontology, where the output of the system is informative enough to serve several presentation purposes, such that the answer to the user s question can be displayed through different media (e.g. mobile devices or computer screens), in different modalities (e.g. text to speech messages, interaction with digital assistants, web presentations or SMS) and in multiple languages. 3.1 Question- answer structure The following sections investigate the interdependence between questions and answers in an interactive scenario, where one must necessarily consider the response in conjunction with a deep analysis of the question. Page 5 of 29

8 3.1.1 Structure of a question We restrict our analysis to factoid questions, i.e. questions which require as an answer the name of an entity, and propose analyzing questions according to three features: ExpectedAnswerType (EAT), Constraints and ContextOfUtterance. Expected answer type The EAT of a question has been defined by Prager [2] as the class of object (or rhetorical type of sentence) sought by the question; in other words, it is the semantic category associated with the desired answer, chosen from a predefined set of labels, e.g. a date, a quantity, a named entity, etc. For instance, Example 1.1-(a) requires the name of a facility, 1.1-(b) a geographical name and 1.1-(c) a date. Different classifications exist for EATs, at different levels of granularity, so there can be a very general classification which does not distinguish between facilities and geographical names, thus having named entity as EAT both for 1.1-(a) and 1.1-(b). On the other hand, a very detailed classification might distinguish between bodies of water and mountains (so the EAT for 1.1-(b) would be body of water ) and even among bodies of water, between lakes and rivers (so 1.1-(b) would have river as EAT). Example 1.1 Factoid questions: (a) Where is Titanic showing on April 23rd in Trento? (b) Which river flows through Verona? (c) When can I see a movie starring Kate Winslet? Constraints Constraints make the request more specific by restricting the range of elements satisfying the EAT so that (ideally) only one is left which actually answers to the given question. Constraints may include specifications on space, time, names, numbers, ratings, cost, etc. In Examples 1.1-(a-c) we have respectively the following Constraints: (a) is Titanic showing, on April 23 rd and in Trento, (b) flows through Verona, and (c) can I see a movie and starring Kate Winslet. Context of utterance Finally, a question is characterized by its ContextOfUtterance, i.e. the time and place in which the question is uttered (which is generally known in the case of QA systems as far as time is concerned). For Examples 1.1-(a-c), we can assume the following ContextOfUtterance: April 22nd, 2009, Trento Structure of an answer Defining the structure of answers to factoid questions is a particularly challenging task as there could be a variety of different ways to correctly (or at least acceptably) answer the same question. We propose a scheme to classify the different elements that can be contained (or not contained) within variations of the same answer, while also being able to cover all acceptable answers. According to this scheme we identify three primary parts, i.e. CoreInformation (CoreInfo), Justification, and ComplementaryInfo (ComplInfo). Page 6 of 29

9 Core information CoreInfo represents the minimal information, satisfying the EAT of the question, which is necessary to successfully answer a factoid question. CoreInfo could also be viewed as the shortest acceptable realization of an answer, which could be exploited in several answer presentation techniques, e.g. to present just the minimal answer if it has to be sent through a message of limited length (e.g. on a mobile phone). For instance, just providing the CoreInfo Cinema Astra can be considered an acceptable answer to the question in Example 1.1-(a). Justification In addition to the CoreInfo, an answer typically also contains some Justification for it, i.e. some explanation and contextualization, which can either be taken directly from the question (direct Justification) or derived from a specific interpretation of the question itself (derived Justification). Direct Justification of an answer is realized by repeating or rephrasing (some of) the Constraints contained in the question, which makes the answer more trustworthy by showing that the question has been correctly understood. In Example 1.2-(a), for instance, the core information is presented along with a rephrased Constraint ( is Titanic showing, in the interrogative form, is rephrased as Titanic is showing ). In Example 1.2-(b), two more Constraints are repeated (i.e. today and in Trento ) and in 1.2-(c) by Cameron is also added. Example 1.2 Question: Where is Titanic by Cameron showing today in Trento? (a) Answer: Titanic is showing at Cinema Astra. (b) Answer: Today Titanic is showing at Cinema Astra in Trento. (c) Answer: Titanic by Cameron is showing at Cinema Astra today in Trento. Derived Justification, on the other hand, is realized by presenting information that is not present in the question. In fact, there are many cases where the question is underspecified and consequently ambiguous (i.e. the Constraints provided are not sufficient to answer the question). Answers to such ambiguous questions are necessarily based on a specific interpretation of the question, which must be provided explicitly in the answer in order to support it. For example, the question in Example 1.3 is ambiguous from the temporal point of view as it contains no temporal Constraints. In order to provide a direct answer to the question, it is necessary to choose a specific interpretation, i.e. to select a specific time and make the answer refer to that time, and then make the interpretation explicit by providing the selected time in the answer as a Justification. In our example, the question has been interpreted according to the ContextOfUtterance, i.e. as enquiring about the day in which it was uttered ( today ). Example 1.3 Question: Where is Titanic showing in Trento? Answer: Today, Titanic is showing at Cinema Astra in Trento. As an alternative to providing a direct answer with derived Justification, it is also possible to deal with an underspecified question by starting an interaction with the user. With the question in Example 1.3, for instance, the dialogue can be started by asking the user to specify the missing information (e.g. Can you specify to which day your question refers, please? ), or to confirm whether the question has been correctly Page 7 of 29

10 interpreted (e.g. Time is not specified in your question. Do you wish to know about today? ). Complementary information The amount of information provided by an answer does not depend on the presence of Justification. In fact, in all the examples above, the answer contains only the CoreInfo explicitly asked for, while Justification strategies only contribute to contextualizing the CoreInfo without properly adding any information. ComplInfo is additional non mandatory information that can be added to any type of answer if considered useful. In the following examples (respectively without and with Justification) the time at which Titanic will be shown is ComplInfo. Example 1.4 Question: Where is Titanic showing today in Trento? (a) Answer: At Cinema Astra at 3 PM and at 8 PM. (b) Answer: It/Titanic is showing at Cinema Astra in Trento at 8 PM Empty answers We have an empty answer, i.e. null CoreInfo, when the range of elements satisfying the EAT is empty. In this case, a satisfactory answer should necessarily contain some Justification, i.e. an explanation of the reasons for the null CoreInfo, and possibly some ComplInfo, i.e. some related positive information. The CoreInfo can be null either as a consequence of a wrong presupposition in the question or because of a missing constraint. Wrong presupposition. Null CoreInfo due to wrong presupposition occurs if a Constraint mentioned in the question is not satisfied. For instance, in Example 2.1 the reason for null CoreInfo is that Titanic was directed by Cameron and not by Spielberg as incorrectly presupposed by the question. Through (direct) Justification it is possible to explain why the CoreInfo is null while some ComplInfo based on a possible solution of the inconsistency is added as an attempt to make the answer more useful. Example 2.1 Question: Where is Titanic by Spielberg showing today in Trento? Answer: I don t know of any movies named Titanic directed by Spielberg. Titanic by Cameron is showing at Cinema Astra. Missing constraint. Sometimes CoreInfo is empty because of the specific interpretation given to the question. See for instance the question in Example 2.2 (underspecified as far as time is concerned) which, if interpreted as referring to the ContextOfUtterance, leads to null CoreInfo. In this case (derived) Justification gives the reason behind the failure (the requested movie is not scheduled for the day of utterance), while ComplInfo provides the scheduling for the following day. Example 2.2 Question: Where is Shrek showing in Trento? Answer: No theatre in Trento is showing the movie Shrek today. It is showing tomorrow at Cinema Modena. Page 8 of 29

11 Interaction to recover from failure. As an alternative to provide ComplInfo, it is also possible to deal with empty CoreInfo by interacting directly with the user. Examples 2.3 and 2.4, respectively, present possible ways to start such dialogues in the case of wrong presupposition and missing constraint. Example 2.3 Question: Where is Titanic by Spielberg showing today in Trento? Answer: I don t know of any movie Titanic directed by Spielberg. Are you interested in Titanic by Cameron or in movies by Spielberg? Example 2.4 Question: Where is Shrek showing in Trento? Answer: No theatre is showing the movie Shrek today. Are you interested in tomorrow s scheduling? The Interactive Question Answering (IQA) ontology, available under a Creative Commons license on the project web site, is a domain independent ontology developed to formally represent the elements that are used to build question-answer pairs, i.e. interaction turns (see Figure 3 for a graphical representation 5 ). InteractionTurn Question 1 Answer 1 Expected AnswerType + ContextOf Utterance (0/1) Justification* Complementary Information* Constraints* Core Information* Figure 3. IQA ontology The primary issue in the development of this ontology was the representation of the relationship between the answer and its fragments (i.e. core information, complementary information, justification) and also of the Question and its fragments. These relationships had to be of type part of with some additional constraints. Direct primitives of part-whole relations (as studied in mereology and mereotopology) are not included in OWL. However, there are a few workarounds for this problem by using the built-in primitives in OWL 6 and RDFS which (partially) address this issue. Two such approaches, relevant to our set of specifications in designing the IQA Ontology could be: 1. defining a transitive property partof and a subproperty partof_directly 7 and using them to describe part-whole relations in general. As an example, this technique will hold good for expressing the following: 5 Superscripts in Figure 1 are regular expressions with their conventional meaning (i.e. * is used for optional, + for more than one and (0/1) for 1 or 0) Page 9 of 29

12 Engine, Headlight, Wheel is a direct part of (related by partof_directly) Car Crankcase, Carburettor is a direct part of Engine Crankcase is a part of (related by partof) Car (derived implicitly due to transitivity) At this stage, it is useful to point out that in classic mereology, the part-of relation is: Transitive - Parts of parts are parts of whole, i.e. If A is a part of B and B is a part of C, then A is a part of C. Reflexive - Everything is a part of itself, i.e. A is a part of A. Antisymmetric - Nothing is a part of its parts, i.e. if A is a part of B and A is not equal to B then B is not a part of A. 2. using value partitions and value sets in modelling various descriptive features like qualities, attributes and modifiers 8. Here, values act as subclasses partitioning a feature. As an example, the Health of a person (feature) may consist of several values (value partitions) such as: Good health, Medium health and Poor health, and the person cannot have Good health and Medium health simultaneously. Due to various special considerations that need to be included in our Ontology (detailed in Section 4.2), neither of the above approaches in isolation is sufficient to express the concepts in IQA. We therefore use a combination of these two suggestions for creating the IQA. 3.2 Special requirements of IQA The features that need to be expressed in the IQA ontology can be summarized as: 1. The concepts CoreInformation, ComplementaryInfo and Justification need to be defined as a part of the concept Answer and not as its subclasses. The part of relation described here necessarily includes the feature of transitivity (which is the core characteristic of any part of relation). 2. The concepts CoreInformation, ComplementaryInfo and Justification are disjoint from each other and together they represent the class Answer and an Answer contains nothing more. 3. The concepts CoreInformation, ComplementaryInfo and Justification can accept 0 or more values. Similarly, the class EAT should contain at least 1 value. 4. The classes Question and Answer are kind of InteractionTurn and not part of it. Analogous considerations corresponding to points 1 and 2 hold between the concepts Constraints, Context, EAT and the concept Question. While having a transitive property partof would be sufficient to satisfy requirement 1, we would need to resort to value partitions for requirement 2. It is to be noted that enforcing condition 3 might be tricky in this case because OWL-DL does not allow a transitive property (partof in our case) to have any cardinality restrictions. 8 Page 10 of 29

13 3.3 Description of Classes In this section, we will describe the implementation of individual classes in the IQA ontology. Answer The class Answer has been defined as being equivalent to the union of classes CoreInformation, ComplementaryInfo and Justification (using the value partitions approach). This ensures that an answer consists only of the subparts core information, complementary information and justification and nothing else. In addition, these three classes have been described as being disjoint from each other. Without any of its subparts, the information contained in the system s answer would be incomplete. Answer is also defined as being disjoint with the Question class. In the ontology, it is represented as: <owl:class rdf:about="#answer"> <rdfs:label>answer</rdfs:label> <owl:equivalentclass> <owl:class> <owl:unionof rdf:parsetype="collection"> <rdf:description rdf:about="#complementaryinfo"/> <rdf:description rdf:about="#coreinformation"/> <rdf:description rdf:about="#justification"/> </owl:unionof> </owl:class> </owl:equivalentclass> <rdfs:subclassof rdf:resource="#interactionturn"/> <owl:disjointwith rdf:resource="#question"/> </owl:class> Question The class Question is defined analogously to Answer with the subparts of Question being Constraints, Context and EAT. Core Information Before providing the details about the implementation of the CoreInformation class, we shall present the techniques used to describe it. Universal vs Existential To be able to use the transitive partof (or partof_directly) relation mentioned above for representing part-whole relationships on classes, we need to make a choice whether to use universal (owl:allvaluesfrom) or existential (owl:somevaluesfrom) restrictions on them. Each of these methods has advantages and limitations. Before describing these further, it would be helpful to revisit the logical meaning behind universal and existential restrictions. An existential restriction on a property is represented as: R.C = {a Δ b[(a, b) I(R) b I(C)]} Page 11 of 29

14 Here, C is a concept description, R is a functional role while a and b are individuals. An interpretation I consists of a non-empty set Δ (the domain of the interpretation) and an interpretation function, which assigns to every atomic concept A a set I(A) Δ and to every atomic role R a binary relation I(R) Δ Δ. The interpretation function is extended to concept descriptions (like C) by a set of inductive definitions depending on the type of DL used. Similarly, a universal restriction is represented as: R.C = {a Δ b[(a, b) I(R) b I(C)]} Coming back to the IQA ontology, core information would be represented using existential restriction as: CoreInformation partof_directly.answer partof_directly.answer = {a Δ b[(a,b) I(partOf_directly) b I(Answer)]} This expression for Core information describes individuals that participate in at least one relationship along the property partof_directly that are members of the Answer class. In other words, this restriction describes the class of individuals that have at least one partof_directly relationship to an individual that is a member of the class Answer. In the Ontology, this is represented as: <owl:class rdf:about="#coreinformation"> <rdfs:label>coreinformation</rdfs:label> <rdfs:subclassof> <owl:restriction> <owl:onproperty rdf:resource="#partof_directly"/> <owl:somevaluesfrom rdf:resource="#answer"/> </owl:restriction> </rdfs:subclassof> </owl:class> However, using existential quantifier has a drawback, because adding it would mean that CoreInformation (and for the same reason, also ComplementaryInfo and Justification) cannot exist without being a part of Answer. In a broader sense, all these kinds of information may exist with or without being specified as part of an answer to a specific question (maybe as a part of description of some entity in another ontology). But this fact can be ignored here because we are trying to capture an intuitive schema for composition of answers and not a schema for types of information (like core, complementary, etc.). Trying to express the CoreInformation class using universal quantifiers would result in an expression like: CoreInformation partof_directly.answer partof_directly. Answer = {a Δ b[(a, b) I(partOf_directly) b I(Answer)]} This expression describes CoreInformation as the class of individuals that for the property partof_directly only have relationships along this property to individuals that are members of the Answer class. In other words, CoreInformation is any individual that can be related through the partof_directly property only to the Answer class and nothing else. This, again, would not be true in the real world because CoreInformation (and also Page 12 of 29

15 ComplementaryInfo and Justification) is a type of information and does not necessarily need to be a part of an answer. In fact it can be a part of a text explanation of an object in another ontology. In the light of the arguments mentioned above, it seems more natural to use existential restrictions on classes to describe their subparts like CoreInformation, ComplementaryInfo, etc. Interaction turn Even though it could be possible to treat the relation between InteractionTurn and {Question, Answer} in the same way as we treat Answer and {CoreInformation, ComplementaryInfo, Justification} (using part-of and value sets), this might turn out to be a wrong choice. At this point it is important to emphasize on the need for distinguishing Parts (represented by part-of) from Kinds (represented by subclasses). While CoreInformation, ComplementaryInfo and Justification are parts of an Answer in our interpretation, the same doesn t hold between {Answer, Question} and InteractionTurn. Indeed Answer (or Question) is a kind of InteractionTurn and not a part of it. Also, at any point in time, only one of Answer or Question will form an InteractionTurn and not both simultaneously. The following example consisting of a sample class hierarchy will help in explaining this point further: Vehicle Car Engine Crankcase Aluminium Crankcase In this hierarchy, while Car is a kind of Vehicle, Engine is a part of Car, Crankcase is a part of Engine and so on. Although this hierarchy serves well for navigation, it does not take into account the difference between part of and subclass of (representing kind of). For instance, a fault in Engine would mean a fault in Car, while a fault in Car does not necessarily point to a fault in the Vehicle (because Car is only a subclass of Vehicle and not a part of it). In our Ontology, the class InteractionTurn has been defined as: <owl:class rdf:about="#interactionturn"> <rdfs:label>interactionturn</rdfs:label> <owl:equivalentclass> <owl:class> <owl:oneof rdf:parsetype="collection"> <rdf:description rdf:about="#answer"/> <rdf:description rdf:about="#question"/> </owl:oneof> </owl:class> </owl:equivalentclass> <rdfs:subclassof rdf:resource="&owl;thing"/> </owl:class> Page 13 of 29

16 Other classes Other classes in the IQA Ontology follow analogous rules, i.e. Question and {EAT, Constraints, Context} follow similar rules as defined for Answer and {CoreInformation, ComplementaryInfo, Justification}. 3.4 Properties In this section, we briefly describe the way we have defined different object properties in the Ontology. Parts and Direct parts Although defining separate properties for Parts (partof) and Direct parts (partof_directly) is not very important at this stage, some of the future enhancements (that might require deeper hierarchies) envisaged in the Ontology can be very easily implemented with such a distinction already in place. These properties are defined as transitive properties with partof_directly being a subclass of partof. The implementation looks like: <owl:objectproperty rdf:about="#partof"> <rdf:type rdf:resource="&owl;transitiveproperty"/> </owl:objectproperty> <owl:objectproperty rdf:about="#partof_directly"> <rdfs:subpropertyof rdf:resource="#partof"/> </owl:objectproperty> Properties connecting IQA to domain ontology The two properties that connect concepts in IQA ontology to domain ontology are isspecifiedby and hasvalue. The range of any terminal concept (i.e. EAT, Constraints, Context, Justification, CoreInformation, ComplementaryInfo) in the IQA ontology is either a concept or an RDF triple in the domain ontology. The hasvalue property relates a terminal concept in the IQA ontology with an instance of some concept in the domain ontology. It is to be noted that the corresponding concept in the domain ontology is the actual range of the terminal concept if and only if the isspecifiedby property is not used on this terminal object. Otherwise, the actual range is the object of the triple consisting of the instance (subject) and the property value of the isspecifiedby property (predicate). Alternatively, the isspecifiedby is a property denoting that the hasvalue of an answer object is not the actual range of the terminal concept; but the range is the object of the triple consisting of the instance pointed to by hasvalue as the subject and the value of this property as the predicate. If this property is not used, then the value of hasvalue is the actual range. The domain of hasvalue and isspecifiedby consists of the union of classes ComplementaryInfo, Constraints, Context, CoreInformation, EAT, Page 14 of 29

17 Justification while the range of isspecifiedby is of type DatatypeProperty. The implementation of these properties is shown below: <owl:objectproperty rdf:about="#hasvalue"> <rdfs:label>hasvalue</rdfs:label> <rdfs:domain> <owl:class> <owl:unionof rdf:parsetype="collection"> <rdf:description rdf:about="#complementaryinfo"/> <rdf:description rdf:about="#constraints"/> <rdf:description rdf:about="#context"/> <rdf:description rdf:about="#coreinformation"/> <rdf:description rdf:about="#eat"/> <rdf:description rdf:about="#justification"/> </owl:unionof> </owl:class> </rdfs:domain> </owl:objectproperty> <owl:objectproperty rdf:about="#isspecifiedby"> <rdfs:label>isspecifiedby</rdfs:label> <rdfs:range rdf:resource="&owl;datatypeproperty"/> <rdfs:domain> <owl:class> <owl:unionof rdf:parsetype="collection"> <rdf:description rdf:about="#complementaryinfo"/> <rdf:description rdf:about="#constraints"/> <rdf:description rdf:about="#context"/> <rdf:description rdf:about="#coreinformation"/> <rdf:description rdf:about="#eat"/> <rdf:description rdf:about="#justification"/> </owl:unionof> </owl:class> </rdfs:domain> </owl:objectproperty> Other properties Cardinality restrictions have been put on several properties like hascomplementaryinfo, hasconstraints, hascontext, hasjustification, which can have a minimum of 0 values in their range while hascoreinformation, haseat should have a minimum of 1 value in their range. The maximum number of values allowed for the range of the property hascontext is 1. It should also be noted that some properties have been defined even though their respective domains and ranges are already connected by the property partof_directly. This is done to apply extra cardinality restrictions on the ranges of these properties which are not allowed in a transitive relation like partof_directly. For example, the property hasconstraints has as domain Question and range Constraints which are already connected by the partof_directly relation. Having hasconstraints ensures that we can put a minimal cardinality restriction of 0 on the range (i.e. Constraints). The other properties in this Ontology are very intuitive as can be seen from the implementation shown below. The following snippet of ontology presents the actual implementation of cardinality restrictions, the partof_directly relation to various classes and the domains and ranges of respective properties: Page 15 of 29

18 <owl:objectproperty rdf:about="#hasanswer"> <rdfs:label>hasanswer</rdfs:label> <rdfs:range rdf:resource="#answer"/> <rdfs:domain rdf:resource="#interactionturn"/> </owl:objectproperty> <owl:objectproperty rdf:about="#hascomplementaryinfo"> <rdfs:label>hascomplementaryinfo</rdfs:label> <rdfs:domain rdf:resource="#answer"/> <rdfs:range> <owl:restriction> <owl:onproperty rdf:resource="#hascomplementaryinfo"/> <owl:onclass rdf:resource="#complementaryinfo"/> <owl:mincardinality rdf:datatype="&xsd;nonnegative Integer">0</owl:minCardinality> </owl:restriction> </rdfs:range> </owl:objectproperty> <owl:objectproperty rdf:about="#hasconstraints"> <rdfs:label>hasconstraints</rdfs:label> <rdfs:domain rdf:resource="#question"/> <rdfs:range> <owl:restriction> <owl:onproperty rdf:resource="#hasconstraints"/> <owl:onclass rdf:resource="#constraints"/> <owl:mincardinality rdf:datatype="&xsd;nonnegative Integer">0</owl:minCardinality> </owl:restriction> </rdfs:range> </owl:objectproperty> <owl:objectproperty rdf:about="#hascontext"> <rdfs:label>hascontext</rdfs:label> <rdfs:domain rdf:resource="#question"/> <rdfs:range> <owl:restriction> <owl:onproperty rdf:resource="#hascontext"/> <owl:onclass rdf:resource="#context"/> <owl:mincardinality rdf:datatype="&xsd;nonnegative Integer">0</owl:minCardinality> </owl:restriction> </rdfs:range> <rdfs:range> <owl:restriction> <owl:onproperty rdf:resource="#hascontext"/> <owl:onclass rdf:resource="#context"/> <owl:maxcardinality rdf:datatype="&xsd;nonnegative Integer">1</owl:maxCardinality> </owl:restriction> </rdfs:range> </owl:objectproperty> <owl:objectproperty rdf:about="#hascoreinformation"> <rdfs:label>hascoreinformation</rdfs:label> Page 16 of 29

19 <rdfs:domain rdf:resource="#answer"/> <rdfs:range> <owl:restriction> <owl:onproperty rdf:resource="#hascoreinformation"/> <owl:onclass rdf:resource="#coreinformation"/> <owl:mincardinality rdf:datatype="&xsd;nonnegative Integer">1</owl:minCardinality> </owl:restriction> </rdfs:range> </owl:objectproperty> <owl:objectproperty rdf:about="#haseat"> <rdfs:label>haseat</rdfs:label> <rdfs:domain rdf:resource="#question"/> <rdfs:range> <owl:restriction> <owl:onproperty rdf:resource="#haseat"/> <owl:onclass rdf:resource="#eat"/> <owl:mincardinality rdf:datatype="&xsd;nonnegative Integer">1</owl:minCardinality> </owl:restriction> </rdfs:range> </owl:objectproperty> <owl:objectproperty rdf:about="#hasjustification"> <rdfs:label>hasjustification</rdfs:label> <rdfs:domain rdf:resource="#answer"/> <rdfs:range> <owl:restriction> <owl:onproperty rdf:resource="#hasjustification"/> <owl:onclass rdf:resource="#justification"/> <owl:mincardinality rdf:datatype="&xsd;nonnegative Integer">0</owl:minCardinality> </owl:restriction> </rdfs:range> </owl:objectproperty> <owl:objectproperty rdf:about="#hasquestion"> <rdfs:label>hasquestion</rdfs:label> <rdfs:domain rdf:resource="#interactionturn"/> <rdfs:range rdf:resource="#question"/> </owl:objectproperty> 3.5 General axioms Apart from the classes and properties, a few general axioms have been defined to make sure that the classes EAT, Constraints and Context are disjoint from each other. Similarly CoreInformation, ComplementaryInfo and Justification are also disjoint. The implementation of CoreInformation, ComplementaryInfo and Justification is shown below: <rdf:description> <rdf:type rdf:resource="&owl;alldisjointclasses"/> <owl:members rdf:parsetype="collection"> <rdf:description rdf:about="#complementaryinfo"/> Page 17 of 29

20 <rdf:description rdf:about="#coreinformation"/> <rdf:description rdf:about="#justification"/> </owl:members> </rdf:description> 4. Retrieval process In the first phase of the project, we explored various storage systems for storing the RDF data, such as Jena2 (Wilkinson et al., 2003), Sesame (Broekstra, Kampman & van Harmelen, 2002), Kowari (Wood, Gearon & Adams, 2005), KAON (Bozsak et al., 2002). After comparing some important performance characteristics of these systems, including response time, scalability and efficiency, and reasoning capability, we finally selected Jena2 as the RDF storage system for the QALL-ME project (see details in D4.1). Jena2 supports memory-backed storage and database-backed storage. In the first phase, we used the memory-backed storage solution, i.e. storing the RDF tourism data in the file system, since this storage solution is very simple and also quite efficient for small amounts of data. However, this solution is not scalable. As the amount of RDF data increased, the memory-backed storage solution became inefficient because of the limit of the computer s memory. In order to deal with this limitation, we adopted the database-backed storage solution. The RDF data was imported into a MySQL relational database. For the first prototype system, Jena s usual database schema (RDB) was used. This schema was designed for supporting a fine-grained API and basic graph patterns. During the second phase, Jena s new database schema (SDB) was released (in November 2007). It was designed for larger graph patterns rather than API operations, and has two layouts Index (which uses a four-byte sequence id to reference a node), and Hash (which uses an eight-byte hash to reference a node). In order to determine which of the available schema is most appropriate for our purposes, we performed two simple experiments to compare two time-related indicators that are important for a QA task loading performance and query performance. The experiment results indicated that (1) SDB-Index was the most efficient database schema for loading the RDF data from the file system into a relational database; (2) SDB and RDB database schema had similar response time for running simple queries; (3) SDB schema was much faster than RDB when running complex queries; and furthermore SDB-Index was a little faster than SDB-Hash. According to the above results, we selected the SDB-Index schema for the second prototype system, replacing the RDB schema used in the first prototype system. During the third year of the project, Jena released a third database schema (TDB), which provides for large scale storage and query of RDF datasets using a pure Java engine. TDB has two index options incremental which loads the RDF data incrementally and parallel which rebuilds secondary indexes for new RDF data in parallel. Since response time is crucial for a QA system, we need to find the database schema which can support the fastest query search. To test TDB s query execution performance, we carried out an experiment on the basis of the experiments performed in the second phase (see details in D4.2) to compare this new schema against the Jena s former database schemas RDB and SDB-Index. We used the same twelve SPARQL queries (ten simple queries Q1~ Q10 and two complex queries Q11~Q12) as those used in the experiments in D4.2. These SPARQL queries were executed over RDF triples. The experiment results are given in Table 2. Page 18 of 29

21 Query TDB (parallel) TDB (incremental) SDB-Index RDB Table 2: Query Execution Time Using Different Jena Storage Schemas Time unit is ms (millisecond); Each SPARQL query was executed 10 times to get the average execution time. As shown in Table 2, TDB s query execution time is similar with RDB s, but both are slower than SDB-Index. It indicates that SDB-Index is the proper data storage solution for the QALL-ME system. Thus we still used this database schema for the third prototype system. 4.1 Scaling up the amount of data During the last year of the project FBK also addressed the problem of scalability of the QALLME framework with respect to the amount of data managed by the system. The goal was to test the system performance considering an application domain whose size is one order of magnitude bigger than the one already successfully experimented in the second year of the project. In this direction, FBK, supported by Comdata, started collaboration with Zapster ( a portal providing information about movies/cinemas throughout all Italy. While a detailed description of the Zapster scenario, from the user point of view, is reported in Deliverable D1.2, in this section we report the amount of data provided by Zapster daily, and managed by the QALL-ME system. On average, there are several dozen of thousand instances which populates the QALL-ME ontology very day, which is one order of magnitude bigger than the Trentino Cultura database we have been using for the second QALL-ME prototype. As an example, the tables below report the exact number of instances uploaded by QALL-ME from Zapster on October 12 th 2009, divided according to entities, relations and attributes, for a total of more than 160,000 instances. ENTITIES qmo:cinema 874 qmo:contact 874 qmo:destination 525 qmo:director 3327 qmo:distributor 81 qmo:event 765 qmo:genre 66 Page 19 of 29

22 qmo:movie 9306 qmo:postaladdress 874 qmo:star qmo:datetimeperiod 167 qmo:timeperiod 167 Total entities RELATIONS qmo:isindestination 874 qmo:hasinfrastructure 874 qmo:hascontact 874 qmo:hasevent 765 qmo:haspostaladdress 874 qmo:hasdirector 7234 qmo:hasdistributor 2713 qmo:hasgenre qmo:hasstar qmo:haseventcont 765 qmo:hasperiod 765 qmo:isinsite 765 Total relations ATTRIBUTES qmo:name qmo:telephone 859 qmo:postalcode 842 qmo:street 874 qmo:description 4616 qmo:duration 8067 qmo:originaltitle 5890 qmo:releasedate 2512 qmo:endtime 113 qmo:starttime 167 qmo:hasdateperio 167 qmo:hastimeperio 167 Total attributes We experimented with the Zapster domain. In order to make the processing of the user requests fast enough (i.e. real time), a number of optimizations were required with respect to the second year prototype. Specifically, we optimized the entity recognizer and the SPARQL queries. As for the entity recognizer, we moved from a language model approach, which was considered too slow, toward a two steps approach, following the typical methodology applied in named entity recognition. The first step consists in the identification of the tokens in the request that might represent a certain kind of domain entity. This step is carried out using string inclusion operations between the tokens of the questions and the list of entities stored in the ontology. In the second, each entity recognized in the first step is disambiguated among the categories it can belong to. This step is carried out using classification techniques based on machine learning algorithms (i.e. WEKA SVM algorithm). Page 20 of 29

23 The optimization of the SPARQL query was carried on considering a re-ordering procedure of the conjunctive clauses of the query: the clauses that allow the higher reduction of the solutions are placed first. The reduction of solutions allowed by a clause is computed as the ratio between the potential instances of the concept mentioned in a clause and the number of solutions for the clause: the higher the ratio, the higher the reduction of solutions. Figure 5: The abstract structure of the domain ontology 4.2 Adaptation to the bibliographical domain A portability study was carried out at University of Wolverhampton in order to assess what adaptations are necessary to move to a new domain. The domain of bibliographical entries was selected as it poses similar challenges as the domain of tourism. In order to develop a prototype for the bibliographical domain, an ontology was developed (described in Section 6.4.1), the existing Information Extraction modules had to be adapted to convert unstructured data to the QALL-ME format (described in Section 6.4.2) and the web services had to be adapted to address the particularities of the new domain (described in D7.3) Page 21 of 29

24 4.2.1 The QALL- ME ontology for the bibliographical domain Given that the scope of the new domain consists of academic citations, we could not use the existing QALL-ME ontology and instead we had to find an ontology which: uses standard metadata terminologies such as Dublin Core (dc and dcterms); supports the entry types used by the open BibTeX reference management software or other similar schemes; allows arbitrary keyword indexing schemes; and uses dereferenceable URIs for interoperability with other systems (faceted browsing, semantic web mash-ups) We decided to build an ontology around the BibTeX standard, as it is very popular in the academic community and it is supported by many citation management systems. The advantage of using BibTeX as the format of the input data is that there already are several ontologies that can be used (e.g. the MIT bibtex ontology 9, bibo 10, SWRC 11 ). The differences between them are the vocabularies used and details such as author list representation and event representation. We chose to use a subset of SWRC, an ontology for modelling entities of research communities and relationships amongst them. The main entities involved are: persons (authors and editors), organisations (publishers, research institutes, universities), publications (articles, conference papers, theses, book chapters) and collections (proceedings, journals, books, series). A relevant subset of the Dublin Core metadata terminology is used to describe the properties of the bibliographic entries. An example of a conference paper defined by our ontology can be seen below (in the TURTLE syntax): qa2:mitkov1998 rdf:type swrc:inproceedings; dc:title "Robust pronoun resolution with limited knowledge"; terms:issued "1998"; swrc:pages " "; terms:ispartof qa2:conf/acl/2008; dc:creator qa2:mitkov_r_. qa2:conf/acl/2008 rdf:type swrc:proceedings; dc:title "Proceedings of the 18th International Conference on Computational Linguistics (COLING'98)/ACL'98 Conference"; swrc:address "Montreal, Canada". The SWRC terminology is also used by the DBLP 12 (Digital Bibliography & Library Project) computer science bibliography website. This makes it easy to augment the bibliographical data information from other sources. This can be further extended by employing protocols such as Open Archives Initiative (OAI) Metadata Protocol Handler which is an interchange format that facilitates metadata harvesting from electronic repositories or the PRISM 13 protocol. Whilst the data we collect does not provide us with details such as affiliation relations, this information could be added Bibliographic Ontology Specification 11 Semantic Web for Research Communities Page 22 of 29

25 from such sources, enabling the system to answer questions such as Scientists working in which German universities have published papers about Question Answering in 2008? In addition to the ontology used to encode information about publications, a second ontology was created to represent terms referring to topics and relationships between them. Investigation of existing resources revealed that the SKOS (Simple Knowledge Organisation System) ontology 14 is appropriate as it provides a model for expressing the basic structure and content of concept schemes. A concept scheme is defined in the SKOS ontology as a set of concepts, optionally including statements about semantic relationships between those concepts (e.g. thesauri, classification schemes, terminologies, glossaries, etc.) The SKOS ontology is useful for our purposes as it encodes relations such as SKOS:BROADER, SKOS:NARROWER, SKOS:BROADERTRANSITIVE and SKOS:NARROWERTRASITIVE and allows the asking of questions such as: What did Constantin Orasan publish about summarization? and the retrieval of papers which were tagged with multi-document summarization. A part of the terminology corresponding to computational linguistics can be found in Figure 7. Figure 7: Part of the terminology corresponding to computational linguistics 14 Page 23 of 29