There is an extensive class of Web applications that involve predicting user responses to options. Such a facility is called a recommendation system. We shall begin this chapter with a survey of the most important examples of these systems. However, to bring the problem into focus, two good examples of recommendation systems are:

1. (1) Offering news articles to on-line newspaper readers, based on a prediction of reader interests.

2. (2) Offering customers of an on-line retailer suggestions about what they might like to buy, based on their past history of purchases and/or product searches.

Recommendation systems use a number of different technologies. We can classify these systems into two broad groups.

• Content-based systems examine properties of the items recommended. For instance, if a Netflix user has watched many cowboy movies, then recommend a movie classified in the database as having the “cowboy” genre.

• Collaborative filtering systems recommend items based on similarity measures between users and/or items. The items recommended to a user are those preferred by similar users. This sort of recommendation system can use the groundwork laid in Chapter 3 on similarity search and Chapter 7 on clustering. However, these technologies by themselves are not sufficient, and there are some new algorithms that have proven effective for recommendation systems.

A Model for Recommendation Systems

In this section we introduce a model for recommendation systems, based on a utility matrix of preferences. We introduce the concept of a “long-tail,” which explains the advantage of on-line vendors over conventional, brick-and-mortar vendors. We then briefly survey the sorts of applications in which recommendation systems have proved useful.

9.1.1 The Utility Matrix

In a recommendation-system application there are two classes of entities, which we shall refer to as users and items. Users have preferences for certain items, and these preferences must be teased out of the data.

Most of the algorithms described in this book assume that we are mining a database. That is, all our data is available when and if we want it. In this chapter, we shall make another assumption: data arrives in a stream or streams, and if it is not processed immediately or stored, then it is lost forever. Moreover, we shall assume that the data arrives so rapidly that it is not feasible to store it all in active storage (i.e., in a conventional database), and then interact with it at the time of our choosing.

The algorithms for processing streams each involve summarization of the stream in some way. We shall start by considering how to make a useful sample of a stream and how to filter a stream to eliminate most of the “undesirable” elements. We then show how to estimate the number of different elements in a stream using much less storage than would be required if we listed all the elements we have seen.

Another approach to summarizing a stream is to look at only a fixed-length “window” consisting of the last n elements for some (typically large) n. We then query the window as if it were a relation in a database. If there are many streams and/or n is large, we may not be able to store the entire window for every stream, so we need to summarize even the windows. We address the fundamental problem of maintaining an approximate count on the number of 1s in the window of a bit stream, while using much less space than would be needed to store the entire window itself. This technique generalizes to approximating various kinds of sums.

The Stream Data Model

Let us begin by discussing the elements of streams and stream processing. We explain the difference between streams and databases and the special problems that arise when dealing with streams. Some typical applications where the stream model applies will be examined.

There is much information to be gained by analyzing the large-scale data that is derived from social networks. The best-known example of a social network is the “friends” relation found on sites like Facebook. However, as we shall see there are many other sources of data that connect people or other entities.

In this chapter, we shall study techniques for analyzing such networks. An important question about a social network is how to identify “communities;” that is, subsets of the nodes (people or other entities that form the network) with unusually strong connections. Some of the techniques used to identify communities are similar to the clustering algorithms we discussed in Chapter 7. However, communities almost never partition the set of nodes in a network. Rather, communities usually overlap. For example, you may belong to several communities of friends or classmates. The people from one community tend to know each other, but people from two different communities rarely know each other. You would not want to be assigned to only one of the communities, nor would it make sense to cluster all the people from all your communities into one cluster.

Also in this chapter we explore efficient algorithms for discovering other properties of graphs. We look at “simrank,” a way to discover similarities among nodes of a graph. We explore triangle counting as a way to measure the connectedness of a community. We give efficient algorithms for exact and approximate measurement of the neighborhood sizes of nodes in a graph. Finally, we look at efficient algorithms for computing the transitive closure.

Social Networks as Graphs

We begin our discussion of social networks by introducing a graph model. Not every graph is a suitable representation of what we intuitively regard as a social network. We therefore discuss the idea of “locality,” the property of social networks that says nodes and edges of the graph tend to cluster in communities. This section also looks at some of the kinds of social networks that occur in practice.

