Bit Dev

Download as pdf or txt
Download as pdf or txt
You are on page 1of 14

GSOC 2017 Application

Contact Information
Name: Ram Ganesan Athreya
E-Mail: ​ramgathreya@gmail.com
LinkedIn: ​https://www.linkedin.com/in/ramgathreya

Project
Project Name:
First Chatbot for DBpedia

Project Description:
The requirement of the project is to build a conversational Chatbot for DBpedia which would be
deployed in at least two platforms (including social networks).

There are three main challenges in this task. First is understanding the query presented by the
user, second is fetching relevant information based on the query through DBpedia and finally
tailoring the responses based on the standards of each platform and developing subsequent
user interactions with the Chatbot.

Based on my understanding, the process of understanding the query would be undertaken by


one of the mentioned QA Systems (HAWK, QANARY, openQA) the Chatbot simply needs to
connect to it via API. Based on the response from these systems we need to query the DBpedia
dataset using SPARQL and present the data back to the user in a meaningful way. Ideally, both
the presentation and interaction flow needs to be tailored for the individual social
network/platform since each network has its own range of capabilities, limitations and best
practices.

I would like to stress that although the primary medium of interaction is text, platforms such as
Facebook​ suggest that a proper mix between chat and structured interactive elements such as
images, buttons etc would lead to better user engagement. So I would like to incorporate these
elements as part of my proposal.

If you would be willing and able to work on another of our suggested project ideas instead,
which ones?
Question Answering from DBpedia to the whole LOD cloud

Please describe why you are interested in this specific project:


I find this project personally interesting because I see virtual personal assistants as the logical
next step in technology. When you really think about it all the information that is required to
make AI useful such as images, maps, places, entertainment (books, movies, videos etc), my
contact list and everything else I can think of is available in large quantities and more
importantly in a structured format which can be easily queried using technologies such as SQL.
All that remains is to create a user interface layer to seamlessly plug into and connect all this
information together. To a certain extent search engines achieve this goal but it can be vastly
improved with conversational bots especially when they can understand context, meaning and
the relationships between entities which is what the DBpedia and DBpedia Spotlight projects
are trying to do. This is also the primary motivation behind my present research on Question
Answering over Linked Data.

Please describe a tentative project architecture or an approach to it:

Image Link

The Chabot system can be broadly divided into two parts:


1. The Chatbot Server
2. Associated Storage Services (Database and Cache) that would store user information.
As stated in the requirements of the idea, the Chatbot server needs to be an adaptive interface.
That is, it must be able to support multiple platforms such as Facebook, Slack, Web, etc. The
process by which the Chatbot server handles requests can be divided into 6 steps as follows:

Step1: Incoming Request


Typically any request that comes from a particular platform would have its own dedicated
webhook URL/endpoint eg: ​https://chatbot.dbpedia.com/facebook-webhook​ or web-webook
etc. The request contains information about the query that the user is asking as well some form
of identification of the user for example the User ID when accessed from the web or Facebook
ID if user uses the bot through FB etc.

Step2: Classify Request


Incoming requests can be of four types, they can be:
1. Natural language question for example ‘Give me the capital of Germany’
2. Command Requests such as About, Help, History
3. Banter or casual conversation such as ‘Hello’, ‘How are you?’ etc.
4. Parameterized Requests eg: When user clicks on links in the information presented for a
query

Step 2a: Classifying Pure Text Requests


For pure text requests, we can create a classification model which can classify the question into
a command or a banter. There are several ways of doing this ranging from using dedicated third
party services to using standard open source libraries or building our own. For now, I am
proposing to use wit.ai which is a free service provided by Facebook that can be used for this
task although I am open to learning and implementing any other service that can achieve this.

Here I have created a short list of commands and banters that the bot might commonly
encounter. Please note this is not an exhaustive list.

Command List
1. About
2. Help
3. History
4. Start Over/Restart

Banter/Conversations
1. Greeting (Hi, Hello etc)
2. What is your name?
3. Who made you?
4. What can you do?
5. How are you?

We would create some training data (different variants of asking for this information) for the
above mentioned types and use it to train the wit.ai model. Ideally, the model would classify
any incoming request into any one of the above mentioned categories. If it fails to do so then
the request is probably an NLP question.

Step 2b: Parameterized Questions


