Re: Comments on GSOC2014 ReputationBox proposal

[GESCONSULTOR - Óscar Bou]

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. Perhaps the Computation Algorithm could also be specific for one or more Contexts. In that case, a relationship is also needed. 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. HTH, Oscar El 03/04/2014, a las 09:59, Dileepa Jayakody <dileepajayak...@gmail.com> 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 <dileepajayak...@gmail.com 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 <d...@haywood-associates.co.uk wrote: On 2 April 2014 08:09, Dileepa Jayakody <dileepajayak...@gmail.com> 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  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.