Researchers and companies are making great efforts to create new ways of interaction with a increasing number and types of electronic devices, with particular attention to the conversational interface, whether spoken or written. The cultural heritage domain can bring many benefits from the great effort in this field, as a smart conversational system can provide both room/hotel/apartment information and information related to the area, natural or cultural points of interest, tourist routes, social events, history etc. The paper's main goal is to present a quick and effective service to the tourists visiting a city for the first time. Learning the cultural preferences of the users can enhance customer satisfaction, since a smart system can propose them customised tours in order to reach point of interests according to the expressed preferences. The interaction with the user is simplified by a conversational interface (chatbot).
The Chatbot4Heritage (CB4H) project was born with the aim of integrating and centralising, on a single platform, information related to the tourism sector in Campania, generally from heterogeneous sources. In fact, the information a tourist may need during his or her stay ranges from details on local cultural sites, to upcoming cultural and entertainment events, the location of various types of services (e.g. in the catering sector), updates on the status of mobility, making it necessary to carry out numerous searches on different websites and worsening the overall user experience.
the information coming from multiple event aggregator websites, transform it into a common
format and, through the mediation of an Enterprise Service Bus, store it in special databases. This
information can then be made available to client applications, including a Chatbot[
with a increasing number and types of electronic devices, with particular attention to the
conversational interface, whether spoken or in writing. The cultural heritage domain can bring many
benefits from the great effort in this field, as an intelligent conversational framework can include
both room/hotel/apartment information[
from social networks[
services, like underground, by implementing a routing service for tourists[
• Detection of the nearest stop to a given tourist’s attraction.
TravelBot[
• Informing the user about the working timetables of metro’s services.
In order to retrieve information about locations, events or other relevant information, we have to
chose a set of sources considered reliable. Then, the obtained data-set must undergo a process of
processing and cleaning, removing formatting errors and non machine readable elements, so that
the information contained in it can be inserted in a natural language sentence[
architecture, in fact, each module is developed independently and can be connected and removed from the main system without compromising the others. If, conceptually, the chatbot is considered a front end module, then it is possible to delegate data extraction and cleaning operations to other back end modules, using the Service Bus as an intermediary. The chatbot, at this point, can use the received data immediately, without having to process it further at runtime.
Some example components were chosen and described in Figure 1: a scraper, whose implementation in Python is described here through the Scrapy framework, for the Napolitoday.it website; an external API, that of the Yelp website; a MySQL database, which in this field is identified as
WSO2. WSO2 Enterprise Integrator has a graphical drag-and-drop interface for the configuration of the message flows between one component and another. One of the main features of a Service Oriented Architecture is the possibility to configure the interactions between components, instead of defining them entirely by code.
Information extracted from web pages sources are processed and stored in the system’ Knowledge Base. The Knowledge Base was implemented in Prolog language, taking advantage of its ease of use. The code will be divided into: • Facts: they report certain data known by the machine.
• Rules: they manipulate the facts to obtain data useful to the end user.
3.1. Facts
conn(battistini, cornella, 2).
It links a list of tourist attraction to their nearest stop.
3.2. Rules
The rules can enhance the inferential process that retrieve customised information
according to user preferences. Further enhancement can be taken with the exploitation of semantic
techniques[
Append The “append” rule, like his name suggest, will take care of appending one element to an existing list and it will give a new resulting list as an output.
• [Head1|Tail1] = List where you want to append an element. • List2 = Element or list of elements that you wish to append.
• [Head1|TailResult] = Result.
First part of the code, by using a simple fact, establishes the result of appending an element to an empty list. In the second part then we will use a rule that with a recursive call, taking advantage of backtracking, delete the head of [Head1|Tail1] and continues until the list is empty, after that it starts to rebuilt a new list starting from tail to head, using as a tail List2. This rule will come in handy when we will need to find out how many line change we have to do during end user’s journey. 1 append([],X,X). 2 append([Head1|Tail1],List2,[Head1|TailResult]):3 append(Tail1,List2,TailResult).
Change We use average time to go from one stop to the next, to check how many lines the tourist must change.
• T = Average time between two stops. • Lc = List of changes, initially empty and used as a temporary.
• [T |Ris] = A second list of changes, needed to make append rule to work and to get a result.
The rule will initially check if given T value is inside Lc by using: not(member(T,Lc)). After that if the result is true, append rule will add the given T value to [T|Ris]. Otherwise we use append with an empty list, so it will not add nothing to [T|Ris]. Result will be a list containing a maximum of three elements, that it will be then used to determine how many lines the tourist must change. 1 change(T,Lc,[T|Ris]):2 not(member(T,Lc)), 3 append([T],Lc,[T|Ris]). 4 change(T,Lc,[T|Ris]):5 member(T,Lc), 6 append([],Lc,[T|Ris]).
Len len works pretty much like append with a recursive call (backtracking) of itself and using a given fact: len([],0). goal is different, we need to evaluate the length of a given list, in our case that list will be Lc.
• [_HEAD|TAIL] = List.
• N = Number of elements.
Decr This simple rule will decrement P by 1 and it will store the result in Q. decr will work with change and len to work on Lc, we will see that our main goal is to get the number of elements in Lc and decrement that number by one to get our result.
Connection connection is a rule that takes two stops as input and calculates the list of stops, line changes made and duration time of the journey. The algorithm takes care of solving the "travel salesman" problem.
Rule’s arguments are: • Fs = First stop. • Ls = Last stop. • Ms = Middle stop. • Lc = List of changes. • Pl = Prohibited list. • T = Total time of journey. • N1 = Number of changes. • Result = Non decremented list of changes.
• L1c = Temporary list with last stops to do.
(Fs) and last stop (Ls) by using rule conn1 and checking after if these two stops are member of Pl. Otherwise if this first part is false, the machine will search for a middle stop Ms and check if there is a direct connection to first stop (Fs). When this stop is found, the machine will check if both stops are not in the prohibited list using not(member) after that change rule will be called checking if there was a line change from one stop to another. Change rule as we saw makes a list made of average times taken only once (in this specific case), so the maximum length of this list will be three, decreasing this value by 1 will give us N1. Please note: Both Pl and Lc must be empty list while calling connection in a query, because when the tourist starts his journey he have not travelled to anywhere still. Also neither first stop and last stop can be prohibited stops. Connection is going to use a recursive call that will find a connection between Ms and Ls, using updated arguments value:
Fs → s
Pl → [Fs, Pl]
Lc → Result (1)
(which is going to be updated everytime) and final stop (Fs). After the rule will find final route it will determine length of Result by using change and len, lastly to get N1 it uses decr (N,N1).
Then connection will calculate T by adding each time between all the stops. 1 connection(Fs,Ls,Pl,Lc,[Fs,Ls],T,N1):2 conn1(Fs,Ls,T), 3 not(member(Fs,Pl)), 4 not(member(Ls,Pl)), 5 change(T,Lc,Ris), 6 len(Ris,N), 7 decr(N,N1). 8 connection(Fs,Ls,Pl,Lc,[Fs|L1c],T,M):9 conn1(Fs,Ms,T1), 10 not(member(Fs,Pl)), 11 not(member(Ms,Pl)), 12 change(T1,Lc,Result), 13 connection(Ms,Ls,[Fs,Pl],Result,L1c,T2,M), 14 T is T1+T2.
Visit Rule that calculate the path for the nearest stop, based on the selected attraction, it also shows the travel time, the number of changes and the stops list. Or, choose the final stop you want to reach and define the initial stop where the user is located, check if there are tourist attractions nearby. Compared to ‘Connection’ rule, there is an additional argument: the attraction that the user wants to visit (Att). The IM, as we already said, shows facts that associate a list of attractions with their nearest stop. Arguments: • Att = Attraction. • Fs = First stop. • Ls = Last stop. • Ms =Middle stop. • Lc = List of changes. • Pl = Prohibited list. • T = Total time of travel. • N1 = Number of changes. • Result = List containing the number of changes not decreased.
• L1c =List that represent the remaining path.
Knowledge Base, that can be associated with the last stop (Ls). After the IM finds it, checks if the desired attraction belongs to the list X, if it’s true the IM searches a connection between Fs and Ls. If, at the first try, the IM doesn’t find a direct connection, then it recalls the OR in visit and it will repeat the initial step, but this time searching, In the facts, a connection between Fs and a middle stop Ms, with T1 as travel time, recalling the rule: conn1. For the remaining part of the code, can be checked the rule: connection. 1 visit(Att,Fs,Ls,Pl,Lc,[Fs,Ls],T,N1):2 locate(X,Ls), 3 member(Att,X), 4 conn1(Fs,Ls,T), 5 not(member(Fs,Pl)), 6 not(member(Ls,Pl)), 7 change(T,Lc,Ris), 8 len(Ris,N), 9 decr(N,N1). 10 visit(Att,Fs,Ls,Pl,Lc,[Fs|L1c],T,M):11 locate(X,Ls), 12 member(Att,X), 13 conn1(Fs,Ms,T1), 14 not(member(Fs,Pl)), 15 not(member(Ms,Pl)), 16 change(T1,Lc,Result), 17 visit(Att,Ms,Ls,[Fs,Pl],Result,L1c,T2,M), 18 T is T1+T2.
In this section we will show the main functions of the chatbot component and guidelines for correct execution. The main program uses two doc.json, these two document has been made with two different approach to test the chat bot:
pronouns;
ifles or uncomment line 46 and 123, and change the following constant to the corresponding file.
In Listing 1 we open the document ’doc.json’ and download the content. With the Boolean cycle ’for’ we are taking the words taken from the document and inserting them in the lists through the functions ’append’ and ’extend’. 1 with open(DOC_FILE) as file: #Opens "doc.json" file and load with json libray .
data = json.load(file) #Start cycling through out data dictionary (doc.json) for intent in data["intents"]: for pattern in intent["patterns"]:
#tokenize all the world in our document using nltk, after that we extend word list, wrds = nltk.word_tokenize(pattern) words.extend(wrds) docs_x.append(wrds) docs_y.append(intent["tag"]) if intent["tag"] not in labels: labels.append(intent["tag"])
In Listing 2 we make all the words lowercase, and remove the character "?". After that we will stem the words, in other words we find the root version of our words. This will help us to see the dimension of the whole vocabulary not counting on duplicates.
words = [stemmer.stem(w.lower()) for w in words if w not in "?"] words = sorted(list(set(words))) #Remove duplicates and sort my list of words. labels = sorted(labels) #Sorts labels list.
The paper main goal is to present a fast and effective service to the tourist, who is visiting for the first time a city, full of culture and connections. In this work we verified the feasibility of a centralised service-oriented system aiming to the population of a Knowledge Base to be integrated into a tourism chatbot. Further development involves the enhancement of natural language processing algorithms to perform a data extraction based on page content, using the bot only to automate navigation or to support data already extracted.