UMIS: A Service for User Model Interoperability

In this paper we describe UMIS, a service architecture that enables user adaptive applications to exchange User Model data on the Web. UMIS provides a set of facilities that allow applications to interoperate with minimum changes in their internal logics and knowledge representation. The goal is to support the process of interoperability in three ways: providing an efficient centralized discovery service; offering a service for simple interaction for the exchange of UM value in a p2p way; and offering a negotiation mechanism to be used in case of communication hurdles (i.e. semantic ambiguities and missing response). We developed a proof-of-concept prototype of UMIS and we tested it with an existing user-adaptive application. According to our test results, our approach improves the communication with respect to standard solutions for interoperability regarding the quality of exchange, with a negligible impact on the communication costs and traffic generation.


Introduction
In recent years, with the diffusion of Social Web applications people provide a lot of personal information to applications.That is particularly useful for adaptive applications [1], that need to collect data about users to provide adaptive services to them.In an adaptive system, the information on the users is explicitly stored in a specific data structure, the User Model (UM), which maintains domain-independent (e.g., age, gender, etc.) and domaindependent user features, represented by values assigned to some domain concepts, indicating the user's level of preference for these concepts [2,3].
In this context, sharing information about users among applications (UM interoperability [4]) can be a practical way to have more complete and accurate user models.This enables systems to offer more accurate adapted services to the users, since the quality of adaptation mainly depends on the quantity and quality of user data in the user model [5,6].Moreover this makes systems able not to bore the users asking them for the data which are already available in other systems.UM interoperability proved especially useful at the early stage of a user-system interaction to solve the so called cold start problem [7].
Despite these advantages, UM interoperability is not very often exploited by real systems.In fact, UM interoperability in an open and dynamic environment like the Web is a complex task and requires a very high level of alignment by applications, both on communication protocols and on syntax and semantics of data [8].
We aim at lowering some of the common barriers to interoperability, proposing a web service infrastructure for User Model Interoperability (UMIS), that adaptive web applications can exploit to exchange data about users.UMIS offers a set of facilities making applications able to interoperate in a flexible and dynamic way, limiting the changes in their internal logic and knowledge representation.
The process of UM data interoperability can be logically divided in three phases:  Discovery of the system which stores the desired UM data;  Exchange of the UM data;  Interpretation of the data.
The main contribution of the work is to support the process of interoperability in such three phases:  It provides an efficient centralized service discovery tool;  It offers an effective simple basic model of interaction for the exchange of UM value in a peer to peer way;  It offers a negotiation mechanism to support interpretation in case of semantic ambiguities or missing (or non satisfactory) responses.UMIS can be exploited to exchange both domain-independent and domain-dependent information.In this paper we focus on the latter, considering the use case of applications exchanging the value of the user interest in some domain concepts.In order to evaluate our approach, we made iCITY [9], an existing adaptive application, interoperate exploiting UMIS services.Then, we evalu-ated: 1) the performance of the exchange, with respect to the network traffic and the communication cost; 2) the quality of the exchange.
In this work, we implement the conversation model of [10], revised and modified in order to fit implementation requirements.With respect to such previous work we:  Revised the original communication model and provided a new implementation of it;  Provided a service architecture to support the model;  Added an event-based information discovery mechanism.
The basic ideas of UMIS has been proposed in a preliminary version in [11].
The paper is structured as follows.Section 2 describes the interoperability problems and our approach to address them, while Section 3 focuses on the dialogue model.Section 4 describes the framework components and 5 presents the framework in action.Then Section 6 describes the evaluation of our solution.Section 7 analyzes some of the most relevant related work.Finally, Section 8 concludes the paper with some comments and remarks.

