On 18/10/13 17:08 +0200, Udo Spallek wrote: > Hi Cédric, > > thanks a lot for your feedback! > > Fri, 18 Oct 2013 15:15:15 +0200 > Cédric Krier <[email protected]>: > >On 18/10/13 14:01 +0200, Udo Spallek wrote: > >> 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. > In structural relationships could be combinations which doesn't make > sense, like making parent-child relations out of persons. Employees can > be persons only. Companies are always 'organizations'... > It is just collecting semantic information and find ways to use them.
Could be solved by adding domains but I don't think it is really useful.
Because it gives false impression about control.
> >> 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.
> no, that's unfortunately too simple. A 'relation' or 'relationship' is a
> _relational_ link or connection, not a functional. E.g. in another
> relationships UVW can be also play the role as a 'partner' of the
> enterprise, when they sponsoring a convention.
I don't agree with you. The proof is that the word "Customer" is in your
example in the name of the relation and also in the role.
There are here a duplication of information.
> >> 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.
> Here my point is: ability to collect different opinions about one and
> the same thing. Here are two employees having different opinions about
> one and the same interest. Again, as the name 'Relationship' suggests,
> it is about relational connections, not functional.
I don't think such data design could be re-used/exploit in anywhere.
I think also that it is not a relation because it is not a fact.
For your example, I will just store this information on the
sale_opportunity not on the party.
> >> 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.
> Wrong. The collected data is about the point of view of everyone
> (usually Tryton users) who fills the database with
> opinions/meanings/facts. These facts can unfortunately change over time.
Not for me, relationship must be filled with fact and fact doesn't
change over time.
> >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.
> There is no 'point of view of the company', because the company is not
> a person/user, which can encode the information/opinions. And be sure
> facts can be 'wrong' or getting 'wrong' over time.
Of course if you collect mood but not if you collect fact.
> >> 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.
> Why?
Because it constraints to collect fact on which you can build stuffs.
Also it is completly free about which facts you collect.
> >I don't see any advantage about the role because the role is contained
> >in the relation.
> ... so in the end, someone who really needs a relationship management
> will have a table with many many different relations. Without having
> some *aspects* to look on the data like roles and relation_types, it is
> nearly the same PITA as searching a bunch of free text fields filled
> with data ...
I don't get you because in your example you'll get the same amount of
relation. So of course if you store a lot of relations, you will have
a lot of relations.
If later you want to filter them, as I said, a group of relation type
could be added.
> Roles instead are declarative: The user 'defines' if a party is
> a 'customer',
I though we agree that such declarations were useless.
Someone is a customer because he buys something, not because someone put
a flag (idem for supplier).
> 'employee'
Already exist.
> or 'doctor'.
Could be added but it doesn't involve a relation.
But of course to a doctor will create new relations like
"doctor of"/"patient of"
> You can say when someone started
> to be a 'customer', 'employee' or 'doctor'. And you can say when someone
> stops playing a role.
Roles are managed by creating a Model for it like:
- Employee
- Company
- Carrier
- Bank
etc.
> Roles can be used to filter parties like
> showing customers on top of the search parties in out invoices or sales.
Bad example because anyone can be a customer.
> And parties with roles take part in a relationship.
Here is our divergence. The definition of the relation contains the
roles.
Example:
"Employee of" -> there is a employee and a company
"Customer of" -> there is a customer and a supplier
"Subsidiary of" -> there are two companies
"Salemen of" -> there is a party and a company
> >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.
> Putting from role and to role together in one couple sounds
> interesting, but is IMHO a premature implementation detail.
It is the definition of the relation.
> Just to be sure:
>
> Do you think every example I gave can be translated
> into the conception of Alberts blueprint, without information
> loss?
Yes.
> Can you translate the examples to fit the blueprint?
> >> Table 1:
> >>
> >> ============ ========== ========== =========== ============
> >> PARTY
> >> RELATIONSHIP FROM FROM TO TO
> >> TYPE NAME PARTY ROLE PARTY ROLE
> >> ============ ========== ========== =========== ============
> >> Customer ACME Customer DEF Internal
> >> Relationship Company firm organization
> >> ------------ ---------- ---------- ----------- ------------
Customer of
> >> Customer Eric Customer UVW Competitor
> >> Relationship,
> >> ------------ ---------- ---------- ----------- ------------
Customer of (competitor is a relation between UVW and the current
company).
> >> Organization XYZ Subsidiary ABC Parent
> >> Rollup firm company Organization
> >> ------------ ---------- ---------- ----------- ------------
Subsidiary of
> >> 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
> >> ------------ ---------- ---------- ----------- ------------
Bad example.
> >> Organization Customer Division DEF Subsidiary
> >> Rollup Service firm
> >> Division
> >> ------------ ---------- ---------- ----------- ------------
Division of
> >> Agent Sell- Sales DEF Internal
> >> Relationship Assist. agent firm organization
> >> Corp.
> >> ------------ ---------- ---------- ----------- ------------
Sale agent of
> >> Supplier Fantastic Supplier DEF Internal
> >> Relationship Supplies firm organization
> >> ------------ ---------- ---------- ----------- ------------
Supplier of
> Or is the approach in the blueprint for rolling-up parties?
I don't understand the question nor the "rolling-up parties".
--
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/
pgpmpLFIalSjo.pgp
Description: PGP signature
