app relationship calculation abs

7/23/2019 APP Relationship Calculation Abs

http://slidepdf.com/reader/full/app-relationship-calculation-abs 1/7

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 user’s log or app’s

description, which can only detect whether two apps are downloaded, installed meanwhile or

provide similar functions or not. n 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

user’s log or app’s description.!eviews contain user’s viewpoint and "udgment 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. #$perimental

results demonstrate that via this iterative process, relationship between apps can be calculated

e$actly. Furthermore, this process is improved in two aspects. %ne is to obtain e$cellent results

even with weak initiali&ation. The other is to apply matri$ product to reduce running time.



INTRODUCTION

n people’s daily life. They can be used not only for commu- recent 1

to ! 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

ma#e the best use of their phones. These methods ac$uire considerably

hi%h performances in various scenarios. In fact" facin% the situation that the

amount of apps %ro&s fast" ho& to de'ne their relationship is more useful. To

de'ne relationship bet&een apps" or furthermore to classify relationship

bet&een apps" it needs to invent a method to calculate relationship bet&een

apps e(actly at 'rst. )or e(ample" %iven t&o apps respectively desi%ned forAndroid and I*+" to determine &hether they

refer to t&o unrelated apps or are ,ust the same app adapted to t&o dierent

systems" the 'rst step is to '%ure out &hether these t&o apps have

relationship or not. In %eneral" the tas# of calculatin% relationship bet&een

apps is more valuable and challen%eable. ith it" &e can %roup related apps

by lin#in% them to form a %raph. ith this %raph" app retrieval and app

recommendation are easy to be performed.

'pps seldom appear alone. n most of app stores, one app corresponds to one webpage.

Taking (oogle play for e$ample, each webpage in it has four parts. The first part

includes app’s name and its rate marked by stars. The second part is app’s 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 e$tract attributes from app’s

description to represent apps, and then calculate app relationship based on conte$t similarity.

This kind of method can only detect whether two apps own the similar function or not, namely

app similarity. 'pparently, reviews contain useful information about apps, such as user’s

viewpoint and "udgment, which cannot be included by app’s description. For instance, given two

apps )labeled as app* and app+, users in one review to app* require a service that app* cannot

provide, while there is another review to app+ where users state this service is provided by app+,

app* and app+ are related. The typical e$ample is otels. com/ and 'lipay/. 0oreover, the



relationship between them is not similarity, and cannot be calculated via app’s description.

Unfortunately, there are seldom methods considering importing reviews in app relationship

calculation. Two main reasons cause this situation. %ne 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 user’s viewpoint, thus are difficult to be used to e$tract attributes.

's the previous analyses, reviews can be used to e$tract 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. %ne operation uses app relationship to measure review similarity. The other

operation uses review similarity to calculate app relationship. #$perimental results demonstrate

that no matter following which way, the similar high-quality final results can be obtained.

n this paper, we construct one app collection to test our proposed process. This collection

includes *,111 app pairs downloaded from (oogle paly, whose relationship values

are defined by users. 0oreover, to test our proposed process for real application, we use it in app

recommendation. #$perimental results demonstrate that our proposed process can calculate app

relationship e$actly and can provide more reasonable recommending results.

Unfortunately, this iterative process encounters two defects. %ne 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. #$perimental results indicate that initial parameters

deeply affect calculating results. owever, 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 matri$ product, which reduces running time when novel apps

appear. To deal with the latter defect, we ad"ust 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. %ne

way is dictionary based. The other way is statistic based.



2ictionary based way )sometimes called knowledge based way relies on professional

thesauruses to e$tract attributes to calculate entity relationship )or app relationship. The

thesauruses are designed by e$perts, and often organi&e entities by hierarchy. The entities with

the similar meanings are grouped together. 3ord4et is "ust a typical e$ample. 3ith 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 e$tract 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

e$pand attributes by thesauruses which are already e$tracted from the other corpus )e.g. web

data.

5tatistic based way )sometimes called corpus based way is another powerful method for

entity )or app relationship calculation. t calculates entity )or app relationship based on large-

scale corpus, which seldom encounters missing data issue occurring in dictionary based way.

5tatistic based way is conducted by e$tracting conte$tual attributes from corpus to represent

entities and then applying certain measurement to calculate entity relationship based on this

representation. 5ince this way is based on conte$tual similarity, it can only detect entity

similarity. There are many online corpora available, such as 3ikipedia and 6aidu 7nowledge.

