Re: [orms] Comparison of documents

[Nat Sakimura <n-sakimura@nri.co.jp>]

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