RE: [orms] Comparison of documents

["Giles Hogben" <Giles.Hogben@enisa.europa.eu>]

Hi Nat,
In your example, the service level would be an attribute:
(Pseudonym= SubjectID, Attribute= serviceLevel, Value=good)
So in your example, the DisplayScore would be what the algorithm spits
out, even if we are not allowed to know what that algo is? I think the
idea of datapoints makes sense. In cases where the voteset is large, one
might send just datapoints over the wire and refer to a URL where the
vote set might be found if it is open. This is more or less what eBay
does - you see the aggregate and can drill down into individual votes if
you want.

In deciding what the data points are, I guess we would go for some of
the parameters used by popular algorithms. I can't really see how one
could provide suitable data-points for a 2nd-order algorithm though.

WRT call timing - I am in Heraklion, Greece, which is GMT +3 so it is
midnight here. I checked ET on the web
(http://wwp.greenwichmeantime.com/time-zone/usa/eastern-time/) and it
was 7 hours behind my current time. It's impossible to satisfy everyone
so this is not a complaint, just an explanation as to why I probably
won't make it...

Regards,

Giles

> -----Original Message-----
> From: Nat Sakimura [mailto:n-sakimura@nri.co.jp]
> Sent: 25 June 2008 15:08
> To: Giles Hogben
> Cc: orms@lists.oasis-open.org
> 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