From: cvs@openprivacy.orgCVS update: openprivacy/htdocs/notes/reputations
Date: Wednesday December 13, 19100 @ 0:18
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:
some replies to KAB's markup and spelling/format corrections
*****************************************************************
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.29
CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?rev=1.29&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.29&r2=1.28
-----------------------------------
Index: openprivacy/htdocs/notes/reputations/requirements.txt
diff -u openprivacy/htdocs/notes/reputations/requirements.txt:1.28 openprivacy/htdocs/notes/reputations/requirements.txt:1.29
--- openprivacy/htdocs/notes/reputations/requirements.txt:1.28 Tue Dec 12 23:55:38 2000
+++ openprivacy/htdocs/notes/reputations/requirements.txt Wed Dec 13 00:18:33 2000
@@ -1,8 +1,11 @@
-$Id: requirements.txt,v 1.28 2000/12/13 07:55:38 burton Exp $
+-*- indented-text -*-
+$Id: requirements.txt,v 1.29 2000/12/13 08:18:33 fen Exp $
+
Reputation Server Requirements: top level feature list
(kab) FEN: do we really need this here? seems like shameless self promotion.. :)
+(fen) KAB: yes, I think this helps for the time being to keep the page focused
"The OpenPrivacy Platform enables a distributed, secure marketplace
for anonymous user demographic and profile information."
@@ -30,16 +33,20 @@
1. decentralized, peer-to-peer
a. agent => reputation server [ => broker ]
-
2. a reputation can be attached (grafted) to any URI
- a. all reputations are URL-addressable
+ a. note URIs can reference non-networked resources (books, cars, etc.)
+ b. all reputations are URL-addressable
i. all reputations can have reputations grafted to them
- ii. since a reputation can be grafted to a URI... it can also work for
- conventional non-networked resources (books, cars, etc)
- iii. it is only 'possible' that a reputation may be addressable, an
- agent/computer resources can not be certain that a given reputation
- server holds the value it needs... Reputation server reputation can
- grow based on this.
+
+[(kab) it is only 'possible' that a reputation may be addressable, an
+agent/computer resources can not be certain that a given reputation server
+holds the value it needs... Reputation server reputation can grow based on
+this.]
+[(fen) on the contrary, I believe that all reputations must be addressable
+- they must in fact be XML DSigs of the sort we have defined in /src/xml/
+reputation-opinion-example.xml. It may not be accessible (the server may be
+down or it may have been deleted), but it must be addressable.]
+
C. === Security, Authentication, Privacy, Validation ===
Key:
@@ -85,6 +92,7 @@
Note: Getting data in and out of the system securely is not part of this spec
D. === Data store facility ===
+
1. Data store features to support:
a. setReputation(URI=object, XML=reputation) // insert
b. reputationCollection = getReputation(querySet=???) // select
@@ -105,10 +113,12 @@
i. size of database (Kb)
ii. number of objects
iii. (what else?)
- iv. generally this is out-of-scope for a reputations system.. it should
- be provided by an underlying databased facility.
- f. should uses a standardized interface. SOAP, XQL, etc. This needs to be
- defined as this technical area is very limited to-date.
+ iv. generally this is out-of-scope for a reputations system. it should
+ be provided by an underlying database facility.
+ [(fen) kab: are you saying that admin features are
+ out-of-scope? should we not define a minimum set required?]
+ f. should uses a standardized interface.
+ i. SOAP, XQL, etc. (TBD: this technical area is very limited to-date)
2. Standardized data format specification
a. based on the xmldsig namespace (xmlns="http://www.w3.org/2000/09/xmldsig#")
@@ -122,10 +132,11 @@
c. technically any XML data could be stored in an 'reputations' based XML
repository. XML Signature will probably be used more often.
-
3. Standardized data store API
a. (XML...)
+E. === sorting, ranking, calculating ===
+
1. Sorting, ranking
a. results may be returned ranked according to local server rules
b. local reputation enhancement
@@ -157,8 +168,8 @@
1. Agent discovery (in a distributed, peer-to-peer network)
a. local directory maintenance
i. initial trusted agents 'built-in'
- ii. address book maintenence facility
- b. find an agent pased on:
+ ii. address book maintenance facility
+ b. find an agent based on:
i. reputation
ii. capability(s)
iii. price, speed, ...
This archive was generated by hypermail 2b30 : Mon Jan 22 2001 - 15:52:14 PST