Parameterized Questions would generally have some inherent structure in them through which
we can decipher how we would like to present the response. Consider the scenario where the
user asks a question about ‘Germany’ and the bot presents information such as Germany
(label), Berlin (capital), map, etc. with a link for Berlin. When the user clicks on the Berlin link
we need to provide additional information about Berlin. We could have extra parameters in the
request identifying Berlin such as DBpedia Resource URI, etc. and we can use this parameter to
process the request without having to resort to any NLP techniques.

A parameterized request could be of the form:


{
"​params​":​ {
"​request_type​":​ ​"​entity_info​",
"​dbpedia_uri​":​ ​"​http​:​//dbpedia.org/page/Berlin"
}
}

For a regular request it could simply be a query with no additional parameters:


{
"​query​":​ ​"​What​ ​is​ the capital of ​Germany​?"
}

Step 3: Handle Request Based on Classification


In this step the Chatbot server decides on how to process the request based on the request
parameters as well as the information derived from previous steps. The result from the
previous step would be one of the following:
1. A Natural Language Question that needs to be resolved using NLP
2. A Command Request
3. A Banter Request
4. A Parameterized Request

Step 3.1 and 3.2: Get/Set User and Session Information


We also store the user information in the database if the user is accessing the bot for the first
time. We basically store their User ID for future identification, source (the social network from
which they are accessing the bot) as well as any basic information for personalization such as
name, gender, etc. for future use. All user information is stored persistently in the MySQL
Database. We also use any context information which is stored in a Redis cluster that may be
useful in processing the user query.

Step 4.1: Get Answer for NLP Query


If the question is a natural language question then we need to resolve its meaning. So the query
would be forwarded to a Question Answering Service such as HAWK, QANARY, openQA etc. The
result from the QA system would typically be an array of DBpedia Resource URIs.

Step 4.2: Get Information from DBpedia


The chatbot can then query DBpedia using the individual Resource URIs and get basic
information such as label, thumbnail, abstract, corresponding Wikipedia URL which most
DBpedia resources are likely to have. But we can go one step further and give more information
depending on the type of entity that is returned. Below I have compiled a small list of DBpedia
properties which can provide more useful information based on its rdf:type. Again this is not
exhaustive merely illustrative of what is possible.

DBpedia rdf:type Example Additional Information that can be Displayed

dbo:Country Germany dbo:anthem, dbo:currency, dbo:flag, dbo:language,


dbo:capital, dbo:populationTotal,
dbo:populationDensity, geo:lat, geo:long

dbo:Book The Hobbit dbo:author, dbo:publisher, dbo:releaseDate,


dbp:followedBy, dbp:precededBy

dbo:Person J R R Tolkien dbo:birthDate, dbo:child, dbo:deathDate,


dbo:deathPlace, dbo:nationality, dbo:occupation,
dbo:spouse

dbo:Film Titanic dbo:Work/runtime, dbo:budget, dbo:director,


dbo:gross, dbo:starring

Ideally, this can be extended further. For example, for Berlin we can additionally find places of
interest which are located in Berlin. We can also extrapolate data from WikiData.

A command request would give some preset message back to the user as is the case of
commands such as help or about. In the case of History we can maintain a list of previous
queries that the user has made to the Bot in the MySQL database and show it as a response to
the user. The Start Over option is applicable when the user gets stuck or is unsure what to do
next and acts as a way for them to restart the conversation.

For a banter request we can provide some preset canned responses. To prevent the bot from
seeming monotonous we can have several variations of these responses. For example, when
the user types ‘Hi’ or something similar we can reply ‘Hi how are you doing today?’ or ‘How
may I assist you?’ or ‘What can I help you with?’ etc. We would have to continuously monitor
usage of the bot to understand how users interact with it and increase our coverage of these
responses as applicable.

In Parameterized Requests we would typically know what DBpedia URIs need to be queried so
we simply need to make the query to DBpedia and return the response to the user.

Step 5: Generate Response


Now that we have the response that we need to send to the user we need to customize it for
each platform. This is needed because each platform has its own individual capabilities,
limitations as well as specific structure for the API response. For example, in Facebook we can
display a diverse set of interactive elements such as plain text, images, videos, buttons,
carousels etc while in Twitter we are restricted to mostly text which are usually limited to 140
characters. Also, in the case of Twitter we may want parts of the response to have hashtags
since it is a capability that the platform provides and can improve the usefulness of the
response. We can also present follow up interactions in the form of buttons or platform specific
interaction elements such as ​quick replies​ to augment the user experience.

