APP Relationship Calculation:

An Iterative Process

Abstract
Today, plenty of apps are released to enable users to make the best use of their cell
phones. Facing the large amount of apps, app retrieval and app recommendation become
important, since users can easily use them to acquire their desired apps. To obtain high-quality
retrieval and recommending results, it needs to obtain the precise app relationship calculating
results. Unfortunately, the recent methods are conducted mostly relying on users log or apps
description, which can only detect whether two apps are downloaded, installed meanwhile or
provide similar functions or not. In fact, apps contain many general relationships other than
similarity, such as one app needs another app as its tool. These relationships cannot be dug via
users log or apps description.Reviews contain users viewpoint and judgment to apps, thus they
can be used to calculate relationship between apps. To use reviews,this paper proposes an
iterative process by combining review similarity and app relationship together. Experimental
results demonstrate that via this iterative process, relationship between apps can be calculated
exactly. Furthermore, this process is improved in two aspects. One is to obtain excellent results
even with weak initialization. The other is to apply matrix product to reduce running time.

INTRODUCTION
In peoples daily life. They can be used not only for commu- recent 10
to 20 years, smart phone becomes essential in communication, but also for
entertainment, business, and travel,
etc. The popularity of smart phones causes many apps released to help users
make the best use of their phones. These methods acquire considerably
high performances in various scenarios. In fact, facing the situation that the
amount of apps grows fast, how to define their relationship is more useful. To
define relationship between apps, or furthermore to classify relationship
between apps, it needs to invent a method to calculate relationship between
apps exactly at first. For example, given two apps respectively designed for
Android and IOS, to determine whether they
refer to two unrelated apps or are just the same app adapted to two different
systems, the first step is to figure out whether these two apps have
relationship or not. In general, the task of calculating relationship between
apps is more valuable and challengeable. With it, we can group related apps
by linking them to form a graph. With this graph, app retrieval and app
recommendation are easy to be performed.
Apps seldom appear alone. In most of app stores, one app corresponds to one webpage.
Taking Google play for example, each webpage in it has four parts. The first part
includes apps name and its rate marked by stars. The second part is apps description. The third
part includes reviews provided by users. The fourth part contains the apps recommended by
system to the current app. Traditional calculating methods often extract attributes from apps
description to represent apps, and then calculate app relationship based on context similarity.
This kind of method can only detect whether two apps own the similar function or not, namely
app similarity. Apparently, reviews contain useful information about apps, such as users
viewpoint and judgment, which cannot be included by apps description. For instance, given two
apps (labeled as app1 and app2), users in one review to app1 require a service that app1 cannot
provide, while there is another review to app2 where users state this service is provided by app2,
app1 and app2 are related. The typical example is Hotels. com and Alipay. Moreover, the

relationship between them is not similarity, and cannot be calculated via apps description.
Unfortunately, there are seldom methods considering importing reviews in app relationship
calculation. Two main reasons cause this situation. One is that reviews are too short thus are
difficult to be fully used. The other is that most of reviews do not directly describe apps but only
contain users viewpoint, thus are difficult to be used to extract attributes.
As the previous analyses, reviews can be used to extract relationship between apps other
than similarity. For this purpose, this paper combines app relationship and review similarity into
an iterative calculating process. This process has two operations and alternately repeats them
until convergence. One operation uses app relationship to measure review similarity. The other
operation uses review similarity to calculate app relationship. Experimental results demonstrate
that no matter following which way, the similar high-quality final results can be obtained.
In this paper, we construct one app collection to test our proposed process. This collection
includes 1,000 app pairs downloaded from Google paly, whose relationship values
are defined by users. Moreover, to test our proposed process for real application, we use it in app
recommendation. Experimental results demonstrate that our proposed process can calculate app
relationship exactly and can provide more reasonable recommending results.
Unfortunately, this iterative process encounters two defects. One is that it needs to run
once more when novel apps appear. Thus, it is time consuming. The other is that this iterative
process needs to set two initial parameters. Experimental results indicate that initial parameters
deeply affect calculating results. However, it is difficult to determine which parameter is suitable.
To deal with the former defect, we convert calculating results to two matrices and
replace iterative calculation by matrix product, which reduces running time when novel apps
appear. To deal with the latter defect, we adjust iterative process by combining two ways to
maintain the performance even with weak initial parameters.

EXISTING SYSTEM
There are two generally acceptable ways to perform entity relationship calculation. One
way is dictionary based. The other way is statistic based.

Dictionary based way (sometimes called knowledge based way) relies on professional
thesauruses to extract attributes to calculate entity relationship (or app relationship). The
thesauruses are designed by experts, and often organize entities by hierarchy. The entities with
the similar meanings are grouped together. WordNet is just a typical example. With its
hierarchical structure, one can easily tell entity relationship in terms of the position of entity .
Unfortunately, most of recent thesauruses do not import apps as their terms, thus it is impossible
to extract attributes from them to represent apps, which causes dictionary based way unsuitable
for app relationship calculation. To our knowledge, the only method to apply this way is to
expand attributes by thesauruses which are already extracted from the other corpus (e.g. web
data).
Statistic based way (sometimes called corpus based way) is another powerful method for
entity (or app) relationship calculation. It calculates entity (or app) relationship based on largescale corpus, which seldom encounters missing data issue occurring in dictionary based way.
Statistic based way is conducted by extracting contextual attributes from corpus to represent
entities and then applying certain measurement to calculate entity relationship based on this
representation. Since this way is based on contextual similarity, it can only detect entity
similarity. There are many online corpora available, such as Wikipedia and Baidu Knowledge. H
just used cross-document co-reference in Wikipedia to calculate entity relationship. Linking
information in online corpora is also considered just used graph model to calculate entity
relationship via linking information in Wikipedia. Unfortunately, those corpora are unsuitable for
app relationship calculation, since online corpora are often manually updated by web users and
importing apps and their descriptions often delay than their appearance. For this reason, snippets
collected from searching engine are often used as corpus. This kind of method puts app like
query and collects retrieval results as corpus to extract attributes .
In conclusion, the usual way to calculate app relationship is to extract attributes from
apps description to represent apps and then apply some similarity measurements to calculate app
relationship. This way has two defects. One is that it can only detect shallow similarity between
apps. The other is that some useful information is oblivious, such as the viewpoint in users
review.

