[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [orms] Comparison of documents
Thank you very much for your input. This helps a lot. In general, I agree to your point. As to the data set in <reputation></reputation> is concerned, I think it is worthwhile to have number of data points, statistical distirbution, and standard diviation (or variance), in place of <voteSet /> especially when <voteSet /> tends to be large, or poses some privacy issues. (I actually think this voteSet idea is really nice, though.) FYI, what I have been proposing is something like (following your example): <reputation> <assertion id="http://www.reputation.com/12345"> <SubjectID>http://www.exampleBuilderX.com/</SubjectID> <SubjectPublicKey>{Some Key Material}</SubjectPublicKey> <ReputationServiceID>http://www.reputation.com/</ReputationServiceID> <Criteria> <name>http://www.reputation.com/ontologies/serviceLevel</name> <value>http://www.reputation.com/ontologies/good</value> </CriteriaID> <CriteriaText>{Some Text explaining the Criteria}</CriteriaText> <DisplayScore>0.95</DisplayScore> <RawScore>0.65</RawScore> <Distribution>http://oasis-open.org/orms/gamma</Distribution> <Mean>0.52</Mean> <StdDiv>0.2</StdDiv> <PubDate>2008-06-24T12:00:00Z</PubDate> <Expiry>2008-09-24T12:00:00Z</PubDate> <sig>{some signature here}</sig> </assertion> <voteSet>http://www.reputation.com/votes/no1.xml/</voteSet> </reputation> Instead of Algorithm, I have specified its statistical qualities, as I think in many cases the actual algorithm will not be open and thus having the name of it is not very useful. With regard to the call timing, I believe it is not quite mid-night for Europe ;-) Current time schedule is: Tokyo: 6:00AM (Summer) 7:00AM (Winter) Europe: 10:00PM U.S. East Coast: 5:00PM U.S. West Coast: 2:00PM The reverse time schedule may be: Tokyo: 10:00PM (Summer) 11:00PM (Winter) Europe: 2:00PM U.S. East: 9:00AM U.S. West: 6:00AM Giles Hogben wrote: > Dear All, > As requested, I took a (quick) look at the Reputation ontology model and > wrote down some thoughts as a comparison with my reputation model (both > docs attached). Unfortunately the call times are rather difficult for > Europeans (Midnight here) so unless this changes, I won't make many > calls, if any, > > Regards, > > Giles > > [1] http://www.iiia.csic.es/~jsabater/Publications/2007-TrustWS.pdf > (attached) > [2] hogben-reputation2.pdf (attached) > > 1. Overlap > ----------- > Entity, Source, Target <==> Pseudonym > Focus <=?=> Assertion > Reputation <==> Aggregate Score > > 2. General points > ------------------ > [1] > -is unnecessarily complex, which restricts its applicability within a > web/electronic context. In particular, [1]: > - includes elements of subjective experience which are impossible to > derive from an electronic context > - precludes more advanced reputation algos because it prescribes how > second and higher order reputation algos should operate (reliability > etc...). > - prescribes aspects of assertions which should not be restricted (e.g. > good/bad, Norm/Standard/Skill) - reputation may not just be about good > or bad and the Norm/Standard/Skill classification seems unnecessary for > our purposes - why not just let reputation cover any assertion. Why > restrict the model like this? > - does not model authentication of the voter/entity. One could say that > this is just yet another assertion but in IAM contexts, it is a very > specialised type of assertion. > > [2] > - is simpler and more closely fits the electronic use-cases we have > (from what I've seen) > - is more closely aligned to SAML and other IAM models (using assertions > and authentication etc...) > > Specific criticisms of [1]: > ---------------------------- > -Strength - the use of reliability of the evaluation as the only > second-order reputation statement possible makes assumptions about the > algorithm used and therefore makes the model a bit restricted. It is > simpler IMO just to have a heap of assertions, some of them referring to > other assertions and let the algo derive reliability. This allows you to > use anything from the time of the assertion to the authentication method > used by the voter as an input to the second-order evaluation. > -Good or bad is just another assertion - why separate it out - this > creates unnecessary complexity and restriction (see above)0. > -It is better to simplify the model and just have assertions rather than > good/bad assertions, reliability assertions etc... and an algo which > mashes them up into an overall evaluation. Esp since algos may be > proprietary. > -Norm/Standard/Skill is also unnecessarily prescriptive. > - WRT "SimpleBelief, a belief that the holding agent acknowledge > as true, and MetaBelief, a belief about others' belief" - again > unnecessarily complex and restrictive - refers to information which is > not available in the data available to algos. > - Image and direct experience are also completely unnecessary in an > electronic context - we don't need to know about people's mental states > - just the assertions they made. This is not how algorithms work. > Algorithms just take a stack of assertions (whatever the mental states > of those who made them) and spit out a score. > > > > > Giles Hogben > Network Security Policy Expert > European Network & Information Security Agency (ENISA) > Tel: +30 2810 391892 > Fax: +30 2810 39000 > > -- Nat Sakimura (=nat) Nomura Research Institute, Ltd. XDI.ORG Vice Chair
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]