This is an idea for a reputation/trust metric system.
The basic idea has a few key parts:
The page is called "ReputationBudget" but upon further reflection, it's really a general architecture for ratings.
In order to say who you like/admire/trust (I'll just say "like" from now on), you just put up an XML document using a yet-to-be-specified "reputation budget ontology" and link to it from your FOAF page. This document will be called a "reputation budget document".
Hmm… upon further reflection, maybe we should allow the ratings themselves on the one hand, and the groupings into ratings budgets on the other hand, to be in separate documents. For instance, if you review your 10 favorite books, then each review could be on a separate web page, and somewhere inside those webpages you could provide the rating of that book. And then you could have a separate document that refers to all ten reviews and says, "include all of those in my list of rated books". Then a client could, for example, spider through FOAF pages and all these book reviews, and construct a graph of average book ratings according to you and your friends. I don't know if distributing one budget across many documents would be easy to program, though. Maybe RDF would help.. but I don't know enough RDF to know.
Your ratings consist of a list of target URIs and, for each URI, a real number denoting "reputation points", as well as, optionally, a URL correponding to the target's own reputation budget document.
The trick is that whoever reads these numbers will first renormalize them (add them up, then divide each number by the total). So, it's as if each person has a fixed number of reputation points to allocate to all of their targets.
You can also assign "attribute values" to each target. These values must be real numbers on a scale on 0 to 1. For instance, you might want to say something like "Bob is a great programmer" by giving Bob a value of ".8" in the "programming skill" attribute. Or you might want to say, "I trust John, but I don't necessarily put much stock in his trust ratings of others". So you might give John a large proportion of your reputation points, but then give him a small value in the "reliability of reputation ratings" property.
One more important detail: each reputation budget document has an associated "reputation type" property, whose value is a URI. The reputation type functions like a namespace; it tells the reader how to interpret the values. For instance, the default interpretation type might be "people I like". But another "reputation type" might mean "books i like". And another one might mean "people who I may have no opinion on as people but who tend to post interesting things on their blogs". And another one might be "people who I think have created valuable open-source stuff".
So, note that one person might post have multiple reputation budgets. For instance, you might post both a "people I like" and a "books I like" budget. Whether or not this is "legitimate" depends on the "reputation type" that you choose – each different "reputation type" is in essence its own internet standard.
For example, the default "people I like" type would specify that each human being should have no more than one "people I like" budget 1.
"Value by network context" is not a document or part of a document, but rather an idea. The idea is that a reputation budget does not have "value" just by being posted on the web. It has "value" only when it is linked to by other nodes in a network. For instance, if Bob tries to "subvert the system" by creating 2 reputation budget documents titled "people Bob likes", that doesn't mean that he gets twice as many "points" in his budget. The documents will be meaningless unless other people link to them. In the end, your "reputation browser client" will start with your own reputation budget, follow the links, and answer your reputation queries. No one will link to both of Bob's budgets, so Bob gains nothing.
Although clients are allowed to use the information in any way they want, it is envisioned that a reputation client would start at a seed node (the user's reputation budget) and traverse the network, building a tree structure. It is envisioned that rather than giving equal weight to every node encountered, the each node's values would be weighted by the "reputation points" assigned to that node by the parent.
For example, let's say that Amanda, Billy, and Cara were friends, and that Cara is friends with David, who is friends with Jake. Here are their reputation budgets:
Amanda: Billy: 5 points Cara: 5 points Billy: Amanda: 1 point Cara: 1 point Cara: Amanda: 1 point Billy: 1 point David: 1 point David: Jake: 3 points Kyle: 2 points
I would assume that a standard reputation browser client, responding to a query from Amanda, would say something like this:
Reputation ratings prepared for Amanda: Amanda: 4.16 (Billy, Cara) Billy: 1.66 (Cara) Cara: 2.5 (Billy) David: .83 (Cara) Jake: .5 (Cara->David) Kyle: .33 (Cara->David)
How are these generated?
For each person P to whom Amanda gave X points, we assign an additional X points for the subtree starting with P. Then, we look up P's reputation budget. After normalizing, we go through the list. For each P2 on the list, we reserve X*(P's normalized points for P2) points for the subtree starting with P2. We then give .5X(P's normalized points for P2) points to P2. Then, we recurse by looking up P2's reputation budget in order to distribute the other .5X(P's normalized points for P2) points. Etc.
If multiple people gave points to the same person, we sum them.
In this example, we calculated
Amanda's points = (Billy's points assigned by Amanda * Amanda's rating on Billy's list) + (Cara's points * Cara's rating on Billy's list) = 5*(1/3) + 5*.5 = 4.16 Billy's points = (Cara's points assigned by Amanda * Billy's rating on Cara's list) = 5*(1/3) = 1.66 Cara's points = (Billy's points assigned by Amanda * Cara's rating on Billy's list) = 5*(1/2) = 2.5 David's points = .5 * Cara's points assigned by Amanda * David's rating on Cara's list = 5 * (1/3) = .83 Jake's points = .5*(David's points so far) * Jake's points on David's list = .83 * (3/5) = .25 Kyle's points = .5*(David's points so far) * Kyle's points on David's list = .83 * (2/5) = .16
Note that in this algorithm, the points in the query result will always add up to at most 10 points (because Amanda's friends were "given" a total of 10 points to assign to their friends). In this example, 10 points is not reached (we're about .41 short) because neither Jake nor Kyle specified their own reputationBudgets; so, the .25 and .16 that were put aside to spend on Jake and Kyle's friends was never used.
Note that other clients may choose to use different algorithms and come up with different ways of using this information. But this is one example that should demonstrate:
A very messy, hastily written Python program that implements an algorithm close to that given above has been uploaded to the page ReputationBudgetClientExample. The output of the client may be found on the page ReputationBudgetClientExampleOutput.
In writing an email to DannyAyers, I formulated another introduction to the idea that may be more concise:
although all parts of the idea, taken individually, are old, the 3 most crucial "newest" parts are:
the ratings would be expressed via some semantic web document, similar to (or perhaps an extension of) those described at http://dannyayers.com/xmlns/rev/
the ratings could be used to rate items such as books or to rate people (in which case perhaps they could form a "reputation economy")
clients could use the ratings information however they wished. for instance, different clients could have different ways of calculating the "trust" or "reputation" of a target person.
the examples I've given aren't a well-thought out format, just something I thought up to have examples. Here's some examples:
See also other StandardizedFormatsForRating