On 18/10/13 14:01 +0200, Udo Spallek wrote: > Hello Albert, > > great that you reanimate the discussion. > > Wed, 9 Oct 2013 19:15:29 +0200 > Albert Cervera i Areny <[email protected]>: > >I've just created a blueprint for it. Your comments will be very > >welcomed. > >[1] https://code.google.com/p/tryton/wiki/PartyRelationship > > IIUC the blueprint proposes structural relationships like memberships or > roll-ups. IMHO the handling of structuring parties without sorting them > them into persons and (legal/informal) organizations makes the > later use of the information complicated (See [1] for the aged > plannings).
I don't see why. > But more important for me is, relationships could be so much more > than *just* a structural roll-up of people and organizations. I don't think the current design is. > Len Silverston, - the guy from whom we borrowed the conception of the > actual party model,- proposes already a conception[2][3] for a > relationship management which introduces *party roles* to relate > parties in a relationship. His proposed design is not restricted to the > management of *structural relationships* or just *customer > relationships*. We did not always follow it otherwise we will have a Rube Goldberg machine. > Len's model is able to handle the traditional > customer relationships like (see table 1 for the data): > > "In a Customer-Relationship, Party ACME Company takes the > role as a Customer of DEF firm an Internal Organization" Yes. > but also to collect information about a competitor: > > "In a Customer-Relationship, Party Eric is a Customer > of Party UVW an (external) Competitor" And why can't we store it with current design? The relation type will be "is customer of". The fact that UVW is a competitor is outside the relation because it is the relation the current company has with UVW. > It can be used to describe hierarchical relationships like company > roll-ups your blueprint also provides, > > "In a Organization-Rollup-Relationship, Party XYZ is a Subsidiary > of Party ABC the Parent Organization" > "In a Organization-Rollup-Relationship, Party DEF is a Subsidiary > of Party ABC the Parent Organization" Same here. > or handle information with different opinions > > "In Sales-Lead-Relationship, Party Thomas is a Hot-Lead > of Party Victor an internal employee" > "In Sales-Lead-Relationship, Party Thomas is a Cold-Lead > of Party Jack an internal employee" > > "In a Sale-Chance-Relationship, Party Thomas is a 90%-Chance > of Party Victor an internal employee" > "In a Sale-Chance-Relationship, Party Thomas is a 10%-Chance > of Party Jack an internal employee" I would prefer to have a percentage field on the relation for such case instead of predefined value in the relation/role. > The basic idea of Silverston's conception is to collect > semantic information the company is interested in separated by > relationship types. It is using the "roles" (and role types) the parties > *take* or *play* in the relationship as the "relators". I think the error is here. It is only about the point of view of the company. I think it is more powerful to remove this point of view and be generic. And later with customization adding the point of view if needed. > So for me, either the name 'Relationship' or 'Relation' is much too > general for the structure-only approach of the blueprint, or the > functionality misses all the needed parts to build real *semantic* > relationships. I think it is excatly the power of this design. > > Table 1: > > ============ ========== ========== =========== ============ > PARTY > RELATIONSHIP FROM FROM TO TO > TYPE NAME PARTY ROLE PARTY ROLE > ============ ========== ========== =========== ============ > Customer ACME Customer DEF Internal > Relationship Company firm organization > ------------ ---------- ---------- ----------- ------------ > Customer Eric Customer UVW Competitor > Relationship, > ------------ ---------- ---------- ----------- ------------ > Organization XYZ Subsidiary ABC Parent > Rollup firm company Organization > ------------ ---------- ---------- ----------- ------------ > Organization DEF Subsidiary ABC Parent > Rollup company company Organization > ------------ ---------- ---------- ----------- ------------ > Sales-Lead Thomas Hot-Lead Victor internal > employee > ------------ ---------- ---------- ----------- ------------ > Sales-Lead Thomas Cold-Lead Jack internal > employee > ------------ ---------- ---------- ----------- ------------ > Organization Customer Division DEF Subsidiary > Rollup Service firm > Division > ------------ ---------- ---------- ----------- ------------ > Agent Sell- Sales DEF Internal > Relationship Assist. agent firm organization > Corp. > ------------ ---------- ---------- ----------- ------------ > Supplier Fantastic Supplier DEF Internal > Relationship Supplies firm organization > ------------ ---------- ---------- ----------- ------------ I don't see any advantage about the role because the role is contained in the relation. If we take the above example, they are no cross-mixing between the possible role and the relationship type. Indeed for me, in the current proposal, the relation type is the couple (from role, to role). And the Silverston's relationship type could be a group of relation type. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgp6GHxXtp5EP.pgp
Description: PGP signature
