Determinación de Inhibidores

GMAURO is designed to accommodate requirements from stakeholders’ viewpoints, which corresponds to viewpoint-oriented requirements. A “viewpoint” is an important requirement elicitation technique in Software Engineering and Requirement Engineering [110]–[112].

The generalized topics designed in the ontology GMAURO consider viewpoints from different stakeholders, such as users, requirement engineers, developers (including UI developers).

Figure 24 to the right is the class hierarchy of GMAURO. All classes under the “Subject” are subject hierarchy representing requirements from stakeholders’ viewpoints. “Request” is the class to store new user requirements elicited from the automatic user request elicitation process. “Feature” and “Function” represent existing requirements that can be traced in the requirement engineers’ viewpoint. Classes under the “Category” emphasize the developers’

viewpoint, while “UserInterface” emphasizes more on the user interface developers’

taxonomy. The “Price” and “Version” classes are attempts to elicit user feedback on price and version control, which may be optimized in more sophisticated ways.

133

“Attribute” is a class of attributes that can describe individuals under “Category” with more detailed information. However, this detailed information is not developed in this version of implementation. Future researchers are strongly recommended to improve this ontology and make use of the “Attribute” class.

“Opinion” is a class that hosts all the individuals for opinions. All individuals in “Opinion”

class have two object properties: “isOpinionFromReview” linking to “some” “Review” and

“opinionIsRegardingSubject” linking to “some” “Subject”.

“Review” is a class that hosts all the individuals for reviews. The individual reviews all have two object properties:

“reviewHasOpinion” linking to “some”

“Opinion” and

“reviewIsTalkingAboutSubject” linking to

“some” “Subject”. The

“reviewHasOpinion” property is an inverse property for “isOpinionFromReview” and vice versa.

“Subject” is a superclass for all types of topics that a review could talk about currently. There are subclasses “App”,

“Category”, “Device”, “Feature”,

“Function”, “Price”, “Version” and

“Request” so far. These classes are not disjointed in this ontology. Similarly, the first level of four super-classes are not disjointed as well. This design is to accommodate concepts that appear as more than one classes in the same level.

Figure 24 GMAURO class hierarchy.

134

Figure 25 The inverse relationships among the six object properties

All individuals under “Subject” have at least two object properties:

“subjectAppearedInReview” linking to “some” “Review” and

“subjectIsRegardedAsOpinion” linking to “some” “Opinion”. The

“subjectAppearedInReview” is an inverse property for “reviewIsTalkingAboutSubject” and vice versa. Similarly, the “subjectIsRegardedAsOpinion” property is an inverse property for the “opinionIsRegardingSubject” property and vice versa.

It is important to note that none of those above object properties is functional because the relationships all are many to many. Similarly, none of them are inverse functional properties.

Moreover, “App” and “Review” also have a pair of inverse object properties:

“appHasReview” linking to “some” “Review” and “isReviewOfApp” linking to “exactly” 1

“App”.

135

The mutual inverse relationships among those above eight object properties are depicted in Figure 25.

The mutual inverse relationships among the eight object properties attempt to maintain the traceability among App, Review, Subject, and Opinion classes.

The “Review” class also has three sub-classes “NegativeReview”, “NeutralReview”, and

“PositiveReview”, which are disjointed one another. All these three classes are equivalent classes that enable reasoners automatically infer the sentiment type of each review. The definitions of these three classes are below:

Table 25 Equivalent classes of three types of reviews

Negative review:

Review

and (hasSentimentScore exactly 1 xsd:double[< "0.0"^^xsd:double])

Neutral review:

Review

and (hasSentimentScore exactly 1 xsd:double) and (hasSentimentScore value "0.0"^^xsd:double) Positive review:

Review

and (hasSentimentScore exactly 1 xsd:double[> "0.0"^^xsd:double]) When a reasoner is turned on, reviews are automatically inferred as one type of review according to their sentiment values. The inferred types are highlighted as a light yellow colour as in the figure below.

Figure 26 A reasoner highlights the inferred type of a review

There are also a number of data properties in this ontology. Both types of properties are presented in Figure 27. The highlighted “keywords” property in Figure 27 is optional for the concept mapping from the topics mined from the previous component to this ontology. The

136

purpose of this property is for researchers who prefer to use conventional methods to compare the previous keywords array with some data source in the ontology itself. Since a simpler approach of a two-dimensional array has been taken in this version of implementation, the

“keywords” property is not used currently.

Figure 27 Object properties and data properties in GMAURO.

Because of such design, users can achieve easy navigation in the concepts of this GMAURO ontology. For example, from app to reviews, from a review to the opinions and topics that appear in this review, the descriptive relationship between opinions and topics, and vice versa. Figure 28 shows the easy navigation from an app to the reviews and the properties of the app in the left picture.

Moreover, easy navigation is also provided by Protégé itself. Individuals are grouped by classes and accessible via the “Individuals by type” tab. This tab is convenient to show what individuals are for each type, and how many they are. Figure 28 also shows the “Individuals by type” tab after the population in the right-hand side of the picture.

A series of SPARQL queries are delivered with the framework together to answer some common questions. For the detailed SPARQL queries and the questions they answer, readers

137

are referred to the 4.6 section in Results and evaluation chapter. Users are also recommended to inspire their own SPARQL queries to answer more questions.

Snap SPARQL Query is recommended to use for the SPARQL queries. The reason to recommend it is that Snap SPARQL Query is very fast in opening and actions. As a contrast, the Protégé built-in SPARQL Query tab takes unreasonable long time to open for a big populated ontology. For example, for the resulting ontology from the dataset one, the built-in SPARQL Query tab takes 5.5 hours to open the tab on the author’s computer, provided the memory setting “-Xmx” of Protégé run.bat has been increased from 500MB to 30GB.

Figure 28 Easy navigations in the ontology

One more benefit of Snap SPARQL Query is that it supports querying over inferred knowledge. Though this is not used in the evaluation due to the large size of the ontologies.

The reasoners take an unacceptable long time to start for the ontologies that are populated with the datasets.

138

In order to use Snap SPARQL Query, it is needed to create a new tab. The Snap Plugin is available as a View: Window > Views > Query Views > Snap SPARQL Query. Then drop it in the tab that is just created.

Technically there are more possibilities to proceed further to visualize the answers if piping the data from the answers to a data visualization software, such as a spreadsheet software or a statistical tool. Different SPARQL queries produce different answers that vary in the number of fields. Future researchers are welcome to handle this process in different ways.

This is not included in this implementation of the deliverables.