Simple Reputation Feed

Session: Tuesday Session 3 Space A

Conference: IIW 10 May 17-19, 2009 this is the complete Complete Set of Notes

Topic: Simple "Reputation" Feed
Convener: Tatsuki Sakushima, NRI/OASIS OpenReputation TC

Note taker:

URLs of Note: http://buildingreputation.com/doku.php

Agenda
1. Introducing "Simple Reputation Feed" 2. What is your use case? What do you want the data to be? 3. Issues in the current desing?

What is "Reputation"
Reputation:
 * is a metric (a score, a rank, a state, a multi-dimensional profile, etc.) associated to an entity (a person, a business, a digital identity, a website, a  system, a device, a category of devices, a computing resource, etc.) or to a tuple [entity, attribute(s)] (e.g. [person,skill]) in a particular domain and at a particular moment in time. (Data)
 * is a subjective evaluation of the assertion about a subject being true based on factual and/or subjective data about it, and is used as one of the factors for establishing trust on that subject for a specific purpose. (Function)
 * helps you make sound judgments in absence of any better information. (Purpose)

Examples of Reputation Data

 * FICO credit score
 * Nielsen ratings for television programs
 * Page views for web sites
 * Online movie reviews and ratings
 * Dow Jones Industry average
 * Amazon Book reviews
 * eBay User feedback score
 * PageRank, Buzz, Digg, Facebook "Like", etc.

These are all aggregated reputation data examples. Reputation data takes other forms:
 * Assertion: "Harvard is a good law school."
 * Prizes and Awards: Nobel Peace Prize.
 * Actions: Volunteer for Earth day.

The Goal of Simple Reputation Feed
Why has never Reputation Feed taken off?


 * No standard data format for distribution.
 * No motivation to share?
 * eBay declined Amazon in late 90's.
 * No Web20. Web may not be so social back then.

Our goal would be: If we can share existing reputation data out there in a standardized way and let developers freely aggregate them, the potential and impact is tremendous. Feed helps de-compose data and re-compose something new.
 * To provide a data format in order to open up existing reputation data and to share it across domains.
 * To provide a data format like "Atom" for reputation data.

Approach
Subject: The evaluated entity(reputee). The entity could be a person, a business, a digital identity, a website, a system, a device, a category of devices, a computing resource, and a tuple [entity, attribute(s)] (e.g. [person,skill]) in a particular domain and at a particular moment in time. Context: The definition of reputation data. Context defines who/what(Subject) is evaluated in what context and how(Score). Score: The result of evaluation in this context. The score should be somewhat numeric value like a score, a rank, a grade, a rating, a digg/likeit/thumbup. It excludes opinions and reviews(text) because it is hard to aggregate as data.
 * Reputation is polysemic and polymorphic.
 * We need a reasonable scope to describe reputation data.
 * Reputation data must be machine-friendly and aggregatable.
 * How about Subject, Context, and Score?

Examples
'''Example 1. Simple ORMS Example'''  http://bookstore.co.jp/reputation/bookreview http://bookstore.co.jp/literature/auther/hmurakami/title/1Q84 1970-01-01T00:00:00Z 1970-01-01T00:00:00Z  '''Example 2. ORMS ReputationBundle Example'''   http://bookstore.co.jp/reputation/score/products/books http://bookstore.co.jp/literature/auther/hmurakami/title/1Q84 <Date type="http://bookstore.co.jp/reputation/date/lastupdated">1970-01-01T00:00:00Z</Date> <Date type="http://bookstore.co.jp/reputation/date/created">1970-01-01T00:00:00Z</Date> </Reputation> <Reputation id="http://bookstore.co.jp/reputation/document/MRIwEAYDVQQIEwlXa" type="child"> http://bookstore.co.jp/literature/auther/hmurakami/title/1Q84</Subject> ---whatever sub reputation data here--- </Reputation> <Reputation id="http://bookstore.co.jp/reputation/document/F1VuaXZlcnNpdHkgbX" type="child"/> ---only link to sub reputation document--- </ReputationBundle>

Design Principles
1. It only defines a "framework". ("Relationship" among elements.) 2. The transport layer is out of scope. 3. It keeps the structure simple. 4. It supports and covers 80% of use cases. 5. People intuit how to use it.
 * The data provider must define the context and detail of what the data means.
 * It is a markup language(XML) for writing reputation data.
 * No standardized score format, normalization and representation. (The data provider should define those in a "profile".)
 * However, it assumes REST API(HTTP GET) to be used for retrieving this document (data).
 * No more than 2 layers in hierarchy. (3 layers with <ReputationBundle>)
 * Only 6 elements are defined. (excluding ds:Signature)
 * , , , <Score>, <ReputationBundle>, 
 * It avoids defining a group element if possible. (To make the structure flat.)
 * It avoids defining unnecessary schema (elements, attributes).
 * It avoids defining unnecessary data types. (e.g. id values since URI is identifier.)
 * It avoids adding function for specific usage. (Can the usage apply to other use cases?)
 * It avoids supporting all needs out there.
 * The semantics of elements and attributes make sense to everyone.

Action Items for ORMS TC
1. To consider element naming alignment with terminology in "Building Web Reputation Systems". 2. To consider "JSON" representation from the beginning (for expecting more adoption.) 3. To consider non-numeric reputation data to be presented. (e.g. text for book review)