In the previous chapters, we saw that finding optimal offers can be computationally expensive, especially in the context of solving the trade-off problem for the PDP and for finding optimal agendas. Because software agents have limited computational resources at their disposal, heuristic approaches can be useful for the design of negotiating agents in such situations. In such approaches, a heuristic is used to generate counter offers that are “good enough” (i.e., close to optimum) but not necessarily optimal.

Dealing with the bounded rationality of agents is just one of the reasons for using a heuristic approach. Another reason is that an opponent might not always play equilibrium strategies. In such cases, a strategy that is a best reply to the opponent's strategy must be played rather than an equilibrium one.

Irrespective of the reason for using this approach, heuristics can be designed for a number of purposes. For example, they can be designed to generate optimal counter offers, to predict information about an opponent, or to find optimal agendas. Research into the design of heuristics has been growing continuously and several different approaches – including local search methods, approximation methods, and machine learning methods – have been adopted. Below, we introduce a number of representative works in terms of their key underlying ideas, goals, and main results.

In our everyday lives, negotiation is ubiquitous. At work, we bargain with clients about the terms of a contract; we bargain with our boss about a pay rise when the contract is signed. At home, we bargain with our partners about who will tidy the house; we bargain with our children about how many stories they can read before bed. And politicians, of course, routinely bargain in situations that have life or death consequences. The purpose of negotiation is to reach an agreement, and in particular, agreement in the presence of conflicting goals and preferences. If your preferences, goals, and aspirations were completely aligned with mine, then there would be no conflict, and hence there would be no need for negotiation. In this case, the best outcome for me would also be the best outcome for you, and so we could simply determine such an outcome, and then implement it. Neither of us would have any incentive other than to find such a mutually optimal best outcome – our joint problem is nothing more than an optimisation problem. Unfortunately, of course, the real world is not like that. More often than not, people have very different goals and preferences, and when this occurs, some method is required to find an outcome that will be acceptable to all concerned. Negotiation provides such a mechanism.

We turn in this chapter to one of the major families of techniques for characterizing data: the discovery of frequent itemsets. This problem is often viewed as the discovery of “association rules,” although the latter is a more complex characterization of data, whose discovery depends fundamentally on the discovery of frequent itemsets.

To begin, we introduce the “market-basket” model of data, which is essentially a many-many relationship between two kinds of elements, called “items” and “baskets,” but with some assumptions about the shape of the data. The frequent-itemsets problem is that of finding sets of items that appear in (are related to) many of the same baskets.

The problem of finding frequent itemsets differs from the similarity search discussed in Chapter 3. Here we are interested in the absolute number of baskets that contain a particular set of items. In Chapter 3 we wanted items that have a large fraction of their baskets in common, even if the absolute number of baskets is small.

The difference leads to a new class of algorithms for finding frequent itemsets. We begin with the A-Priori Algorithm, which works by eliminating most large sets as candidates by looking first at smaller sets and recognizing that a large set cannot be frequent unless all its subsets are. We then consider various improvements to the basic A-Priori idea, concentrating on very large data sets that stress the available main memory.

Next, we consider approximate algorithms that work faster but are not guaranteed to find all frequent itemsets. Also in this class of algorithms are those that exploit parallelism, including the parallelism we can obtain through a MapReduce formulation. Finally, we discuss briefly how to find frequent itemsets in a data stream.

The Market-Basket Model

The market-basket model of data is used to describe a common form of many-many relationship between two kinds of objects.

One of the biggest changes in our lives in the decade following the turn of the century was the availability of efficient and accurate Web search, through search engines such as Google. While Google was not the first search engine, it was the first able to defeat the spammers who had made search almost useless. Moreover, the innovation provided by Google was a nontrivial technological advance, called “PageRank.” We shall begin the chapter by explaining what PageRank is and how it is computed efficiently.

Yet the war between those who want to make the Web useful and those who would exploit it for their own purposes is never over. When PageRank was established as an essential technique for a search engine, spammers invented ways to manipulate the PageRank of a Web page, often called link spam. That development led to the response of TrustRank and other techniques for preventing spammers from attacking PageRank. We shall discuss TrustRank and other approaches to detecting link spam.

Finally, this chapter also covers some variations on PageRank. These techniques include topic-sensitive PageRank (which can also be adapted for combating link spam) and the HITS, or “hubs and authorities” approach to evaluating pages on the Web.

PageRank

