Building Web Reputation Systems- P6

Building Web Reputation Systems- P6:Today’s Web is the product of over a billion hands and minds. Around the clock andaround the globe, people are pumping out contributions small and large: full-lengthfeatures on Vimeo, video shorts on YouTube, comments on Blogger, discussions onYahoo! Groups, and tagged-and-titled Del.icio.us bookmarks. User-generated contentand robust crowd participation have become the hallmarks of Web 2.0.
Nội dung trích xuất từ tài liệu:
Building Web Reputation Systems- P6model is activated by a specific input arriving as a message to the model. Input gets theball rolling. Based on the requirements of custom reputation processes, there can bemany different forms of input, but a few basic input patterns provide the common basicstructure.Typical inputs. Normally, every message to a reputation process must contain severalitems: the source, the target, and an input value. Often, the contextual claim name andother values, such as a timestamp and a reputation process ID, also are required for thereputation system to initialize, calculate, and store the required state.Reputation statements as input. Our diagramming convention shows reputation statementsas inputs. That’s not always strictly accurate—it’s just shorthand for the commonmethod in which the application creates a reputation statement and passes a messagecontaining the statement’s context, source, claim, and target to the model. Don’t con-fuse this notational convention with the case when a reputation statement is the targetof an input message, which is always represented as a embedded miniature version ofthe target reputation statement. See “Reputation Targets: What (or Who) Is the Focusof a Claim?” on page 25.Periodic inputs. Sometimes reputation models are activated on the basis of an input that’snot reputation based, such as a timer that will perform an external data transform. Atpresent, this grammar provides no explicit mechanism for reputation models to spon-taneously wake up and begin executing, and this has an effect on mechanisms such asthose detailed in “Freshness and decay” on page 63. So far, in our experience, spon-taneous reputation model activation is not necessary and keeping this constraint outhas simplified high-performance implementations. However, there is no particularuniversal requirement for this limitation.OutputMany reputation models terminate without explicitly returning a value to the applica-tion at all. Instead, they store the output asynchronously in reputation statements. Theapplication then retrieves the results as reputation statements as they are needed—always getting the best possible result, even if it was generated as the result of someother user on some other server in another country.Return values. Simple reputation environments, in which all the model is implementedserially and executed in-line with the actual input actions, are usually implementedusing on request-reply semantics: the reputation model runs for exactly one input at atime and runs until it terminates by returning a copy of the roll-up value that it calcu-lated. Large-scale, asynchronous reputation frameworks, such as the one described inAppendix A, don’t return results in this way. Instead, they terminate silently and some-times send signals (see the next paragraph).Signals: Breaking out of the reputation framework. Sometimes a reputation model needs to no-tify the application environment that something significant has happened and specialhandling is required. To accomplish this, the process sends a signal: a message that56 | Chapter 3: Building Blocks and Reputation Tipsbreaks out of the reputation framework. The mechanism of signaling is specific to eachframework implementation, but in our diagramming grammar, signaling is always rep-resented by an arrow leaving the box.Logging. A reputation logging process provides a specialized form of output: it recordsa copy of the current score or message into an external store, typically using an asyn-chronous write. This action is usually the result of an evaluator deciding that a signif-icant event requires special output. For example, if a user karma score has reached anew threshold, an evaluator may decide that the hosting application should send theuser a congratulatory message.Practitioner’s Tips: Reputation Is TrickyWhen you begin designing a reputation model and system using our graphical gram-mar, it may be tempting to take elements of the grammar and just plug them togetherin the simplest possible combinations to create an Amazon-like rating and review sys-tem, or a Digg-like voting model, or even a points-based karma incentive model as onStackOverflow. In practice—“in the wild,” where people with myriad personal incen-tives interact with them both as sources of reputation and as consumers—the imple-mentation of reputation systems is fraught with peril. In this section, we describe severalpitfalls to avoid in designing reputation models.The Power and Costs of NormalizationWe make much of normalization in this book. Indeed, in almost all of the reputationmodels we describe, calculations are performed on numbers from 0.0 to 1.0, even whennormalization and denormalization might seem to be extraneous steps. Here are thereasons that normalization of claim values is an important, powerful tool for reputation:Normalized values are ...