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:

• 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.

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.

Approach

• 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?

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.

Examples

Example 1. Simple ORMS Example <Reputation>

 <Context>http://bookstore.co.jp/reputation/bookreview</Context> 
 <Subject>http://bookstore.co.jp/literature/auther/hmurakami/title/1Q84</Subject> 
 <Score type="http://bookstore.co.jp/reputation/score/products/books/fivestar">4.3</Score> 
 <Score type="http://bookstore.co.jp/reputation/score/products/books/rank">1</Score> 
 <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>

Example 2. ORMS ReputationBundle Example <ReputationBundle>

 <Reputation id="http://bookstore.co.jp/reputation/document/MIICyjCCAjOgAwIBAg" type="parent"> 
   <Context>http://bookstore.co.jp/reputation/score/products/books</Context> 
   <Subject>http://bookstore.co.jp/literature/auther/hmurakami/title/1Q84</Subject> 
   <Score type="http://bookstore.co.jp/reputation/score/products/books/fivestar">4.3</Score> 
   <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"> 
   <Subject>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.)

• 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".)

2. The transport layer is out of scope.

• However, it assumes REST API(HTTP GET) to be used for retrieving this document (data).

3. It keeps the structure simple.

• No more than 2 layers in hierarchy. (3 layers with <ReputationBundle>)
• Only 6 elements are defined. (excluding ds:Signature)
• <Reputation>, <Context>, <Subject>, <Score>, <ReputationBundle>, <Date>
• 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.)

4. It supports and covers 80% of use cases.

• It avoids adding function for specific usage. (Can the usage apply to other use cases?)
• It avoids supporting all needs out there.

5. People intuit how to use it.

• 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)