Introduction

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 project aims, through a service-oriented architecture, to extrapolate through a web crawler 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 [1,2,3] with which any users will be able to interact easily in natural language.

Researchers and companies are making great efforts to develop new ways of communicating with a increasing number and types of electronic devices, with particular attention to the conver-sational 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 [4] and area specific information, natural or cultural points of interest, tourist routes, social events, history etc. The main aim of the paper is to provide the tourists visiting a city for the first time with a fast and efficient service.

The system can suggest to the users most appreciated cultural sites, by analysing opinion taken from social networks [5], and specifically taking in consideration cultural heritage communities [6] or the most authoritative persons [7] in the field of cultural heritage domain. Therefore, understanding the users' cultural preferences can improve customer loyalty, as a smart system can give them personalised tours to reach the point of interest according to the preferences expressed. A conversational interface [8] (chatbot) simplifies communications with the user.

Moreover, since of Covid-19 disease spreading, many cities started to improve their mobility services, like underground, by implementing a routing service for tourists [9,10], that offers:

• Route planning by taking as input user's first and last stop.

• number of stops from starting stop to last one. • Number of line changes during the route.

• Detection of the nearest stop to a given tourist's attraction.

TravelBot [8] provides the aforementioned basic functions and other services like:

• Informing the user about any faults on the lines.

• Showing the metro's map.

• Informing and guiding the user to the purchase of tickets.

• Showing the order of the stops for the line selected.

• Informing the user about the working timetables of metro's services.

System Architecture

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 [11].

We adopted a Service Oriented Architecture because of its intrinsic modularity. In this type of 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 Data Service; a web application in Django for direct insertion. For the implementation of the Service Bus, the choice fell on the open-source framework 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.

The application in Django, finally, was born as an interface for the management of CRUD (Crud-Retrieve-Update-Delete) operations by an employee or operator of a cultural entity. However, due to restrictions imposed by the framework itself, it was decided to use it for insertion only. In the section dedicated to future developments, this issue will also be dealt with [12].

Knowledge Base population

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.

The "machine learning" process is used to obtain useful information for the user (e.g.) and this will help the programmer who does not need to provide too many facts to the machine.

Facts

The machine knows two types of facts:

1. Connections (conn), composed by 3 arguments: a) First stop; b) Second stop; c) Median time between that two stops, it also serves to identify which line is it. It establishes that there is a connection between the two stops and how long the subway takes to travel from one to another.

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 [13] Conn1 The machine can determine only a one way connection with his known fact "conn". To be able to establish a bidirectional connection between two stops, the machine uses this mathematical expression:

∃conn(X,Y,C)i f ∃conn(Y, X,C)

The OR statement is needed to get rid off infinite recursive call that can be possible in the next set of rules.

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.

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. 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.

In the first part of code, connection will check if there is a direct connection between first stop (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)

The recursive call has to be called until it find a direct connection between middle stop (Ms) (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. 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: In the first case the IM checks if there is already an attraction or a list of them X, in the 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.

TravelBot

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:

1. 'doc-v1.json' had pattern made of extended question containing when/how/what/which pronouns; 2. 'doc.json' is the current document in use, and is made of keywords for each tag with no pronouns at all.

If you want to test the two different documents please make sure to delete model [8] and data files 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'. 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. Listing 2: Text Normalization

Conclusion

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.