Information Technology Reference
In-Depth Information
6.3.3 System Communication
ORPoperates on an event-driven interactionmodel. Events include visitors requesting
recommendations, visitors responding to recommendations by clicking, and news
articles added to the collection or updated thereafter. Events occur in predefined con-
texts. ORP represents context as feature vectors. These vectors comprise information
such as publisher, article, categories, and more. Events trigger messages containing
the contextual information. For instance, as a user visits a news article, all of ORP's
participants will receive a message. Participants may use this information to build
their recommendation models. Although, ORP will randomly select an individual
recommendation provider to serve this very request. ORP provides participants with
an application programming interface (API). The API allows participants to connect
their recommendation servers with plista's eco-system. The API uses JSON for data
encoding. ORP uses HTTP POST messages to exchange requests including item
updates, event notification, and recommendation requests. The contextual data in the
ORP is represented through vectors. The system represents such vectors as values
mapped to IDs. IDs are represented as integers. They refer to certain types of context.
Vectors comprise individual IDs or lists of them. Thus, vectors allow describing an
object by layering attributes. ORP distinguishes two types of vectors. One type clas-
sifies input vectors while the other refers to output vectors. Input vectors describe the
context of events and messages and may be used by the participants for contextual
optimization. Input vectors are static and cannot be modified. Output vectors are used
to convey information about calculations. During transmission, vectors are grouped
together by their type and packaged in a map where the key is the vector's ID and
the value related to an instance (depending on its type). The vectors group maps
are again grouped together depending on their class. Internally, ORP adapts a multi-
armed bandit component. Multi-armed bandit models enable systems to balance the
exploration-exploitation trade-off [ 45 ]. This trade-off implies that the system fails to
accurately estimate recommendation algorithms' performance beforehand. There-
fore, the system has to occasionally select seemingly suboptimal strategies to verify
that it continues to apply the best strategy. ORP randomly selects recommendation
algorithms among active participants. The system disables participating algorithms
in case they continuously fail to provide recommendations. Having fixed technical
issues, participants can re-establish the communication with ORP and again receive
requests. This approach guarantees simple exploration, minimal pre-testing, and low
risks of recommenders crashing. Additionally, the system contains a fallback recom-
mender which it activates as participating servers continue to fail.
Figure 6.1 depicts the system's structure and its components. Publishers inte-
grate recommendations as static javascript. The javascript loads recommendations
by asynchronously querying ORP. ORP returns a widget box captioned “You might
also be interested in…”, “Recommended articles:”, or similar texts. Frequently, ORP
includes small pictures next to recommendations. Recommendations consist of a
headline and the initial phrases up to 256 words of the recommended articles.
Search WWH ::




Custom Search