Hi All,
On Fri, Apr 4, 2014 at 11:11 PM, Dan Haywood <[email protected]>wrote: > I think I like Oscar's a bit more, also. > > Qn: Why is there a 1:1 relationship between Reputation and ReputationValue? > > ReputationValue entity encapsulates the result of the reputation analysis process. It can simply be a value type (a reputation score). And I think each Reputation object should have a corresponding reputation value, that's why I added it as a 1:1 relationship. Any ideas for a better model? > > > > > On 4 April 2014 17:08, GESCONSULTOR - Óscar Bou <[email protected]>wrote: > >> Hi Dileepa. >> >> Not sure about this, but seems a little "strange" the "cycle" on your >> model between the Context, Criteria and Reputation entities. >> >> Perhaps the Context is a more generic entity than Criteria, and it's the >> Criteria what should have a relationship with a Context, and also with >> Reputation? >> >> I agree with you on the cyclic model being bit strange. I also adjusted the association between ReputationValue and Criteria entitys as [ReputationValue]0..*-1>[Criteria] so that now ReputationValue has a uni-direction association to the criteria used for the computation. See : http://yuml.me/17514278 Something like this: >> >> http://yuml.me/3aa65a6f >> >> HTH, >> >> Oscar >> >> >> >> El 04/04/2014, a las 17:56, Dileepa Jayakody <[email protected]> >> escribió: >> >> Hi Oscar and all, >> >> On Thu, Apr 3, 2014 at 1:52 PM, GESCONSULTOR - Óscar Bou < >> [email protected]> wrote: >> >>> Hi Deleepa, >>> >>> Seeing at your last diagram, shouldn't the Criteria be related with (is >>> specific to) a Context? If so, a relationship would also be needed. >>> >> >> Yes, I agree. The criteria to calculate reputation depends on the >> context. Therefore there should be a relationship >> [Context]1-1..*>[Criteria]. >> I have modified the diagram like this : http://yuml.me/26953ad7 >> >>> >>> Perhaps the Computation Algorithm could also be specific for one or more >>> Contexts. In that case, a relationship is also needed. >>> >> >> I think, now that Context has a relationship with Criteria, the >> relationship between the ComputationAlgo and Context could be derived >> through the Criteria entity. >> >>> >>> Also, perhaps the relationship between Reputation and Criteria is >>> redundant, as it can be obtained through the ReputationValue. It could be >>> modeled as a derived relationship in Isis. >>> >>> Yes, Thanks for pointing out. Removed this relationship between >> Reputation and Criteria >> >>> HTH, >>> >>> Oscar >>> >>> >>> >>> El 03/04/2014, a las 09:59, Dileepa Jayakody <[email protected]> >>> escribió: >>> >>> >>> Hi Dan and all, >>> >>> I modified the diagram and the latest is : http://yuml.me/75c87f26 >>> >>> >>> On Thu, Apr 3, 2014 at 12:50 PM, Dileepa Jayakody < >>> [email protected] >>> >>> wrote: >>> >>> >>> Thanks Dan, >>> >>> I will modify the diagram with proper notations and reply with >>> explanations.. >>> >>> >>> On Thu, Apr 3, 2014 at 12:31 PM, Dan Haywood < >>> [email protected] >>> >>> wrote: >>> >>> >>> On 2 April 2014 08:09, Dileepa Jayakody <[email protected]> >>> wrote: >>> >>> Hi All, >>> >>> After doing some background reading on Reputation object modeling [1], >>> >>> >>> >>> (good to hear) >>> >>> >>> I >>> have extended my class diagram to describe the reputation analysis >>> >>> model in >>> >>> my application : http://yuml.me/c97453ec >>> >>> >>> There are some discrepancies between this diagram and the description >>> below... >>> >>> >>> >>> An entity >>> >>> >>> >>> Not sure if having an entity called "entity" is a particularly good idea; >>> could get confusing... >>> >>> >>> has a reputation >>> >>> >>> >>> The diagram shows the "entity" entity as having many reputations. >>> >>> An entity can have different reputations in different contexts. As an >>> >>> example entity might have a good reputation for email context but bad >>> reputation for marketing context. >>> Hence, [Reputation]1-1[Context] and [<<Entity>>]1-0..*[Reputation] >>> >>> >>> >>> >>> which describes it's value. EmailContact, Email >>> are the 2 entity objects in my application. >>> >>> >>> The diagram shows EmailContact and Email as having (an association with) >>> an >>> "entity", rather than being (implementing) entity. But I think the >>> latter >>> is probably what you want; Entity is an interface and EmailContact and >>> Email implement them. >>> >>> Yep, I wanted to show the inheritance relationship. Sorry for the mistake >>> >>> with notation. I have modified this in the latest diagram. >>> >>> >>> >>> >>> Reputation is an interface implemented by ReputationObject class. >>> >>> >>> The diagram doesn't show this, it shows an association. >>> >>> In yuml.me, think that is shown using RepuationObject -^ Reputation >>> >>> Also, ReputationObject isn't a particular great name. Why have >>> Reputation >>> as an interface at all; as I understand it there's likely only one impl. >>> >>> >>> I agree. I removed ReputationObject and added Reputation as an entity >>> in >>> the diagram. >>> >>> >>> >>> >>> >>> Reputation has a particular context/domain in which it isearned >>> >>> (eCommerce, >>> >>> films, technical forums etc ), >>> >>> >>> >>> Reputation *->1 Context >>> >>> >>> in this case the context is email >>> communication. The reputation's value is represented by the >>> >>> ReputationValue >>> >>> object which is calculated based on a certain criteria (In my case the >>> criteria are People associated with the email, topic and actions in the >>> email). Criteria defines the required parameters and the >>> ComputationAlgorithm to be used to calculate reputation value. >>> >>> >>> >>> The reputation value is calculated by the particular >>> >>> ComputationAlgorithm >>> >>> using the parameters given by the criteria. This is where the >>> implementation specific stuff comes in for calculation. Mahout >>> recommendation algorithms, Drools rules are implementations of such >>> ComputationAlgorithms. >>> >>> >>> From an implementation standpoint, my first pass would be to implement >>> ComputationAlgorithm as an enum. That way it can be polymorphically >>> dispatched to. >>> >>> Overall, I like the way that the domain is getting richer. But I do >>> still >>> worry pragmatically about where these entities are all to be persisted, >>> and >>> how to they are sync'ed. Perhaps you could extend the diagram and use >>> stereotypes to indicate for each entity whether its native persistence is >>> in Isis, or Mahout, or gmail, or somewhere else. >>> >>> >>> Yes, I will design the persistence model and we can discuss over that. >>> >>> >>> Could also indicate if types are entities or value types. >>> >>> HTH >>> Dan >>> >>> >>> [1] Adrian Paschke, Rehab Alnemr, Christoph Meinel, The Rule Responder >>> Distributed Reputation Management System for the Semantic Web >>> >>> >>> >>> >>> Thanks, >>> >>> Dileepa >>> >>> >>> >>> Óscar Bou Bou >>> Responsable de Producto >>> Auditor Jefe de Certificación ISO 27001 en BSI >>> CISA, CRISC, APMG ISO 20000, ITIL-F >>> >>> 902 900 231 / 620 267 520 >>> http://www.twitter.com/oscarbou >>> >>> http://es.linkedin.com/in/oscarbou >>> >>> http://www.GesConsultor.com <http://www.gesconsultor.com/> >>> >>> >>> >>> Este mensaje y los ficheros anexos son confidenciales. Los mismos >>> contienen información reservada que no puede ser difundida. Si usted ha >>> recibido este correo por error, tenga la amabilidad de eliminarlo de su >>> sistema y avisar al remitente mediante reenvío a su dirección electrónica; >>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. >>> Su dirección de correo electrónico junto a sus datos personales constan >>> en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la >>> de mantener el contacto con Ud. Si quiere saber de qué información >>> disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo >>> enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a >>> la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, >>> 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 >>> (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o >>> sus archivos adjuntos no contengan virus informáticos, y en caso que los >>> tuvieran eliminarlos. >>> >> >> >> *Óscar Bou Bou* >> Responsable de Producto >> Auditor Jefe de Certificación ISO 27001 en BSI >> CISA, CRISC, APMG ISO 20000, ITIL-F >> >> 902 900 231 / 620 267 520 >> http://www.twitter.com/oscarbou >> >> http://es.linkedin.com/in/oscarbou >> >> http://www.GesConsultor.com <http://www.gesconsultor.com/> >> >> >> >> Este mensaje y los ficheros anexos son confidenciales. Los mismos >> contienen información reservada que no puede ser difundida. Si usted ha >> recibido este correo por error, tenga la amabilidad de eliminarlo de su >> sistema y avisar al remitente mediante reenvío a su dirección electrónica; >> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. >> Su dirección de correo electrónico junto a sus datos personales constan >> en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la >> de mantener el contacto con Ud. Si quiere saber de qué información >> disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo >> enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a >> la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, >> 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 >> (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o >> sus archivos adjuntos no contengan virus informáticos, y en caso que los >> tuvieran eliminarlos. >> >> >> >> >> >> >
