Nikos Manouselis et al. 429
• Date: contains the time period(s) during which the experience took place.
• Coverage: includes information about the particular coverage of the experience (e.g. cover-
age of a particular geographical area, of a particular type of e-markets, or of a particular
transaction phase).
• Subject: stores information about the topics that the experience referred to, in terms of the
business sector that the evaluated e-market belongs to, and the product / services it offers.
• Evaluation: stores the results of the experience, according to the multiple dimensions of the
evaluation instrument used, and from multiple evaluators.
• Audience: stores information about the roles of the audience that have taken part in the eva-
luation experience (e.g. customers/users, operators, evaluators).
• Relation: stores information about which is the evaluation instrument used to collect eva-
luation results, and which is the evaluated e-market.
3. Designing the e-market recommendation algorithm
During the years, the term ‘recommender systems’ has been introduced to generally describe
systems in which “...people provide recommendations as inputs, which the system then
aggregates and directs to appropriate recipients.”(Resnick & Varian, 1997). The envisaged
recommendation algorithm will have to synthesize e-market evaluations that have been stored
using expECEM. It is assumed that all the e-market evaluations are performed using the same
evaluation instrument, and have the same, multiple evaluation dimensions. In this section, the
e-market recommendation problem is modeled as a multi-criteria decision making one, and
therefore a multi-criteria recommendation algorithm is designed.
The problem of recommendation in a VC is referred to as the way to help the VC members to
identify the items (or ‘alternatives’) that are most likely to be interesting to them or relevant to
their needs (Konstan, 2004). Following the formalization of Adomavicius & Tuzhilin (2005),
we describe the e-market recommendation problem in the context of a business VC. In
particular, let C be a set of all the members of the VC and S a set of e-markets that some of
these members have already transacted with (e.g. for finding appropriate supplies or for
promoting their products). If u is a utility function u : C × S → ^ that measures the
appropriateness of recommending an e-market s to a business partner c, then for each partner
c∈ C we want to choose the e-market s’ ∈ S that will maximize this partner’s utility function.
More formally:
∀c ∈ C, s’ = arg max u(c, s)
s∈S (1)
In a real life situation, the utility function u is not defined on the whole CxS space but only on
some subset H of it (H ⊆ S). Thus, the goal of recommendation is to estimate (or approach)
the utility function u, in order to be able to predict utility values for the e-markets of the space
(CxS - H) for which u has not yet been defined. In most recommendation systems, the utility
function u is single-criterion (refers to only one attribute of an item s), e.g. an overall rating.
Nevertheless, utility can be an arbitrary function that involves more criteria of an item. In the
case that we examine, an e-market is evaluated upon the multiple criteria (attributes) of an