Interoperability Issues
As seen above, the UM interoperability process follows three steps: 1) discovery; 2) interaction; 3) interpretation.In our work we aim at solving some interoperability problems that can occur in each phases: Discovery issue.Applications looking for user features should easily and quickly discover which applications offer the desired information and how they can be contacted.Thus, we aim at providing a sort of yellow page mechanism focused on the user model context.
Communication issue.The interaction between two applications can take place only if they agree on the communication protocols and on the syntactic structure of the exchanged information.Our purpose is to provide a framework which makes applications able to interoperate in a flexible and dynamic way, avoiding the necessity to a direct peer to peer preliminary agreement on the communication protocols.
Semantic interpretation issue.When the knowledge model is not shared, it is needed to ensure a correct understanding of the exchanged data; we aim at ensuring an interpretation mechanism to solve semantic ambiguities.In case of missing or unreliable response, our purpose is to provide a value derivation mechanism.
In order to address these problems, we propose the following solutions: 1) To enhance the discovery issue, we chose to enhanced a traditional UDDI (Universal Description Discovery and Integration) registry with a shared network space based on the publish/subscribe pattern.
2) To solve the communication issue we exploited Service Oriented Computing [12], since the loosely cou-pled structure and the well accepted stack of standards underlying Web Services technology represent an effective solution for communication on the Web.
3) To cope with the semantic interpretation issue we use resources from the Semantic Web (ontologies and specification languages) [13].To preserve the autonomy of the applications, we do not impose to use a unique ontology 1 , but we only require to refer to ontologies expressed with Semantic Web languages.In case of semantic ambiguities on the exchanged concepts, we chose to negotiate the meaning of the concepts by means of a conversation, adopting a revised version of a Dialogue Game model specifically conceived for UM interoperability [10] (Section 3).We also used the dialogue model to deal with the problem of missing or unreliable response in order to derive a response when the exact one is not available or is not satisfactory.

Conversation Model
As mentioned, UMIS extends the conversation model presented in [10] in order to solve the problems of semantic interpretation and of missing-unreliable responses.Such model adapts to UM interoperability context the diagnostic learning dialog model of [15], based on Dialogue Games [16] and Speech Acts [17] theories.The model is based on Dialogue Game (DG), a template describing the communication behavior the systems should follow to reach a particular goal.In the UM interoperability context, a dialogue involves a system looking for user data (Requestor), and a system providing this data (Provider).The basic dialogue primitive of a DG is the Speech Act, represented as a couple "move, statement" where:  A move is a domain-independent verb expressing the system intention, such as to inquire for something, to inform about something, etc.  A statement about the User Model is represented as a quad <f, c, v, r>, where: ˗ f is a domain-dependent user feature in the UM; ˗ c is the concept of the Domain Model the user feature refers to; ˗ v is the value of the UM feature (a value from 0 to 1); ˗ r is the reliability of the value (a value from 0 to 1).
An example of Speech Act is inform,<Interest, Art, 0.5, 0.2> which informs that the value of the UM feature Interest in the Domain Model concept Art is medium (0.5) with a low reliability (0.2).
More in details, the dialogue game components are:  Specifications, the pre-conditions of the game, i.e. the specific situation triggering a dialogue game;  Parameters, the goals of the game;  Components, strategies determining the Communicative Acts to be generated during the game: ˗ Content tactic: to gather the concepts to be discussed in the game (focus space).˗ Scope strategies: to extract from the focus space the concepts to use as statement of the CA.˗ Dialogue rules: to determine the sequence of Communicative Acts ˗ Post-conditions: to determine the changes at the end of the dialogue.
We revise the original model to favor its implementation by applications.
First, we did not consider the preconditions and the postcondition of the game, leaving each system free to decide when to start and end a dialogue instance.
We also ruled out the scope strategies, relaxing the constraints in the order of concepts exchanged in a dialogue, leaving more autonomy to the systems.
Then, we selected only a subset from the original moves in [10] (i.e., to inquire, to agree, to disagree, to request, to inform, to deny) sufficient for the goal of UM interoperability.
Finally, we revised the dialogue rules modeling the flow of Communicative Act to be exchanged during a game in terms of Conversation Protocol.
Moreover, we enriched the model introducing an explicit measure of similarity between concepts.In particular we consider a measure of Similarity derived from properties [20,21] 2 .Similarity between objects can be expressed as a function of their common and distinctive features (properties).We derived this idea from the Similarity Theorem [18], that asserts that the similarity between A and B is measured by the ratio between the amount of information needed to state the commonality of A and B, and the information needed to fully describe what A and B are.Thus we define a similarity measure sim between two concepts A and B as: where comm(A, B) is the number of the properties shared by A and B, and description(A, B) is the total amount of properties of A and B.
As a result, in UMIS a Dialogue Game is defined by the combination of Content Tactics and a Conversation Protocol.