Step 6: Send Response


Finally, we send the response back to the user via the dedicated URL for each social platform or
to the web interface. In the case of a response to a web interface (for example a chat interface
in a browser) we would additionally need to implement the client side code to render the
responses in HTML format along with styling in CSS and orchestration using Javascript. Another
option for the web interface would be to use existing implementations such as ​AKSW Genesis
as a base for the front end which would integrate to the chatbot backend via a webhook.

Additional Features
In this section I would like to highlight some additional features which are not core to the
Chatbot but are good to have and can be implemented in subsequent iterations.
1. Internationalization: Multilingual Support, both for queries and responses
2. Tips: we can occasionally show messages to the user on how to effectively use the
chatbot
3. Bookmarks: Users can bookmark frequently accessed DBpedia Resources
4. Notifications: Today’s Featured Article, In The News, On This Day etc (based on
Wikipedia Home Page)
5. Games: Trivia/Quiz
6. Wikipedia/DBpedia Polls: For important decisions or feature requests etc
7. Analytics Dashboard (backend system to understand user queries and conversation
flows and thereby improve the Chabot)
8. Alexa Skills or Google Actions for Smart Home Assistants

Example Scenario: A Typical Bot Conversation


Consider a simple scenario where the user types the query ‘Tell me about the film Titanic’. The
following could be a possible bot conversation. I have used Facebook Messenger for the
example but this can be extended to other platforms as well.

Please detail an expected project plan and timeline with milestones:

I am proposing an agile approach where the work is generally divided into two week sprints.
Some notable exceptions are Sprint 5 which is roughly 3 weeks. More time is allocated here
since we finish the bulk of the development at the end of this phase and push to production. So
more time may be required for handling issues while deploying to production and ensuring
stability. Sprint 6, the final 10 days are devoted to ensuring that the system is working properly
in production and it would be advisable not to introduce any big changes at this point.

The sprints are designed in such a way that at the end of each sprint we have a functional
system that can address at least one aspect of the final system. In subsequent sprints I try to
incrementally improve the features that the Chatbot can handle. I am also proposing a Test
Driven Development approach so that reliability can be ensured at every stage.

Time Period Activities Milestone

May 4th to May 1. Touch base with mentors -


29th (Community 2. Finalize initial plan and features
Bonding Period) 3. Finalize technologies to be used and initial
architecture
4. Understand software development
practices/processes and coding standards used
by the DBpedia team such as tools, best
practices/code conventions, SVN/Git Branching
procedures
5. Understand and subscribe to the
communication channels used (Slack, Mailing
Lists etc)
6. Understand the basics of the Question
Answering and NLP Technologies needed within
the context of the project

Sprint 1 -​ May 30 1. Create webhook integration with at least 1 A barebones bot that
to Jun 14 social platform is integrated with one
2. Enable API integration with the Intent social platform and
Recognition service as well as QA System and can answer at least
DBpedia one command and
3. Handle at least one command and banter based one banter
on intent conversation
4. Generate corresponding response for the
command and banter
5. Send response back to the Social Network
6. Create basic test cases for above mentioned
scenarios

Sprint 2 -​ Jun 15 1. Handle at least one type/class of natural A bot that can answer
to Jun 30 (Phase 1 language questions (eg: Person, Country, Book at least one class of
Evaluation on etc) questions
June 30) 2. Generate corresponding response for the
natural language question
3. Deploy to a staging environment for testing by
the community
4. Improve Test Coverage and Bug Fixing

Sprint 3​ ​-​ Jul 1 to 1. Integrate one more social network A bot that can answer
Jul 14 2. Refactor code as necessary to accommodate at least one class of
multiple social networks questions in two
3. Improve Test Coverage and Bug Fixing social networks

Sprint 4 -​ Jul 15 to 1. Handle one or two more natural question types A bot that can answer
Jul 28 (Phase 2 2. Handle one or two more commands and banter few more natural
Evaluation on Jul conversations question types,
28) 3. Handle edge case scenarios as they arise commands and
4. Improve Test Coverage and Bug Fixing banter conversations

