From: cvs@openprivacy.orgCVS update: openprivacy/htdocs/notes/reputations
Date: Friday December 8, 19100 @ 17:40
Author: fen
CVSWEB Options: -------------------
Main CVSWeb: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi
View this module: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations
-----------------------------------
Update of /usr/local/cvsroot/openprivacy/htdocs/notes/reputations
In directory openprivacy.org:/home/fen/projects/openprivacy/htdocs/notes/reputations
Modified Files:
requirements.txt
Log Message:
updated requirements
*****************************************************************
File: openprivacy/htdocs/notes/reputations/requirements.txt
CVSWEB Options: -------------------
CVSWeb: Annotate this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?annotate=1.4
CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?rev=1.4&content-type=text/x-cvsweb-markup
CVSWeb: Diff to previous version: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt.diff?r1=1.4&r2=1.3
-----------------------------------
Index: openprivacy/htdocs/notes/reputations/requirements.txt
diff -u openprivacy/htdocs/notes/reputations/requirements.txt:1.3 openprivacy/htdocs/notes/reputations/requirements.txt:1.4
--- openprivacy/htdocs/notes/reputations/requirements.txt:1.3 Fri Dec 8 17:12:31 2000
+++ openprivacy/htdocs/notes/reputations/requirements.txt Fri Dec 8 17:40:38 2000
@@ -1,56 +1,57 @@
-$Id: requirements.txt,v 1.3 2000/12/09 01:12:31 fen Exp $
+$Id: requirements.txt,v 1.4 2000/12/09 01:40:38 fen Exp $
-Requirements:
+Reputation Server Requirements:
+=== top level feature list ===
-
- Minimal:
-
- -
-
- Optional:
+Database features (insert, select, delete)
+ define selection criteria (query) constraints
+ provide query mechanisms for standard data mining interfaces
+ when and how does this calculation span peer reputation servers?
+ define retrieval set format
+ define exceptions
+ define admin features, such as size, number of objects, etc.
- - Support a reputation:// URI namespace based on pet names.
- http://www.erights.org/elib/capability/pnml.html. This could provide a
- facility to specify a way to lookup a reputation based on a human name and
- include this URI in another facility (XML, e-mail, etc).
+Object validation
+ does the object that was grafted to still exist / has it changed?
+ are signatures valid/reputable?
- -
+Sorting, ranking
+ results may be returned ranked according to local server rules
+ enhance the object with high billing or additional local reputation if:
+ the signature/content/object has high reputation according to the
+ local agent
-=== access ===
+Reputation calculation (may require peer communications)
+ given an object, return its full reputation
+ as a set of object grafts
+ as a merged value
+ facility for 'blending' reputation results from multiple sources
-Provide query mechanisms so that the data can be mined in a standard manner.
+Local garbage collection, editing, enhancement and censorship
+ A reputation server can sweep its objects and, based on local criteria:
+ remove the object if:
+ the signature/hash is no longer valid
+ the signature cannot be validated (purely anonymous)
+ the signature belongs to a low-reputation source
+
+Note the many possibilities for a local reputation server to affect results
+ server reputation loss will occur when:
+ if it is found to be too biased, unreliable, or random
+ server reputation gain will occur when:
+ good results within some particular domain are regularly retrieved
+
+=== Optional ===
+
+Support a reputation:// URI namespace based on pet names.
+ http://www.erights.org/elib/capability/pnml.html. This could provide a
+ facility to specify a way to lookup a reputation based on a human name and
+ include this URI in another facility (XML, e-mail, etc).
-Facility for 'blending' reputation results from multiple sources
+=== Wish list ===
Ability to verify calculated results by requesting the 'opinions' which were
used to determine a calculation and then compare the results of the calculation
-with the opinion.
+with the opinion. (Note that this is unreliable, in that the returned set
+of 'opinions' is defined by the local reputation server(s).
-Local garbage collection, editing, enhancement and censorship
- A reputation server can sweep its objects and, based on local criteria:
- remove the object if:
- the signature/hash is no longer valid
- the signature cannot be validated (purely anonymous)
- the signature belongs to a low-reputation source (potential for local censorship)
- enhance the object with high billing or additional local reputation if:
- the signature/content/object has high reputation according to the local agent
- Note that overall, there are many possibilities for a local reputation server
- if the local reputation server is found to be too biased, it will lose reputation
- if it is found to yield very good results within some particular domain space
-
-Reputation Server Requirements - top level feature list
- basic database features (insert, select, delete)
- define selection criteria constraints
- define retrieval set format
- define exceptions
- define admin features, such as size, number of objects, etc.
- object validation
- does the object that was grafted to still exist / has it changed?
- are signatures valid/reputable?
- sorting, ranking
- results may be returned ranked according to local server rules
- reputation calculation (may require peer communications)
- given an object, return its full reputation
- as a set of object grafts
- as a merged value
This archive was generated by hypermail 2b30 : Mon Jan 22 2001 - 15:52:14 PST