We begin with a portion of the history of search engines, in order to motivate the definition of PageRank, a tool for evaluating the importance of Web pages in a way that it is not easy to fool. We introduce the idea of “random surfers,” to explain why PageRank is effective. We then introduce the technique of “taxation” or recycling of random surfers, in order to avoid certain Web structures that present problems for the simple version of PageRank.

5.1.1. Early Search Engines and Term Spam

There were many search engines before Google. Largely, they worked by crawling the Web and listing the terms (words or other strings of characters other than white space) found in each page, in an inverted index.

So far in the book, we have been focusing on situations in which all the negotiating participants are software agents. However, there are many applications where automated negotiators should be able to interact proficiently and collaborate with people. Automated negotiators can be used with humans in the loop or without them. When used with humans, they can alleviate some of the effort required of people during negotiations and can assist people less qualified in the negotiation process (Kersten and Lai, 2007). Also, there may be situations in which automated negotiators can even replace human negotiators (Durenard, 2013). Another possibility is for people embarking on important negotiation tasks to use these agents as a training tool, prior to actually performing the task (Lin et al., 2014). For example, automated negotiators in e-commerce applications can bargain over a price with their site's buyers (Kauppi et al., 2013). Personalised agents that support their users can negotiate with humans with conflicting preferences towards deciding on a meeting time (Tambe, 2008). They can also negotiate the formation of a “care plan” for patients requiring a course of medical treatment (Amir et al., 2013). A person who is preparing for a job interview can train herself with an agent that plays the role of the employer (Lin et al., 2009).

In this chapter we discuss a number of applications where agents can be used to negotiate on behalf of their human counterparts. In general, agents can be used for any kind of negotiation over the allocation of limited resources. For our discussion, however, we focus on the following representative cases. While some of the applications will involve direct negotiations between the parties, others will go through a trusted mediator. Also, while some will only involve software agents, others will deal with both software agents and human negotiators. Then, some applications will be for bilateral negotiations and others for multilateral ones. Finally, some will be industrial applications and others commercial ones.

12.1 Business process management

A business process is composed of a number of interdependent tasks that must be executed in a controlled and ordered way. This execution involves the consumption of resources. In most organisations, these resources are grouped into business units that control the way in which they are deployed. This is also the case with the British Telecom (BT) business process of providing a quote to a customer for installing a network to deliver a specific type of telecommunications service. For the management of this process, Jennings et al. (2000) and Norman et al. (1997) developed an agent-based negotiation framework called Adept (Advanced Decision Environment for Process Tasks).

In this chapter, we turn our attention to negotiation mechanisms – the protocols that will be used by agents when negotiating over domains of the type discussed in the preceding chapter. The first protocol we look at is concerned with negotiation over a single issue. Many real-world situations involve negotiation over a single issue. Typical examples include a buyer and a seller negotiating over the sale price of a commodity, a landlord and a tenant negotiating over the rental price of some accommodation, and an employer and an employee negotiating over the employee's salary. We will refer to the issue over which negotiation takes place as a “pie”, with the terminology arising from the analogy of a group of people negotiating about how to share a pie amongst themselves.

We know that, in order to negotiate, the parties must follow a protocol. There are many different protocols in the literature on negotiation, but arguably the most influential of these is the alternating offers protocol. This protocol was first analysed by Ingolf Stahl (1972) in the context of the division of a discretely divisible pie (i.e., a pie that can only be divided in a finite number of ways), and later by Ariel Rubinstein (1982) in the context of the division of a continuously divisible pie (i.e., any division of the pie is possible).

We all of us have to negotiate – whether formally, as part of our jobs, or informally, as part of our everyday lives – and the outcomes of our negotiations have direct and often dramatic consequences, for us and others. However, it is surely a safe bet that most of us wish we were better negotiators. There are many reasons why we might not be as good at negotiating as we would wish. For one thing, it is often hard for us to really understand the issues at stake and the consequences of various potential settlements, and for this reason we can end up with outcomes that are not as good as those that we might in fact have been able to obtain. Moreover, in many cultures, negotiation is regarded as greedy or impolite, and as a consequence, some people may find it socially awkward or stressful to negotiate. Cultural inhibitions like these can prevent us from obtaining the best outcome even when the topic of negotiation is of great importance to us. Wouldn't it be wonderful, then, if we had computers that could effectively negotiate on our behalf…? In short, the main aim of this book is to investigate this idea.