Content Tactics
UMIS implements the following tactics:  tc1: find.parents(c), to gather the concepts directly related to the concept c, i.e. in an ontology, the direct superclasses.In Figure 1, RedWine for c = Barolo;  tc2: find.children(c), to collect the descendants of c, i.e. in an ontology, the subclasses.In Figure 1, Baro-loChinato and BaroloRiserva for Barolo. tc4: find.property(c), to collect all the properties of c; in Figure 1, has_taste and has_smell for RedWine. tc3: find.siblings(c), to gather the closest siblings concepts, i.e in an ontology, the concepts at the same level with the same parents and with a certain number of same properties.In the figure, among the children of RedWine, Barolo and Nebbiolo can be considered as the most similar since they share the property is_still. tc5: find.ancestors(c), to gather all the ancestors concepts of c, i.e. in an ontology, all superclasses upper than parents.In Figure 1, Wine and Beverage for Barolo.

Conversation Protocols
A conversation protocol is the set of ordered messages the two roles (Requestor and Provider) have to exchange to correctly implement the dialogue.In UMIS, we defined two main basic communication blocks, using the chosen subsets of moves: Request-pattern: a Requestor may ask to receive the value v (and its reliability r) of the UM feature f for the domain concept c: (request (f, c)) (e.g.request (Interest, Barolo)).As answer, a Provider can: 1) inform (f, c, v, r), to provide the value and its reliability, e.g.inform (Interest, Barolo, 0.5, 0.2); 2) deny (), to refuse to provide an answer.
Inquiry-pattern: a Requestor may simply want to know if the model has the concept c: inquire (c) (e.g.inquire (Barolo)) or the property p: (inquire (p, c) (e.g.inquire (is Sparkling, Barolo)).
The Provider can then: 1) agree () (when it has c or p); 2) disagree () (when it does not have c or p).
In UMIS a communication protocol is represented by means of a UML Activity Diagram where each activity node is a Communication Activity representing the fact that an application sends (or receives) a message to (or from) another application.For instance, the activity (send (inform(s))) in the conversation protocol associated to the role of the Provider means that the application playing the role of Provider has to send the message inform with the statement s to the Requestor.Note that in the protocol no internal business logic and activities, as well as internal data flow, are represented.Figures 2 and 3 represent the conversation protocols implemented in UMIS. 2 With property we refer to rdf:Property as defined in the specification: "RDF properties may be consider as attribute of resources and in this sense correspond to traditional attribute-value pairs.RDF properties also represent relations between resources."(http://www.w3.org/TR/ rdf-schema/).Explorative Game, used for the de s for a concept of a shared ontology, when the Provider does not have the requested value or the reliability value is too low;

UMIS implements the two Di logue Games presented in a
Clarificatio main concept c in the request, when c does not belong to a shared ontology.
In the following w mes, highlighting the difference with respect to the original model.An example of game execution in the framework is provided in Section 5.

Explorative Game
The goal of this dialogue ga user feature for a domain concept starting from the values of such a feature for the related concepts.The rationale behind the game is that the attitude of a user on a concept can be assumed to be similar to the attitude on its related concepts (according to taxonomy approach [18]).For instance, if the user expresses an interest in a concept, this interest can be extended with high reliability to its Content Tactics.The focus of this game is constituted by the concepts related to the starting one (parents, chilen, sibling concepts).The tactics tc1 (find.parents),tc2 (find.children),tc3 (find.siblings)can be used for this purpose.
Conversation Protocol.The conversation protocol of the game ribed in Figure 2. In the figure we give a compact representation of the protocol using the convention that tc1-tc2-tc3 indicates that the same block of actions can be repeated in sequence using tactics tc1, tc2, tc3.
A starting message start (cID, tc1) is sent by the Requestor to inform that it is starting to send messag ying the tactic tc1, and then it starts to send a message request (cID, c), where request is the move, and c is one of the concepts derived from the application of the tc1.
The Provider can deny (cID) the request or produce an inform (cID, s) message with the requested statement.I th cases, the Requestor can go on with the conversation or terminate it, according to its own internal strategy.If it decides to go on, it can produce a second execution of the block sending statements derived by the application of tc2 tactic.In this case the Requestor asks for the children concepts.The same can then be done using the tactics tc3.Notice that in the protocol we do not represent any condition associated to the Choice construct: the decision depends on the policies of each system.
Policies for the value derivation.Generally, IS-A relations do not represent a uniform similarity distance among concepts [19].Thus, in the value derivation we consider a measure of similarity among classes connected with IS-A relations according to Formula (1).Thus we compute the derived value as an average of the values of related concepts, weighed on their similarity degree (Formula (2)) where c i are the n concepts related with c and si the similarity degree computed between c and c .
Reliability.The derivation of the value has a negative impact on its reliability; e.g., if the value of user Barolo is derived from the Interest in its parent Red-Wine, its reliability is lower than a value directly associated to the Barolo.In UMIS, reliability (r) of the derived value (val(c)) depends on the similarity of the involved concepts (Formula (3))

  
The goal of the game is to belonging to different ontol two concepts are the same concept.The rationale of the game is that two concepts can be considered as the same if their similarity is very high.To measure similarity, we consider both the similarity derived from properties and from IS-A relations.
Content Tactics.The focus of the game is constituted by 1) the properties of the concept; 2) the parents of the concept.For example, the concept Barolo can refer to a typology of wine (ontology Food, Figure 1) or to an Italian city (ontology GeoLocal, Figure 4).To disambiguate it, a possible focus could be composed by: ˗ Properties (e.g is still, has_taste), according to tc4 (find.properties)tactic; ˗ Superclasses (e.g.RedWine, Wine, Cuneo, Piedmont) following tc1 (find.parents)and tc5 (find.ancestors)tactics.
Conversation Protocol.The conversation protocol is based in the inquiry-pattern (Figure 3).The initiative of starting the game is undertaken by the Provider when it needs to disambiguate a request.The schema of the conversation is similar to the Explorative Game (Figure 2).
Policies for concept disambiguation.In UMIS, we consider two concepts as the same concept when a certain threshold is passed (t = 0.55).We use the following formula (Formula (4)): where sim'(c 1 , c 2 ) represents an approximation of the similarity between the two concepts c 1 and c 2 computed only on the exchanged properties (a minimal set of properties is considered).An additive factor of 0.2 is added for each superclass shared between the two concepts (sameSuper i = 1 when the superclass is shared, 0 otherwise).
Reliability.With respect to the reliability, in the framework when the computed threshold is higher than 0.8, the reliability of the concept is considered not affected by the uncertainty deriving from the disambiguation procedure.In the other cases the reliability of the concept is weighed on the computed value.Copyright © 2012 SciRes.AIT