Sprint 5 -​ Jul 29 to 1. All commands, banters and finalized question A bot that can answer
Aug 19 types should be completed by the end of this all question types as
phase envisioned in the
2. Closed Beta Release in a Production requirements. Bot is
Environment and actual User Testing deployed to
3. Monitoring of User Interactions with the Bot production and user
4. Identification of bottlenecks in interaction and testing begins
coming up with improvements
5. Improve Test Coverage and Bug Fixing

Sprint 6 -​ Aug 20 1. Changes based on actual User Practically a code


to Aug 29 (Final Feedback/Analytics/Monitoring freeze. Only minor
Day on Aug 29) 2. Cosmetic Changes eg: Text Changes (Minor but modifications are
important) done
3. Adding Privacy Policy, Terms of Service etc if it is
applicable
4. Improve Test Coverage and Bug Fixing
5. Documentation

Please include in your plan how will you evaluate the performance of your contribution (in
terms of time, or accuracy, or both), as well as which data sets you will use for that
evaluation:
There are four aspects to evaluate the performance of the chatbot. They are:
1. User Experience
2. Accuracy of Response
3. Speed of Response
4. Scalability, that is number of concurrent requests that the bot can handle

User Experience
Before we analyze the User Experience for the Chatbot we first need to define the target user
base and a baseline to compare it to. It is quite obvious that since this is a general purpose
information Chatbot it should (at least in some respects) outperform Google Search since that is
where users go to seek answers or information. So I propose Google Search as a possible
baseline for our evaluation.

A typical user is usually interested in information that is happening right now or something that
is likely to happen in the future such as ‘When is Game of Thrones Season 7 going to air ?’
(Answer: July 16 2017). Unfortunately DBpedia may not be the best resource for getting this
kind of information since it is updated periodically based on facts in Wikipedia that have
already happened. So we need to target users who are more likely to leverage DBpedia’s
strengths which is its extensive structure and organization of information/facts that have
already happened. Based on this fact I believe the target user base who are most likely to find
the chatbot useful would be researchers, scientists, journalists, students, teachers, etc. who not
only need access to information but also need to understand the relationships between them.
For this target user base we can create a survey or questionnaire to evaluate the chatbot. The
questions could include the following (all are scored 1 to 5 where 1 is Strongly Disagree and 5 is
Strongly Agree):
1. Relevance: The responses from the chatbot was what I was looking for
2. Comprehensiveness: The responses from the chatbot covered all the information I was
looking for
3. Relatedness: The responses from the chatbot illuminated meaningful relationships
between the answer and related entities
4. Presentation: The responses from the chatbot was presented in a manner that could be
effectively/efficiently consumed
5. Value: It was easier to find the answer through the chatbot than through traditional
methods (Google search, books etc)
6. Stimulation: Information surfaced through the chatbot gave me more ideas and insight
in the area/field I was researching
7. Stickiness: In the future I would prefer to find answers through the Chatbot over any
other medium (assuming it is a question that the chatbot can answer)

Apart from this we can also track general quantitative metrics such as:
1. Average number of words per query
2. Average Time Spent (per Session)
3. Number of Sessions (total as well as per User per Week)
4. Conversation Length (per Session)
5. User Churn (Week on Week)
Accuracy of Response
Established public datasets and benchmarks are available for evaluating the accuracy of
response for a question answering system. Some example benchmarks that we can use for this
project are:
1. QALD 7
2. WEBQUESTIONS
3. TREC QA Dataset
But among the above mentioned datasets I feel ​QALD 7​ is the most applicable dataset for our
task.

Speed of Response
Since the Chatbot is essentially a web service we can use tools such as ​Apache jMeter​ to
analyze its performance and response time. We can use standard metrics such as ​95th
percentile response time​ for calculating the efficiency of the system in handling user requests.

Scalability
Scalability of the Chatbot can also be tested through Apache jMeter. We ​load test​ the
application to find out how many concurrent requests it can handle while still maintaining
acceptable levels of Quality of Service and plot concurrent requests vs response time as a
graph. The graph would be asymptotic in nature and would tend towards infinity after a certain
threshold of requests. This threshold is the approximate number of requests the system can
handle without breaking down.

Technical Skills

Please describe in a few lines your programming knowledge or experience (if any):
Fresh out of college, I worked in a startup for over 4 years. I started as a Mobile and Web
Application Developer for the first two years. During this time I was solely responsible for
building our mobile product from scratch in both Android and iOS. I also did a little bit of
machine learning, specifically multivariate linear regression for predicting the price of used cars
in India which was the cornerstone of our product.