For this reason, this paper proposes an iterative process to combine app relationship
calculation and review similarity calculation together. Experimental results demonstrate that this
iterative process can calculate app relationship exactly. It can find more general relationships
between apps. Furthermore, two improvements are made on this iterative process. One is to
adjust iterative process by combining two ways to obtain high-quality results even with
weak initial parameters. The other is to replace calculationby matrix product to reduce time.

LITERARY REVIEW
On document relevance and lexical cohesion between query terms
Lexical cohesion is a property of text, achieved through lexical-semantic relations
between words in text. Most information retrieval systems make use of lexical relations in text
only to a limited extent. In this paper we empirically investigate whether the degree of lexical
cohesion between the contexts of query terms occurrences in a document is related to its
relevance to the query. Lexical cohesion between distinct query terms in a document is estimated
on the basis of the lexical-semantic relations (repetition, synonymy, hyponymy and sibling) that
exist between there collocates words that cooccur with them in the same windows of text.
Experiments suggest significant differences between the lexical cohesion relevant and nonrelevant document sets exist. A document ranking method based on lexical cohesion shows some
performance improvements.

Introduction
Word instances in text depend to various degrees on each other for the realisation of their
meaning. For example, closed-class words (such as pronouns or prepositions) rely entirely on
their surrounding words to realise their meaning, while open-class words, having meaning of
their own, depend on other open-class words in the document to realise their contextual meaning.
As we read, we process the meaning of each word we see in the context of the meanings of the
preceding words in text, thus relying on the lexical-semantic relationsbetween words to
understand it. Lexical-semantic relations between open-class words form the lexical cohesion of
text, which helps us perceive text as a continuous entity, rather than as a set of unrelated
sentences. Lexical cohesion is a major characteristic of natural language texts, which is achieved

through semanticconnectedness between words in text, and expresses continuity between the
parts of text (Halliday & Hasan, 1976 ). Lexical cohesion is not the same throughout the text.
Segments of text, which are about the same or similar subjects (topics), have higher lexical
cohesion, i.e., share a larger number of semantically related or repeating words, than unrelated
segments

Conclusion
In the method reported in this paper, documents which contain query terms close or
adjacent to each other do not receive any special treatment compared to documents where query
terms are separated by longer distances. Intuitively, query terms located in close proximity are
more likely to be related topically. We experimented with attributing collocates in the
overlapping windows of two distinct query terms to both of them,which led to the formation of
more links between the collocates of closely located query terms, and consequently higher LCS.
But, the results were inferior to those of the reported method. Interestingly, our study also shows
that there is no significant difference between the average shortest distances between distinct
query terms in the relevant and non-relevant sets in two TREC collections. However, it has been
demonstrated in some studies that term proximity can be useful for document retrieval tasks
(e.g.Clarke & Cormack,2000), therefore possible combination of the two approaches to
document ranking needs to be investigated further. In particular, queries which consist of a stable
multi-word unit (e.g., United Nations) may benefit more from proximity search, whereas
queries consisting of a set of separate words (e.g., China trade) or loose phrases, whose
components can occur separately in text (e.g., AIDS in Africa), may benefit more from lexical
cohesion-based methods.

CONCLUSION AND FUTUREWORK

Facing the situation of lack of plans to dig more general relationships between apps, this
paper proposes an iterative process to calculate app relationship via reviews. It combines app
relationship and review similarity into an iterative calculating process and set them for the same
objective. This iterative process has two ways to run and only needs to set one initial parameter.
By this process, the relationship between apps can be calculated accurately. However,
experimental results show that this iterative process cannot converge. Thus, we import an
annealing parameter to make it converge. Besides, this parameter does not prolong running time
and decrease precision. This paper also makes two improvements on this iterative process. One is
to make it high-quality even with weak initial parameters. The other is to reduce running time by
matrix converting, when novel apps appear.
Unfortunately, the matrix converting plan for reducing running time has one defect. In
these two matrices (respectively formed by app relationship and review similarity), one entry
corresponds to one app or one review. If novel apps contain the reviews that are not included by
matrices or novel reviews contain the apps that are not included by matrices, these apps and
reviews cannot be automatically inserted into matrices. For this reason, in the future work,
we intend to automatically expand matrices to import novel apps and novel reviews. Besides,
there are many kinds of relationship between apps, whereas our proposed process can only detect
there is relationship and gives its value but cannot tell which type of relationship it belongs to.
Therefore, in the future work, we intend to invent a plan to classify app relationship