A Service Architecture for User Model Interoperability
The UMIS service (Figure 5) is composed by a centralized set of tools (Enhanced User Model UDDI Registry (EUMUR) (Section 4.2) that UM-based Web Services (UM-WS) (Section 4.1) can exploit to exchange user data.

UM-Based Web Services
To join the framework, each UM-based web service (UM-WS) has to offer a Web Service interface and provide the basic WSDL operations required to interact with other services, and the interface to interact with the central registry (Section 4.2).We consider as mandatory at ast the imple ain co r, where Statement is a complex y for the definition of the domain knowledge.

UDDI Registry
shares the same ontology, which games it supports, and to start a conversation with it.It is composed by: Communication Tools, the definitions of the Dialogue Games elements: Conversation Protocol: the sequence of messages a UM-WS has to manage according to its role.
Content Tactics of the game.
Dialogue Game: the reference to the Conversation Protocol and to the Content Tactics of the game.
Service declaration, the list of the available UM-based Web Services, with the Communication Tools they support: Service Name: the UM-WS's name.
Wsdl reference: the reference to the WSDL file with the operations it offers.
Ontologies: the domain ontologies it refers to.play.ncept for a certain use type representing a Statement (Section 3).Then, a set of operations representing the moves specific for the games can be implemented, i.e. inform, request, inquire, deny, agree, disagree.Moreover the UM-WS has to refer to an ontolog

The Enhanced User Model
The Enhanced User Model UDDI Registry (EUMUR) is a centralized shared component with the goal of offering a UDDI registry and a search service (Search Network Buffer).

Search Network Buffer
The Search Network Buffer (SNB) is a shared network space able to auto ders of specific UM features.The interaction model is managed according to the publish/subscribe e UM-WSs subscribe to the SNB asking to be notified (as a Provider) when a certain kind of request arrives into the SNB.When a UM-WS (acting as a Requestor) looks for some user information, it publishes a request to the SNB with the desired feature.Then the SNB notifies all the services subscribed and the service havi lue can notify their availability to exchange this information always through the SNB (Figure 6).
In the SNB the user features values are not nce the interaction consists only in requests odel features, and in responses of availability.change of the values will take place directly between the UM-WSs.In this way, the Requestor is free to select, according to its internal policies, which UM-WS to consult as Provider, and the Provider is free privacy policies.
The general format of a request published on the SNB is: (Sender Name, Inquiry, Interest, Type, Ontology, Object, User ID) where in particular:  Type: is the typology of the request: byUri (if the requested object refers to an ontology URI), and byLabel (if the object is expressed with a label);  Object: if Type = byUri, it is the URI that identifies the requested concept; if Type = byLabel, it is the Label associated to the concept; For instance if UM-WS-A needs the interest of the user us44 in the concept Barolo of the ontology Food, it invokes on the SNB the operation: publish (UM-WS-A, Inquiry, Interest, byUri, Food, null, Barolo, us44).All -WSs subscribed (by means of t scribe an example of UMIS usage, prese i data items according to the Linda [23] tuple space model.
To implement the Dialogue Game, each application has to manage the status of the conversation and to select xecute, and to decide when the goal has abilities are closely related to the business logic of each application and thus they can not be delegated to some external component.Thus, an ad hoc component managing the Dialogue Game has to be integrated in the application.For this purpose, we developed the Dialogue Manager module, which implements the logic of the Dialogue Games and maintains the status of each conversation instance.In order to execute the content tactics required by the games, it contains a special purpose java class with the needed general-purpose SPARQL queries over a OWL ontology, i.e. to extract the parents, the ancestors, the siblings, the children, the properties of a concept.
his prototype implementation is to make easier for existing applications to exploit UMIS.To composed by a set java-based libraries implementing a Proxy IN Interface (acting as a s and the framework), and a set he APIs offered by he requests coming re the following to apply its own which action to e been reached.These the UM su he operation: A goal of t bscribe (M-WS-X, Inquiry, Interest, byUri, Food) will be notified by the SNB.

UMIS in Action
In this Sec.we de nting some technical details about the developed prototype and describing two use cases.

Prototype Implementation
To implement the UDDI registry, we chose to adopt ddi, an open source Java implementation o ju f UDDI specification for Web Services.We then represent the additional information requested by our registry exploitng the mechanism offered by tModel, an abstraction for a technical specification of a service type offered by an UDDI registry.
To implement the SNB, we exploit the GigaSpaces middleware, which offers a robust implementation in of the JavaSpaces paradigm supporting the propagation of minimize this effort, we developed a UMIS Wrappers component (Figure 7) proxy between the system of wrappers managing the interaction with the other components in the framework.Each wrapper offers to the Proxy IN Interface a set of APIs to interact with the component it manages, and invokes t the Proxy IN Interface to manage t from such components.The wrappers a ones: WSwrapper: provides the implementation of the WSDL operations for communicating with the other services: it translates the SOAP messages into the format managed by the Proxy IN Interface.It also provides the Proxy IN Interface with the facilities to invoke the WSDL operations offered by the other services; SNBwrapper: manages the communication with the SNB implementing the publish/subscribe pattern and

mediating the interaction with the Proxy IN Interface;
UDDIwrapper: manages the communication with the UDDI registry, offering a set of APIs to query the registry.
We designed the Proxy IN Interface in order to decouple the defined wrappers from the technologies and the communication protocols used by the wrapped application.The independence of the wrapped application enables the integration of heterogeneous kind of adaptive applications, based on different environments and technologies.As showed in Figure 7 a configUMIS.xmlfile is accessed by the UMIS Wrappers; it stores configuration information to be used at initialization time (e.g. the ontologies).

Use Case
In order to test our solution, we integrated an existing adaptive system, iCITY [9], a Turin events recommen-der 3 into UMIS.To this purpose we coded the Proxy-INiCITY class, the implementation of the Proxy IN Interface that mediates between the existing iCITY REST interface and the UMIS Wrappers, and we filled the requested initialization information about iCITY.Then we made a change on the iCITY sw module for user data access, adding the invocation of the ProxyINiCITY to search for the missing data.We also added the Dia-logueManager component into iCITY, in order to start new games instance according to some simple rules: 1) a new Game is started each time is requested by an other application; 2) a new Clarification Game is started for each request that does not refer to a shared ontology; 3) a new Explorative Game is started when the reliability of the value is lower than 0.5 or when no one can give a response.
Then, we connected to UMIS two d eveloped providing web service interfaces to existing he fo s collaborate using UMIS.WS-FOOD and WS-A refore, WS-FOOD publishes a request into the SNB implemented by the GigaSpace server: publish uiry, Interest, byUri, Food, #RedWine, e sibling concepts (tactic tc3).Table 1 shows the obtained values and their reliability ummy applications, cepts, and then in th d internal repositories of user data: 1) WS-FOOD, in t od domain; and 2) WS-ART, in cultural events domain.In such an environment, we run our tests making such system RT share a subset of users with iCITY.Figure 8 illustrates the entries in the Web Services Declaration component in the registry for the scenario.
As use case we consider WS-FOOD interacting with the user Roby.In particular, it needs his Interest in the concept RedWine in its domain ontology Food (Figure 1).
Discovery.WS-FOOD has to find another adaptive system, working in a similar domain and storing a model of Roby.The (WS-FOOD, Inq Roby).GigaSpace notifies the iCITY (its Gigawrapper component), which has been previously subscribed to this kind of request.iCITY has the requested value and publishes its availability on the SNB.
P2P request-response.WS-FOOD, reading such information from the SNB, directly contacts iCITY, by means of the provided WSDL interface (WSwrapper), asking for the value: getValue (Roby, Interest, #Red-Wine).
Dialogue-based negotiation for value derivation.The reliability of the value provided by iCITY is considered too low by WS-FOOD.In this situation, an Explorative Game can be played for finding other possible related concepts that can be used instead (Section 3.3.1).Looking at the registry WS-FOOD discovers that iCITY is able to play such a game.Following the conversation protocol of the game, WS-FOOD asks for Roby's interest in the parent concept of RedWine, in the children con-together with the similarity degree (column sim) with respect to the starting concept.Applying the value derivation defined in Section 3.2.1, the interest in RedWine is 0.74 with a reliability of 0.73.
Dialogue-based negotiation for concepts disambiguation.As second example, WS-ART has to suggest Roby a touristic tour for the weekend and it needs to know if he is interested in visiting the city of Barolo, represented as the concept #Barolo in its ontology Geo-Local (Figure 4).Since no system in the framework shares this ontology (no entry in the registry), it submits to the SNB the byLabel request: publish (iCITY, inquiry, Interest, byLabel, Places, Barolo, Roby).iCITY has the label Barolo associated to a concept in its ontology Food as wine and in its ontology GeoLocal as place.In order to figure out if one of the two concepts is the requested one, it exploits the Clarification Game (Section 3.

Evaluation
In this section we discuss the evaluation of UMIS under different perspectives.First, we wanted to test the performance of UMIS communication process, i.e., the additional network traffic and the communication cost for the Requestor (Section 6.1).Second, we aimed at seeing how our solution affects the quality of the UM exchange, i.e., the effectiveness of the exchange (how many times the communication ends positively) (Section 6.2). tion in the use case.

Performance Evaluation
We evaluated the UMIS communication process measuring: the network traffic and the communication cost.Network traffic.We wanted to measure the additional network traffic generated by the introduction of UMIS in a decentralized collaboration.We compared in Table 2 the number of data exchanged among iCITY and N Web Services (WS-1, WS-2, WS-N), when iCITY looks for some user value without using UMIS (row 1) and using UMIS (row 2).If UMIS is not used, iCITY has to directly contact each WS, hence it sends a maximum of N messages.Each WS-i can receive network traffic generated is of N m case.Ins UMIS is u lways two interactions (publish the request and read the answer) with the S nb in the when the requested data is not available at all (Null).
In a centralized solution, the cost is always 4 (2 for sending a request and 2 for receiving the value).In UMIS each system declares if it has the value, then in the First case the cost is always 6 (2 for the communication with the SNB (publish and read), and 4 for the communication with the service with the value), in the All M case is 1 for publishing, plus M for reading all the M answers and 4 M for interacting with each service.In the Null case is always 1 (request).In a pure decentralized solution the cost in the first case depends on when the seres are founded.In other cases eac .In general, we can conclude that r approach is proportional to the atio N/M increases uch differe e scattered in the network: if each system keeps different UM fragments, the convenience is close to a cen ed solution (and better tha centralized sol s); if all the syste ave the sa user data, it is worse than classical decentralized sol 1 essages in the worst WS has to be contacted the convenience of ou message and the vices with the valu tead, if sed, iCITY a performs r NB (2s ), pl ex with an e W e) S-i perform n if sub teraction e req (1 of avail, only if it has the requeste WS-i can have 1 message exchan global network traffic generated is at most of 2N interactions with the SNB and 1 message between the service e can conclude that even if the amount of exchanged data is growing using our approach, the difference strongly depends on the different cases 4 .However, the wider part of the traffic overhead is in charge of the SNB, which is specifically designed to scale on large numbers without loosing in performance. Communication costs.We also examined the communication process in term of communication cost for the Requestor, with respect to a centralized/decentralized approach.To do so, we approximated the cost of each interaction with the SNB (publish, notification, read) as 1, and the cost of each SOAP message (send or receive) as 2 (due to their different complexity and dimension).Table 3 summarizes the cost paid by Requestor, considering that, after a request to the SNB, M of the N systems in the framework keep the requested data.Row I shows the cost when for the Requestor the first obtained data is sufficient (First), Row II when the Requestor wants to look for all the available values (All M), and Row III

Communication Effectiveness
As a second step, we wanted to verify how the use of UMIS impacts on the global effectiveness of communication for the exchange of UM, i.e. the requestor gains the desired value.
Testbed.As testing environment, we used the enviro Simulation parameters.In the test setting, iCITY needs the values of the user's interest in concepts of the shared ontology Food and of the non shared ontology GeoLocal.
Metrics.In each test, we measured the quality of the exchange (QoE), defined in [25] as the number of exchange that succeeded 5 , n(succ), out of the total number of exchange, n(tot) (Formula (5)):  We performed two tests: one implem plorative Game and one implementi enting the Exng Clarification sponses; and 2) how it im the effectiveness of exchanging UM data.
We measured uality of the exc (QoE) considering an exchange as successful when the derived val has relia 0.5.We simu iCITY the nee of the v 's Interes ts in the ared ontology Food.First, iCITY asks the SNB, disring that the data are available times (60%).In the remaining 16  We measured again the quality of exchange resulted by the application of the clarification game, considering the data exchange as successful when the concept is correctly disambiguated.We simulated in iCITY the need of the value of the user Interest in 20 concepts of its not shared ontology GeoLocal.Table 4 summarizes the results of the Clarification Game execution in these cases.In the table the column "answer" keeps the percentage of the time the game returns positive answers (same concept, 12 ca lumns "correct" and "incorrect" represent for each row the correctness of the final disambiguation process.The central shared space and delivered to the applications through a client-server architecture (e.g.UMS [27]).This solution is widely adopted since it allows different applications to access the same user kn quality of exchange in this case is: QoE = n (correct)/n (tot) = 14/20 = 0.7.
of communication, the U w impr UMIS a clarif game the qua .