"ust used cross-document co-reference in 3ikipedia to calculate entity relationship. 8inking

information in online corpora is also considered "ust used graph model to calculate entity

relationship via linking information in 3ikipedia. 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 e$tract attributes .

n conclusion, the usual way to calculate app relationship is to e$tract attributes from

app’s description to represent apps and then apply some similarity measurements to calculate app

relationship. This way has two defects. %ne is that it can only detect shallow similarity between

apps. The other is that some useful information is oblivious, such as the viewpoint in user’s

review.



For this reason, this paper proposes an iterative process to combine app relationship

calculation and review similarity calculation together. #$perimental results demonstrate that this

iterative process can calculate app relationship e$actly. t can find more general relationships

between apps. Furthermore, two improvements are made on this iterative process. %ne is to

ad"ust iterative process by combining two ways to obtain high-quality results even with

weak initial parameters. The other is to replace calculationby matri$ product to reduce time.

LITERARY REVIEW

On document ree!ance and e"#ca co$es#on bet%een &uer' terms

8e$ical cohesion is a property of te$t, achieved through le$ical-semantic relations

between words in te$t. 0ost information retrieval systems make use of le$ical relations in te$t

only to a limited e$tent. n this paper we empirically investigate whether the degree of le$ical

cohesion between the conte$ts of query terms’ occurrences in a document is related to its

relevance to the query. 8e$ical cohesion between distinct query terms in a document is estimated

on the basis of the le$ical-semantic relations )repetition, synonymy, hyponymy and sibling that

e$ist between there collocates words that cooccur with them in the same windows of te$t.

#$periments suggest significant differences between the le$ical cohesion relevant and non-

relevant document sets e$ist. ' document ranking method based on le$ical cohesion shows some

performance improvements.

Introduct#on

3ord instances in te$t depend to various degrees on each other for the realisation of their

meaning. For e$ample, 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 conte$tual meaning.

's we read, we process the meaning of each word we see in the conte$t of the meanings of the

preceding words in te$t, thus relying on the le$ical-semantic relationsbetween words to

understand it. 8e$ical-semantic relations between open-class words form the le$ical cohesion of

te$t, which helps us perceive te$t as a continuous entity, rather than as a set of unrelated

sentences. 8e$ical cohesion is a ma"or characteristic of natural language te$ts, which is achieved



through semanticconnectedness between words in te$t, and e$presses continuity between the

parts of te$t )alliday 9 asan, *:;< . 8e$ical cohesion is not the same throughout the te$t.

5egments of te$t, which are about the same or similar sub"ects )topics, have higher le$ical

cohesion, i.e., share a larger number of semantically related or repeating words, than unrelated

segments

Concus#on

n the method reported in this paper, documents which contain query terms close or

ad"acent to each other do not receive any special treatment compared to documents where query

terms are separated by longer distances. ntuitively, query terms located in close pro$imity aremore likely to be related topically. 3e e$perimented 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 8=5.

6ut, the results were inferior to those of the reported method. nterestingly, 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 T!#= collections. owever, it has been

demonstrated in some studies that term pro$imity can be useful for document retrieval tasks

)e.g.=larke 9 =ormack,+111, therefore possible combination of the two approaches to

document ranking needs to be investigated further. n particular, queries which consist of a stable

multi-word unit )e.g., >>United 4ations’’ may benefit more from pro$imity search, whereas

queries consisting of a set of separate words )e.g., >>=hina trade’’ or >>loose’’ phrases, whose

components can occur separately in te$t )e.g., >>'25 in 'frica’’, may benefit more from le$ical

cohesion-based methods.

CONCLUSION AND (UTUREWOR)



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. t combines app

relationship and review similarity into an iterative calculating process and set them for the same

ob"ective. This iterative process has two ways to run and only needs to set one initial parameter.

6y this process, the relationship between apps can be calculated accurately. owever,

e$perimental results show that this iterative process cannot converge. Thus, we import an

annealing parameter to make it converge. 6esides, this parameter does not prolong running time

and decrease precision. This paper also makes two improvements on this iterative process. %ne is

to make it high-quality even with weak initial parameters. The other is to reduce running time by

matri$ converting, when novel apps appear.

Unfortunately, the matri$ converting plan for reducing running time has one defect. n

these two matrices )respectively formed by app relationship and review similarity, one entry

corresponds to one app or one review. f 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 e$pand matrices to import novel apps and novel reviews. 6esides,

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

app relationship calculation abs

Documents