In a nutshell, I have extensive experience with web technologies both frontend and backend
including deep knowledge of web architectures such as MVC, LAMP etc. I also have experience
in DevOps and Testing Tools used in reliably deploying and scaling infrastructure using Amazon
Web Services (AWS), Continuous Integration and Continuous Delivery through Jenkins and
Automated Testing using Selenium with Cucumber and Apache jMeter for Load Testing.

Please describe any other project related experience (if any):


CarAndBike, the startup I worked on is a service used by over 4.5 million users in India. I was a
key member of the founding team and helped in not only building the initial systems from
scratch but was also involved in product decisions, such as ideation on how the product should
be built and the directions we should take. I also helped build the core technology team and
hired around 10 people.

Please provide one or more URLs to code samples that you have written in the past or to
DBpedia Spotlight's SVN/issue tracker for which you have provided a fix in the form of a pull
request:
I built a ChatBot recently for a hackathon called ​SunDevil Assistant​ which gives information
about places and events happening in the university campus. It is written in Node.js and the
NLP engine is powered by Facebook’s wit.ai.

Open Source

Please describe any previous Open Source development experience:


I have made some minor code contributions to ​Wappalyzer​ which is a cross-platform utility
(Chrome/Firefox Extension) that detects the technologies used on websites (eg: Server Side
Languages, Frameworks, Analytic Tools etc).

Why are you interested in Open Source development ?:


Open Source over recent decades has become an important part of software development. All
my work depends on Open Source Technologies and I owe most of my accomplishments to it. I
have always wanted to contribute something impactful in return for all that I have received
from the community but till now couldn’t find a viable pathway for that. So I feel this could be a
great opportunity for me to make a meaningful contribution to a very important Open Source
Project and I am excited to give it my best.

Background and Education

What school do you attend?


Masters in Computer Software Engineering (Arizona State University, US): 2017 - 2019

Previous Degrees
Masters in Free and Open Source Software (Anna University, India): 2012 - 2015
B.Tech in Information Technology (Anna University, India): 2008 - 2012

What is your specialty/major at the school?


Software Engineering

How many years have you attended there?


Around 4 months (since Spring 2017)

Research

What is your current research experience? Please point us to the best paper you have read
(preferably in the context of your project proposal), and the best paper you have written, if
any.
I would like to include the product requirement document (​PRD​) that I wrote and implemented
when I was building the Chatbot (​video​) in my previous company since I feel it is relevant to this
proposal.

Research Papers/Articles relevant to the project:


Is Question Answering fit for the Semantic Web?: a Survey​ (Academic)
How to get people to use your chatbot every day​ (Industry)

Present research in ASU:


In my present master’s research I am exploring the use of Semantic Technologies in building
end to end Question Answering systems that can aid users as personal assistants in specific
closed domains.

Paper I have written previously:


While I was working in India I co-authored a paper (published in IEEE Computer Society) called
‘​A Public Cloud Based SOA Workflow for Machine Learning Based Recommendation
Algorithms​’.

Would you be interested in co-authoring a conference paper with your mentors about your
work in GSoC 2017?
Yes, definitely.

Summer Plans

What city/country will you be spending this summer in?


I will be spending my summer in Tempe, Arizona (USA)

How much time do you expect to have for this project (est. per day and per week)?
I can easily spend 4 to 5 hours a day on the project

Please list jobs, summer classes, and/or vacations that you'll need to work around:
No other plans for Summer at present

GSoC Experience
I have not participated in GSoC before

Why did you decide to apply for the Google Summer of Code ?
This project is in an area relevant to me and my research in Question Answering and I am
deeply passionate about Personal Assistant Technologies which I feel will be the next big wave
in computing.

Why did you decide to apply for a DBpedia Spotlight project ?


It is very relevant to the work I am presently doing and if possible I am also hoping to establish
some contact with the AKSW Project for mentorship and guidance with my research since they
are doing pioneering research in the area of Semantic Technologies.

And finally

Why should we take YOU?


Unlike the other GSoC ideas, this project requires a person not only well versed in the technical
aspects of semantic technologies but also someone who understands how to build products for
consumers and has a deep understanding of product development and User Experience. I hope
that based on my past experience and my proposal I was able to persuade you that I possess
the required mix of skills which are necessary for this role.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy