Especificaciones sanitarias 1 Generales

This subsection introduces the second step of the Topic-Opinion Extractor component. As reflected in the example of how this component works in the first subsection 3.5.1 of this chapter, this step filters the previously produced arcs from Figure 13 to produce the final arcs in Figure 14. In other words, the task of this step is to distinguish the arcs and filter out the unwanted arcs, thereby producing the final arcs that map one or more classes in the ontology.

The topic-opinion pairs produced from the last step are stored in a database table. During this step, both the topics and the opinions go through a filtering process.

In order to help understand the general algorithm of this component, readers can imagine the whole approach as making “Sandwiches”. Firstly, prepare the materials by traversing the dependency trees with linguistic rules. The candidates of the relationship arcs are the materials to make these “Sandwiches”. However, in order to become ready for “Sandwiches”, both the two ends, topics and opinions, have to undertake certain filtering processes, just like to wrap the materials with two bread layers.

The filtering process for opinions:

Because there are two different versions of the traversal function in the previous step, the opinions filtering is also different in this step accordingly, which is reflected in two versions.

Corresponding to version one of the traversal function, the filtering of opinions is achieved through a list of “stopOpinions” in C.11. During this process, some unwanted opinions are filtered out by “stopOpinions”. The disadvantage of this version is that the list of

“stopOpinions” is manually maintained. However, if this list of “stopOpinions” is maintained well, the strange strings that flee from the opinion filtering are normally low in frequencies.

Therefore, the resulting strange opinions don’t affect the performance much. They just affect the data looking in the ontology. The list of code C.11 contains the opinion filtering corresponding to the version one of the traversing function in C.9.

Corresponding to version two of the traversal function, the filtering of opinions is achieved through the list of “popularOpinions”, which has been implemented in the code C.10. How the popular opinions are gathered has been introduced in the previous subsection 3.5.5. The

122

list of code C.12 does not enable the list of “stopOpinions” filtering. C.12 is corresponding to version two of the traversing function in C.10.

Both C.11 and C.12 contain the same filtering process for topics.

The filtering process for topics:

The topics are compared with a two-dimensional array, which contains keywords corresponding to classes under the “Subject” class in the ontology. This is a classification process in this framework that maps the topics onto the ontology. The literature of this concept mapping onto ontology is briefly explored in section 2.3 in the Literature review chapter. The detailed method on how this is accomplished is reported in this subsection.

It is a debatable topic about what the most formal way to classify and map the topics onto the concepts in the ontology is. There are plenty of varieties in the literature on this question that apply different methods. In this component, the classification and concept mapping are realized in a very simple and light-weight method via a two-dimensional array. This is an alternative method to the formal ways of classification and concept mapping and is suitable in this specific framework.

There are three questions below in this classification process.

Q1. How to know which user reviews are talking about a concept in the ontology?

Q2. What if users use different but similar words with the terminologies?

Q3. How to actually map the pairs onto the concept categories in the ontology?

Question Q1 is resolved through a list of keywords for each concept, which forms the first dimension of the array. The two-dimensional array consists of such an array for each concept in the ontology. In the list of code C.11 and C.12, the topic of each topic-opinion pair is compared with each keyword in the array.

These keywords are carefully decided by manual selection initially, and enhanced by the high frequency keyword analysis during the data evaluation process. An example of 'UserInterface' below explains how to design and enhance this array in the future.

123

Table 23 An example of 'UserInterface' in the two-dimensional keywords array

['UserInterface', 'background', 'button', 'buttons', 'colour', 'color', 'colors', 'dark', 'display', 'emojis', 'fields', 'font', 'giggling', 'green', 'gui', 'icon', 'icons', 'interface', 'interfaces', 'layout', 'user interface', 'light', 'message', 'messages', 'noise', 'noises', 'notification', 'notifications', 'popup', 'popups', 'presentation', 'red', 'screen', 'screens', 'search', 'settings', 'sound', 'sounds', 'size', 'scroll', 'scrollbar', 'toast', 'ui', 'view', 'voice'],

All the keywords in the lower cases are the keywords to look for from the user reviews. They are decided gradually from the manual data analysis initially. Furthermore, 'voice' is included from the data evaluation process. During the evaluation against dataset one and two, 'voice' appears in the top 500 frequent words. Although in dataset one, 'voice' appears only 3 times, it appears in dataset two 206 times, thereby positions at the top 201st most frequent word in dataset two. The SQL query that statisticizes the subject words by frequencies in the previous subsection 3.5.4 helps the decision making in the keywords enhancement.

Readers might wonder why 'toast' appears in this keyword list of 'UserInterface'. This 'toast' is a term for mobile app developers to design a temporary popup message that disappears in a few seconds. But in practice, it is frequently linked to “bread” with the involvement of WordNet. Future researchers are recommended to make their own decision on whether to keep this term.

To resolve the question (Q2) of recognizing similar words being used in the reviews, WordNet is used in this component.

If a topic term is the same word with any keyword in the array, this specific topic-opinion pair is classified into this category and recorded into the database in the form of the pair id and the category, which is the class name in the ontology. The pair won’t be classified into duplicated categories because duplications are filtered out in the classification.

If the topic term is different with all the keywords in the array, it is then compared with the keywords in the context of WordNet for similarities. A similarity is calculated between this term and the keywords. If the similarity is above the predefined threshold, and this specific topic-opinion pair has not been classified into the same category previously, it is regarded as

124

related to this category and recorded into the database in the same form of pair id and the category.

It is worth to mention that, above two comparisons are accomplished in a same loop that loops through the keyword array for each topic-opinion pair just once.

The reason to separate the above two comparisons is that some topic terms are not in WordNet. For such terms, WordNet throws errors because it cannot calculate similarities for terms that it does not know.

For the sequence of above two comparisons, it is better to put the equal comparison before the WordNet similarity calculation. This is a decision after a series of experiments that suggest WordNet performs worse for exact same word similarity calculations than for the different words. For example, the same word “enter” and “enter” have a similarity of 0.5 when 'wup_similarity' is used. Whereas 'wup_similarity' performs the best in the experiments compared with other similarity calculations.

The similarity threshold is set to 0.90 for 'wup_similarity' in this component in the deliverables. This threshold provides good performance for most cases, although it is still awkward to merge singular and plural forms. It is also arguable whether it is too generous in the case of the 'toast' above, in which WordNet thinks “bread” is very similar to the 'toast'.

However, the experiments suggest that wup_similarity at 0.90 outperforms other algorithms.

The answer to the question Q3 is inside the design of the array and the above loop. This is a simplified solution that puts the category (the class) name at the first position in each of the dimensional arrays that represents one class in the ontology. All the single-dimensional arrays together build up the two-single-dimensional array. When looping the array for each topic-opinion pair and the pair is found related to a specific keyword (keywords[i][j]), the value of the first keyword in that line (keywords[i][0]), which is the name of the class in the ontology, is assigned to the variable “subjectCategory” for this pair. This

“subjectCategory” is written into the database with the pair id together in order to remember which topic-opinion pair belongs to which class in the ontology.

125

For the full logic of this step and how above questions are resolved, readers are referred to the list of code C.11 Topic-Opinion pair filtering via keywords Version one and C.12 Topic-Opinion pair filtering via keywords Version two.

This keyword comparison step works together with the previous step Topic-Opinion pair extraction via linguistic rules to produce the pairs that can be mapped onto the ontology. In the previous example sentence used in subsection 3.5.1, the original topic-opinion pairs that match the linguistic rules are six pairs. But the final matching pairs are two. The Figure 23 below depicts the result that the debugging code C.13 produces for this example. The debugging code is introduced in a later subsection 3.5.8.

Figure 23 Example result of Topic-Opinion pair extraction

Lastly, there is a point that needs future researchers’ attention in this piece of code. This code contains the WordNet snippet in the loop for database query result processing. WordNet looks consuming considerable memory, which causes the code unexpectedly quits in the experiments when there are printing statements in the code. The solution to the unexpected quit is removing all printing statements from the code, including the one in the “except”

block. After this adaptation, the code C.11 and C.12 never quit unexpectedly.

3.5.7 Data flow connector between the Request Elicitor and the Topic-Opinion Extractor