Rela rk
ommunica pe e arting from t oaches gain dep ang plications on devices with limited memory to exploit a UM.However, such centralized approach imposes a set of user features and a non-negotiable format of representation and protocols.Inste oach [5], each system maintains a user model and interact with other systems in a peer-to-peer way (e.g.SUMI [28]).Advantages are flexibility in managing privacy and efficiency in obtaining only the necessary data.UMIS can be considered as a mixed approach: it is decentralized (each system has its UM and exchange data in a p2p way) and centralized (it offers a centralized discovery tool).
Semantic interpretation.We can distinguish two main approaches for data interpretation: common representation and conversion.In the first one, a uniform representation of the UM is required [22].This is very restrictive ws this e we chose not to impose to use a hus some form of concepts mapsemantic interpretation) is reported in [32] to instance-based [33].In our appro cation can negotiate or reaching an agreement ov shared concepts usi g a negotiation protocol (C cation Game) s disambiguation, bas schema-based raph-based techniques With respect to standard mapping solutions, our ap-desired user data and how to interact with it.Regarding echanism, other works proposed a central repository which acts as a broker sys [42,43].Other hes propose a sim tion but in a totally dec d perspective, suc ].

Conclusions
(or no eterogeneous systems supported; in the UM inte based and collaborative-filtering based) [24].
for applications, but it does not suffer from semantic ambiguities.The second approach instead lets free each application to represent UM as it prefers and then to use suitable techniques to ensure semantic interoperability (e.g.Mediator [29], IDIUMS [30]).UMIS follo second approach, sinc unique ontology, and t ping is necessary.A comparison with most relevant related work with respect to this two features (interoperability architecture and Table 5.
The main contribution of this work is mainly related to mapping and communication modalities.
Mapping.In the literature, different methodologies for mapping have been proposed [31], from schema-based Act-based approach coming from multi-agents fields to specify the conversation flow between Web Services allows extending the interface in a direction of more flexibility and dynamism, managing more-than-twoturns interactions and defining different communication behaviors as response to messages [39,40].
One central aspect of our framework is an enhanced UDDI registry offering a discovery tool (SNB).The idea to enrich UDDI registry with semantic information is not ne ach, each appli-our discovery m f n er not larififor concept ed on mapping and g [34].
proach, even if more suitable for small ontologies, it is ready-to-use, allowing to perform a basic form of ontology mapping at a run time, not requiring a pre-process task on ontologies or complex form of reasoning.Similarly to us, other approaches proposed to use negotiation through a dialogue [35] in order to enhance standard mapping approaches.For example, [36] solves semantic differences at run-time using the WordNet lexicon6 ; [37] presents an ontology negotiation protocol which enables agents to exchange parts of their ontologies by a process of interpretations, clarifications, and explanations; [38] presents a method for accepting a set of candidate mapping correspondences among concepts of different ontologies according to agents preferences and beliefs.
We use the dialogue model also to derive the value in the answers using related concepts (in Explorative Game).With respect to more complex forms of value propagation (e.g.Bayesian Networks) that requires a remarkable configuration efforts by applications, our solution can be more easily adopted by applications to guess missing values.
Communication.With respect to st andard request-response communication of Web service, the dialogue model is a mean for enriching the ineraction of Web Services with negotiation capabilities.The use of Speech-The paper proposed UMIS, a set of services that support web-based user-adaptive applications in sharing user model data, in a loosely-coupled way and with little changes in their internal logics and knowledge representation.The main contribution of the work is to support the process of interoperability in three phases: 1) it provides an efficient centralized service discovery tool; 2) it offers an effective simple basic model of interaction for the exchange of UM value in a p2p way; 3) it offers a negotiation mechanism that can be used when the second step fails, in case of semantic ambiguities or missing w in Semantic Web community [41], but in general the goal is to describe the services in order to facilitate the discovery.Our registry works in a more bounded context, where all the services exchange UM knowledge, and thus here the need is limited to discover who maintains the tem, such as ilar solu approac entralize h as [44 n satisfactory) responses.UMIS has been conceived to support interoperability among content-based adaptive applications representing their User Models by means of property-based linear parameters.However, a framework for interoperability becomes as more useful as it is able to increase the number of h roperability context this means to support systems using different User Model representations.The basic principles of the framework logic makes it able to deal with different types of heterogeneity: different kinds of users information (both domain-dependent and independent), different user model representation (such as probabilistic model), different adaptive applications (both content- Finally, we can mention the management of the possil based model gives t (or modify existing ones) in a seamless way.In order to enable applications to collaborate in this environment we provide them with a set of software tools to reduce their integration efforts.However, part of the integration remains still in charge of the applications that have to make ion (Section 5).UMIS e chnique to mbigu oul lities o frame tance, the e lemented can be used a m [45] ing capabil in th b e novel issues the Social Semantic Web context [46,47] (e.g.privacy management, users reputation and systems proof).

Figure 1 .
Figure 1.A portion of the domain ontology Food.

Figure 2 .
Figure 2. Conversation protocol for the Explorative Game from the Requestor point of view.

Figure 3 .
Figure 3. Conversation protocol for the clarification game from the provider int of view.0] according to the revised model: rivation of the value

Figure 4 .
Figure 4.A portion of the domain ontology GeoLocal with the context of the concept Barolo.

Figure 7 .
Figure 7. Service declaration in the use case.
3.2).(Fig-Since the concept Barolo in GeoLocal ontology ure 4) shares the property has_coordinates and the super-classes Cuneo and Piedmont with the concept in the WS-ART ontology, it concludes that they are the same concept.

Figure 8 .
Service declara Section 5 (iCITY, WS-FOOD, and WS-ART).The dataset is composed by data about 25 users shared by the systems.The UMs of the systems refer to three domain ontologies: Food, shared by iCITY and WS-FOOD (60 concepts), Place (258 concepts), used by WS-ART, and GeoLocal (180 concepts), used by iCITY.
the Dialogue Games it is able to ment get Value (user ID, feature, concept) to inquiry the value of the UM feature with respect to a dom

Table 5 . A comparison with m Architecture ost relevant related work.
Sections 4 and 5, UMIS architecture offers a certain level of flexibility.First, the UMIS Wrapper architecture provides a high level of decoupling between the components of the framework.The ProxyINInterface allows an easy integration of heterogeneous systems based on different technologies.Second, the SNB eventhe possibility to add new components their custom proxy implementat uses Dialogue Gam model as a negotiation te