With the beginning of the new millenium, the concept of group interactions in communication systems was boosted by the emergence of Web 2.0 technologies. Based on this new area of application, the notion of group decisions and group preferences also evolved, leading to new requirements for corresponding modeling frameworks. Purely numeric approaches are barely able to meet these newly emerging challenges. Therefore, we provide a comprehensive group preference framework to overcome the deficits of previous solutions and demonstrate possible applications in social network services. The concept provides both numeric and semantic means which can be applied to determine group preferences and to perform further evaluations based on the semantic value of preference terms. With Preference SQL a powerful system exists to implement the presented group preference model using standard commercial databases.
With the beginning of the new millenium, the concept of
group interactions in communication systems was boosted
by the emergence of Web 2.0 technologies. From social
networking sites to e-commerce platforms, communities have
been established allowing users to provide recommendations
for products or to share common interests. Consequently,
the next step in this development is to combine these
single user valuations into consensus decisions for a group.
Lately, a new method has been introduced to combine
single user ratings into a common group recommendation [
Numeric approaches often determine an implicit utility
function based on previous decisions of a group member in order
to determine group member preferences. This generalization
of past preferences has to be assessed critically since
environmental aspects and moderator variables [
A preference P of the kind “I like y more than x” is
formally defined as x <P y. This intuitive definition of
preferences in terms of “better-than” has a natural counterpart
in mathematics, namely strict partial orders. Besides basic
“better-than” preferences, often complex valuations have to
be expressed, which requires the accumulation of base
preferences into more complex ones. This leads to the inductive
construction of preferences P = (A, <P ) with the help of
complex preference constructors. P is accordingly specified
by a preference term wich fixes the attribute names A and
the strict partial order <P . Like base preferences, preference
terms that consist of complex preference constructors also
respresent strict partial orders, therefore laying the
foundation for a preference algebra [
Group members express their preferences on single attributes which can have either numerical or non-numerical domains. Numeric preferences include amongst others: • LOWEST(A): x <P y iff x > y • HIGHEST(A): x <P y iff x < y • AROUND(A,z): x <P y iff |x − z| > |y − z| • SCORE(A,f): x <P y iff f (x) < f (y) for a function f Non-numerical preferences determine likes or dislikes on categoric attribute values and are e.g. expressed by: • POS(A, pos): x <P y iff x 6∈ pos ∧ y ∈ pos, with pos being a set of preferred values • NEG(A,neg): x <P y iff y 6∈ neg ∧ x ∈ neg, with neg being a set of disliked values Each group member specifies base preferences on some or all attributes A1, . . . , An of a relation R. These base preferences are afterwards combined using complex preference constructors such as: • Pareto P1 ⊗ P2: equal importance of preferences P1 and P2 • Prioritization P1&P2: preference P1 is more important than P2 The Pareto constructor stands for equal importance of participating preferences. In contrast, a prioritization constructor expresses a favor for the preference provided as first attribute. Only if two tuples are equally important concerning the first preference then the second preference is used for further discrimination.
As a result of this first step towards a common group preference, a complex preference term for each group member in preference algebra is formed. In a second step, these terms T1, . . . , Tk of k single members are combined into a single group preference.
Given k single user preference terms T1, . . . , Tk there are multiple ways to form a group preference by using the complex preference constructors described before. A group hierarchy can be introduced by the use of Pareto and prioritization constructors. A flat hierarchy in which all group members are of equal value is defined by a group preference
Pgroup = T1 ⊗ . . . ⊗ Tk.
Accordingly, some group members can be marked as more important than others by the use of the prioritization constructor, e.g.
Pgroup = T1&T2& . . . &Tk.
In this case, group member one is more important than group member two who is more important than group member three and so forth.
Most likely, these two possibilities are combined to form an individual group hierarchy, e.g. (1) (2) Pgroup = T1&(T2 ⊗ . . . ⊗ Tk). (3) Especially hierarchy patterns depicted in equations 1 and 3 frequently occur, with the first equation describing a group with no hierarchy and the third equation a group with one leader amongst otherwise equal members. However, virtually all combinations of single user terms are possible, e.g.
Pgroup = T1&(T2 ⊗ T3 ⊗ Tk−2&(Tk−1 ⊗ Tk)). (4) Equivalent to single users preferences, group preferences can be transformed to statements in Preference SQL for further evaluation.
The Preference SQL (PSQL) system implements the SQL 92 standard and additionally supports a PREFERRING clause which allows the expression of soft constraints. Hence, it provides a powerful means to implement group preferences in present database systems. A user preference term in preference algebra can be transformed into an equivalent PSQL statement which is evaluated by PSQL. The result of such a preference query for preference P on relation R is denoted as σ[P ](R). Preference queries are evaluated according to a Best-Matches-Only strategy (BMO) which means that a perfect match is returned if such tuples exist and otherwise the best matches are retrieved but nothing worse. This proceeding behaves contrary to conventional SQL queries which determine only exact matches. As a consequence, preference queries represent soft constraints that should be fulfilled while SQL queries are interpreted as hard constraints that have to be matched without exception. A PSQL statement is similar to a SQL statement, with the distinctive feature of an additional PREFERRING clause:
Within the PREFERRING clause, POS preferences are indicated by the keyword IN followed by the set of preferred values while NEG preferences are indicated by NOT IN and group preference contains more than just the aggregation of single user preferences P∪ = σ[PU1 ](R) ∪ σ[PU2 ](R) or the intersection P∩ = σ[PU1 ](R) ∩ σ[PU2 ](R). Instead, compromises are found such as the tour with id=4.
This effect becomes even more obvious if no perfect matches exist for single users: (5) • PU1 = P OS(dif, {easy}) ⊗ P OS(lsc, {sparse}) • PU2 = N EG(dif, {hard}) ⊗ N EG(lsc, {nice} the set of unliked values. AROUND and BETWEEN preferences are obviously stated by the corresponding keywords AROUND and BETWEEN in combination with a numeric value or interval. Finally, the Pareto constructor is described by the keyword AND while PRIOR TO stands for a prioritization.
While an extended documentation of the PSQL syntax can
be found in [
(AROU N D(A3, 5) ⊗ BET W EEN (A4, [
AND A2 NOT IN (’lsc’))
Once a group preference is formed and the corresponding PSQL statement determined, a PSQL query returns the BMO set for the specified group preference. This result represents more than just the intersection of single user preferences as the following two examples based on tuples representing hiking tours illustrate: id 1 2 3 4 5 dif easy medium hard easy medium lsc nice sparse neutral special special
Based on the tuples depicted in Table 1, users U1 and U2 state the following preferences on attributes difficulty (dif ) and landscape (lsc): • PU1 = P OS(dif, {easy}) ⊗ P OS(lsc, {nice}) • PU2 = P OS(dif, {medium} ⊗ P OS(lsc, {special}) In this example it can easily be seen that user U1 favors the tuple with id=1 while U2 prefers the tuple with id=5. The result σ[PU1 ⊗ PU2 ](R) of the common group preference Pgroup = PU1 ⊗ PU2 is depicted in Table 2.
id 1 4 5 dif easy easy medium lsc nice special special Based on the results of single user preferences σ[PU1 ](R) for user U1 and σ[PU2 ](R) for U2 this evaluation shows that the In this case, no perfect match exists in R for both U1 and U2. The corresponding BMO sets for U1 and U2 are listed in Tables 3 and 4. Eventually, Table 5 shows the result σ[PU1 ⊗ PU2 ](R) of the combined group preference Pgroup = PU1 ⊗ PU2 for U1 and U2 which in this case is the intersection between the two single user preferences. However, example 1 already showed that this is not the case in general.
id 2 4
dif medium easy
lsc sparse special The two examples illustrate the behavior of group preferences consisting solely of base preferences and Pareto constructors. Correspondingly, the same results can be shown for group preferences using prioritization constructors and group terms consisting of a mixture of complex Pareto and prioritization preference terms. Furthermore, different preferences on the same attribute have been treated equally with respect to any other preference constellation in this evaluation. Considering the fact that semantically opposite preferences on the same attribute stated by different members of a group might end up in a common group preference, it becomes obvious that an approach disregarding preference semantics would produce poor group preference results. The concluding outlook therefore outlines how the special semantics of these pairings can be used as indicator for the formation of subgroups.
To illustrate the presented findings, a use case scenario is evaluated in the following section.
The formal foundations of previous sections are now all put to action in a fictionary social network service. In this scenario, a website offers a database of tours for various outdoor activities in which a user can find suitable entries by specifying desired tour features in a predefined search overview. Furthermore, a community exists in which every user keeps a profile. This profile can be used to store search results and to create personal tour entries which can be shared with other members of the community.
This pre-existing service is now augmented by the introduction of preferences into the search process. A user states preferences directly in the personal profile of the community. This process doesn’t have to be performed repeatedly and can be assisted by suitable GUI components for each preference, such as sliders for AROUND preferences or checkbox groups for POS or NEG preferences. These preferences are then transformed into equivalent PSQL statements on a relation containing the tour entries. Considering a user U1 and four tour attributes named difficulty, distance, duration and landscape in a relation called hiking, a preference for a distance close to 50 km, an easy difficulty level, a duration between five and six hours and a dislike for sparse landscapes can be expressed by the following PSQL statement:
This statement can be used any time the user whishes a tour suggestion and can be extended by hard constraints to restrict potential candidates to specific locations. In this case, if the relation also contains an attribute region, a corresponding request with restriction to tours in Franconia would be:
WHERE region = ’franconia’
This example of applying single user preferences in individualized search processes clearly highlights the advantages of preferences in contrast to conventional approaches via search masks and SQL. Using the conventional approach, the user has to state the same search criteria over and over again, even if user preferences remain constant. With the preference approach, preferences statements are only changed if the user preferences indeed evolve. Furthermore, PSQL results deliver BMO set which means that empty result and flooding effects are avoided. Conventional approaches, in contrast, show no result tolerance and thus don’t list tours that have distances of 52 or 49 kilometers if a distance of 50 kilometers is specified in the search statement. In this case, the user is required to frequently reformulate search requests to obtain suitable results.
Now consider the group function that is common to most social networking websites which allows users to join groups based on common interests. In this case, preferences provide a major improvement for the social network service. Once a user joins a group, e.g. the group representing the local hiking club, common group activities can be organized based on single user preferences. Considering PSQL conform preference terms T1, . . . , Tk for k group members, a common PSQL query is constructed as follows:
This presented statement reflects a flat group hierarchy. Furthermore, a group administrator might know of further restrictions that have to be imposed onto the group decision, e.g. limitations for the difficulty of the tour. These preference hierarchies can be integrated seamlessly:
Finally, administrators may form subgroups by the definition of critical attribute values, e.g. to define a beginner and an advanced hiking group:
After these groups are determined, single users have to be assigned to groups based on a quality metric that determines how good the user fits into a particular group.
Despite past activities of various disciplines in the exploration of group decisions, newly emerged areas of application demand an extended framework to model the complex process of group preference determination. This procedure of merging single user preferences into a group preference consequently raises the question of how well this group consensus represents the notion of every single group member. In contrast to group decision support systems which are constructed to force a consensus among members, social network services act upon the maxime that connections are formed freely by users who share common interests. While this assumption is certainly true with regard to some aspects, interests might yet differ in other parts of a specific domain. In the use case described in section 4, users built groups based on a common interest in outdoor activities or the membership in a hiking club. Nevertheless, essential differences might occur based on diverse ability levels, e.g. in terms of preferred tour difficulty. In these cases it might be more fortunate to form multiple subgroups instead of impose a single group on all members.
The presented preference framework provides various new insights to approach this problem. Preferences can be used to define a quality measure which in turn determines the homogeneity of a group by measuring the quality of its group preference. In case the measure is below a certain threshold, the semantics of preferences further allow to detect certain phenomena that lead to a heterogeneous outcome. This analysis finally delivers starting-points for the formation of subgroups.
Being able to explicitly state preferences in a community profile certainly is an additional benefit of the presented approach, however, it requires an extension of already installed social network services. For present networking sites a preference mining subservice might be of special interest that generates base preferences out of pre-existing text blocks. The presented approach provides a set of means which extend the possibilities of modeling group preference far beyond the status quo of numeric techniques and points out starting-points for new research efforts. The introduction of semantics into the group preference model provides an additional layer that can be used as background knowledge for informed heuristics. Most recent projects at the University of Augsburg include the definition of quality metrics for group preferences and the development of heuristics to improve that group quality dynamically. Future publications will address some of these newly emerged aspects in detail.